Jump to content
  • Advertisement
Sign in to follow this  
kickenchicken57

Help with Planing and design

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

Im working on a small-medium sized game using directdraw and I have a couple of questions on the best way to go about the design I have a Graphics class that handles all loading of bitmaps to surfaces and creating surfaces and initializing graphics that I have made global. It is initialized in the game engine and used everywhere that I need to create or load surfaces such as my map engine and Sprite class. What I would like to know is where is the best place to create my sprites(Player, enemies, bullets, and static sprites like barrels or something) and where would be the best way to manage them. My original Idea was a sprite manager of some sort that would create the sprites, destroy the sprites, and check for collision with other sprites/bullets. I had planed on creating the sprite manager in the game engine class and controllong it there. This is the first game I have made using any collision so I am having trouble with this part of the design. Any suggestions or psuedo code would be great. I can also post my class headers if it helps

Share this post


Link to post
Share on other sites
Advertisement
I'd make that Graphics class a singleton, rather than a global object, or I'd create a Graphics object within the game engine (assuming that 'game engine' is a class). Keeping it global can get messy. :)

What I do is keeping both surfaces and sprites in the same manager class, as each sprite refers to a surface. The class is relatively small, so I didn't see the need to create subclasses for both. This renderer class allows game entities (or menu objects, anything) to register and unregister sprites and allows entities to update the sprites they hold a reference to.

I seperated my collision code from the rendering code, as in my game, not every visible object needs collision checks, and I believe such different tasks shouldn't be put in the same class for clarity sake. My collision manager class works in much the same way as my renderer: game entities can register a shape and get a reference to it in return. They can then ask the collision manager to check for collisions, and they can update their collision shape.

So, basically, I've set up both modules as utilities for the game logic: game entities can use them to do collision checks and do rendering for them. It may not be a perfect design, it's my first attempt at a 2D engine, but the structure works quite well so far.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
for now, the graphics class does need to be global to be accessed everywhere because of my design (which is probably a poor one anyway) because i have the sprite class and MapEngine class as seperate objects that need to create surfaces which is handled in the graphics class. The graphics class is bassically just a collection of a few functions to make it easier to create surfaces and load graphics, nothing complex at all.

As for the collision, could you desribe in a little more detail how exactly I should handle it? I have a rect for each sprite that I can use for the collisions but how do I efficiently go about handling the collisions? Should I check every onscreen sprite against every other onscreen sprite for a collision in a loop and then deal with it as necessary? or are there better ways that are easy (for a collision newb) to understand? If you have a link to a good post on simple collision management that would work too.

Thanks again for you help :)

Share this post


Link to post
Share on other sites
I agree, it's better to define which parts of the program may have access to this Graphics class than using a singleton (which is basically just a global, single object, accessible through a static member function).

Anyway, as for the collision tests, my code currently tests against all other objects. Which is obviously a bad idea, as 10.000 checks for 100 moving objects is a waste of CPU power. It's a good idea to implement a culling method, like a quadtree for example, so you can look up which other rectangles are in the same area as the one you want to check against. While moving objects, you need to update their position in this quadtree, and it takes a little time to look through the quadtree, but it allows you to narrow down your collision tests to a small set of objects.

Handling movement is somewhat more difficult, and I still haven't ironed that out completely. Whenever I move an object, I test it against other objects and whenever it collides with one, I push it back so that it doesn't collide anymore. A problem with this method is that, while it's fine for two objects, it gives some trouble when there's more objects involved: after popping out of object A, it may get stuck in B, which pops it out as well, back into A... It's probably not a big issue when dealing with few and simple objects, but still.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!