Jump to content
  • Advertisement
Sign in to follow this  
kcirbmab

Engine Structure - improvements?

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

I'm beginning to get into game development and am working with Python with PySFML. A huge issue I'm having right now is the structure of the code itself. I was wondering if you could give me a few tips based on my current implimentation. The game will be a 2D shmup.

I've never done something like this before and I'm kind of roughing it, so I'm sure it could be improved (especially since I'm still very early in development).

Basically I have a "game" class which encompasses everything else. It's main functionalities right now are:
- it contains a list of current game objects (ie - player, NPCs, map, etc)
- a function to call update on all objects in the list
- it contains pointers to the input controller, graphics controller, game state, events etc.

I basically pass the game object to anything that needs any of the above. If the player character needs to access input or the clock, it can do so through the game object. If an object requires an image, it can find it in through the game object.

Is there a better way to do this? Any comments?

Share this post


Link to post
Share on other sites
Advertisement
Sounds ok for a small game, but it's already apparent that your game class is taking on too much. Ideally, a class should only have a single purpose. You can put all game objects inside a Level class, and image caching into an ImageCache class. You could still have a central Game object that contains all these objects, but it no longer contains all that functionality itself.

As for input, personally I wouldn't give game objects access to this - instead, I'd write some glue code that reacts to input. This glue code would then control the player object. As for updating, I'd pass a frame delta to all game objects - most likely they won't need access to a clock anymore.

Share this post


Link to post
Share on other sites
Kind of like Captain P said, I'd say it's fine to do it how you are so long as the game class contains objects that handle the functionality instead of handling all the functionality itself.

Basically, you want to divide and conquer the tasks of your game and keep them in simple, compartmentalized classes in their own well named files.

If instead though, the main game class is looking deep into these objects, doing logic based on them and heavily manipulating data within them, you are going to drown in the complexity in anything but a really simple game (:

Also on the idea of input, instead of the player polling input, you might think about having the input system send out events?

I haven't used python much but if there is some way to do delegates and make objects register to receive events, i'd have the player register with the event system that it wants specific input events.

hope this helps! You are on a pretty decent path IMO

Share this post


Link to post
Share on other sites
Quote:
Original post by Atrix256
Kind of like Captain P said, I'd say it's fine to do it how you are so long as the game class contains objects that handle the functionality instead of handling all the functionality itself.

Basically, you want to divide and conquer the tasks of your game and keep them in simple, compartmentalized classes in their own well named files.

If instead though, the main game class is looking deep into these objects, doing logic based on them and heavily manipulating data within them, you are going to drown in the complexity in anything but a really simple game (:

Also on the idea of input, instead of the player polling input, you might think about having the input system send out events?

I haven't used python much but if there is some way to do delegates and make objects register to receive events, i'd have the player register with the event system that it wants specific input events.

hope this helps! You are on a pretty decent path IMO


I'll bite... what is your definition of deep? Single dot principle?

Share this post


Link to post
Share on other sites
The shallower the better, but rules have to be broken sometimes so it's just a guideline, not something to live or die over (:

The deeper your main game class digs into the objects it contains, the more complex your main game class becomes and the harder the code is to work on and improve, and the bigger possibility for bugs.

Compartmentalization ftw!

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!