I would like to build a new AI Engine

[dj_oldfield]

Providing such access to AI would also enable game mods and cheats to be created which would be unreasonably difficult to eliminate. For example... revealing unit positions, construction orders, and potentially the condition of resources. Further still... such mods would be likely to create sync errors with other clients. Perhaps there is more consideration then I thought that must go into this... as while I desire that it is efficient... I do not wish to present information to the gamer which why are not suppose to have.

What if an AI is selected and shared across all computers, therefore any game mods or cheats would also be shared? Can we make the application so that the host's scripted model is loaded across each client?

Further still, is TASpring prepared to provide a digital signature on validated scripts and mods? Perhaps the game engine can flag scripts which are not "Known Good"... and report this in both the lobby and gametime?

I think that at this point... even supplying the engine will not be enough... if it is liked... there will have to be some serious consideration for modifying sourcecode outside of the game to keep the battles "Balenced".

[jcnossen]

I should think that if I was going to do this, it would make more sense to model it from something that many people are familiar with and has a relatively simular structure.

I have given more thought to modeling it after javascript... and that seems to be a decent approach. JavaScript is a C-Based language... and the heierarchy in Javascript (to some degree) makes sense here. Your top level element would be game I suppose.

If there has to be a scripting language, I think it's best to use one that is used in other parts of spring as well, which is lua. Also LUA is fully stable and documented, while a new scripting language would not be.
This way people don't have to learn 2 new language just to mess around with scripts.

If you want something to do, make a lua interface to the group AI. Group AI is usually not as cpu-intensive as a full AI, so it's really suited for a scripting language. Just a suggestion though.

[dj_oldfield]

As far as having to learn two languages with a single interface... I had no intention of setting up the scripting to handle only one portion of the AI (read previous posts for details)... but instead... one AI that runs on all levels of the software. This means that those using my AI platform would not be using LUA at all.

At the moment... while definately within a spotlight of it's own... Spring is not truly well known enough at this point to assume that there would be a large number of people having to reWrite what they have. On the other hand... javascript is an extremely common language that many people beyond the reach of Spring know really quite well.

Another consideration is my own means. I work as a programmer... have my own private programming projects... and have a family. I don't know much about LUA with exception to it's reach within the code... and that the community here seems to feel like this reach leaves a lot of room for adjustment. If I must first get to know an entirely different application + Spring + extend it's reach... I would be amazed if I would ever be able to release something more useful then what is available. I imagine this limitation exists for many other programmers on this project.

My goal is to make a single project of streamlining all of the unit interoperability into a single collection of classes, and provide a dispatchable template class to enable scripting where needed.

What I have so far
I have built a completely seperate namespace for the moment outside of the taSpring project for the moment. My object model stems from CCritter class (of my own construct) to prevent ambiguis naming. My CCritter component system is slightly more robust and tremendously less "Pre-Defined" then the CUnit infastructure.

My thoughts are...
When I finish... I will probebly innitially test the new system by deriving the CUnit class from the CCritter class. I would then replace all of the member variables with property dispatches... making calls to the baseclass (CCritter) which has a namespace container.

The namespace container that I am building in is 50% of the new AI that I am trying to produce. This actually maps both bytes and text (for testing purposes) to logical instructions within the CUnit model. Individual scripts will be stored (step by step) in the namespace container as well.

A dispatch mechanism will also be provided within the namespace container which will link the instructions to the request, and hopefully(if I can get it to work this time) provide a void pointer to the calling operation to the intended rutine.

All dispatched calls will process the exact same argument list... the variable portion of the parameter list (to replace the functionX operations within LUA) will be stored in a namespace container as well, passed to the target dispatch as a pointer.

All of this having been said... I can't really produce this archetecture and dodge LUA at the same time... hence... I can either try to replicate LUA.. or write a conversion utility when I finish.

Obviously... what we are really conerned about is the end result... which is more symbol driven instead of word driven... therefore... I don't see why there couldnt be a million different languages that could be used. How about... I produce the target symbol format... and one language to go with it... and anyone who wants to can produce a new language to produce it from.

[DeathHawk]

We also need something So we can capture other units without the AI Crashing.

Is that the commmon crash of the Ai at the moment?

[dj_oldfield]

There are generic problems which can cause AI crashs... which will just have to be worked around at runtime... and I can see a couple of entrypoint for gamecrashes beyond this.

Please remember that most of the executable portion of the script is created prior to runtime... which means that when capturing units... there is are some general "Assumptions" which must be made about the existing data model. I have seen AI crashes happen in many cases when the code attempts to retrieve a pointer which is either in use by another module...

Another consideration is how these references get innitialized. They may have been innitialized from a portion of code which used readonly data to create the object, in which case the object in question somehow has attributes which are unexpectedly readonly... Also... depending on the type and usage of the pointer... and the datastructure that it points too... it is possible that the object must be recreated to provide an alternate state... and therefore other references to it would be invalid. I noticed this in C#... when writing a workaround to create a variable length pointer array. I was forced to create a new instance of the target object... nest the array inside of the target's datastructure... copy the data from one object to the other, destroy the origional and replace the pointer to point to the latest version. This seems more time consuming then it is... fyi. Anyway... any other references would be pointing to the old version... and therefore would be stale... and could not be used.

All of these are general code fixes which take time to discover and to repair. It involves tracking the threads through the various intricacies and possibilities to discover possibilities which were not considered durring earlier writes and fixing them.

When it comes to capturing AI with script in the new model... I imagine some of the problems will be solved simply due to a centralized unit management core and centralized unit creation core. The reason is that instead of pointers to the actual objects... will actually be storing logical addresses to the namespace index... which will always retain and manage the one and only copies of all objects. The remainder of the program would interact using the namespacing... and forwarding messages through templated dispatch calls.

EDIT:
I would be utterly amazed though if I didn't have a few hundred hangs and crashes of my own though. These will be fixed over time.

[FireCrack]

So this is a "per unit" ai?

Will you be making it so large groups of units moving dont get caught up on eachother?

[dj_oldfield]

So this is a "per unit" ai?

Will you be making it so large groups of units moving dont get caught up on eachother?

Well lets start out by saying that for the AI to function usefully on a global scale, it must have a fully functional foundation. I believe the biggest problem with the current infastructre is that there is a seperation between the unit command processing and the global AI archatecture. There again, I might be blowing smoke... I have only been fishing source code for a few days, and I could potentially be off base with that assessment.

Lets define a unit in the format that I am currently writing them: (A Critter)...

Codewise... a critter is defined as an object with a variable list of properties, physical dimensions, and a rendering output. Obviously, the units that you interact with would use code... not directly from my Critter object, but instead from another object from which it is derived.

A critter can recieve and dispatch commend text, assess it's environment, define scope, calculate paths, and render visually the actions it is performing.

How is this deffinition of a critter different from how you would define a group of critters under the control of a script or instructionset? Further still, an AI Player also fits this definition as well!

The design of this infastructure is to explose all levels of the game to the same software interfaces, in a manor such that a script can control the features on all levels.

For Example: AI Computer must repeatedly assess it's resource needs...
LOOSE EXAMPLE... NOT ACTUAL CODE
... // Lines of AI Script
if( AVG_POWER_USAGE < POWER_PRODUCTION )
EXPAND_POWER();
... // more AI Script
Global AI_Procedure EXPAND_POWER()
{
... // How much power do I need?
... // Look for shortest time to meet power requirments
... // Find the most accessable builder ( assuming we have created if needed )... and build the plant
me.builders.fastestToReach( point ).build( POWER_PLANT, point, TOP_PRIORITY );
}

... // triggers the units AI Script when called...
... // which will plot a course... and yadda yadda yadda
... // if the unit finds another unit in it's way...
if( units_in_path( MY_PATH ).length >0 )
{
for( var i=0;i<units_in_path( MY_PATH );++i );
{
if( units_in_path( MY_PATH ).units.distance( MY_POSITION ) <=3 )
if( !units_in_path( MY_PATH ).units.clear( MY_POSITION, MY_PRIORITY ) )
{
MY_PATH = plot_course( MY_POSITION, MY_TARGET, MY_PRIORITY );
break;
}
}
}
EDIT:
Then the units automation scripts are called by these procedures:
... // SET_DIRECTION( x );... ETC...

so yes... this will control units on all levels.

[Triaxx2]

Well lets start out by saying that for the AI to function usefully on a global scale, it must have a fully functional foundation. I believe the biggest problem with the current infastructre is that there is a seperation between the unit command processing and the global AI archatecture. There again, I might be blowing smoke...

*pokes AF*

Told you so.

[Min3mat]

nice list

[SwiftSpear]

sooooo hawt. Make it possible mr oldfield.

[dj_oldfield]

The processor in my Good Workstation blowd up yesterday... needless to say... it is not my good worstation anymore. Ill have a new one today... and Ill be getting back on it shortly.

that sukd

[jcnossen]

We also need something So we can capture other units without the AI Crashing.
Is that the commmon crash of the Ai at the moment?

It's not the common crash, because capturing and giving usually doesn't occur very much.
However I have added a proper callback call in the current spring cvs,so it can be detected in a clean way. See the cvs changelog (located in text\changelog.txt on the repository) for some info about the AI callback changes.

dj_oldfield:
What is wrong with the current setup then? Apart from unfinished AI's I have no problem with how things are right now. And when I find something that restricts me I start extending or modifying existing code. But rewriting all the AI code takes a lot of time. Mainly it's going to be your time, but for a part of it it's going to be us current AI developers too who have to support and modify our existing code to this new framework.

Everything you said you wanted in the first post, can be accomplished by improving current code.

1. The introduction of pattern scripting
2. I would like to add unit action priorities
3. I wish to expand this technology to include AI Computer opponants
4. These Scripts would also enable game mods to include new tool bar options (simular to those like "Guard") as well as more advanced unit mods.

1. I think this is very well possible to accomplish by using and improving group AI/group AI interface. If you want it scripted, a very simple script could suffice.
2. Extend the unit code.
3. Guess what cain, submarine, AF, triaxx2, alik, myself, and probably someone else i forgot are doing right now... There will be/are scriptable AIs in those, and they are still under development.
4. Yet again, make it possible with the current code, I think that's much faster.

By saying you're going to rewrite half of spring, you're basically ignoring the fact that there is a whole group of developers here who are working very hard on many aspects of spring. Refactoring is good, but throwing away fully working code isn't.

[BvDorp]

that's a pity! Well, goodluck with your project. I think there is not much need of an extension of GroupAI, for ppl feel like they should do stuff themselves too, otherwise it's just that players learn to 'manage' GroupAI well, and don't actually play the game :)

As I said, goodluck, and I hope you and the other AI developers make a nice team

BvDorp

Edit: Err.. posted before I read Zaphods' post

[Richie P]

If somone allows for the scripting of AI through CLI assemblies I'll be very happy. Or just a CLI interface to the GlobalAI maybe

[AF]

I'm not sure I want to code in another scripting language. C++ is fast, and efficient, albeit with it's memory management issues that've been my downfall, but experience is slowly correcting that.

My point was if we have AI scripts I'd like to access them from lua mod scritps and lua unti scripts or unti mission scripts aswell as my AI, and I dont want to throw away ym C code and rewrite for another scripting engien ro spend time converting things.

I think a small very quick scripting engine is neeeded, it would be useful for config files etc rather than lengthy parser code that only works for a set pattern of code, such as Zaphods config loader or my longwidned OTA AI loader.

And yes AI is sorta split up, we have our groupAI and GlobalAI interfaces and what we do, then we have the sub-AI command structrue which deals with other thigns such as autorepair, reclaiming features that get in th way etc. The only tie between these 2 systems is cb->GiveOrder() GetUnitCommands and the pathfinder callback functions.

What triaxx is poking me for I dont know. And zaphod, veylon was the one you forgot.

While I am happy for anything that improoves the stability of AI itnerfaces foundation, or adds extra foundations to work on such as an alternative itnerface with better functionality, I'd like that.

Binding the CAICallback class to lua is very easy using luabind, but I wont do it myself. Look at how fnordia binded the current functions and you'll se ehow easy it is.

And aside from that it would be nice to have a CLI in the spring engine other than the info console, one that was bidned to the scripting engines too.

And for GroupAI, there is a limit to what you can do in those terms fo people not doing anything. Just look at what the current AI are capable of, any human could do each respective task better, but the AI has much faster reaction times and doesnt need to mvoe a mouse, and can calculate thigns that a human cant within milliseconds.

Any decent player could outdo another player who used GroupAI for anythign but meneal tasks such as keeping units in formation or cotnrolling pathfinding or controlling metal makers.

I think the more important part is the fact GroupAI is written in C++, so you could call on other itnerfaces such as creating windows to diaply extra information, logging data, etc.

[jcnossen]

I think a small very quick scripting engine is neeeded, it would be useful for config files etc rather than lengthy parser code that only works for a set pattern of code, such as Zaphods config loader or my longwidned OTA AI loader.

My old config parser sucked, but the one used in 0.20 is very flexible, and I will be adding a rule-based system to it that will allow basic unit scripting.

[AF]

interesting, but it doesnt have the nice bits of speed a stack based VM running off of bytecode has if it just parses text straight off, and it's written specifically for JCAI config files?

[dj_oldfield]

Zaphod:

By saying you're going to rewrite half of spring, you're basically ignoring the fact that there is a whole group of developers here who are working very hard on many aspects of spring. Refactoring is good, but throwing away fully working code isn't.

I never said that I was going to rewrit half of spring. I don't have much time to respond to the rest of you... but this caught my attention.

I have no intention of rewriting TASpring... half, ten percent, or all of it. The proposal involved the introduction of code to the system.

As far as extending the capabilities of LUA... it essentially comes to the same. The only true distinction is that I have to spend more time getting to know what's there... which I am already doing with respect to what I am doing anyway.

Ill respond to the rest when I return.

[jcnossen]

Ok sorry then, I drew my conclusions a bit too quick.
If I get your ideas right, part of it is to add a base class (CCritter) with a generalised property system, so that script could use this system. If you don't want to rewrite a lot of unit AI code, you'll have to add properties for all the current unit state, and connect them to the C++ member variables, so the current code still compiles pretty much without changes. This could be done ofcourse, and now that I think it thru it's seems a good idea , so that previous post doesn't make a lot of sense anymore

interesting, but it doesnt have the nice bits of speed a stack based VM running off of bytecode has if it just parses text straight off, and it's written specifically for JCAI config files?

I'll probably use a small VM for it, the parser will have to pre-parse the code anyway to do error checking, so it's quite easy to load the opcodes into memory at the same time. Before I started with spring I've made a script compiler myself, so I should have no problems with creating a limited vm for this purpose.
Btw, if you think lua has a fast vm, see how they implemented operators Ofcourse this is a tradeoff with dynamic typing, but it is quite slow I presume.
Ok im getting offtopic now....

[dj_oldfield]

If you don't want to rewrite a lot of unit AI code, you'll have to add properties for all the current unit state, and connect them to the C++ member variables, so the current code still compiles pretty much without changes.

Yes... this is very much the intention of what I wanted to accomplish with this. I felt that enabling these objects for a dynamic form of linking would increase the potential of the AI. Obviously the system would be robust enough to support all of the AI infastructure... but it would also enable the existing model to run instead... atleast until we find better uses.

When I was looking at LUA... I just didn't like the way that they went about their attempt to make the generic interfaces... using function templating for all of the possibilities given the procedures. It seems to me that most of the cpu burn is really durring compile time which is no loss considering that most people will be using this post-compile... but the real problem that I see is that it does not really shape to the data that it carries... and appears that you would have to do recompiles with new AI Scripts (bare in mind... there are millions of lines of source code in this application... so I am uncertain if that statement is completely valid).

I think that the largest benifit is that we can increase the diversity of units bothin in behavior and properties. Further still... I think that it would extend the reach of the AI scripting... so as to improve the overall gameplay... and prevent units from "Acting like dumb@$$s".

This is actually my best hack at making a simular modal to Microsoft's ActiveX structure...which is the mode of programming that I am most familiar with. My goal is to model the scripting technology to support the same robust archetecture.