• Advertisement

Archived

This topic is now archived and is closed to further replies.

An elegant object-oriented way to design a game engine

This topic is 5988 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

EDITED TO ADD: I want to thank everyone for your insightful advices, this discussion really helped me. I'm about to start coding my first complete engine very soon! ---- Oww my head hurts so much! I have almost 50 scribbles, notes and ideas on how to structure a 2d game engine. I have a big problem : I keep thinking and thinking up until I find a flaw somewhere in my notes and know I can make it better. I then usually start over or put the "project" on hold. That's why I can never really finish a big project even though I got ton's of IMHO good ideas. I've tried looking at some open source code, but sadly most of theses engines are written in C, although I understand what exactly is C compared to C++, I find it awfully ugly and inelegant. Remember that my goal is educational. My goal : - For 2d games - Clean design - Clean code (no quick hacks) - Best OOP - Good comments (easy) I have some questions for the gurus: Should the blitting functions be in the sprite class ? or outside ? I'm leaning toward inside because I guess it would make things easier... or not.., but what about blitting the rest of the stuff like the background, that would mean duplicate function. :/ don't want that. Arghh my head What about sprite animations ? Let's say I have CAnim which include an array of pointers to CSprite objects. Good ? Good practice would be to separate Graphics from Collision Detection. But the bounding box (which would be used in Collision Detection) is stored in the Graphics (Sprite) what the fuck? Well, (right now) just thinking about it, I guess it would be ok since you would have a function for collision detection against all the entities which contain a pointer to a sprite which contain the bounding box. Argh, I got some more questions but this post is already long enough and 90% of it doesnt make sense to any of you. If some of you want to see my most recent plan, I'll digitize it and post it here for all to see and laugh at my pathetic attempt =) Edited by - hpox on November 24, 2001 10:55:02 PM

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
I had this problem. The solution is easy: hack up an engine. Then do it again, but this time make it a little better. Do it a few more times. You need experience to make these kinds of choices. Every journey starts with a first step. It doesn''t matter if you trip and fall, just get up and get walking. Sure it won''t be pretty but your experiences will aid you on your next attempt. Just get something done. I like to have really pretty code, and I can''t stand C, but the simple truth is that you just have to start coding and make some mistakes. If things get too ugly start over. Don''t view it as a waste of time either.

Share this post


Link to post
Share on other sites

For what its worth this is exactly how I''m doing it. Its working for me (so far .

Code something (anything) first. Keep to good coding and OOP practice, but don''t worry too much about the elegance of the design for the first cut. You''ll invariably have to go back over it anyway.

One good tip I have picked up. Don''t spend too much time optimising as you go (bottom up optimisation). Get the structure right first.

Hope this helps,

Keef


------------------
Trouble is my business
------------------

Share this post


Link to post
Share on other sites
Thank you, both of you. This is encouraging, I will (try) follow your suggestions!

Share this post


Link to post
Share on other sites
As far as I''ve learned at school, the most OO-correct way is to keep all your blitting functions etc inside the class to where they belong. Always make sure the sprites do all the tasks they''re responsible for, not shove it off to some other part of the system. This goes for all classes etc. Always make them do their own stuff.
Sprites can then also house their own animation frames, and the animation function would also be inside the sprite class. Same as with the bounding box stuff, the sprite is responsible for it''s own collision detection.
If it''s OO design and programming you''re after, I suggest picking up a book on UML.

-----------------------------
Jappie
BabJap Productions

"There''s no such things as bugs; they''re just unintentional extra features"

Share this post


Link to post
Share on other sites
I was actually going to post a similar problem. When I was younger, I used to take the develop and refine approach to problems. But now I sit thinking and theorising to the nth degree instead of actually getting on with it.

When I see myself getting into that state I have to smack myself upside the head and tell myself to get on with it.

Not always the best approach but if it''s a ''just for fun'' project there''s no harm in wasting a little time redeveloping things.

Share this post


Link to post
Share on other sites
quote:
Original post by Jappie
As far as I''ve learned at school, the most OO-correct way is to keep all your blitting functions etc inside the class to where they belong. Always make sure the sprites do all the tasks they''re responsible for, not shove it off to some other part of the system. This goes for all classes etc. Always make them do their own stuff.
Sprites can then also house their own animation frames, and the animation function would also be inside the sprite class. Same as with the bounding box stuff, the sprite is responsible for it''s own collision detection.



That''s what I thought, at first. Not everything that you want to have collision detection will be a sprite. Say you have an invisible wall/block, or the edge of the screen.

quote:
If it''s OO design and programming you''re after, I suggest picking up a book on UML.



My C++ teacher had a huge book on the subject, I will check it out. Thanks for the suggestion

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Make collision detection a separate class, and have objects inherit from it. Commonly used methods can be implemented in CCollisionDetection, and overriden by those classes which have a special requirement.

Take a look at Game Design & Architecture. They walk through the design of a game engine, and I found it pretty helpful.

Share this post


Link to post
Share on other sites
I don't know much about OO, but I've done quite a bit of game engine coding, so take everything I say with a healthy does of skeptisism.

Your graphics routines will have plenty in them without being a part of the sprite class. You'll have to allocate memory, format it, load images from disk, do straightforward blits, do blits with transparency, do alpha blits, clip all the blits to another chunk of memory, and probablly various other things that didn't get mentioned.

Next, I'd probablly make a rectangle class. The obvious functionalities for rectangles are checking collision, and finding intersections. Both are useful for drawing routines, assuming you're doing everything yourself, but can be implemented in the classes that control the drawing logic.

From those two, it's about time to create a sprite and tile class. The needs of those will vary from game to game, but you're going to need drawing, clipping, and animation routines for those. If you want, you can put collision data here. And remember, any self contained entity has at least 2 possible collision areas, vunlerable areas, and attack areas. Both of these are probablly best kept separate from the rectangle for the graphics blit. edit: And just to let you know, as it's common for different types of creatures to have different collsision needs, it may be best to absract the collision data up one more level.

So, now you can draw. What next? Input! There are a lot of ways to structure this, depending on the API, and I'm feeling too lazy to go into it right now.

Anyway, I think the best way to go about coding it, is to separate everything into little chunks, put only what fits absolutely in there, and code and test one of those. Then do another logical piece. Build the parts, then put them together.

Anyway, good luck.
Hope this helped out a little

Edited by - ThoughtBubble on November 22, 2001 4:35:42 PM

Share this post


Link to post
Share on other sites
If you wanna learn this "software engineering" style. Do this:
1) List requirements you want(called customer requirements) like features such as shadows, or whatever, 2d/3d...you probably have done this in your own way so far.

2) Then go through those features you want and break them down into steps (or use cases if you wanna get technical)... you probably have done this in your own way so far.

3) Architecture: break up the problem in "Systems" and plan out how the data will interact.

4) Start coding, just practice like the others say, and have fun.

5) Once you got some features to your engine, you can add some of the major elements to your game and see how it starts working out...if something aint right, redesign.

As far as OOP/OOD... its good for some things, but sometimes i think its better to code stuff out into functions and later go "AH HAH!! This so-and-so stuff can be a class!"

Good luck.

Share this post


Link to post
Share on other sites

  • Advertisement