ZK Developer Support of AIs

There is currently no working version of spring for zk. All there is to do is choosing from one of the development builds to keep the negative impacts to a minimum. Because of this, zk doesn't use the latest version of spring which means bugs can't be properly debugged either, as some of them have already been fixed in newer versions and the code has changed.

Once we actually arrive at an engine version that could be called stable, we should announce any changes as you say. I'm actually hoping for a new Spring 91 around 104 or 105. But in order to arrive there, we'll have to help the spring devs by letting them know about our issues. The most efficient way to do that is to take a step backwards and use the latest dev builds. This will probably cause even more crashes/lags/desyncs than the current versions, but those bugs won't find themselves.

Our current "player base" would probably hate being experimented on, but DeinSteamDreams require a stable and well tested engine, not some dev build. AIs breaking is a side effect of those experiments.


This is all just what I've picked up from how the engine has been getting updated lately and not representing GoogleFrog or any actual dev's thoughts.

There are plans of adding CircuitAI to spring's releases, it requires an update to the buildbots which unfortunately hasn't happened yet.
Java AIs are a slightly more complex issue.

I don't think bitrot can be solved except with maintenance. And maintenance needs maintainers.

Therefore:
1) AIs that want to be ressilient to bitrot should be maintainable in design and implementation.
2) There should be a superpersonal entity that attracts and keeps AI devs. That is, an AI community.
3) The AI community should be in contact and good relationships with both engine and game developers, from both ends. Though, as here here in ZK game developers fully control engine deployments, the latter are likely a higher priority.

The current ZK AI spring is an outcome of these points being satisfied. They are not satisfied for many other Spring games and this is why ZK has about 100% of current Spring AI scene all to itself.

1) All active AIs are reasonably maintainable and even capable of attracting non-coder contribs (Circuit) or even completely swapping the maintainer without losing ideological integrity (KGB).

2) All they were developed in parallel, constantly measuring up to each other, borrowing some solutions while seeking different ones to distinguish themselves.

3) ZK was changed on multiple points to specifically accomodate AIs (SkirkishAIMessages for various functions; exposure of critical data as rulesparams). Spring was likewise changed to accomodate these projects (rulesparams reading params and luamessage support). Many of those were done by AI devs themselves but this still requires, and amounts to, engine-game-ai community dialogue.

I think the best way to strenghten the AI scene is social engineering, especially on the community front. A pipe dream scenario would be an AI tourney being declared a month after Steam release, which in this optimistic scenario happens in early Spring 2017. The tourney actually happens in summer or autumn, giving entrants time to build their bots; generating new ai devs and projects and galvanizing the community.

A pessimistic scenario is that such radical growth does not happen, and then the effort should be to maintain the current beneficial climate, keeping the currently active projects alive. Perhaps delaying engine upgrades for moderate grace periods pending on AI compat is one way to achieve that. Perhaps even that is not needed as long as no radical destructive actions are taken.

If you have been watching github (you should if you want your opinion to have a weight bonus) there is a plan for lobby support for AI distribution. This is something that has been desired by many people for a while and is going to improve the climate even further. But to reiterate, this in itself does not mean that a project without maintainers can eternal lie.

quote: It a Spring tradition to render AIs useless the very moment that the AI maker stops frantically patching back into compatibility with the constant engine releases. It would be nice to recognize this is not a good model and that it eventually erodes the motivation of the wonderful people who provide us with robot opponents.

It is a Spring tradition to render everything useless with engine releases. Constant maintenance is required. This is something I like about luaAIs, they rely on the lua interface which I am more likely to notice is broken and more able to fix.

I've found that the important thing is how easy it is for me to fix things. Currently I'm just hoping that the AIs are actively developed. On the engine changes, while we are trying to follow engine development I don't think waiting to fix AIs is useful. If something broke in the engine it is unlikely to suddenly fix itself so you must input some action.

quote: I think that's kind of absurd. AI dev is one of the most difficult and involved aspects of game dev in general, and people without prior experience in lua dev are not likely to be able to do it successfully.

I think you are replying to some statement that claims that all players acquired by ZK through any means in some scenarios are expected to become AI devs.

This is indeed an absurd statement - but not one that i ever made.

quote: It's like ZK experience -> spring dev experience -> AI dev which I don't see happening quickly for anyone.

Do you see Spring Engine and ZK suddenly becoming frozen enough to make AI's stable without any maintenance?

(Perhaps CAI is an example of a stable interface. But i think it also has required some fixing over the years).

If not, you are going to need to maintain them (or have maintainers). You can have those maintainers from two cohorts: AI devs themselves, and Engine/Game devs.

For the efficacy of the latter cohort in maintaining AI projects, you only need to launch Spring with all its bundled AI's and see how many still work.

quote: ; generating new ai devs and projects and galvanizing the community

Realistic, but I wish to add something:

Have a Human tourney running at the same time so those who couldn't build bots, or want to fight humans get a chance.

After the Human and AI victor is chosen, the two will duel each other in maps chosen by PRNG, stable only ofc.

I would like to see this happen. It would be a great goal for many players, go in human tourney and get to top, then fight your AI oppponent, or build an AI strong enough to takedown a human

quote: Building an AI that's actually competitive with circuit or KGB as they stand now is a pretty epic undertaking.

Not to downplay the massive, multi-year amount of work that KGB and Circuit represent, but... cheese exists.

I'm quite suspicious that things like a properly optimized blackdawn rush AI may just wreck both circuit and kgb.

And there are still gaping ability holes in even our strongest AI's that could be exploited, even aside from cheese. Things like combat outcome prediction, terraform logistics, etc.

Parsing the GRP's and other associated boilerplate code is where having a community also helps greatly.

hedgehogs has a point: it would be good to have a game of best AI vs Human at the end of the AI tourney, which would allow us to show how good the best AI is, in a way people can understand better. I'd just pick best human players that we think can lose against the AI and have them play a few games.

aeonios: you don't need to do all these things to start with AI development. Scouting is optional (use cheats), metal spots should be easy to get ( this works well enough: metalSpots = spring.getClb().getMap().getResourceMapSpotsPositions(resource); ), and you really don't need to immediately have the best AI, start small :)

Regarding the first public AI tourney, I'm still of the opinion we should have couple of different categories to compete in: unit micro, simplified game (less units) with full vision, and the normal game. I expect this would make the entry barrier lower, and competition more interesting in general.