Now that I've outlined the games I created for the 2014 version of One Game a Week, I'd like to spent a bit of time reflecting on what that experience actually taught me. I certainly made a lot of mistakes five years ago, so in this article I want to outline the lessons I hope to have learned by now!
Scope is very, very important
If you take nothing else from this article, heed this lesson well -- in One Game a Week, and in game development at large, the most important thing you have to consider is scope. For anyone unfamiliar with the term, scope is essentially defining what you plan to implement for your game -- it's blueprint for what is and what is not included in the game you're going to make. I don't have a fancy academic study to cite, but anecdotally, after years and years of reading painful postmortem articles about failed games, I feel like this is something most developers could agree on: not having the right scope is probably the most common recurring problem in game development.
I am extremely guilty of this as well, and it's something I struggled with during OGAW 2014. Some of my projects were successfully completed during the 7-day time limit, but several of my projects were not completed on time and I spent a few extra days trying to get them across the finish line. This is because my scope was too large -- I wanted to try and include so many features, but I didn't have a realistic idea of how long it would take to implement them.
It's a classic problem that developers face, time and time again -- they come up with a fun idea and they want to build a certain type of game, but once you break that project down into its constituent parts, it turns out that its much, much more complicated to implement than first anticipated. Maybe you want to build a Zelda-like game -- well, that means you need to build movement, you need to build enemies, you need to have a way to create an overworld, you need a way to interact with NPCs, and on and on. Each of those systems could end up being a lot of work -- in its totality, it's not the kind of thing you can create from scratch in a week.
The right thing to do is to start out with something very simple, something you feel confident you could implement in a week -- and then cut that in half. As with most types of development, game development follows Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law."
Start small!
Making art for games is hard
In my mind, I visualized several of my games as having a particular aesthetic without really knowing how I was going to create it. It turns out, when you're trying to create a game, there's no part of the visuals that you can take for granted -- every visual effect, every nice animation or transition or fade to black -- all of that needs to be considered and implemented. And if you're anything like me -- a programmer with weak art skills -- it's often not as easy to just generate art that looks good. Usually, programmer art is pretty bad and even if you worked hard on it, a person playing the game is going to notice.
But what alternatives exist if you're not artistically inclined? When I was making these games back in 2014, I was totally broke and I didn't have much income to speak of -- I relied a lot on my family and friends to give me cheap places to live. So I definitely did not have any budget to buy art or hire an artist. Thankfully, there are lots of free options, such as opengameart.org or other similar sites where people host art that you can use either as public domain assets, or with attribution. As long as you're careful about what license is attached to each piece, you can usually bring together enough to get the job done. And by finding cool art instead of creating it yourself, you can save a lot of time on the development.
Not that making your own art is inherently a mistake! If you want that to be a focus of your process, that's awesome -- but just make sure you're aware of how much of a time commitment that can end up being.
Initial project setup (and other initial systems) are time consuming
Installing the game engine, getting the project set up, getting a character to show up on the screen, programming the player input -- all of this takes time, even if you've done it many times before. It can sometimes take your entire first day to get everything set up, and the first day is usually when your enthusiasm is highest! You want to channel that energy into the important, creative parts of your game -- not setting up basic configurations and waiting for things to import or install. I recommend having a template project with basic inputs set up, with basic reusable code structures intact -- you're probably always going to have some kind of AudioManager class, you might often have a GameManager class and if your game contains any kind of dialog, you're probably going to have some kind of TextManager. You can also set up your file structure -- in Unity, that often includes a folder for art, music, sound effects, scripts, prefabs, fonts, and whatever else you might use time and time again. Being able to start working on a game with all of this in place is so much more fun that having to set this up each and every time.
Don't cheat on the deadline
I ran into this problem several times during the 2014 edition of OGAW -- I would be working on a project and I would realize at a certain point (usually around Friday evening) that I wasn't going to be able to finish in time. Usually, my instinct was to just extend the deadline a bit -- after all, if I'm doing this project as a fun learning exercise, why not?
Well, I found out why not -- and the reason is motivation. It's a huge motivation boost to finish a new playable game each week. It becomes such a pleasant rush -- you get to show your new prototype to friends or family, and you have a real, tangible, playable game that you've just created. If you extend your development cycle past the end of the week, though, you deny yourself that gratifying finish line. It's a real bummer to not start something new on Monday. Basically, by not having a finished game, you end up generating this really negative sense of failure -- and it's super depressing and demotivating.
Instead, the right move is to aggressively cut features or content to try and move the target a little bit so that you're working toward an attainable goal. Cut as much as you need to in order to have a finished project at the end of the week. Even if it's not as awesome as you thought it would be -- it's much, much better to have something finished than to have to explain to yourself or others why you're still working on last week's game.
So over the next several weeks, I plan to be very strict with myself about not cheating the 7-day constraint. I want to feel awesome at the end of each week!
Your game will probably change throughout the week -- lean into it
There's a concept in fiction writing of two different types of writers -- the architects and the discovery writers. The architects spend a bunch of time planning out each individual chapter, each plot twist, and then they sit down and write it. Discovery writers, on the other hand, figure it out as they go -- they invent plot twists in real time and let the story carry them in the direction they find interesting at the time. When it comes to both writing and video games, I'm the second kind of creator -- a discovery writer (or a discovery developer, in the case of video games). So if you're someone who identifies as an architect, take this next piece of advice with a grain of salt -- but I certainly find it to be true.
Many of my games changed substantially throughout the week that I worked on them -- and yours will too. Sometimes, this is for artistic reasons -- you find better art to work with, or you decide that the aesthetic you're working with just doesn't look that good after all. Sometimes, the game changes for technical or scope reasons -- you realize you won't have time to implement a feature that you thought was essential, or you realize that it is much easier to implement something in a slightly different way which changes the game's mechanic. My advice in these situations is to lean into it -- let the game tell you what it wants to be. I think it's important to be a discovery developer while working on these short prototypes, because it's hard to know how long each component will take to implement, and it's hard to know what is going to be fun or what will look good until you see it on the screen.
You need to be flexible, and a lot of times, you will "find the fun" of your game along the way -- the best part of your mechanic won't be the thing you set out to make, but will instead be some silly thing you started messing with on the third day. It's okay to change the focus of your game to be about that silly thing. When I started making Canvas, I set out to make a traditional Zelda-like game -- but I was tweaking the color of some of the materials I used for the environment, and I realized I was having more fun playing around with the colors than anything else. Eventually, that led to me creating the core mechanic that actually ended up being the focus of that game -- using the Color Wand to paint certain objects and manipulate the world around you. That's how it goes sometimes, and the game I ended up with was a lot more fun than the one I set out to make.
Be adaptable -- be the discovery developer.
Those are the lessons -- now go forth, and create!
Those are the key lessons that I learned from my experience during OGAW 2014. I hope you find these points useful -- and I hope that both you and I can successfully avoid some of the pitfalls I've outlined above.
Well, I hope I can avoid most of them, anyway. I'll probably still have problems with scope. That one never really goes away.
--Kyle