quote:Original post by ace_lovegrove
If you read the post u would see that it was hardly vague, i gave brief concise description of how it worked, class names how they link etc...
Show me. I re-read this whole thread.
I Really Cant Think Of A Good OO Layout For An Engine
Show me. I re-read this whole thread.
Could you elaborate a bit more? Are there any specific parts of the engine you're stuck with? The scene graph or renderer for example? I'm facing similar problems myself at the moment, but I find with each rewrite, my engine becomes closer to being finished. It just takes perseverence.
edit:
Sorry, let me rephrase that. Are there any specific parts of the engine you aren't sure how to write in an OO way?
[edited by - MumbleFuzz on May 25, 2004 2:29:43 PM]
edit:
Sorry, let me rephrase that. Are there any specific parts of the engine you aren't sure how to write in an OO way?
[edited by - MumbleFuzz on May 25, 2004 2:29:43 PM]
Author
Im not entirely sure how different parts of the engine link together regarding classes and the instances, objects, methods like inheritance and polymorphism (i know how these work BTW). Methods for having it Finite-State like in operation. Im trying to obey the diagram that was presented in the Enginuity article and im having trouble trying to contrive a concept for how different parts work. I have already created a simple engine, just a renderer though, which is basically a kernel that once having initialised the main window calls a TaskManager class every frame. The Task Manager then controls the states the engine lies in, ie playing, paused etc. In order to use the engine you have to create an inherited class from the kernel. I am having problems with overriding methods within the other base classes.
PS thanc fort he kind help MumbleFuzz
regards
ace
PS thanc fort he kind help MumbleFuzz
regards
ace
Go and read some source code - there is plenty out there.
There are a lot of open source games. There are some commercial games which have since released their source into the public domain.
Note that these won't necessarily be model examples of how to do things.
I wrote a game in a weekend last year (for a compo); it wasn't very good but provides an example of how to do polymorphic OO with a manager (which is procedural).
http://www.vectrex.org.uk/aotmj/
None of these are necessarily very good, but you will see a way of doing things.
NB: To build this code on some versions of VC, you may need to change some compiler options from their defaults. Specifically, I use RTTI and assume correct for() scope.
Mark
[edited by - markr on May 25, 2004 4:01:05 PM]
There are a lot of open source games. There are some commercial games which have since released their source into the public domain.
Note that these won't necessarily be model examples of how to do things.
I wrote a game in a weekend last year (for a compo); it wasn't very good but provides an example of how to do polymorphic OO with a manager (which is procedural).
http://www.vectrex.org.uk/aotmj/
None of these are necessarily very good, but you will see a way of doing things.
NB: To build this code on some versions of VC, you may need to change some compiler options from their defaults. Specifically, I use RTTI and assume correct for() scope.
Mark
[edited by - markr on May 25, 2004 4:01:05 PM]
quote:Original post by Codexus
My advice is not to try to find the "perfect" OO layout. You need to get started. Identify the objects you think you''re going to use for example views, meshes, cameras and start with that. Think of how you would like to be able to use the engine. For example, it seems one would like to control the camera movement in the same way as the objects movement. So you could make a common base class for them. Keep things as simple as possible and avoid redundant code that way it will be easy to change things as you identify problems or ways to improve your design.
OO programming is really great if you like thinking in an abstract way.
What he said but don''t necessarily start with the OO way to do things. Once you write down some things you want your engine to be able to do, you''ll notice certain themes and you''ll be able to come up with a solution that will work for a number of features(templates are your friend and work marvelously for a procedural style). Maybe you should even start with solutions and see what can be solved by them.
I probably won''t be a great help to you, as I''m still experimenting with different methods myself. However, a few points to keep in mind...
1. I found most of my difficulties came from trying to keep the Windows related code away from the rest of the engine (parts such as the renderer). Once you''ve got the Windows and GL/DX initialization in place, the rest should fall into place quite nicely.
2. I think the Enginuity article treated the Video Task (including window initialization) and Renderer as one and the same. I found it much easier to keep the renderer separate, partly because of the reasons mentioned above.
3. While OO stuff is great, don''t underestimate the flexibility you can get with a simple procedural engine. I think Quake 3 was written in C alone, for example, and that''s powered some great games over the years.
You can create an engine without any OO parts. OO is simply a tool to make your coding easier; only use it if it''ll do this.
1. I found most of my difficulties came from trying to keep the Windows related code away from the rest of the engine (parts such as the renderer). Once you''ve got the Windows and GL/DX initialization in place, the rest should fall into place quite nicely.
2. I think the Enginuity article treated the Video Task (including window initialization) and Renderer as one and the same. I found it much easier to keep the renderer separate, partly because of the reasons mentioned above.
3. While OO stuff is great, don''t underestimate the flexibility you can get with a simple procedural engine. I think Quake 3 was written in C alone, for example, and that''s powered some great games over the years.
You can create an engine without any OO parts. OO is simply a tool to make your coding easier; only use it if it''ll do this.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
