How to create "clever" bots:
-------------------------------------
I won't pretend to have THE knowledge on "how to create clever bots", but if you follow my advises, you should obtain rather good results. And "all this" without to use special scripts...
The creation of clever bots is rather "tricky", mainly because a lot of factors will act on a bot's behaviour... Those factors are: the scripts, the waypoints (and their linking), the environement and the inter-action between the bots. It's only by optimizing ALL those aspects to the maximum that you will create the bots you are searching for! Be sure that if you only rely on your scripts, you will fail in your...mission! lol
Note: The next informations are ONLY based on my own experiments and observations, with the help of the SDK, written by Shigor!
The scripts:
Let's say that the scripts will set the "character" of your bot. It's by mean of your script that you will create an attacking or defencive bot, careful or not... It's important to give a specific "mood" to your map by giving your bots the right behaviour. If they have to defend a VC base, don't give them too much "attacking power" for example...
Usually, I'm setting 3 kinds of scripts for 3 kinds of bots (those "informations" will be stored in the .inc files). A "covering one", a "normal one" and an "attacking one", but you can create more type of bots of course...
- The "covering bot" will usually stay more at his place, and will provide "covering fire" for the other bots... That bot will be equiped most of the time with the machine guns. I advise you to increase the shooting precision of such bots.
- The "normal bot" will have neutral skills, able to act as an attacker or a defender. He will probably be the main bot of your map. I advise you to set a normal shooting precision of such bots.
- The "attacker bot" will be the most "daring" of your bots, not fearing the death and able to put you in big troubles (give him more "running skills",lol)! I advise you to decrease the shooting precision of such bots (he will run more often and so, should be less precise).
Note: It's important to NOT give a bot too much skills in a specific behaviour otherwise he will become...predictable! A "covering bot" must still be able to "jump on you" if he saw you were behind a wall for example!
Here are examples of the possibilities you can add to your .inc file, in the: SC_P_Ai_GetProps(info->pl_id, &props); section.
Note that I've just copied those informations from another source (based on the SDK) I lost the trace. I may update those informations myself in the future...
//props.max_vis_distance = 120 // maximum visual distance the AI can see, if not specified, AI uses maximum visual distance specified for the level. //props.watchfulness_zerodist = 2 // how good is AI at recognizing the enemy at zero distance. //props.watchfulness_maxdistance = 1 // how good is AI at recognizing the enemy at maximum distance. //props.boldness = 1 // this is used to determine how bold is the AI when in cover and under fire. 0.5 is very cautious player, 2 is medium, 4 is high. 10 is almost suicidal, the AI will not give a damn if someone is shooting at him. //props.coveramount = 0.5 // how far the AI will run for cover compare to the distance to the closest enemy, default is 0.5. //props.hear_imprecision = 1 // imprecision of the AI’s hearing. 0 absolute hearing, 1 average, 5 very bad. //props.hear_distance_mult = 1 // hear distance multiplier – 0.5 is half, 2 is two times better. //props.hear_distance_max = 1000 // maximum hearing distance. //props.grenade_timing_imprecision = 2.5 // this is maximum time (will be randomized) between impact of the grenade and its explosion. //props.grenade_throw_imprecision = 1 // imprecision of the grenade throwing. 0 perfect, 1 average, 2 quite bad. //props.grenade_sure_time = 10 // how long the AI will wait until it’s sure the situation demands a grenade. //props.forget_enemy_mult = 1 // how fast will the AI forget the enemies it has no more contact? 1 is default, 0.5 means two times slower, 2 mean two times faster. //disable_peace_crouch = 0 //BOOL // this disables AI crouching in the peace mode. //props.peace_fakeenemy_run = 1 // this is used to set the movement type under the fake enemy situation. 1 means always run, 0 always walk, 0.5 use run/walk 1:1. //props.peace_fakeenemy_phase = 0.5 // same as previous, only for the stand/crouch. //props.shoot_while_hidding = 0.3 // if enabled the AI will shoot even when moving to the hide out. //props.aimtime_max = 0.7 // maximum time for AI to take an aim, default 0.7 seconds //props.aimtime_canshoot = 0.1 // minimum time for AI to take an aim, default 0.1 seconds. //props.aimtime_rotmult = 0.5 // multiplier of the rotation speed when aiming, default 0.5 seconds. //props.wounded_start_perc = 0.5 // value of the current hp/max hp when the AI aiming starts to be worse //props.wounded_aimtime_mult_max = 2 // multiplier for the maximum aim time when hit points of the AI is zero. //props.wounded_shoot_imprec_plus = 0.5 // multiplier for the maximum aim imprecision when hit points of the AI is zero.
The waypoints:
- If the script will be the "brain" of your bot, the waypoints will be his "feet", or the roads! It's thanks to the waypoints that the bot will move. He won't exactly follow the waypoints but their positions on the map are VERY important for "a good move". For example, you can fix a "moving bug" (bot that can't pass a log by jumping all the time against it) by just moving the position of a waypoint a little bit "left or right", or changing its linking!
- Also, you're not obliged to entirely cover your map with waypoints. Pterodon's maps are, but don't forget those maps have been mainly used for the solo campaign, or for the "quick fights" mode. Your "AI" mates should be able to follow you anywhere on the map!
For the coop mode, I advise you to place your waypoints (and link them together) only in areas where you want to have fights. It will also help to keep your bots in those specific areas by "closing the path" and leaving empty places...
- The waypoint will act on a bot like a magnet also. If the bot "feels" a "hide out" place is in his "surrounds" (it can be set in the script), he will be directed to it to find...cover!
- You can also "obliged" a bot to go in certain directions "only one time", by linking the waypoints by pressing the [shift] key at the same time. It will be a "one way" linking. Depending of the direction the bot will "randomly" chose, he can go in completely different areas!
In this example (1), you can see how to avoid that a bot tries to go back a "hide out" waypoint on the hill once he went down of it. If you don't set a "one way link" and if the hill is too high, then, the bot may try to climb the hill by jumping continiously at the same place!
The environement:
- Give your bots "covers" to go hide behind! Each time you will place an object on your map, the Editor will (re)calculate the collisions; and those will be detected and used by the bots. It's important to test those covers like if you were going to use them for yourself. If a bot is continiously shooting into a rock (or a log or whatever), place it a little more into the ground or decrease its "Z" axe of few %, to "clear" the sight of the bot...
- Also, don't forget to correctly place your waypoints depending of the covers. The position of a "hide out" waypoint may completely change the "cleverness" of your bot because he will then use that cover for the best!
The inter-action between the bots:
- Bots from inside the SAME group will communicate together. I still haven't determined what was the "speaking distance" but as long as 2 bots are close enough, they will exchange informations about you, like your position. It partly explains why, sometimes, a bot is able to nade you even if he hasn't saw you personaly. A "bot's mate" probably told him where you were! lol
Note: It's a false idea to believe that a bot will only nade you because you nade him before. In fact, a bot will nade you if he knows you are "there" but can't shoot at you "the normal way" (with a gun). It seems that a bot is also able to see from where the "US nades" are coming from, and so, nade you back!
- If you spread 2 bots of the same group too much, they will stop to communicate and won't be able to set "tactics" anymore... It's very important to THINK where you will put your bots on the map, to make them act like you want!
You can also have a kind of "random" bots' behaviour by spreading your vc group cleverly on the map. For example, if you kill the "central bot" of a group of 7 bots, spread on a line on a map, you will also "kill" the communication between the other bots... You may have now created 2 vc groups of 3 bots each!
- If you set your scripts correctly, an "attacking bot" is able to move if the "covering bot" succeeds to force you to stay in cover, and so, unable to shoot on the bots. It explains on some of my maps (like VC_Storm_II) why you can be "surpassed" by the bots the more you will lose mates. The "attacking bots" won't be under fire anymore (or less) and will dare to advance because their "covering bots" will maintain you under fire, unable to reply! The next time you will "pop up" your head, you may find 5 or 6 bots in your sight! lol
- Bots are also sensible to guns' sound, and each gun has a "hearing distance" (same as the human one?). If you shoot with the M60 for example, you will activate more bots "inside the area" because its "sound range" is wider, compared to a M16 or a Thompson. Your first shots will act as a trigger...
You have to understand that it's the addition of all those "features" that will make your bot "clever" because he will be able to use them depending of the situation. Those informations will "feed" your bot with "intelligence" (scripts, waypoints, surroundings, AI mates...).
The more you will give your bots "possibilities", the more they will surprise you by creating their own "artificial tactics", to mislead you!
How to optimize your map:
-----------------------------------
The optimization of a map is almost never made by mappers but I really advise you to apply it to your scene, even if it's a boring task to do that can also be very tricky to set!
The better will be the fps of your map, the more she will be played, even for those with a very basic pc!
I would say there is 3 ways to optimize a map:
- By linking objects to dummies.
- By using the "clipping option" of an object.
- By using the "clipping option" of an object LINKED to a "clipping dummy".
The Dummies:
The dummies can be used for more "things" but usually, we are using them to optimize the map, to have "better" fps and to help the Ptero Engine to be more efficient.
This is what is written in the the Editor's help file:
Dummy is an auxiliary object used for scene optimization, scripts and other purposes. When an object is linked to a dummy near it, the object tree search is faster, thus the game itself performs better. A dummy has a variable called "clip distance" which determines the distance from which the dummy and its children are not drawn anymore.
It's not really that the fps will be "better" but let's say that if a map has around 25 fps in the scene... With an optimization, the scene will still be smooth by moving the mouse. But without an optimization, with the same 25 fps, you will feel "stutters" (like a lag) in the scene!
So, the "main idea" is to put some dummies above the map (like +5 meters), seperated from each others by around 20 meters, to create "a grid" (it's up to you to "feel" the distance and the place)... Now, select all the objects in the surrounds of a dummy and click on the "link tool (P)" (11th icon above the toolbar). Now, click on the dummy and all the selected objects will be linked to it (1)... Repeat the operation as much as possible... If you made a wrong "click" and linked objects to the wrong "dummy", do the same but use the "unlink" tool instead (12th icon) and all your objects will be "unlinked"!
Clipping of an object:
If you can "clip" objects in the scene (we must NOT see those clippings, when we aim for example!!!) then, you will gain the fps... Because an object not drawn in the scene won't be "calculated" by the game's Engine! In this example at NuiPek (the view is from under the map), you can see that despite I gave the objects their own "clipping distance" inside the TOC bunker, I linked them to a dummy (2), having its own "clipping distance" (3)... The objects aren't not only drawn but also optimized for the game's engine "search"!!!
Usually, we are using those "clippings" with objects inside huts, houses, caves... Because of the shorter distances in such places, those objects would be real "fps eaters" if you let them at their full "view"!
...
Clipping of an object linked to a dummy:
In this last example, I'm showing you how to cleverly use a dummy in certain circumstances... In the first picture, all the selected objects (red frame) are linked to the dummy at the extreme right (green frame) (4). If you're wondering why I made such an "unusual" linking, the explanation will be in the 2 next pictures!
The PoTlongKarai (NVABase) map is very tricky to optimize because the scene view distance is rather big (above the 100 meters) and the "direct view" on some objects can be completely different depending of the place we are looking at... That's why it's very important to "analize" the map to find the best "compromizes". So, in the trench (at the respawn), the view on the trees and the bushes at the end of it is "direct" and at "full distance". However, once we quit the trench, it's not really a problem anymore because those objects are closer of the players. The "trick" was to link those objects to a dummy "outside" of a normal position and set to a distance of 100 meters (in this case). But because, in the trench, we are still "inside" of the 100 meters range of that dummy, the clipping can't be seen by the players at that place...
In the next picture you can see how despite the clippings of the objects are set to the maximum, they WILL "clip" once we have passed the wall to the next part of the temple, because they have been linked to the dummy set "outside" of the map (5)! Because of the presence of the wall, all those objects weren't visible anymore and so, had to be "clipped" to gain fps! If I hadn't used that dummy, it was impossible to make the objects "clip" differently depending of the area we were moving on (6). The objects were affecting all the areas, even if we weren't seeing them anymore...
Note that the same "trick" is used for all the objetcs in each area "behind" the wall, and the biggest difficulty was to find WHERE to place those "special dummies" for the best optimization!
It's complicate to explain but I hope the pictures will help you to understand what was my goal...
I'm rather pleased to have you explained "this" because all that looong and booooring work CAN'T be seen by the players when they play BUT it had to be done! It explains you also why it takes me soo much time to update an original map to a VC_ or FA_ level because all my "editions" are full of those "unseen tricks"! lol
...
Under Construction (this post may still be updated in the future)!
How to correctly name and write your modes:
-----------------------------------------------------------
It may be just a detail but to help the players and the understanding of your "mode", I really advise you to follow the "naming process" Pterodon chosed from the start...
For example, the CTF mode we all know is for Capture The Flag, the RW mode is for Real War...and our dear Coop mode is for Co-operation. Note that in this last case, it has no real sense to call a mode just "C", that's why we have added the "oop" letters to the first one (and it's shorter)! lol
However, we have seen many different "unlogical" Coop names, like COOP, CooP, or whatever...
So, if we follow the original "naming process" created by Pterodon, a COOP mode would mean something like this, Co-operation Of Our Partners (COOP)... But if that Coop mode is globaly like the one we all know, it's a "wrong naming"!
So, be very careful when you create a new mode (or not) by respecting some "rules" to be sure it means "something", like Don Turtuma made it very well (just an example) by naming his new King Of The Hill mode... KOTH!
Under Construction (this post may still be updated in the future)!
How to correctly name and set your vc scripts:
-------------------------------------------------------------
As I've already said, I'm not a scripter and my knowledge is mainly based on trials, errors and comparisons... However, with the time, I think to have succeeded to find the best way to correctly set the vc scripts to avoid errors. I've read many times that if we uncorrectly set those vc scripts, it may create troubles and crashes!
So, I'm explaining you my way to set them correctly, by avoiding mistakes you could do. And the only thing I'm pretty sure is, your vc scripts will be stable!
The naming:
- To add a vc bot, we need to add a new "player" to our scene, and the editor will use that name as default (Player, Player#1, Player#2,...). However, I strongly advise to change that name with informations written "inside" the scripts we will use. It should be a lot easier to select the script we need to change during our future tweakings.
- Now, let's have a closer look on that naming process:
vc01_01_00_A_AK47_N.c
vc01:
vc01, vc02, vc03, vc04,... The number of bots our map will contain, simply. Don't forget we can't exceed the maximum of 64 "players" (vc bots + real players) or the game will crash!
01:
01, 02, 03, 04, 05. The ID_GROUP of our vc bot. The default number used in the level.c file is 5.
00:
00, 01, 02, 03, 04,... The ID_MEMBER of our vc bot inside its own group.
A:
A, B, C,... These letters will show what kind of .inc file we may use for our bot.
For example we can set 3 different .inc files to have different bot's behaviour in our map. A for vcattack.inc, B for vcbasic.inc and C for vccover.inc
AK47:
AK47, SKSS, DEGTA, PPS41,... This information will simply show you what kind of gun we assigned to the vc bot.
N:
N, to indicate if we assigned (gre)nades (or not) to the vc bot.
And if we open the first script: vc01_01_00_A_AK47_N.c , this is what we will see:
With all those informations, we can directly know what's inside our vc script, without to have to open them one by one.
The setting:
- Let's imagine we decide to add 30 vc bots on our map, in 5 different groups... All the vc inside the same group will act independently from the other groups but those vc will exchange "informations" (like your position) between themselves.
So, without to have a look inside all the scripts, here is the list of the scripts we will have:
How to create "healthy waypoints":
----------------------------------------------
The symptoms:
- To create a Coop map, you will need waypoints for your bots to move and behave correctly. However, after all those years in mapping for Vietcong, it's only recently that I discovered how important it was to have "healthy waypoints and without errors", to avoid many troubles! Whatever the care you will take to correctly place them on your map, it's almost impossible, from "a human point of view", to know if the game will support or not the errors from the waypoints... The Editor and the game won't complain. The map will be finalized normally but it will be "infected" for sure and will start to behave strangely
Depending of their number and kind, those errors will create bugs and crashes like, for example:
- Missing classes at the selection.
- The server will crash when the map has loaded.
- The game browser shows a server full of players when it is not the case.
- Players can be kicked or banned from a server for cheating after the map has loaded.
- The game can crash when a player tries to rejoin a server he just left.
- And many more...!
It has been a real pain to finally discover what was causing all those troubles because nowhere in the SDK, I remember to have read how it was essential to have waypoints without errors, to avoid troubles. And because they are apparently creating what I can call "random bugs", I had no idea waypoints could be the culprit of all that mess!
The fix:
1) First, let's start with "the basics":
To place a waypoint on your map, select the "Place" panel in your Editor panel and select the "waypoints" in the dropdown window, then just under, select the kind of waypoint you want to place on your map, "normal", "hideout" or "noshortcut"... Next, select the "Placeator" tool in the Toolbar and place a waypoint by clicking the "Tool Icon" on your terrain. The waypoint is now placed on your terrain. Repeat the operation for each waypoint on your map (max 2.500!).
2) Second, let's continue with the more "complicate part":
Once all your waypoints are placed on the map, link them together by using the "link at" tool... Select a waypoint > select the "link too"l and click on the waypoint you want to link your selected waypoint. I advise you to observe how "Pterodon" made, to link your own waypoints together as an example.
Notes:
- Freeze your terrain first. Edit > Freeze Dialog [F] > select your terrain > Freeze
- To work with waypoints, don't forget to set them before with: [Ctrl] + [H] (keys) > tick the waypoint box and, View > Show > WayPoint paths.
- Don't cross the waypoints' paths (links) together...
- If you accidently linked a waypoint to an object, use the unlink tool. Toolbar > Unlink, and repeat the process to "reverse" the mistake.
- A waypoint can't be linked more than 6 times to other waypoints.
Comments:
- It is VERY important to ONLY link a waypoint to another waypoint and nothing else, otherwise you may start to have an "unstable map"! But the real problem is that the Editor is not very "friendly" and during the "linking process", a waypoint could be linked to another object, even though you haven't made it yourself "by mistake". If you are used to work with the editor, you probably already noticed that sometimes, after to have made an operation, the Editor will directly select another object, or many others "by default". And I really believe that the same "bug" is happening with waypoints when we link them together and because it goes very fast, we never notice it may be also linked to an object!
- Trick: After to have placed your waypoints on your map and before to link them together, you can already check if they have been linked to "something" by mistake by pressing the [Home] key and by ticking the "Scene tree" box, in the Display panel. By doing this, the Editor will show you if a waypoint(s) has been linked to something if "a space" exists in the waypoints' list or if a waypoint is placed under an object's name... > In that case, it means a waypoint(s) has been linked and must be unlinked from that object!
- It's also important to be very careful because once a waypoint will be linked more than once, the visual "trick" won't be working anymore for the waypoints and so, very hard to visually spot the "corruption(s)"!
3) After to have linked all your waypoints together, it's time to check the errors only the Editor will be able to find.
Place your cam above the terrain, in an "empty area" without objects to obstruct the creation of your player. Press F8 > Shift F9, to create the default Hawkins player, then > Game > Waypoints tester. In the small window panel, the "1)Waypoints placement" and "2)Ways between wps" boxes are ticked by default, probably because they are the most important ones... Start the test and wait till the errors that will be found are written in your wptest.txt file (in the main Vietcong folder). If you have a "popup window" that will appear during the process, click on the "ok" as long as it will be needed and NEVER stop! You may think the Editor has crashed but if your map is full of errors, you may have to "click" hundreds of times.
If the Editor found errors, you can usually fix the waypoint(s) by slightly moving it "away" from its original place or change its linking(s). But because there is no "defined rule(s)", it's up to you to find what could be the cause of the error(s)... Repeat the process till no more errors are found.
4) Once your waypoints have no more errors, you can tick the third box to calculate the "3) Extended ways"... Because that box is not ticked by default, I'm not sure it is essential to make that test but let's stack all the odds in our favour by doing it anyway! ;). And if I propose you to do it only after the 2 first, it's because that test seems to be a lot more "sensible" to editor's crashes!
The process is the same as in "point 3)" but from my own experiment and if I remember correctly, the errors that will be found are only those from waypoints linked to another object... The real problem is that apparently, there is a bug in the Editor that will constantly link those waypoints to their objects, even after you unlinked them from. And it's very difficult to fix that! I tried many of my "tricks" but very few if not any are working because the Editor's bug will "take over" to re-link the waypoint(s) to those objects.
Usually, some of your waypoints will be linked to your terrain (that's why I proposed to freeze it in the upper "notes") but if it can't do it, The Editor will decide to link them to your "!World sector!" instead!!! If you're facing such a problem, the only solution I found so far is to place those waypoints above your terrain (no "physical contact" with) before to un-link them from it. Save and restart the test...
IMPORTANT NOTE:
It seems evident that the Editor has a bug during the linking process! In fact, I noticed that the wrong linkings ususally happen during "the transitions" of the "cursor tool" when we pass the mouse from the upper "Toolbar" till the main "Editor' screen"! At that exact moment, the Editor may link the selected waypoint to the first object your cursor will fly over (usually the terrain). Because we can't avoid such a mouse movement, the only solution I found so far is to ONLY use the keyboard shortcuts for such a task. In our case, the [S] key to "Select" the waypoint and the [P] key to "Link at"... It won't fix all the linking troubles but your work should be a lot "safer" and with less errors!
Comments:
- During all those tests and depending of the kind of errors that will be found, the Editor may crash or have strange behaviours like "freezes" (program not responding message) but don't worry it's rather "normal"... Don't jump on your "tasks bar" to kill the Editor. Let it work! It may take many minutes of calculation.
- After the test is completed, press again on "F8" to go back in the Editor's mode but here again, sometimes it may take a long time before the Editor is working again...
- Before a waypoints test and because the Editor may crash during the process I advise you to save your map to record all your changes or you will have to re-do all your fixes!
That's it! It's all for the moment...
I really hope this "how to" will help you to have Coop maps free of bugs and strange behaviours and if you have or know maps having problems, CHECK the errors in the waypoints!!! Don't forget that I've been able to already fix 3 maps, having 3 different kind of bugs, by just correcting the errors in the waypoints!
Under Construction (this post may still be updated in the future)!
x 7
x 1
x 1
x 1
x 1
x 1
x 1