PLAY HERE

NOTE: Just like in last week, this post is coming almost a month after finishing the game. The lessons learned from this week are a bit clearer in my head since I didn’t start a new project right away (thus giving my grain some time to absorb some insights from the week), but apologies in advance if this isn’t quite up to snuff.

Idea

As this was my last Game a Week game for the year, and there were a bunch of organized jams occurring this week, I decided that it would be a super fun idea to make a game for both ProcJam and 7DFPS. Procedural generation is something that I’ve always had an interest in (but not the knowledge base), and FPS are something that I tend to avoid. So, what better way to end a year long project than to work on something WAY over your head?

I started out trying to think of ideas that would fit in both jams, but it became apparent SUPER fast just how hard that would be. As I had more ideas for first person games, I decided to focus more on that and hope that I could throw some procedural generation in later (yeah, right). I started out by deconstructing a bit about what makes an FPS and FPS and ultimately landed on the vision aspect of it. I decided that I wanted to make a game that played around with limiting your vision in unusual ways.

Eventually I concluded that lenses which only allowed you to see certain colors sounded like a really interesting idea to play around with. I then went into the week with only knowing the mechanic I wanted to play around with (and with no actually game idea).  Basically, I wanted to make a game where you would have two lenses (one for each eye), and you could see items only of the color of the lens (and the colors of both lenses in the middle where the vision overlapped).

What went right

I successfully made a shader! I knew that I wanted to/had to use shaders to achieve the effect I was going for, but I also knew that I knew approximately zero things about shaders. So, I reached out for some help from people who knew shaders and learned a bunch about shaders.  I’m sure my shader code is not super great, but it did the thing I wanted it to do, and that makes me proud 🙂

What went wrong

I spent a lot of time learning shaders and went into the process of making the game without having a game idea. This means that I spent a lot of time playing with the shader and almost no time actually creating a game idea. After jotting down a bunch of overly ambitious games, I ended up shoe-horning an infinite runner game where you simply had to avoid obstacles and collect stars. It was generic, not well thought out, and didn’t do my fancy shaders justice.  Also, I didn’t do ANYTHING for ProcJam 🙁

What I learned

A BUNCH about shaders. Here’s my shader (please don’t laugh).

PLAY HERE

NOTE: Because of an extreme case of holy-crap-I-have-so-much-to-do-and-I’m-so-burnt-out-on-game-a-week-stuff, this post is happening over a month after actually making this game. Thus, this is probably going to be short and not full of too much helpful information (seeing as how I can hardly remember the process of making this specific game).  Sorry!

Idea

I’m not sure where the idea for this game came from. I think I was trying to come up with a game that was just an infinite experience with minimal input.

I’ve always liked magnets, so it seemed like a pretty fun mechanic to play around with.  I also wanted to play around with an indirect control scheme again (like in week 45), so I decided to combine those two thoughts!

The original idea was that you’d have a charged particle that you could control via two magnets. Just like how normal science works- opposite charges would attract and similar charges would repel.  I ultimately settled on hovering a particle between two magnets that you could rotate but clicking on them.

What went right

I remember having a few nice design “ah-ha!” moments this week.  Unfortunately, I don’t really remember what they were after a month of sitting on this. I remember realizing that the game would get really stale feeling after a while of just avoiding obstacles.  I fixed this by switching charges on a regular interval and swapping the mechanic around so that now you would have to collect items instead. This keeps you on your toes and confuses the player a little bit – which I always enjoy doing.

What went wrong

I waited a month before thinking or writing about this game – so now I’ve basically lost 90% of the things I would have learned from making this game.  It’s not that I have that bad of a memory, it’s more that I gave myself exactly 0 time to decompress from this week. While doing something like Game a Week, you will generally immediately start thinking about the next week’s game upon finishing the current week’s. I relied heavily on these postmortems to collect my thoughts, figure out what exactly I learned from the week’s work of game development and solidify that new knowledge in my head. By putting this off for so long and then immediately jumping into a new brain-space after completing the game, I spent no time committing any lessons to memory.  I would actually say that this is my most failed week in terms of Game a Week, despite having actually made a game as I gained almost no long term insights from it (which is completely my fault).

What I learned

Holy moly postmortems are important.

PLAY HERE

Idea

This week, between Game City, a cold, and spending the first half of the week making a different game (which you can read about at the bottom of this post), I knew that I would have to work with a tiny idea if I wanted to have any hope of finishing something.

I struggled with creating an idea (as I’m still suffering from what feels like a brain completely devoid of any ideas), so I spent a lot of time trying to just think of something that even just SOUNDED like an idea. Ultimately, after discussing different ideas with a bunch of people, I landed on a simple two player game where you could shoot one bullet at each other and then had to dodge and deflect the two bullets back to one another until someone got hit.

What went right

I wasn’t really trying to emulate another game when I thought of this idea (though Samurai Gunn was definitely an inspiration), however, I went into exploring this idea knowing that it wasn’t really anything new or exciting (also, it hit me a few days into this idea that I basically came up with Lethal League, but with two projectiles). I think that this would have demotivated me in previous weeks, but I knew that working on an idea that I thought of in my own head (no matter how unoriginal it really was), would be better than nothing.

As I tend to do, I went to Lisa for advice when I was struggling through accepting this notion, and she reminded me that much like anything else, your design brain is a muscle that needs to be exercised. If I were to just give up and rely on someone else’s idea (as I was very close to doing), that’s not really exercising your brain muscle. I needed to come up with an idea, not immediately dismiss it, and allow my brain the satisfaction of working on something that I thought of.

So, the biggest thing that went right this week is that I allowed my silly little brain to think of a dumb idea and then not tell it that it was dumb right away (good job, brain!).

What went wrong

As I mentioned before, this week was busy and I came down with a cold that knocked me on my butt for most of the middle of the week. I didn’t want to push myself too much, so I left a lot of this week’s game off to little moments of work when I could/felt good enough.  Because of this, I didn’t really spend too much time exploring some fun stuff that I could have done with this game.

What I learned

It’s okay to make unoriginal ideas.

—

Bonus Rami Birthday Game!

I spent the first few days this week  working on a birthday game for Rami. There’s not a lot of “real” gameplay to it (you just dig through the earth and battle your way to Australia to deliver a birthday cake), but whatever – I just wanted to make something fun for someone I love.

(In case you want to, you can play last year’s Rami birthday game here)

PLAY HERE

Idea

This week’s game was inspired by this cutie right here.

I was staying with a friend in Nottingham for the week before Game City – and she, among her many other accomplishments in life, is the proud owner of a super adorable bunny named Chomsky. It turns out, however, that even though bunnies are adorable and soft and cuddly and cute – they are also little poop machines. They tend to leave trails of tiny little poop balls everywhere they go in a manner that can only be described as “reverse pac-man”. Because reverse pac-man sounds like a fantastic idea to explore, it very quickly became the basis of this week’s game.

The basic plan that I started this week with was to create a game where a bunny would hop around a grid with the ultimate goal of leaving a tiny poop nugget in every square.

What went right

The idea of a reverse pac-man came with a decent number of fun design exercises. Some of the questions I had to ask myself  were: Is the bunny in a constant state of motion? Are there equivalents in this game to the ghosts in pac-man? If not, what is the challenging part of covering every square in a grid?

I toyed around with a few different iterations of the idea. The first was almost exactly pac-man: I wanted to have paths and walls that the player would navigate around, with dung beetles that would roam the board and roll up the poop trails left behind into large balls that would block the bunny’s path. After tying that out and feeling as though it was lacking *something*, I decided to try out the same thing, but without the walls (i.e. an entirely open grid).

I liked the feel of this style better, but now the idea of dung beetles blocking the bunny’s path was completely useless. To solve this, I altered the purpose of the beetles. The beetles would no longer wander around the board, but they would randomly appear off the grid and traverse in a horizontal or vertical line eating up any poop pellets left in their path. This created a very frustrating dynamic because there was currently no way to stop the beetles once they went on the war path of eating all of your finely laid poop.

To solve THIS problem, I added a new mechanic to the game. Now, in addition to leaving poop pellets around, the player could choose to dig a hole in any of the squares of the playing field. The holes would trap the beetles and then disappear (with the beetle) after a certain amount of time. This meant that you could now mitigate the damage done by the beetles, which created a fun little dynamic.

At this point, the final thing I had to solve was the fact that there was no driving sense of urgency to covering the entire board. Because the bunny had unlimited poop laying powers, the player could simply keep moving and trapping beetles until the entire board was covered. In my mind, this felt less like an active “game” (which is what I was going for) and much more like a passive waiting game. To solve this, I added one final thing to the game: a poop meter. The poop meter represents the number of poop pellets that the bunny has left to dispense across the board. Because the bunny is constantly moving, and leaves a poop pellet behind at every step, the player now feels as though they’re constantly fighting against something finite to cover the entire board. I also added an item that the player could consume in order to replenish a bit of the poop meter. Randomly, across the board, a bunch of carrots appear every few seconds. The carrots grow larger the long they are left alone, and if the player eats the carrots, the bunny’s poop meter is replenished with an amount that grows with the size of the carrot bunch.

All of these things combined created a really fun (in my opinion) resource management game. The player is constantly torn between having to cover the board with poop pellets, stopping the beetles, and finding carrots to eat.

What went wrong

Most of this week’s game making was spent adding little new mechanics to solve problems, which I feel could have gone horribly wrong very quickly. Luckily, all of my decisions very nicely cascaded into one another and created an interesting and fun dynamic, but throwing new things at a game to solve a problem felt dangerous to me. I would have liked it if I had been able to come to these conclusions in more of a thought-out way (however, I am pretty happy with how this one turned out regardless!).

What I learned

Bunnies are adorable and are basically a reverse pac-man.

—

Bonus 0h Game Jam

Also happening this week was 0h Game Jam! Just in case you don’t know what 0hr Game Jam is, it’s a game jam that happens right as daylight savings time ends. You have one hour to make a game the hour before the clocks reset an hour. This means that from 2am until 2am, you have 1 hour to make a game (in 0 hours). Obviously, an hour is not a very long time to make a game, but it’s a fun exercise in creating something silly and quickly – and then tell everyone that you made it in zero hours. This year, I created a game about a flying penguin shooting little moles out of the sky. The moles were being carried around by balloons and…well…that was it. It was super simple, but a nice little break from what I was doing the rest of the week!

PLAY HERE

Idea

I’ve spent the last few weeks feeling extremely exhausted. Not physically exhausted – just unable to think or motivate myself. My brain is simply tired.

When I first started this challenge almost a full year ago, I assumed that I had approximately 1 billion million zillion ideas floating around my head.  It turns out that I had about five, and they were all crap. I have been able to spend most of this year being inspired by something eventually, but the last few weeks have just taken a toll on me. I spent most of the first half of this week debating on whether or not I would skip Game a Week twice in a row (which felt horrible). Every time I would try to think of an idea, I just felt like there was nothing left in the little creative cavern in my brain. I would think of a word in an attempt to spark an idea, however, the word would simply bounce off the walls of the empty cave of my brain – creating echoes off in the distance.

Eventually, I decided to do the only thing I could think of to address these feelings: make a game about them.

I settled on the idea of making a game that would serve as one long metaphor for how Game a Week has felt for me over the last year.  The idea was to place the player in a cave and allow for them to choose to fight the monsters in each cave, walk past them, or rest. As the player, you would have experience points, health, and (most importantly) an exhaustion meter. The exhaustion meter would deplete every time the player took a step or attacked with the sword, and could only be regenerated by standing still (while not engaging with the enemies in the room). Experience would only be gained when the player struck an enemy and health would deplete when the player is struck.

I wanted to make sure that I got across the constant pull I feel between gaining the experience of making a game/exploring an idea and giving my brain a break. I decided that the best way to do this was to make the player choose between fighting an enemy in a room (thus gaining the experience you need for subsequent rooms), and simply resting.

What went right

I think I did a pretty good job at getting my feelings across. The game (to me) feels as though you’re constantly under a time pressure to either kill the enemies in the room or take a breather – which is exactly what I wanted.

I had a really nice moment late one night into the development where I had one of the hugest most sudden epiphanies in the history of my game design history. I had been struggling with how to truly force the player to choose between fighting or resting in a way that felt thematically relevant to the story. I tried a few things – gating the player off until they chose one or the other, having the player step on one of two switches in each room (one would open the door and one would spawn the enemy) when all of a sudden (thanks to some gentle guiding), it finally hit me: A per-room timer.  By adding a short timer to each room, the player was now forced to quickly decide each room whether they would rest or fight. Once the timer expired, all enemies would disappear (so you could no longer gain any experience from them), and the player would have to move on (see, look at that metaphor!). Additionally, once the player start fighting the room’s enemies, the player CANNOT rest. Once you fight the enemies, you are committed to finishing that fight to the best of your ability without resting.

I also spent a lot of time this week teaching myself parts of Unity that I had been neglecting for way too long. I must admit that I had basically no idea of how Unity’s “new” animation system worked (I put this is quotes solely because it’s not even that new anymore – I’ve just been putting it off), and all of the 2D stuff that I’ve been doing was using a free tool called Orthello. So, I took it upon myself to finally suss out how all of this worked.  Additionally, I spent a lot of time adding little game feel effects to create more life to the game.  Though spending so much time on the aforementioned stuff took a lot of time away the design, it was nice to just learn something new and make something “look nice”. Because a week is so short, I rarely get to add bells and whistles to my games – and it felt nice and refreshing to allow myself to do so.

What went wrong

Oh, you know – same thing as always. Put it off for too long. Blah blah blah.

What I learned

One thing’s for sure, I’ve definitely solidly proven to myself that my greatest detriment is my own inability to properly budget my time. I tend to take on a lot of different projects thinking that I can handle them all – then they all tend to come to a head at the same time. This makes for big bursts of being overwhelmingly busy – which definitely isn’t conducive to pleasant game development.

Also, I learned about mecanim and a lot more about Unity’s built-in 2D features.

PLAY HERE

Idea

This week I was visiting family and living on a sailboat for part of the week. Because of these two things (mostly the seasickness, to be honest), I wanted to keep this week a little light. Also, because I knew that I would be seeing my 5 year old niece at the end of the week, I thought it would be really fun to make a game specifically for her. I know that she likes playing games a lot, as we’ve play things together every time we see one another (fun fact: her favorite games to play when she sees me are Octodad and the game I made for Rami’s birthday last year).

Last I had heard from my parents, my niece was doing well learning her numbers, but was having a hard time recognizing/reading them (especially those past 11).  So I decided that this would be a good place to start.  I’ve never made an “educational” game before, so I had no real idea what to do, or what would be useful, engaging, and educational to someone of this age. So, I decided to go with the simplest thing I could think of: I would have numbers floating around, and she would have to find a certain number of numbers (e.g. five 5’s or twelve 12’s).

What went right

Since it seemed like having cute and childish pictures to click on would be integral to holding her attention, I reached out this week for help on the art. I got a response back from Dina who said she could whip up a few cute animal numbers for me. I think reaching out for artwork this week was a really good move, since I’m obviously still trying to find a good art style for myself. By utilizing someone who had more experience and talent in that department, I ended up with a more polished looking product (which is definitely important when making a game for someone with the shortest attention span in the history of humanity).

I had my step-mom provide some “voice acting” for the game. As my niece can’t read all that well yet, I knew that the instructions for the game would have to be audio based. I also wanted to have a voice that said the number that she would be seeing. This was extra important to me as that seemed to be the biggest hurdle with her learning the numbers – recognizing the number visually and associating it with the word she knew for that number. Finally, by having my step-mom do the voices, this gave the game a nice extra personal touch to it for my niece (she immediately, and happily, exclaimed that it was Granny Shelly talking to her once she played it).

I had a little bit more planned for the game, but ended up cutting a few things out to keep it as simple as possible. I really wanted this to be a tiny game that she could pick up whenever she wanted and play a few rounds of. De-scoping was definitely my friend this week.

I was also able to easily put the game straight onto her Nabi Tablet as it’s  an Android device and the game was simple enough to just quickly export from Unity into an .apk file.  She caries that thing with her everywhere and is the device that she plays most of her games on, so I was happy with how easily I could put my own executable on there!

What went wrong

Not a lot went wrong with this game. I recorded the voice files in two different parts (1-9 then 10-20), and the second recording is significantly quieter than the first. I didn’t realize this until after I had completely chopped up the file into the individual clips and wasn’t sure of a good way to mass-fix the problem, so I simply let it be. I think it takes away from the game a bit as it’s a little hard to hear the numbers that my niece was having more difficulty with, so in retrospect, I wish I had fixed it.

What I learned

This was simply a fun week where I got to make a fun game for someone I love. It was a nice break from more intense game design ideas, and a great way to wind down from my excitement of making a game that I’m super proud of last week.

PLAY HERE

Idea

Quite honestly, I’m not entirely sure what sparked the initial idea for this week’s game*.  Something along the way made me think about space, which ultimately led to me thinking about orbits and gravity. Unlike Week 43, I didn’t go into the technical part of this week’s game with any clear vision of what I’d be doing.  I started out by looking up a few equations about gravitational force in space, implementing them in code, and then bending them to my will.  I pictured myself making a game where you would shoot a rocket into space and aim it in such a way as to slingshot yourself around the gravity fields of the various planets to get yourself to a destination.

However, once I got the gravity implemented, I attached a trail renderer to my orbiting object and proceeded to spend the better part of a day looking at the pretty pictures it was making.

It

made

cool

patterns

It was at this point that I decided that being able to move the planets around to change the fun patterns was way too much fun to play with to stick with the original plan.  So, I altered my game design to have a more indirect method of player input. Now, you, as the player, would have to create and destroy planets in order to control an orbiting object and collect various “star bits”.

What went right: This game was wonderful to work on – I actually think that I like this game more than Week 27 (which is still a wonderful game). One of the things that made this game feel so nice is that I didn’t force myself into a box with it. Once I realized that I had accidentally created something different than my original vision, I allowed myself to simmer in it and evaluate what I could do with what I had now.  One of the reasons that I was able to do this, was that I had started working on it more appropriately early in the week – this meant that as I saw that the idea had to change, I wasn’t in a state of panic trying to just get it done.

I made my own art again this week (reusing the Earth from last week). Even though I’m not really happy with what I was able to draw – I feel proud of myself for having made more original art assets.

I also took action to make sure that I was focusing on my tasks more efficiently. Because I have so many different things going on, I tend to become easily distracted by the other stuff that I need to get done. For example, if I’m in the middle of coding something and I remember an email that I need to send – I stop what I’m doing and send that email. This disrupts my programming flow, and makes me rush through the email (so that I don’t forget what I was working on). All in all, it’s completely useless.  So, I took this week to really sit down and adhere to the pomodoro technique. Basically, you split your tasks into 25 minute chunks and work (without distraction) for 25 minutes straight. After those 25 minutes are over, you take a 5 minute break and repeat (I used this website to keep track of my time). It worked really well for me, as 25 minutes seems to be about the length of time that it takes me to get something done without getting antsy about other tasks. I also enjoyed the 5 minute break, as I would generally then stand up and walk around (something I’ll forget to do otherwise).

I also discovered that putting on headphones fixes another problem that I seem to have.  Because I’m almost constantly around other people, and not particularly in a “working” environment (e.g. other people’s homes, conferences, really anywhere where people usually just talk to you because it’s a relaxed environment) – I find that I’m easily distracted by conversations. Whether it’s a conversation going on around me or one directed at me, it’s almost inevitable that the second I get into a rhythm with my work, someone will say something that draws me away from it.  By putting my headphones on and blocking out the noises around me, that seemed to cut it out almost entirely. Also, since the people around me, for the most part, knew that I’d be working in 25 minute chunks – they would hold off asking me a question, or including me in a conversation until my break time!

What went wrong

Honestly, not a lot went wrong this week. If I had to nitpick, I’d say that I didn’t start RIGHT at the beginning of the week – which meant that by the time I was completely in my groove, I did have to cut out a little bit of polishing.

What I learned

Find a working process that works for you – for me it was the Pomodoro Technique and noise canceling headphones 🙂

Also, gravity and space make cool patterns.

*[EDIT: I finally remembered what sparked the idea for this week! I was listening to Sigur Ros one night while falling asleep, and their song Sé Lest came on. This ended up making me think about space (the soft piano/xylophone part sounded like stars twinkling), when then led to the idea of flying around space utilizing gravity to move yourself]

PLAY HERE

Idea

With Fantastic Arcade happening most of the week, it was shaping up to be a busy one – which meant that I knew my game would have to be small this week. With all of the negativity surrounding the games industry recently, a flippant conversation with Fernando Ramallo led to me wanting to make a game where the only goal is to hug everyone.  I took this in a Katamari direction and ultimately decided that this week’s game would be about hugging people and growing larger, until you were large enough to hug the whole world.

What went right

I made a game about hugging everyone until you hugged the whole world. It’s a fairly pleasant game and I’m happy to have made something that, at its core, is about something positive.  Hugs are wonderful, and everyone could use more hugs.

I’ve been trying to make my own art more and more.  When I’m laying around and relaxing, I attempt to now spend that time doodling on my iPad. As someone who has always had a very “technical” mind, art has never really been my strong suit. I would draw when I  was younger, but it was always copies of already existing pictures. Creating an artistic vision out of my own head always seemed out of my reach.  This was one of the first weeks where I really tried to integrate my own artwork into a game.  It’s not wonderful, but I had a vision and made it happen.

What went wrong

My first week after my huge revelation of how great working on a game ahead of time is, and I procrastinated again.  Fantastic Arcade is such a wonderful event and there were so many great people to catch up with, that I had a hard time finding the time to work on my game.  It was a refreshing event, but I had a really hard time managing my time properly.

I also have a problem where, every now and again, events will cause a sneaky sadness in me.   I talked about it a little bit here, but while I find that attending events like this is helpful in 99% of the ways, I will sometimes feel completely demoralized by all of the amazing things that my peers are creating. I convince myself that I’m not good enough to ever make “something like that” and fall down this endless hole of self doubt.  This happened with quite the force this week, and made working on a happy game about hugging all the harder.  I’m out of my self-doubt hole for now, but that doesn’t change that it did happen this week.

This doesn’t excuse away my procrastinating, but it is why it happened.

What I learned

I didn’t learn too much in the sense of game development this week, but what I did learn is a lot of the reasons behind why I go down my self-doubt spiral of sadness. I’m hoping that in the future, I can recognize it a lot sooner and nip it in the bud before I really fall down the hole.

PLAY HERE

Idea

This week was fun because I spent my entire week staying in the home of my super talented game designer friend, Lisa Brown. As I’ve been notoriously bad at starting my Game a Week games far enough in advance to properly explore them, she swiftly began the week by pushing me into a few design exercises. We, together, brainstormed a multitude of ideas by utilizing the elemental tetrad (as learned from Jesse Schell in his book The Art of Game Design: A book of lenses). We made columns for each of the four design elements (mechanics, aesthetics, technology, and story) and spent a short amount of time on each element individually, writing down anything that seemed interesting to me and/or was was available to me for the week. After working with each column individually, we drew connections throughout the four columns (yes, even with help from Mr. Davis) and discussed the pros and cons of each idea until I settled on the one that seemed the most likely to hold my interest and be completed in a week: “A networked multiplayer memory game about travel”.

My original plan for the week when thinking about this idea was to create a game that integrated into google maps and had players work together to do something. As I found it harder and harder to conceptually flesh out this idea, I decided to focus a little more heavily on the “memory game” aspect of the idea instead of the “travel” aspect. While accompanying Lisa on her daily task of taking Mr. Davis for a walk, the game idea  quickly evolved into a game where two players would both be shown a board (one with hazards and one with the ultimate goal to reach) where they would have to work together in order to safely make it from the start to the finish.

What went right

This week I was forced to start my game early. Having somebody around to constantly encourage me (see: un-relentlessly badger me) to work and knock me out of the periods of procrastination was wonderful. When I first started Game a Week, I used the internet and twitter as something to hold myself accountable in order to get anything done. Now that Game a Week is so engrained into my weekly cycle, I’ve found it easy to put it off until the last minute. . .because as long as I meet the Sunday deadline – I did it. This has resulted in many weeks where I spend Saturday panicking and Sunday staying up until 6am. It was refreshing to work on something before Saturday hit!

This week, I also playtested a paper prototype version of the game before  delving into the technical side of it. To be totally fair, Lisa made the paper prototype, but we took it to Game Häus and played through it a few times with some of her friends (before our session of Betrayal at House on the Hill).  This immediately made apparent a few inherent flaws in the original design and allowed me to find that one “thing” that was missing from the design (and was keeping me from really starting working on it).

Another thing that went very well this week was that I had another person around me who had the time, energy, interest, and experience to joint design the game with me (and had the gumption to push herself into my guarded wall of game dev process).  I find that as indies, we almost pride ourselves on working alone and “having to do everything”. Even while on teams, it seems as though we take on every roll we can and clutch onto them with ever fiber of our being.  This week was a wonderful reminder that utilizing the ideas and experiences of another person can help alter your games in ways that you wouldn’t think of any other way. This is why being part of a diverse community feels so important to me – when you bounce your ideas around with someone who has a different background/experiences/ideals than yourself, new and wonderful ideas flourish.

What went wrong

I was incredibly resistant to working on my game in an appropriate timeline. For all of the times Lisa asked me how my game was going, I had a whole slew of excuses fresh and ready for her. Even with the encouragement to work on it so early, I still managed to have to stay up way too late on Sunday night to finish it.  Because of that, I didn’t have enough time to really make the networking portion of the game as robust as I had hoped. There’s tons of bugs with the network connections and it makes the game unplayable more than I would have hoped.

What I learned

I pretty much covered the “What I learned” portion up in the “What went right” section, so just go read that again. TL;DR: People are wonderful idea makers, procrastinating is bad, and playtest your game.

PLAY HERE

Idea

I actually had the idea for this game last week, but as I hardly even  touched it before the week was over, I decided to push it off to this week. I wanted to make a game that was simple in concept but hard and confusing to play. I decided that a game where you had to use almost every button on your keyboard in order to play would fit that description incredibly well.

My idea was that the player would assume the position of someone who controlled every traffic light in a giant grid of roads. Each key on the keyboard would switch the traffic signal from allowing for traffic from one set of directions to the other and the goal of the game was to get as many cars to the other side of the board without letting them sit for too long (and thus become enraged).

What went right

I created what I set out to create, so that’s good.

What went wrong

This week was (as were the previous few weeks) incredibly demoralizing for me in the area of game development.  I feel angry and saddened at watching amazing people leave the industry and I’m personally having a difficult time remembering why I want to make games at all.

What I learned

I’m not sure what I learned this week. I didn’t try anything particularly new or difficult, and things worked out on par with how I thought the game would turn out. I think I need to either push myself to create something more difficult (in terms of my design skills) or something more personal (to work through the things that I’m feeling right now) in the next few weeks.

PLAY HERE

Idea: Due to a lot of traveling, events, and other things occurring in the industry, I wasn’t feeling particularly motivated to make a game this week.  To sooth a lot of feelings I was having, I decided to spend a portion of my week doodling pictures. With these pictures, I thought it would be fun to create a game where the player would be presented with a series of random pictures and tasked with the goal of creating a story which would connect all of them (much like the children’s game Tell Me A Story).

However, after my laptop charger broke, I was left without a device that would allow me to easily make this game.

In order to continue making any game this week, I sat down with a deck of cards and made a non-digital game. My goal officially changed to creating a card game that was a single player game, and did not rely on the mechanic of separating the cards into piles (such as Solitaire or FreeCell).

What went right: This week’s game was designed with a lot of help from Rami. As we were on a long (looooong) road trip, we had plenty of time to sit without the distraction of technology and work through a solid design together. He started me out with just a few cards (I believe it was all four of the 2 cards from the deck) and we sat through all of the different ways we could create a game from them. We slowly removed constraints and added cards until we started designing a one-player fighting game.

It was incredibly fun to design a game with a completely different set of tools and constraints than I work with most weeks, and it was refreshing to work through a design with a fellow designer.  Sometimes with the Game a Week project, I find myself burrowing into a little design hole that doesn’t allow me to gain any insight from anyone else.  People will occasionally poke into my design hole, but I tend to only allow them in after the fact instead of during the critical parts of the design process.  Having other voices in your design is so incredibly helpful for you to see things in a different way. Everyone has their own experiences in life, and allowing yourself to listen to those other voices really fosters creativity and new ideas.

What went wrong: There’s not a lot that I would deem as having ‘gone wrong’ this week. Technically, losing access to my computer for an entire week could be seen as something that went wrong, but it was actually a wonderful thing. It was nice to get away from technology for a little bit and design a game outside of my comfort zone.

What I learned: Writing rules for a card game (or any non-digital game) is very VERY hard.  Without a digital presence showing the player how the game works, I had to rely on words to explain the entire thing.

Words are funny, because a lot of words mean a lot of different things to a lot of people. Even saying something as simple as “Place these four cards in front of you” is incredibly ambiguous.  Does that mean to place them horizontally? Vertically? In a pile? Face up? Face down? In a circle? What? If they’re horizontal and you say to look at the “first” card, what does that mean? The left most card? The right most card?

It was a very enlightening experience to rely on words to show how the game works.

PLAY HERE

Idea

My goal for this week was to focus, once again, on learning networking. I wanted to choose a simple (already existing) game, turn it into a multiplayer experience, and perform some simple networking.

I ultimately decided to play around with the game Snake.

Snake seemed like a simple game to incorporate multiplayer elements too and had the added benefit of a movement style that lent itself to very few networking latency issues.

What went right

There were relatively few design challenges related to the task of turning Snake into a multiplayer game.  I had to add additional apples for the snakes to eat, but other than that, the game’s original rules remained: Don’t run into walls and don’t run into yourself (or another snake).

Ultimately, two player snake felt very much like a slower version of Light Cycles.

What went wrong

I didn’t have time to incorporate networking into the game. I focused on getting the game itself to work and then added local multiplayer controls (as the control scheme for Snake is extremely simple, it’s easy to share the keyboard) –  and I did not manage my time well enough to get the networking completed.  This is something that seems to happen most weeks, and is increasingly becoming one of my least favorite traits about myself. As I specifically chose this game to learn more networking, it is a huge problem that I did not add any functional networking to this game.

What I learned

I am very very very bad at managing my time. I need to start front loading my week with working on the task most relevant to my overall goal for the week.

PLAY HERE

Idea

The idea for this week started out drastically different than the final product.

As it was my last week in the Netherlands for a while, my week was filled with sightseeing and “Dutch things”.  When you’re on a road trip through the entirety of the Netherlands, it’s hard not to wonder about how wind turbines and wind power works. After some research on the use and regulation of wind turbines, I decided that a game about maximizing the power output of a set of turbines based on the environment around you would be an interesting concept to explore.

I wanted to create a game where you would have to manage whether a wind turbine was turned on or off based on the wind patterns, weather, and bird flight paths. The more efficient your use of these, the more prifitable you would become, and thus, the more wind turbines you could install. It was basically going to be a game of managing resources (money, wind power, turbines) for maximum output.

After creating a simple sprite for a wind turbine and programming the on/off control, I decided to take a last minute trip to Berlin on my way to Cologne for GDC Europe and Gamescom to attend the Local Multiplayer Summit there. This was an amazing event, but unfortunately caused me to procrastinate on finishing this game until the train ride from Berlin to Cologne on Sunday afternoon. As I also hadn’t finished creating the slides for my talk that would occur early the next morning, I began to panic a little bit. One of my fellow attendees of the Local Multiplayer Summit suggested that I just simply scrap the idea that I already had and instead turn my presentation slides into my game for the week.

So, I did just that. I stopped work on the wind turbine game and began sketching out tiny little mini games for me to use on each slide of my presentation. I limited myself to a self-contained scene for each slide and wanted to ensure that each scene related to the subject I was talking about at the moment.

What went right

In terms of the wind turbine game – I made a pretty nice little wind turbine (that also turned on and off). So, that was cool.

As for the GDC Europe presentation slides, I think that a lot went right with them. After sketching out every idea that I wanted to incorporate, I prioritized each one in the order of importance. This allowed me to easily cut slides as the night went on. This was especially important as I only had about 20 hours to finish creating the entire game. I also reached out to someone that I knew would be able to create the art that I needed quickly and efficiently (thanks again, Andrew). I kept to a simple art style and made sure that each scene would only need a minimal amount of artwork to get its point across. Each game was kept as simple as possible, and I focused on the message of each slide instead of attempting to create something grand.

On the presentation side of things, I did two things, in particular that proved to be super helpful:

1) I added cheat keys. Each scene (slide) had an override key to allow me to simple skip forwards or backwards in the case that something went terribly wrong (i.e. an unforeseen breaking bug). Additionally, there is a bug that still remains in the final product that causes my character to fall through the floor. As I didn’t have enough time to fix it, I simply added a shortcut to reset the player’s position in each scene.

2) I sat down and typed out every single word that I wanted to say in my presentation into a text document. I wrote it exactly as I would want to say it and worded exactly how I wanted to say it. I put this text document onto an iPad, rehearsed from it before hand, and used it during the presentation itself.

Basically, as this was essentially going to be a live performance of me playing a game I made less than 24 hours beforehand (while attempting to say all of the things I wanted to say), I had to make sure that I prepared for as many things as possible.

What went wrong

I never got to explore the wind turbine idea. I think that it had a lot of potential as a way for me to explore a game about resource management, but through procrastination and then distraction by a “better” idea, it will sadly be thrown away forever. I debated for a while on whether or not I should discard the idea entirely (as in never to return to it again during the Game a Week challenge) or simply push it off until a later week and ultimately decided to do the former. One of my favorite parts of the Game a Week challenge is that it very quickly uses up the ideas that are in my head. By doing this every single week, there is always a void in my brain that is available for new ideas to seep into. I didn’t want to fill that part of my brain with an idea that could potentially sit around for weeks on end.

I will think of a new way to explore resource management, and it will build on the tiny bit of knowledge that I gained from even thinking about the original wind turbine idea. So, even though I’m sad that I won’t explore it further, I don’t think that it is a waste to no longer pursue it.

What I learned

This week reaffirmed the notion of trying things even when they sound ridiculous.

Here’s the GDC talk in its entirety for you to watch!

PLAY HERE

Idea

I had a particularly busy week ahead of me this week, so I wanted to work on a game that wouldn’t take too much thought or work.

As I’m a naturally clumsy person, it only seemed natural to finally delve into the idea of making a game about knocking stuff over when trying not to.  With that vague idea in my head, an online conversation with a friend eventually lead to the idea of creating a game of chess, but with big clumsy animal hands instead (which resulted in this very intelligent exchange).

I wanted to make a game of chess where you had to control the hands similarly to Surgeon Simulator, and force the player to exist in a situation where you can very easily knock everything over and mess it all up.

What went right

This week’s game was another exercise in just creating something fun and entertaining. I wouldn’t say I got as much joy out of creating this game as I did with week 34‘s, but I still just had a fun time making it. I needed a little bit of a break from the networking learning and had a super limited amount of time to work on this week’s game – and this was a nice little break.

What went wrong

As I was limited with my time this week, there were a lot of features that didn’t quite make it in. Some of them I think may have been for the better, but some I’m a bit disappointed in. These features include snapping all upright pieces to a valid spot after a move is completed, determining whether either player is in check or checkmate, and (if I was feeling up for it) a way to include networked multiplayer. I think that the determining check/checkmate would have been a very useful feature, but otherwise, I’m okay with the other features being passed over. Having the pieces snap to a grid space felt as though it would take a lot away from the intentional clumsiness of the game – and networking was simply beyond what my brain could handle this last week.

What I learned

I’m not sure what I learned this week – this was just a fun game about playing chess with bear hands. I didn’t do anything revolutionary or out of my realm of knowledge (not that I’ve ever played chess with a bear, mind you…), and I didn’t push myself in any real way. The biggest thing I learned this week is that chessboards are only 8×8, not 9×9 – which I unfortunately learned after spending an hour or so laying out all of my grid and pieces 😐

PLAY HERE

Idea

Continuing on my quest to gain knowledge of networked multiplayer systems, I wanted to spend this week working on a system where players could seamlessly drop in/out of a game revolving around one host player. Ultimately, I decided that a re-make of Asteroids would be the best way to go about this.

The plan was to have one player be the ‘host’ of a room and act as the ship while allowing for another player to join the room and take over control of the asteroids. While there was no second player, the asteroids would behave normally, but otherwise, the direction of the asteroids’ movement would be controlled by the second player.

What went right

Two player Asteroids works surprisingly well. Having one player in charge of altering the movement of the asteroids added a pretty interesting element to an otherwise consistently un-changed classic.

What went wrong

I didn’t budget time well this week. Between having to leave the Schengen Area of Europe due to visa issues, contract work, and the ending of Ramadan (basically meaning that I was hungry and tired all of the time), I couldn’t quite find the free time/motivation to do nearly as much as I wanted to on this game. Most disappointingly, I didn’t have a chance to really delve into the networking part of this game. As that was one of the biggest parts of this week’s idea, I’m incredibly bummed about that.  This was going to be a really wonderful learning experience in the type of networked multiplayer that I am hoping to achieve, and I essentially blew it.

What I learned

Honestly, I didn’t learn all that much this week that I haven’t learned before (see: any week I’ve said I need to budget my time better). I learned a lot about visas and Ramadan – but I’m going to save those lessons for a non-Game a Week related post 🙂

PLAY HERE

Idea

Once I complete my contract work, I’ve decided that I would like to spend some time exploring one of my previous game a week games further (not as part of Game a Week). One of the main things that I am planning on implementing in this game is a networked multiplayer feature. As I have no real experience with networking, I’ve decided to spend the next few weeks using my Game a Week challenge to also assist in me learning how to implement networking in Unity.

The idea for week’s game was the most basic idea that I could think of that would require multiple players to complete: it is a game where one player (it doesn’t matter who) simply has to reach a goal. Because the goal is sufficiently out of reach, multiple players have to work together to achieve this goal. I figured that this would be simple enough as a game and would allow me ample time to learn the basics of networking.

What went right

I got a networked multiplayer game to work. Thanks to a wonderful tutorial that I found by Paladin Studios, I had networking up and running in Unity in no time. This tutorial covered a lot of the things that I was wary of (such as simple synchronization), and was super super helpful (Thanks, Paladin!).  Though the stuff that I’ll need to do for my game will be a bit more complicated, this gave me a pretty good base of knowledge to work off of in the upcoming weeks.

What went wrong

A lot of the networking code that I ended up implementing for this game was incredibly messy and essentially un-reusable. I was hoping to be able to continuously build off of each week’s code as I go through this networking sub-challenge, but due to poor time planning and general lack of understanding of networking as I was going along, this week’s networking code ended up as a giant spaghetti mess.

What I learned

Networking! It’s not too hard in Unity, so that’s pretty cool.

PLAY HERE

Idea

The last few weeks have been busy and have left me feeling particularly drained. Ramadan has altered my daily schedule in an interesting way, contract work has been eating up a lot of my time, and the spare time I had left this week was spent with friends who were visiting.  In order to stick with my Game a Week goals and not utterly destroy myself, I decided to create a game that was just silly.

It’s no secret that I find farts hilarious.  I think Louis C.K. described it best when he said that you don’t have to be smart to laugh at a far, but you’d be stupid not to.  Nine times out of ten, a fart is purely hilarious – however, every now and again, a situation arises where you need to fart and you have no safe space to do so.  Whether it be a nice restaurant or in a church or surrounded by people you don’t know and/or respect – there will some day be a situation in which you can’t fart.  And that is when you will need to fart the most.

I decided to translate this experience into a game where you are stuck in a crowded room with no way to escape. The pressure inside of your bowels builds until you just can’t hold it in anymore – unless you are able to discretely release your toots.

What went right

Everything. There is nothing about this game that didn’t go right. I love farts, and I just spent the last few days making a game about farts and looking up fart sound effects and programming functions such as ReleaseBigFart() in scripts titled Fart. I wanted to make a game that would bring me joy and help me feel more relaxed (instead of stressed out with the pressure to finish something), and I accomplished that goal by about a million percent.

I think that this game fairly accurately captures the experience that I was going for and creates some nice tension between releasing little farts when you can, and bigger farts when you need to (all while running away so as to not be detected as the flatulence culprit).

This game was meant to simply make me happy – and it did.

What went wrong

This may be the first week where I legitimately can just say that nothing went wrong. If I wanted to nitpick, I would have spent more time coloring the characters in the crowd (as it is now, I just replaced a bunch of colors – and kind of poorly), but other than that, this game is exactly what I wanted it to be.

What I learned

You don’t have to take yourself seriously. I already knew this, but it’s a good lesson to be reminded of.  I spent the last few weeks placing a strange amount of pressure on myself to creating something “great” and “real” and I could feel it draining every last ounce of motivation and creativity out of me. Sometimes creating things can just be fun and silly and dumb, and that’s okay. Make whatever it is you want to make.

PLAY HERE

Idea

As I had a particularly busy week this week, I wanted to create a simple/minimalistic game.  I began thinking about an astroids-style game where your ship remains stationary (other than rotation), which led me down the path of exploring games whose main mechanic is rotation.  Inspired a lot by Duet and Revolvengarde, I settled on a game where you would shoot enemies and protect yourself while only being able to rotate your weapon.

Throughout the game, you gain various colored bullets, which only affect enemies of the same color.  In addition, the player would be able to switch between the aforementioned offensive mode as well as a defensive mode.  For defensive mode, the player could pulse with the currently selected color, which would deflect any similarly colored enemies that were within range.

What went right

The game turned out simple and fun. It becomes more chaotic as more colors are added to the gameplay, but it never feels overly chaotic.  All in all, exactly what I was going for with this.

What went wrong

I didn’t get to experiment with the defensive mode. Ultimately, I think the game is better with only having an offensive play-style (to keep to the minimalistic ideal), but as I didn’t actually play around with the pulsing mechanic, I can’t say for sure.

The game can also feel a bit too easy at parts. I didn’t balance the difficulty curve as well as I would have liked, and this is mostly due to lack of time.  I didn’t have a chance to allow for any play-testing before finalizing things, and this forced me to make a lot of decisions based on nothing.

What I learned

Controlling rotation with directional arrows leads to a funny thing in a person’s head.  When creating the controls for the game, I equated the arrow keys to how a car’s steering wheel and turn indicator light work. When you indicate right, your hands move the wheel in a clockwise motion – and when you indicate left, your hands move the wheel anti-clockwise. To me (and probably the majority of people who drive cars), this is an intuitive sounding control scheme, however I still found myself getting confused in times of panic.  I’m not sure of a good way to solve this particular problem (or even IF there is a good way to solve it), but it’s nice to be aware that even the most intuitive seeming controls can fall apart when under pressure.

PLAY HERE

Idea

This week, I wanted to try my hand at  a horror game.  Horror is a genre of any medium that I’ve always had a soft spot for, and as I’ve never tried to create an experience like that, it finally felt like the time to take up that challenge.

I very much enjoy the type of horror games that create uncomfortable and slightly claustrophobic situations.  To achieve this feeling in my game, I wanted to create a situation that required you to use your ears instead of your eyes to determine where the danger was located.  I envisioned a dark environment where you had limited sight to achieve your goal of getting somewhere and very much wanted to place the player in situations where their movement was limited (thus, creating a type of tension when trying to escape from whatever dangerous creature was around you).

What went right

About halfway through the week, I had a bit of a crisis of faith about my game. I had these ideas in my head (as explained above), but couldn’t quite place my finger on the ‘game’ portion of it. Luckily, I have a wonderful Lisa around to talk me through my design process.  She sent me over this extremely helpful article, and guided me through my thoughts until I was able to settle on a mechanic that made the game feel more complete.  I settled on creating an environment where you had to locate a moving object (a rat which held a key), and keep your flashlight on it for a certain number of seconds. At the same time, the enemy creature that was moving around would only be able to sense where you were while your flashlight was on. This created a nice tension between your ability to complete the goal as well as your ability to keep the enemy creature away from you – you had to trade off one for the other constantly.

What went wrong

Even though this game is mostly played with super limited sight, I think it loses a lot having no real graphics. This is a 3D game, and the best graphics that I could create on my own were spheres and capsules. I believe that having an actual creature that you see once you finally turn on your flashlight and gain visibility would have improved the horror quality of this game a lot.

What I learned

I learned a lot about creating tension and balancing the various components of your game. Utilizing the flashlight as both a negative experience as well as the only way to complete you task created a really interesting tradeoff.  More generally, I learned that when working on a game, the most elegant solution often feels the best. When I was thinking through all of the various ways to implement this game, I continuously threw extra items, rules, and mechanics at it to make it feel real.  It wasn’t until I stripped that all away to focus on just one major gameplay element that it all felt like it could come together in one cohesive experience.

PLAY HERE

Idea

In the spirit of branching out to features in Unity that I don’t use all that often, I decided that I wanted to create a game dealing with joints and hinges.  In addition to this over-arching goal, I was incredibly in the mood for the type of game that is frustrating yet master-able (is that a word? It is now) with enough practice.

I decided on a game about traversing from point A to point B through an area where everything kills you….using only grappling hooks.

What went right

I definitely made a difficult game – I’ve only seen a few people get through the whole thing, and it generally takes them a looooong time. This is what I was setting out to achieve and I think I did it quite well. You, the player, are faced with a seemingly easy task , yet it’s frustratingly difficult to execute.  I also implemented a quick restart system to help amplify the “Just ONE more time” feeling that tends be the driver of these types of games.

As hinge joints were the crux of this week’s game’s mechanic, I became quite familiar with the basics of how they work and can now add this to my bag of Unity knowledge.

What went wrong

For how much I used hinge joints in this game, there’s one part that I couldn’t quite figure out. In this game, I allow the player to use two grappling hooks to swing around (much like a monkey would with both of its arms). However, the way that I have it set up and the way that Unity’s physics engine works, the two grappling hooks will sometimes create a tension with one another which causes the grappling hooks to feel like they’re attached to sticks instead of ropes.  I played around with the settings and tried to understand how to fix this, but to no avail.  If anyone out there has any suggestions, please please send them my way (I’m just super curious at this point).

I also didn’t have enough time to play around with more intuitive controls. As it is now, the color of the grappling hook depends on which key you use to release it – this causes a lot of confusion in the situations where the rope further to the left, uses the keyboard key further to the right. In addition, I’ve seen a lot of people struggle with having to aim and click with the mouse to fire the grappling hook(s).  If I had had more time, I would have play-tested alternate control schemes. These types of issues make the game difficult, but in an incredibly frustrating way.

What I learned

Hinge joints!

Also, I’ve re-learned (yet again) just how bad I am at art – I  don’t seem to have an eye for user interface and/or colors. I have continually tried each week to improve my skills at choosing colors and creating more intuitive user interfaces, but even after all of this time, it’s definitely something I still struggle with.

PLAY HERE

Idea

E3 was busy. So much so that I didn’t really have a chance to seriously think about this week’s game until Sunday. I had a few ideas at the beginning of the week, including putting thought into a pervasive game that I could play during E3 (thanks Lisa for the suggestion), but none of the early ideas came to fruition.

So, once Sunday rolled around, my brainstorming session for this week’s game basically went as follows:

Me: “I need a game idea for this week – something simple that I can get done in 4 hours.”
Rami:“How about Pong?”
Me: “Okay, something Pong”
Rami: “Something Pong sounds good, what will you do with it?”
Me: “I don’t know, I’ll just make Pong and see what happens”

. . .and that was it.

So, finally, a little past midnight (four hours before I needed to leave to go to the airport) I sat down and made Pong. I decided that since the idea wasn’t particularly original, I would spend some time adding effects and whatnot to make Pong ‘feel’ good and play around with some of Unity’s features that I generally neglect.

What went right

Well, I made a game and it was Pong. Pong is a nice easy base to start from and it provided me with a blank slate to start playing with. Even though I didn’t have an original idea, after last week, it felt nice just to make something that was playable. I created an interaction and added my own little twist to it, which was a satisfying and motivational achievement.

Specifically, the mechanic that I added where you can actively reduce your opponent’s paddle size worked well.  It added just enough to make Pong feel a little bit more exciting, and doesn’t seem to make the game that much more chaotic to play.  It’s nice to see what a tiny adjustment to the core mechanics can do to a game.

What went wrong

I didn’t have a lot of time to make this interesting. I made Pong and Pong is, quite frankly, a little boring.  I wanted to use the base of Pong as a canvas to try out a bunch of Unity’s features that I never played with before – but due to lack of time, I was only able to touch a fraction of the ones I wanted to try.

What I learned

I want to branch out to the features in Unity that I don’t often use. I’m going to attempt to make it a point to try out something new every week that I use Unity from here on out.  Even something as simple as tacking on a trail renderer and playing around with the settings until it made something pretty was super rewarding.

PLAY HERE

Idea

My original idea for this week was to create a dungeon crawler about fighting goblins. This was mostly based on a dream I had a few weeks ago about eating dinner in a mansion that was eventually taken over by a hoard of goblins that I was able to fight off with a machine gun. It seemed like a pretty cool concept, and I really wanted to make a game about it.  I started working on it early in the week like a responsible human being, however I just couldn’t get into. Every time I tried to make something, I would realize how bland and unoriginal the idea was and just how un-excited I was about it. By Thursday, I completely scrapped the idea and had to start from scratch.

The second idea for this week was to create a simple game about pressing all of the keys on a keyboard. Basically, I wanted letters to fall down and you had to press the corresponding key in time to avoid losing the ability to use that key forever.

What went right

I made a game. I accepted the fact that I had to start over again three quarters of the week through and did so. The second game that I made worked how I wanted it to, and created the experience I was going for.

What went wrong

I should have realized earlier in the week that the first idea wasn’t going to work. Even though I did start working on the original idea earlier in the week than normal, I didn’t really delve deep into it until later in the week. By the time I realized that I couldn’t finish it, I only had two days, again, to finish this week’s new idea. It was particularly demotivating and didn’t allow me any time to test the game out on anybody before the week was over.

What I learned

Don’t base the entire week’s game on a fragment of an idea. I need to start actually designing the game fully (or at least a lot more than “Hey, a game about goblins would be cool!”) before dedicating my game a week time to it.

I think I’ve also learned that I need to take actual breaks every now and again. I realized this week that a lot of my “break” time consisted of me sitting on my computer and half working on things – this is a completely draining way to approach a “break”, and pretty counter-productive. Even though these games are small and incomplete most of the time, I’m still creating A LOT of content on a consistent basis, and I think it has finally drained me.  Brains need rest, and I keep forgetting to let my brain rest <3

PLAY HERE

Idea

The idea for this week’s game had been festering in my head for a few weeks. I sketched it out one night when I was feeling particularly alone, and I hadn’t really been able to stop thinking about it. Over the past few years, I’ve been trying to think of a way to portray a very specific feeling, and this is the first time I’ve thought of a way to do so. I am not going to elaborate on the feeling, mostly because I’m curious to see how well it gets across.

In terms of gameplay, I wanted to create a game where you control a bird-like creature who flies and soars around catching pockets of wind and teaming up with other flocks of similar creatures. The feeling of flying and gliding were super important to the experience, and was definitely the aspect I wanted to focus on.

What went right

I captured the feeling of flying exactly how I envisioned it. With some simple sine waves and rotations, I was able to take the vision I had in my head and translate it to the creature’s movement.  The ultimate product that I created, though it doesn’t contain as many of the features as I had hoped, does a decent job at getting the feeling across (from my perspective).

What went wrong

For how proud I am of how this game turned out, I have a lot to put in this section. I think that this is mostly caused by the fact that I was after a very specific experience here, which ultimately means that anything that varies from that can be see as a failure.

Firstly, let’s talk about my elusive bug. I encountered this bug on Sunday afternoon and it was the bane of my existence for a good portion of the day. The bug would appear only if playing and actual build or when playing in the editor ONLY if the scene view window/tab was closed. As you can see in the video, the bug caused the wings on the flocking birds to become disproportionate and would be “fixed” if you paused the game and moved the flock creature’s position in the editor (it would not be fixed if you moved its position by dragging the game object in the scene view). I struggled with it for a few hours and finally posted my issue to twitter curious to see if anyone else had a similar problem. Luckily, after a while a fellow by the name of Mike had a suggestion that ultimately fixed the problem. It turns out that the third party library that I was using for my sprites (which was ultimately overkill since I didn’t actually use any sprites) was storing and locking the rotations so that only rotating around the z-axis would work properly. This makes sense as a library dedicated towards 2D games, but as I was performing the wing movement in 3D space, everything went to hell. I’m still unsure why it would work fine if I had the scene window open, but by removing the third party library from the wings, everything finally worked (in terms of the wing flapping code).

Unfortunately, I wasted a lot of time chasing this bug and had to give up a few of the features I had planned because of it (well, that plus my poor time management this week).  This means that I never got to put in the wind pockets for you to glide on and didn’t have a lot of time to craft the experience that I wanted. There was a very specific path of flying around that I wanted to gear the player towards, but I had to settle for a much more random environment.

What I learned

In terms of process, I learned that when prototyping or working on a short/quick project, I need to stop giving into the allure of solving a bug. The aforementioned bug didn’t actually affect anything about the gameplay – it merely made the wings look ridiculous. The creatures flew fine and flocked as desired – and I should have left it at that. As mentioned above, I had to cut a lot of features because I wasted hours wracking my brain over this silly little bug.

In addition to this, I had a long conversation with the wonderful Lisa about pacing moments and crafting the feel of a game. We examined the patterns of ‘moments’ in various games and discussed how my game ultimately lacked the pacing structure that it deserved. The ultimate experience that I had in my head did, in fact, contain this type of structure, but unfortunately, I was unable to dedicate the correct amount of time to it. However, the thing to note here is that even though I feel that I thought of a decently paced experience (even if not implemented), I didn’t actually know that I did. By going through some design exercises, I now understand more technically why I wanted to pace my game that way.

I’ve also learned (for about the 27th time now), that I NEED TO START MY GAMES EARLIER. To help actually fix this issue, I’m going to now aim to get my games ‘feature complete’ by Thursday – giving myself  a few days to add the polish on.

Let’s see how that goes this wee-oh crap, it’s Tuesday already. . .

PLAY HERE

Idea

This week’s game was an experimentation in making a game that could emulate the feeling  I got that one time I finally made it to the veni vidi vici trinket in VVVVVV. I’ve always enjoyed the parts of VVVVVV that required a lot of precision with the gravity switching mechanic and movements. I very much wanted to emulate the feeling of fun frustration (or funstration, if you will) that you get when you attempt to perform a precise movement that requires a lot of practice – specifically the feeling that when you fail it feels like it’s your fault and not that the game is too hard.

What went right

The game ultimately turned out simple and fun – which was exactly what I wanted. I tested out a few alternative scoring methods to use instead of the obvious “how far did you get?”, but ultimately concluded that the nature of the game lent itself very much to just trying to get as far as possible before dying.

What went wrong

I don’t feel that I really captured the frustrating feeling that I wanted. This game isn’t particularly skill based – it’s mostly about precision and twitchy movements. I like those two things, but I really wanted to make a much more frustrating and skillful feeling game. I’m unsure how to really capture that at the moment, and it’s something that I’d like to explore further in the future.

What I learned

Like I said, I played around with a few alternative scoring methods as well as a few other “room” setups. I play tested it a few times and got a lot of really good feedback from people that I wouldn’t have gotten otherwise. It’s a lesson I’ve already learned, but it’s a good lesson to reiterate anyways. Play testing is good. Getting feedback is good.

A related lesson that I want to talk about is self-depreciation and skewing player feedback. I (and from what I gather, MANY others) have a habit of pre-empting negative feedback by declaring that whatever it is that I’m about to show off “isn’t done yet” or “isn’t very fun yet”.  The first person that I showed this game to, I sent it over and then promptly declared that the game “isn’t very good yet”. This was meant as an semi-apology for its rough state but mostly to make myself feel better about any negative reactions to the gameplay (since I already told myself and the player that it wasn’t good anyways). It also makes an positive feedback, if gotten, feel that much better.

This is bad.

This is an un-helpful way to approach getting feedback and presenting your work to others. By declaring that the game isn’t good before giving someone the chance to even see it, I’m already planting the seed of doubt in their head. They’re no longer anticipating a game that could be fun – they’re anticipating a game that “isn’t very good yet”. Now they’ll give feedback based on how to fix the problem of “not being very good” as opposed to  ways to improve the gameplay and usability. There’s a huge difference between those two types of feedback, and one is definitely better than the other in most cases.

Aside from that, I’m beginning to realizing how toxic it is to our self-esteem, as creators, to constantly be giving in to this feeling of inadequacy. We already all deal with impostor syndrome at every turn – why do we feel the need to make it worse by indulging in this idea of “not being good enough” yet? I talk about it a bit in the last section of this post, but this way of thinking literally does nothing to help improve our craft. Self-depreciation, even in the most “joking” of ways, is just an unnecessary hit to your self-esteem by the one person who should really be believing in you the most.

On a totally unrelated note, this now concludes half a year of game a week <3

PLAY HERE

Idea

I really liked the aspect of last week’s game where I tried to get the community to play together towards achieving one goal. In addition to that, I’ve also been thinking a lot about creating a game that integrates into twitter. So, I did the logical thing and smashed those two thoughts together.

I thought of a few different ways that I could use twitter in a game – using mutual followers to power you (the player) up, using key words from a player’s tweets to generate a level, utilizing the interactions between you and others as enhancing gameplay abilities, etc. Ultimately however, I settled on a Twitch Plays Pokemon style game. I had a lot of grand plans about a whole text adventure setup, but as most short projects go, it got de-scoped all the way down to a simple maze. With a maze, all I had to worry about was which of the four cardinal directions the ‘maze player’ could move in and which direction was input by the twitter players.

What went right

I’ve been playing around with twitter bots on and off for the last month or so while working on a joke project with a friend, so I was already somewhat familiar with how I wanted to set this up. I used this PHP library as a place to start, and pared it down to only the parts that I needed.

I used a python script that I wrote a few years ago to generate a maze with a guaranteed solution between two points that I chose and saved that data out to a text file which I then read in to the PHP script every time that it’s run. I read in the current location and which moves are legal, and then check all of the mentions associated with the most recent tweet by @mazeBotGame. I filter out all of the mentions that contain a direction (North, South, East, or West) which also matches one of the maze’s current legal moves and then choose one of those at random. The bot retweets the chosen command and updates its location to the new current location within the maze and then tweets a new tweet indicating which moves are now allowed.

All in all, it was pretty simple, and I’m pleased with how it turned out. I skimped out on a few things (e.g. it looks for the direction commands in the order of North, South, East, then West – so it favors multiple inputs in one tweet in that order), but it seems to work pretty solidly.

I’m also extremely happy watching people play with the maze. It’s been going for almost a day now, and people have managed to go from the top left to the bottom left. . . and then all the way back to the starting (in 73 moves).

What went wrong

I’ve been toying around with how often the maze bot checks for input. I originally had it at 30 minutes which after a few times felt WAY too long. I downed it more and more until I got to 5 minute intervals. Now, it feels a bit too fast. I like when people are playing it, but I also do want it to take time. I’m going to continue playing with the time interval over the next day or two until I really find something that feels right. Basically, I want to find the sweet spot of time where it will take a nice long time to solve but people won’t completely forget about it. I wouldn’t say that this has gone ‘wrong’ per se, but at the very least, it’s not ‘right’ yet.

What I learned

I learned a lot about PHP this week. PHP is one of those things that I’ve used a bunch but never entirely delved into. Between this week and last, I’ve definitely used it more than I have in a while. It’s powerful and interesting – but also slightly infuriating (seriously, it’s impossible to see where a PHP script is failing).

I’ve also been trying to put more thought into what I want the player to get out of the game and build the experience out of that as opposed to just working on one solitary mechanic. That’s why I’ve been struggling with the time interval for checking so much. I ultimately want Maze Bot to be used as a community experiment, where the experience of navigating through this maze is a long and involved process. I panicked a bit when I woke up this morning and the maze had only moved a handful of times (and was still stuck in the beginning 4 spots), so I set the time interval much lower – to 5 minutes. However, that takes the amount of time that community could play this down a lot, which completely negates my intention with this game. So, now that people have seen a decent amount of the puzzle (and even mapped some of it out!), I upped the time interval back up to 30 minutes. I think I’ll just leave it now as a mysterious maze that people slowly wind their way through, like originally intended.

So yeah, if you’re interested in participating in helping @mazeBotGame navigate its way through this maze, make sure you follow it in order to be updated when it makes a move!

Also, someone made a bot to play with my maze bot! Awesome!

PLAY HERE

Idea

This week’s game was made during the Game Changer’s Game Jam in Århus, Denmark, which I was invited to keynote at. This was a wonderful game jam that focused on making disruptive games with a purpose.  The theme of the jam (Justice) was announced by Michelle Mildwater, a representative from Hope Now which is an organization focused on helping victims of human trafficking and bringing those responsible to justice. She explained the various methods that are used to traffic people, the issues that arise when trying to bring the perpetrators to justice, and on figuring out what ‘justice’ means to the victims of trafficking.  Please, read more at Hope Now and check out some of the other games that were created at this jam.

So yeah, once I decided to also partake in the jam (as well as keynote), I sat down and tried to think of what I could do with a theme of ‘justice’. To get a better understanding of what justice means in the literal sense, I went straight to wikipedia. The two things that really stuck out to me were the concept of justice as a harmonious type of living and justice as a divine commandment. When I started thinking of harmony, I started thinking of music, and that basically led me straight down the path of a crowd source musical composition. I wanted to give everyone one chance to add something to this community and see if we could all work together to create a harmonious (and just) output. In addition, I thought it would be a fun experiment to (very rarely) add a type of ‘divine command’ mode, where the user could change the overall tone and feel of the song (key signature, temp, etc), to emulate the divine power determining what is harmonious and what isn’t.

What went right

Well, it seems to be working so far. People are adding notes and I (very loosely) put in the logic to only allow one note per IP address. So far, it’s mostly just notes, but I’m looking forward to what happens as time goes on.

Also, I discovered a super wonderful musical note rendering API called VexFlow, so definitely check that out if you ever need/want to display musical notes.

What went wrong

I way over-scoped this idea. To make this work, I needed to program in html, javascript, and PHP (none of which I’m particularly wonderful at), I had to have a few different modes for the site (pre-submission of note, post-submission of note, divine-mode) and I had to figure out how to display the notes, have a user input their note, and play the notes back. Even just divine mode itself was entirely over-scoped (it was to be a mode where you could basically change everything about the playback).  So yeah, the finished product is nowhere near what I wanted to do for this. Divine mode doesn’t exist, the user input is extremely confusing, and the playback is not very well programmed. Also, you can only place quarter notes….in the treble clef (there’s no bass clef support at all yet). The Overscope Monster definitely struck me hard this week.

What I learned

Obviously – don’t over-scope. If you’re going to only give yourself about 12 hours to make something, don’t program a game that requires you to interface with a database and uses three languages you’re only about 70% comfortable with.

Outside of game development, I learned a lot about human trafficking (both in Denmark and outside of Denmark). It’s something that I’ve thought about and read a lot about before, but I definitely learned some new aspects of it (e.g. it’s not just limited to the sex industry – it extends to factory workers, construction workers, organ harvesting, and more). Please, if you have a moment, read more about this issue – there are plenty of resources online to educate yourself on it.

PLAY HERE

Idea

I’ve been wanting to make a fun little shooter game for a while, so that’s what I wanted to focus on this week. I’ve also been thinking a lot about the idea of using your past selves to help you solve puzzles and/or complete the game (a la Super Time Force), as I love that concept a lot. So yeah, I  made a little shooter game where each loop through utilizes your former loop’s movements and attacks.

What went right

I really liked how the mechanic of your former selves continually looping through the game turned out. It was much easier from the technical side than I thought it would be (I literally just saved your position every [x] amount of seconds and on each loop through, I would place the game object at that location the appropriate time offsets), and it was a fun thing to play around with.

I also spent some time adding visual polish and a little bit of gameplay juiciness here and there, which made this feel a lot more like a complete game than my previous games.

What went wrong

The enemy movement is a little erratic. I made it so that they would jump after a semi-random interval, and then every time they touched the ground, it would randomly choose to move left or right.  This proved to be a little *too* random in a lot of circumstances and made the game more difficult than I wanted (and in a way that wasn’t fun).

I also had a really hard time getting the jump mechanic to feel right. In fact, I still don’t have the jumping behavior working in a way that I enjoy. Jumping is a big part of this game (since a lot of times the player relies on an accurate jump mechanic to avoid the enemies), and it just doesn’t feel great.

What I learned

Jumping is hard and erratic enemy movement really detracts from a game. There’s a fine line between something being frustratingly difficult in a fun way and just frustratingly difficult – having erratic and completely unpredictable enemy movements definitely seems to push things over into the bad kind of frustrating.

Big big thanks to Martijn Frazer who provided the super catchy tunes in this week’s game. And a continued thanks to Andrew Gleeson for making me a pixel character that I use in basically everything nowadays.

Also, I learned how to not make the desktop so blurry on my time lapse videos, but not for this week’s video. So, enjoy the last time lapse video that still includes a blurry desktop!

PLAY HERE

Idea

Right off the bat, I want to point out that I started this game on Thursday. I’m pretty excited about the fact that for the first time in a while, I was able to give myself ample time to create and gather feedback on a game – which I then would be able to act on.

The actual idea for this week didn’t really come from anywhere. I’ve been thinking a lot about games that I think are designed well and/or enjoy, and trying to pinpoint exactly why I think that. I’ve been doing this a few different ways – by talking design with other developers, writing analyses of games that I enjoy, and of course truly thinking about the design of my games – and one theme that I kept noticing was that of a heavily skill/practice based game. I like a game that you have to work to be good at – a game where you truly feel rewarded for the time that you put into it.

So, I thought of a game where you fly through various obstacles as close as you can without hitting them. Not the most original idea, but fun to try out!

What went right

I had a lot of time to work on this game. Despite also working on another project this week – the fact that I had literally nothing else going on meant that I could really sit down for some long development sessions. I was able to sketch out a few ideas and really think about what I was doing (instead of hurriedly creating SOMETHING before an arbitrary deadline).

I think the core concept of flying around and avoiding obstacles turned out fairly engaging. It’s a game that you can keep playing and improving at, which was basically my only goal for the feel of this game. The better you do, the harder it gets and there’s a pretty quick restartability to it.

What went wrong

I designed the game so that the closer you get to a bar the more points you receive. In addition, if you achieve the really close score level multiple times in a row, you get a pretty large score multiplier. I was hoping that this would draw players in to being a bit more risky with their movements in order to achieve a high score, however, I found that a lot of people I talked to would simply take the less risky option to stay alive.

What I learned

High score isn’t as strong of a motivator for risky moves as I thought. I should think of more creative ways to force the player to play the way I expect. Also, holy crap is it nice to have real time to work on stuff again.

I also started playing around with recording time lapses of my development. The software I found that can make time-lapse videos on mac takes incredibly blurry shots of the desktop which I’d like to fix, but for now – here’s some videos of me programming and walking around.

PLAY HERE

Idea

After a long week of international travel followed by PAX, I didn’t really have a chance to think about a game this week before Sunday again. I was exhausted both mentally and physically by then, but I was determined to still make a game. After discussing some game ideas, I started thinking about the old Police Trainer arcade game that I’d always play after catching a movie as a teenager, and the various mini-games that it contained.

There were two mini-games in particular that I was good at – a game about shooting the numbers 1-16 in order and one about matching patterns. I decided to try my hand at a little game that essentially combined those two games.

What went right

The design process was quick and simple. I had a vision for my game and executed it exactly like I had wanted to. I think it turned out pretty fun and had a nice interesting self-competitive feel to it.

What went wrong

Not too much, honestly. Again, I had way too little time to properly explore this idea, but I still feel like I was able to try it out well enough.

What I learned

I had a lot of positive feedback on this game. The big problem, however, is that I don’t understand why. I’ve played it a few times since making it, and while I find it fun, I haven’t been able to figure out what makes it better than some of my previous games. I’ve been trying to focus more on understanding the little intricacies of game design and what truly makes a game ‘good’ – and this week has shown me that I still have a lot to learn about this.

PLAY HERE

Idea

I was thinking quite a bit about Super Hexagon this past week and I wanted to create an experience where I could evoke many of the same feelings skill-based of accomplishment and frustration (accompstration, if you will). I devised a game where shapes would constantly fly towards the screen and the player would either rotate the screen to get the ‘player piece’ through or move the mouse to avoid the walls of said flying objects – I ultimately settled on the latter.

What went right

The only thing that really ‘went right’ this week is that I made a game. Other than that, please see the ‘What went wrong’ section for more information about this week’s development process

This, however, is one of the very best things about the game a week challenge. No matter how ‘bad’ I think the game is, how un-fun, or even how broken it is, at least I’ve still created a game. Every single week, even if the game is ultimately a disappointment to me – it is still a game.  These micro-accomplishments have been so incredibly helpful proving my worth as a game developer to myself (and maybe to others, but at the moment I’m focusing on my feelings towards myself), because every week I can look back to see that I put thought into a game system and created something that people can play –  that is amazing to me. Even on my most disappointing weeks, the feeling of accomplishment far outweighs all of the negative.

What went wrong

This week fell victim to yet another incredibly busy week in the land of Adriel. I started my week in San Diego and ended my week in Orlando – between those two I also visited Los Angeles (for a day longer than intended thanks to my inability to read parking signs) and Vancouver. In addition to the traveling, Train Jam is fast approaching and my larger project is crunching to get a demo ready for GDC.

Needless to say – I was busy.

However, Game a Week has become so ingrained in my weekly schedule that it doesn’t even really cross my mind anymore to skip a week (okay, maybe a little – but it’s much easier to ignore that little voice nowadays).  I’m not setting out to make amazing games – I’m just setting out to make games. So, even though I didn’t have a moment to spare for game a week until I got on my plane to Orlando on sunday (after having legitimately pulling an all-nighter on Saturday), I still powered through extreme exhaustion to make something.

I wish I had started thinking about my game a bit earlier. This week’s game, even though I was busy, could have been more solidly conceived earlier in the week. However, I had simply moved game a week entirely to the back burner of my mind until way later than I should have.  The end result was something that wasn’t challenging, engaging, or fun – just . . . . tedious.

What I learned

Making games is good! Even when I’m disappointed in the end product of a game a week game, at least I’ve still made something. Micro-accomplishments are motivating, and I should attempt to keep game a week further towards the front of my brain during the week.

Secondary lesson of the week: Time sure flies. I swear it was only a week ago that I thought to myself “wow, can’t believe how quickly Train Jam sold out – good thing I still have a  few months to figure everything out”. EEK!

PLAY HERE

Idea

As I’ve always been the type of person to prefer number games over word games, I decided to try my hand at creating a version of SpellTower – but for numbers. I started out the development attempting to jam Threes! into it, but ultimately settled on drawing inspiration from the kid’s game Fizz-Buzz (this also pops up as a simple entry level programming test quite often).

The rules off Fizz-Buzz are simple – you pick two numbers (generally 3 and 5) and designate each as either ‘fizz’ or ‘buzz’. All participants then stand in a line and begin counting successively one after the other. If a participant has to say a number that is divisible by 3, they say ‘fizz’ in place of the number – and then the same for 5 (except saying ‘buzz’). If the participant is meant to say a number that is divisible by both 3 and 5, they should say fizz-buzz. If you miss a fizz/buzz/fizz-buzz, then you’re out of the game. This is a practice that is meant to help children learn how to divide, and I remember it being a fun event (though, I was a nerd from a very early age, so maybe ‘fun’ isn’t the right word most would use).

Anyway, I smashed Fizz-Buzz into SpellTower and created Divisibility. Divisibility is a game where you have to find numbers that are divisible by either one of the numbers at the top.  If you find a number only divisible by one of the other, the number at the top switches for a new number. Otherwise, you can continue with the same two numbers while building up score multipliers.

What went right

I’m really proud of how this game turned out. It looks nice (big thanks to Rami for some late night quick art assets), the game play is solid, and I think it’s a fairly engaging game. I also spent a lot of this game’s development cycle really thinking about the decisions I was making and discussing them through with other developers. I felt like I had a vision for this project and executed it in a very intentional way.

What went wrong

If you noticed, I intentionally danced around saying how long I spent on this project and referred to things such as “this game’s development cycle” instead of “this week”. In truth, I didn’t start this game until Saturday night, and didn’t even come up with any semblance of an idea for it until Saturday afternoon.

I spent the beginning of my week hanging out at Glitch City working on my larger project and then the next few days reveling in the fact that I wrote an article for Gamasutra and people liked it. The rest of my week was then spent putting pressure on myself to produce a game I could be proud of.  I essentially took everything I wrote in that article – everything I’ve learned over the last 14 weeks – and threw it out the window. I found myself wandering around the house I was staying in frustrated at not having an idea and panicking over how I was going to fail immediately after telling the world how wonderful everything was.

So that happened. I let the pressure of ‘having to’ produce something cloud my ability to simply just produce something – effectively negating the entire point of Game a Week (at least for me).

Once I was able to wrap my head around what was happening in this silly little head of mine, I was able to fix it. I went for a run, took a nice long shower, and spent some time intentionally not thinking about making my game. I calmed my brain down and was finally able to focus on just creating for the sake of creating instead of as a show for others. (Funny note – even writing this summary of week 15 has been more difficult than it should have been. It’s amazing how much a larger audience can paralyze your entire brain).

In terms of the actual game, I really struggled with creating art. Even though I started the game very late in the week, I completed most of the core gameplay by early Sunday. I then decided to spend an actual chunk of time Sunday night trying to make real art assets for myself.  It turns out that whatever it is that people have in their brain that allows them to see when colors look good next to each other seems to be completely missing from mine.  I can appreciate things that look nice and I can picture it in my head, but trying to get it out of my head is where I truly struggle.

What I learned

Overthinking and pressure seem to completely halt my brain. Also, a cohesive color scheme and some actual time spent on art makes a game look way more finished and feel much better. I’ve learned that in addition to honing my game design skills, I can also use this challenge to work on my visual design abilities. I’ll now be spending a bit of each of my weeks focusing on the visual representation of my games.

PLAY HERE

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. Other than that, no exciting development revelations this week!

*EDIT* Upon further discussion, it turns out that I also learned quite a bit about communicating game play to the player. 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.

PLAY HERE

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.

PLAY HERE

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.

—

Also, 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.

PLAY HERE

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 well

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.

PLAY HERE

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 well

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.

PLAY HERE

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 well

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.

PLAY HERE

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 well

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.