A quick question on how you guys approach game development. Do you start completely with the back-end business logic for the game (the models/controllers), with disregard for the graphical end… and then create the client interface (using jme of course!) to access the controllers, so the game "client" is highly abstracted from the game logic?
So if I wanted to create a card game, I would start with a simple Java project, write the classes for the cards, the deck, the players, the rules for the game, a class to evaluate the hands, etc, before I ever start worrying about the GUI? Or is this simply a matter of preference? If so, what is your preference?
Balforth said:
A quick question on how you guys approach game development. Do you start completely with the back-end business logic for the game (the models/controllers), with disregard for the graphical end... and then create the client interface (using jme of course!) to access the controllers, so the game "client" is highly abstracted from the game logic?
Yes, that is an excellent way of achieving good object oriented design. I usually work that way, with a very sketchy basic GUI for testing the functionality. Note that you don't need "perfect" business logic with all functionality and their tests before you even start thinking of UI stuff, but it sure helps to have at least all the contracts (Interfaces) in place.
Working the other way is much harder and will likely yield "spaghetti code" which you'll never want to look at again.
I suggest you to take a look at www.lostgarden.com to get sme insight in game design, or, how to approach game projects in general.
As most of the old guys know, I like to have a basic framework to work over, such as http://www.jmonkeyengine.com/jmeforum/index.php?topic=6980.0. Then I go straigh to code simple prototypes, whithout too much graphics (although this framework enables the fast prototyping using graphic assets from big bang time).
I tend to work later on HUD and these stuff, but that’s a matter of preference.
Anyway, I like to draw in paper, both top down views of the game world and example screens for HUDs.
EDIT: Regarding OO design, I tend to use the componentized approach described in the second link, since it’s difficult to code 3D game “logic” without thinking (and using) Vector3f and other stuff scene-graph related. For a card game it’s possible to have this kind of abstraction layer and isolation. For most games I do, it’s not.