Shapetopia is a card game with some city simulation elements aiming at opening a conversation about making the world more sustainable and a better place to live.
It is a semester-long project, and I am our team's programmer and game designer.
More information can be found at our project website:
You can try our game here!
Our three-member development team decided to divide all the tasks into three categories: a card system which includes deck builder and turns controller, a city simulation system which handles all the buildings' generation, cars and pedestrians' path-finding, and switching environment settings including fogs and camera filter, and also a UI system. My job was to figure out the city simulation system while assisting another programmer to build the card system.
In the gameplay play, we want to build mechanics so that when a certain card was played, a certain number of buildings or constructions will pop up in the city.
For example, there are cards in our game that can allow the player to construct new hospitals for the citizens. Also, there are other cards that only increase the economic level of the city which will result in more ordinary houses will be instantiated standing for the city is becoming increasingly prosperous.
To get started, I implemented a class called Grid which has several fields as shown in the right picture. Each cell is available for placing one building block.
Additionally, the class has methods that map the row and column value of the inside cell to the world position and vice versa, and also a setter that allows us to set the enum type of the its inside content.
Then, in the start method of the CityManager script, I created several Grids and put the cells inside different list according to the their content type. We can have a list of grids that contains ordinary houses, a list of grids that contains skyscrapers, etc. Thus, when I want to instantiate different buildings randomly on their preset locations, I just shuffle the list and retrieve several grid from the corresponding list.
A common way to do fix route path-finding is to define a series of waypoints and let our agent iterate through the waypoints list.
The Waypoint stucture is rather simple. It's like a doubly linked list: each waypoint point has a reference of the previous waypoint and the next waypoint. To add more flavor, I also create a field called 'branches' that stores the branches that a waypoint can have, and a 'branchRatio' that stands for the posibility that the current waypoint can enter its own branches.
To make the waypoint editing easier and more intuituive, I also created some other classes acting as tools, providing functions like adding and deleting the waypoints in a window and also rendering them in the scene view through gizmos.
The red line and green line indicates the boundary of each route, while the blue line indicates the branches.
waypoints in scene view
Adding branches to the waypoints definely make my AI looks more realistic and fun, but sometimes they can make these unexpected U turns, which are acceptable for cars but it looks really weired when the AI citizens do that. That bug is triggered because I set all the branchRatio (controls whether the AI should step into branches) to 0.5 by default, and there are plenty of branches when an agent arrives at a crossroad, so there are chances that the agent could trigger this unwanted behavior.
This problem can be easily fixed simply by setting the branchRatio more carefully. However, due to time limitation, and our team didn't think this little bug is a huge issue, I chose to ignore it.
U turn problem