"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:

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.

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)

How do you plan on doing the AI Networking? One player as the definitive 'host' and have it connect to itself, like Minecraft did? (I'm sure there are others that did this, but that was the one that came to mind) Or some other way? I'm curious because I'm thinking of how to network a basic game at the moment, because my approach for previous games wasn't scaling at all. Also, you should consider using GitHub or something similiar if you plan on releasing the source, it will make it much simpler in the long run. *Is a huge hypocrite*

How do you plan on doing the AI Networking? One player as the definitive 'host' and have it connect to itself, like Minecraft did? (I'm sure there are others that did this, but that was the one that came to mind) Or some other way? I'm curious because I'm thinking of how to network a basic game at the moment, because my approach for previous games wasn't scaling at all. Also, you should consider using GitHub or something similiar if you plan on releasing the source, it will make it much simpler in the long run. *Is a huge hypocrite*

I actually prefer bitbucket over github.

As far as my multiplayer approach, in my first implementation I used Kryonet for all the network communication. I set of a host and peer style server client implementation, where one person is the host, and everyone else (including the host) connects to the server on the host machine. I plan to do it the same way in this implementation. I think it may be easier then before though, because my entity classes will be much simpler (since all logic and rendering is off loaded to module classes now)

Also, your professor is an idiot. Lets find the definition of database from wikipedia:

Quote

A database is an organized collection of data, today typically in digital form. The data are typically organized to model relevant aspects of reality, in a way that supports processes requiring this information.

The term 'database' is so generic that anything to do with computers could be described as a database with a fancy front end. As Roquen points out, over simplifications help no-one and convey very little information.

As for your design, it sounds very much like 'data oriented design'. You should probably google it as there's lots of info on this kind of organisation that would probably help you.

Interesting experiment. Though, as others have suggested here, I don't really think there's a fundamental difference between what you are doing and a more traditional approach. Only you seem to plan on using String ID's to set relations between objects, rather than object pointers. This does seem to be less efficient to me (as in: a Module that has to process 100 planets, for example, needs to look up these 100 planets using the HashMap getter. While this is reasonably fast, it still is a lot slower than just referencing the object directly). But maybe I'm overlooking something, so I'm interested to see what happens

The term 'database' is so generic that anything to do with computers could be described as a database with a fancy front end. As Roquen points out, over simplifications help no-one and convey very little information.

In fact it sucks the soul out of the whole game development process, which can only lead to a boring soulless game IMO.

A good game is not a pretty front end - its someone's baby that was created with love and care, with the intention to provide entertainment as the exchange for currency. Best example of that:

Also, your professor is an idiot. Lets find the definition of database from wikipedia:

Quote

A database is an organized collection of data, today typically in digital form. The data are typically organized to model relevant aspects of reality, in a way that supports processes requiring this information.

The term 'database' is so generic that anything to do with computers could be described as a database with a fancy front end. As Roquen points out, over simplifications help no-one and convey very little information.

As for your design, it sounds very much like 'data oriented design'. You should probably google it as there's lots of info on this kind of organisation that would probably help you.

thank you so much for the spelling correction, exactly what I was thinking of when I mentioned feedback!

I did look up data oriented design... I'll get back to you on what I thought.

I predict (based on my own real-life experience) that your implementation to redo your game is going to turn into a code-base monstrosity especially considering that the term database has very specific connotations. I disagree with your professor's viewpoint.

I predict (based on my own real-life experience) that your implementation to redo your game is going to turn into a code-base monstrosity especially considering that the term database has very specific connotations. I disagree with your professor's viewpoint.

However, don't let that stop you. It'll be a good learning experience.

Ultimately what works best is Cas' approach: implement something as quickly and simply as possible. Then refactor as necessary.

huh...rotmg is kinda like that...when I entered the game there was 11 tiers of items and 5 dungeons

when I left there was trading, 12 tiers and numerous other items, 9 dungeons, entirely new game stage, etc.There is a point where development should stop for the sake of the game(at least in some games).

The term 'database' is so generic that anything to do with computers could be described as a database with a fancy front end. As Roquen points out, over simplifications help no-one and convey very little information.

In fact it sucks the soul out of the whole game development process, which can only lead to a boring soulless game IMO.

A good game is not a pretty front end - its someone's baby that was created with love and care, with the intention to provide entertainment as the exchange for currency. Best example of that:

You are seeing that explanation from the wrong end. A game can, and is, made with lots of TLC and becomes the developers baby. If you look at the finished product though you can still conclude that, based on what the program is doing with the data it has, it can be described as a real time database. All I am doing is starting a project with that in mind, and seeing if anything useful comes from this kind of thinking.

I think of a Game (or a GameEngine that its built on) as an exceedingly large and complex real time state-driven data processor. Well, that was quite a mouthful

I visualize the Game as a very busy capital city, where there is only traffic and loads of intersections and you as the Programmer is the Architect. You do not know what kind of traffic will be created (coming from the player), your job is to write a system that regulates the internals of the city in such a way that traffic can move at an overall optimum speed and efficiency. If you are a GameEngine Programmer like myself, your job is alot more difficult, since you will be required to build the city from scratch!

I think of a Game (or a GameEngine that its built on) as an exceedingly large and complex real time state-driven data processor. Well, that was quite a mouthful

I visualize the Game as a very busy capital city, where there is only traffic and loads of intersections and you as the Programmer is the Architect. You do not know what kind of traffic will be created (coming from the player), your job is to write a system that regulates the internals of the city in such a way that traffic can move at an overall optimum speed and efficiency. If you are a GameEngine Programmer like myself, your job is alot more difficult, since you will be required to build the city from scratch!

Just my two cents

So, you never actually make games, just engines, you never actually get to know what developers want or need in an engine, and you build your engine(s) based on guesses. Good one.

"A game is just a real-time database with a pretty graphical frontend."

I hate to say this, but I disagree with this somewhat. A database usually implies that all data is used and stored. Games don't actually use and store "all" data into itself. There are cases in games in where data is bypassed, or one object can be used for many different purposes (like "temp" objects within a game.) Even though you can design a game exactly like you would a database, it just isn't practical and it is very limiting in design.

What I agree on...

I do agree that most objects in a game are designed in a database like fashion. Images and animation are linked to an object directly. You store enemy objects in a linear way so you can process many on the same screen without sacrificing memory. These objects are usually set once per level, and are used for the duration of the entire session.

What I disagree with...

However, when it comes to the interactions between objects, things can get a little hazy. Databases usually ensure there is a one-to-one ratio between information stored and the data stored within it. For example, if you have a telephone database, it basically guarantees that you will have a slot for "first name, last name, and telephone number."

In games, that is not entirely the case. Even if you have an enemy object, there is no guarantee that each enemy is going to share the exact functionality. Sometimes, you sacrifice linearity for making the game run faster. Example: Explosions with particle effects. If a whole bunch of enemies explode at once, you can choose only a certain number of those enemies to release particles to keep the game from lagging.

I don't think database is the right word to describe it. Games are not 100% linear in design, especially if you want games to run quickly. Databases usually mean that everything can be stored within an array without much trouble. However, with games, if you were to list all the functionality of it in a linear fashion, there will be a lot of overhead (a.k.a. items that are not being used.)

So, even though you could build a game in this fashion and it will work. The teachers comment is just a exemplification of what game programming really is. The truth is, in order for you to make good games, you have to make sure you are using data in the most efficient way possible. Databases are by-no-means the most efficient way to design games. (Unless it was a phone directory game or something )

I think of a Game (or a GameEngine that its built on) as an exceedingly large and complex real time state-driven data processor. Well, that was quite a mouthful

I visualize the Game as a very busy capital city, where there is only traffic and loads of intersections and you as the Programmer is the Architect. You do not know what kind of traffic will be created (coming from the player), your job is to write a system that regulates the internals of the city in such a way that traffic can move at an overall optimum speed and efficiency. If you are a GameEngine Programmer like myself, your job is alot more difficult, since you will be required to build the city from scratch!

Just my two cents

So, you never actually make games, just engines, you never actually get to know what developers want or need in an engine, and you build your engine(s) based on guesses. Good one.

Cheers

No I get to know the needs of a Game Developer just fine, it all comes to how you architect your software

Let me tell you a story of the "evolution" of our Particle System Manager

Version 1 was very simple, it could emit particles at a direction with some color and alpha blending - this worked for a while untill the Games Programmer wanted to make nice looking weather effects such as snow and rain.

Version 2 was an improvement, it provided "states" as you call them to control a particle effect, for example, a SPREAD_XY state and some parameters would spread the particle effect across the screen in its dimensions. This worked great for a while untill i began getting requests for all sorts of states which needed to be implemented engine side onto the Particle Manager itself.

Version 3 was a complete cleanup, and incorporated a design of a state-driven particle system that could make almost any effect possible. It incorporated a programmable interface that allowed the Game Programmer to "Script" particle effects much like he would script game logic, without exposing any Engine source code or functionality. The old states from version 2 were re-programmed into pre-written states that could be used if needed.

Version 4 was a natural improvement over version 3, it added the capability to store and retrieve particle-specific data in a state, this gave the power for example, for the Game Programmer to add collidable particle effects, effects that could react to game world conditions such as wind, hurricane, or even effects that could react to user input. All this done via the new programmable interface and a state driven particle system.

Moral of the story? now i'm free to spend my time implementing other things, I return once in a while to do optimization as the engine side renderer gets better, however the Game Programmer got what he wanted, and I got what I wanted. Version 1 - 4 was about 4000 lines of code with end result being about 1300 lines. Besides the effort to write the manager from version 1-4, the effort it took me to add them into the engine was about 10 lines of code, and the engine is still compatible with versions 1-3 if needed.

So no, guesswork has nothing to do with Engine Programming. But I did not have to bulldoze an entire engine just to add a particle system to it.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org