The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

In 2013 I embarked on a year-long project to implement a game a month, experimented with new gameplay mechanics and created games that gave me hugs.

This may seem a little odd, but when I speak about games giving me “hugs” I’m speaking metaphorically. When I get hugged by someone in the real world, I feel a sense of love and acceptance. I wanted the games I made to help me love myself, love others and feel better about my life in general. I wanted to make games where a woman’s role wasn’t solely to be saved; where being single is the happy ending; where characters conquer the kinds of problems I tackle in my own life; where people work together rather than competing; and where I could be reminded that humans can be surprisingly kind to each other. I wanted to make games that accept me for who I am, not who I would rather be.

It also may seem odd to make games for the designer to feel something, rather than the players. However, my hope was that by making games that gave me a hug, they would also give my players a hug.

So over the course of last year I designed and built 12 unique games to give me hugs, all of which can be played for free via my website. In doing this project, I learnt much that I would like to share with you about design, processes, mechanics and hugs.

Why?

Together in Love: A game where you have to talk
to your friend so that you both move in sync.

Here are some of the reasons why I embarked on this project:

I wanted to implement and complete games, not just come up with ideas.

I wanted to work with different people on short projects so I could learn more about myself and be inspired by others and their ideas.

I always felt I was good at designing gameplay mechanics, but didn’t feel like I had much proof of this.

I wanted to concentrate on just a single mechanic and not get bogged down on games with multiple features. That way, I could test out what I liked working on, test what other people liked playing and what mechanics actually work and are fun.

As already stated, I wanted to make games that would give me hugs.

I felt like I achieved most of these goals for every game, with one notable exception: a game that, instead of giving me a hug, gave me an emotional slap in the face. But more about that later…

Games Created

Below is a list of the twelve games and gameplay mechanics created during my project and are a combination of digital and non-digital games. I gave each game a “hug rating”, from -5 to 5, indicating how much of a “hug” or “anti-hug” it gave me as the designer. This isn’t about how good or bad the game was, but more how it made me feel about myself.

Add excitement to a long car trip by quickly, but accurately guessing how far away other cars are.

Car

1

I obviously had my favourite games and ones whose gameplay mechanics I felt worked better than others. Interestingly, the mechanics that I thought were weakest were also the games that were the most difficult for me to complete. For this article I could go into details about the good and bad points of the mechanics themselves, but I’d rather discuss my process of creating the games, what went right and wrong and about how getting hugs from games made me feel better about myself.

The Process

Each month there was a somewhat standard process I went through in creating the game. Often this started before the month began. I started by talking to friends and colleagues to find out who was interested in working with me on a small game. I spoke to non-gamer and gamer friends, and would sometimes book in people well in advance.

I searched for upcoming game jams. By the end of the year I had participated in three 48 hour game jams: the Global Game Jam, the Molyjam and the SF Indie Game Jam. These days there are many game jams with different themes, so it is highly likely that you will find one that suits your tastes.

I maintained a loose schedule that paired up game ideas or teams/people to the remaining months of the year so I knew what I was going to be working on or who I was going to be working with for the upcoming months. For example, I knew I wanted to do a co-op adventure game in July, but ended up booking it in for November since I wanted to ensure I had enough time to complete the game.

Once the team was decided upon and the month began, the development could begin in earnest.

During the brainstorming phase I often spoke to friends to get feedback on an idea or had in-depth discussions with them to get tips on new directions I could explore. For example, when I was brainstorming my “audio adventure” game I knew that I wanted a game that had no visuals, but wasn’t sure about what sorts of puzzles were most suitable. So I discussed my preliminary ideas with friends and asked for feedback and new suggestions. This helped me come up with the mechanic where you move from room to room by entering a letter on your keyboard.

I also thought about the skillset of the team (often just myself), which meant we developed games with mechanics emphasising our skills. For example, in May I was working with an artist and a writer, so, instead of doing a game requiring significant programming skills, we created a non-digital game that needed a lot of writing and art assets.

I would then attempt to get a playable version of the game as soon as possible so I could see the mechanic in action. During implementation, I tried to make sure the majority of my time was spent on developing the mechanic itself. This often meant I’d remove any extra features or content that didn’t showcase the mechanic. For example, when working on The Will I started spending too much time on creating an in-depth “point-and-click adventure game”, instead of the new mechanic which was the two player keeping or sharing prizes. So I scaled back the point-and-click adventure game and added a new plot that changed based on each player’s choices.

I usually didn’t leave much room for testing and tweaking the game. Every month I said I’d give myself more time for testing next month, although I almost never followed through. Once the game was completed, I wrote up both the mechanic and the game description for my website and posted to Twitter.

What Went Right...

Switching between digital and non-digital

Throughout the year I switched between making digital and non-digital games, as this helped me get away from my desk and interact with people. It also challenged me to think of games in different ways by considering the strengths of the development platform. For example, I developed a mod to the card game Dixit, which was called Storytime. It relied on the fact that humans can make up amazing stories on the spot, something that is more difficult to do within the context of a video game.

Concentrating on the mechanic

I felt my goal to concentrate on just the mechanic, rather than creating interesting fiction or amazing art or so on, worked well. It meant I could focus on a single core mechanic that I wanted to explore, rather than attempting to combine a lot of mechanics into a complex game. It kept the games manageable so that I was able to stick to the timeline of releasing a new game and a new mechanic every month.

Getting better at working in teams

I’m an extrovert and I love being around other people. Getting better at working with others is something I want to be perfecting for the rest of my life. When working on a team, different people’s individual styles brought out different aspects of myself and helped me develop new and refine existing skills. Some of these skills included being a nurturing “mother” figure, being a persuader, being a diplomat, and being a listener. Just working in a team helped give me hugs and remind me that people are awesome.

Asking friends for feedback

Continually asking friends for feedback on the mechanics and content helped keep me inspired and work out how to make each game better. One month (for The AI with a Broken Heart) I asked friends for personal breakup stories I could include in the fiction of the game. I was surprised and delighted how many were able to contribute. It enabled me bring a more varied and realistic side to the story and made sure it wasn’t just about my experiences.

Storytime: A mod of Dixit where you work as a team to create a story with picture and word cards.

What Went Wrong...

Crunching at the end of the month

Many times I ended up crunching to finish the game by the end of the month. This made me frazzled so that at the beginning of the next month I needed about a week to recover and then I’d be behind right from the start. Luckily, game jam months meant I could get ahead and back on schedule.

Not setting up a version control system

I should have taken the time at the beginning of the year to familiarise myself with a version control system and set one up for personal use. Because I didn’t, it meant when I worked with other people on projects, we lost a lot of time waiting and fixing mistakes due to incorrect merging or overwriting files. It wouldn’t have taken me that long to learn and setup version control, but since it wasn’t directly “game development” I never took the time and I paid dearly in frustration.

Making a game that didn’t hug me

Most of what went right and wrong can generalised and applied to a number of the games in my yearly project. However, I felt that one particular game went horribly wrong...

As already stated, I was on a quest to make games that gave me a hug, so after I went through a breakup I decided to make a game about breakups (The AI with a Broken Heart). I believed I was over my breakup and making a game about it would be a cathartic and healing experience, similar to how I imagine it must be for people writing songs or poems about breakups. But for me it wasn’t…

Instead of the game giving me a hug, it gave me an emotional slap and generally made fun of me and my heartache. I wanted to make a black comedy, but often felt like I was making something that was simply black. I found the entire topic depressing and I struggled to separate what my character was going through from my actual life. It didn’t help that the game was about choosing emotions instead of actions, so every time I loaded the game, my screen was filled with the negative emotions people often experience in the middle of a breakup.

On top of this, I felt like the game mechanic didn’t fully work because it was difficult for the player to understand the potential result of their choices. For this reason it was also difficult for me to design the emotion options the player was choosing between. I had to imagine such things as: if I was "angry" or "self-loathing" or "manic", what would I do next? How would it make me feel if I deleted all email and conversation history with my ex? How does anyone get out of a negative emotion loop? If you are “hateful”, are you closer to getting over the breakup than if you are “inconsolable”?

Instead of helping me feel better as soon as I started development, the game made me feel worse and felt like it prolonged my breakup recovery. When I finally completed the game, I was simply very happy that I didn’t have to keep making that game anymore. It was as though a massive weight had lifted off my shoulders and I knew I really was well and truly over my breakup and could get on with my life.

The AI with a Broken Heart: Instead of choosing actions to take, players tell the AI how it should feel next based on what just happened.

What Went Right Sometimes and Wrong Other Times...

Creating games using my strengths

At times I found myself creating games that didn’t rely on my strong points, such as programming and art. For these games I was often crunching at the last minute and when I was done I felt unsatisfied with the game. The games I made in the months where I got assistance from friends and colleagues in my weak areas or made games that relied on my strongest skills were much more powerful. This was largely because we didn’t spend the limited development time attempting to learn completely new skills or take twice as long as an experienced person to complete tasks. It also meant that the game emphasised our skills and so each aspect of the game was given the attention it deserved.

Early prototyping

The game development went much better when the basic structure of the game’s core was outlined early on, particularly any puzzles in the game. If I had a playable prototype within the first week, the game turned out even better because then I knew the scope, knew that I had a good gameplay mechanic to work with and knew that I could just get on with creating the content.

However, sometimes the team or I would get carried away trying to come up with the perfect game or jumping straight into the development without thinking it through a little bit beforehand. This meant there were times when part-way through development I would realise the innovative gameplay mechanic wasn’t actually the main focus of the game and/or wasn’t particularly innovative. In those cases I had to spend a lot of time going back and working out what I really wanted from the mechanic and figuring out how to showcase that within the game as a whole.

An example of not prototyping early was during the Molyjam: our team spent a long time attempting to make the game multiplayer and eventually had to give that up in favour of completing a compelling single player game with Back to the First Date.

On the other hand, prototyping on The Dragon Whisperers was successful. The game relied on a new pictogram language, but before we designed the new language, we wrote out the story in English. We then developed a code using numbers and letters in place of the pictograms and tested using a simple questionnaire with multiple choice answers.

Scoping the game

Estimating the scope of a game was very difficult and prone to both successes and failures. One success happened during the Global Game Jam while developing Together in Love. The scope of the game was appropriate given our team’s skill level and the duration of the game jam.

During other months last year I attempted to create games that were way too large for myself or the team I was working with. The Will is a point-and-click adventure game with a multiplayer turn-taking mechanic layered on top. This meant I had to start by creating a point-and-click adventure game from scratch including the art and then layer in the new turn-based keep/share prizes mechanic. I should have significantly reduced the scope of the game or found more people to collaborate with.

Finding collaborators

Finding people to collaborate with was somewhat unpredictable. In some months, I collaborated with people who ended up having other pressures on their time arise, which meant we weren’t able to work on the game together anymore. When this happened I was left attempting to do their tasks or drastically changing the scope of the game. On top of that it made me feel somewhat lonely and abandoned.

Other months, I thought I was going to have to make a game entirely on my own and ended up having amazing friends pitch in and help me out when I most needed it which gave me bonus hugs.

Back to the First Date: Take turns playing as the woman or the man and choose from drop down lists to adjust what each character says in the comic.

What I Learned

Over the course of the year I learned a lot of things about myself, about gameplay mechanics, about game development and about hugs.

What I learned about myself

I can get a surprising amount done in a single calendar month if I push myself and focus.

I don’t like to fail in the eyes of the public, even though I knew my “public” was only a small handful of friends. Having said I would complete a game each month, I felt obligated to follow through by posting to Twitter and my website every single month.

I like making games with others. Different people’s individual styles brought out different aspects of myself and helped me develop new skills. Further, when I interact and share with others I know I’ll definitely get baseline hugs.

I learned how to be better at compromise and listening to other people’s opinions.

Other people’s ideas can be better than my own.

I like making games I can play with other people. Two thirds of the games created were multiplayer or co-op. I particularly like non-competitive games so that you can feel a sense of belonging with others.

I really enjoy creating games that have core themes of friendship, kindness, sharing and altruism. I also enjoy creating games that encourage players to have those attributes. I want to create games and experiences that have a positive influence on people and give them faith in humanity.

I don’t like working on games with a sad theme.

Games I make can give more back to me than they give to players. That is, I was excited to find out how well my goal to get hugs succeeded.

Team Ninja: Children could feel comfortable playing with adults because they had an adult on their team.

What I learned about gameplay mechanics

Ideas which I have been working on for a long time and seem great, sometimes aren’t as great when implemented (e.g Marie’s Mr Right).

Ideas which seem a bit lame initially can be awesome and work unexpectedly well with a different demographic than initially intended. For example, Team Ninja was developed as a way to get strangers to hold hands, but ended up being a great introduction for kids into physical games (since they could team up with an adult).

There are a lot of ways to do co-op gameplay. During the year I explored many different co-op mechanics, but I feel like I barely scratched the surface of the possibilities.

There are so many interesting mechanics to create without relying on violence and conflict.

Exploring different mechanics within a particular genre can give you a greater appreciation of the strengths and weaknesses of the genre. For example, I enjoy adventure/narrative games so 7 of the games made were heavily narrative/story driven and I was able to explore the genre to see which mechanics worked and which ones didn’t.

What I learned about time-constrained game development

Within a month it is possible to have a fully playable version of a feature that can be tested immediately to determine whether it works or not. Having something playable is much more valuable than a million untested ideas.

Scoping a game is very difficult. Even if you get it right sometimes, that’s no indication you’ll be able to keep getting it right in the future. Games can be so different from each other that predicting the scope and the development time can be extremely difficult. Luckily, practice does make it easier.

Having extra time to work on a game doesn’t always help. When I did a game jam it meant I’d finished a game in a short time and I could get started on the next month’s game. However, the games where I had extra time actually ended up being the hardest to complete. Having a short time meant I had to concentrate on what was good at the core and I couldn’t take the time to change my mind and try to make the game “perfect”.

What I learned about making games that give me hugs

I learned that games really can give me metaphorical hugs. If I continue to make games that give me hugs, at least I know at the end of development, even if the game doesn’t do well, isn’t fun or whatever, I will feel better about myself, will feel proud of what I have accomplished and I will feel loved. As a result, I want to keep making these sorts of games for the rest of my life since the process, as well as the result, makes me happy.

The Will: A two player point-and-click adventure which I created using my own art.

Advice to Others

Try making a game over a weekend or a month in whatever spare time you have. Try working with people who you wouldn’t normally work with. Try finding people who aren’t in the games industry, it can be inspiring because they come up with very different and innovative ideas.

If you feel like you’re stuck in a rut, doing one game jam or one short project can really help you. A short project allows to you try something entirely different from what you’re doing in your day job or in the rest of your life. There are little to no consequences of failure for a short project and, most importantly, you will have completed a game, which feels fantastic and rewarding since most game development lasts months and even years.

Keeping at a project to create a series of games will help you refine your abilities and help you learn about yourself and the sort of games you like to work on. My project helped me discover a game idea that I’m really excited about, so excited that I’m founding a company called Inquisiment to make the game.

If you are going to embark on a similar project to mine, choose a theme of games for yourself that make you feel a certain way. Perhaps making games that give you hugs isn’t something you feel any affinity with, so choose a theme that works for you. Consider games that make you laugh, games that help you make friends, games that improve your self-confidence, games that help you accept your life as it is, games that help you become a better person, games that restore your faith in humanity. The key is how they make you, the developer, feel. If creating the games makes you feel a certain way, maybe the player will feel that way too and maybe it will improve their life and help them to grow. The important thing to note is: even if you can’t manage to help the player, at least you will have helped yourself.