Jump to content
  • Advertisement
Sign in to follow this  
JaguarDown

Managing game logic?

This topic is 684 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 all, just to give a brief background before my question:

 

I'm learning how to create games independently in my spare time as a hobby using C# and the MonoGame (XNA) framework.

 

C# is the most familiar language to me and I am probably an intermediate programmer with it. I have completed a couple of 2D space shooter tutorials, one by an individual on the internet and the other by Microsoft. I picked up where Microsoft left off and implemented their XNA game state and input management into the tutorial game and I fully understand it, it's very efficient and flexible. My goals are to learn other game tasks such as file management, networking, and efficient content management, but there's a lot of information on these topics and they sound trivial to implement.

 

However, my trouble is with game logic. The basic structure of the game loop on the game play screen in MonoGame/XNA (and I suspect most games) is to initialize, update, and draw. The Update() method processes all of the game logic during play. Even in a very simple and small 2D space shooter like I am working with, there is already a lot of objects and data to process and is clearly way too much for one Update() method. I had divided up all of the logic into further methods within the game screen class to organize things but this just resulted in about a dozen nested methods which seems very sloppy.

 

I was thinking about implementing a Logic Manager class to handle all of this logic but I think it would quickly become bloated and have the same problem as the game screen class. Then I thought about having different classes, i.e. Player Manager, Projectile Manager, Enemy Manager, etc. I am still going to have to pass a lot of data from the game into these classes either into their constructors or their methods, unless I am approaching this poorly.

 

I can only imagine how much logic would be written for larger games which I will be working on in the future and it sounds like a nightmare.

 

My main question:

Is there any conventional wisdom, approach, or general architecture games use to handle this behemoth amount of logic that any of you would suggest? Or is it different for every game and I just have to hammer it out through trial and error, trying to improve my OOP skills? I haven't been able to find much searching the internet. I suppose I could just try to read some source code if I could find some that's good.

 

Sorry for the long post, thanks in advance!

Share this post


Link to post
Share on other sites
Advertisement

I'm making a Zelda/Isaac dungeon crawler using libGDX, and my way of handling it was having entities with their own update() method and call all of them in my main Game class's own update method. The same for rendering, I have each entity having their own render method that gets called in the Game's. I believe that's the most common approach too, having an Entity-Component System each one managing itself.

Share this post


Link to post
Share on other sites
One very common pattern is to have a GameObject class with a draw method and an update method. Then you extend that class to a player class and an enemy class and so on. In your level class, or world class or what have you, you can have collections of these GameObjects and just loop through them in the update and draw functions.

This pattern has some flaws, but it is a great starting point.

Share this post


Link to post
Share on other sites

Thanks for the replies, they definitely help.

 

I guess what I'm trying to say is, even if you have self contained objects and update them all at once, how do you determine collisions and other interactive logic without having hundreds of lines of code in the main game class's update() method? Is this not unavoidable? Should there be some kind of entity manager that calls update on all the objects and says "if projectiles collide with enemies, I'm going to kill those enemies." And then just call EntityManager.Update() in  the main game class?

 

In other words, you can't have spaghetti code where all objects know about each other, so how do they know when they interact? I suppose I could use events. Unless you can check for collisions some how in the "Game Object" base class.

 

Maybe I'm having this problem because of my lack of experience and I can't think abstractly enough about it?

Share this post


Link to post
Share on other sites

You could skip the use of an 'EntityManager' and manage them entities updates in the main Game class, I don't really see anything super bad in that. For collisions you could have a Controller that u use as a component in every entity (like the 2DController Sebastian Lague makes on his Unity platformer tutorial for example); or just manage the collisions in each entity 'customly'. For example I have my Projectile class with it's own CheckEnemyCollisions method that gets called in every enemy in the room (I wouldn't do it like that on a, for example, sandbox; it may be neccesary the use of quadtrees in there for optimization purposes, you don't wanna check collisions on a enemy you KNOW it's like 1 km away lul), and if it detects a collision it even takes health away from the enemy who it collided with.

 

I don't think having this behaviour would be considered spaghetti code, it may be breaking encapsulation a bit but I prefer to have 1 line of damage code in my projectile and run it when it collides with an enemy than having a whole class wih events and such just for it.

And say that I want enemies to shoot to, I could abstract all the projectile's movement and other general functionality in a superior Projectile class and have my now PlayerProjectile class a subclass of it, and only implement the CheckEnemyCollisions for THAT kind of projectile alone, and even have a method in my Enemy class called takeDamage (calling it in the aforementioned method) so I don't mess with variables that should be private of the Enemy class in my Player class directly.

 

I wanna point out that u should take my advice with a grain of salt tho, since I'm no authority, but just a fellow beginner who has had the same headache u are goin thro (not knowing how to structure my game) and that finally decided on use the approach I'm talking about, which so far haven't given me any real pain; and also that I'm basing advice in my current situation only, just because it's the only basis I have for giving any advice at all :D

Share this post


Link to post
Share on other sites
Whiskydogs advice is sound.
In OOP you should try to put the logic with the objects that do them. So, the missiles themselves should check for collisions against enemies, enemies should check collision with the player, and so on. Generally, the use of '-manager' is a bad idea.
Give your Entity/GamObject objects a reference to the world and put the logic for verbs together with their nouns.

But always remember: It's not about writing pretty code after everyones standards, it's about writing code that is easy to work with for you in your current project. If you want to make games, focus on making games :)

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!