Actor Node... Smart or Dumb?

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

    • Actor Node... Smart or Dumb?

      Hi,

      I have an actor node which I use in my game logic class to represent an actor in the game (held in a hash table list of actors by name). It holds basic information such as position, rotation, scale and state (walking, standing). Previously I had this as a process and during the onupdate() it would check the state and move the actor if the state was 'walking' and then move the actor and issue the appropriate move event. Now, I need to use this same actor node in my humanview view to keep track of the actors, but I can't have it moving the actor around as that is not the views job.

      Should I move my code that moves the actor around out into an view similar to an ai view and attach the actor to it, or should I have two actor classes, one for use in the view and one for use by the game logic?

      Hope I'm making some sort of sense.

      Thanks!
      Rael

      The post was edited 3 times, last by Raeldor ().

    • At the moment I have my game logic handling events for player start walking, stop walking, change direction etc. which are generated by keypress events handled by the humanview.

      I guess if I have a ai-like view for the player I could handle all of these events in there. Is that what Mike was aiming for in his book? He mentions an ai view, but no view to handle player movement.

    • Here's what I'd do:

      Game logic has an actor manager that controls whether the actor is in motion or not, and keeps the authoritative location of the actor. When the actor moves or changes state - it sends an event.

      Game view traps the Actor_Change_State event or the Actor_Moved event and does whatever it needs to draw the actor. The Teapot Wars game sample did exactly that.

      An AI view is something a little different - it is something that you could plug into the game and take the place of a human being. That's pretty different from something in the game logic that simply changes the states of game objects.
      Mr.Mike
      Author, Programmer, Brewer, Patriot

    • Originally posted by mrmike
      Here's what I'd do:

      Game logic has an actor manager that controls whether the actor is in motion or not, and keeps the authoritative location of the actor. When the actor moves or changes state - it sends an event.

      Game view traps the Actor_Change_State event or the Actor_Moved event and does whatever it needs to draw the actor. The Teapot Wars game sample did exactly that.

      An AI view is something a little different - it is something that you could plug into the game and take the place of a human being. That's pretty different from something in the game logic that simply changes the states of game objects.


      So, the actor manager would be a process and during it's onupdate event would check the state and move the actors based on the elapsed time?

    • Originally posted by Raeldor
      So, the actor manager would be a process and during it's onupdate event would check the state and move the actors based on the elapsed time?


      Not exactly. There is no state polling neccesary when you can listen for move events to update your actor position. Your ActorManager would basically be hooked up to listen for move events to keep it's data true as opposed to checking the state of actors in its update. That way, you don't waste cycles checking every single actor in the world for movement on every frame.

      To answer your original question, each one of your views will have a sort of duplicate proxy in the logical area that the particular view cares about. So for example, your GraphicsView will have some managed GraphicsActor (stored in a hashmap) that corresponds to some global actor ID with the minimum set of data required to interact with the GraphicsView. Your PhysicsView will have some PhysicsActor (stored in a hashmap) that corresponds to some global actor ID with the minimum set of data required to interact with PhysicsView. You have your central ActorManager as an authoritative central database that is great for saving the game or transmitting a state to another machine on the network, but the objects managed by the ActorManager would not even be aware that there is Physics or Graphics somewhere in the codebase. With this model, the separate logic subsystems (PhysicsLogic, AILogic) will generate the move events that ActorManager will use to update itself.

      ActorManager is basically a central authoritative database that the other logic subsystems use for queries and keeping data in synch. You want to avoid polling data in update loops as much as possible... so your favored method of making sure your actor data is in synch lies in using the event system to notify all listeners of pertinent changes.

      The post was edited 1 time, last by Kain ().

    • Physics logic generating events would depend on the type of actor. Some actors, such as characters tend to be moved by the AILogic. Other actors, such as vehicles, tend to be moved by PhysicsLogic. You'll eventually want a means of telling where the event came from so you don't end up in a vicious feedback loop where physics is sending a move event that causes something to move that causes physics to send a move event that causes something to move that causes physics to send a move event...

      So when you say AILogic... you are talking about an AI view?

      Nope :) AILogic, for sure. The purpose of a view is to be the thing that connects the logic to the rest of the application. In essence, the view is going to be what you make "public EventListener". The logic is the nuts and bolts of the system that is probably not aware of any other system in the game. In terms of design patterns, the view is known as an "Adaptor" pattern.

      So a way to think of it is this... let's use graphics as an example:
      • The GraphicsLogic is the part of the application that controls the renderer. It is self contained. You could ideally hook up a GraphicsLogic object to any application and have it do everything you need for graphics in the application.
      • The GraphicsView is an event listener that has access to all of the functions of the GraphicsLogic object. When an event comes in that GraphicsView is interested in, such as move, the proper action will be performed on the associated GraphicsLogic that the GraphicsView is in charge of.... such as "m_pGraphicsLogic->HandleActorMove(ID, position, rotation)"


      The benefit of keeping this separation of the view and logic is that you make sure that the separate systems of the game (physics, graphics, AI) are unmarried from each other so that each piece can be independently operated on without affecting other systems. This makes it easier for a team of programmers to maintain and write new systems. The physics programmer will write the PhysicsLogic first and only worry about what Physics can do without reguards to which events will need to be handled. The Graphics and AI programmer will also just worry about their own sphere of influence without reguards to which events to handle, which may not be set in stone that early in development. Then... when it is time, the programmer of each subsystem can take their logic class outside of their personal sandbox and insert it into the game using a corresponding view class as the glue that connects the logic to the rest of the app.

      The post was edited 2 times, last by Kain ().

    • I have started implementing a basic physics system and have it moving the character, but I am having issues with the terrain. Should the physics system be responsible for detecting collision with the terrain the same as any other object, or do most games cheat and do an initial test with the terrain before asking the physics system to check collisions with the other objects?

      Thanks!

    • What are the issues you are having with terrain? Also, which physics system are you using? Are you rolling your own? Kudos to you if so! Most third party physics ADKs will make the choice of cheating for you by allowing you to designate static terrain in the world differently from dyanamic objects.

      My guess is that most games will cheat as much as possible. Collision detection is an O(n) process where n is the number of triangles in the object. With a natirual terrain, that's a lot of triangles to check. There are a lot of mathematical shortcuts that fast physics engines will take to alleviate the number of triangles to check, but I don't know all of them. I vaguely remember terrain being defined as a 2D heightmap as opposed to a collection of triangles, but I must admit that I am weak on the details of that. There's a lot of information out there on advanced collision detection techniques, and probably in relation to terrain, too.

    • Yes, I am rolling my own. I want to write every part of my engine from the ground up as an educational exercise so I can use it in some kind of portfolio if I ever want to move into the industry.

      I guess maybe I will try and meet half-way then and have ability to subclass the physicsobject that the physics engine uses in order to override some kind of Intersect(boundingvolume) method. At least that way it would give the option to move the intersection test out into the users own code where they could code their own intersection test for something like terrain. Sounds like I need to take a step back though and work out the overall design for this rather than just wading in. Physics seems like a bit of a pandoras box.

      Seems like physics in the future might go the way of 3d with hardware acceleration, in which case writing your own physics engine becomes a little non-sensicle. Still, it's not part of DirectX yet, so I figure there is probably a couple more years before we get to that point. Plus it doesn't hurt to know the math behind it.

      Thanks again!

    • I wouldn't hold my breath on any physics boards, but physics APIs that use the shader language on a flexible GPU that returns values back to a CPU... that seems very likely to be the way it's gonna go. Havok is already doing it.

      Check out the OpenDynamics physics engine. I hear you can see the source code. It could be an excellent frame of reference to learn from.