game engine design

Due to the vagueness of your post I doubt you would get an answer more than: Initialise game, perform game loop, close game.

Any more details?

Sorry. What I meant was: i need help organizing classes. I want to map my base classes for a game engine.

I can think of some classes I need, but I may forget some, and may just go about the wrong way about them.

e.g. (for the actor part of the engine)

Actor --+-- Character --+-- Player --+-- UserControlledPlayer
        |               |            +-- ComputerControlledPlayer
        |               |            +-- NetPlayer
        |               +-- NPC
        +-- Object
  

Oh, and btw, I want to make the engine as modular (and OOP) as possible, so that future changes be done easily.

[edited by - Ionut Costica on January 8, 2003 3:25:18 PM]

No matter how much you plan it, and/or how OOPish you make your engine, you will still have to add/remove/modify a lot of things, while working at it.
Besides, your question is way too ambigous, no one here can give you a good answer.

Height Map Editor | Eternal lands

quote:

---

base classes

---

My Java lecturer would have a fit at this! lol

You have 5 years of C experience, but I don''t think you have enough experience of OO design and development. You should be making an object diagram first, not a class diagram. A single class does not necessarily relate to a single object.

Work out the "objects", and how they interact. Once you''re satisfied with that, then move onto the class diagram.

You also need to understand the domain you''re working in. For example, what objects will you have for handling keyboard and mouse input? What about window handling and text output? What will you use to keep track of time in the engine? Until you know what you need, you can''t (I mean shouldn''t!) start designing. Of course you can dive right in and prototype any number of ideas, but as long as you throw the prototypes away and start from scratch with what you''ve learned, you should slowly produce a solid design.

I know you can ignore everything I''ve said, but I''m just trying to pass on the useful knowledge I gained from my Java course, which also included a sprinkling of OO.


http://www.stodge.net - the powerhouse in personal commentary

No offence stodge - but you are back to front

A class diagram shows what classes you have - an object is an instance of a class......

http://www.martinb.com/software/ooad/uml/

I suspect your Java lecturer may fail you

Ionut - I would suggest you do a search on google for other 3D engines - many of which are open source or well documented. This will give you a good idea of what others have concluded.

Personally I have some base classes (GraphicsCore, BaseMesh, Camera, Light, Position, etc) and a whole host of derived classes for various ''tasks'' - but then I''ll probably find out as it progresses that it isn''t great either. Try to seperate the classes to be used for the ''engine'' from those to be used for the scenegraph. Best I can advise I''m afraid.... good luck.

Jerimiah: I''m afraid not. I quote you from Chapter 1, Introduction of "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma et al:

quote:

---

Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. ***You must find pertinent objects, factor them into classes at the right granularity, define class interfaces and inheritance hierarchies, and establish key relationships between them***.

---

Emphasis and mistakes are mine. So there''s the reason that I''m right, I passed my Java course and my lecturer is also right.


http://www.stodge.net - the powerhouse in personal commentary

Hello, when people asks this question I always reply the same:
Have a look at the JTGame engine, the URL is www.jtgame.com. If you go to the documentation and overview section, you'll find some nice charts of dependencies and classes.
Another good source for 'inspiration' is the Ogre engine...I forgot the URL, but you can download the full source code (try a google search). Its very good.

Some time ago I posted a very basic overview of the engine of a game I made...its simple but I will give you the link anyway:
http://www.robals.com/odyssey/notes/

Regards, Rob.


[edited by - _robals_ on January 8, 2003 4:44:50 PM]

/sigh - students

Objects are instances of classes - before you can create an Object diagram you must have a Class diagram (Object Diagrams include references to the class they are instances of.. i.e MyDog : Dog is an object called MyDog and is a Dog class object).

You may be talking about knowing what data you have and what problem you need to solve before you can get to a Class diagram - this isn''t an Object diagram - it can be called many things - but not an Object diagram (how could you possibly know what objects you will instantiate before knowing what classes you have?). Prior to a class diagram you have Use Case diagrams, Sequence Diagrams, Activity Diagrams - but not Object diagrams....

A+ for effort - F- for application

quote:

---

Original post by Jerimiah
/sigh - students

Objects are instances of classes - before you can create an Object diagram you must have a Class diagram (Object Diagrams include references to the class they are instances of.. i.e MyDog : Dog is an object called MyDog and is a Dog class object).

You may be talking about knowing what data you have and what problem you need to solve before you can get to a Class diagram - this isn''t an Object diagram - it can be called many things - but not an Object diagram (how could you possibly know what objects you will instantiate before knowing what classes you have?). Prior to a class diagram you have Use Case diagrams, Sequence Diagrams, Activity Diagrams - but not Object diagrams....

A+ for effort - F- for application

---

Oh I think I see the problem here. When I say Object, I don''t mean objects within code that are instantiated. I mean high level, abstract design objects.

For example, I have an abstracted object called InputEngine. It encapsulates objects such as InputManager, InputMap, InputMapping, MouseEvent and KeyboardEvent which all interact.

I then have classes hbInputManager, hbInputMap etc, which I instantiate in my program.

So it''s Abstracted Object Diagram --> Class diagram --> Instantiated objects.....

Stodge - yeah - I guessed that is what you meant - but it is critical not to use the wrong terminology....


Both Class and Object diagrams are structural models (along with Component and Deployment) - which is what Ionut is looking to produce.

You may be correct in your assumption that he hasn't yet done his Behavioural diagrams (Use Case / Sequence / Collaboration / StateChart / Activity), but these are a little excessive for a graphics engine (which is an incredibly simple model in OO terms) and going straight to a first draft Class diagram is perfectly reasonable. Class diagrams evolve like everything else in programming, usually by the application of Use Case scenarios - the key here is that doing one in the first place gives you a much greater chance of getting it right early on.

>>For example, I have an abstracted object called InputEngine. It encapsulates objects such as InputManager, InputMap, InputMapping, MouseEvent and KeyboardEvent which all interact.<<

Ermmm..... not sure how that works for me - you either have them all inherited from a single Class (Input maybe) or they are not related in OO terms - they are only related by name, nothing more. If they interact then a Collaboration diagram shows that. I see no need to abstractly link these objects other than maybe putting them in the same chapter of your project plan to allow us humans to find them easily. You appear to be talking about a Behavioural diagram.


UML Specification 1.4
http://cgi.omg.org/docs/formal/01-09-74.pdf

Class Diagram
A class diagram is a graph of Classifier elements connected by their various static relationships. Note that a “class” diagram may also contain interfaces, packages, relationships, and even instances, such as objects and links. Perhaps a better name would be “static structural diagram” but “class diagram” is shorter and well established.

Object Diagram
An object diagram is a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The use of object diagrams is fairly limited, mainly to show examples of data structures.
Tools need not support a separate format for object diagrams. Class diagrams can contain objects, so a class diagram with objects and no classes is an “object diagram.” The phrase is useful, however, to characterize a particular usage achievable in various ways.


[edited by - Jerimiah on January 8, 2003 5:19:50 PM]

I wasn''t implying that he should produce the Behavioural diagrams that you listed. Just that he should sit down and think a little before he started coding. I know from experience, I produce a better design (not that I''m an expert) when I do this.

>>You should be making an object diagram first, not a class diagram. A single class does not necessarily relate to a single object.<<

This is where the problem arises - you gave advice (and implied that Ionut didn''t know what he was doing) that was plain wrong (even if it was just the wrong terminology)

>>Work out the "objects", and how they interact. Once you''re satisfied with that, then move onto the class diagram.<<

This part I agree with 100% - but then that was what Ionut was asking for advice on - what the "objects" in a 3D engine should be.

>>I know from experience, I produce a better design (not that I''m an expert) when I do this. <<

Good to know you have started on the right foot - and in time (which is where most experience comes from) you''ll do well, just be careful when offering advice on bulletin boards

Just for your own interest - the following is a much better explanation of UML than OMG gives:
http://www.dotnetcoders.com/web/learning/uml/default.aspx

Ionut - the following page/engine also has some documentation that may inspire you:
http://www.ploksoftware.org/docs/en/

Jerimiah: To call stodge''s use of the word "object" flawed is erroneous. Many texts and instructors use the term exactly as stodge has. I, for one, would discourage anyone from using the term object to imply an instance of a class. This is vague and hinders communication. The term instance should be applied when referencing an instance. The strongest (and most common) association of the word object is with Object-Oriented. In this instance, it references a world object and not an instance of a class.

Also, never discourage someone from posting their interpretation on a subject. We learn more by teaching and we gain clarity by the carefull expression and sharing of ideas.

quote:

---

Original post by Raduprv
No matter how much you plan it, and/or how OOPish you make your engine, you will still have to add/remove/modify a lot of things, while working at it.
Besides, your question is way too ambigous, no one here can give you a good answer.

Height Map Editor | Eternal lands

---

I know it's bad practise, but I'm writing my game will very little planning and it's coming together nicely. Be aware that it is rigorously tested and riddled with error handles should anything go wrong.



[edited by - Mathematix on January 8, 2003 5:45:42 PM]

EEROOKIE:
>>Jerimiah: To call stodge''s use of the word "object" flawed is erroneous<<
Stodge:
>>You should be making an object diagram first, not a class diagram.<<

Actually it was this part that was badly flawed - his use of ''object'' in quotes I also used. An ''object diagram'' is a standard UML diagram - and not what Stoodge was talking about as he later clarified.

But... the use of Object in Object Oriented refers not to world objects, but to the fact that OO languages manipulate Objects (which are instantiated from Classes)....

From the OO FAQ:
"Object-orientation is the use of objects and classes in analysis, design, and programming. "

Some references use ''object'' in a general way to describe a ''thing'' or even a ''concept'' - but since UML was pretty much accepted as the standard I rarely hear anyone use it that way. For avoidance of confusion it isn''t a good idea to use ''object'' in a general way unless you also clarify what you mean by an ''object'' - or this kind of confusion arises.

>>The term instance should be applied when referencing an instance.<<

From the OO FAQ:
"1.16) Is A Class An Object?
In C++ no, because C++ classes are not instances of an accessible class (a Meta-Class) and because C++ classes are not accessible to programs. Classes are objects in 3 Level Systems and above because classes are instances of meta-classes. But classes play a dual role, because objects can only be declared to be instances of a class (and class objects instances of a meta-class). In 1 Level (single-hierarchy) systems, all classes are objects.

1.17) Is An Object A Class?
In a Level 3 System and above yes, but only instances of a Meta-Class are Classes. Instances of a Class (ordinary objects) are not classes (excluding hybrid systems). However, all objects may be classes in single hierarchy systems, since any object may act as a class (provide object instantiation or act as a shared parent)."


Now what that boils down to is the terms Object and Class are pretty much interchangeable in Level 3 systems and above. Which is why Object diagrams are abstract representations of the state of a system - they do not (in general) show all Instances - they show all Objects.


Correct terminology is important. Even more important is defining your terminology when you step outside what is generally accepted.

>>Many texts and instructors use the term exactly as stodge has.<<

Texts and instructors tend to define their terminology in this case, and if they don''t then they shouldn''t be teaching

>>I, for one, would discourage anyone from using the term object to imply an instance of a class.<<

So would I - it isn''t an instance - it is an Object (it is also not an ''abstract thing'')

One quote that I always try and go back too is
''Code to an interface not to an implementation''

One quote that I always try and go back to is
''Code to an interface not to an implementation''

thanks for all the info and links. And I''ll do some more research, after which I''ll finish the base-diagrams, and hopefully no MAJOR code rewrites will be necessary. ttyl, because I''m sure to have at least some problems in implementing the engine.