Happy midday friends,

Sprint 3 is a very exciting time for all of us. For Card Garden, it meant seeing our game in action with textured models, unique core systems functioning, and even particle effects. A big part of my duties in verifying work is that I see every element as they come in and test for function and feeling, but there is a magical moment after the completion of each build where you play the .exe for the first time and it amazes you. As with the previous sprints, I am ever jealous of Alex, our Producer, who gets to share with you all of the great work we have done in her production blog post. Our new prototype has an introduction to our spells, level up, tile effects, and the fully feature enemy AI in a beautiful level one that we are very excited to share. You can try it in the attachment at the bottom of this post.

We are especially grateful to our playtesters this sprint who let us know when we are going in the right direction. This sprint had a lot of new concepts for our players and some of them were further along than others. The player's towers and minions could level up, but enemies did not and that made the second half of our playtest wholly lacking in challenge and engagement. Even still, our playtesters managed to give clear feedback about what was working and what was not. Our new level and level spawning behavior was a hit and we were mostly bug free. Conversely, we did discover some areas in which visual feedback and clarity was needed. While players liked the ideas of the cards they had available, we found that most of our placeholder text and imagery was not sufficient for them to know precisely what they did. However, we did find a scaling increase in clarity with some of the cards that were better detailed in the playtest which gives us confidence in the tools we had in the game for delivering information. Since our playtest cohort is primarily made up of the same peer group in each playtest, it is imperative that we address these issues early to keep our feedback pure. Having consistent and clear visual feedback for the player may seem like a given, but I believe nothing can be taken for granted in game development. We had to break down what elements are required to be clear to the player and how to achieve that consistently through all aspects of our game. 

All of game development is a super cool and interesting, but we had the opportunity to do something especially cool with our game this sprint. Our programmer, Jacob, has been solo tasked with a multi-sprint epic of creating this tool for our level designers and it is everything we asked for and more. It has the ability to load tile sets, save and load level layouts to serialized files, and generate the level at runtime and in the editor. That said, a solo task multi-sprint epic is an amalgamation of red flags in any circumstance, much less in the form of tools programming which is an area none of our programmers have been taught. While I am grateful to Jacob for being able to take on the task, I also see this as a learning experience to be more prepared about the needs of the team and not just the needs of the game. I cannot understate just how valuable pre-production would have been in this regard. We are very happy to have this feature for our level designers, but will take much greater care with new tasks like this in the future.

Finally, I am very happy to start talking about systems. I will not be getting into the exact specifics here as many of our game systems are still a work in progress and will require a lot of internal and external testing. There were two major systems that impacted our playtest for Sprint 3. The first is our spawning behavior. While our programmer, Alex, took responsibility for the actual spawning and timing elements of this system, I took full responsibility for building editor components that our level designers could quickly prototype and explore. I am very happy with how this turned out as I got to work directly with the level designers to show them how the tool works and to talk about their needs directly. In the end, we created a game spawner that takes a number of nested Scriptable Objects of spawns inside of waves inside of encounters. Each encounter holds multiple waves which hold multiple spawns, the timing between them, and the lane assignments they will be following. I am very proud of this system as it gives our level designers precise control over the exact timings, paths, and power levels of each enemy in our game. It also allows them to be quickly drag and drop high level Encounters so that they may test and iterate rapidly and easily. I do not often get opportunities to directly work on our gameplay systems code, so making this my own made me feel great. 

The other system I am excited to share is our unit level up system. This system is a joint effort among our programmers allows our minions, buildings, and enemies to level up in game so that there is some form of numerical progression. This was one I had to change several times during the sprint due to the level of complexity I wanted not matching our goals. One of our design goals for reaching a medium core gamer audience is to have lenticular design. That is to say that we want our content to be both easily approachable and to also have a high mastery ceiling. Many of the initial designs succeeded strongly in one or the other, but finding room for both required adjustment. The level system we are committed to uses a familiar tabletop multiclass component where each card or enemy functions as it's own class. They may level up and increase in stats across the board. They may also be augmented by the player's cards with elemental levels which work to specialize the units with type advantages. These elemental levels still count towards the level cap, and any and all stat bonuses are additive. The goal here is to allow the player to decide between elemental ubiquity and hyper specialization of their own units according to either their strategic necessity or their personal playstyle preferences. Each element, themed to the four seasons, provides a sharper damage increase than normal leveling and one unique stat per element to offset the loss of scaling in each of their other stats. Spring increases attack speed, Summer increases physical damage, Autumn increases attack range, and Winter increases defensive capabilities. It is our hope that each of these feels intuitive but the choice between them when weighted against normal generalist leveling allows for a meaningful choice to the player. Only tuning and testing will tell.

Sprint 3 offered a glimpse into the future of Card Garden. We have a lot of tools for rapidly creating and iterating on new content as we please in the future and we are already starting to reap the rewards of these tools as we enter the next sprint. I am very pleased with the direction we are taking and very eager to see how the playtesters respond to our upcoming changes. We are exiting the new features step of development and entering the new content steps. With that change comes a whole new set of problems to solve and I cannot be more excited. Thank you for coming on this journey with us.

Farvel,
Arjun Gambhir
Game Designer