Now to move on to the game structure itself. I'm not too keen into drawing UML diagrams or other fancy charts, also because I have not gotten really comfortable with pre-visualization tools on the computer. I'd rather sketch them on paper and take some photos of it with a phone. Guess this calls for getting a drawing tablet (anyone have one, does it greatly increase productivity even for programmers?) However, at least I have a tree-like structure for my code organization.
This planning comes easier as I figure out the first thing I want to do with my terrain loader is to put it in a game state to represent the in-game map editor. I have barely mentioned it in this journal, but I made a puzzle game clone as a learning experience in building a screen and menu system from an XNA sample, where multiple states and screens run independently of each other. The game may not be 100% done, but its code is stable enough for me to be able to port the system into this new game. Because this would be the most complex game I've attempted, I look forward to seeing how far I can take it. With a loading screen and transition to game modes are in place, it will at least finally start feeling more like a game than a tech demo.
The graphics engine is still a work in progress so I will work on it together with making the game. The game code will be organized in three different areas: Core, Game, and Screens.
- Graphics engine (my own)
- Physics engine (BEPU)
- File saving/loading
- Screen system (from my last game)
- Menu interactions
- Screen drawing/updating system
- Game logic, AI
- Player interactions
- Game objects
- Editing tools and functions
- Loading screen
- Gameplay modes
- HUDs and interfaces
Core contains all the systems that deal with the lower-level workings of the game. Sending data to the graphics engine, setting up and managing physics (using BEPU for this one), input management, and the loading and saving of files all go here.
Game contains all the very game-specific logic that's all about setting the rules, game modes, and specific interactions with game objects. They all tie into Core in some way, depending on what they are responsible for doing. A more specific area, Editor would include all the tools and functions used for the game's map editor mode.
Screens can be seen sort of like game states and also like components that, when grouped together, can describe a game state or mode of behavior. They are loaded and ran from the screen system, and either specialize on displaying information related to the game, or tell the user what actions are available. Background screens, gameplay screens, HUDs, inventory screens, and menus would belong here.
As you may have noticed, the three groups tend to progress from low-level to high-level code. This was not really intended, but does give me a better idea of how to pass data around.
When the program launches it add a Screen to a list, which loads the content to be rendered. Here is the game loading a terrain in real-time, with some interactions handled by an "Editor" screen.
There are a few issues I have to take care of with the screens and graphics. Both the screen system and graphics engine are loaded as XNA game components, which means they draw and update automatically within the game, outside of the screen system's control. Although the content loading code is in the Editor screen, I need the option to make the explicit choice of what order the graphics should be drawn, so that any graphics that are set in a particular screen get drawn with that screen's Draw call.
- Game logic, AI