{"__v":1,"_id":"554f03de1bc7d20d0045858c","category":{"__v":8,"_id":"543b9ef065bf840e00b473e0","project":"543b9b0065bf840e00b473d5","version":"543b9b0065bf840e00b473d8","pages":["543b9f11b1479b1400c42f58","548a78adb77bb70b00ac8c10","55082e75c79a211900a8de1b","55083e4e31eeba2d00d66a2d","550bfa9022ccb01700a79466","550c312a5fdefb19003d1201","554f015d1bc7d20d00458588","554f03de1bc7d20d0045858c"],"reference":false,"createdAt":"2014-10-13T09:44:16.284Z","from_sync":false,"order":4,"slug":"pvp-battles","title":"PvP Battles"},"project":"543b9b0065bf840e00b473d5","user":"543b9aa865bf840e00b473d1","version":{"__v":11,"_id":"543b9b0065bf840e00b473d8","project":"543b9b0065bf840e00b473d5","createdAt":"2014-10-13T09:27:28.467Z","releaseDate":"2014-10-13T09:27:28.467Z","categories":["543b9b0065bf840e00b473d9","543b9ef065bf840e00b473e0","54890012f291f61400c02d36","54890902f291f61400c02d3e","54890c43f291f61400c02d44","54890d71c178b40b00aa3086","5508125c0c4d8c19008a5f83","55094050961f17170070abbd","550945111c38c50d006118ad","550a4c2e42fff40d00ae6049","55221c074801a40d00a77610"],"is_hidden":false,"is_beta":false,"is_stable":false,"codename":"","version_clean":"1.0.0","version":"1.0"},"updates":[],"createdAt":"2015-05-10T07:08:14.670Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"auth":"required","params":[],"url":""},"order":6,"body":"One of the most complex components in the startup kit is the Helios AI (we initially called it BattleProcessor). His purpose is to coordinate and centralize, as much as possible, the operations regarding the attack of another city. The idea behind this was to reduce the processing load necessary for the units to individually keep track of their goals, since we expected it to become a problem/add up when hundreds of units are instantiated.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Helios handles diverse situations such as:\"\n}\n[/block]\n- A new group of units is instantiated – the nearest building location is sent to them to attack\n- A building is destroyed – the unit groups attacking the building are reassigned to another target (if any)\n- The user selects a building – the nearest group of units is ordered to attack the new target\n- The user selects a group, and then points to a building – the respective group is sent to attack that building\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Other functions of Helios\"\n}\n[/block]\nIn addition, Helios performs smaller functions, like processing the loot as the buildings are damaged, keeping track of battle end conditions, retreat orders, destroyed units, ordering cannons to fire when a building is under attack, etc.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://www.filepicker.io/api/file/iz96LZHiSbOFC7WklgJH\",\n        \"moving-units-helios-ai-battle-processor.jpg\",\n        \"800\",\n        \"600\",\n        \"#72aa34\",\n        \"\"\n      ],\n      \"caption\": \"Group orders\"\n    }\n  ]\n}\n[/block]\nThere are several optimizations in place:\n\n- Sending the new targets to units is done in sequence, so the units don't look for their path all at once\n- All the calculations are done at 1 second intervals.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Unit Lists\"\n}\n[/block]\nThe units are kept in lists – one general list, and then individual lists for each group. Most operations require processing only one of the groups, but there are orders that are passed to all.\n\n- DeployedUnits – all deployed units, regardless of their group\n- GroupO, GroupI, GroupII, GroupIII\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"AITarget Cubes\"\n}\n[/block]\nEach grass prefab has target cubes and obstacle cubes – to send the units to those grid locations, or to mark the pathfinder grid properly with locations the units can not walk on. These cubes have their mesh renderers disabled, but they can be enabled so you can see them. The AITarget cubes are necessary for the units to know where to go – to which square in the pathfinder grid - to attack a certain building. Also there is a “surround” function who makes the units occupy each grid, starting with the nearest.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://www.filepicker.io/api/file/jIzCNKbwSledP2y1EJ5U\",\n        \"surround-function.jpg\",\n        \"800\",\n        \"600\",\n        \"\",\n        \"\"\n      ],\n      \"caption\": \"Bounds surrounding the object\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Unit Groups\"\n}\n[/block]\nThe position of each group is given by the first element in the list - GroupO[0] – this is a simplification, since the units can be spread on the entire map before attacking a building. They will all converge on the same building, chosen as the current target.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://www.filepicker.io/api/file/rAyIliwkSTi03IEaNBmc\",\n        \"unit-groups.jpg\",\n        \"800\",\n        \"600\",\n        \"#77aa57\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nThe targets for each group are kept in an array - \n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"targetBuildingIndex = new int[unitGroupsNo];\",\n      \"language\": \"csharp\"\n    }\n  ]\n}\n[/block]\n\nThis array will contain the building indexes under attack by each group, for instance {5, 12, 2, 4}. Since the user can both build and destroy buildings on his initial map, in which case the building index just grows, the building indexes are not necessarily in order, from 0 to the number of buildings. Since most of the lists in Helios are created on the fly when the map is loaded, there is a translator, who translates the actual building index, stored in the BuildingSelector, to the continuous list index (from 0 to total number of buildings) we have:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"GetBuildingListIndex(int buildingIndex)\",\n      \"language\": \"csharp\"\n    }\n  ]\n}\n[/block]","excerpt":"","slug":"helios-ai-battle-processor","type":"basic","title":"Helios AI Battle Processor"}

Helios AI Battle Processor


One of the most complex components in the startup kit is the Helios AI (we initially called it BattleProcessor). His purpose is to coordinate and centralize, as much as possible, the operations regarding the attack of another city. The idea behind this was to reduce the processing load necessary for the units to individually keep track of their goals, since we expected it to become a problem/add up when hundreds of units are instantiated. [block:api-header] { "type": "basic", "title": "Helios handles diverse situations such as:" } [/block] - A new group of units is instantiated – the nearest building location is sent to them to attack - A building is destroyed – the unit groups attacking the building are reassigned to another target (if any) - The user selects a building – the nearest group of units is ordered to attack the new target - The user selects a group, and then points to a building – the respective group is sent to attack that building [block:api-header] { "type": "basic", "title": "Other functions of Helios" } [/block] In addition, Helios performs smaller functions, like processing the loot as the buildings are damaged, keeping track of battle end conditions, retreat orders, destroyed units, ordering cannons to fire when a building is under attack, etc. [block:image] { "images": [ { "image": [ "https://www.filepicker.io/api/file/iz96LZHiSbOFC7WklgJH", "moving-units-helios-ai-battle-processor.jpg", "800", "600", "#72aa34", "" ], "caption": "Group orders" } ] } [/block] There are several optimizations in place: - Sending the new targets to units is done in sequence, so the units don't look for their path all at once - All the calculations are done at 1 second intervals. [block:api-header] { "type": "basic", "title": "Unit Lists" } [/block] The units are kept in lists – one general list, and then individual lists for each group. Most operations require processing only one of the groups, but there are orders that are passed to all. - DeployedUnits – all deployed units, regardless of their group - GroupO, GroupI, GroupII, GroupIII [block:api-header] { "type": "basic", "title": "AITarget Cubes" } [/block] Each grass prefab has target cubes and obstacle cubes – to send the units to those grid locations, or to mark the pathfinder grid properly with locations the units can not walk on. These cubes have their mesh renderers disabled, but they can be enabled so you can see them. The AITarget cubes are necessary for the units to know where to go – to which square in the pathfinder grid - to attack a certain building. Also there is a “surround” function who makes the units occupy each grid, starting with the nearest. [block:image] { "images": [ { "image": [ "https://www.filepicker.io/api/file/jIzCNKbwSledP2y1EJ5U", "surround-function.jpg", "800", "600", "", "" ], "caption": "Bounds surrounding the object" } ] } [/block] [block:api-header] { "type": "basic", "title": "Unit Groups" } [/block] The position of each group is given by the first element in the list - GroupO[0] – this is a simplification, since the units can be spread on the entire map before attacking a building. They will all converge on the same building, chosen as the current target. [block:image] { "images": [ { "image": [ "https://www.filepicker.io/api/file/rAyIliwkSTi03IEaNBmc", "unit-groups.jpg", "800", "600", "#77aa57", "" ] } ] } [/block] The targets for each group are kept in an array - [block:code] { "codes": [ { "code": "targetBuildingIndex = new int[unitGroupsNo];", "language": "csharp" } ] } [/block] This array will contain the building indexes under attack by each group, for instance {5, 12, 2, 4}. Since the user can both build and destroy buildings on his initial map, in which case the building index just grows, the building indexes are not necessarily in order, from 0 to the number of buildings. Since most of the lists in Helios are created on the fly when the map is loaded, there is a translator, who translates the actual building index, stored in the BuildingSelector, to the continuous list index (from 0 to total number of buildings) we have: [block:code] { "codes": [ { "code": "GetBuildingListIndex(int buildingIndex)", "language": "csharp" } ] } [/block]