When I first left my job and started traveling around, I had assumed that all my newfound freedom would allow me to work non-stop on all of the “awesome” ideas that I had floating around in my head.
Unfortunately, as someone once put it, “It’s hard to think outside of the box once you no longer have the box”. Without any constraints, I felt myself losing the ability to do anything. Total freedom was much more difficult to deal with than I ever thought it could be. I knew it would be hard to stay motivated with zero constraints, but all the foresight in the world couldn’t prepare me for the total paralyzation of my mind and abilities in this situation. I basically hit "game-developer's block".
My first few months were spent mentally recovering from a rough year. A lot changed for me in 2013, and once I really had time to process it all - man, it was hard to work. Every time I sat down to work on something, I would inevitably browse reddit and buzzfeed for a few hours before giving up in total frustration. Where did all my ideas go? I spent the last few years engrossed in thoughts of all of the amazing games I would work on once I had real time, and now that I was faced with the chance - nothing. I would start a prototype only to throw it away a few hours later. The number of mostly empty “New Unity Project” folders on my desktop was steadily growing, and my motivation/perceived self-worth was dwindling proportionally.
After months of me struggling, Vlambeer's Rami Ismail suggested trying Game a Week. The rules of Game a Week were that I would take one new idea and explore it for one week. I would start Monday morning and put whatever it is that I have accomplished on my website Sunday night - even if it was an incomplete piece of junk.
Finally, I had some accountability. I had a goal to work towards, and deliverables that I had to achieve every week. The first few weeks were full of me trying to “cheat” the system in a way.
“Oh, well, I’ll give myself a few extra hours on Monday to finish this idea up”
“If I fail this week, I’ll just make two games next week”
“Maybe I’ll spend this week re-visiting an idea I had a little while ago and started prototyping”
I’d be lying if I said I could have done this as successfully without tons of external motivation at the inception of this challenge - Rami would consistently shoot down every one of those cheats and stringently encourage me to stick within the constraints - pick one new idea, develop it, explore it, finish it, don’t touch it again. Over time it became easier to push the "cheating" out of my way of thinking and focus on the games.
Each week I learned something new and each week I accomplished something. Even though 80% of the games I created were absolutely terrible, I finally had the reassurance of seeing something that I created appear every week. The accountability of having to put the games on my website for all to see was incredibly daunting and one of the other major reasons that I stuck to it. I can actually feel myself improving every week on various aspects of my game design skills. I won’t say I’m amazing at any of it in any way, but now that I’m forcing myself to think about new ideas every week, and critically explore my mechanics and game creation approach, I can definitely see the improvement.
I sometimes feel like my brain has a secret second brain hidden inside of it. My “second brain” is where all of my half formed ideas get stuck - it feels like a place where my ideas swirl around and distract my real brain from all of the work it should be doing. Game a Week forced me to empty out all of “what if” ideas that were caught in there. Some were fun, some were not, but the most important part is that once I was able to empty out all of those ideas, I could finally see new and more exciting ones. Without all of the old ideas floating around, I could feel myself becoming more focused.
I can’t talk enough about how much Game a Week has affected my game development - I also don’t have enough data points yet to definitively make an assessment on this either. I’m only now on my 15th week, but personally, I can see the difference. For me, one week is long enough to be able to properly explore one idea/mechanic to an extent where I can see whether it works as well as I think it should, yet short enough that I don’t become completely invested to the idea. I’m curious as to where the next 37 weeks will bring me in this.
Recap of Weeks 1 - 14
Idea: I tried to start small with my first idea. It was a game where you had to simultaneously control a number of circles and place them in a certain area to score points. I had no real direction in my head for this, it was just something “easy” that I thought could be “fun”.
What went right: Almost nothing. However, it was my very first game a week game and I definitely made something. I made something that you could theoretically interact with and had a very loose connection with the original idea.
What went wrong: I started WAY too late in the week. I think I started this game on Friday (honestly can’t remember, I just know it was way later in the week than it should have been). I also didn’t think my idea through before hand. I had a concept, didn’t put much thought into how to interact with it, and just made it.
What I learned: I need to start working on my game a lot earlier if I want to give myself ample time to properly explore the current week’s idea.
Idea: I personally really enjoy the idea of local multiplayer games and games that force a physical interaction. Some good examples of what I’m talking about are Game Oven’s Fingle, Kaho Abe’s Hit Me!, and Doug Wilson’s J.S. Joust. This was my little contribution to that movement. It’s a two player game where each player can potentially have to press any key on the keyboard. The goal is to be the first person to destroy all of your blocks.
What went right: I started this game as soon as I finished week 1. Taking my lesson from the previous week, I was able to really give myself ample time to explore this idea. The final product turned out almost exactly like I pictured in my head, and I finished it on time.
What went wrong: It wasn’t a super fun game like I had hoped. I didn’t really take into account how unbalanced the physical part of this game could be. Testing it with someone stronger and much larger than I am felt extremely unfair, as it was easy for him to bash on the keyboard and keep me away from my keys. Though that was somewhat the point of it, it became very not fun for me very quickly.
What I learned: The physically interactive games that I like tend to not be easily skewed based on size and strength - they’re more easily manipulated by skill and technique.
Idea: This game turned out frustratingly bad. I’ve always had an affinity towards how music can affect a person’s feelings and experiences, and this was meant to emulate that. I saw CHVRCHES in concert at the Boston House of Blues a few months ago, and the opening act, xxyyxx, consisted of one guy on stage with his macbook pro making wonderful musical experiences. This game was meant to be my interpretation of what that would feel like to do. I wanted to create an experience on the iPad where the player would interact with events on the screen in time with the music in order to feel like you were creating the musical experience yourself. Sort of a DJ-simulator meets Fantasia: Music Evolved.
What went right: Almost nothing. This game turned out nothing like I envisioned and was one of the ideas that I had poured over for a long time in my head. It’s hard to to see an idea that you’re super excited about die a horrible horrible death.
What went wrong: I did not take into account how difficult it was so craft an experience exactly like it is in your head.
What I learned: Ideas should be explored as soon as possible. I need to stop building up an idea in my head as a wonderful concept if I have no real proof that it will be an experience that I’m able to create.
Idea: This week had an extra constraint of trying to create a direct interaction with the game. The first three weeks had very indirect interactions, and it clearly wasn’t working well for me. I wanted to make a puzzle game based controlling two different characters. Sort of a one player Ilomilo meets Flow.
What went right: I was able to create a direct interaction with the game like I had set out to do. I also learned how to create music directly inside of Unity. I focused a bit more than normal on the game feel for this and was able to get a nice thing going for the game
What went wrong: I only made one puzzle and the music was very jarring.
What I learned: I am not very good at creating puzzles. I struggled even creating the one puzzle level that made it into the game.
Idea: One of my favorite games so far. This game is based on creating a tower as high as you can, while not letting it tip over. This idea is another one that I had in my head for a while. I like the idea of a simple balancing game (inspired by Eyezmaze’s Vanilla), and have been wanting to try my hand at something like this for a while.
What went right: I really enjoyed how this game turned out. It worked almost exactly like I had pictured in my head and most of the things that I had to change from my original vision were things that I was able to critically think about and produce in a way that actually had thought-out game design and purpose.
What went wrong: A few of my solutions for design issues were cheap. To stop the player from simply building straight up forever, I made it so that you couldn’t build on blocks in the center. There’s no reason for that other than a cheap solution to a bad design problem.
What I learned: Simple ideas are easy to explore. I need to stick with one mechanic/one idea and explore that one thing fully instead of focusing on an entire experience. It helps to talk through the reasons behind design decisions and to ask yourself “why” you chose to create the interaction that you’re creating.
My first failure. I started my game this week based on a memory of an old game from my childhood. I ended the week with zero interaction complete - just a sprite of a pegasus on a backdrop of pixel clouds.
What went right: I thought a lot about a game that I have fond memories of.
What went wrong: Well, I didn’t finish a game this week. After spending a few months in the Netherlands, I was faced with flying back to the US and couldn’t bring myself to work on anything because I was too busy moping around.
What I learned: I need to not let my emotions get in the way of my development. There was no reason to mope around and not create a game. Not creating a game didn’t stop me from having to fly back to the US, and instead just made me feel worse. It was a lose-lose situation all around.
Idea: With the surge of local multiplayer games, I wanted to explore an idea I had related to that. When I play Samurai Gunn, I spend all of my time on the character select screen wall-jumping while waiting for the other players to choose their character. I love wall jumping and think it’s an interesting and fun interaction. My idea was to create a battle setup where each player had to constantly walljump while fighting each other. Obviously, the concept changed a lot throughout the week. The result was a one player wall jumping game where the point was to get as high as possible without hitting an obstacle.
What went right: I started this game early in the week and adapted my idea to my time constraints.
What went wrong: I didn’t think through the design of this game nearly enough. There’s no purpose to a lot of the interactions, and there’s no real feedback letting the player know how well they did or what the point of the game even is.
What I learned: Wall jumping is hard to program. I spent the majority of my week working on that and it left little time to explore other parts of the game. I need to not let myself get hung up on one problem for the whole week. If I’m stuck, I need to move on and revisit later.
Idea: Another attempt at a local multiplayer game. Unlike Week 2, This one wouldn’t focus on the physical aspect of it, and just rely on the interaction between the two players. This idea was inspired a lot by Hokra. Hokra has such a simple mechanic that works very well. I wanted to create a game where you could play defensively and/or offensively and really think about the strategy behind each type of play style.
What went right: The finished product was close to what I had envisioned and the experience is generally what I wanted it to be.
What went wrong: It wasn’t actually that fun to play with two people. The gameplay was a bit too slow and the interactions were not as intuitive as I had hoped.
What I learned: Playtest. Playtest. Playtest. Playtest. I personally thought it was a fun game to play once it was finished. Not quite as action packed as a game like Hokra is, but I found enjoyment in it anyway. However, I only ever played it with myself. I didn’t have many people around to playtest it for me, and I didn’t send it to friends soon enough to get any useful feedback. A game like this is impossible to develop without constant feedback.
Idea: I tried something new this week. I had become increasingly annoyed at my ability to be easily distracted and also wanted to try a new tool. I combined those two things into creating my very first Twine game called Game Dev: The Game. I often joked about creating a game based on how hard it is to actually make a game, and this was my attempt at portraying that. I’m not much of a wordsmith, so creating a Twine game was an incredibly daunting task for me, but I figured that I might as well challenge myself at the things I’m not good at.
What went right: Twine is awesome. It’s a great way to organize your thoughts and simultaneously create a game. I’m proud that I successfully worked with a different tool and feel like I got the general feeling that I had intended across in the game.
What went wrong: I didn’t give myself enough time to explore this as much as I wanted to. With Steam Dev Days being the same week, I pushed this week’s game towards the end of the week after all the fun and excitement was over.
What I learned: Putting new challenges onto yourself is fun. I need to work more on my ability to create beautiful prose, and, again, I need to start earlier in the week if I really want to explore an idea fully (how many times have I “learned” this lesson by now?).
Idea: By far my current favorite game to work on. Back at Game City in Nottingham, me and Joonas started talking about an “oculus text adventure” game. I loved the idea of using a technology that advanced to make such a primitive experience, and he loved the idea of creating an experience almost entirely based on sound design. I decided to use this week to explore how a first person text adventure would feel at all.
What went right: A lot. A first person text adventure is something that I found to be very fun and different. The environment that it creates feels amazing and forcing people to use their imagination is something that I really miss about text adventures/choose your own adventure novels. I feel like I was able to create an experience that was somewhat unique and entertaining, and even created a few puzzles that I was quite proud of.
What went wrong: With Global Game Jam approaching, I didn’t have the full week to explore this idea again. Because of that, the end was entirely rushed and didn’t feel like it fit into the rest of the game. Whereas the first few sections were interesting puzzles, the end utilized a cheap “gotcha” with a creature chasing you and felt very forced.
What I learned: Out of the box ideas are fun. Using a technology not quite as intended leads to things that are interesting and novel. Sound design is important and I’m getting a little better at words and puzzles!
Another failure. This week was a weird one because I actually made multiple games/prototypes this week. None of them, however, fell into the Game a Week mantra and thus, I technically failed. I had Global Game Jam (you can see my team's game here) at the beginning of the week and then had a former co-worker/current collaborator was out visiting me all week in Colorado to work on a new project. We got a lot accomplished on this new project and Global Game Jam was an amazing experience, but between that and the 3 feet of fresh powder we got in the mountains, I didn’t even start a Game a Week game this week.
What went right: I got a ton accomplished in a lot of other aspects in my game development life. The new project I’m working on is going amazingly well and I’m extremely excited about it. Also, I had the best snowboarding week of my life. I spent most of my days back in the back bowls of multiple great ski resorts in the rockies and managed to not hurt myself (while snowboarding).
What went wrong: I didn’t make a Game a Week game :(
What I learned: A failure is a failure. I let too many other things get in the way of the one thing I said I would accomplish every week. I need to prioritize my time and not waste the the spare time that I have.
Idea: I decided to try my hand at a non-digital game this week. Because I rely so heavy on technology in my daily life, I figured it would be a fun challenge. And, as I was in Las Vegas for DICE, I decided that the only logical course of action would be to make a game using a deck of cards. There were a lot of constraints with using only a deck of cards to create a new game, but I ultimately settled on a two player game where you had to get your token from point A to point B. Each card in the deck would represent a distance and direction that you had to move and each player would attempt to reach their opponent's joker card first.
I used the value of the card for the distance you could go (dividing the value by 2 since the movement value would be way bigger than the playing area size otherwise) and the suite of card as the direction you moved.
Playing off of the theme of the Global Game Jam a few weeks ago, the direction of movement is relative to the player's viewpoint. This means that if player 1 is told to move left, then that player moves left relative to his or herself - not in respect to the playing area's orientation.
I ended up making a custom deck for the game, as the rules were incredibly confusing when told in the context of playing cards. This means that I actually ended up making a card game that works much better NOT as a card game, but at least it's non-digital as originally intended.
What went right: I set out to create a non-digital game, and I did so.
What went wrong: Again, I learn the lesson of playtesting. I had been working on this game on and off all week while at DICE (in between meeting with people and writing emails), but by the time I got it to a playable state, DICE was over and I was alone in a hotel room in Denver. I tried to play the game on my own, but it's borderline impossible to play a two player game (which relies on strategy involving hidden cards from your opponent) all alone. I'm still not even sure if this truly works as a two player game - even after reaching out to the all-mighty internet for playtesting help.
What I learned: The more constraints I have on my tools, the more I'm forced to be creative with a mechanic. I'm not saying that technology is bad (I would NEVER), but it's nice to put various constraints on yourself to see what you can come up with.
Also, writing the rules to a non-digital game is incredibly difficult. I had it all worked out in my head, and on paper, how it would work. However, creating a text that would explain to someone NOT in my head how to play this game was very VERY difficult. I have a new found respect for people who write the instructions for non-digital games.
HUGE THANKS to the ever-wonderful Andrew Gleeson for surprise making cards for the custom deck that are way more beautiful than the piece of junk I whipped up.
Idea: Inspired by a few of the more popular casual games out at the moment, I was curious to see what kind of experience I could create if I only allowed the players to perform one type of action. I settled on a simple mechanic based on your reaction speed and ability to make two things be the same size. I had some larger visions for this game when the week started, but I de-scoped until it was just one shape that you filled up over and over again.
After creating the core mechanic of the game and the basic loop, I realized that I didn't actually find the game to be very fun. I then decided - what better way to make something fun than to add a little friendly competition to it! I salvaged an old leaderboard system that I had in another game that I worked on last year, plugged it into this week's game, and POOF instant success (well, after 4 hours of refactoring and debugging an issue that only seemed to happen on the web build).
What went right: I was able to de-scope a lot of extra ideas earlier in the week. Also, the addition of the leaderboards at the last minute was a great last minute boost to the fun aspect of the game.
What went wrong: AGAIN, I learn the lesson of playtest. I didn't post the game at all until Sunday night, and while I was sleeping I got a lot of really great feedback. Because of my self-imposed rule that I don't work on any of the game a week after their week is up (at least not as part of game a week), I don't know when/if I'll be able to test some of these suggestions out.
What I learned: Competition is fun, and I need to really start posting a version of the current week's game by Saturday at the latest.
Idea: This week didn't actually start with a solid idea. I wanted to play around with a few features that I've neglected in Unity, so I simple started messing with a hinge joint to see what I could make it do. After creating the simplest of things (a hinge joint with an arm attached), I decided just to make another multiplayer game based on swinging an arm around to shoot balls into your opponent's goal.
What went right: The game ended up fairly fun. Also, I learned a lot more about how joints work in Unity!
What went wrong: I didn't get to add any sound effects or anything to this week's game. By the time I reached that point in my development process, I was in Los Angeles, CA staying at a hotel that didn't provide free wi-fi. Because paying for hotel wi-fi is incredibly silly, I was using a karma wi-fi device to connect to the internet instead. To save some data, I decided that downloading a bunch of sound files wouldn't be the smartest thing in the world.
What I learned: How to use joints in Unity. In addition, after playtesting, there were two things in particular that I changed which made the game MUCH more intuitive and fun.
1) Originally, the game worked in such a way that you would shoot the ball into the goal that corresponded with your player's color. This means that you started out by a goal of your color and you would shoot the ball back into that goal to score a point. Because I'm not much of a "sports person", this made sense to me in the respect of collecting the ball into your own basket. However, the rest of the game really lent itself towards more soccer or football feel. By switching it around so that each player was aiming to throw the balls into their opponent's goals, the game instantly became much more intuitive. The lesson learned here is that even if you're not particularly in to a type of game (i.e. sports), you should still pay attention to the various mechanics of what makes sense to the larger audience.
2) Skill vs. Luck based gameplay. Until playtesting, the arms of the players were about four times as long as they currently are. This resulted in two things. First, the player could swing wildly around and still generally make goals. Secondly, the player could easily block the entirety of the goal effectively preventing the other player to EVER score. By shortening the swinging arms to their current length (and increasing the goal size a bit), the gameplay instantly turned much more skill based as the player had to actually aim to hit the ball and aim at the goal.
On Failure
As you can see - out of the 14 weeks that I’ve been at Game a Week, I’ve failed on two of them. I have what I would normally call “valid excuses” for those two weeks, but in all honesty, any excuse is just that - an excuse.
Personally, every time I “fail” at anything, I take it hard. A failure to me reflects directly on my self worth as a human being and a contributing member of society. For example, failing at something such as Game a Week causes me to think: “Wow, you can’t even accomplish one measly prototype in seven days? You are a terrible game developer and will never be successful at anything ever”.
Obviously, this is an entirely counter-productive way to think, but when you’re laying in bed trying to sleep, it’s hard to keep your mind from wandering where it tends to go. I know a lot of people out there struggle with self-doubt and impostor syndrome, but even so, my mind still wonders “When is everyone going to realize that I have no idea what I’m doing?” (according to The Onion, it’s today).
I try to remind myself of all the things I’ve accomplished but, I generally end up rationalizing to myself why they don’t count as real “successes”:
Rational Adriel: “Remember that time you worked on Rock Band Blitz?”
Irrational Adriel: “Yeah, well, that was years ago and I was fumbling around in the dark and no one noticed. I actually had no idea what I was doing and can’t believe that no one picked up on that. I only really was hired because they were desperate for more programmers”.
Rational Adriel: “What about Train Jam? That got pretty popular.”
Irrational Adriel: “There’s no proof yet that it will be fun. Plus, I’m probably just making this organizing thing way more complicated than it needs to be. Someone else could have done way better with much more ease. Also, I’ve screwed up a lot of this along the way - it could be so much better.”
Rational Adriel: "Sooo, you do know that you wrote code that will go to space, right?”
Irrational Adriel: “So what? So did plenty of other people. That is a job that I objectively had no idea what I was doing at - I can't STILL believe I worked there for that long without anyone noticing how stupid I was.”
Rational Adriel: “Okay, well how about [X]?”
Irrational Adriel: “It doesn’t count because of reasons [Y] and [Z]”.
It’s a constant battle in my head, and a battle that I’m actively trying to remind myself is untrue and unhelpful.
At Steam Dev Days, I talked with another developer (well, I talked to A LOT of other developers, but this one is relevant to the proceeding story). He’s a developer who is working on a game that I personally find to be awesome. It’s creative, has received praise from other developers and news websites, was successfully kickstarted, and has been greenlit. In my eyes, this guy has everything going for him. After a bit of talking, he began to open up to me about his insecurities. He lamented about how he felt out of place because he hasn’t produced a finished game and how he doesn’t feel like he can talk to the other developers because he’s not “successful”. He even referred to me as someone who is more successful than he is. Here is someone that by all units of measure is further along on something real than I ever have been, wallowing in his non-success to me. This is such the quintessential example of the self-doubt that runs rampant in our industry.
A good dose of humility is a quality that I consider to be important, but it’s dangerous when it starts crossing over into a territory where it messes with your self-worth. It’s something that I’ve been actively trying to recognize when it’s happening to me and push the negative thoughts out of my head. These thoughts do nothing to help me accomplish the things that I want to, and are counter-productive in every way.
It helps to talk to other people both inside and outside of the industry to process these thoughts. Seeing others have the same doubts, the same insecurities, is almost reassuring in a way. If everyone could see how scared everyone else is, maybe we wouldn’t all be quite as afraid to try something new.
I’m trying to live my life in a way where I simply just try to do things things - no matter how scary and how big the risk of failure is. If you don’t try, you won’t know, and in my eyes, not knowing is worse than failing.
If you see something that should exist where it doesn’t exist - make it exist. If you have an idea that you can’t stop thinking about it - explore it. If you don’t like something that is happening in your life - fix it. If you want to do something but haven’t for one reason or another - please, just find a way to do it.
Failure is a part of any meaningful endeavor in life. If you're not failing, you're probably not taking enough chances. You should mitigate against the fallout from failure, but you should not fear it. You can learn from success, but I find that you learn much more from failing.
The overall theme of Game a Week has been to just start making things. There is a HUGE difference between thinking about something and actually doing something - and this experiment has only proven it to me more and more each week. You can extend this lesson into a lot of different aspects of life, and for me, it's been an incredible concept to take to heart.
You can play all of my game a week games here on my website, or follow me on twitter to keep up with the whole development process.
[Adriel Wallick wrote this article using Gamasutra's free blogs]
The horse piece in chess (the knight) moves is such a curious way compared to the others. RatoLibre1 made puzzle game Horse Jump to celebrate its L-shaped movement. 
