As you’re probably already aware thanks to the title of this post, this isn’t a standard dev blog as I haven’t gotten enough done since my last one. However, I have done a significant chunk of work on a feature that’s been desperately needed and I’ve finally been able to grab some quick images!
To wit, I have completed 1/4 to 1/3rd of the mission scripting tool that will be vital to make Small Gods into a proper game. While it’s nothing too special, I’ve successfully made use of the systems and tools on offer in Mecanim to turn it into a very basic (but functional!) FSM for setting player targets and goals.
Here’s what the FSM looks like for the first level:
As you can see on the left, there are 11 different variables included in the current testing level. These variables are: Population, Food, Happiness, Wood, Iron, Sandstone, Gold, Glory, Task_1_Complete, Task_2_Complete, and Task_3_Complete.
Population is an integer variable that is used to tell the player how much population they have (and is useful for population challenges such as “have a city of 50+ people”). Food, Happiness, Wood, Iron, Sandstone, Gold, and Glory, meanwhile, are float values that can be used for tasks like “gather 1000 gold” and “transport 3000 units of wood to this neutral faction.” Finally, Task_1_Complete, Task_2_Complete, and Task_3_Complete are bool variables that tell the system when the player has completed tasks 1, 2, and 3.
Meanwhile, here’s what the actual setup of the FSM looks like in the editor view:
As you can see on the left-hand side of the screen there is an empty game object called LEVELSCRIPTING. This game object contains an Animator component with an animation controller called Level_1 assigned to it. This is because, in the current implementation of the level editor system, each level requires a LEVELSCRIPTING object in the scene and a unique animation controller. I’m not too concerned with changing this implementation right now as it works effectively enough and there are no real benefits to trying to change things, in my opinion.
To add a new objective for the player to complete all you need to do is create an animation controller:
Create an empty animation state within the controller:
Attach the SetVariable script to it as a StateMachineBehaviour:
Select the kind of effect you’d like that state to have:
Create a transition to the state (and input the transition triggers) from the start/core loop state:
And add a blank transition back to the start/core loop state:
That’s…… pretty much everything you need to know about how to make tasks for the player to carry out using the current implementation of the level scripting system. Hopefully, it wasn’t too boring for you guys!
By the 28th of August, I hope to have completed everything in the future plans/additions sections of my last dev blog. To recap, the plans are to:
- I need to fix the terrain flattening system so that it works properly in conjunction with building rotation.
- I need to ensure that the terrain flattening system produces a gradual rise to a flat surface rather than a sharp, 90-degree plateau in order to prevent the navigation system from messing up.
- I will need to adjust the values of happiness gain/loss in order to improve playability.
- I need to re-examine how happiness is gained/lost. Right now it’s a constant drain due to tiredness/hunger but I’m thinking that a flat modifier would be better as it’d let me add better unhappiness features.
- Add civic improvements to improve happiness.
- The immigration formula will need to be modified/replaced in order to give greater variability in the number of immigrants that can arrive in each immigration wave.
- AI will be given the behaviours necessary for them to leave should they stay unhappy for long enough. If a player is unable to provide enough housing, food, or civic improvements to their citizens, this will cause them to leave.