“A game is just a real-time database with a pretty graphical front end.” This is what one of my college professors told me when we were talking about implementation styles for various game types. I will let you take that statement how you will, but it hit a chord with me, and I have decided to take it quite literally and design a game accordingly. I have never done a game in this fashion so this will be an learning experience for me, and I need a place to sort out all the details. I figured I would do that here, instead of on paper, that way I can get feedback and maybe even help guide others who want to take the same approach.
I plan to use this post to sort out how everything will function and work together, and no doubt after countless edits I will end up with a working model to start actually programming the game with.
I should probably start with what kind of game I am going for, and define a scope (and hopefully not creep over it) At the current moment I am really into real-time strategy games! I just finished a simple RTS game called Exodus, and it is this game that I am going to try to re-implement via this design strategy.
Exodus is a space based RTS with one of it’s coolest features IMO being a dynamic map (planets and other solar objects orbit stars and planets, causing the map to constantly change) A player builds various space platforms to carry out tasks such as mining minerals from asteroids, or building war ships. The goal of the game is to eliminate the opposing player, or players.
My current implementation of Exodus includes a state machine for the various game states, like the Intro, Main Menu, Game Settings, Game, Game Results, and Credits. It also used a simple inheritance style entity system where all the games entities where stored in an ArrayList.
What I am thinking for the new implementation:
First off, the state machine for the game states can probably stay, but the entity system will have to change. Here is what I am thinking:
All the game’s entities will be stored in a HashMap with a String as the key, and obviously the entity as the value. the String will be the entities unique ID (like in a database) I may even have two HashMaps and flip between them for death checking. All the logic will be off loaded from the entities to module classes. Each of these Modules will carry out a specific task and will hold a list of all the entity IDs to perform this task on. A cycle of the game loop will consist of processing all of these Modules.
Without too much thought here is a list of all the tasks I will need Modules for:
Rendering
Moving / Orbiting / Scrolling (screen moving) *these may become individual modules
Death Checking
Collision Detection
Attacking (firing weapons)
Creating entities (i.e: creating weapon projectiles)
Input Handling
AI logic
Map Generation (If I decide to make the map out of entities)
interpolation
entity message handling
Each of these modules will implement a common interface with methods to register, and remove entity IDs, and an update method to carry out the task.
*as I implement each of these Module classes I will post pastebin links
Entities will simply hold data, and will have not other methods except the appropriate getters and setters. I still have yet to determine if I want to make a component system for the entities, it depends on how clever I can be with my variables (for instance a health variable can be used not only to show the health of a ship, but also to represent the amount of minerals in an asteroid.
Here is a list of the entities I currently know I want / need:
-solar bodies-
Star
Planet / Moon (implemented the same way)
Asteroid
solar storm
black hole
-player made ‘buildings’-
solar collector
mining station
space yard
storage center
relay station
defense turrets (various degrees of bad-assery)
space station
-player made units-
command ship (slow moving, powerful, improves ship’s AI in range)
carrier (caries smaller ships across long distances)
-space yard made ships-
support ship (used at storage center, and relay stations to transport resources)
scout ship (fast moving, week)
repair fleet (a small fleet of ships that automatically repairs structures and ships within range of space yard)
mining fleet (gathers minerals from asteroids in range of mining station)
*as I implement all of these entities I will post pastebin links
For multiplayer in the old implementation I simply send out snapshots from the server to all the clients, and interpolated from one snapshot to the next. The snapshot consisted of a list of all the entities the server had, this was compared to the local entities and did one of three things for each entity; 1) if the entity in the snap matched a local entity: update entity data, 2) if the entity in the snap doesn’t exist locally: create new entity with data, 3) if local entity doesn’t exist in snap: destroy local entity. This worked very well, thanks to Kryonet! I plan to do the same thing for the new implementation, but I think I am going to have a dataStub class that all entities will have, this will contain just data (variables) no methods of any kind, and entities will have a queue of these to interpolate with. The snapshot will now only contain data stubs, and not entire entities. Which means I need another Module to process interpolation. (I have updated the modules section of this post) I have also added modules for processing entity messages; these will be commands issued from the player to be sent to the server. i.e: the player tells a ship entity to move to a given coordinate. This will generate a move-to-coord command that will be stored in the entities message queue until the message module sends it to the server. The server will then process the corresponding entity accordingly. The next snapshot will reflect the changes the command caused. (if that makes sense)
