Looking back: Treevolution

Hail Wanderers!

Sorry in advance for the massive blocks of text (I may break this up into several smaller blog posts and clean it up a bit at a later date), and a quick note before I begin. It is very difficult, except for a few areas, to give credit to any one person for many of the decisions or parts of the design process, at least for the narrative and systems side of things. One of the best parts of our team, at least from my perspective, was that we really all had a say in how the games shaped up and where we wanted to take them, so while I was a driving force in the decision making process for many of the systems, I can’t at all claim that they were ‘my systems’ or ‘my decisions’. Though I certainly brought my perspective and experience as a systems and narrative designer to the decision making process, we made the high level decisions as a team in almost all cases, and I feel that made our game that much stronger.

Before the Beginning: Fire Trees, Days of Grey, and Mutations

Treevolution started out as a desire by our coder (Chris) to make a game based around growing, mutations, and evolution, and was then given direction by a simple question (I forget who asked it at the time), “What would a fire tree be like?” Initially it was being developed alongside another game, a puzzle based exploration game Days of Grey, and actually was not the team’s main focus. The initial concept was rather simple, we had decided that the mutations would be a main focus of the game as it would allow the player to discover new things about the game as they played, and this feeling of exploration and discovery was at the core of our intended experience for the game. Our original idea had the player acting as a tender of their forest, and did not have any multiplayer aspect, as the player would simply grow and develop their forest, exploring across a larger map, and eventually encounter new tree types that they would then be able to interact with and develop. We knew we wanted to have unusual and interesting tree types in the game from the very beginning, but we didn’t yet have a context for the game, and as such most of our variations were based more or less in reality. We had thorn trees, and trees that would give the player more energy (which was then used to grow more trees), and of course we had the fire leaves (though we didn’t yet know what they would do), but the game wasn’t really going anywhere until we added a second player. Suddenly the tone of the game had changed, we had conflict, and the mutations were given more of a purpose. It made sense, after a fashion (we tended to have trouble explaining just how trees were doing battle) as the idea was that the two forests would be competing with each other for resources, and that would explain why the opposing trees would be dying out, and it also made finding and using the new tree types take on a greater sense of urgency, as doing so was planned to be a game changing moment. Still, though we often found ourselves going back and forth on the issue, as a whole we were leaning towards moving forward with Days of Grey.

Aside: Days of Grey

Days of Grey was, as I already mentioned, going to be a puzzle focused adventure game. The game came from an old prototype and idea that Cody (he was either ‘the designer’ or ‘the other designer’, depending on which of us introduced ourselves first) had worked on in an earlier semester. The game at that point was a simple demo where the player would use magic seeds to overcome obstacles within the game world (the first two seed types were fire seeds, used to burn down brambles, and vine seeds, used to cross gaps and make ladders). Our team took a liking to the idea, and it grew very quickly. We wanted to create a larger world, made up of interlinking smaller areas that the player could explore, find new seeds within, and solve puzzles to advance. Again, the main focus of the experience was on exploration and discovery (a common core theme within all of the ideas our team bounced around, and something that would become an important unifying factor in later stages of development), in this case with the player discovering new seed types that they could then use to overcome new challenges. Eventually we shifted the seeds from being discovered outside in the levels to being grown by the player at their home base, a farm, with the help of elemental sprites that the player would encounter and rescue outside in the levels. The sprites became the main context of the game, with the lore of the world going something like this: the sprites were avatars of the elements, and kept the world going as it should. Eventually, the world grew old, and the sprites were put in a slumber to allow them to rest and rejuvenate. This caused the world to become grey and lifeless, and many years later, it would be the job of the player to venture forward into the greying world and reawaken the sprites. Doing so would not only grant the player access to the sprite’s power, which would in turn allow them to grow more seed types and progress further into the game, but it also would slowly bring color back into the world as the sprite’s influence started the process of reawakening the world. Though we loved the concept, and were quite excited about perusing it, concerns were raised that the exploration and puzzle based gameplay would not be engaging enough to provide for a solid experience for the player. I still maintain that we would have been able to bring the desired experience out, but due to the time constraints on the project, and the fact that Treevolution (though it wasn’t going by that name just yet) already had its core gameplay well on the way, we decided to drop Days of Grey and go forward with Treevolution. That, however, was not the end of Days of Grey for our team, or at least not for parts of it.

For my part, my main focuses with Days of Grey were on the story and also on the systems. I can’t claim sole authorship of the story, as much of it was decided upon as a group, but I would like to say that I provided a driving force behind it. I can, however, say that I was pushing for incorporating the story with the mechanics and the game world as much as possible, and that focus gave rise to such decisions as having the plants grown from the seeds, and later the sprites themselves, slowly bring color back to the world as a way of showing the player’s process and also really showing the effect the player was having on the world. I also put in a lot of work on the farm system, creating among other things a system where the player could use energy collected out in the main game world to upgrade and further develop the seeds, thus unlocking new powers for the player to employ in solving puzzles. The goal of that system was partially to bring out the idea of discovering more of how the seeds could be used, to lend a sense of progress and progression to the game, and also to provide the player with smaller goals that they could pursue while working towards the main goals of finding the sprites. As I stated earlier, one of the main concerns about Days of Grey was a possible lack of gameplay outside of the puzzles, so I wanted to create a system where the player would encounter smaller goals in the levels (“I want to get that group of energy shards, but I need to solve this small puzzle to do so”) and then be rewarded for achieving these sub-goals by more powerful and diverse abilities, which would provide a certain degree of reward on its own (upgrades being a solid way to reward the player, especially if they unlock new abilities and not just stat upgrades for the player, but that’s a discussion for another time) and further reward the player by allowing them to use these cool new abilities to solve the main puzzles in more interesting ways. In addition, for the puzzles and the aforementioned player abilities, I wanted to put a focus on abilities that could be used in multiple ways, not just as a specific ability that would solve a specific sort of puzzle. For example, we had fire seeds in the game that would burn things. It would be one thing to say, “ok, we have these seeds and they are used to burn away brambles in the player’s path” but I believe it is far more interesting, both from a design and a gameplay perspective, to instead say, “ok, we have these seeds and they simply have the property of setting things on fire, what can the player set on fire in our game world, and what will that then do?” By switching from a sort of lock-and-key style of puzzle solving to a system where objects have properties, and the player has tools that can modify or interact with those properties, it is not only possible to create more interesting puzzles, but also opens the puzzles up for more creative solutions by the player and makes the game more intuitive. For example, say the player needs to light a torch that they can’t reach. They could either solve another puzzle that would open up a path for them to reach the torch, or they could use a vine seed (which has the ‘burnable’ property) to attach vines to the torch and then, because the vines are burnable, set the vines on fire, lighting the torch in the process. It is a more complex style of system from a coding perspective, to be fair, but at the same time it should be manageable if the focus is placed on creating behavior styles (‘burnable’ things can be set on fire, and spread the fire to other ‘burnable’ things that they are in contact with, ‘pushable’ things can be moved, etc), assigning those to objects in the environment (brambles, vines, and trees are all ‘burnable’, rock blocks are ‘pushable’), and then giving the player abilities that interact with or trigger those behaviors (‘fire’ allows the seed to set things on fire, ‘push’ allows the seed to push things. So a simple fire seed would have the ‘fire’ property, a seed that created a gust of wind would have the ‘push’ property, and a seed that created a bolt of fire may have both). Once those behavior styles and ability properties are created, it should be simple enough to create puzzles with them (simply by assigning objects different behaviors) or add new abilities (just assign the seed a group of abilities). Such a system would also allow for the player to take actions or come up with solutions that the designers may not have originally envisioned (putting vines, which are ‘flamable’ around a rock, which is ‘pushable’ and then setting it on fire, creating a pushable flame source). That all being said, we decided that, in the end, such a system was beyond the scope of what we could do in the time we had.

In the Beginning: Lumberjacks, Bees, and Deavers, oh my!

With the focus of our team now solidly on Treevolution, the question then became how we would take the concept further. We had the trees, we had the trees growing, we had the mutations (though we didn’t have much to do with them), and we had the player’s competing with each other, but, it was decided, we didn’t have much of an ecosystem behind the game. The though was that adding a collection of systems to help simulate an ecosystem within the game would solve some of the challenges we were facing at that point. First off, it would give the mutations more purpose, as they could be used to counter entities within the ecosystem, it would also provide more ways of the player to interact with the game world (which fit with the growing desire to take the game in a strategy direction), and it would also help bring the experience together and branch (oh yes, we had many such tree puns along the way) the focus of the game out. So, with all that in mind, I set off on creating a manageable list of entities that would create our ecosystem. Having taken several science classes over the course of my high school and college days, I had a pretty good idea of what our ecosystem would need. Our trees would serve as one of the primary producers (the things that serve as the foundation for the ecosystem as they are the bottom of the food chain) which fit into the gameplay quite nicely as changes to the primary producers would have changes to the rest of the ecosystem and the trees were the main way the player would interact with the game (as a quick aside, one of the main intents of the ecosystem was to allow the player to interact with as many of the systems indirectly as possible, making it feel more like the player was interacting with and guiding the ecosystem, rather than directly managing it. The intent there was to have the player react to the game and vice versa as opposed to having the player control the game’s direction, but more on that in a moment, and possibly another blog post). For the first level of consumers, we would have deer (which the player could control and send to eat the opponent’s trees, which would damage them) which necessitated the creation of grass (a resource that the player would place to feed the deer, and a way to have a cost for the unit), bugs (another way to damage the trees, but one that the player would not control), and bees (which would pollinate flowers, which the player would grow from grass, which would then spread more grass). On the second level we had birds (which would eat the bugs, and which would also be attracted by berries, which the player could grow on trees for just that purpose). And then on the third level (sort of) we had the lumberjack, who would show up at random and cut down trees (he also skipped and jumped, but that’s another story). Of all of these new entities, the player only ever had direct control over the trees, grass (and thus flowers), and the deer, everything else was randomly spawned into the game world and moved based on their own simple AI. With the addition of new entities into the game, we also changed and gave purpose to many of the mutations. Thorns would now damage hungry deer, poisonous leaves would kill off bug infestations, and apples were just too delicious for lumberjacks to cut down trees that produced them.

Speaking of the mutations, the system by which the player would gain new mutations underwent many different changes during this part of the design process. At all stages trees would pass down any mutations that they had from generation to generation, but the method for gaining those mutations changed dramatically over time. At first, the mutations would be randomly assigned to trees whenever a new tree was grown, which certainly made growing a new tree an exciting process (it was fun to see what may happen) but it made it very hard to plan or make any strategic decisions, other than focusing on growing trees that had multiple mutations on them (which in then turn ran the risk of having the trees mutate again and lose the old mutations). This system was swiftly replaced by one where the players would have a choice between three possible mutations, which were randomly drawn from the total mutation pool. This solved the problem of randomness to a certain degree, but it also made some of the negative mutations that we had rather useless (nobody would willingly pick them, after all). This, in turn, made us change up the mutations so that instead of having negative and positive mutations, we had some of the more powerful mutations have a negative aspect to them as well (energy booster, which caused a tree to gain more energy and was fantastically overpowered at the start of things, now came with an increase to incoming damage). This still didn’t quite solve another issue we were having, where some mutations were more powerful than others (again, energy booster) and could break the game if encountered too early. The solution to this, and also to the concern that we were throwing too many things at the player at once (trying to learn the entire ecosystem in one shot was proving to be something of a challenge) was to break the flow of the game up into several stages through the use of a diversity meter.

The diversity meter (also known as the biomass meter, or simply the progression gauge) was actually a rather creative solution to the problem, and one that we borrowed, at least in rough concept, from science. In the real world, as an ecosystem has more things in it, it can thus support more things. More specifically, an abundance of a specific food source allows more than one species to use it as a food source without straining the ecosystem (take sheep and cows for example. With enough grass they can both stay in the same area, but if there is a shortage of grass one or the other will probably die out as the ecosystem can no longer sustain them). That’s a simplified version of a more complex process, but it served as a solid way for us to introduce new things into the game. As the players created more trees, and thus increased the capacity of the ecosystem, the gauge would increase and new creatures or mutations would be added to the game. This allowed the players time to learn about the existing systems before more were added, and also gave the game a nice feeling of progression. It also allowed for the game to take some interesting turns, as the death of trees would deduct points from the meter, meaning that if enough trees died out at once the game would go back down a level and higher tier entities would stop spawning in (as the ecosystem could no longer sustain them).

In addition to, and sort of working alongside, the ecosystem, we added a changing climate to the game. The climate effected the entire game board, and would slowly change as the game went on based on a trend that was set at the start of the game. We had four climates (desert, tundra, grassland, and tropic. Remember those for later.) with each one having higher or lower temperatures and rainfall, in addition to associated mutations. The intent was to have the players, and the ecosystem, change and react to the changing climate, adding strategic depth to the game and also making each play through more interesting and unique.

We took the game to Quality Assurance testing several times during this stage, and several things became quite immediately apparent. For one, the lumberjack was well received but almost universally hated. He was funny, and rather iconic, but his one man quest to cut down every tree on the board made far too many games end prematurely, and through no fault of the players, for him to be considered a fun part of the game. The deer on the other hand were almost universally loved (though the concern was raised that deer don’t actually cut down trees “They’re deavers” was our immediate response, “You know, deer-beavers”) and though they were somewhat overpowered (the thorns mutation did little to deter a hungry deaver) players absolutely loved building up their deaver armies and marching them across the map to do battle with the opponent’s trees! The bugs, birds, and bees were, on the other hand, considered rather useless, though the bees did see some use as a utility to grow more grass. Speaking of grass, it created no shortage of interesting situations as players soon found out that they could use it to block off their opponent’s trees, which was not at all the original intent, but it wasn’t quite broken, and it created an interesting group of strategies that could be employed, so we left it in (in the future, we would provide the players a way to break grass-blockades, but that would only come with the return of the sprites). The diversity meter was well received, as it gave the game a nice feeling of flow and progression, though it was also noted that we could very well just make it an internal system that the players wouldn’t be able to see. Our intent for making it an on screen meter was to show the players the current state of the ecosystem and also create some feelings of excitement and discovery (we wanted to mark each tier on the meter and show silhouettes of the new entities that would be unlocked for that tier. It wasn’t quite apparent in that stage of the game, but we wanted to add more tiers, and with them more entities, which would have made the meter more akin to an unlock meter) but it wasn’t always focused on as much as we thought it would be, and the appearance of new entities would still have the excitement and discovery impact, with or without the meter. In the end, we planned to just have it be an internal system, but we ended up changing up the game systems before that happened.

The climates, on the other hand, were not well received, to say the least. When the players could get mutations that fit well with the climate they were in, they worked, but as the mutations were randomized, as was the direction the climate was moving in, too often we found that players were either not interacting with the climate, not able to react adequately to it, or simply getting killed off by the desert climate and the lack of rain that went with it (rain replenished the trees and gave them more water. If a tree ran out of water, it would die. The desert adapted gene let the tree consume less water, but as stated above, getting it was purely luck based). Furthermore, though each entity in the ecosystem made sense, it didn’t feel like a cohesive whole. It felt less like an ecosystem and more like a loose collection of systems, which was not what we wanted for the game. We also weren’t satisfied with how competitive the game had become, and wanted to find a way to change up the game so that destroying the opponent’s trees was not the main focus. In hindsight, this may not have been as much of an issue as we originally thought it was, even though it didn’t quite fit with our original intent, though I also believe that the system we decided to replace it with had merit and could have introduced some very interesting gameplay scenarios if we had more time to develop it.

Regrowth: Terrains, Deaver Life, and Sprites 2.0

To address these concerns, and also clarify the context of the game, the lack of which was seen as one of the main issues with the game at that stage, we went back and brainstormed the direction we then wanted to take the game. We knew we wanted to have the mutations play a center role, and we had started to want to delve more into an otherworldly context. Not straight out science fiction or fantasy, but more of a world like and unlike to ours, a world of extremes that would have caused similarly extreme mutations within the trees and creatures that inhabited it. We knew the current terrain system was not working, but we also wanted to find some way to incorporate terrains into the design of the game, and wanted them to change over time. The solution, from a gameplay perspective at least, was to have the trees spread the terrain with them, and to mutate and change based on which terrains they interacted with. The question, then, became why. The answer came in the form of the sprites, in a rather similar role to the one they played in Days of Grey. The sprites would be avatars, would be what the players played as, or at least what allowed the players to interact with the trees, and would be servants of the old gods, these ancient and powerful beings that each represented one of the four terrain types within the game. We wanted to use terrains instead of elements as that fit with the game better and allowed us to have the old gods be something more akin to forces of nature, drawn loosely from some older religions that would actually have gods of rivers or other natural bodies, rather than just the very cut and paste elemental forces (not that there is anything wrong with that, when done well). This change also solved the issue of the mutations being highly random and unpredictable, as now the players could pick a line of mutations to go down based on which terrains they grew trees on. It also made the mutations feel more realistic and intuitive, as now they were actual adaptations to the environment that the trees were growing in and not just random changes that happened as the game progressed. Furthermore, it gave the game and awesome feeling of the players really striving for control of the game board, as the influence of each player would spread out as their chosen terrain spread across the field. Going along with all this, the trees would actually re-adapt to the standard terrain if the player grew them on the normal terrain, which helped to slow down gameplay a little and allow for more in depth strategies to emerge, in addition to highlighting the importance of spreading the terrain type. All of this also went along with a simplification of the existing ecosystem, along with some modifications to how the deavers behaved. The lumberjacks, birds, and bugs were all cut as they were really just self-contained systems that were either broken and not fun to play with (the lumberjack) or too insular to really be able to influence other parts of the game (the birds and the bugs). The bees saw a change in focus, as they were now able to purify the non-standard terrain types from the board as opposed to spreading grass around, which gave them a much stronger gameplay purpose as they could be used to slow down or completely reverse an opponent’s spread across the map. The deavers saw the largest update, especially as they were one of the most enjoyed parts of the ecosystem so far. They were given a life cycle and a sort of sub-objective internal to them, now when a deaver collected enough wood from trees (by damaging them) they would leave the player’s control and construct a shelter, in which they would raise a new deaver. We made this decision because we wanted the deavers not only to play a larger role in the gameplay (the players loved them, and they served as a good tool for the competitive aspects of the game) and more deavers allowed for more of them to be used at once, plus it made them feel more like an actual entity within the game world as opposed to just a system that the players were interacting with. The plan moving forward would have been to create mutations for the deavers as well, further increasing the amount the players could discover and explore within the game, and also increasing the strategic depth of the game, but unfortunately those plans will either go unfinished or have to wait until the team has a chance to work on Treevolution again. Going along with the changes to the deavers, we also changed up what sort of mutations the trees would have. As the mutations would be broken up into four categories based on the four terrain types (tundra, desert, poison, and tropic, with grasslands acting as the basic, unmodified terrain) it made sense to create two mutations that each terrain would have that would each cover a specific role within the game. So for each terrain, the trees would have a mutation that allowed them to better deal with the deavers, and then a mutation that would serve them better in dealing with other trees. Accompanying this change was a system where the mutations that a tree would obtain would be based on what the tree had interacted with over the course of its life, so if a tree was damaged by a deaver, any offspring of that tree would then get the anti-deaver mutation whereas trees that did not interact with deavers would get the normal mutation. This actually really helped make each set of mutations feel unique, and it also helped with balancing as I had a clear idea of what each group of mutations would have to do. Furthermore, as we already had the ideas for what each terrain would be like worked out, those decisions really informed my design process for what each mutation would be like as I was able to base the style of mutation after a sort of loose logic of what a tree that had adapted to that terrain would be like. I’m rather proud of both the design and narrative work that went into the mutations, as I think the otherworldly style of the game is really apparent and I think that each group of mutations really has its own unique feel to them that makes playing and learning about the various terrain types, and the sprites, gods, and trees that go with them, much more fun and interesting. Lastly, we changed the end state of the game to trigger once one of the four terrain types had covered more than half of the map. The idea was that the players were trying to create an environment that would be suited to one of the four gods, thus allowing that god’s reawakening, and I would say it was working to an extent, but as we weren’t yet assigning players to a god (thus giving them a clear goal specific to them to work towards) it wasn’t quite as apparent what the players should be doing, or who was wining, than it could have been. Then again, the system allowed for some interesting possible scenarios, (such as two players cooperating to achieve the rebirth of a specific god, or even two players competing while both working on the same terrain) and I believe it would have been far more interesting than a simple elimination game mode with some more work. We could have just locked each player into using a specific type of terrain, and the trees that went with it, but we felt that such a decision would get away from the experience of discovery and exploration that we wanted for the game and so, even though it was slightly less intuitive, we stuck with the more freeform end state. In the end, I’m not sure how much it mattered. Where it was, most players were falling into a playstyle conducive to the free-form endstate naturally (as the immediate inclination was to try and compete with the other player for control of the map) and those who weren’t were enjoying the game all the same, though we did have one or two times where the players didn’t realize why the game ended when it did (again, that was something that could have been fixed with a bit of iteration on the system). All told, I think the change in direction that we took really made the game much richer, both in terms of gameplay and context, both of which then helped to create a much more cohesive and engaging experience. The main issue, at least from my perspective, was that explaining the game was sometimes hard to do (there were many systems that the players would have to learn and understand rather quickly to be able to fully engage with the game) and that was one of the main areas, if not the main area, that required significant improvement. We created a tutorial for the game, which carefully went through each game system, but I realize now that it would have been better to incorporate the tutorial directly into the flow of the main game, and have it act less as a lesson on how to play the game and more as a guide that helped the player along as they explored the game for themselves.

The Takeaway: Cry, Stand Up, Grow Stronger

Though Treevolution did not go forward into second semester, working on it was a phenominal and rich experience that has helped me grow as a designer, and as a person. Going through all that I’ve learned would be difficult, as some of the growth comes in a more deeply personal, and thus less easily defined, sense, but the major thing I’ve taken away from the process is that I need to put a greater focus on creating systems that can be easily intuited through gameplay. It is one thing to have a game with complex systems, and there isn’t anything wrong with that (I love complex games, I’m one of the few people I know that really gets into the rules for things like D&D, just as an example) but (very much unlike the aforementioned tabletop game) the way the game systems are presented and explained needs to be intuitive enough for the player to explore the systems and discover how they work without having to delve through long and often overwhelming tutorials. The process for doing this is something that I’m going to have to spend time exploring and working on, but I imagine it will be something similar in theory, if not exactly in execution, to the process for incorporating the game systems and the narrative context of the game together. The goal in both cases is to make something that makes sense within the world of the game and that holds together, not just from a gameplay perspective but also from a narrative perspective. Actually, more than just making sense, good systems should inform and advance the narrative, and vice versa. This is yet another subject that deserves its own blog post, but I firmly believe that the strongest systems are the ones that are tied in some way to the narrative, not just as a justification for something occurring, but as a way of engaging the player and drawing them into the narrative space through the use of gameplay. Take Dark Souls for example, death in that game is scary, as repeated deaths without a source of humanity to replace what was lost will cause characters (at least from a narrative sense) to become mindless hollows. It’s one thing to say that to the player and expect them to get scared (the game never actually has the player character go fully hollow after all, as the game would end at that point) but it’s another entirely to actually make death a scary process for the player. Dark Souls does it by having the player drop their collected souls (a currency used to level up and buy items) on death. These souls can be regained by reaching the dropped bloodstain, but a second death will create a new bloodstain, resulting in the loss of the original souls. This makes repeated deaths, or the threat of repeated deaths, scary as it will wipe out progress that the player has made. Sure the player never runs the risk of actually going hollow, but the system is being used to create an experience for the player that fits within the narrative (in this case, the fear of repeated deaths), thus making both the system and the narrative that much stronger. It’s this style of working the systems and the narrative together that I really want to focus on as a designer, and now that I know that I need to work more on teaching the systems to the player, I’ll make that a part of the process as well. My goal now is to get to a point where I can work the systems and the narrative together, and use the experience created by both to teach the player about the systems and the narrative through gameplay, rather than by trying to walk them through a tutorial. The learning process is never over in the game industry (something that I must confess I’m rather excited about), but I think that learning how to do that will put me that much further along in my studies, so to speak.

Until next time,

Guardian Soul