New API features planned!

This past week has been a hive of activity in respect to the JS API, with loads of new features being planned or confirmed for future releases!

DORDER_RECOVER

Cyp mentioned that DORDER_RECOVER should be making it in to Warzone 3.1 Beta 5.

More importantly, the hard-coded restriction that prevented AI scripts from using it has been changed, meaning that your scripts can now pick up oil barrels and artefacts!

DORDER_OBSERVE

Per has confirmed that this constant has been added to the JS API, although it's not yet clear if it will make it in to 3.1 Beta 5 or much later in 3.2.

It's a really useful constant if you use sensor droids because it means they can observe a target not only for their assigned units, but also your base defences.

If you want to start using it in your scripts right away, check out backport.dorder.js which backports the constant all the way to Warzone 3.1 Beta 1!

Object linking

This is still in the discussion phase, however it's likely we'll soon see a way to associate objects with each other. This is going to open up much better ways to manage droids.

A good example of this is when getting multiple construction droids to help build a structure. Currently it's a bit of a pain trying to work out how many droids are building the structure, which in turn makes it difficult to decide whether to order more droids to help or not. With object linking, the structure will contain links to the droids building it, and the droids building it will contain links to the structure they are building. The same sort of thing can be done for attack droids - they can be linked to their victim, and their victim linked to them.

There will likely be a number of functions around this, such as:

• link(obj1,obj2) – create a bi-directional link between two game objects
• unlink(obj1,obj2) – remove the link between two objects
• enumLinks(obj) – get a list of all objects linked to the specified object

I'm also hoping that we'll get automatic linking done by the orderDroidObj() and orderDroidBuild() functions.

If either object is destroyed, the links will automatically break.

Object annotations

Also in the discussion phase is object annotations. This will allow scripts to store arbitrary data on game objects that will persist as long as the game object exists.

I'm still not sure if I like this idea - I can't decide if it's a good thing or a bad thing – but like I say, it's still at discussion phase.

Listing objects in a specific part of the map

This will hopefully make it in to 3.1 Beta 5 - a function that allows you to get a list of game objects within range of a specific point on the map.

Immediately, this will be very useful for sensor droids because it will allow them to move somewhere then get a list of nearby local targets and DORDER_OBSERVE them.

There are lots of other possible uses too. For example, you will be able to get a list of your droids near an enemy droid or structure.

While this sort of thing can be done using the existing API, having a dedicated high-performance function in the JS API will make it much easier and quicker to use.

I'll be writing a backport of the associated functions when they are released.

Improved data persistence

I'm really stoked about the planned changes to data persistence.

Currently, the JS API will try and persist any global vars with the exception of functions, constants and JS API features. This causes all sorts of problems as I outlined in sessionStorage and localStorage.

To my utter amazement, it looks like the new data persistence approach will be very similar to my proposed solution - we'll be getting two new global objects (the names of them are still under discussion):

• <game storage> – will persist data for the current game, including save/load cycle
• <permanent storage> – will persist data across multiple games

This is just huge, I literally did a Chandler dance in front of my laptop when I read the news!

Not only does this solve a load of gripes I had with the current system, it also opens some huge new possibilities for us scriptwriters:

• <game storage> might be shared between all player scripts, allowing live data sharing between AIs!
• <permanent storage> will allow scripts to remember what happened in past games, an in turn scripts can then be developed that identify trends and adapt to them

That last point is loaded with future potential: Human players learn how an AI script "thinks", identify weaknesses and exploit them. In the future, AI players might be able to do the same thing against human players!

Scavengers

There's been a bunch of work recently around making it easier for scripts to "see" scavengers. In the past, AI scripts haven't been able to get lists of scavenger droids or buildings, resulting in the AI being somewhat useless when there's scavengers on the map.

Luckily that's all about to change (and in fact some of the changes might already be in recent beta releases).

The enumDroid() and enumStruct() functions have recently been altered to allow them to get lists of scavenger player droids and buildings. It's likely that these changes are in 3.1 Beta 4, and possibly even Beta 2.

The problem is that the player ID of scavengers is always greater than maxPlayers so AI scripts aren't currently aware of scavenger objects until a scavenger attacks them. Luckily, we're about to get a new scavengerPlayer global that will tell us what player ID is being used for scavengers on the current map.

So, expect AIs to start getting much better at dealing with scavs in the future!

That's all for now!