Show whole topic
Dec 16, 2012 7:48 pm
Dec 16, 2012 7:48 pm
Subject: Re: Ai implementation
Hi Everybody,
@fyzzo thanks for cheering me up!
@Toranaga My purpose was to use as much as possible from the existing protocol implementation, for instance, if you miss-implement the message packing or unpacking, the client (and also likely the server) may crash. Most of the game use the B) method, simply because AI is too "dumb" and it needs to cheat in order to make the game challenging. "Connected process" reduces cheating to a point: if the server doesn't check and control the "cheater", AI cheating may happen. For example, my landing party is not constrained to the game specified amount.
What I did is A) but I use the original source code of MAXR, to avoid additional work, this was a good shortcut. Many objects require graphics, so my program also loads all the graphics available.
Planning is difficult since we are a group of volunteer with different goals and variable time availability.
I will check your bot implementation, thanks for sharing!
My PhD topic is data mining (for the moment, I am concerned with big data storage) in a remote program at Transilvania University of Brasov, Romania. Currently, I don't pursue a degree or publications related to gaming AI. However, C++11 may be a part of the research.
@ness the original code is almost all the times self explanatory. Some German skills may help in understanding the comments. I spent 2 evenings and Saturday morning to understand the code and write the bot. There is no formal definition of the protocol, that is not all the time stateless. For example, by not handling the GAME_EV_ATTACKJOB_LOCK_TARGET and GAME_EV_ATTACKJOB_FIRE messages in the right way, the enemy (with regard of the bot) unit becomes locked indefinitely. I don't know the exact mechanism behind, I only used existing classes that handle this messages right. Indeed, sharing the same protocol makes collaboration easier than direct memory access.
Razvan
Hi Everybody,
@fyzzo thanks for cheering me up!
@Toranaga My purpose was to use as much as possible from the existing protocol implementation, for instance, if you miss-implement the message packing or unpacking, the client (and also likely the server) may crash. Most of the game use the B) method, simply because AI is too "dumb" and it needs to cheat in order to make the game challenging. "Connected process" reduces cheating to a point: if the server doesn't check and control the "cheater", AI cheating may happen. For example, my landing party is not constrained to the game specified amount.
What I did is A) but I use the original source code of MAXR, to avoid additional work, this was a good shortcut. Many objects require graphics, so my program also loads all the graphics available.
Planning is difficult since we are a group of volunteer with different goals and variable time availability.
I will check your bot implementation, thanks for sharing!
My PhD topic is data mining (for the moment, I am concerned with big data storage) in a remote program at Transilvania University of Brasov, Romania. Currently, I don't pursue a degree or publications related to gaming AI. However, C++11 may be a part of the research.
@ness the original code is almost all the times self explanatory. Some German skills may help in understanding the comments. I spent 2 evenings and Saturday morning to understand the code and write the bot. There is no formal definition of the protocol, that is not all the time stateless. For example, by not handling the GAME_EV_ATTACKJOB_LOCK_TARGET and GAME_EV_ATTACKJOB_FIRE messages in the right way, the enemy (with regard of the bot) unit becomes locked indefinitely. I don't know the exact mechanism behind, I only used existing classes that handle this messages right. Indeed, sharing the same protocol makes collaboration easier than direct memory access.
Razvan