While I believe that I could add a great deal of functionality to the AI portion of this game, I am aware that many of you have already written AI utilities as well, so your feedback would be helpful. The idea of this AI engine is to expand units to be more industrius... and to provide more meaningful runtime Intelligence then other games (Including TA). Among these features would be:
1. The introduction of pattern scripting... where you could queue up a multi-building plan instead of object placement of single building at a time (I am aware of the shift click concept... but sometimes it gets monotinous... Anyone played TA with that TAUCP Expansion? Laying out 20 nano-lathe pads and queuing up the nanolathes and so on? ). This may also be considered one of the skill parts of the game... so that may be a touchy issue.
2. I would like to add unit action priorities... where you can select (for example) that constuction units should move out of the way of a military unit... if you wish to insure that military units can enter battle rapidly. It gets annoying if you are trying to dispatch units from several parts of the map... just to find out that some idiot is making a traffic jam.
3. I wish to expand this technology to include AI Computer opponants... as well as Schenario construction... hopefully if anyone can create text based computer AI scripts... I won't have to battle 3 computers at a time to get a challenge :).
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.
The draw back would be that many of you who have created AI scripts may need to have them converted... but I can probebly make a tool for that also. On the up side however... perhaps a fresh approach to computer AI Capabilities may prove to enable more challenge and possibly provide some unique new commands which were not possible prior to this.
I would like to build a new AI Engine
Moderators: hoijui, Moderators
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
mmmm, working AI...
I don't know if it would be very fair to some people, but it would be great if we could define our own AI combat scripts that our units load. Might have to be restricted, but it would be a great oppertunity to really experiment with micromanagement tactics from a practical AI standpoint.
I don't know if it would be very fair to some people, but it would be great if we could define our own AI combat scripts that our units load. Might have to be restricted, but it would be a great oppertunity to really experiment with micromanagement tactics from a practical AI standpoint.
-
dj_oldfield
- Posts: 71
- Joined: 24 Oct 2005, 07:10
is anyone actually familiar with the source code here?
While I think that I am going to work on key assignments first... the AI thing is just something that I have wanted to try forever... but I am not going to write an ENTIRE GAME to myself. This just gives me a unique opportunity to do what I want to do without having to do something TOO BIG!
Anyway... I don't assume that I can make the AI SMART... I just hope to make it robust... so that you guys can use a notepad to make it SMART
I mainly need to know where I would be crossing the line/unbalencing the game... and I would really like to connect with others who have worked with this source code in hopes to focus my attention on the correct files! (For those of us who have downloaded the source code... you may have already noticed that it is a very massive program).
Either way... I play TA and games like it all the time... and I have this massive list of things that I have always wanted from such games that were not there. This should be an adventure if nothing else!
Anyway... I don't assume that I can make the AI SMART... I just hope to make it robust... so that you guys can use a notepad to make it SMART
I mainly need to know where I would be crossing the line/unbalencing the game... and I would really like to connect with others who have worked with this source code in hopes to focus my attention on the correct files! (For those of us who have downloaded the source code... you may have already noticed that it is a very massive program).
Either way... I play TA and games like it all the time... and I have this massive list of things that I have always wanted from such games that were not there. This should be an adventure if nothing else!
-
dj_oldfield
- Posts: 71
- Joined: 24 Oct 2005, 07:10
... HOW FUNNY
I think that there is one fix that I wish to do immediately! I have located the Camera functionality... and I think that I wish to change some of the camera controls... they are driving me BONKERS!
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Re: ... HOW FUNNY
I'd be happy if the up/down simply was inverted in FPS view... I can't stand having to move the opposite way I'm used to from normal FPS.dj_oldfield wrote:I think that there is one fix that I wish to do immediately! I have located the Camera functionality... and I think that I wish to change some of the camera controls... they are driving me BONKERS!
-
dj_oldfield
- Posts: 71
- Joined: 24 Oct 2005, 07:10
yea... that kinda got on my nerves too...
programmers note
I think that I am going to write a dispatch template class and and try to enable all of the embedded classes to type them and link commands. This way, hopefully I can build something that will allow us to link in other controls as well. My worry is that it might create an entry point for cheating though, so perhaps some suggestions would be useful.
What I basically wanted to do was enable dispatch IDS for all of the functions within given classes (for example... the camera class would have dispatch IDS for all of the methods it supports... thereby enabling the current settings to be overridden by a file. Then each user can manage their own controls for the camera. I was going to continue on however... to link the CUnit class and others in the same way... so that the AI scripting would have a simular entry point. Problem being... it allows access to the data infastructure supporting units, radar, etc. I fear that this perhaps may enable applications to exploit that to reveal information about units that should not be revealed.
I think that I am going to write a dispatch template class and and try to enable all of the embedded classes to type them and link commands. This way, hopefully I can build something that will allow us to link in other controls as well. My worry is that it might create an entry point for cheating though, so perhaps some suggestions would be useful.
What I basically wanted to do was enable dispatch IDS for all of the functions within given classes (for example... the camera class would have dispatch IDS for all of the methods it supports... thereby enabling the current settings to be overridden by a file. Then each user can manage their own controls for the camera. I was going to continue on however... to link the CUnit class and others in the same way... so that the AI scripting would have a simular entry point. Problem being... it allows access to the data infastructure supporting units, radar, etc. I fear that this perhaps may enable applications to exploit that to reveal information about units that should not be revealed.
There is an option 'Invert Mouse in FPS veiw' in the Settings program. One of the check-boxes in the middle. That option is already taken care of.
And an easier and better way to get the source code is through the CVS System. The CVS code is (apparently) updated daily, so anything on there is very up to date, where (IIRC) the source on the Downloads page is out of date, possibly by a few versions.
Tutorial on using the CVS: http://taspring.clan-sy.com/wiki/CVS_tutorial
Spring CVS Page: http://cvs.sourceforge.net/viewcvs.py/springrts/
Appologies if your already using the CVS, just doent appear that way from what youve said.
And an easier and better way to get the source code is through the CVS System. The CVS code is (apparently) updated daily, so anything on there is very up to date, where (IIRC) the source on the Downloads page is out of date, possibly by a few versions.
Tutorial on using the CVS: http://taspring.clan-sy.com/wiki/CVS_tutorial
Spring CVS Page: http://cvs.sourceforge.net/viewcvs.py/springrts/
Appologies if your already using the CVS, just doent appear that way from what youve said.
-
dj_oldfield
- Posts: 71
- Joined: 24 Oct 2005, 07:10
Cool... Ill bookmark that
You are right to assume that I am not using the most up to date one... the page that I downloaded the source from suggests that it was actually a couple weeks old.
Either way... I downloaded this Boost program and moved the files in to find out that I need to retrieve the propert boost configuration files for this platform... I gather that most of you are familiar enough with Boost to have already had the said configuration. I have never worked with it... but it seems pretty cool...
I think that I might end up spending more time getting this to compile with boost then I will getting some of these things going on the programming end...
Either way... I downloaded this Boost program and moved the files in to find out that I need to retrieve the propert boost configuration files for this platform... I gather that most of you are familiar enough with Boost to have already had the said configuration. I have never worked with it... but it seems pretty cool...
I think that I might end up spending more time getting this to compile with boost then I will getting some of these things going on the programming end...
I like this idea, although bases might get very similar if people start using prefab constructions. This depends on the complexity of the script ofcourse.1. The introduction of pattern scripting... where you could queue up a multi-building plan instead of object placement of single building at a time (I am aware of the shift click concept... but sometimes it gets monotinous... Anyone played TA with that TAUCP Expansion? Laying out 20 nano-lathe pads and queuing up the nanolathes and so on? ). This may also be considered one of the skill parts of the game... so that may be a touchy issue.
You realise that the current AI's are beta if not alpha? Challenge will improve anyway. And an AI is more than a building script.3. I wish to expand this technology to include AI Computer opponants... as well as Schenario construction... hopefully if anyone can create text based computer AI scripts... I won't have to battle 3 computers at a time to get a challenge :).
You just seem a little overambitious, I'd say take one step at a time, then people tend to take you more serious.
Okay, first of all I'll repeat it here, you don't have to fix the cammera, jut press SHIFT+J (more info http://taspring.clan-sy.com/wiki/Using_ ... a_Controls)
and since no one else has bothered, there are 2-ish interfaces for AI, there is group AI (you can see this in game by pressing CTRL+Q in game and selecting an AI from the list, the metal maker AI turns of MMs if you are out of energy fore example, and there's one for building a base...) in theory you could build a script loading interface that players could customize with a text file and then choose in game using this interface.
The second is custom DLLs that interact directly with the execution of the program, I would assume that if you can make it do things stable (unlike the other ones) and push the interface out to read a text file instead of having it hard coded into the interface that you could achieve this goal...
EDIT:
ALso, there is a new GUI hidden in the source code that can be included at build time... apparently, if you can find jounikimbo (solely in charge of this department) he might let you help.
and since no one else has bothered, there are 2-ish interfaces for AI, there is group AI (you can see this in game by pressing CTRL+Q in game and selecting an AI from the list, the metal maker AI turns of MMs if you are out of energy fore example, and there's one for building a base...) in theory you could build a script loading interface that players could customize with a text file and then choose in game using this interface.
The second is custom DLLs that interact directly with the execution of the program, I would assume that if you can make it do things stable (unlike the other ones) and push the interface out to read a text file instead of having it hard coded into the interface that you could achieve this goal...
EDIT:
ALso, there is a new GUI hidden in the source code that can be included at build time... apparently, if you can find jounikimbo (solely in charge of this department) he might let you help.
mwha, you're saying a lot of stuff and I'm not in the best frame of mind at th moment so I'll go ahead.
In AI atm, I cant queue a row of buildings or multiple untis in a factory or dot he equivilant of shift clicking with buildigns to create command queues.
NTAI has to use tasks, and wait for the task to finish before doing the next one along, adding the shift option tot he command structure simply makes the engien do absolutely nothigna dn the command si never executed at all.
When tryignt o give commands to a factory, I give ti however many commands and it doesnt always do them. EG I set NTAI to give adv kbto labs the following:
1 adv con
5 pyros
1 can
3 morties
1 necro
Upon seeing this the engien queued up an adv con a can and a necro instead. I had to fiddle the numbers to get ti to build at least 1 of every unti I asked.
This is all very annoying for me to see code that ahs no problems with ti not doing what it's supposed todo even though it should work when you go through it, possibly reimplementing it and seeing the same results.
I welcome any improovement to the AI interface, more information and more control is a must, however I dont want to be changing my AI extensively to suite it.
For one combining AI and groupAI dll's into one or allowing multiple groupAI in a single dll would be nice.
This slowdown may be ok for the odd function or class but for the entire AI it is a problem.
Your pattern placement is the equivilant of build designs at darkstars essentially.
And otherwise I suggest the new GUI handler simply give the lua interface an interface to add GUI controls. That would do the bit you said in point 4 too.
Also, computer controlled players arent a challenge because we've made nowhere near the progress we can make yet. As time goes by these simple AI's that we ahve now will get better and more complex. eg.g see how I described TAI at darkstars and compare it to how NTAI is structured atm, they're different, NTAI is far simpler and eaker than the proposed TAI, and NTAI will eventually be the TAI I proposed and thus be a lot stronger than it is today.
Also would I be right in saying then that you could be the 5th AI project? (1:JCAI 2:NTAI 3:ZcAIn 4:5Matrix).....
In AI atm, I cant queue a row of buildings or multiple untis in a factory or dot he equivilant of shift clicking with buildigns to create command queues.
NTAI has to use tasks, and wait for the task to finish before doing the next one along, adding the shift option tot he command structure simply makes the engien do absolutely nothigna dn the command si never executed at all.
When tryignt o give commands to a factory, I give ti however many commands and it doesnt always do them. EG I set NTAI to give adv kbto labs the following:
1 adv con
5 pyros
1 can
3 morties
1 necro
Upon seeing this the engien queued up an adv con a can and a necro instead. I had to fiddle the numbers to get ti to build at least 1 of every unti I asked.
This is all very annoying for me to see code that ahs no problems with ti not doing what it's supposed todo even though it should work when you go through it, possibly reimplementing it and seeing the same results.
I welcome any improovement to the AI interface, more information and more control is a must, however I dont want to be changing my AI extensively to suite it.
For one combining AI and groupAI dll's into one or allowing multiple groupAI in a single dll would be nice.
I believe these scripts would use a stack absed script interpreter, I think binding lua would be the answer to that, and would or already provides a lot fo what you said. I also note that any AI written in lua versus c++ would have a considerable slowdown which we cannot afford.3. I wish to expand this technology to include AI Computer opponants... as well as Schenario construction... hopefully if anyone can create text based computer AI scripts... I won't have to battle 3 computers at a time to get a challenge :).
This slowdown may be ok for the odd function or class but for the entire AI it is a problem.
Your pattern placement is the equivilant of build designs at darkstars essentially.
And otherwise I suggest the new GUI handler simply give the lua interface an interface to add GUI controls. That would do the bit you said in point 4 too.
Also, computer controlled players arent a challenge because we've made nowhere near the progress we can make yet. As time goes by these simple AI's that we ahve now will get better and more complex. eg.g see how I described TAI at darkstars and compare it to how NTAI is structured atm, they're different, NTAI is far simpler and eaker than the proposed TAI, and NTAI will eventually be the TAI I proposed and thus be a lot stronger than it is today.
Also would I be right in saying then that you could be the 5th AI project? (1:JCAI 2:NTAI 3:ZcAIn 4:5Matrix).....
-
dj_oldfield
- Posts: 71
- Joined: 24 Oct 2005, 07:10
I am replying to the masses here...
Zaphod:
All programmers are a bit overambitious... we like to see our work when we run a program...it is just our nature. As far as how seriously people take me... words are never as serious as work, and therefore I suspect that I am currently little more then a voice at the moment. My intention when posting these ideas was not to be taken seriously... but to gather all of the information that I can so that what I produce does get taken seriously.
SinbadEV:
I guess I missunderstood whenever you mentioned the camera controls prior... or perhaps I did not entirely notice the body of your message. Thank you for the information on the cameral. This is a very large program and sometimes it is the simplest things that get overlooked... I definately was surprised at my earlier conclusion that that prior camera mode was all that there was.... but it would have taken a while to figure out otherwise. Thanks again for the info... gameplay is much better as a result.
as far as the GUI is concerned... that was more for selfish reasons. I definately was not excited about the idea of working on it... I just saw that as an area in need of work, and there was a request for GUI assistance in the documentation supplied with the source code. I wanted to fix it to improve my own experience with the game.
Alantai Firestar:
I suppose that my suggestion that I was writing a full AI was a bit bold... but instead I would like to write some supporting infastructure to manage commandsets a bit tighter... which would fix the problem of build orders not working and other such things. I wanted to expand these commandsets to function as a language of their own (I actually have a lot of experience writing simple script engines for various types of programs). The idea would not neccessarily hurt performance... as I believe that this depends on the condition of the script at runtime...
I have no intention of having the engine parse text at runtime... but instead I wish to (loosely speaking... this may actually have to be done when saving the script) load an object model into memory which closely resembles the script. The only additional CPU overhead that I can predict would be dispatching procedure calls within the objects themselves... which I could get around if I could manage to get void pointers working correctly. I have never managed to get those working the way that I wanted them too... but if I could, I figured that I could buid a mapping utility which will map the units basic commands to a single dispatch engine... and have the dispatch engine handle everything from the micromanagement of individual steps... to unit commands given by the player... AI Build scripts and more.
Finally... the text parser itself would enable commands to interoperate just as they would in an ordinary programming language... hence... you have your Master AI file which (is probebly going to be stored in a compressed binary format to address the need for fast load times)... but this innital file can be replaced or expanded into incorporate new functional ideas.
As I have seen from the codebase... there is no real need to get too much into the actual gaming engine to work on this... as from what I see... that part works fine. It seems as though this is something that I can do simply by adding supporting classes... and proposing the introduction of new code into various classes within the system.
Either way... please continue your feedback... as it has been most valuable in learning my way around this code... and the game itself.
-- Dave
All programmers are a bit overambitious... we like to see our work when we run a program...it is just our nature. As far as how seriously people take me... words are never as serious as work, and therefore I suspect that I am currently little more then a voice at the moment. My intention when posting these ideas was not to be taken seriously... but to gather all of the information that I can so that what I produce does get taken seriously.
SinbadEV:
I guess I missunderstood whenever you mentioned the camera controls prior... or perhaps I did not entirely notice the body of your message. Thank you for the information on the cameral. This is a very large program and sometimes it is the simplest things that get overlooked... I definately was surprised at my earlier conclusion that that prior camera mode was all that there was.... but it would have taken a while to figure out otherwise. Thanks again for the info... gameplay is much better as a result.
as far as the GUI is concerned... that was more for selfish reasons. I definately was not excited about the idea of working on it... I just saw that as an area in need of work, and there was a request for GUI assistance in the documentation supplied with the source code. I wanted to fix it to improve my own experience with the game.
Alantai Firestar:
I suppose that my suggestion that I was writing a full AI was a bit bold... but instead I would like to write some supporting infastructure to manage commandsets a bit tighter... which would fix the problem of build orders not working and other such things. I wanted to expand these commandsets to function as a language of their own (I actually have a lot of experience writing simple script engines for various types of programs). The idea would not neccessarily hurt performance... as I believe that this depends on the condition of the script at runtime...
I have no intention of having the engine parse text at runtime... but instead I wish to (loosely speaking... this may actually have to be done when saving the script) load an object model into memory which closely resembles the script. The only additional CPU overhead that I can predict would be dispatching procedure calls within the objects themselves... which I could get around if I could manage to get void pointers working correctly. I have never managed to get those working the way that I wanted them too... but if I could, I figured that I could buid a mapping utility which will map the units basic commands to a single dispatch engine... and have the dispatch engine handle everything from the micromanagement of individual steps... to unit commands given by the player... AI Build scripts and more.
Finally... the text parser itself would enable commands to interoperate just as they would in an ordinary programming language... hence... you have your Master AI file which (is probebly going to be stored in a compressed binary format to address the need for fast load times)... but this innital file can be replaced or expanded into incorporate new functional ideas.
As I have seen from the codebase... there is no real need to get too much into the actual gaming engine to work on this... as from what I see... that part works fine. It seems as though this is something that I can do simply by adding supporting classes... and proposing the introduction of new code into various classes within the system.
Either way... please continue your feedback... as it has been most valuable in learning my way around this code... and the game itself.
-- Dave
well, the simple formation ai is just an example how much would be useful to produce behaviour driven groupAI. still, imho ai developers are more concentrated on develop ai's on higher level: let me explain.
an ai should have a great deal of communication between all it's parts. as the groupai interface is more targeted to human support, command driven task, it's not suitable for our need of cooperation betwwwn groups of units.
So what almost all of us are doing is to build our own group interface.
For example mine UnitRequestSystem: it is just too much complex to fit in the command interface of the groupai class.
what could be done is to backport it to simpler tasks, as building as mani mex as possible with lvl1 air builders. this will fit in the groupai interface but will be too much useles and dedicated to be used on an full blown ai: and as we're developing ai's just don't have time to develop group behaviour.
also our's interfaces are quite primitive, but later on somebody could think of backport some features into simpler behaviour and put them on a groupai interface: for example you culd take the threat zone of zaphod, make it brawler specific and build a module wich coordinates tons of fighter against enemy aircraft attack. this will bost of 1000% the defence ability of any airbase.
an ai should have a great deal of communication between all it's parts. as the groupai interface is more targeted to human support, command driven task, it's not suitable for our need of cooperation betwwwn groups of units.
So what almost all of us are doing is to build our own group interface.
For example mine UnitRequestSystem: it is just too much complex to fit in the command interface of the groupai class.
what could be done is to backport it to simpler tasks, as building as mani mex as possible with lvl1 air builders. this will fit in the groupai interface but will be too much useles and dedicated to be used on an full blown ai: and as we're developing ai's just don't have time to develop group behaviour.
also our's interfaces are quite primitive, but later on somebody could think of backport some features into simpler behaviour and put them on a groupai interface: for example you culd take the threat zone of zaphod, make it brawler specific and build a module wich coordinates tons of fighter against enemy aircraft attack. this will bost of 1000% the defence ability of any airbase.
-
dj_oldfield
- Posts: 71
- Joined: 24 Oct 2005, 07:10
I hope that I read this right...
What I am trying to write would be merging the two. The scripting interface would be namespace driven...and these namespaces would be primarily resolved during game load (or script storage if need be)... to either a reference commandset or a parameter commandset, depending on the condition of the script and the type of instruction to various scopes.
The examples below are just symbolic of their instructionsets and not neccessarily representative of the predicted syntax.
SOME EXAMPLES:
xUNIT:Move(+/-X,+/-Y)
This would be a basic instructionwhere +/-X and +/-Y would indicate a grid coordinate with xUNIT's current position as 0,0.
xUNIT:Guard( xTARGET )
This is a more complex instruction which will automatically execute a script built within another namespace what is designed to enqueue unit actions.
var instruction{x, y, o, u}= xMAP:FindSuitableLocation( BLDG_REF, AVAILABLE_UNITS )
instruction:u:MoveTo( x, y, u:buildRange( u:currentPosition ) )
instruction:u:Build( BLDG_REF, o, x, y )
And this would be a more complex series of instructions that you would find in a global AI Script.
This is obviously not C Based... if any of you remember a long time ago where was this computerized robot program that you could write scripts for and it would execute those scripts. I based this on my memory of that since it seems fitting in this instance. Besides... I think that C Based is more then some people wish to handle.
We could always do JavaScript though :).
The examples below are just symbolic of their instructionsets and not neccessarily representative of the predicted syntax.
SOME EXAMPLES:
xUNIT:Move(+/-X,+/-Y)
This would be a basic instructionwhere +/-X and +/-Y would indicate a grid coordinate with xUNIT's current position as 0,0.
xUNIT:Guard( xTARGET )
This is a more complex instruction which will automatically execute a script built within another namespace what is designed to enqueue unit actions.
var instruction{x, y, o, u}= xMAP:FindSuitableLocation( BLDG_REF, AVAILABLE_UNITS )
instruction:u:MoveTo( x, y, u:buildRange( u:currentPosition ) )
instruction:u:Build( BLDG_REF, o, x, y )
And this would be a more complex series of instructions that you would find in a global AI Script.
This is obviously not C Based... if any of you remember a long time ago where was this computerized robot program that you could write scripts for and it would execute those scripts. I based this on my memory of that since it seems fitting in this instance. Besides... I think that C Based is more then some people wish to handle.
We could always do JavaScript though :).
-
dj_oldfield
- Posts: 71
- Joined: 24 Oct 2005, 07:10
finally got the app to compile
It came to my attention that I was copying the wrong directory (copied lib instead of "boost"). I don't know what is wrong with me!
Anyway... that having been said... I am ready to begin. Any suggestions are welcome (ESPECIALLY FROM THOSE OF YOU WHO KNOW THE SOURCE CODE WELL!)
Anyway... that having been said... I am ready to begin. Any suggestions are welcome (ESPECIALLY FROM THOSE OF YOU WHO KNOW THE SOURCE CODE WELL!)
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Swift, you'd be surprised how much alike ti is to what you expect.
GroupAI is a shambles at the moment, I would work on GroupAI but I cant because many fo ym ideas rely on things that are only present in the GlobalAI interface.
NTAI and JCAI use agents based off of GroupAI and GlobalAI, JCAI is based more off of GroupAI from I can remember whereas NTAI has the full list of GlobalAI functions.
Apart from that NTAI's system is primitive, Engien creates GlobalAI itnerface globalAI itnerface creates Global class which spawns all 4 agents, then when globalAI interface is called ti calls the equivilant function in globals which fitlers down to each agent in turn. That about as complex as any of ti works.
I am curious, I think a small quick script engien would be a good diea but I think it is a good idea to make it so scripts that the AI use are accessible to all the other LUA scripts, and that both have access to the AI itnerface and fnordias current itnerface. That assumes we use the lua stack and simply optimize lua to run faster for spring.
And no parsing normal text, I assume we'd have it compile to bytecode like in lua to run faster.
I also assume we'd tie that into the Virtual File System ofcourse. And yah C syntax would be nice, but I dont mind going for lua if you're intent on your own engine.
And yah I see now, you mean more like Sub-AI behaviours and their improvement and general command handling improvements.
And a sidenote, I'm a little offput by seeing an AI's raw dll name in the menu and in the lobby, perhaps a more User friendly aproach is needed?
GroupAI is a shambles at the moment, I would work on GroupAI but I cant because many fo ym ideas rely on things that are only present in the GlobalAI interface.
NTAI and JCAI use agents based off of GroupAI and GlobalAI, JCAI is based more off of GroupAI from I can remember whereas NTAI has the full list of GlobalAI functions.
Apart from that NTAI's system is primitive, Engien creates GlobalAI itnerface globalAI itnerface creates Global class which spawns all 4 agents, then when globalAI interface is called ti calls the equivilant function in globals which fitlers down to each agent in turn. That about as complex as any of ti works.
I am curious, I think a small quick script engien would be a good diea but I think it is a good idea to make it so scripts that the AI use are accessible to all the other LUA scripts, and that both have access to the AI itnerface and fnordias current itnerface. That assumes we use the lua stack and simply optimize lua to run faster for spring.
And no parsing normal text, I assume we'd have it compile to bytecode like in lua to run faster.
I also assume we'd tie that into the Virtual File System ofcourse. And yah C syntax would be nice, but I dont mind going for lua if you're intent on your own engine.
And yah I see now, you mean more like Sub-AI behaviours and their improvement and general command handling improvements.
And a sidenote, I'm a little offput by seeing an AI's raw dll name in the menu and in the lobby, perhaps a more User friendly aproach is needed?
Not really. It's based on a task system that handles everything involving construction units, a force class that handles groups of assault units and uses the AICallback interface directly, and a bunch of other classes. All of them are used by the task manager and use the global AI interface directly, so it has nothing to do with group AI.NTAI and JCAI use agents based off of GroupAI and GlobalAI, JCAI is based more off of GroupAI from I can remember whereas NTAI has the full list of GlobalAI functions.
-
dj_oldfield
- Posts: 71
- Joined: 24 Oct 2005, 07:10
hmmm...
First of all, creating text parsers is easy, but creating functional syntax is a bit more difficult. 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.
It would enable you to access both the global AI, as well as construction ais, and any other types which would be needed. This would set the distinction between a regular user and an AI player to be another AI, which could be customized also. I assume that we could have support for Java and C# interoperability at some point, but for the most part I think that it would make the most sense if the game engine takes and compiles text files... builds cache files... and simply checks the modification date each time. Then you can actually create a plain text document... and make modifications as you need.
To be honest... I am not certain if that is even what you guys want... these are just ideas. I have committed to the idea that I want to start doing source code for this app... but most importantly I want it to be something that is wanted. After all, if a bear farts in the woods and nobody is there to smell it... does it really stink?
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.
It would enable you to access both the global AI, as well as construction ais, and any other types which would be needed. This would set the distinction between a regular user and an AI player to be another AI, which could be customized also. I assume that we could have support for Java and C# interoperability at some point, but for the most part I think that it would make the most sense if the game engine takes and compiles text files... builds cache files... and simply checks the modification date each time. Then you can actually create a plain text document... and make modifications as you need.
To be honest... I am not certain if that is even what you guys want... these are just ideas. I have committed to the idea that I want to start doing source code for this app... but most importantly I want it to be something that is wanted. After all, if a bear farts in the woods and nobody is there to smell it... does it really stink?