Chicxulub was our 6th Ludum Dare at Literal Games. If you haven't played it, it's a "bullet hell" "dodge 'em up" with space dinosaurs!

We had a great time this LD, even with a few changes from normal! After every LD I try to write a post mortem for a couple of reasons: I love reading other people's, so this is my way of giving back; and it's a really nice experience to be able to go back and reflect on previous LDs after the fact.

In general, I always think LD is a time to try new ideas and push yourself. In the past, we’ve done this by trying to take the game design in innovative ways, rather than just sticking to established genres. However, for a while, I’ve wanted to see if I could put my game making skills to the test and make something that really feels like a tight, well made little game. How did we fare? Well, I think that’s up to you to decide.

Pre Jam

Unfortunately, our usual artist was busy for this LD (the first time ever!). Luckily, my friends are multi-talented, and a team member who usually does a bit of everything stepped up to do all the art. I'm always a fan of LD for pushing us out of our comfort zones and making us do things we might not otherwise, and I think this is a great example of this.

pico8

We've previously used Flash (RIP) and Unity as our game engines. This time, we decided to go with pico8. pico8 is "a fantasy console for making, sharing and playing tiny games", and it's a hell of a lot of fun. I've tinkered with it a few times and made a few prototypes, and always wanted to do more with it. Being also aware that art would be a challenge for us, we thought that pico8's severe limitations and restrictions on sprites/art (16 colours, 8x8 sprites, 128x128 pixels in total for art) would help us focus.

It turns out we were right! pico8 really helped us capture a simple art style we were happy with, and the restrictions also pushed us towards keeping things simple, which I always think helps in a game jam. I'll definitely be revisiting pico8 in future jams, and encourage you to take a look for yourself.

 Start time/Brainstorming

Being located in the UK means the theme is usually announced at 2/3am. In the past we've stayed up to do an hour of brainstorming before bed. This time though, the theme was released at 11pm - a much more socially acceptable time! This meant brainstorming was longer and a lot less sleepy.

We were a little less than enthused with the theme, but jumped into brainstorming. We tend to throw everything at a page and see what sticks. It's fairly usual for us to not have a concrete idea before bed, but this time something crystallised fairly quickly! One of our first ideas was "orbits", and after a few minutes, someone suggested the idea of you being an asteroid that needs to crash into a planet. But what would be stopping you? The answer seemed obvious: dinosaurs in spaceships. Our artist even drew a mockup of the first dinosaur that evening, and we were all on board.

Getting the basics down

On Saturday morning, we got to work on the basics. Given we had a pretty solid idea, everyone knew what they were doing - our artist started on the asteroid and some dinosaurs, our musician started getting to grips with pico8's music capabilities, and I got started on the core gameplay. pico8 made this a breeze, and within a couple of hours I had an asteroid and a shooting dinosaur. Our artist very quickly found a style and was pumping out content.

Focus

We spent some of Saturday thinking and talking about what would make the game good. Upon reflection, I think there were four main areas that we focused on. They can be boiled down like so: - Interesting enemy waves and formations - Enemy variation - Game progression/difficulty - Polish

Interesting enemy waves and formations

I don't think any of us in the team had really played many "traditional" bullet hells/shoot 'em ups. However, from a few youtube videos and vague recollections, I was fairly sure that the way enemies moved and how they arranged themselves on screen was an important part of the gameplay. Because of this, I knew I wanted a flexible, easy way to define the enemy movement/waves.

Here again, I think the limitations of pico8 restricted us to the basics, which led to a fairly nice solution. There are only four ways to store data in pico8:

• code
• sprites
• map
• sfx/music

I briefly considered using sprites or the map to somehow "draw" the movement patterns, but any way I thought to do that seemed restrictive in some way. Sfx/music seemed dumb - so code/text was the only real option! Whilst doing some morning chores, I came up with a way to represent movement patterns as strings, which would be easy to create and edit as the jam went on.

Below is an example of one of the movement patterns, as well as how it looks in our debug mode. See if you can work out what it means!

The waves/orbits of the game were defined in similar ways - each wave has a list of the enemies that should spawn, when they should spawn, and what movement pattern they should do.

One thing that I knew was important was the ability to repeatedly tinker and play the waves as I was creating them. From experience, both in Ludum Dare and in my work as a software engineer, I know that making it as easy and seamless as possible to quickly iterate is imperative for a good experience when creating content. To make this possible, I spent some time adding a feature to start the game at any wave, and at any point throughout the wave. This meant I didn't have to sit through 40-50 seconds of each wave repeatedly just to change a couple of bits at the end of the wave. I think this is one of the things I got really right in this LD - make it easy to view, edit and play with your content during development!

Enemy Variation

In the game currently, there are 4 distinct enemy classes, which each have a regular and large variation. The classes have different attack styles, with the larger versions having a more powerful style of attack.

Caption: Never speak to me or my son ever again

Even though the game is short (less than 10 minutes!), I think the enemy variety really helps! Meeting new enemy types and learning their mechanics makes sure the game doesn't get stale. On the flip side though, introducing so many different enemies and mechanics could get confusing and frustrating. One part of solving this was ensuring that enemies are visibly different, and follow established patterns - mainly that the larger dinosaur of the same colour was a more difficult version of the smaller dino.

The cherry on top of the enemy variation, is, of course, the bosses. We have two bosses in the game, which are supposed to be real gauntlets. The bosses themselves don't have any unique abilities, but are deployed in a more difficult way. They were a lot of work, but I think they add a lot - not just in terms of pacing (which I'll get to) - but also in terms of increasing enemy variation and increasing the amount of cool content.

Game progression/difficulty

I think game balance is the hardest thing to get right in Ludum Dare. You can spend heaps of time on great features, interesting levels, and polish - but if the game isn’t balanced right, it can very quickly lead to frustration or boredom. There are types of games where it’s less important, which we’ve tended towards in a couple of our previous entries. This time, I knew we needed to face it head on. I think we made some interesting decisions, but in the end I’m actually very happy with the balance and how the game plays. I think there are 3 main reasons why.

Enemy introductions

I’ll be honest - a lot of my game design thoughts and opinions stem from Mark Brown’s incredible channel, Game Maker’s Toolkit. One particular video (youtu.be/dBmIkEvEBtA) touches on how Mario introduces new concepts. In essence, there are four steps: 1) introduce the concept in a safe space, 2) establish the concept further, 3) twist the mechanic slightly, 4) show off/conclusion. I don’t think we followed these four steps explicitly, but each of the first four waves follows them loosely to introduce a new dinosaur type.

Wave 3 (see gif below), deals with the red dinosaurs that shoot homing bullets. First, only two dinosaurs fly onto screen, giving you a chance to understand their attacks and focus on how the homing bullets move. To establish the concept further, some of the previous types of dinosaurs are brought in to ramp up the challenge a bit. To twist the mechanic, the large variant of the red dinosaur appears - who shoots four homing shots at once! I think following this formula really helped the levels flow and helped the player not get overwhelmed or stressed by the different enemies.

Failure state/scoring

One of the things we discussed as a team a lot was how the game should be balanced around death/game overs. Classically (as far as I know), bullet hells/shoot 'em ups are usually designed around mastering the levels and enemy/bullet patterns, and therefore can require a lot of repetition and failure. This was not the design I was looking for in a LD game. I wanted to provide an enjoyable experience that everyone could complete - whilst still providing a challenging experience.

We went through a number of iterations and ideas. To start, the asteroid's size was a percentage, where zero would have meant death: however, it was hard to balance and with a minimum of zero and a maximum of a hundred, it was hard to make getting hit feel impactful.

We considered having two "scores" - one for size, which would increase when you collected debris; and one for integrity, which would decrease when you got hit and cause a game over at zero. It would have given us a lot of options for balancing, but in the end, we thought it was too confusing for a 10 minute experience.

In the end, we settled on a simple idea: a single "score" (the mass of the asteroid), which increases when you pick up debris and decreases when you get hit. The important part is that it starts at 10,000kg - and with each bullet only removing 55kg, there was no chance of reaching zero and thus a "game over" state. It is a simple score based system, disguised with a bit of set dressing.

The one flaw with this system was that it was hard to know what a "good" score was, or what you should be aiming for. To help counter that, we added a "rating" at the end of the game - and for a bit of fun, it's displayed as a percentage of how many of the dinosaurs you wiped out. I think this is one of the best parts of the game - lots of reviewers have left their score in the comments, along with some thoughts on how they did or how it made them feel.

Some early playtesters of the game and our first few reviews didn't seem quite clear on the scoring until the end of the game - we had a couple of comments that the game seemed a bit too easy if you could never die. I think some people may have an innate belief that shoot 'em ups are difficult and should have unforgiving game overs. Being more upfront that this was an arcadey, high score type game could have helped that - and indeed, adding a line to the description of the game to that effect seems to have primed people not to expect any failure and that they were playing for score.

Difficulty curve

I remember hearing once that "if your game is the right difficulty for you, it's much too hard for a new player". I took this to heart - the first level I designed (which I was designing to be a nice intro to the game) ended up being reused as Orbit 6! The gif below shows the level in an early build of the game.

I had to constantly remind myself that the levels should be easier than I thought. In the end, I think the difficulty curve is fairly smooth and well done; we've had a fair few comments to that effect. The early levels especially feel like a nice feed into the first boss.

If I had one gripe, it would be Orbits 6 + 7. They lack the focus of the earlier levels, as they're not introducing a new enemy, and because of this I think they end up feeling a bit messy.

I didn't spend as much time as I would have liked on the bosses. Their shooting patterns are hard coded, and were produced fairly quickly. Given that, I'm surprised how well they turned out. The difficulty definitely steps up, but the attack patterns are simple and therefore predictable enough to feel like you could dodge them. The second boss is almost identical to the first, except he has homing shots instead of a laser. I'm amazed how much a simple change like that increased the difficulty, and really made the final boss seem like a fitting final challenge.

Polish

Most of the core gameplay was complete by the middle of the afternoon on Saturday. That left a lot of time for both features and polish. Polish can sometimes feel like a waste of time during LD, but even a little bit can go a long way. A title screen, for instance, can make your game feel so much more like a real game - and they are so quick to add. Screen shake and particles are the classic “juicy” additions - don’t be afraid to add them!

I’ve already mentioned the end screen, but the whole ending of the game could be considered extraneous. A short cutscene of the asteroid actually crashing into the earth was fairly quick to make, but really sells the consequences of the game.

SFX is another great example of polish. Adding some simple sound effects whenever an action occurs can make the game world feel so much more real. They can also be functional - My favourite SFX in Chicxulub is the laser sound - as it powers up, it plays a musical trill, which turns into a constant note when the laser is on. The rhythm helps teach players how long the powerup of the laser is, and when they need to be avoiding it by.

One thing to be aware of is not spending too much time on polish. If something isn’t working out - simplify. Don’t waste your time. As part of the backdrop in the game, you can see the earth below you. It’s drawn as a very simple circle. I spent about an hour trying to get a more realistic earth, which would rotate as you orbited around it - but when I couldn’t get it looking any good, I dropped it. Would the game have been better with it? Probably. Does it suffer without it? Not at all - which is why I was happy to stop spending time on it.

Conclusion

I'm really happy with how Chicxulub turned out. I think the whole team worked well together and produced some great output. The game itself plays very smoothly, and I think it's a great little experience. The only two things I'm really unhappy about are the length (it could do with being a little bit longer) and how innovative the game is (I always like trying to push the boat out a bit more).

I think that’s just about everything I wanted to mention. This has turned into one of the longest post mortems I’ve written - thank you if you read any of it! I really enjoyed thinking more about good game design and game feel this LD, and hopefully I’ll be able to take some of it into the next LD and return to making something a bit more inventive!

If you’re interested in playing the game, you can find it here: https://ldjam.com/events/ludum-dare/47/chicxulub

I also created a timelapse of my part of the development. Have a watch if you’re interested!

https://www.youtube.com/watch?v=jTnMP0kV79U