Quote:
Originally Posted by Dano
Integrate it with CoD, /end thread 
Seriously though, CoD is crying out loud and begging for some sort of graphical interface for commanders with the ability to assign flights and orders, it'd make online servers better by orders of magnitude. |
Well, having slept over it I think it would be interesting to code AFC (Air Force Commander - working title
) to be able to do both from scratch
When playing the "single player strategy game" the AFC AI has to spawn the flights and give them orders, set up rendezvous points and to direct them to the target etc. If integrating with CloD it would actually be about the same thing - the difference is just that the AFC would not have complete control. This is all based on the assumption that it will be possible to build a bridging API between them. The though is to build some kind of simple RESTful Web Service API where you have a number of methods like SpawnFlight(), GetFlightInfo(), ChangeFlightOrders(), GetListOfSquadronsAtAirBase() etc. These would then have to get the data through the server side scripting. As there are no such API:s open in CloD I guess one would have to do some hybrid solution where the server side script looks into some async Redis key/value command handler storage structure for new commands, and then stores data with some kind of interval in some hashtable with all flights/aircraft other objects to track. Then the bridge API would for many of the queries get an answer directly from Redis (like GetAircraftPosition), but for some like SpawnFlight the API layer would "create" the flight structure in Redis and return the ID for it, then on the serverside the scripts will see that it has a SpawnFlight request and do it... In a while the Redis structs with ActiveFlights will "show it" to the AFC GUI that is driven by drawing what it gets there...
An interesting dream would be that it could be possible to create third channel integrating via the bridge API.... Do a web lobby where players log in and select a squadron they want to join looking at the plan that the AFC gamer has put up. There all the current missions should be possible to show as well as the current battle situation based on the web page reading data the same way as AFC from Redis (or maybe make the whole AFC game web based - but that would hamper the GUI). When the user selects his squadron/mission/available plane - it gets into the Redis structure that AFC is "watching". The CloD server side scripts picks that up so when "Player X" logs into CloD they are moved to the correct location and plane, that has already been warmed up by AFC via the bridge API into CloD. The interesting coding part is that all objects, both the "AI" and player objects will have a life of their own and may disobey orders / crash into mountains etc...
But - all in all the stand alone strategy game would work exactly the same way, the difference is just that SpawnFlight() etc would have to be handled by the AFC AI instead of CloD. For the commander API in AFC it would be the same thing. Every loop get the list of flights/aircraft/movable object positions ("what - have they not gotten off the ground yet?") and update the game map. When the AFC player clicks a unit it calls GetFlightInformation that returns a datastructure with the flight/planes/pilots/orders chain/etc.. So if dividing the code into a GameWorld AI part that actually moves the planes and act in dogfights it really does not matter for the AFC GUI if it's a real player in CloD that did it, AI in Clod or the standalone AFC AI...
And finally, the dream++ is naturally to not have to do the pseudo bridge but get an API directly into a CloD server "from the outside"