Game a Week 3

Climb. – 14 September 2014

A puzzle platformer made in Unity.

My Goal

Make a game that was more mechanically focused that my previous games, something with a bit more gameplay depth.

What went right:

Using unity for this sort of thing is amazing. I manged to build the basic building blocks of the game really quickly one night, so when I came back to it over the weekend I could focus a little more on levels/ progression.

What went wrong:

The gameplay still ended up being pretty shallow. My level design/ puzzle building skills are pretty rubbish. I realized too late that the core mechanics of the movement etc… didn’t lend themselves well to interesting levels that involve a bit of thought. I might try making a full on puzzle game soon to see if I’m capable of making something that is difficult to play/solve, as everything I make seems to end up stupidly easy!

Also, I ran out of time to do a final visuals improvement pass. Most notably I didn’t get round to swapping out the default unity 3d text for something that wasn’t pixelated.

Edit: I went back to this to fix the pixelated text and add more text passages for the Newgrounds version.

Game a Week 2

Nothing – 17 August 2014


An atmospheric browser game about self preservation.

My Goal

Finish something for the second week in a row! I also wanted to make something atmospheric and learn a bit more javascript.

What went right:

The music and graphic style (the ascii effect wasn’t mine) work nicely together. I think the gameplay speeds up and gets harder at the right speed together with the music and cluttering of the screen.

What went wrong:

I spent too little time building it into a game after getting the initial look. The collision detection is very dodgy (if its a problem try resizing the screen smaller) and I didn’t have enough time left to fix it with a proper solution. I also wanted more interaction with the projectiles to make the gameplay more interesting. I’ll try to put more emphasis on gameplay next time.

Game a Week 1

0822 – 10 August 2014


A twine game about a morning commute.

My Goal

Make a game in a week for the first time. I decided to start with something that should be simple and completely new to me.

What went right:

I managed to find a writing voice that I think fits the game well. I’ve had so little writing practice that I’m pleased I managed to finish this and make it’s voice seem fairly consistent. On a whole I think the components work well together and manage to represent the situation nicely, especially the music.

What went wrong:

I initially found myself using twine in a “block of text followed by two choices” way. This lead to a lot of branching early in the game and, in my opinion, is one of the more boring ways to use twine. I managed to overcome this as I progressed but quickly found myself heading the in the opposite direction: making the story too linear. I also fell into the trap of making some of the branches get randomly selected for you. This meant that, despite me knowing otherwise, some parts feel more linear than they are. I think this causes some of the feeling of exploration and agency that is possible with twine games to be lost.


In the last update we’d got to the point of integrating the front end and back end. Well, the world kept spinning and the work kept rolling. So here is our progress from that point on.

 Screenshot_2014-06-10-17-55-07        Screenshot_2014-06-10-17-56-15(2)        Screenshot_2014-06-10-17-57-06

Initially we focused on login and group management as they are core to the app’s functionality; Without users and groups, events and ideas would not be possible. To get this done we created a group creation activity and a group select activity. The latter asks our server for all the groups you exist in, displays them and allows you to pick one. It can be seen in the second picture above (excuse the “hilarious” test names). These options, as well as being accessible on first login, populate the left hand slide out menu, as can be seen in the third image.

Screenshot_2014-06-10-17-56-46        Screenshot_2014-06-10-17-57-00        Screenshot_2014-06-10-18-09-29

Next up: implementing ideas and events. When I got to implementing events and ideas the back end system was mostly in place. This provided me with some much needed space for flexibility and experimentation in the front end. We had previously decided our core view would be a map screen so I began by looking at adding markers to the map. This proved to be very easy thanks to the Google Maps API as mentioned in the last update. However, I spent quite a while working out how to integrate the logic required for the many parts of the map screen (keeping track of events and ideas, the slide out menu, and the slide up context sensitive panel) without the code getting messy. Luckily, with a little trial and error, I managed to work out an elegant solution that uses fragments to manage the logic and contents of each view while the activity deals with movement of the panels.

The final interesting part of progress is the “slide up context sensitive panel” that can be seen in the last three images. Basically, we wanted uncluttered way of displaying information about selected items on the map screen. The solution to this was obvious:

copy someone better than you.

This proved to be a good solution for two reasons:

  • It looks good and provides the right functionality.
  • People know what to expect.

When you see a Google Map screen you expect it to behave the same way as the Google Maps app, right? So we implemented a context sensitive panel that slides up when something interesting is selected, displaying information about it, like in Google Maps. It can be slid up to give more information about the selection and unveil possible interactions with it. Though, as you can probably tell from the sixth image, the view for this information has yet to be tidied up properly!

API Hell

To tackle the task of building a fully featured android app, as well as a full web server and database stack, we started by splitting our team into two subgroups. I say subgroups, but essentially one of us wanted to toil away on the web server/database setup while the rest of us jumped blindly into the Android, Facebook and Google APIs. Here are the results of three and a bit days of work, all screenshots are taken from a single install of the app in it’s current state (all icons are placeholders an Dave Thing is a test facebook user):

Login Screen        Map Screen        Slide Out Menu

Ignoring all the pain from setting up the Android development environment and library dependencies, the first thing we noticed was two fold:

  • Firstly, by following one of the many tutorials online it is relatively easy to get something working, be it tutorial on setting up a slide out menu from a random blog or a Facebook tutorial for setting up logins.
  • Secondly, actually understanding the code enough to tidy it up and combine elements together is not so easy.

All tutorials seem to use different best practices in regard to Fragments and Activities (android jargon) and never comment on how to abstract things into reusable chunks. They often work from a blank app and implement the tutorial feature as the sole element of the main activity whilst never explaining how they can be used as elements of a larger app. However, we are slowly coming to terms with how these elements can be combined by gradually learning more about the functionality of the components and through the patterns section of the google developer site, as can be seen in the above screenshots.

Another large chunk of the work so far has been spent on learning to use other APIs. Using Facebook has been pretty fiddly with lots of forum hunting, avoiding outdated web resources and bureaucracy through their developer site. The biggest hitch so far was finding out that a recent API update allows you to only see friends who have also logged in with the app, thus making testing pretty tricky (though we eventually worked out how to use test users). Google maps, on the other hand, has been pretty straight forward. With a few lines of code and xml we were able to display a full map view centered on you location. The ability to add markers to the map and other things like camera animation also look equally intuitive, which should be useful going forward.

In At The Deep End

On Monday I began work on a new university project. Our task, as a team of four, is to build a multi-user application that utilises a database for persistent storage and HTTP for client server communication. Essentially “build a website or an app” with top marks for dynamic page updates.

As is tradition for our group, we chose the most overly ambitious option possible:

An android app that interfaces with both the Facebook and Google maps APIs whilst simultaneously communicating with our RESTful java powered web server.

Bearing in mind:

  • None of us have even glanced at the Android SDK let alone written a slick, well designed, multi-screen android app that communicates with a web server.
  • None of us have ever set up a web server using our chosen web technologies of Apache, Java, Tomcat, MongoDB etc…
  • We have four weeks to complete the task it.

Our chosen goal is to build a last minute event planning app for small social groups.

(CODENAME: Instaplan)

In more detail, it’s an app in which you create small friendship groups based on locality and interests, using your facebook account. Within these groups, members can add event suggestions linked to a location e.g. “We should go see this exhibition at the Tate”, “This pub says it has the best ale in the country, we should try it out!” etc… At any time, anyone in the group can select a suggested event from the list and make it happen: by simply selecting a time for the event (limited to a week in advance). All members of the group then get a notification of the event and can hit a button saying they are going!

The intention, graphically, is to have the main focus of the app as a map screen with a toggleable overlay of planned vs possible events. Auxiliary screens will then be used for event viewing/creation and group management.

Look out for more updates (most likely on my battle with the android sdk) and wish us luck. We’re going to need it!


It’s been a busy 4 months. Here’s how it went down:

  1. In February I turned a bizarre night out into a video game.
  2. On one week in March I went to my first London Indies south, in Clapham, and ended up spending that weekend at the IGCCGD conference.
  3. January through March I helped build an operating system as part of my university course.
  4. April was spent on summer internship interviews, popping home for chocolate eggs, one long night on three night buses to get back from the O2 and the occasional hour of revision.
  5. And finally, early May has been exam time (which is nearly, nearly over).

This also included the occasional week with no motivation to do anything but heh… you can’t have everything.

So what does all this mean?

What I See

Firstly, I’ve got a new game up. It’s a thinky, feely, nothing really happens type game based on real life that you can play here. I plan to do a blog post about it at some point (about the idea, things learnt etc…) but I wasn’t really in the mood to talk about it untill now.

Secondly, I’m going to be working at EA over the summer! Which is awesome! It does mean a busy summer but I’m looking forward to the free evenings and weekends that 9-5 brings.

Thirdly, exams are (nearly) over so I should  have more time now. I’ll be working on a web app project for uni for the next 6/7 weeks and plan to interleave work on that and Till The End (which I’ve finally got back into working on again). Hopefully you should see updates on here about both in the near future.

So hold on tight as I promise I’ll get more content up over the coming months!

The Important Things

Over the Christmas break I came across this video from Vlambeer titled “The Art Of Screen Shake” (one of a few titles). I’d come across the playable part of it before and also seen this video “Juice it or lose it”, by Martin Jonasson & Petri Purho, a while ago. Both of which I recommend having a look at. However, it was after watching the Vlambeer video, as rubbish Christmas t.v. blared in the background, that I had a sudden urge to start working on Till The End again.

Someone's got to die

The first thing I set to work adding was directly due the Vlambeer video: a more juicy camera. Previously, when you were playing in a new soldier, the camera would track the player with the soldier directly in the center. I changed it so that the camera now tracks towards a point between your cursor and the soldier, at a speed proportional to the distance the camera is from that point. This has two main benefits:

  • It means that the player can see more in the direction they are interested in. This allows the camera to be more zoomed in but still give for a decent view distance, when needed, which helps with the “limited information” feel of the soldiers.
  • The camera moves more smoothly and fluidly which improves that dreaded term: the “feel” of the playing soldier sections.

After that I decided to focus on getting all the core mechanics I’ve decided on in there, at least in some form. So, as it was first on the list, that meant adding grenades!

grenade1                   grenade2

The hardest part of adding these was getting the grenades to not explode through walls. I used the same system as I did for the lights and as I was adding this I finally got round to improving how raycasting with the walls works, which has needed doing for ages.

I also added a better system for managing levels, a level select screen, spawn areas in levels and the ability to choose where to spawn within those areas. This should all fit in nicely with the bones of an XML level saving system I already started on a while back.

Next up to add is capturable spawn points, to allow for more progression within levels, and the ability to spawn at any given time, as long as one of your soldiers has survived until that point. Then I will need to take a step back and make sure all those mechanics work well together and still work with all the time stuff (keeping it deterministic is hard when more is added). I think the hardest task will be too keep the time stuff forgiving enough to still be fun; at the moment it’s too easy to screw up everything. I hope adding these things will allow for constant progression in time and space so you won’t be treading on your own feet, unless it is tactically beneficial.

The Game Is Life

If you’ve read my last post you will know I’ve been working on using my Launchpad as a games controller. This post is going to be about how I’ve started creating a game to go with it. I’m using Unity and an xbox controller for the second player.

As soon as I’d got a character walking around a world that was changing due to interactions with the Launchpad I knew that should be the focus of the game. With two different game controllers interacting in different ways it became obvious too that the game should be a local two player experience. It terms of what that experience would be, I really like the idea that, while playing the same game, each player is getting a completely different experience. This is possible with the Launchpad as the Launchpad player can have a completely self contained experience of input and feedback based around the pads and lights of the Launchpad. While the controller player has a different input and feedback loop using the controller and screen. Paraphrased, I like to think of it as one person playing a board game while the other plays a video game.

The Game Is Lifelaunchpad

But what is the game actually like? Well as usual, It simply grew out of an iterative process of changing things and seeing what works. As the controller player it was fun to try and stay on top of the blocks before they vanished, trying to jump from block to block without falling off. This lead to creating a sea like world, as seen above. The idea then is for the controller player to stay out of the water. At this point the game had no real objective for either player, other than survive for the controller player and get them in the water for the Launchpad player, so the first thing was too add was an objective for both. I thought the best and simplest goal was for the controller player to get from one corner of the grid to the other, while the other player tries to stop them. Thus turning the game into a head to head situation.

There were now two problems to focus on. One, increasing the engagement of the controller player. Two, deciding on the mechanics the Launchpad player has. Until now the blocks could either be placed or removed with a simple toggle on the Launchpad or, if the option was selected, by following the rules of the Game Of Life.

Both of these problems could be tackled in the same way. A system of rules deciding where blocks could be placed and removed was needed. The controller player can then place blocks down, if allowed by the chosen rules, to advance towards the goal and the Launchpad player can place and delete blocks to disrupt him. Deciding on these rules, however, has been tricky as each change affects the balance of the game.

I want the rules to be simple enough so you can start playing without thinking too hard but also have enough depth so that gameplay strategies can emerge. I’m also undecided as to whether these rules should be the same for both players. For now I’ve decided on the rules that blocks can be placed next to any existing block, by either player, but can only be deleted, by the Launchpad player, if they are in the middle of two other blocks or have no adjacent blocks. This gives the nice feature that the Launchpad player must add blocks in order to delete others which makes things more interesting for the controller player and opens up options.

Anyway, that’s where I’m at now. The next step is to get some people playing it to see what works and what doesn’t so I can tweak and improve the balance, gameplay speed, information feedback etc… Maybe at some point I should take it to London Indies!

Pushing Buttons

On the 2nd December I went to my first London Indies pub night. It was great fun! The people were great and there were some great games to demo.

One such demo, that I got a go with, was Alan Zucconi’s, @AlanZucconi, homemade game controller. This got me thinking a little about alternative input for video games and after seeing my Launchpad knocking around my room I had a lightbulb moment: using all those buttons in a video game could be pretty fun!

And thus The Game Is Life was born, sort of. But first…

Game Of Life

I needed to find a way to easily send and receive midi messages to and from the Launchpad. I quickly found midi-dot-net, a C#/.NET library for MIDI programming, that could be easily used within Unity. After reading up on the API and on how the launchpad treats MIDI signals I managed to get to a point where you could press any pad to toggle its light on or off.

From there I set to work on another script in Unity to see what could be done with this. The first thing that sprung to mind was to create an interactive version of The Game Of Life, the classic cellular automata. It would make a good starting point/showcase of what could be done with this. See the picture above.

The next step was to get something working on the video game side of things, to get some visual feedback on the screen. Thanks to the ease of Unity this was pretty straight foward. I threw in a first person camera, a floor and a script that added and removed blocks in the game world as the cells lived or died in the Game of Life.

Now the only task left was to come up with a game!