Sign in to follow this  

Structing your classses/engine correctly + Tile layers

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

So I'm making good progress with my 2d side-scroller, but being my first attempt at what I guess you could call an engine I've run into a few problems as I didn't do enough design before starting to code. Main class is CGameEngine. This is where I plug all my sub-classes or managers into, i.e log class, font class, as well as holding my stack of game states. Each game state has its own input handling and draw functions. My problem comes when for instance, the draw function for my title game state needs to render some text using my font. The font class is plugged into CGameEngine (in future I was intending to store all my needed fonts for that game as an array member of CGameEngine). Another example is my tilemap class that is responsible for loading the tilemap, storing the tiles and rendering them based on an array. The tilemap class is part of the main engine class but the individual game states are unable to access them. In a previous thread, relating to game states I mentioned passing a pointer to the engine to the state, so the state could refer back to the main engine and any part of it, but was advised this was bad design/programming. I suppose I could pass the top of the stack's state's draw function various pointers to font/tilemap class but I don't see how this is any better, and seems rather inefficient. How would I go about structuring this? Also, I can probably figure this out but how would you advise I go about the various layers of tiles in a side scroller (using SDL). I'm guessing that I render the background tiles to a surface. Then I render my next layer to the surface (bearing in mind the tiles have alpha transparencies) and so on. When all layers have been blitted to the surface I 'flip the screen'. Would this work or should I go about it another way? (like having a seperate surface for each layer, though I wouldnt really know how to implement this) Thanks for any help

Share this post


Link to post
Share on other sites
I don't have all the answers for you, but your questions are basic fundamental problems of game design that everybody faces. In my opinion, you should build some link between the classes that need to know about each other. Yes, this creates dependencies and isn't necessarily 'good programming'. But it works and its very powerful and if it gets your game closer to 'done' than go for it. This is my approach and my latest game is almost finished. Never sacrifice something that works just because you can't find a 'more elegant' solution -- there will always be one, limit your time searching for it and move on. If you were programming industrial strength type code I might not say these things, but in practice there's only a limited amount of interaction between your classes that you'll need for a decent 2D game.

I don't know about SDL in particular but your layers system sounds like the right idea for a 2D game. The more powerful your 'layer' and 'layer collection' classes are, the better, at least based on my experience. These types of structures are critical to powerful 2D engines.

C++ experts feel free to correct me, as I am definitely not one...

Share this post


Link to post
Share on other sites
I am having the same problems as you , but the best solution I found was to make font class global, so all elements of engine class can access it and type text. I think passing the pointer is not a good option, because in my class it would pass 3 or 4 functions until finally starts using it.

Share this post


Link to post
Share on other sites
Hello,

Quote:

C++ experts feel free to correct me, as I am definitely not one...

Neither I am :) But:

1) There is one game engine, because there is no point in having more than one.

2) you need it extensively through your program.

3) you still want to have a clean interface and to control how the client application access to your game engine.

Sounds like a work for the the singleton design pattern.

To create surfaces in SDL: SDL_CreateRGBSurface and SDL_CreateRGBSurfaceFrom should do the trick. If the flags sepcify SDL_HWSURFACE you'll take advantage of the hardware bitter. SDL_LockSurface allows you to modify a hardware surface. And SDL_BlitSurface blits the surface. The SDL documentation is located here.

HTH,

Share this post


Link to post
Share on other sites
I don't use a class for the engine as there would only be one instance of it anyway. Instead, I have a number of namespaces which include functions. These functions handle dynamic loading and destruction of data by using either maps or vectors. For situations where there would be more then one instance though (ie sprites), I have a class made up.
System::Initialize(640,480);
System::Audio::Load("music.mp3");
System::Audio::Play("music.mp3");
// ... etc

Share this post


Link to post
Share on other sites
Quote:
Original post by Rob Loach
I don't use a class for the engine as there would only be one instance of it anyway. Instead, I have a number of namespaces which include functions. These functions handle dynamic loading and destruction of data by using either maps or vectors. For situations where there would be more then one instance though (ie sprites), I have a class made up.
System::Initialize(640,480);
System::Audio::Load("music.mp3");
System::Audio::Play("music.mp3");
// ... etc


Yep. It's okay to make things "global", but you should always be trying to reduce the scope of the variables (and functions!) to the smallest, easily definable scope that will do the job. Making use of file scope (and the data-hiding features of the C/C++ inclusion model - hint: not everything has to be declared in the header. Use the model to your advantage), namespaces, and static class members is often useful.

Share this post


Link to post
Share on other sites

This topic is 4691 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this