Object-Oriented Game Design

Object-Oriented Game Design
Author: Britt L. Hannah
Description: The article deals with designing games through an object-oriented approach and discusses some of the implementations ideas.

You included image 2-B instead of 5

Great so far!

interesting read

Very interesting article. I am trying to implement a basic engine based on the article but am unclear on somethings.

If anyone has designed a basic engine with the concept, please send me the source. I am a little stumped on a few concepts. Some of them seem to contradict themselves.

I am dealing the the object form concept. This is what i grasp so far.

The Entity class has a Object Form class, States Class, Action objects (Possible Action, Current Action) and other entities in it.

IS the entity class a collection or does it have a collection inside of it? Can i make a generic form class and then just load the different meshes into it to represent the object? Or do i make a base form class and derive it?

I think if i could see someones implementation the concepts it would clear alot of my questions up.

Thanks for any assistance you can give me.

Normally, in the development process, one first makes deep thoughts on the matter then write plans, schemes, documents or whatever and after that - the coding phase begins.

The whole process takes quite much time and it's not a job for 2 days. Yeah, i agree the paper work is annoying but after some time you get used to it.

The article, that the guy wrote is also completely by it's means. It describes only rough ideas, which you should extend and implement on your own . Also, the question 'if something SHOULD' makes no sence in programming 'cause everything depends on you as a developer. There is no 'correct' solution. There is a solution that works. So just try it the way you think it's right and it will work, i promise!

i disagree... planning everything beforehand is something you do when you are familiar with the matter. the first steps you make are usually plain hacking. don't get me wrong i'm totally pro pre-code design but it requires a lot of knowledge about the APIs you are working with and the problems encountered during the development process and i doubt that anyone can stear clear of them without having run into them at least once

With my current project, and others I always make a quick 4/5 file project to try to create a specific part/subsystem like a .so game object loader, or lod grass renderer ect.. Having them isolated makes bug hunting much cleaner, and you really learn how to do it better next time.

So, code plan code

What i am doing to better grasp the concepts is reading each section and diagramming out how i would implement it. That is kind of my approach to understanding things. I thought maybe if i saw someone elses implementation, it would help me design my own.

But I'll pick a subsystem (like action / state releationship) and work on that. We'll see how it goes Thanks for your advice all!

It seems that Ed Mack has found the true way. However it greatly depends on what you want to do. For example for my last phone-game (a cave-ship cloning) i only needed to figure out how to effectively compress levels so they're not 50 MBs in size ). It was all straightforward then. Well it's not yet finished but the optimization phase doesn't count! For simple thing like that, no planing is needed i guess...

Greetings all,
I'v got a question, concerning the article.

It tells that State class represents any data that takes part in interaction of objects. But how then different data types can be coded? What if another Entity or Action knows nothing about the type of the data, which the State class tries to represent? It seems I can't understand the idea without some sample code.

Take for example speed of an entity (it is of a "vector3D" type and has 3 components: x, y, z. ) and name of an entity ("string", an array of characters). How so distinct types can be represented by a common interface (through abstract class)?

Could someone show me an example of the State class implementation?
Thanks in Advance.

I've been thinking today about this for my own engine (settings, and game object properties), and want to hear other's input too

For representing them, I was thinking of using an STL map<string, string>, and then you pass a reference to the map, so other bits of code can just look for certain properties. Also, instead of using a string for all data types, I'm trying the following (but really want a better solution)

Some Baseclass
->Templated value classes that derive from that

So that all values are the baseclass, and through polymorphism can work as they should. My problem is having a nice proper interface to work with this class, It just hasn't turned out nicely for me. Help!

Originally Posted by Ed Mack

Some Baseclass
->Templated value classes that derive from that

So that all values are the baseclass, and through polymorphism can work as they should.

[snapback]9431[/snapback]

But reading, assignment and constraint checking would be crude and involve la lot of dynamic type cast.

That's why I'm not so happy with it! BTW, you only need to dynamically cast once when setting.

I just found this article tonight and I must say that I am impressed and motivated by it. I have started a few times to create a game and put it off, but I did quickly learn there is a difference between a game and an engine. I was headed towards creating (or trying) to create a game engine and this is even more of a reason. I am hoping that my lack of notions and preconceptions of how game engine works will help me in this endeavor. I would like any feedback to see if anyone else is having any luck with this. Thanks.

I am trying to do a class design based on this article in UML. No point start coding until we understand it fully. I use Embarcadero's Describe to make UML diagrams. If you are willing to get into UML ( wich every programmer should do ) ask me to post what i already have.

darkelf2k3 - sounds like a good idea, I would like to see what you already have.

You will never understand it fully before you start coding.

Re the original article, it seems.. out of this world

First, I would like to apologize for dumping this article and then disappearing. When I first wrote this article my real life status was a little shaky...then got worse.

Now things are a little better.

At any rate. I have implemented the design which I described in the article maintaining about 80 to 85 percent of the original intent. I intend to distribute an exprimental application based on the system. The application has been implemented using c# and the .net framework...so, sorry for those of you that haven't installed the .net framework on their windowsXP systems.


As to the source code...
You can have that too, BUT...don't forget where you got it, AND...remember its exprimental. My article and the system IS out of this world. I intend to reign the design system back into this world. The next version I write will attempt to approach 90% - 95% of the original intent of the article.

email me at immotus@yahoo.com for info or if you have any questions

Thanks
immotus

I know this is an old thread but this thread is about a great article that is timeless. :wink: I just had a beginner question which I'm sure plenty of you know the answer to: in the article, the author refers to core services to the game application. I think I understand all of them except persistence systems. What is that? Maybe I'm just ignorant of the jargon. If in addition to a definition you could give me a simple example of one, I would be grateful.

Persistence is just another word for File System or Data Base System. A game might persist (store) its states in a save game file format or perhaps it may need a data base. This just depends on the type of game it is.

I read this article a while ago, was quite interested and decided to implement this solution. So far I've only been able to do little, because of time constraints (real life)

The only thing i've got trouble to understand is State objects.
I just can't make the transition between what's written in the article and my code.
How is it possible to make states without primitive data ?
For me it was the place to put this kind of data in.

For example, if I want FAST behavior, (state) I will put somewhere in my code a little float that will multiply the object's displacement value (for exmple by 2), and put a conditionnal expression in the "move" action class. if state is FAST then multiply by 2 the current displacement value.

Could someone give me a clue here ?

Design and prototyping go hand in hand. "Plan to throw the first prototype away", or something to that effect.

You'll never know if something works until you get your hands dirty and code. Prototype some ideas, and when things don't work, pick a new direction. If things work, take what you have and either re-factor it from what you learned, or extend it. Live and learn!

-- I'm tired, therefore I ramble --

Yes, I'm thinking the same way, because too much thinking = shit, and I better like coding. But I do believe that I must have a general idea to keep me from drifting apart and having to totally rewrite my code.

I wrote a fucntionnal prototype of a State class and some other classes inherirted from the State class.

And I don't like it, each class is just a bunch of primitives, and it's really hard to have some cohesion between these classes, because a game object can have so many different properties. I must create a new State class every time I create a new game object (Entity), and it does not achieve my goal : reusability.

I don't need to stick with the ideas of this article, but so far I prototyped Action , form and entity objects , and I really like the way they work. I just couldn't come with an idea to implement states(and I don't fully understand the article on this point)


So if anyone got an idea for a better State class than just a primitives and get/set functions to access those primitives, It would be cool.

I think of states as a named data container for the action objects.
Something like a named void* pData;
If the action finds a state object with the correct name, it will now what the data behind the void* will contain and it will know how to use it.
The final goal is to create a system where you only have to define action objects, the rest is the same for every application.

I think of states as a named data container for the action objects.

I agree

Something like a named void* pData;

If I extrapolate, I would see a hashtable, containing void pointers..
Tha action objects queries the table and obtain the pointer containing the data it needs.
But this would involves lots of casting to get the data from a void pointer,and often that data is a simple int or float.
That's what I think.

ANd what about those services, (dislpay input, persistence, communication), it says they are implemented using interfaces ?

What does interface means in terms of coding? From what I got so far, these services are just global classes in my application.