I was curious, before going straight into the implementation do you create a high-level architecture of what you are trying to create. For example, take for instance the Isosuface Dev Experiment by Pspeed, was a high-level architecture created before implementation?
Maybe you get into game development a bit more, then you’ll be able to ask more specific questions that can actually be answered.
If you mean did I write a design document or something: nope. I think I might have taken some notes on specific subsystems just to get details straight but frankly the high level architecture for almost every game is exactly the same.
I think unless you plan on making a game/application which either require some kind of third party or you plan on exposing something to third parties then a design as such is a bit of an overkill. You don’t want to over engineer things if you can help it.
Not sure what you mean with this exactly, what is the outcome of “creating” an architecture? In many cases I will generally have design discussions with my fellow developer(s) and often do we actually see the internal structure of an application change as it evolves.
One thing I’ve taken note of so far when it comes to JME in specific is that we generally try to separate code which is used for game logic, the rules of the game as it were, from the code that translates the entities into geometries, meshes, sounds etc. for rendering within the scene. This keeps it nice and clean if ever we were to use another game engine or if we decided to update to lets say 3.1 in which case we can just rewrite the translation layer.
Another good thing with this is that most if not all game logic is unit testable 
2 Likes
I personnaly use the MVC pattern as a base, and dive immediatly into the code, implementing things one after the other, and refactoring when it becomes too messy.
I spend a LOT of time in refactoring, but if I try to fix an architecture at the beginning, the refactor is even longer ^^
1 Like
Yeah, the one thing that 99% of software projects share is that the author wishes he’d done it differently when looking back. Strategies that allow flexibility and easy refactoring (clean separation, decoupling, etc.) are the best for this reason.
1 Like
This, try to make a flexible architecture with loose coopling, use Interfaces where possible, ect.
This allows way better changing later. (One part where Entity-Component-Systems shine btw.)