• Advertisement


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

Help w/ Game Architecture

This topic is 5996 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

Hi. I''m trying to create a 2d scrolling, overhead tile-based adventure RPG but I''m not sure of the best approach to use. I''m already familiar with C++ and intermediate level OO-techniques, DirectX, Win32 etc and I''m also aware of the basic structure of a game app (game loop, getting input, etc) so I don''t need advise on those things. My big problem is that I''m stuck deciding how to design the entire project using elegant software design techniques. My first few attempts at this project ended up with piles of messy, hard-to-maintain, unmodularized code. I need some advise as how to keep my code portable, modularized, extensible and at the same efficient. Thanks for any advise.

Share this post

Link to post
Share on other sites
Guest Anonymous Poster
Well there is no "correct" way to go about this. But here are some ideas that might help you on your way.

Decide what is an object.
- Position Data
- Image and sprite stuff.
- Etc.

Use polymorphism. Create an object base class, and derive classes for the different types of game objects you have.

Create an object manager class.
- Maintains list of active objects.
- Ticks each object.
- Responsible for adding and removing objects.
- Acts as a message link between the objects and anything outside the objects, like the graphics engine, or perhaps network stuff.

For rendering,
Your graphics engine draws the background, then cycles through list of objects owned by your object manager, and draws the objects.

Collisions etc.
I personally like messaging. Your graphics engine can detect collisions and send a collision message to your object manager. The object would then call the OnCollide() function of the two colliding objects. Maybe they subtract hitpoints, or do something else. When an object reaches 0 hitpoints, it might send a Destroy message to the object manager, so it takes it out of the active object list.

A pretty cool approach is create an AI Base class, and a map Base Class. Then derive classes specific to your game AI, and game map format. It''s good when you move on to game two, you can just over-ride your shortest path algorithm to handle the new map format, but your "Hunter" AI is still re-usable. Then you just have each object own and AI object that represents the object''s AI.

(For example, in the game of pacman, the a Ghost might own a HunterAI, that finds the shortest path to the prey and trys to move there. He might also own an Evade AI class that gets used when pacman has eaten a power pellet).

My advice, draw lots of pictures. And pick a path that works for you. I just listed some ideas. I''m not sure how clear they are but maybe it will atleast give you some starting points.

Games are actually the one type of program that don''t follow the software engineering approach of use cases. Typically to do a design the first step is to do use case diagrams. Well in games you may only have 3 use cases, (left, right, fire) which doesn''t even start to tell you how to design the software.

Good luck.

Share this post

Link to post
Share on other sites

  • Advertisement