Exploring above the clouds

In January I participated in the Global Game Jam at the Vancouver location. I worked on a game called City Pulse with Shane Morin and Mex Hsu. Shane  pitched an idea where you revive a dead city by moving pulses throughout the area using pumps. It took awhile until we were able to concretely define the gameplay but we finally settled on using energy towers that send out pulses that degrade over time. The concept was inspired by Space Chem but the final version turned out to be more action oriented than puzzle focused.

What went right

1. Choosing Unity – I’m fairly confident in using Unity and Shane also had worked with it before. We didn’t have much trouble getting the game running.
2. Creating levels – My other game jam games either had a single level or procedural levels so I was looking forward to having multiple levels in this game.
3. Last minute sound – Gordon McGladdery did a fantastic job creating some quick sound effects hours before the deadline. It turned out to be a great collaboration because I was accustomed to adding audio at the last minute in Unity.

What went wrong

1. Missing visual feedback – The directional towers didn’t have an animation to indicate they were charged. It was also hard to see which buildings were the critical ones that needed to be lit up.
2. Everyone wanted to tap the heart – We designed the heart to emit a pulse when there is no pulse or tower left with a charge. It’s automatic but players continued to tap on the heart even when we told them it did nothing.
3. Slow start – We weren’t able to start programming until late the first night. The Ethernet ports weren’t working so Shane and Mex couldn’t connect to the internet to activate their Unity license.

Overall it was a really fun project to work on. Since then I have fixed a few bugs and made it easier to see which buildings you need to power. You can play the game in your browser if you have the Unity Web Player plugin installed.

In December I started a new card game project. The goal was to make a simple game that could be played with no hidden information so it could be played locally on the iPad. At first it started as a tutorial project for a video series I’m planning to make on how to use Card Maker for prototyping. I did a top down design planning out all the hypothetical interactions ahead of time. The first game I played with my mom wasn’t fun at all. It felt like there was a lot of work to make it fun. Then I tried a 4 player game with some of my Magic: The Gathering playing friends. To my surprise it was immensely fun and actually fairly balanced. The design just worked.

I spend the last few months on and off refining the rules and prototype graphics. It’s getting pretty close to being complete. I’m hoping to either start a Kickstarter to fund an initial printing or upload it to the print on demand service, The Game Crafter. Here’s a picture of the latest prototype.

This month we focused on tweaking existing systems and balancing game objects based on feedback from playtests. There are a few big issues left to solve such as giving players more control over how they gain cards but the game is fairly stable and is still very fun to play. We have been working hard to speed up the game and make it easier for players to arrive at correct decisions to reduce analysis paralysis. At the start of the month a four player game took around 4 hours to complete and we have brought that down to 1.5 hours, which was our goal. I thought I’d share how we sped up the game in this post.

Using metrics – We started timing how long it takes players to finish each phase of a turn and used that data to focus our efforts. We didn’t do this right away so we ended up optimizing phases that only yielded a saving of around 10 minutes. The result was more elegant systems that were easier to learn and use.

Removing cards that slowed down the game – Most of the Tech cards and quite a few of the ships prolonged combat because they were defensive in nature. Both of us like playing defensively in other board games so this subconsciously affected our design. Now that we are aware of the issue we have a column in our spreadsheet indicating if a card speeds up, slows down, or does not affect combat speed. The biggest offenders were cards that repaired ships or prevented damage. For example we removed Patch It Up and replaced it with Backfire.

 

Made ships weaker – We reduced the hull strength (health) of a handful of ships slightly. Originally we felt ships were dying too fast so we gave the more hull strength.

Simpler ships – Every ship had a unique ability that required players to remember or read multiple times. We didn’t have many vanilla ships (no abilities) so we got rid of some abilities and made others less complicated. This lead to quicker decision making during combat.

A lot of these changes were incremental but the net result is a significantly shorter playtime. This month we will focus on theme and art direction while tying up loose ends and playtesting.

Space Victory is a card game I’ve been working on for the past few months with my friend Lanz Singbeil. It’s a spaceship combat game that can be played with 2-4 players. Players build spaceships, send them to planets, and engage in combat to claim planets for victory points. The combat system uses dice to determine hits and includes a damage system and other ways to change the odds. There are more systems but I’ll cover them in future posts. Currently we are in the design phase and are playtesting it with people whenever we have the chance. The game is a blast to play and is already nicely balanced.  There are a few systems we need to finalize and a handful of problems to address but the hard parts are done.

I plan to talk about the evolution of the design, the tools we’re using, and how we solved specific design problems in future posts. For now here’s a picture from the latest playtest. The cards have art found through Google image search. We have not figured out the art direction yet.

Here’s a quick video of a game I made over the weekend at the Full Indie game jam. It’s a co-op game where you shift enemies between universes since the only way to kill them is with the opposite elemental shot. I’m planning to fix some bugs and upload a web build that can be played locally on the same keyboard later this week.

The Beginning

Tiny World was an interesting theme since a few of my past game jam games fit the theme perfectly. I wanted to create something different so micro gravity and spherical worlds were out. I also bought an iPad a few days prior to the competition so I wanted to make a game that would work on both tablet and desktop. At this point I knew I was going to use Unity but I wasn’t sure if I would go 2D or 3D. After sketching a few ideas like giants playing soccer with planets, I thought about making a board game with relationships. It went through a few iterations. It  started out as a simple rule base combat version of Conway’s game of life game and ultimately arrived at a solitaire worker placement game inspired by Carcassonne. This was the final sketch before I started. It still had hex tiles and citizens had ‘hates’ too, which I quickly eliminated.

What went right

Using RagePixel – It allowed me to create all the art inside the Unity editor and not have to deal with exporting and importing. I could see exactly what they would look like in game and iterate over the design quickly.

Using Paper by 53 to brainstorm – I had just bought an iPad so I wanted to use it for brainstorming. I started by using Procreate but I quickly realized I needed a notebook solution instead of a single canvas. Working digitally is slightly slower than a pen and paper but I liked how quickly I could share my pages on Twitter and undo mistakes. You can achieve pretty good looking results in no time.

Balancing the game (sort of) – I created 7 different types of desires with parameters to tweak. At first I randomly assigned three desires to each citizen but then I realized it was too random. Certain combinations were more interesting than others. So I created citizen templates for those combinations and grouped them into 4 categories: easy, medium, hard and rare. Each category is assigned a probability with each template in the category having equal weighting. In total there are 13 templates and this made the game much more enjoyable.

The amazing feedback – I’m honestly surprised by how much positive feedback I got. I thought my game was decent but not as good as people are telling me it is. I’ve been encouraged by many people to polish it up and release a mobile version. It’s definitely something I’m considering.

What went wrong

Resolution independent font positioning – I ended up using Unity’s GUI system and wrote code to scale and position the text on the iPad. It didn’t work perfectly in the end but most people played the web version.

Not enough playtesting – It wasn’t until the end of the competition that I had the time to sit down and play my game for real. I quickly discovered problems I hadn’t thought about before. Now I understand why Notch plays his games so much during development.

Representing desires – The biggest challenge I faced was displaying each citizen’s desires visually. It’s quit easy to represent attributes of a citizen such as their name and colour, but there was no space left over to display their desires. Right now you hat to tap on each square to see them.

Results

I’m really happy I placed 41 in the innovation category. Other categories weren’t bad either. My desire as a game developer is to create innovative games but that doesn’t always work out.

Statistics

I used Playtomic to record some basic stats. The average playtime of my game is 9 minutes and at least 24 games have been completed out of a total of 273 plays. It’s inspiring to see which countries are playing my game.

I created a simultaneous turn-based local multiplayer game called Qua-tzar for Ludum Dare #21 using Unity.  The core gameplay is implemented but as with all my projects there was more I wanted to do. Try it out and let me know what you think.

I participated in the FullIndie 48 hour game jam and created a game called Bad Fairy! with Piper Jackson and Carson Morton. It is definitely rough around the edges but the essential experience of capturing fairies and breeding dragons is there. You can play the game by clicking on the screenshot. I will write up a postmortem at some point.

Today is the first time we had a chance to play with the finished game pieces since they were on display at the school board for a week. Overall I’m really impressed with what he was able to accomplish. We taught him the basics of graphic design principles and showed him how to use them to create card layouts but everything beyond that was his creativity at work. He made most of what you see in the picture below in a week, while doing homework and preparing for a math fair. Very impressive indeed! We were not able to finish everything in time so we improvised with Lego. Over the next few weeks we plan to work with him to refine a few systems that need a bit more work and to generate more game objects.

I was looking through my old game prototypes the other day and realized just how many of them could be expanded into full games. Most of the ideas I revisited are suitable for short-form downloadable games or what Andy Moore of Steambirds fame calls “marketable prototypes.” I clearly remember dismissing many of those prototypes as experiments and that nothing more would come out of them. I would like to share some observations I made while going through mine and hopefully encourage other designers to take another look at their shelved prototypes.

The best prototypes teach you something

When I’m coming up with an original game concept I almost always try to come up with something distinctly different or innovative from games I’ve played. It just has to be something interesting to me as a game designer but it is usually the hook for the game as well. These kind of prototypes always teach me something as a game designer and spark my interest when revisiting them.

Getting a new perspective

When designing games I get pretty caught up in the current design direction and it is sometimes difficult to see the game from an objective point of view. By shelving the game idea for enough time it becomes much easier to look at it objectively; just don’t forget to look at it again. If you decide to shelve the prototype, make sure you do not analyse it in detail until you have a more objective perspective. That analysis stays in your mind and may give you a false conclusion that there is nothing more you can do with it. What if you don’t want to wait that long? Show your game to your designer friends and get their perspective on it.

Start by focusing on what you liked the most

Rather than starting with the negatives, try to find that germ of an idea you worked so tirelessly to create in the first place. It may not work yet but you should at least be able to see the potential of it. Sometimes there is just one missing ingredient that would turn the idea from mediocre to great.

What bugged you the most?

Usually the difference between an okay prototype and one that has a lot of potential is fixing that one thing you couldn’t figure out. Sometimes this requires significantly changing the game but almost never does it require changing the thing you liked the most.