IPB WARNING [2] preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead (Line: 311 of /sources/handlers/han_parse_bbcode.php)
IPB WARNING [2] preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead (Line: 312 of /sources/handlers/han_parse_bbcode.php)
IPB WARNING [2] preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead (Line: 313 of /sources/handlers/han_parse_bbcode.php)
IPB WARNING [2] preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead (Line: 317 of /sources/handlers/han_parse_bbcode.php)
IPB WARNING [2] preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead (Line: 311 of /sources/handlers/han_parse_bbcode.php)
IPB WARNING [2] preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead (Line: 312 of /sources/handlers/han_parse_bbcode.php)
IPB WARNING [2] preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead (Line: 313 of /sources/handlers/han_parse_bbcode.php)
IPB WARNING [2] preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead (Line: 317 of /sources/handlers/han_parse_bbcode.php)
Analysis of Rcbot2, suggestions and improvements to Cheeseh and partners (and others V.I.Ps forum-members: genmac, madmax2, Emotional, Septien etc.) - RCBot Forums
IPB

Welcome Guest ( Log In | Register )

> Analysis of Rcbot2, suggestions and improvements to Cheeseh and partners (and others V.I.Ps forum-members: genmac, madmax2, Emotional, Septien etc.), Observations, suggestions, request improvements and others...
Brief Survey
Do you think that the observations and ideas of this topic are important (partially or fully)? So, do you think that these ideas and observations (partially or fully) deserve consideration in the continuing process of Rcbot2 improvements?
[ 2 ] ** [100.00%]
[ 0 ] ** [0.00%]
Total Votes: 2
Guests cannot vote 
YuriFR
post Jan 22 2014, 04:55 PM
Post #1


Advanced Member
***

Group: Members
Posts: 51
Joined: 7-January 14
Member No.: 2,318



Analysis of Rcbot2 v.0.76, suggestions and improvements to Cheeseh and partners (and others V.I.Ps forum-members: genmac, madmax2, Emotional, Septien etc.)

I leave a reproduction of this topic attached (format .zip)


INTRODUCTION AND INSTRUCTIONS:

• This post this was very extensive, partly because I have difficulties with writing in English (and perhaps why my writing seems wordy, at first sight). I use Google Translator, without which it would be impossible for me to communicate with anyone on this forum.
Google Translator, however, is not perfect ... !

I ASK PATIENCE TO ALL READERS. I ASK APOLOGIES IN ADVANCE FOR MY ERRORS: in spelling, wrong emphases, misuse of idioms, misinterpretation of the meaning of sentences, confusion between cultured and popular standard, among others.

When I use the term "Rcbot" or "Rcbot system" or "Rcbot2", i'm always referring to the same program (same software structure), irrespective of versions (1 or 2 etc..).
The technical term "AI" refers to "Artificial Intelligence".
The term "bot" refers to soldiers controlled by artificial intelligence of Rcbot system (or other system like Sturmbot).

This topic relates SPECIFICALLY to Rcbot system for Day of Defeat: Source. This post is a DETAILED REPORT of the results of the tests that I undertook with bots of Rcbot2 v.0.76 for Dod:Source. I'm a HARDCORE fan of Day of Defeat series and I made sure (i've certified) of the quality of Sturmbot-system for Dod-Classic and i approved him. I also enjoyed the Rcbot system, which surprised me POSITIVELY. I envision one VERY PROMISING FUTURE FOR RCBOT SYSTEM. Largely for this reason, I intend to contribute to Rcbot, (the best I can), for your development. Despite my many limitations!
• Whenever possible, i made observations about Rcbot, with references to Sturmbot. My intention is NOT simply compare the two systems. Not interest (me and here) know which system is better and which is worse, in an absolute sense, the goal is other: is to show (at who does not know) as Sturmbot works in the context of each of the reported observations to Rcbot, in order to stimulate the emergence of new ideas and solutions to Rcbot, based on a pre-existing (and solid) system; i.e: a system for bots who already proven/consolidated itself. Thus i intend that Sturmbot can serve as a "system-support" for the evolution of Rcbot, going forward: for each observation about Rcbot, the Sturmbot shows a possible solution, or implemented resource, or a different idea that was successful, or unprecedented things, much them yet nonexistent in Rcbot.
• It is NOT my goal criticize negatively the Rcbot system. On the contrary: I want the Rcbot IMPROVE EVEN MORE BECAUSE HE SHOWS THAT IS A VERY GOOD SYSTEM, AND SHOWS A VERY PROMISING FUTURE.
• This topic also seeks to satisfy a suggestion (perhaps a kind of "request") of mr. Cheeseh, in this post: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 ; namely: try the latest version of Rcbot2 (version 0.76) for Dod: S, and make general comments about the program / system (observe what can be improved, what is more important etc..).
• I created this topic, and i made this post with the intention of continuing another post (link: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 ). This topic will be better understood from reading the other post, quoted above. This present topic does not delete the comments, suggestions, ideas etc.. of the same previous post. On the contrary: this post complements the other (and maybe reevaluates some observations made in that previous other post).
• I invested a lot of time to write it (over 2 days). First, in my native language, then translate it into English. No details spared. I suggest you take a time to yourself, to be able to read it all at once, without interruption. And... please: read carefully (one sub-topic is always related to another sub-topic or sub-thread).

• This topic (and this post) is the result of tests that I did with Rcbot2 v.0.76 for Dod:S. on my computer. I stayed also for 2 days, focused in it, making these tests, and jotting down notes about the observations. The software ran relatively well: there were no lags at various maps. In larger maps, and with the total amount of bots (all of them with very high settings for skills), there were some lags and the game became slower. I tried to establish a certain amount of bots that not disturb much the performance of my PC, from this amount of bots i started the tests, only varying the skill level of the bots. I post just below a summary of the specifications that i used for the testings:
The number of bots was between 24 (good performance) to 32 (lowest performance), in total. On my system, I set the amount 24 bots in total, for longer time (like a “default” to tests).
In general, i established higher rates for the skills, for example: "visionticks_clients = 28 | visionticks = 75 | pathticks = 172". I modified these numbers down as well, but no modification changed the content of the comments/observations I have made here in this post.
The skills "braveness | aimskill | sensitivity" were also modified several times, without significantly modify the content of comments posted below.
I established more stable values for the following skills, staying around on the following numbers, along all the test battery: "rcbot_defrate = 0.13 | rcbot_skill = 0.94 | rcbot_anglespeed = 0.68"



SUMMARIZED INDEX OF SUBTOPICS:

1. Bot “perception” of firearms and explosive devices
1.1. The perceive of the origin of the gunshots
1.2. The perceive the “bullet impact” hitting the environment.
1.3. Expositions of bots, unnecessarily, to enemy gunfires
1.4. Negligent behavior even when bots anticipate the bullets impacts, at distance

2. Perception of noise from the enemies, and reactions

3. Perception of risk during the paths / routes

4. Improvement of some movements of bots in Rcbot
4.1. Prone and crawling
4.2. Simultaneous movements: opening fire, taking cover, responding fires
4.3. About “go in crouch” and “go to run” and improvements
4.4. Bots and walking crouching
4.5. About tactic movement "shoot firearm and evading to the side"
4.6. Changing main weapons to guns found on the ground
4.7. About interruption of walk to engage the enemies, and return to old path
4.8. Adoption the resource "always vocal response to the commander"

5. About close-combat (“hand-to-hand”)

6. Throwing grenades and responses to them
6.1. Warning and speed of run-escape of grenades
6.2. Frequency, timing, accuracy and stances to throw hand-grenades

7. Deploying Snipers and automatic machine-guns
7.1. Insignificant and significant places and (preserve) randomness
7.2. Postures/stances to deploy weapon: exposing the body
7.3. Small bugs on mechanism "deploy guns", bad choices and exposing the body
7.4. Deploying Snipers and MG, fixed position on the ground
7.5. Important problem with the perception of the enemy, (on surround area), while deployed

8. Brief note on "form(ing)-squad"

9. Latest considerations


-------------


1. Perception of risk in the environment (firearms and explosive devices)

1.1. Bots are still not able to properly perceive the origin of the shots of firearms (and explosions) "BY SOUND" that gunshots produce, regardless if the projectile hits a building/obstacle or if goes skyward. That is, the bots are still unable to use the DATA "(sound) of gunshots and explosions" to locate the position of the enemy who is carrying out these gunshots and throwing these bombs. Because from this, with this failure, the bots are not yet able to calculate the risks they are exposed to every moment of your route or every moment of confrontation. Consequently, the bots are not enabled to use this perception as a relevant data/information on which to base their conduct of reaction to the event (and so, acting reasonably and take corresponding measures to the characteristics of the attack from the enemy: direction and number of attacks). As an example of reaction, the bots could: pointing in the correct direction of the enemy and retaliate the fire immediately, or crouch/prone, taking covers, throw hands grenade, inform around squads about the impending danger, make a quick withdrawal to behind friend lines to rally forces, flank the enemy position, drastically change of course or path (look for a way to facilitate the response to fire or circumvent/avoid confrontation with the opponent in question) etc. . etc. The Sturmbot is able to detect the sound of gunshots (and voices), but needed further optimize these resources.
In Rcbot2 I spotted only THREE exceptions to this observation " 1.1 ", and that will make the bots react to shooting of firearms (and bomb blasts) of the enemy:
a) in the case of directly seeing the enemy firing (and see the grenade or other bombs dropped on the floor near them), and ...
b) in the case of seeing a partner being slaughtered specifically for enemy Snipers (perhaps also by an enemy machine-gun, now i can not remember...), and ...
c) in the case of bot being hit directly by a non-lethal fire-shot, and survive.

1.2. Bots are also not able to perceive the enemy's projectile hitting the walls, floor, ceiling, and other structures (glass, objects etc.) near them, and so are unable to use this event (" ballistic impacts on the surrounding") as a relevant "data to compute" (information) in their structure of "reflection/reasoning " (part of the AI responsible for formulation of plausible "lines of responses" to the threat in the environment). I better explain: bots do not understand that ricochets or explosions surrounding them (or around the area a partner next to him) indicate that he is under direct sight (or under close indirect threat), and is therefore exposing themselves unnecessarily. As the ballistic event is not perceived, or computed, the bots no takes sensible attitude for self-defense/protection or counter- attack measures. This failure of perception also includes the circumstances in which the bots can see the indirect ballistic impacts with much anticipation (eg: see a partner be slaughtered in front him, or see, by far, the ricochets in the buildings). The Sturmbot could also provide bots with a feature of "perception of ballistic impacts", but that did not work 100 % (similar to the case in item "1.1").

Due to the items "1.1" and "1.2", the behavior of the bots falls short in terms of prudence and caution. The 3 exceptions of the item "1.1" also apply to this item "1.2".

1.3. Does not always happen, but the next event is frequent: the bots that are exposing themselves unnecessarily to enemy gunfire and have not yet located them (as described in previous items), stand still with his back (or side) to the source of the gunshots (or explosions) without any sketch of reaction. Remain for a while as if they were "unconcerned" with the risk of being hit anytime. A minimally reasonable behavior for this circunstance would be: once the shots are perceived, bots must crouch, or go in prone position, or retreat/evade, or just rotate the body in contrary direction to the ballistic impacts on the structures surrounding, aiming to find the source of gunshot (the enemy) and act against him. The Sturmbot always had this same flaw/defect, which was never fully corrected by Johan Linde. And this characteristic has always irritated me (one of the few very negative critical points of the Sturmbot system). The exceptions "b)" and "c)" in the item "1.1" also apply to this occurrence.

1.4. Bots step into places or regions that are suffering intense ballistic impacts by guns and explosions, carelessly/rashly. Many go inside this way, and die, and are followed by many others (all ignoring the death of the previous waves just ahead). The bots that enter these territories tend to always repeat the same pattern of "negligent behavior". The Sturmbot was a little different, it enabled them bots with a kind of "sense of caution" (self-preservation or self-defense): at the sight the bullets impacts in buildings, in real time the bots stopped walking, "thinkin", and look for rework their routes and actions measures. When resuming the walk and observe the resurgence of gunshots (reaching the environment), they stopped again to reassess the degree of danger. However, the attitudes they took soon after were not perfect, and many bots after their stops did not change theirs routes (or measures of action) and continued on the same path until to get shot of firearms and die ...

2. Perception of risk in the environment (noise from the enemies: footsteps of soldiers, voice commands, doors opening or closing, falling of objects or soldiers, cries, explosions, "fight melee" nearby, etc; & visible lighted lanterns)

The bots yet not react appropriately to these environmental variables listed above (especially the sounds). Even when they occur in quiet places (away from the "hot" combat sites). The most recommended conduct for the bot that passes through an empty and silent region will be: when they hear these sounds nearby, coming from another bot (or human player) belonging to the opposing army, the bot should abandon its route temporarily and go to the site, with caution, to verify and take offensive measures. Based on these noises, the bot does not need deviating too much from its normal path, no need to travel long distances in order to search for the presence of nearby enemies. But the bot should be able to do a quick search and short within a radius of action/intervention that is plausible for him (that makes real sense). What I mean is: introduce a little bit of variables "curiosity" and "conduct patrol" into Artificial Intelligence of Rc bots. The Sturmbot possessed this ability, but there was a limitation: only a noise very close can able to arouse the attention of the bot (equivalent to 1 or 3 meters at most). And yet nevertheless, the bot didn't use much effort to "hunt down" the opponent that made the noise. This would probably be improved by Johand Linde, but it was not ... ...

3. Perception of risk in the environment: during the paths/route between waypoints.

In the Sturmbot there are many kinds of waypoints, in this post interested two types: a) "precision waypoints" and b) "common waypoints". The diference between them is that the former establishes the obligation of the contact between the bot and a specific waypoint, and the second is more flexible, allowing a significant degree of deviation in the path between a waypoint and another waypoint, but without exaggeration. The first was more used to force a bot to go through a very narrow path and avoid problems (such as: climbing a narrow staircase, pass through a tight alley, walking near slopes and abysses etc.), the second was widely used (as standard) throughout the extent of the map. I think it worked that way... What I want with it all ...? See below:
If Rcbot2 works also using "Common waypoints" (non-precision) as "default", you can add for bots, in the script, self-defense behaviors during the travel between "common waypoints". For example, I will use the following assumption: from a point 'A' to another point 'B', the bots crossing an open plaza and ample space (eg: the main square of the map "dod_anzio"). Rather than always follow the path straight 'A' --> 'B', bots can make small deviations, sub-routes through obstacles and things that provide coverages (protection) during movement of bot progression (between 'A' and 'B'). Or, in the absence of elements which provide protection, the bots would make like rats do (in real life: avoid open spaces): walk along walls (protecting theirs "side back"/shoulders) until when it is no longer more possible (eg: point where the end of wall forms an oblique or right angle, in relation to destination point 'B'). If you decide to implement this feature, you can make it work as "default", for cases in which the bots walk through wide open spaces (which in theory: expose the bots to enemy gunfires). And do make this as optional (or random) when the bots roam tight hallways, alleys, or relatively enclosed spaces.

4. Improvement of some movements of bots in Rcbot.

4.1. Sometimes I saw the bots of Rcbot go in prone in combat. Initially liked it because it could be intended to protect himself. However, often the bots crawling sideways for no apparent logical reason to do this - i got to witness a scene in which a bot crawling sideways in the absence of any enemy in evidence at the site (a battle had occurred there earlier, but no bot opponent still there). I think the bots should be able to crawl, as I have already explained in this and in the other posts (see below), but must do so with some rationale and purpose (at least I was not able to clearly understand the specific reasons justifying this attitude of "creeping sideways"). Sturmbot bots are also able to crawl (can crawl in certain situations, including, for several meters without getting up). But do this following a more rational purpose (such as: suppressive-fire protection, search for take cover against intense gunfire, escape from grenades, attempts to flank the opponent, attempt to kill an enemy that is very close, and also in prone, using the bayonet or knife etc. etc.), as I detailed in the other posts (check on link: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 ).

4.2. The bots in Rcbot, when they are surprised by many distant enemies, in front of them, also should be able to open fire and simultaneously run in the direction of obstacles on the way, with the goal of establishing good shooting positions and get enough coverage and protection (eg: behind concrete blocks on the streets or low walls of stone, behind sandbags, go to corners of walls, behind czech-hedgehog, behind cars or armored vehicles, behind an open window etc. etc.). Once the bot to gain good coverage, he can continue and keep your gunshots (alternating between the following movements: gunshooting, escape/evade of fire-retaliation: crouch or go in prone behind coverage, and return to shoot against enemies... and so on ... repeating the process). The tactics described above no need always be activated, either will become very predictable, but should be widely used from time to time, occasionally/periodically, providing a more richer combat experience, more actual or verisimilar, and much more varied. I'm sure that these resources will be nice and very cool in Rcbot2! Sturmbot was able to provide to bots some rational use of coverages, in combat situations.

4.3. I feel missed of some movements in the Rcbot 2, more present in bots of Sturmbot (and more present in real life and in game between humans), both movements: “go in crouch” and “go to run”. The Rcbot is able to make bots crouch, and more rarely: make the bots go to run. I think the frequency of use of these movements should be increased in Rcbot, at least a little more. Many, many times the bots of Sturmbot go in crouch in order to get more accurate gunshots and minor setbacks (recoil), mainly (but not exclusively) when the bots used sub-machine guns (eg: MP40, STG44, Thompson, BAR). Bots (Sturmbot) also crouched with rifles to gunshoot, but less frequently than bots with sub-machine guns. Alternatively, bots of Sturmbot (regardless of his class), were also go in prone aiming to improve the chance to hit and reduce as much as possible the gun's recoil.

In Sturmbot , the movement "run" was set to execute through specific waypoints along the routes, the only exception to this rule is the perception of grenades on the ground around and consequent leakage "racing" (see sub-topic below). I always considered this particular feature of Sturmbot a little bit restrictive: I think the movement of running might be sometimes employed in certain specific situations of much danger, regardless of whether "run waypoints", such as: emergency withdrawal straight-line ("fall back"), escapes of very intense gunfire going in the lateral direction (right or left), escape quickly of the area controlled by some Sniper, crossing an area that is in the perpendicular under heavy fire of machine-gun/MGs (eg: the area to cross forms a letter "T" in relation to MG: bots go through the upper extension of the "T", which is under control of the machine gun positioned at the bottom of the "T"; i do not mean that the bot should run in straight-line toward the machine-gun…!). Perhaps, more other situations may be thought for use of "run movement" to Rcbot. Another point is which the Rcbot should improve the "speed of run" and "time of run", when the bots are running: i think that the bots are performing very short runs and with a "speed racing" perhaps below the maximum (compared to observed in Sturmbot: in there it was satisfactory).

4.4. In Sturmbot is relatively more common to see certain situations where the bots walk crouching. In Rcbot it is also possible, but so far i've only seen the bots walk crouching for a very few meters and only in situations where they were ambushed, without possibility of withdrawal (eg: grouped, defending a last flag of opponent's attack). I think that more situations ("walk crouching") can be added in Rcbot... would be nice!

4.5. The bots in Rcbot should use with more accurately the resource "shoot firearm and evading to the side" (gunshot, and flee of fire-response, going to right or left side / flank). I've seen the bots Rcbot perform this procedure, however, the bots just take a few steps towards the lateral and could to protect yourself more, with (a little bit) longer steps. If i'm not mistaken, the bots of Sturmbot walk sideways by a slightly greater extent. Another thing: the Rcbot-bots when in combat, could also have the ability to switch between shooting positions ("standing", "crouching", "in prone"), once in a while, with the intent to hinder the accuracy of the opponent's gunshots and minimize yourself damage. In turn, I think this option can only is valid if the shift of position does not significantly impair the accuracy of the shots of the bot itself.

4.6. The bots in the Sturmbot (only last version 1.7) could change their main weapons for other weapons that were (thrown) on the floor (friendly or enemy weapons). The bots did this change once in a while. I did not know identify the reasons for this changes, beyond the possible motive "run out of ammo". This aspect ("change weapons") can also be thought to Rcbot. However, I think the frequency of exchanges of weapons should be less (in Rcbot) than the existing frequency in Sturmbot (the frequency of changes was exaggerated).

4.7. I did some testing in Rcbot in order to verify the operation of the resource "bots interrupt your journey when they spot an enemy out of him, engages the enemy to kill him, and returns to his old route". Based on the results I got, my opinion is that this feature MUST BE MUCH IMPROVED. Why i think so? Because many times I teased bots, exposing myself to them and then i hiding (and evading your gunshots), aiming to lure them out of their routes. In fact, i noticed that the bots deviate from their routes to kill me, but deviate VERY LITTLE and DESIST QUICKLY OF ENGAGEMENT. The Sturmbot promotes a longer engagement than Rcbot, and yet I felt that the time and distance were still insufficient (and implausible in relation to the behavior of a soldier in a real situation, or to a human playing Dod : Source in internet) . In my opinion , a bot should be PERSISTENT DURING ENGAGEMENT out off course; obviously to a certain limit. It is not necessary, nor desirable, program the bots to undertake a long and relentless persecution, or an engagement that scroll across the map. But the bot should be able to abandon their old route PERSISTENTLY, once noting the threat of an enemy outside them, and pursue it in several situations: climbing and descending stairs, entering homes and buildings, jump into holes in the walls of buildings, etc. . - to kill the enemy, within a reasonable radius of action, a distance equivalent to several meters in all directions (you must stipulate an amount for it, maybe 10%, 20% of the map? I don't know...). If the bot follow the entire extension/range determined, and he can not kill the enemy, he returns by the same path toward its old route. This is the core of idea. It is important that, during this return, the bot look back with some frequency, in order to defend its backs.
One important detail: bots of Sturmbot only engage the enemy off course, if the enemy is seen evading (hiding, or going around a corner), ie: 1°, the bot sees the enemy off course, shortly after (2°) the bot shoot against him (but misses the shot or: enemy survives), and 3°: the enemy does not fight back (do not "shot/fire respond") and evade the site. More or less like this, only with these 3 conditions that the bot starts the procedure of "engagement off course".

4.8. According to my other posts (i will not detail here)*: insofar as it is being added new voice commands (among bots) in Rcbot, and corresponding behaviors, remember to also add the corresponding gestures, and a verbal response of bots at command-voice of commander: "Yes, sir" for if so (and "yes gesture" with head) and "No, sir" to if not (and "negative gesture" with head). I'm basing myself once again on the legacy left by Sturmbot. Although this seems a silly detail, even throwaway, he CONTRIBUTES GREATLY TO THE ATMOSPHERE of the game Day of Defeat. Although it not seems, at first, the lack of response cries impoverishes the experience of the game, and its lack is felt.
* Link to the same old posts: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 .

5. Fight "body-to -body"/"hand-to-hand" (close combats).

As I realized , the bots Rcbot are actually able to use "spade tools" or knives to attack the opponent in hand-to-hand fight (skirmish within walking distance) instead of conventional firearms. However, the bots only shifted the conventional gun for shovel or knife, when their main (and secondary) weapons were fully discharged. This phenomenon is logically correct and should be maintained!, but there is a problem regarding this issue (close combats): i witnessed a curious scene in which two opponents Rc-bots suddenly collided among themselves in the doorway of a room, as they were too close one to other (touching each other), the bots found some trouble hitting gunshots at very close range. They stood looking at one another, and firing unreliably, once in a while, until a bot finally managed to kill the other. In Sturmbot this does not occur: as soon as that two opponents have collided across a short distance ( 1-2 meters at most, or less than 1 meter: contact "body- to-body"), they immediately change their main guns (fire-weapons) to knives or shovels, the bot that is faster in this change, gain an advantage, and probably be able to strike the opponent and wins. This feature can be adopted in Rcbot, it will solve the double-problem of aiming and hit the gunshot for very short distances and, at the same time, turn the close-combats coolest!, interesting and realistic (eg: i refreshment our memory, using the "fight scene" with knives between a German and an American soldiers in the movie "Saving Private Ryan").

6. Throwing grenades (and explosive devices) and response to grenades thrown by the opponent.

6.1. “Rc”-bots are able to realize the grenades the enemy on the ground, thrown against them, and notify their partners around. Bots of Rcbots are also able to escape. However, they do not take a quick and satisfactory (effective) reaction against the threat posed by grenades. Example: escape running as much they can, all the way out of the "area impact" of these explosives. I saw the bots evade of local, moving relatively slow for that situation (maybe a little faster than usual, but not running enough!). With this behavior Rc-bots conveyed an unrealistic impression: as if they were not "impressed" with the inherent risk of death by grenades (note that in real wars, the soldiers has a big fear of being maimed or killed by hand-grenades - a similar reaction happens even with human players, in war games for PC: all of them try avoid the grenades, the maximum possible...). The reaction to hand-grenades, by the bots of Sturmbot, are more consistent (and quick) than reactions in Rcbot: they run with maximum speed, all of them disperse, and go in prone behind obstacles, such as: sand bags, entries, holes on walls, shell-holes in streets, or even in ground (but far enough from the grenade). In Sturmbot can occur some bot not see the grenade on the ground and die because of this (plausible act that can happen in real life too), but if a bot on Sturmbot perceived the grenade he will flee and alert her to any other bots in the surroundings, with frantic gestures and cries (saying: "Grenade!"). The other bots, warned, will also try to escape of the grenade just as the first bot he saw. In my opinion, the Rcbot should adopt the same behavior / reaction used by Sturmbot. A strong argument for adopting this change: I witnessed bots in Rcbot die because not ran enough (far away from hand-grenades) and because the bots coming from back not heard the cries warning ("Grenade!").

6.2. The bots of Rcbot throw grenades, but I noticed they are more biased in throw explosives by their firearms, instead of using the classical hand-grenades. My opinion is that this feature must be reversed. Another thing that can be changed (increased) is the frequency and accuracy of throwing the hand grenades: the bots must throw hand grenades a little bit more often, when appropriate (see explanation below), and with better "hit rates" for hand-grenades: make it a bit more accurate. Bots of Sturmbot can serve as an example again. They threw their grenades based on a very sophisticated "timing" ("sense of opportunity"). They were able to understand various combat-situations, and respond to them with the racional use of hand grenades, such as: clustering of enemy troops, heavy shootouts (during a medium period), if the friend team is suffering a fire-suppression, on cases of deadlock / standstill in the lines of contact between armies (no faction move for advance or indentation), in cases of numeric disadvantage against the enemy, bot get ambushed/cornered alone, several unsuccessful attempts to kill someone with firearms, presence of machine-gun nest, sighting an inaccessible Sniper, defending the last flag, support the withdrawal in an emergency case etc. .. All these situations are conducive to the use of hand-grenades. It's amazing, in Sturmbot: every time I thought " this situation (fighting) asks hand-grenades" opponent bots threw their grenades on me and my team! However, the Sturmbot does not employ the philosophy "always the same solution for to the same problem", and the measures-actions of bots varied (perhaps with the use of probabilistic ... i dont know...). Thus, the context of the fight became more realistic: more unpredictable (and therefore more dangerous) - what's good!
Another feature that i not have observed in Rcbot (not sure if there is or not...), but there is in Sturmbot, is the ability of a bot efficiently launch a hand-grenade into any of adoptable possible positions: "standing", "crouching" and "prone". The Rcbot could also implement this feature, if not have in there.

7. Deploying snipers and automatic machine guns (MGs, .30, .50 etc. )

7.1. Bots of Rcbot2 are able to deploy snipers and machine-guns (the Sturmbot also had the same feature). Often the chosen location is good and is sufficient to cover fire and help curb the advance of enemy troops. But sometimes the bot that controls the machine-gun or Sniper insists deploy your weapon on totally insignificant places. An example: bot deploys the weapon in 1st barricade of sandbags (or: Sniper on the near building) nearest the spawn area of your own team, when his army is fully advanced, taking the offensive (therefore, have an advantage and is attacker), and about to conquer the last enemy flag. It is assumed that at this circunstances an MG or Sniper would be more required in the middle of the map (to keep the territory achieved) or at the end of the map (to support completion of the battle: fire-support), but not on start of the map, because it makes no sense... Obviously, a Mg or Sniper can deploy weapons in the first sandbag (or first window, or first building), near the spawn area of the team, but only when it is appropriate, as in the case of the friend team being at a disadvantage (the offensive belongs to enemy army), maybe having only one flag to defend... .
If, however, this feature is improved in Rcbot, the (cap)ability of the bot (MG or Sniper) choose more or less randomly, the deployment point, it should be preserved. Unless this random choice consider PRIMARILY the datas "where is the front-line, more or less, in the present instant" and "where is the flags are being disputed/quarreled" and "where fighting is concentrated". I particularly love and enjoyed this feature (randomness in choice of deployment point) because it makes the game less predictable. I think until this feature must also be improved with time.

7.2. Sometimes the bot that controls the MG or Sniper, (Sniper especially!), when fixing a position, let your own body very exposed to enemies, and so it becomes easy target. This aspect is less common in MG-bots because they crouch a bit at the time of deploying, but is very often and common on the Sniper cases. The Snipers have the (bad) habit of staying in the "standing" posture, at time to fix position, rather than crouch or in prone positions. I think the Snipers can use the "standing posture" when strictly necessary to kill an enemy, but should always stay crouched or prone when these two positions do not disturb your sight.

7.3. There are some small implementation bugs that must be fixed. I will cite a fact: MG-bot goes to the point of deployment to fixed position, and the choice of posture in the waypoint is established as "prone". To meet the specification, and fix the mg-gun, he stay in prone and not can see beyond a salience or corner that is capping his vision, however it remains fixed and the tip of his head is exposed to enemies. He does not see the enemy and can not fire his weapon against him, but the enemy sees the tip of his head - he is then shot down, despite owning a powerfull Machine-Gun MG... Another example occurs when the MG-bot lies behind a sandbag and decides to implement the gun right there on the ground: so, the sandbag impairs vision of MG-bot preventing him from realizing the enemies. There are other examples, such as the Snipers (can happen with MGs too...) who choose fixed position in buildings (eg: towers) with more of one chance of implementation (different angles of vision). In this cases is common that the Sniper select the worst possible direction in these buildings, getting their back to the movement of enemy troops - ignoring the risk of being killed by a shot hiting their back. Apart from the risk of dying, by doing this, the Sniper does not contribute to the team, and misses opportunities for intervention.

7.4. I felt missed of firearms-implementations (MG and Sniper) on the ground (in "prone" stances), at the same time: FIXED AND RANDOM; and not only on sandbags, or windows, holes, towers etc. With this option (more implementations in prone), I think the game would be even more unpredictable and Snipers and MGs would surprise us with a much higher frequency. At this point the Sturmbot is very similar to the Rcbot: by default, the MG-bots and Snipers do not establish fixed points on the ground for a long time, but are able to go in prone when they see the presence of enemies at distance, in order to kill opponents with accuracy. In both bot-systems, shortly after eliminated the threat, the MG-bots stand up again and continue the route/travel. Personally, I think implementations on the ground, both FIXED AND TEMPORARY, should exist in Rcbot2 for both classes "MG" and "Sniper" (maybe extend the option for Bazooka / Panzerschreck).

7.5. There is an important problem with the implementation of fixed MGs (not sure if the same happens with the Sniper class) in Rcbot that DESERVES TO BE CORRECTED. This problem is closely connected with the discussion of the items "1.1", "1.2" and "2". This is a nonexistent problem in Sturmbot.
I'll use a real example that happened to me in testing: after I see an MG-bot (enemy) fixed in a window on the top floor of a house, I managed to escape from their radius of action (mg-gun), and i walked around the buildings for the purpose of reach the 2 story house. I climbed the stairs and positioned myself just behind the MG-bot, but I did not kill him. I chose to do a test: i approached him to touch my weapon on his back, but he did not retaliate me, he continued in the window watching the movement on the outside. Then I pulled away again and ran toward him touching my gun back into his shoulder, again he did not come out of its fixed mg-position. I pulled back a little, again, and i started jumping, gave several jumps, but the bot did not move, ie : not "listened" my noises and failed to notice my presence there, right behind him. So, i chose to employ another test: i open fire on wall close him (his right side), but without hit the MG-bot, and he did not leave the fixed position to react against me (in a real combat situation or PC games between humans, anyone would have heard the shots and perceived ballistic impacts, not counting the previous sound of my footsteps coming up the stairs, approaching, or heels that i perform behind the enemy). I could only move the bot from there and force him to react against me, when I approached him again, put the gun in his back and walked towards his right side until I touch the wall where he was positioned. Once I touched the window, i immediately noticed that the bot finally dropped the fixed position, and turned his body toward me with some speed and killed me.

This example illustrates the IMPORTANCE OF ADOPTING the features discussed in the previous items, particularly the items "1.1", "1.2" and "2" !!

8. Brief note on forming squad

I am aware that mr. Cheeseh is working with the forming of squads to Rcbot2 (Dod: S), from the knowledge of this function in Rcbot1.
I think, and i suggest, that the formation of the squad on Rcbot2 should be FLEXIBLE and not rigid. In Sturmbot is flexible. I explain better: the formation of squads should not restrict the independence/freedom of bots that are following the bot-leader (or human-leader), like it is in Sturmbot. The bots should still retain some ability to autonomous choices (and make some decisions for themselves), according as development of the combat situation. Moreover, the bot can make the decision to leave the squad immediately when they notice that their squad is being huge decimated, or is in big danger, through the fault of the "decisions" of the bot-leader/human-leader. This is my opinion.


9. Latest considerations.

I reiterate the suggestions I made in the previous posts: study the entire system-Sturmbot, adopt the existing features in it, and go slowly perfecting each resources. Start by installing the Dod-Classic with the last version of Sturmbot (version 1.7), then analyze the behavior of bots in several different combat situations, and several maps. Reserve you the changelog-history of Sturmbot for reference. Make notes.

There are still many VERY GOOD features in Sturmbot that are missing in Rcbot2, to Dod:Source. Personally, I think ALL of them should be considered: implemented gradually, one by one, in Rcbot-system. After this: improving each one resources, also gradually, to a satisfactory point. For more information, please, i ask to all to reread my last considerations in the post: http://rcbot.bots-united.com/forums/index.php?showtopic=1709 .

I have in mind that the Rcbot2 to DoD:S. already made TREMENDOUS PROGRESS.
All my comments are intended to assist in the development of Rcbot2 for years to come.
With these analysis and suggestions, i hope, i intend to contribute to the development of Rcbot-system (Dod:S), including the first full-version of the program (non-beta version). I ask all developers (mr. Cheeseh and partners) to consider these my posts for the future, with attention, even after the release of a non-beta versions (in the case of not yet being possible to implement all these ideas described above).


If i happen to remember more things, i return to post to this topic.



THANK YOU VERY MUCH !



I leave a reproduction of this topic attached (format .zip)

-------------------------------------------------------------------------------------------------------------------------------Attached File  Topics___rcbot.zip ( 27.58k ) Number of downloads: 405
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



- Lo-Fi Version Time is now: 24th May 2024 - 05:49 PM