Behind The Scene: Civil
The DraggableIsoItem and IsoDropZone classes are responsible in dragging and dropping building blocks. Each building block has a DraggableIsoItem script and each tile that can have building blocks placed on it has a IsoDropZone element.
Each DraggableIsoItem has a name in string (e.g. road, bridge, corner, three_way_intersection, four_way_intersection), a reference to an IsoDropZone that will be registered when the DraggableIsoItem is dropped in the IsoDropZone.
While each IsoDropZone has a list of droppable names representing the names of the DraggableIsoItems that can be dropped on this zone.
The drop zone only allows items whose names are in the droppable names list to be dropped on it, this is where we implemented the placement rule. The use of names and droppable names list makes the placement rules flexible and extensible, that the placement rules on each individual tile can be specified while we can also specify the rules on a group of tiles (by selecting those tiles at once in Unity) easily, also it allows new building blocks and placement rules to be implemented easily without changing the code.
These elements are controlled by three classes - DraggableIsoItem, IsoDropZone, and CivilLevelController.
Each DraggableIsoItem has an item price which is the price of the building block.
For building block factories, each factory has a IsoDropZone script, that has prefeb name which is the item it will make, and also the price of the item.
Besides, the factories are all tagged with the "TileFactory" for the CivilLevelController to get references to them.
While the trash can also has a IsoDropZone, but its IsoDropZone will have a boolean "returner" been set to true.
Besides, the CivilLevelController is the class that storing and managing the budget.
Whenever a prefeb is removed from a drop zone and dropped to another drop zone, the old drop zone will call the CivilLevelController to deduct the budget based on the item price registered on this drop zone. A normal ground tile has 0 registered while a factory has the price of the item it produces registered on its IsoDropZone. Here is when and how the budget is deducted when a building block is dragged from the factory and placed on a ground tile. While for trash can, if a DraggableIsoItem is dropped on it, it will call the CivilLevelController to increase to budget by the price registered on the DraggableIsoItem, and set the game object of the item to be inactive. Thus, the building block dragged and dropped to the trash can is removed and the budge of the item is back.
On the CivilLevelController side, the controller maintains references to all factories by searching for "TileFactory" tags, and whenever the budget is updated, it will run through all factories, test is the budget enough for the factories to produce their building blocks. If the budget is not enough for a factory, the CivilLevelController will then disable the factory, and re-enable the factory when the budget become available again.
For path finding, based on the Ultimate Isometric Toolkit's GridGraph and AstarAgent classes, we implemented a CivilCarAgent extends the AstarAgent, modified the GridGraph, and created a new classes called GoalAgent to realize the automatic path finding and car driving in our civil mini game.
In the GridGraph, we added a list of customizable travelsable tiles, containing strings representing the names of the DraggableIsoItems that a car can travel on, and also a boolean "UseTravelsableTile" indicating should the grid graph use the travelsable list to define travelsable tiles, or use its original implementation. In the civil mini game, we set UseTravelsableTile to true, and in the traversable tiles list, we add all names of the DraggableIsoItems that a car can travel on, so that the grid graph will create a graph that only on the building blocks placed on the map when we ask it to.
In the CivilCarAgent, we made a field "Type" to indicate the type of this car (e.g. blue, red), and on the map there will be corresponding goal tiles having GoalAgent scripts with matching goal types (e.g. blue, red). The base class of the CivilCarAgent, the AstarAgent has a Graph field that link to the GridGraph that stors the travelsable graph information. We implemented the CivilCarAgent such that it can be called by the CivilLevelController to move to their corresponding goals by using the methods in the AstarAgent and the GridGraph. Besides, we also modified the AstarAgent to make it being able to detect the direction it is moving so that an animator can use it to create the animation.
The modifications we made to the AstarAgent and the GridGraph are in a way that not specifically designed for the civil mini game, to still allow the two classes to be used in any other part of the game if needed.
The road rotation checking is used to detect incorrect placements of the building blocks due to their wrong rotations. The GridGraph and the RotationUtil classes are used to detect this, while the DraggableIsoItem is the classes that stores the rotation direction of the tile and the corresponding sprites.
In the GridGraph, we added a field RotationUtilInstance to link to a RotationUtil object that detects the adjacent tiles beside a tile and the ones that have invalid placements among these adjacent tiles, and a boolean "CheckRotationOfTiles" to indicate should the GridGraph use the RotationUtil. If the CheckRotationOfTiles is set to true, the GridGraph will run through all the travelsable tiles, use the RotationUtil to detect any tile that breaks the route, and remove those tiles from the graph.
The RotationUtil is an abstract class with two methods - GetAdjacentTiles, and GetInvalidTiles. We implemented a concrete class CivilRotationUtil that extends that RotationUtil abstract class that finds the adjacent tiles of a tile in four directions (NE, SE, SW, and NW in the world space, which are top, right, down, and left in the isometic world space), and detect any invalid placement of a road or bridge, or the roads, bridges, corners, or three way intersections adjacent to the road or bridge. Once the road or bridge itself is invalid or on side of it is placed in an invalid direction (the road cannot match up), the road or bridge will be added to the invalid tiles list to be removed.
The (rotation) placement rules are implemented case by case, for example, for a road or bridge facing NE or SW, a corner placed in NE of the road or bridge should directing NE or SE so that the roads can match up, if the corner cannot match up with the road or bridge, the road or bridge will be marked invalid, which means it breaks the route, so it will be removed from the graph, as the car cannot move into the corner through this road tile.