Game turn Loop

So, after a bit of reflection today, i decided on the initial draft of the game loop (ie: what happens on every turn of the arena match), so here is what i have thought of so far:

• The timeline is discreet, ie: the player units and AI see the world in steps (read: turns). They examine the game world every turn and then act upon their AI and code. I figure this way, it would be easier to implement such things as speed (allowing each bot to move a certain distance during each turn) and also be easier to implement code wise. I also think that if the timeline steps, or turns, are small enough, then the arena will seem to unfold in close to real time, and not so jerky
• When the bots submit their actions, they do so in an ordered queue (so say, moving to point A and then shooting, is not the same as shooting and THEN moving to point A). However, some actions might not be exclusive, and maybe we can provide a way for them to be grouped together into more complex actions (such as moving AND firing at the same time, or harvesting resources AND shooting one of the guns)
• In any case, I guess the main event loop will be something like:
  1. Units get their Unit::think() called every turn, and then they return an array of actions to be done in an ordered queue
  2. Actions are then passed to a Referee Engine, which disqualifies illegal actions (moving too much, shooting many times, etc)
  3. Legal actions are then applied (units moved, shots fired, health decresed, etc) using the referee engine, with the physics engine verifying outcome (colliding units stopped, hit units shaken or moved by impact, etc)
  4. A script is generated of what happened in the turn detailing all the actions and events
  5. The turn script is sent to the Gfx & sound engines to produce output to user
• The script generated should be complete enough to allow it to be some sort of recording mechanism, allowing the user to break down the work, which might allow later a dedicated AI server, where players can upload their AI teams and just download the script then and allow match servers to only focus on the AI part, with the competitors able to download the results and playback of their matches to examine how their AI behaved, ie:
  • The engine can run in AI-only mode, only producing a script of the match, without any visualisation of the game itself
  • The engine can run in Playback-Only mode, where the input is a match script, and the engine just renders the match script as it unfolds to the player
  • The engine can run in Live mode, where the complete process is implemented as mentioned above, with the script being updated every turn and the results presented to the user “on-air”

That is all for now, keep you updated as usual

Designing the universe

In my design of the API for the OpenAIArena, i must here recall something that I read in the book Head First Desgin Patterns, that was about designing any piece of software… a simple line that read: “Code for CHANGE” and i have to agree that over the last few weeks, i have found this to be QUITE true…

anyways, reading through the previously mentioned API design book, today i will quote this piece of the book that i will have to keep in mind:

“Although some developers might think differently, I am sure that the APIs of almost all our libraries in active use will never be final. They’ll always evolve. We must be ready for that. We must be prepared to modify our understanding of the universe and we must be ready to enhance and improve our library APIs“

I have to say i COMPLETELY agree… so, i will have to keep in mind to try & keep the arena API open for evolution

API Design

Nothing much new going on in the arena front, just trying to formulate more & more on the types of bots, weapons, terrain, matches, etc…

however, on the theoretical side, I got a hold of a new book, namely Practical API Design: Confessions of a Java Framework Architect… to make a long story short, it deals with the design of APIs, not regular apps, and that is a DIFFERENT thing…

im currently still in the introductory chapters, but this book looks like it would be exactly the type i’d need to design the arena api… more on it later on

Laying out the Foundation

So i did a bit of thinking today and i thought about how the bots should move, how the shots will take effect, what Physics engine will be used and even the build system i would use to ensure cross-platforming… however, after a while i realised that my thoughts were generally incoherent, because (i had to admit) i was going at the project, from the wrong end… it is true that i wanna learn about engines and game components, but first, we had to have a base…

As a result, i decided i wanna lay down the ground rules to what this project is all about, and what i actually want from it… so here is the ground work about how the project will be used and how it will work:

1. the users will be presented with two things, an API (basically some shared libs that are linked in the code) and an app that runs the simulation
2. the app can be run in full mode (simulate match and render events) or in just AI mode (simulate match and present a script of what happened) or just a renderer (read a script and animate what happened)
3. the arena must be VERY moddable, ie: players can create their own:
   • Levels (ie: terrain + objectives)
   • Game types (ie: king of the hill, last man standing, allows buildings or not & rules)
   • Models and textures for the units in the game
4. the players must have the option to code as little as they want of their bots (only the top strategy for the team they are playing) or could get down and dirty to replace everything about the engine itself (ie: even the aiming, shooting and pathfinding algorithms)
5. coders submit their inventions in source code format, that is formatted in a certain way (packaging system) in order to be available for other coders and easily added (everything from custom unit models & animations to AI strategies and algorithms to even Gfx engine and physics engines)
6. perhaps provide a python (or lua?) scripting interface for quickly testing code or algorithms

As for the game itself, i wanna try and make it scalable, from a VERY simple grade (just a number of teams, each team with one bot shooting each other, last one wins) to a VERY complete and complex grade (think full RTS but AI code instead of players, with resources, buildings, walls, transports, siege, etc)

thats all for now folks… the design is not complete and in no way coherent yet, but atleast now i have a starting ground… i will try to tackle these points one at a time, but generally it is clear that the main point will be to think of making the engine highly moddable as possible…

as always, any comments are more than welcome… keep you posted

Re-invent the wheel

Well, after some thoughtful reading, i have decided that there is actually no point in re-inventing the wheel and writing everything from scratch, and so, i will opt to using ready-made libraries and engines (Qt, Boost, Ogre, etc) for most of the aspects, and just concentrate on building the SDK itself… the only point to note though, is that i need the openAIArena to be completely Open Source, and though i will ONLY use OSS…

what comes next, though, is the actual choice of engines to use… i will most likely use the Ogre3D engine for the graphics… as for the physics, i am looking into the Bullet physics engine vs OPAL / ODE engine… will have to read more about them later…

still don’t know if there is even such a thing as a SOUND engine, and if there is, i will look into finding an OS one to use too…

one more thing, i will most likely try to look into references in order to facilitate the building of the API (ie: i will try to look at how Project Hoshimi used to work) and i will try to build the arena to be as close as possible to a complete RTS game (building, gathering, healing, objectives, etc)

thats mostly it for now… stay tuned for more on the OpenAIArena project later…

ps: the exile game has to be pushed back now to later when i am more experienced and have more time…Technorati Tags: openaiarena