rts ai rant
Why don''t comercial rts games support plugin ai?
They could implement their default ai in a dll, and release the source (several fps games already do this for their game play code). In game when you add a computer opponent instead of just setting easy, medium or hard, you could select your oponent by name (eg, you select "peon_bot" it loads peon_bot.dll). This would mean you could fight against multiple, different ai''s. Or have different ai''s fight it out among themselves.
Within the dll the bot would be implemented as a class inherited from a default bot. Access to map and game data would be routed through wrapper functions to prevent cheating.
Rts games live or die by their ai. With an easily extendable ai system fans of the game would be able to extend the playing time of the game, surely a good thing?. In fact, why has noone done this yet just to get away with releasing a lame default ai?
Come on Westwood and Blizzard. Do the right thing. Give us access to write new ai opponents. It can only make your games sell better. Or are you afraid we''ll see that your ai can only win because it gets free resources on a timer?
Alan
"There will come a time when you believe everything is finished. That will be the beginning." -Louis L'Amour
Actually i believe that blizzard are doing exactly that with Warcraft III. They stated earlier in production that everything will be editable... Even ai code.
There are a number of RTS games that support extensible AI through scripting - for example Kohan. You might be able to find some others at gameai.com under ''extensible AI''.
However, very few if any games will give people the opportunity to write the AI from the ground up. I suspect that the reason for this is that doing so would expose too much of the mechanics of the game than game designers really want made known. Underlying game mechanics are much more important to an RTS, which relies on strategy (simple control, complex strategy), than an FPS which mostly relies on hand-eye coordination (complex control, simple strategy).
Although obscurity is certainly not security in the sense that not really knowing game mechanics isn''t going to stop the creation of ''cheese'' strategies, it certainly can''t hurt the expected lifespan of the game.
However, very few if any games will give people the opportunity to write the AI from the ground up. I suspect that the reason for this is that doing so would expose too much of the mechanics of the game than game designers really want made known. Underlying game mechanics are much more important to an RTS, which relies on strategy (simple control, complex strategy), than an FPS which mostly relies on hand-eye coordination (complex control, simple strategy).
Although obscurity is certainly not security in the sense that not really knowing game mechanics isn''t going to stop the creation of ''cheese'' strategies, it certainly can''t hurt the expected lifespan of the game.
quote: Original post by Argus
However, very few if any games will give people the opportunity to write the AI from the ground up. I suspect that the reason for this is that doing so would expose too much of the mechanics of the game than game designers really want made known. Underlying game mechanics are much more important to an RTS, which relies on strategy (simple control, complex strategy), than an FPS which mostly relies on hand-eye coordination (complex control, simple strategy).
Although obscurity is certainly not security in the sense that not really knowing game mechanics isn''t going to stop the creation of ''cheese'' strategies, it certainly can''t hurt the expected lifespan of the game.
I agree with you 100% Argus. In our various game AI discussion roundtables at the GDC I''ve asked developers about AI interfaces as AlanKemp describes. There are a lot of reasons they don''t provide them but they boil down to a.) too much exposure of their ''secrets'' and b.) no time to build it that way.
Management is usually very concerned about ''giving away'' things like an AI interface--look how long it''s taken to get simple ''bot scripting engines into the FPS games! The only reason games like Quake and Unreal give away their source code is that developers own the thing--they have an interest in advancing the state of the art. Management in general couldn''t care less--you bought the game, didn''t you?--and have to be convinced it''s worth the effort, exposure, and potential liability (who''s responsible if somebody writes an AI .dll file that trashes your hard drive--the .dll writer or the game developer for letting the interface do something like that?).
The other problem is simply time in the development schedule--time to build the AI interface in a modular replaceable fashion, time to document it, time to support it after the fact through posts and FAQs and such. Most developers have a hard time getting their AI up to snuff during the normal course of the schedule--how much more time does it add to build a bunch of documentation and to document two or three .dlls so budding developers can ''roll their own''? Most developers just don''t have the time to do it that way.
Ferretman
ferretman@gameai.com
www.gameai.com
From the High Mountains of Colorado
Ferretman
ferretman@gameai.com
From the High Mountains of Colorado
GameAI.Com
"b.) no time to build it that way."
Aye, that''s the other major factor I didn''t mention. A cost/benefit analysis of providing a low-level AI interface is just doesn''t add up. While there''s no doubt that it would be a great boon to budding AI programmers, those people will make up (at the most optimistic of estimates) maybe 0.5% of their customers.
On a side-note, are there any RTS games that actually do provide such an interface ? Even a very simple one ? If not, perhaps that would be a worthwhile project.
Aye, that''s the other major factor I didn''t mention. A cost/benefit analysis of providing a low-level AI interface is just doesn''t add up. While there''s no doubt that it would be a great boon to budding AI programmers, those people will make up (at the most optimistic of estimates) maybe 0.5% of their customers.
On a side-note, are there any RTS games that actually do provide such an interface ? Even a very simple one ? If not, perhaps that would be a worthwhile project.
On the time issue... I think that it''s a bit of a false economy given that so many developers reuse their old code for the next project anyway. Perhaps the time taken to make the AI more versatile and independent of the main code would be time saved later?
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
With regards to "too much exposure of their ''secrets''". How much would they have to expose?
All requests for information on the gamestate are going to have to go through wrapper functions so people cant build info-bots anyway, so all they need to make available to the dll are functions (ie, no direct access to gamestate variables).
I agree with Kylotan. I work as a games developer, and I know that spending an extra week designing a system properly now, will save me a month later, and two months on the next project. Putting things like AI out in dll''s seems logical, it means you can easily have a seperate developer working on the ai without needing to directly intergrate his code into the main engine build (which even using cvs takes time and is error prone).
No time for documentation? Within my company all code is documented as its developed. This may not quite be upto what the general public is expecting, but I would bet good money that within a few weeks or release you find an internet project spring up dedicated to documenting every function and variable available :-)
Admittedly you are going to have spend time supporting it after release, but as I suspect most companies would also be collecting tactics/strategies/code from user created dll''s even this has a chance to pay for itself. This support person can also fully document the dll''s _after_ release. This will pay off within the company as it will be usefull to new staff, or just generally when the code is used again.
Alan
All requests for information on the gamestate are going to have to go through wrapper functions so people cant build info-bots anyway, so all they need to make available to the dll are functions (ie, no direct access to gamestate variables).
I agree with Kylotan. I work as a games developer, and I know that spending an extra week designing a system properly now, will save me a month later, and two months on the next project. Putting things like AI out in dll''s seems logical, it means you can easily have a seperate developer working on the ai without needing to directly intergrate his code into the main engine build (which even using cvs takes time and is error prone).
No time for documentation? Within my company all code is documented as its developed. This may not quite be upto what the general public is expecting, but I would bet good money that within a few weeks or release you find an internet project spring up dedicated to documenting every function and variable available :-)
Admittedly you are going to have spend time supporting it after release, but as I suspect most companies would also be collecting tactics/strategies/code from user created dll''s even this has a chance to pay for itself. This support person can also fully document the dll''s _after_ release. This will pay off within the company as it will be usefull to new staff, or just generally when the code is used again.
Alan
"There will come a time when you believe everything is finished. That will be the beginning." -Louis L'Amour
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement