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!