GameLogic Responsibility

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • GameLogic Responsibility

      Hey guys,

      I've read through the book a couple different times now and I've almost got my engine completely written using GCC4 as an example (convered to .NET / XNA).

      The only thing I'm having trouble with is the responsibility of the GameLogic class. I look in the GCC4 code base and I see a public "MoveActor" method on IGameLogic, but I can't figure out when or who would ever call this as I thought things like moving actors were event driven (controller realizes a key was pressed, so it fires an "ActorMoved" event that's then caught by GameLogic who then uses the physics system to move the actor. Is my thinking off here?)

      I had originally thought that the Application instantiated a GameLogic and fed it it's views, then told it to update and render itself on each tick. The GameLogic itself would then just coordinate the Update / Render of each of the other systems (physics, views, actors, events, etc) but it looks like it has more responsibility than that. Could someone clarify?

      Lastly, why is there a base GameLogic in the engine and an inherited version in the Application? Is this so that I could potentially create more than a single game using the same engine?

      Thanks!
      -bullgoose
    • Remember that the gamview and game logic comunicate back and foward, I don't have access to the source code right now, but I know in my engine the game logic lets the view know when an object has been moved so the view knows where this object is exactly at so the same could've been implemented here...

      Lastly, why is there a base GameLogic in the engine and an inherited version in the Application? Is this so that I could potentially create more than a single game using the same engine?


      I don't know about this one, maybe rez or mike can answer this better.
      Intel i7 3930k
      8GB Mushkin LP @ 2133 mhz
      GTX 680
      Asus Rampage IV Extreme
      Corsair 650w
    • RE: GameLogic Responsibility

      Originally posted by bullgoose311
      The only thing I'm having trouble with is the responsibility of the GameLogic class. I look in the GCC4 code base and I see a public "MoveActor" method on IGameLogic, but I can't figure out when or who would ever call this as I thought things like moving actors were event driven (controller realizes a key was pressed, so it fires an "ActorMoved" event that's then caught by GameLogic who then uses the physics system to move the actor. Is my thinking off here?)

      VMoveActor() is a great lesson in video game development. Have you looked at the code? Here it is in all its glory:

      Source Code

      1. void TeapotWarsLogic::VMoveActor(const ActorId id, Mat4x4 const &mat)
      2. {
      3. BaseGameLogic::VMoveActor(id, mat);
      4. // [rez] HACK: This will be removed whenever the gameplay update stuff is in. This is meant to model the death
      5. // zone under the grid.
      6. // FUTURE WORK - This would make a great basis for a Trigger actor that ran a LUA script when other
      7. // actors entered or left it!
      8. StrongActorPtr pActor = MakeStrongPtr(VGetActor(id));
      9. if (pActor)
      10. {
      11. shared_ptr<TransformComponent> pTransformComponent = MakeStrongPtr(pActor->GetComponent<TransformComponent>(TransformComponent::g_Name));
      12. if (pTransformComponent && pTransformComponent->GetPosition().y < -25)
      13. {
      14. shared_ptr<EvtData_Destroy_Actor> pDestroyActorEvent(GCC_NEW EvtData_Destroy_Actor(id));
      15. IEventManager::Get()->VQueueEvent(pDestroyActorEvent);
      16. }
      17. }
      18. }
      Display All


      Can you tell what the code is doing? Absolutely nothing to do with movement! All it does is tests the Y for a magic number (-25) and kills the actor if the object is below that value. So what's going on here?

      Here's a bit of a history lesson. VMoveActor() was in GCC 2 and 3 (and 1 I think) and it used to do exactly what you'd expect: it moved the actor. This was before I wrote the component architecture, so actors were their own thing rather than a composite of multiple components. When we went to version 4 and I start playing around, I realized that all those spheres & teapots we were creating were never being destroyed. They were happily falling off the edge of the world and falling forever, which eventually caused performance issues. So I added that hack in VMoveActor(), fully expecting to remove it shortly after once we got into gameplay.

      So I pushed ahead and built the actor/component system. Code kept getting removed from VMoveActor() as the transform component and physics systems were coming online until eventually, all that remained was the hack. I still wanted to add a death object to the world but I never got around to it. I simply ran out of time and it became too dangerous to remove the working hack.

      Welcome to game development. Sometimes you come across an old function like this and scratch your head. It makes sense when you understand the history, but the end result is the same. VMoveActor() should be completely removed. That hack should instead be a large object under the arena grid that destroys anything that touches it.

      Source Code

      1. I had originally thought that the Application instantiated a GameLogic and fed it it's views, then told it to update and render itself on each tick. The GameLogic itself would then just coordinate the Update / Render of each of the other systems (physics, views, actors, events, etc) but it looks like it has more responsibility than that. Could someone clarify?

      The game logic is your core C++ gameplay system. If you're just building an engine, the logic won't do much more than it's doing now, which is managing the actors, dealing with the processes, and managing attached views. Beyond that, it's basically your core gameplay logic. Is your quest system in C++? It should live here. What about time of day for a simulation game? Maybe you have an AI system that needs to be updated? Those types of systems will either live in the game logic, or in Lua.

      [code]
      Lastly, why is there a base GameLogic in the engine and an inherited version in the Application? Is this so that I could potentially create more than a single game using the same engine?
      [/quote]
      Yes. All game-specific code should be in the game project file, which is why the logic and application classes are meant to be overridden. The engine should only have stuff that can be reused on multiple projects.

      I'll give you an example. I built a simple simulation game using my own game engine over the holiday break. My engine-level logic class owns the animation system, the stat component system (a system for updating and maintaining entity stats, which are generic values that can decay over time), my entity click listener (a system for handling gameplay click events on entities), and one of my process managers. In the game-specific logic class, I only had the time-of-day system. That logic class also spun up the various gameplay processes I needed to simulate the world.

      The rest of the gameplay logic lived in Lua script. In fact, the vast majority of gameplay logic was in Lua rather than C++, which made things go very quickly.

      Hopefully that gives you a better idea of what to expect there. When you're building the engine itself, the logic classes tend to remain very empty. It's not until you start actually making games that they fill out. Still, if you add all the code in both of my logic classes, it's only about 300 lines. The complexity lives in other system that the logic just owns (like my animation system, which is over 1000 lines of code).

      -Rez
    • Thanks to both of you guys for your responses.

      Hondero:

      Source Code

      1. Remember that the gamview and game logic comunicate back and foward


      That's an interesting point, my understanding was that communitcation was only 1 way (Logic to View) so I'll have to go back and read up. (Though I do understand there could be indirect communication from the view to logic through events)

      Rez: What's up man thanks for the detailed response.

      Source Code

      1. Welcome to game development. Sometimes you come across an old function like this and scratch your head. It makes sense when you understand the history, but the end result is the same.


      I think you mean welcome to software development :) I've been guilty of this in just about every type of application I've ever written...

      Source Code

      1. When you're building the engine itself, the logic classes tend to remain very empty. It's not until you start actually making games that they fill out. Still, if you add all the code in both of my logic classes, it's only about 300 lines. The complexity lives in other system that the logic just owns (like my animation system, which is over 1000 lines of code).


      This is exactly what I was hoping to hear as it doesn't contradict the engine as I currently have it setup. The individual systems like the Scene Graph, Physics, Events, etc. all make a lot of sense to me because they have specific responsibilities. It's the entry point where my engine gets a little sloppy. I always feel bad asking follow up questions cause I know you guys are busy and I'm grateful for the first response but if you get another minute, does this sound close to the correct flow of things?

      * Application instantiates the Game Logic

      * Game specific game logic instantiates game specific Views, Screens, Actors etc.

      * Application ticks the game logic

      * Game Logic ticks the other systems (Input, Views, Physics, etc)

      * Game specific Game Logic listens for gameplay events generated by the other systems (such as a mouse click, which for this particular game could cause the player to fire a missile which would involve system X)

      Thanks again keep up the good work!
      -bullgoose
    • Originally posted by bullgoose311
      That's an interesting point, my understanding was that communitcation was only 1 way (Logic to View) so I'll have to go back and read up. (Though I do understand there could be indirect communication from the view to logic through events)

      This is correct. You generally only want logic to communicate down to views and not the other way around, except indirectly through events.


      This is exactly what I was hoping to hear as it doesn't contradict the engine as I currently have it setup. The individual systems like the Scene Graph, Physics, Events, etc. all make a lot of sense to me because they have specific responsibilities. It's the entry point where my engine gets a little sloppy. I always feel bad asking follow up questions cause I know you guys are busy and I'm grateful for the first response but if you get another minute, does this sound close to the correct flow of things?

      * Application instantiates the Game Logic

      * Game specific game logic instantiates game specific Views, Screens, Actors etc.

      * Application ticks the game logic

      * Game Logic ticks the other systems (Input, Views, Physics, etc)

      * Game specific Game Logic listens for gameplay events generated by the other systems (such as a mouse click, which for this particular game could cause the player to fire a missile which would involve system X)

      Thanks again keep up the good work!

      Yup, this sounds correct.

      -Rez