OpenRA

(This may be a premature announcement. All things you see here should be considered a Work-in-Progress, Not-Ready, Building-in-Progress, as-is and is subject to change at any time.)

I am currently developing a mission-compatible AI powered solely by Lua scripting. The aim is to include features seen up to Red Alert 2, with flexibility of extension using the arsenal of Lua language.

I make this post so that you can see parts of it in action, and so that I can hear some preliminary feedback on what you'd like to see used by the AI. You can also discuss how some logic should be implemented / how far the OpenRA engine can implement certain functions.

I may not be able to accept or follow all suggestions, but I would at least have an idea on the logic that would be valued by the community. There may also be some ideas I have missed.

Planned scope:

• General Controls
  • Yaml-independent controls
    • Prerequisites
    • Cost
    • BuildTime
• AI Base Building
  • Base Nodes
  • Building prioritisation (e.g. prioritise Ore Refinery on certain conditions)
• AI Unit Production
  • Unit production weights
  • Unit prioritisation (e.g. prioritise Ore Trucks / units requested by AI Teams)
• AI Teams (functionality up to RA2)
  • AI taskforces
  • AI team condition check (can be used to impose certain restrictions on which teams can be built)
  • AI scripts (sequential)
    • Implemented: Hunt, AttackMove, Move, Guard, Wait
    • WIP/Considering: EnterTransport, UnloadTransport, Deploy, Kill, Teleport, Chronosphere, IronCurtain(?), Capture/Infiltrate, DisguiseAs, JumpToScript#
    • (Aircraft compatibility may be limited in some scripts)
  • AI reserved teams
    • Pool - Default team used to receive / transfer actors to other teams
    • Hunt - Kill everyone!
    • Defence - Defend certain actors when they are under attack. Can customised to include defending allies.
• Compatible with ground / aircraft
  • Navy compatibility is WIP
  • Separation of Ground / Navy is WIP
• WIP: Some kind of documentation and API for simple implementation, and so that folks to not completely get demoralised by a fail.

A preview of my current work (a logic and performance stress test with 6 AIs) can be seen here:
http://resource.openra.net/maps/20159

Earlier versions with less features can be found with some example missions:
http://resource.openra.net/maps/19878/
http://resource.openra.net/maps/19901/
http://resource.openra.net/maps/19912/

Note that this is WIP, major refactorings and rewrites are expected. Read / use the existing code at your own risk.

Hooray! AI work!

I approve. I hope I will find time the following days to give this a test, but it's always good to see that someone is willingto do some work on the dated AI.

Awesome! As someone who is dabbling in creating missions in his spare time, I absolutely endorse any kind of improvements to the AI. Keep up the good work!

Before I plan to start working on actual features for the AI, I will have to work on the base level stuff and begin a first refactor to make the code more friendly. This includes:

• Creating a required/optional function call infrastructure to generate logs, catch and handle exceptions, then re-link every important function to it.
• Standardize LuaTable macro functions in utilities.lua
• Standardize all 'registry' tables:
  • ActorRegistry (currently handles prerequisite checks), to also handle an Actor's script triggers, attachments to other LuaTables, and other settings when an Actor is 'registered'.
  • MasterTables.Production, to standardize between building and unit 'rule' definitions.
  • BaseNodes (global base node list), still trying to figure this out
  • ActiveProductionTables, to allow each Construction Yard to have its local base node list.
• Rethink Base/Unit Production process flow to be compatible with both RA-style and TD-style queues.
• Create a list of API calls for safe execution of user extensions for basic functions.

There is already some obstacles along the way, since OpenRA imposes restrictions on Lua functions I can use. I have yet to be able to use the _G global table, debug.info, and coroutine (these are what I can remember off the top of my head). This mostly impacts debugging, error handling and performance (e.g. I might want to find a way to manipulate Tick() to defer functions to the next Tick() before exceeding Lua quota). This should not affect the AI logic itself.

Work on actual game logic will resume when the base scripting and refactoring are at higher levels of completion.

The current status of this endeavor is still WIP and may be expected to take until at least end April.

Hey, how is your project on LUA AI going? Any stops or is everything going smoothly?

This would be the best thing coming to OpenRA after sliced bread. With something like this we could hold an accessible A.I. scripting tourney, which would be all sorts of awesome.

In terms of features, it would be nice if the AI could be conditional in terms of enemy units, and "cheat": e.g. if the opposing team has mostly infantry, it starts using a build with more artillery, it only starts building anti-air when there are airfields etc.

I think cheating isn't the challenge there, it's the other way around^^. Reading the game state should allow you to count units (visible or invisible), but telling the AI to only count visible/discovered units and ASSUME what the enemy has is a lot harder.

So would be wise to start with the cheating AI ;P

Oh yeah, a bot-bashing tournament would be so awesome

I want to point out strong players with good game sense can spot things invisible to them so AI cheating and seeing amount of enemy units is not as OP as it sounds.