In October of this year, I created a game called Love Bytes for a Making Meaningful Games course in which I attempted to create a short, silly satire of online dating. After my original iteration of the game, created in Unity 3D, ended up a major disappointment, I wanted to create an improved version of the game as my last project for the fall 2019 semester. The new version would be created in 2D, in GameMaker Studio 2, and use pixelated, “cutesy” graphics that better matched the tone I was trying to set with the game. My primary goals were:
- Make the game more about the characters and less about the setting. The first version of the game ended up resembling a standard puzzle game far more than the social satire that I originally had in mind.
- Give the game a more concrete visual style. The 3D Unity version had graphics made almost entirely of raw 3D objects created in Unity. I needed the 2D version to have its own unique visuals.
- Don’t be overly ambitious. Just don’t.
Fast forward two very short months later, and I can say that goals one and two were solidly accomplished. (Number three is a different story, but I’ll get back to that shortly.) While I’m relieved that the most stressful part of the process is over, the entire development process was not without its hiccups, and I would still like to continue tinkering with this game in my spare time moving forward. There are plenty of improvements that can still be made.
WHAT WENT RIGHT
Clearly-Defined Vision and Goals
There have been plenty of times during the past year and a half in which I, as an individual or as part of a team, have set out to create a game “about X,” with X being something vague and ill-defined. One thing you have to learn to do quickly in a game design program is how to narrowly define the scope, goals, and vision for any game. What is it really about and how will the theme be communicated? What do we want the game to accomplish? What do we want the game to teach the player, if anything? What do we want the player to feel as they play the game? Does the game fit into a clear genre, and, if so, which one? Trying to force too many mechanics or messages to mesh together coherently just about always makes the entire game weaker in the end.
I had the advantage of having already thought a lot about the themes that I wanted Love Bytes to communicate, so I came in knowing exactly what I wanted to do and how I wanted to narrow down the scope. Knowing exactly how I wanted to do so through the game’s mechanics was a slightly different story and still had a long way to go, but I had a firm grasp of the what and the why.
Granted, this “went right” because it had to. Specifically, creating thorough supplemental documentation was a required part of the project in the context of the graduate course it was made for. So, I needed to learn how to create a game design document, production schedule, professional-looking progress reports, etc. The design document was especially helpful. Up until this project, I had done most of my prototyping and design in a handwritten notebook and my notes were never particularly thorough. Keeping track of all of my goals and ideas in a digital document was a far superior way to manage the game’s development. I know this goes without saying, but keeping everything digital makes it so much easier to properly organize ideas, even if it doesn’t improve memory the way physical writing does.
WHAT WENT WRONG
While I wasn’t the only student in the class who chose to create a final game on his or her own, most of my peers chose (wisely) to work on this project in teams of two to three people. In this particular case, I chose to work alone because I wanted complete creative control over the final product. I wanted to guarantee that I ended up working on something that I was passionate about and that was 100% mine. I certainly got to do that, but it came at a cost.
The two most pressing issues that come up when you work on a game alone with a strict time limit are a lack of anyone to keep you on-task and accountable, and a strict limit in what you can accomplish compared to what you will see produced by teams. Regarding the former problem, I think working with a team on a project of this scope would have been advantageous for me, in particular for this reason. I have major (and I mean almost-life-ruining levels of “major”) procrastination issues that have only improved slightly since I was an undergraduate. This is nearly always far less of an issue when I’m working directly with other folks who expect regular updates that they will need in order to finish their own tasks.
The reality of the latter issue typically hits at the end of the project period when you see what other folks have put together. When working in groups, I’ve seen peers design and create incredible games that they would almost certainly not have been able to make alone.
I am known far and wide for consistently overestimating the number of features I can squeeze into a game and underestimating the amount of time everything will take. This project was no exception. While I was able to get all of the must-have features and a couple of my “nice to have” features into the game, it was still significantly less than I hoped to add. Also, each individual task reliably took about 2.5 times longer than I planned for. You would think I’d be used to this at my age, but somehow I am not, even though the more it happens, the more humbling it gets. Having to work on the final stages of two other major projects at the same time did not help, either.
Because of the too-much-ambition and underestimating-time-needed issues, I ended up doing less than half of the playtesting that I originally planned for. I know that the game could have been improved significantly with additional feedback.
I always struggle, especially when it comes to digital games, to appropriately balance a game’s difficulty level. Many games end up being far too easy or far too difficult. One of the earliest comments I received from a playtester was that, for instance, each change in the player character’s speed that he experienced was either so subtle as to be meaningless or so outrageously overboard that it became a frustrating distraction. Even as I type this, I am still not happy with the game’s difficulty balance, especially since the challenge is part of the message and theme.
This was, without a doubt, the “wrongest” wrong thing on the list of things that went wrongily wrong. As I mentioned, my original plan was to create this game in GameMaker Studio 2. Having recently created a demo game in GMS using resources from an online course I was taking in my spare time, I felt confident that I could use the skills I picked up doing that and easily transfer them to Love Bytes. I was (mostly) wrong and in the end, using a final project as an excuse to use a (comparatively) newly-learned game engine was a mistake.
The simple design elements were easy to put together in GMS: character movement, colliders, scene separation, etc. However, once I began trying to accomplish trickier tasks, panic started to set in. I realized I was in over my head. I still hadn’t reached the skill level in GMS that I had reached in Unity, and the Internet isn’t as saturated with online help/resources on how to solve issues and implement mechanics with the former. About one week before the final deadline, I realized that, as much time as this was taking, moving the game into Unity 2D at the last minute would actually save me time in the long run.
This was the first time I had ever attempted to move a digital game from one engine to another, and it is tedious as hell. Scripts have to be rewritten in a new language, tile maps have to be repainted, character components have to be reapplied, etc. While I ended up with a playable Unity game by the deadline, as I type this, I still have not transferred every last thing to Unity from GMS. This will be one of the tasks I now need to tackle over my Christmas/winter break.
In spite of its many flaws, I’m extremely happy that I created Love Bytes and I’m excited to continue tinkering with the game and improving it in the future. I would especially like to recruit help from some other folks at some point who are better than I am at art and animation, to improve the character sprites (which I made in Photoshop) and the environmental art (which looks lovely but was not designed by me). I learned a lot from this process and am committed to improving the design and development process (at least a little bit) every time I make a new game going forward.