Victory!

Damn! So would have thought, we actually won OUYA create!  I had expected and hoped we'd do well, and perhaps win one of the subcategories, but considering how we felt after finishing the game, I didn't think we'd win (my personal pick, from only seeing the trailers, was Sky Arena). I'd like to take this opportunity to thank the organisers and judges.

It's kind of a weird position to be in, the day after hand-in we were quite bleak and we had a discussion on what we'd done wrong and what we'd do differently in the future to prevent making these mistakes again.  I think a lot of the negative sentiments were amplified due to the jam not ending well for us, with me breaking our repository in the last hours, and some bugs and flow issues not getting sorted out until the last minute.  In the post-mortem I talk a lot about having too much ambition for our game but I guess it paid off.  Perhaps a side effect of having high ambitions and standards are never quite being happy with your work?

Looking back at the game now, however, I do think it is really strong and impressive for 2 weeks' work.  Although it doesn't quite match up to what we'd had in mind at the start, the prototype does demonstrate the potential of our concept quite well, and it is quite fun.  We have some time now to fix and improve the things that had bothered us and to get the game to where we want it to be. Whether we'll actually finish it and release it as a paid title is hard to say, though.  All things considered I still consider Broforce to be the better game, and it is closer to release than Murder Island is, so we'll continue working on that for the time being.  I do feel we owe it to the Ouya and organisers to at least finish what we'd wanted to do for the prototype, and to have a rounded, more stable version that we can put online would be nice.

Post Mortem: Ore Chasm

I've been meaning to do a post mortem on our Ludum Dare game, Ore Chasm, for a while now, and I thought I might as well do it now before it completely fades from memory.

Background

We are currently working on a game called BroForce for which we need to, at some point, implement networked multiplayer.  No one in our team has any experience in implementing multiplayer, so we did a game called Deathsmashers in a for-fun private jam.  That turned out pretty well, but with it being a co-op FPS I felt that we didn't really answer many of the questions that we needed answering.  It is usually a good idea to have some sort of plan for what you will be doing in a jam, and I requested that we do a fast paced platformer with networking and lots of terrain destruction.

Design

Our lead designer came up with the idea of doing a mining game in the vein (heh) of MotherLoad.  This suited what I wanted to try technically very well, and could be worked to incorporate the theme of 'You are the villain' pretty easily - everybody loves mining conglomerates, right?  We didn't quite manage to foster the feeling that you are destroying the entire planet as well as we could have, though.

The game's design is focused around a very simple but effective loop: go down, get ore, try to make it back up, upgrade your gear. Keeping the loop focused and simple really worked for us and it turned out to be highly compelling.  Subtle changes in the game world as you get deeper, along with one or two things to discover also added a lot to the feeling of progression (besides being able to smash terrain near the surface with the more powerful late game lasers).  

The idea for the mining laser as implemented in the game was partly inspired by No Time To Explain's recoil-movement mechanic and works really well in making the weapon feel powerful.  I'd initially wanted to make the starting laser much weaker, with limited range and movement capabilities - but wisely we opted for the design as is.  Having the initial laser nerfed would have made it less effective at teaching the game's mechanics, besides unnecessarily limiting the player.

Some things we had planned did not make it in: We had planned to have creatures underground as you get deeper (although there may or may not be a mysterious and majestic sandworm in certain builds of the game).  A greater variety of weapons and some sort of metagame would also have helped a lot with replayability of the game. Upgrades and scaling are also hard to test when you don't have a lot of time and so the progression and cost of items are not as balanced as they could be.  Still, I think we did a good job of balancing in the limited time we had to make the game.

Tech

As usual we used the Unity engine. One of the technical challenges we faced was managing such a large game world with so many game objects - the map is 350x1024 blocks large, with each block being a game object in itself. We handled this by only spawning onscreen blocks, and despawning those that go offscreen and asset pooling them. We used a "lazy mans's asset pooling" system that I wrote earlier which worked very easily and painlessly for us.

We use a standard perlin noise map to generate the map - 4 layers of perlin noise combined with depth determine a block's state.  The master client determines a random seed and keeps track of all damaged/destroyed blocks. When a client joins, the seed is sent and the client can generate the exact same map. Afterwards a list of all dirty blocks' state is sent.

Networking

We used the Photon library and cloud hosting for the multiplayer portion of the game.  Although I sometimes like to complain about Photon a lot, it is a brilliant library and service and I would recommend it to anyone looking for a quick-and-easy way to get their games networked and hosted on a cloud.

One thing I learnt about networking is that it doesn't necessarily need to be as exact as I'd expected: Player and beam locations are often not the same on different clients, but damage is determined locally and then distributed.  Ore isn't synchronised at all! When a block is destroyed, its ore drop is determined locally. It is theoretically possible (but hard) for two players to pick up the same piece of ore.  Fortunately the nature of the game is quite suited to this relatively low level of synchronisation.

Visuals

We went for a low-res pixel art style, which (with a talented artist) looks good and works well in the context of a jam.  The surface world look was achieved by having some parallax elements on a seperate camera with bloom. Lots of camera shake and a distortion/wobble effects on explosions help with the juiciness of the game and really adds to the feel.

Closing Thoughts

This was quite a successful jam for us, considering that we won 1st place overall in the jam :). Besides that, we had a lot of fun and learnt a fair amount about networking.  Unfortunately not all the lessons are highly applicable to Broforce, where the players are far more dependent on each other than in Ore Chasm.  It did take a lot of hard work, and we had 3 programmers - doing a networked game isn't really a good idea for a jam unless you have good reason to do so.

I'm trying to develop my blog and skills as a writer - if you have any questions or feel there's some important aspect of the game I neglected - please leave a comment!

Post Mortem

So! The jam finished about a week ago, which has given some time for the dust to settle and for us to collect our thoughts.  This was a really tough jam, a lot of things went wrong and we didn't quite get where we wanted to with the game, but we still had a blast and made a prototype which I hope shows a lot of promise.

Before I start I should say that all opinions are my own and do not necessarily reflect the views of the rest of our team!

What Went Wrong

In short... a lot!

Ambition

We were ridiculously ambitious for our game. Shortly before this jam we'd done really well in Ludum Dare, winning the "Overall" category in the jam with our game Ore Chasm. 12 days seem like a really long time, we have a good idea for how much we can get done in a weekend's time for a typical jam timespan but the longer time threw us out a bit and we set our sights too high.  Doing a 3D game is almost always a terrible idea for a jam, and we wanted a 3D game with different mechanics per level, a strong narrative, unlocks and a metagame, dinosaurs and time travel! Which lead to the next issue...

Spreading ourselves too thin

Working on so many different scenes and mechanics meant we never could give enough attention to any one aspect.  In retrospect we should have cut down on story elements, and probably done either only the driving sections or shooting sections, and fleshed out/polished either.  We spent a lot of time on content that didn't make it into the game at all.  It is common jam advice to work bottom up - make something small and improve on it - but we worked from with a top-down methodology.

The Ouya/Dev environment

As is to be expected from a product in such an early phase of development, we had a number of issues with the ouya itself.  The first and most significant being that our Ouya dev kit didn't work out of the box at all! We were lucky to know a nearby developer who also had an Ouya that we could use to test our game on. Still, this meant we had far less time to test our game on-device than optimal.  Building the game for Ouya and deploying also took up a fair amount of time - compounded by the fact that I had never built a game for the Android environment.  The support given by Ouya staff and resources available on their forums were great though, and we managed without too many troubles.

We also overestimated the power of the device, especially on the video side.  Luckily the visual style of our game suits it being run in ridiculously low res (I think in the end we settled for 270p), but even that in addition to a fair amount of optimisation was not enough to stop the framerate from chugging at certain parts of our game.  Another reason we should have made a 2D game!

Finally, the Ouya controller is kind of... bad. The ouya devs have since responded and are improving the controls so I trust this won't be an issue on launch - but the large input delay and inaccurate axis readings made that our game doesn't play nearly as nice with an ouya controller as it does with an Xbox controller.  In the end we opted for a deadzone of about 0.4! We tried to compensate for the problems by adding in a lot of autoaim, which helps, but does not solve the problem altogether.  By carefully watching the youtube videos of other entries it seems evident that other devs were facing the same issues. Again, I don't think these are massive problems for a product in its infancy and the ouya devs are aware so I'm sure these issues will be solved before launch.

Playtesting

As a result of the previously mentioned problems, we did not spend nearly enough time actually just playing our game.  The controls aren't as intuitive as they should be, the difficulty is a bit haphazard and there are a fair number of bugs present.  

I'm stupid

Yep, I'm stupid.  Only a few hours before submission, I accidentally our whole Mercurial repository by committing stuff with the LargeFiles extension, which bitbucket does not support. This meant that the frantic bugfixing which always happens a few hours before submission in a jam could only be done on one machine. If I had more time I could probably have fixed my repo, or worked out a different setup for our mercurial, but there was no time.

What went right

Concept

I think our concept for the game - having lots of different, semi-repeating scenes getting weirder and more difficult a-la Amazing Wagon Adventure is really strong and if fully realised would have made for a really fun, whacky, replayable and unique experience, while allowing us to do pretty much what we want gameplay wise.  Doing something more narrative driven was also a nice change for us, and we learnt some valuable lessons there.

Aesthetics

As per usual our (one man) art team did a kickass job and produced more content than we could even use.  I really like the visual style of the game. On top of that we had some cool terrain tech that allows us to have rippling terrain and marks on ground, making the game quite 'juicy'.

Mood

Even though it does not come across nearly as strongly as I hoped, I still think we somewhat succeeded at establishing the mood we intended - of survivors on an island encountering increasingly weird scenarios.  We did have a whole story planned out - which would have explained what exactly is going on on the island and tied everything together - but we didn't have time to implement it all.  I think the story screen also works quite well - although the writing itself didn't have time to be iterated upon, and I'm not a particularly good writer.

Gameplay

Although again not nearly where we wanted it to be - I think the game sections are quite fun.  Shooting could certainly have been improved by a lot, but there are a lot of different ways of playing the game, and killing mooks by throwing guns at them is quite fun.

Vehicle section

The vehicle section is probably the strongest part of the game - everybody seems to have liked our laser-breathing T-Rex. It's also a lot of fun to play with a friend, and can be quite chaotic (in a good way!).

Final Thoughts

So, our jam didn't go nearly as well as I'd hoped, and I'm not quite sure of our chances of winning. But still think we have an outside chance, and I think at least our trailer is one of the better ones.  Despite this we learnt a lot in this jam and still had a good time, and we might take the game further if we get a good response.  Doing an extended jam (with prizes!) was a great change and I hope there are more of these in the future - we'd definitely like to compete again. It was great being part of something new and exciting and I'm looking forward to the future of the Ouya.  

Thanks for reading!