C++ AI SDK
Moderators: hoijui, Moderators
C++ AI SDK
Is it possible to have an SDK generated automatically that includes just the files needed for C/C++ AIs to build on new release? Rather than lugging around an entire spring source folder?
- hughperkins
- AI Developer
- Posts: 836
- Joined: 17 Oct 2006, 04:14
Re: C++ AI SDK
I'm so tempted to reply "And: a pony
", but I decided if I did that, I'll have to put up with similar replies to my own threads :-DDD
It sounds like a good idea.
Actually, along similar lines, I was thinking that some kind of AI middleware could be quite interesting, so that not every AI has to write its own pathfinder, mapping algorithms and so on...
Obviously, I'd most prefer such a middleware to be Java-based
but it's all good...

It sounds like a good idea.
Actually, along similar lines, I was thinking that some kind of AI middleware could be quite interesting, so that not every AI has to write its own pathfinder, mapping algorithms and so on...
Obviously, I'd most prefer such a middleware to be Java-based

Re: C++ AI SDK
a simple Java SDK can be created with the ant file of the Java AI Interface already. if ppl start to use it, and want further stiff added, ill try my best.
the same could be done for C++, though it would have to be for hte new interface.
i always said i will not be going to make a new interface, but nobody else did anything. so i started it, and got quite far. only one guy tested it so far, as much as i know. i am not very interested in pushing C++ stuff, and i will never use that interface myself, so if you want ot use it, you may put some work into it.
Hugh:
i like your ideas, though i think they should be integrated into the C interface, as they will be available ot all AIs then. The C interface already allows accessing the path finder of the engine. I can understand that you may want an other one, eg one taking a thread map into account .. i never write an AI, so i dont really know what you guys want. but if you work together with me, suply algrithsm, nad give a clean interface, we could integrate it into the interface/engine, and make it available to everyone.
the same could be done for C++, though it would have to be for hte new interface.
i always said i will not be going to make a new interface, but nobody else did anything. so i started it, and got quite far. only one guy tested it so far, as much as i know. i am not very interested in pushing C++ stuff, and i will never use that interface myself, so if you want ot use it, you may put some work into it.
Hugh:
i like your ideas, though i think they should be integrated into the C interface, as they will be available ot all AIs then. The C interface already allows accessing the path finder of the engine. I can understand that you may want an other one, eg one taking a thread map into account .. i never write an AI, so i dont really know what you guys want. but if you work together with me, suply algrithsm, nad give a clean interface, we could integrate it into the interface/engine, and make it available to everyone.
- hughperkins
- AI Developer
- Posts: 836
- Joined: 17 Oct 2006, 04:14
Re: C++ AI SDK
hoijui,hoijui wrote: Hugh:
i like your ideas, though i think they should be integrated into the C interface, as they will be available ot all AIs then. The C interface already allows accessing the path finder of the engine. I can understand that you may want an other one, eg one taking a thread map into account .. i never write an AI, so i dont really know what you guys want. but if you work together with me, suply algrithsm, nad give a clean interface, we could integrate it into the interface/engine, and make it available to everyone.
The issue with having stuff on the C++ side of the Java interface is that the jna boundary is unfortunately not super speedy. I think that Sun did this partly on purpose to discourage native code use.
Whatever the reason, once data is on the Java side of the boundary, it is super fast to use and process.
Re: C++ AI SDK
I dont think they did this on purpose, as they have ot use it htemselfs.. its rather for hte many checks they do. maybe it is possible to tweak it to be a lot faster, in return to less security *as in virus spreading or accidential data corruption).
The reason does not really matter though, you are right there i guess. Still it would be nice to have a nice performance tool; maybe we could make it much faster.
One way that always works, is designing tools/algorithms/interfaces so that the data transfer has to be minimal, if that is possible :D. For example, the metal spot finding algorithm: you call it, and it goas through much number crunching, and in the end returns a list of float3's. in such a case, the JNI slowness would not matter much, as it is a one time function, of which the JNI overhead will always be a tiny fraction of the runtime only.
Its your decission anyway. If you see it could be done in a way like the above mentioned, or that it can be split in such a part and an additional one, and you dont mind coding one of the two in C/C++, then it would be nice if you could do so.
just saying ..
:D
The reason does not really matter though, you are right there i guess. Still it would be nice to have a nice performance tool; maybe we could make it much faster.
One way that always works, is designing tools/algorithms/interfaces so that the data transfer has to be minimal, if that is possible :D. For example, the metal spot finding algorithm: you call it, and it goas through much number crunching, and in the end returns a list of float3's. in such a case, the JNI slowness would not matter much, as it is a one time function, of which the JNI overhead will always be a tiny fraction of the runtime only.
Its your decission anyway. If you see it could be done in a way like the above mentioned, or that it can be split in such a part and an additional one, and you dont mind coding one of the two in C/C++, then it would be nice if you could do so.
just saying ..
:D
Re: C++ AI SDK
Oh I'm not talking about the new C++ API library, I just mean a package with the C API headers, the legacy cpp wrapper, any spring headers needed, and any utility classes.
One should be able to unzip the package along with vclibs/mingwlibs and simply press build. No great big spring folder, just a folder containing your AI code, a folder containing just the spring headers needed, and your IDE.
One should be able to say "This is my AIs source code and dependencies, open the project and press build", no faffing around with git repositories to get spring, worrying about which version of springs interface it will build with, or the accompanying weight of spring and all its dependencies.
For example, one could probably take KAIK and distribute everything needed to develop it in a zip under 200kb
One should be able to unzip the package along with vclibs/mingwlibs and simply press build. No great big spring folder, just a folder containing your AI code, a folder containing just the spring headers needed, and your IDE.
One should be able to say "This is my AIs source code and dependencies, open the project and press build", no faffing around with git repositories to get spring, worrying about which version of springs interface it will build with, or the accompanying weight of spring and all its dependencies.
For example, one could probably take KAIK and distribute everything needed to develop it in a zip under 200kb
Re: C++ AI SDK
yeah.. thing is, the legacy interface is legacy/deprecated, and if anyone would put work into something, it should be into the new interface, not the old one.
also, hte old one has a lot of dependencies on headers all around spring, while the new one only depends on headers in rts/ExternalAI/Interface, and two headers only containing #define's from rts/System.
also, hte old one has a lot of dependencies on headers all around spring, while the new one only depends on headers in rts/ExternalAI/Interface, and two headers only containing #define's from rts/System.
Re: C++ AI SDK
Work? No actual editing of the files themselves should be necessary. Simply having a folder labeled SDK with the files inside in the same folder structure as they would normally be should suffice. If something like this could be autogenerated and packaged every spring release.
- LoidThanead
- Posts: 58
- Joined: 27 Feb 2008, 16:16
Re: C++ AI SDK
hughperkins wrote:Actually, along similar lines, I was thinking that some kind of AI middleware could be quite interesting, so that not every AI has to write its own pathfinder, mapping algorithms and so on...
Obviously, I'd most prefer such a middleware to be Java-basedbut it's all good...
I'm working on a JavaAI wrapper that is intended to do exactly this. I have not yet worked on pathfinding, but so far it contains a mechanism to control units more easily: unit.moveTo(pos) instead of this.callback.getEngine().handleCommand(AICommandWrapper.COMMAND_TO_ID_ENGINE, -1, new MoveUnitAICommand(this.unit, -1, new Vector<AICommand.Option>(), 1000, position).
It also contains modules that handle construction of units, so that you can simply tell the AI to build a specific unit at a position and it will find the nearest available unit capable of building it and give the build order.
It shouldn't be too hard to set up a git repository for this if people are interested in testing or adding stuff.
Re: C++ AI SDK
How to do what I requested by hand:
Take a spring folder, and start deleting files that have nothing to do with AI. When only the AI interface, the legacy C++ wrapper and the necessary spring headers to support it remain, package and upload.
Why I started this thread?
I cannot be arsed spending an hour every single time spring is released redoing this tedious work from scratch and testing, when it could easily be done automatically by a tool.
Take a spring folder, and start deleting files that have nothing to do with AI. When only the AI interface, the legacy C++ wrapper and the necessary spring headers to support it remain, package and upload.
Why I started this thread?
I cannot be arsed spending an hour every single time spring is released redoing this tedious work from scratch and testing, when it could easily be done automatically by a tool.