Hi (again potentially), welcome (back?) to my design blog. I'm Vivian Overbey, lead designer on Entoworks, a lightweight strategy/tactics game about steampunk mechanical bugs. For a bit more information, you can check out my first design blog. 

     Sprint two has completed, and a lot of cool work was done. you can check out the producer's blog for that. This blog focuses on design of the game and how it progresses and shifts throughout development

     Sprint two marked a pretty substantial shift in design. There was an issue with level design, it was unclear how to design levels. The tool was functional, levels could be made, but the more fundamental question of how to design a level was hard to work with. There were two main reasons for this. 

1. Clarity of gameplay to the level designers
2. Lack of agency given to the level designers via the tools

     The first issue was a general uncertainty around gameplay that the level designers had. what would units stats be? how would they behave? While part of this was needing to explain the design to them more clearly on my part, there was a more fundamental issue with the design. There were too many stats, and their affect on gameplay was hard to articulate. I realized that if i am struggling to explain it to level designers, it probably won't be too clear to the player either. So, I worked on adjusting some of the codebase from pre-production to make stats clearer.

     The core change made was reducing the total number of stats units had, from 12 to 8.  This involved combining some stats, and changing some mechanics. The game's turn system has been simplified to something more like advanced wars, where you move all your units, then end your turn. this eliminated the "speed" stat.  there were 4 separate stats related to some variety of lucky event, such as a critical hit, or evade chance.  These were merged into one stat just called "Luck".  Mechanics were changed so that units can attack at half damage after moving any amount, removing another stat that corresponded to reducing damage when trying to do this. Finally, I added a new stat, Special, that corresponds to how much damage is done when a unit uses a special, a two turn attack that does massive damage.  This adds up to 8 stats, and overall made the stats a lot easier to understand and explain.

     The second issue was the level designer's agency, particularly over the enemy's units. This was a major oversite when designing the tool. I initially planned for the enemy team to be determined elsewhere, not really giving any agency to level designers over this, but instead expecting programming to figure out a team mathematically with no real input. My initial reasoning for this was that due to not having units in the game early in production, we will need to figure it out later, as a level designer couldn't tell a level to use a unit that does not exists yet. The solution to this was a layer of abstraction, instead of a level designer putting in a unit to spawn, they put in a bunch of data that can be used to create a unit later. Basically, they attach instructions on a unit they want built into the level data, and the programmers later will need to take that, and get a unit that meets those specs. 

     The level designer can now add data for the 1-3 units the enemy will have. They can also determine how many units they have here. They can input the element of each unit, if they are flying or grounded, which affects which tiles they can move over. Finally, the designer can control how each unit's stats should be distributed and capped. 

     Another feature added to give level designers more agency was what I call the "asset tags" system. this system, similarly to the above system, is a layer of abstraction that programmers will need to later fulfill, but this time for level tile assets instead of levels.

     The fundamental idea is to assign a specific tile asset a tag. this tag will modify how it interacts with the games system in a secondary way. For example, a tile that is used for the ground that has the tag "Rough" may be more difficult to move through, meaning you cant move as far when moving over or through them. Talking with the level designers, a total of 11 tags were created. 

     That is the majority of the design work done during the sprint. some other documents and concepts were made, but the main goal was documenting and setting up this design shift. 

     Thanks for reading, there should be a demo attached to this post if you want to check out the work done so far. Another build will be coming out about every two weeks with these posts.