Why 30 games in 30 days

One afternoon Herman and I were talking about rapid prototyping, a hot topic in our local game development community, Make Games South Africa. We agreed this would be the best way to choose our next product to develop, but it could also help us improve our Unity plugin, Grids. By making a bunch of games, we could prototype new features, get some feedback and even discover and fix some bugs. We turned this into a challenge: we would make 30 games in 30 days to prove our promise that Grids helps you to make games fast. One game a day for the month of November.

During the month we at Gamelogic made games on rectangular, hexagonal, triangular, isometric, Cairo pentagon, rhombille and irregular grids. We made games wrapped onto spheres, discs and spirals. We made games on nested grids and infinite grids. We made puzzle games and arcade games, maze games and simulation games, 2D games and 3D games, runner games, board games and even a simulation of the Game of Life. We made games with zombies, ants, wildlife, paratroopers, monsters, amoebas, and snakes. We made games in space stations, on honey combs and on roller coasters (play all 30 games here). Some of these games even went on to be further developed and used for our clients at Plinq. 

Here is how we did it.

Game 2

How we got it done

Our team had three people: Jonathan Bailey (me!), Herman Tulleken, and Eduard Beukes, a programmer Herman and I got on board for this project.

When you make 30 games in 30 days, organisation, deadlines and communication is vital. We constructed a clear and precise pipeline:

We had 3 days in-between implementing and releasing each game. This gave us time to get the games playable, to write about them and to publish them. It also gave us a bit of leeway in case we fell behind. This way we could make up the time without failing to release a game each day.

We had Monday meetings with Ed to plan for the week and explain some of the tech and best practices to him. Each day we spent time outlining exactly what needed to be done and when. If we weren’t keeping to the schedule, something had to be cut. We also adjusted the scope as we went on. We started off with simpler games with a smaller scope. This allowed Ed to get used to the tech. Once development was going smoothly we increased the complexity and scope.

Our Grids plugin did a lot of the work for us; it has a lot of functionality built in. The tool provides an abstraction to how grids work so that you can concentrate on implementing the game instead of the grid. This allowed us to get unique games out the door fast (that’s our sales pitch out the way!).

Game 5

Game 6

How we struggled

When you make 30 games with an overlapping pipeline, it becomes very difficult to keep track of everything. Here is a watsapp conversation between Herman and me late one night.  

This happened in the first week! By the end of the campaign we had temporarily lost four of our games and had by mistake deleted one of them. We managed to locate and retrieve everything for our video, but this shows how difficult it is to manage 30 overlapping projects, even if you think you are well organised.

About a third of the way into the project we decided to increase the scope and to use a new type of grid (a grid wrapped around a disc). This came at a bad time and for the first time the project was at risk. The new tech was used in Game 11 and took a while to implement, but Game 9 (a wildlife simulation) took longer than expected to balance and Game 10 had a tricky bug. In the space of a few problematic games we lost half of our buffer.  We immediately reduced the scope. We made the buffer up and once we were on top of things, we increased the scope again, developed more new tech and moved onto 3D.

It became difficult to think of cool game ideas by the end of the month. Beside from being a bit fried, physically and creatively, we wanted to end with a bang. This meant making more unique games to show off Grids, which after 25 odd games wasn’t so easy.

We also made a game that we didn’t even publish. It was made around half way but we weren’t happy with it yet. We delayed its release but it became more and more difficult to include seeing as though we were upping our game as we went, and by the time we had 3 games left, we decided it wasn’t good enough to include.

Lastly, Sunday development and publishing wasn’t as much fun as you would think. Friday night was worse!

Game 11

Game 16

What we learnt

During the project we learnt a lot.

The importance of having a flexible plan and adjusting scope as necessary. We had a list of 30 game ideas when we started but cut many of them due to their scope. We got new ideas from user questions and user discussions. Development of one game led to new ideas and tech for others. We adjusted the scope of our games so that were able to complete the challenge but we also increaed it at times to show off the flexibility of grids by developing more complex and unique games.

The importance of communication. We had to communicate as soon as there was trouble, but only if necessary. Unnecessary communication can be very costly when you only have one day to get the job done. Ideas were not discussed; things were not debated. You made a decision and moved to implementation.

The importance of prioritization and not getting stuck on problems. If something was too finicky, buggy, or we couldn't figure it out, we found another way, cut it, or simplified it. It was important to not fiddle, but move on.

Implementation patterns. For example, consistent ways to animate things between cells in the grid, handle game end, and handle states.

Ways to generate levels procedurally. Especially techniques that use symmetry together with randomness to have variety that looks designed.

The importance of having a good base of game controls to work from. We did not have one, and it shows.

The importance of animation to communicate (as opposed to snapping). As the project went on, we animated more things, and the games improved.

What our library lacks. One of the most useful things we learnt is all the places where our library could do even more for the user. For example, we realised it's still tricky to work with triangular grids; we found many algortihms we could add to make life easier.

Game 24

Game 26

How we benefited

The benefits of the campaign went beyond improving Grids and proving our promise.

From the day we launched the campaign our web traffic shot up and our sales more than doubled. We got a lot of feedback from the local and international community, created a huge amount of content and developed new tech and new grids.

The project was also a showcase of what can be done using grids. We like to think that we got people thinking about grids differently by using novel grids and using grids in various ways to make a bunch of different games with different mechanics.

We had tried more traditional ways of marketing Grids, but this campaign blew everything else out the water. We tried something slightly crazy.  More importantly we finished it. The question is now… what's next?

We can’t just go back to marketing Grids the traditional way. Besides from being boring, it hasn’t been effective. We’re looking at new challenges, new out of the box ideas, and more rapid prototyping. We’ve got a taste for crazy and we want more.

Play all 30 games here

Game 28

Game 30