Shard, Gadget AIs, and Project Management

Things are moving forward. Recent political hoohahs and misunderstandings have been cleared up, and a new vision is needed!

To start, Foreboding Angel has offered to lead a port of Shard to exist as a pure lua AI in the spring engine, using the native gadget AI APIs.

How will the different projects move forward?

I will continue to develop Shard as ‘Shard Core’, using the native interface. Foreboding Angel will lead the maintenance of the Gagdte Port of the Shard API. The Shard code from SHard core will use this API, and only this API, to ensure compatability.

Naming

My build will be termed Shard Core, and I suggest the following naming scheme:

<game name or distribution name> Shard <version moniker>

e.g. EvoRTS Shard Ballsey or just EvoRTS Shard if we were to take the latest release ( 0.31 Ballsey ) and the gadget AI currently used in EvolutionRTS.

What is Needed to Port the API?

Shards C++ component exposes an object called game_engine which is wrapped by another object named game in the file api.lua. Using this, one can make this objects functions work in both environments.

E.g. to make the game:SendToConsole call work in both Spring and Shards lua environments, the following ammendments need to be made:

   -- prints 'message' to ingame chat console
   function game:SendToConsole(message)
      if Spring ~= nil then
         return Spring.SendMessage(message)
      else
         return game_engine:SendToConsole(message)
      end
   end

From here on it’s mainly a matter of including the new api.lua, the ai itself, instantiating an instance of the AI from a gadget luaAI, and then passing events to this new AI object. Wrapper wills also need ot be made to prepresent the unit objects and unit definition objects also, but these are simple and would require little work, and can be done entirely using spring gadget API calls.

Spring specific code?

Once Shard is ported, developers will want to use their own code callouts and access spring specific APIs. I ask that rather than modify the existing code, they duplicate the relevant behaviours under a new game specific name, and make their own adjustments there. This way they can retain the benefits of updated Shard code, while having their own code that integrates with their own gadgets. Further documentation and helper methods will be made available to facilitate this, allowing Shard behaviours to be added from other spring gadgets.

Progress

Foreboding is currently refamiliarising himself with Shards internals. Here’s a video of a recent battle he posted:

http://youtu.be/MCeJeCuM4N8