The Scope Creep Demon
I fell into the trap. The trap every game developer falls into. The scope creep trap. Even though I told myself this game was going to be small, short, concise, and to the point, I still went big. I kept adding ideas to the game that were just too big for me. Perhaps if I had motivation for this type of game and/or I was a better programmer, I would have put more effort into making these features come true. But, in fact, I had no motivation for this type of genre and I was not experienced enough to implement the different features I had thought of.
If you play the game, you'll see how simple it is. In fact, you don't even need to play the game. Once you read this article you'll understand how simple this game is. However, I tried to make it complicated and big for no reason other than: "It would be cool if there were chicks with tits, bro". Is it still fun, though, despite cutting out a lot of features? I think so. But that's not the point. My goal with this project was to tackle a game that actually was my own. Maybe it doesn't have the most innovative techniques of game design, but I still tried to make a game that was fun. Not just a clone of Pong or Space Invaders. I wanted to make a game that I designed and thought about. A game that had inspirations from other titles. A game I would not call a clone.
But, I'm not a good programmer. Not even close to it. Perhaps in a year or two or three but not now. If you read the first devlog, you'll know that, for some months, I did not make a game just because I kept trying to think big. I wanted to make a DOOM clone without even having the knowledge or the expertise in how that particular tech works. I wanted to make an investigation game without actually knowing how the various systems of a game like that are going to be implemented. Sure, it is normal to go into a project without knowing how certain parts of the code are going to be implemented. However, what's not normal, is trying to make a game that has systems you absolutely have no clue how they work. That's fine if it's one system or two, but when 90% of the systems that need to be implemented are not in your domain of knowledge that's when it becomes a problem. If you read the devlog where I talked about the engine of this game you would know that a lot of the systems and components of the engine were already thought of and even implemented in previous games. The problem came in the gameplay code.
Ever since I went into the lower-level side of game programming, I always sacrificed the gameplay code. The thing that I focused on the most was the engine code. The rendering, the scenes, the UI, the collisions, and so on. I never stopped to think about the player's controls, a different way to handle enemy spawns, or even how to make the game fun. All I thought about was the engine of the game and not the game itself. However, that's still not a problem if you try to just focus on learning new things. Making a game just for the sake of learning how the camera system works is totally justifiable. And that's what I was trying to do for the past year and a half. I wanted to learn how the different lower-level systems work in games. I was interested and intrigued by them. I wanted to learn more about them. But expecting to make a full and enjoyable game out of it was not the healthiest thing to do.
The challenge I faced while making this game was not the technical aspect. But, rather, the gameplay aspect. How do you make a fun game while being handicapped by your own abilities? Well, you just have to keep your scope to a limited degree and use what you know. And that's completely not what I did.
The Original Design
In the first devlog, I said that I prototyped the hell out of this game. And I did... to some degree. I had a very specific idea of what the core gameplay loop of this game was going to look like. The main idea is that you fight zombies with medieval weapons. That's what I prototyped. A simple player controller, some zombies that followed the player around, and a very simple melee system. I tried to make the zombie kills as juicy as possible. I imagined there being particles, some sound effects, and some text flying all over the place. While some of these things stuck around, I still didn't make the zombie kills as juicy as I wanted. But, nonetheless, that was the main idea that I wanted to hewn in. A satisfying way to kill zombies. Even though I got distracted trying to implement various different features for the game, that part never really escaped me. And I kept it even after removing so many features.
However, that was the only part that I prototyped. Of course, that wasn't the only thing I thought about making in the game. In order to make the game have more personality than just a satisfying zombie-slayer game, I wanted to add a shop system.
The shop system in this game was going to have three categories the player can buy from. Each category had four items the player could buy. The categories were weapons, armor, and potions. Not very innovative I know. Each item had a leveling system. The player could level up an item by killing a thousand zombies while using it. Each item in the shop has four tiers. The final tier is considered to be very powerful but very hard to obtain. For example, one of the potions in the game was the durability potion. If the player manages to level that potion up to the last tier, both the armor and the weapon the player equips will have unlimited durability. The theme is like that for all of the items in the game. Originally, I had thought about having multiple items in the game with more crazy and outlandish ideas for each one. But, thankfully, I backed down and decided to just have four items for each category instead.
But how can the player equip these items? Well, with blood, of course. Every time the player kills a zombie, they will get a random amount of blood. The player can then use the blood accumulated from each wave and buy the desired equipment they would like to use. However, the items change their cost when upgraded. The player can still buy a weaker version of the item at a lower cost if they wish, though. If the player dies, they will lose a big chunk of their blood. Effectively making them equip weaker items and restart them from scratch. However, death won't reset the items' level. Death will only make the player restart from the first wave with a lot less blood than what they had.
As I said before, every category has four items to choose from. The weapons category had the light sword, the medium sword, the heavy sword, and the spear. The armor category has light armor, medium armor, heavy armor, and naked armor. The potions category has the health potion, the damage potion, the durability potion, and the dexterity potion. Each had their own tiers, of course. And each had a different play style. For example, going for the light sword and armor, the player will be quite nimble and fast but very weak both in offense and defense. On the extreme end, if the player went with the heavy sword and armor, the player will be very slow but very hard-hitting and will have a lot of protection. If the player goes the crazy route, choosing to pick the spear and the naked armor, the player will be very vulnerable but it will also be somewhat fun and challenging.
A normal game would first take the player to the shop scene, where they would need to make a choice for the items they will use to fight the zombies. The player will initially be given a small deposit of blood in order to get them started. When the player chooses the items they desire, they will be taken to the game scene where they will be immediately prompted to fight the oncoming waves of zombies. In every wave, there are a limited amount of zombies. The first wave starts out with only 50 zombies. Any other wave will increase 10 to that number. You'll have to kill all of the zombies in the wave in order to end it, of course. Once the wave is over, the player will be taken back to the shop scene again and the cycle continues.
However, that was not all. Since this game is heavily inspired by COD Zombies, I wanted to put in a small easter egg to have somewhat of an ending to the game. I can't find the details of the easter egg anywhere and I don't remember it exactly but I do remember that it was very simple in theory.
For a professional game dev who has made many games beforehand (maybe even games similar to this one), this is not a complicated or even out-of-scope idea. It seems very small and manageable. However, I'm not a professional game dev who made many games beforehand (and I definitely didn't make a similar game to this). While thinking of the design of this game, I had a voice in the back of my head occasionally telling me that I would not be able to tackle any of these features. They're cool features (at least I think so) and they can be done... but I still knew that I couldn't do them.
But how much of this original design changed? What stayed and what didn't?
The Current Design
A lot of things had to be cut from the original design. There were some features that were cut out very early and some that stayed till the end but still got cut out, nonetheless. There were even features that stayed only in the design doc. I never even tried to code it up because I was just ready to finish this game and get it over with.
One of the first features to be cut out from the original design was the item tier system. I had a general idea of how to make a shop system and how to tweak the different values of the items. I knew that putting all of the values of the different items directly into the code was not going to be a good idea. The solution that I thought of was YAML. I could just write the names of each item in a YAML file, have different values for each of the nodes, and read them in when it came time for initialization. Originally, I had put a little indicator for each of the items that told of their tier. But every tier had different values. And every item had a different interpretation of tiers. Should I make different entries in the YAML files for each tier of the item? Should I take the number of the tier and try to create the logic of the tiers in the code instead? Should I add a chick with big tatas that would cheer the player in his zombie-slaying ventures? All questions that were hard to answer.
As time went on, I started to get more and more disinterested in the project. Every time I came across a bug caused by the leveling system, I would just close my laptop and not work on the project for the whole day. There were days when I completely refrained from touching the project whatsoever. I would procrastinate and not think about the project at all. And, during that time, my mind started to think of the worst thing ever. The question that I feared so much. The question I knew would come up: Should I become a web dev?
At that point, I knew that trying to add a layer of complexity to a project that was supposed to be simple was not going to help me finish it. I decided to just abandon the feature altogether. But that wasn't the only feature I cut out.
Even though that feature was part of the original design, I never went far with it. It was very easy to remove it completely from the codebase without having any problems whatsoever. But, there was a feature that I went very deeply with. The shop scene.
In the final design, the shop scene looks very different from the initial design. There is no concept of weapons or armor. There are just potions. However, I did not remove this feature because it was hard to implement. In fact, I implemented this feature and it was in the game for so long that I doubted I'd ever remove it. Everything was fine and dandy with this feature. However, as I was playing the game, I noticed that I would always gravitate towards a specific item in the game: the spear.
As I said before, the core idea of the game is to make the zombie killing satisfying. It should feel juicy and invigorating. Killing the next zombie coming towards you should never feel dull. But, despite that, I felt very bored and uninterested when I used the different items in the game. The spear seemed to be very fun when I first thought of it. And it was very fun when I implemented it in the game. You see, with every other weapon in the game, the player will have to get close to the zombies and swing their sword at them. With the spear, however, the player can just throw the spear and see it penetrate a line or a group of zombies all at once, killing them in the process. When I was hunting for a specific bug that was making me pull my ass hair out, I found myself playing more of the game while I had the spear equipped. Playing with the swords felt awkward and dull. Using the spear, however, felt right. It was the exact feeling I wanted to convey. Seeing the spear flying in front of you and penetrating a line of zombies in one hit was one of the most satisfying feelings I had while playing any of my games. It felt right... it felt fun.
Perhaps removing the different weapons and armor in the game was a mistake, but I don't regret it since it made for a very fun game. I felt the other weapons and armor were useless. Why would anyone choose the medium sword if the spear is way more fun? I could perhaps have made it necessary for the player to choose the earlier swords in the game. Maybe make the spear very expensive and hard to get. Or perhaps I could make the other swords fun as well by giving them a certain twist or fun idea. But, again, I refrained from that as I had no motivation to do it.
As you can see the game changed a lot from the original design. I had in mind to have a camera system, some joystick controls, an easter egg, and many other things but I decided that these systems are better off implemented in another game. Other games that I would make specifically to implement these features. I already had to learn and implement a lot of new features. Features I never even knew how to start with. Putting on top of that other new systems and features I never implemented would have been overkill and would perhaps have been enough to abandon this project altogether.
So was this project useless? Had I wasted my time with it? The simple answer is no.
Why This Experience Was Amazing
Despite the project being small in size, it still gave me a lot of big lessons (IS THAT A DICK JOKE??!!). Lessons that I would have never learned if I didn't do it. I knew this project was way over my head when I first started it but I still did it because I knew that I was going to learn a lot from it. I now know my limits. I know my strengths and weaknesses. I now know the areas I have to get better at. I now know how to implement the basic forms of the new systems and features I made in this game. How else would I have learned these lessons without making this game? I had very big ideas for this game. Sure I did not stick with those ideas but I now know what ideas to stick to. Ideas that I will feel motivated for even if I'm limited in my knowledge. Games that will give me motivation to learn a new thing just to implement it in the game. Games that will make me keep going despite the setbacks.
Knowing your current limits and capabilities, as I have found, is the most important thing you need to do before entering a new project. And you'll never know these limits and capabilities without testing yourself and pushing yourself to the limit. How else are you supposed to know if you know how to make a rendering pipeline without trying to make one? It was hard trying to accept the fact that I'm still not good enough to make my dream games but it was a fact I needed to know. And, now that I know my limits and capabilities, I can try to adhere to them and make the games that I can make, learn new things by pushing my limits, and understanding that, while I might be a better programmer than the one I was a year ago, I still have a lot to learn.
And always remember, Huzzah!
Top comments (0)