Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (522)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (590)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  A game is just a real-time database with a pretty graphical front end  (Read 5383 times)
0 Members and 1 Guest are viewing this topic.
Offline zngga
« Posted 2012-08-19 17:14:20 »

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

My code never has bugs... it just develops unexpected features!
Offline Tjstretchalot

Junior Devvie


Medals: 2
Projects: 1



« Reply #1 - Posted 2012-08-19 17:47:02 »

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*
Offline Roquen
« Reply #2 - Posted 2012-08-19 19:17:19 »

That's a good factual quote, although I'd change database to the plural.  My response would have been:

"Let me tell you how to extreme ski.  Find a place that makes a triple black diamond look like a bunny slope.  Point your skis downhill.  Go really fast and if something gets in your way.  Turn."
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zngga
« Reply #3 - Posted 2012-08-20 05:26:33 »

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)

My code never has bugs... it just develops unexpected features!
Offline SwampChicken
« Reply #4 - Posted 2012-08-20 07:32:45 »

Watching with interest...
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #5 - Posted 2012-08-20 07:44:13 »

it hit a cord with me

Chord (as in music).

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2012-08-20 08:43:31 »

He may have been saying something tongue-in-cheek of course, which sounds a bit more likely. Like saying a computer is a fancy abacus.

Cas Smiley

Offline Grunnt

JGO Kernel


Medals: 94
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #7 - Posted 2012-08-20 08:50:21 »

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 Grin

Offline gimbal

JGO Knight


Medals: 25



« Reply #8 - Posted 2012-08-20 08:52:05 »


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:

Deus Ex - Warren Spector's baby (great game)
Deus Ex Invisible War - pretty front end (well at the time anyway - oh my god I felt robbed)

Offline Damocles
« Reply #9 - Posted 2012-08-20 09:39:17 »

I would respond:

A real-time-database is just a game with an ugly Frontend and no win conditions.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zngga
« Reply #10 - Posted 2012-08-20 12:34:23 »

it hit a cord with me

Chord (as in music).

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! Wink

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

My code never has bugs... it just develops unexpected features!
Offline loom_weaver

JGO Coder


Medals: 17



« Reply #11 - Posted 2012-08-20 14:53:33 »

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.

http://en.wikipedia.org/wiki/Second-system_effect

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.
Offline keldon85

Senior Devvie


Medals: 1



« Reply #12 - Posted 2012-08-20 22:22:22 »

Good question, but then let me ask this ... is life just a real-time database with a pretty distorted and sometimes blurry graphical front end  Cool ...






... the plot thickens :p

Offline ReBirth
« Reply #13 - Posted 2012-08-21 03:25:00 »

Game? a state machine that manipulate its state/world because of user(s)' inputs.

Note:
- all games need input, or it'll be called animation.
- i dont mention graphical, text based also counted.
- so what's the difference to common app? no, it just funnier and colorful sometimes Cool

Online Jimmt
« League of Dukes »

JGO Kernel


Medals: 138
Projects: 4
Exp: 3 years



« Reply #14 - Posted 2012-08-21 04:27:46 »

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.

http://en.wikipedia.org/wiki/Second-system_effect

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).
Offline Roquen
« Reply #15 - Posted 2012-08-21 05:42:14 »

Note: games don't require win conditions.
Offline zngga
« Reply #16 - Posted 2012-08-22 17:53:23 »


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:

Deus Ex - Warren Spector's baby (great game)
Deus Ex Invisible War - pretty front end (well at the time anyway - oh my god I felt robbed)



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.

BTW updated the OP with some thoughts on multiplayer

My code never has bugs... it just develops unexpected features!
Offline DrHalfway
« Reply #17 - Posted 2012-09-07 13:00:23 »

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  Roll Eyes

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  Grin

Offline Sickan

Senior Devvie


Medals: 9



« Reply #18 - Posted 2012-09-08 18:44:07 »

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  Roll Eyes

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  Grin
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 Smiley
Offline ctomni231

JGO Wizard


Medals: 99
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #19 - Posted 2012-09-08 19:24:06 »

"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  Tongue)

Offline DrHalfway
« Reply #20 - Posted 2012-09-09 00:52:51 »

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  Roll Eyes

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  Grin
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 Smiley

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.

Offline alesky

Junior Devvie


Medals: 3
Exp: 15 years


mmm....


« Reply #21 - Posted 2012-09-28 18:36:49 »

I would respond:

A real-time-database is just a game with an ugly Frontend and no win conditions.

I do Business application and software architecture  all with J2EE since 10 years...
and unfortunally most of the time you are right

Offline Gornova

Senior Devvie


Medals: 1
Projects: 3



« Reply #22 - Posted 2012-10-24 14:29:16 »

To me seems a good experiment, you are near concept of Entity/Component system (see here), like Artemis

my 2 cents

Blog | Last game Drone Defense 0.2 | In progress Drone Defense
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

trollwarrior1 (31 views)
2014-11-22 12:13:56

xFryIx (72 views)
2014-11-13 12:34:49

digdugdiggy (51 views)
2014-11-12 21:11:50

digdugdiggy (45 views)
2014-11-12 21:10:15

digdugdiggy (39 views)
2014-11-12 21:09:33

kovacsa (63 views)
2014-11-07 19:57:14

TehJavaDev (68 views)
2014-11-03 22:04:50

BurntPizza (66 views)
2014-11-03 18:54:52

moogie (81 views)
2014-11-03 06:22:04

CopyableCougar4 (81 views)
2014-11-01 23:36:41
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!