Merging AIPlayer and Player?
by Anthony Lovell · in Torque Game Engine · 08/06/2005 (8:47 am) · 3 replies
My game concept differs substantially from TGE's stock treatment of Player and AIPlayer.
The most important distinctions I see are:
1. My avatars must be able to freely switch between AI mode and player-controlled mode. Those not under player control will be driven by AI. In this way, a given avatar might be under Player A's control, and then under AI, and then under Player B's control.
2. I need the AI processing to run purely on the server, as the game is persistent and the world should evolve under the influence of the AI even when no players are logged in. I'm not sure how this compares with TGE's current practice for AI.
What I feel I need to do is unify Player and AIPlayer into a single class of avatar (which I'd probably call Actor to differentiate it from players of the game, which is clearly a different concept entirely), and have this able to run under player control OR under AI logic running on the server.
What tricks and obstacles do people see in this plan of attack?
tone
The most important distinctions I see are:
1. My avatars must be able to freely switch between AI mode and player-controlled mode. Those not under player control will be driven by AI. In this way, a given avatar might be under Player A's control, and then under AI, and then under Player B's control.
2. I need the AI processing to run purely on the server, as the game is persistent and the world should evolve under the influence of the AI even when no players are logged in. I'm not sure how this compares with TGE's current practice for AI.
What I feel I need to do is unify Player and AIPlayer into a single class of avatar (which I'd probably call Actor to differentiate it from players of the game, which is clearly a different concept entirely), and have this able to run under player control OR under AI logic running on the server.
What tricks and obstacles do people see in this plan of attack?
tone
#2
For posterity and open to correction (and in case someone else has the same deficiency I have in understanding this), a Player can have its controlling connection set via
player->setControllingClient( GameConnection *client );
with GameConnection itself supporting a player's client application connected to the server, and AIConnection being a subclass of GameConnection intended to permit script on the server to supply control inputs.
I imagine this setControllingClient() method is called on the server.
Is that the germ of it?
How do Player and AIPlayer relate to GameConnection and AIConnection? Some entries on the site imply that *Connection are being supplanted by *Player -- is this evolution caught in mid-step?
tone
08/06/2005 (1:51 pm)
I think I finally see some of this spelled out.. not in documentation per se, but in threads and blog entries.For posterity and open to correction (and in case someone else has the same deficiency I have in understanding this), a Player can have its controlling connection set via
player->setControllingClient( GameConnection *client );
with GameConnection itself supporting a player's client application connected to the server, and AIConnection being a subclass of GameConnection intended to permit script on the server to supply control inputs.
I imagine this setControllingClient() method is called on the server.
Is that the germ of it?
How do Player and AIPlayer relate to GameConnection and AIConnection? Some entries on the site imply that *Connection are being supplanted by *Player -- is this evolution caught in mid-step?
tone
#3
There is a short hierarchy of Connection classes. NetConnection and GameConnection. GameConnection could just as well be called TorqueDemoConnection. It implements network transport, ghosting, NetEvent transmission, control object updates via move transmission, and so forth.
In TNL you can see a fuller evolution of this model; there's a NetConnection (basic packet protocol), an EventConnection (send/receive NetEvents), a GhostConnection (ghosting!), and then the game's specific implementation that might perform things like control object update, voice chat, and so on.
ShapeBase in Torque implements a network controllable object. It can run without a controlling client (as we find in cases such as turrets), or with a controlling client (in the case of a player). There are provisions in Torque's tick processing code for certain network related pieces of functionality; for instance, control objects update as they receive moves, not on the processs's timebase (within certain limitations to prevent cheating).
The setControllingClient method can happen on both client and server, though it's not necessarily useful to call it on client (the server's notion of the control object is what it sends updates and scopes for, so if you don't agree you get a lot of mostly irrelevant or even indecipherable data).
An AIConnection is just designed to sit in the places where a connnection might be, and provide some dummy services, without requiring a client on the other side. An AIPlayer is designed to run and frolick on its own.
08/06/2005 (8:46 pm)
Oh, Anthony... It's very simple. :)There is a short hierarchy of Connection classes. NetConnection and GameConnection. GameConnection could just as well be called TorqueDemoConnection. It implements network transport, ghosting, NetEvent transmission, control object updates via move transmission, and so forth.
In TNL you can see a fuller evolution of this model; there's a NetConnection (basic packet protocol), an EventConnection (send/receive NetEvents), a GhostConnection (ghosting!), and then the game's specific implementation that might perform things like control object update, voice chat, and so on.
ShapeBase in Torque implements a network controllable object. It can run without a controlling client (as we find in cases such as turrets), or with a controlling client (in the case of a player). There are provisions in Torque's tick processing code for certain network related pieces of functionality; for instance, control objects update as they receive moves, not on the processs's timebase (within certain limitations to prevent cheating).
The setControllingClient method can happen on both client and server, though it's not necessarily useful to call it on client (the server's notion of the control object is what it sends updates and scopes for, so if you don't agree you get a lot of mostly irrelevant or even indecipherable data).
An AIConnection is just designed to sit in the places where a connnection might be, and provide some dummy services, without requiring a client on the other side. An AIPlayer is designed to run and frolick on its own.
Associate Ray Gebhardt