Early Conceptual Design: Devlog #1

Introduction

         Greetings, my name is Everett.  I'm allowed to call myself a game developer, now that I have released one singular game here on itch, even if it is an abomination.

          I am trying to finally start the process of developing (and finishing) a long-term project.  I've heard from many renowned scholars that creating devlog updates while working on a game can help with motivation issues and with preventing the seemingly inevitable fate of many indie projects. There's no guarantee, but I think I'll enjoy writing about my process, even if nobody ends up reading what I put out.  I want to keep myself engaged in something long-term besides my college degree plan or my part-time job.  Historically, I am not the type of person to do that. My tendency to start projects and not finish them has been around since I've had the mental capacity to do anything that even constitutes a project.  If I were to, hypothetically, graph a function of my motivation with respect to time in weeks, that graph would probably look something like this:

         In spite of my attention span (or lack thereof), I want to use this devlog and this project as opportunities for personal growth, so that someone, somewhere out there can see my finished work. I know what it feels like to finish a small project, so it's about time I feel that with something bigger (within reason). I also hope that my perspective on game development is helpful, interesting, or at least entertaining. With that all being said, this post will be the first devlog for my indie project Enchanterland, so let's get into it.

The Early Design Process

         The concept for Enchanterland started with an idea that has already been overturned in the first couple months of development. The original concept was a 2D level-based action platformer based around an equipment enchanting system, similar to the ones in Skyrim or Minecraft. However, I wanted to make the enchantments really change how the player interacted with combat and movement. I also wanted to make enchantments the only way to change how powerful your character was. The player wouldn't have received new equipment, but instead new enchantments that could be applied to their items to form a build. 

         After I decided to center the game around these enchantments, I then gave it its name. I'm a big fan of rhyme schemes in songs and poetry, so I went with this name because it sort of rhymes with itself. I think it works especially well because the second and fourth syllables are the ones that share a vowel sound; I can almost hear a musical rhythm when reading it. It also adds to the fairly-tale-esque aesthetic that I had decided on when making some of the first artwork for the game.

         Of course, the core focus on magical enchantments is still around, as well as the name I came up with. I quickly realized, however, that this game simply does not want to have an RPG enchantment system with player stats and an inventory system. As both the artstyle and concept developed, I couldn't shake off the feeling that having any sort of inventory system wouldn't actually add anything valuable to a level-based platformer. Imagine if Castlevania had you constantly pausing to manage the secondary weapons you had collected. It would shatter the flow of the game, even if it was made to have slower pacing to begin with. Pacing in a platformer with separated levels can be managed through level design, but not with as clearly intrusive mechanics as my original idea. Using enchantment upgrades instead of equipment upgrades wouldn't actually bring anything new to the table anyways; it would have been functionally the same as an equipment system in any standard RPG.

         I generally believe in the game design principal of "Follow the Fun", a concept that originated from game designer Marc LeBlanc. The act of "following the fun" involves building a prototype for an idea and rigorously testing to see what aspects are fun and what aspects are not. You can then shift the concept to focus more on what you found fun, and cut the parts that don't add to the experience.  What you end up with is usually something different from what you set out to do, but still much better than the rough idea you started with.  In my specific case, the pace-breaking inventory system was such an unbelievably terrible idea that I didn't even have to code it in before I saw that it wouldn't work. However, I still needed to have a tangible project in front of me to see that.

         I later decided that the enchantments in Enchanterland would take a similar form to power-ups in a New Super Mario Bros entry. The player character would only have one enchantment at any give time, but it would "power up" the character in a significant and fun way. An enchantment would be applied immediately upon picking one up, and there would be no finnicky menu system that breaks pacing. This will be the core mechanic upon which everything else in the game is built upon. Of course, even this concept is subject to change.

Movement + Limitation-Based Design

         'Movement' is probably something that immediately comes to mind when you hear the word 'platformer'. Even though I want to focus more on combat than platforming for this project, defining how the player moves is still an essential step in development. I believe there's a layered spectrum to how movement gets made in different games, platformer or otherwise. One part of this is how many options you want the player to have access to. On one hand, giving the player more options to work with can increase a player's feeling of control and expression. Think about the freedom of movement you are given in a game like Pizza Tower, a freedom that comes from all the crazy and unique tools you have been given. On the other hand, it may be better to make movement simpler to compliment the level design in a game. Celeste would not work without its minimalistic controls, since the levels were designed around the limitations put on the player instead of being designed around a diverse set of abilities. There is also a foundation for a middle-ground in games like Hollow Knight, where the movement limitations that the players face at the beginning are slowly rectified as they receive more and more new abilities over the course of the game.

         For Enchanterland, I want to lean more towards the Celeste side of the simplicity spectrum. I think bombarding players with tutorial levels and text walls can raise some accessibility issues, and can often reduce player engagement. It's not necessarily a problem when a game wants to give the player access to complex movement, but I don't think its what I want for my own game. However, it's not just that I don't want to have a tutorial level in my game. I also want to to purposefully restrict the player's movement in ways that seem counterintuitive to the platformer genre, but I have some good reasons for this approach.

         The challenge of every game is defined by limitations made to the player. While allowing a player to go on a power trip could give them some temporary enjoyment, long-term engagement is created through risk and reward. A higher risk will inherently grant the player a larger intrinsic reward for their time. Playing a Street Fighter game with a friend wouldn't be nearly as fun if the weaknesses of each character weren't just as exaggerated as the strengths. The best example I can think of to demonstrate this is Zangief, who is just as defined by his size and lack of speed as he is by his high-damage command grabs. Players don't just resonate with strengths, they resonate with limitations as well. In a similar way, I find it oddly appealing how your character in Morrowind starts off with one of the slowest run speeds in gaming history. However, as you build your athletics skill and invest level-up points into speed, your character gets faster and faster. Eventually, you will be able to combine good stats with speed-boosting spells to zoom around the map or jump over mountains.

         For Enchanterland, I wanted to design the movement around strict limitations that most players aren't used to having in a platformer. Just as many Skyrim players might not be used to the initially slower movement of Morrowind, those familiar with todays 2D platformers might not be used to the fixed jump arcs of many NES games. However, I think this old-fashioned and inherently limiting approach to air movement can provide a unique, enjoyable experience in the right context. When you lose the ability to control your character in the air, you start to think more about whether or not you should jump in the first place. I don't want this project to be as unforgiving and frustrating as something made back in the 80s, but I do want to focus on a different, more strategic kind of gameplay than what most other platformers would offer. So, I made movement feel heavy by decreasing acceleration speeds, and I hard programmed jump-arcs to be fixed. I also don't want this project to have any instant dodges or dashes. The challenge will not come from the player's ability to get out of a bad situation, but rather, it will come from the player's ability to not put themselves into a bad situation in the first place.

         Limiting the amount of options the player has access to may make the game more difficult, but it also makes it very easy to understand. Hardly anyone would say that Celeste is easy, but hardly anyone would say that Celeste is confusing or complicated either. By limiting the amount of buttons a player has to press, I can open doors to a wider audience without sacrificing depth or difficulty in any meaningful way.

         An extremely underrated indie game that acted as one of the main sources of inspiration for my limitation-based design philosophy is Loop Hero. I don't need to get too much into detail here, but what sets Loop Hero apart from every other deckbuilding rogue-like is how almost every single card in the game both helps and hinders the player. Mountains increase your max health, but every ten mountains will spawn a goblin camp. Groves give you wood, but they also spawn ratwolves. Outposts will spawn a soldier to help you in combat, but that soldier will take all  high-value items dropped in combat as payment. Working around the strict limitations of your own deck is where the challenge comes from, and it is also what makes completing a run so satisfying. I want Enchanterland to feel like Loop Hero in that sense, so I also want to design more aspects of Enchanterland around limitations than just the movement. As to what that will entail, I'll just have to see what works.

         That's all for now. I'll be consistently posting every [unspecified time frame], so I'll be here then to give more insight into my personal process. I have quite a bit on my schedule at the moment, but I'm hoping I can devote a decent amount of time to both this game and this devlog series. Even if my first game was a modern day E.T, game development is a passion of mine that I hope to get better at and learn more about. Here's to improvement, and to hoping none of us crash the video game industry again. Until next time!