next »

[JaguarDown]

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!

[oahda]

I think the two main ways game engines would deal with this would be something like:

1) Component-based system with systems that work on components and handle them differently depending on the exact combination (a transform component alone may make things work in one way, but if it's combined with a physics body, like a rigid body, which may affect the transform, the system might work differently and so on).

2) Not necessarily but often component-based system where objects have callbacks for various events, so that either individual objects or classes of objects may define how they wish to handle a particular event (update, draw, collision and so on).

Either way the end goal is little systems that kind of work on their own and only know about what they need to know about. Scripting can help make this more manageable.

[Necdilzor]

Hey there, I'm not sure if you already know this but you should check out GoF design patterns to help you structure better your OOP code and find a neat solution for this. It'll be worth the effort.
https://sourcemaking.com/design_patterns

I think your update() method should call update() of other components to separate work otherwise you'll have just one monolithic update() method that could easily get out of hand.

I hope this helps