Hmm. I was nonchalant about that.

Ah well. Time to sleep on the theme. Night guys 😀

Got an awesome game idea lined up, so I’m praying I can get it done in time.

NOW. TO CODING!

Drugs.

Right, my plan for the next 5 hours:

Finish balancing – 30 mins.

Add more drugs (yes.) – 1 hour.

Update graphics – 1 hour 30 mins.

Polish/more drugs – 2 hours.

Or something.

Play it here: http://natpat.hostoi.com/LUDUMDARE21.swf (arrow keys and Z to punch)

http://www.ludumdare.com/compo/ludum-dare-21/?action=preview&uid=3501

I’m really quite pleased with how this turned out. Timelapse and post-mortem coming soon, but now sleep. Lots of it.

 

Firstly, timelapse:

http://www.youtube.com/watch?v=M5UoTeDj7jA

Well, that’s my second LD done. As with last time, I’m very pleased with what I got done in the time I had.

This post mortem is very long. Sorry.

The finished drug - uh, I mean product.

PART 0 – The Idea (03:00 – 16:00)

After seeing what the theme was, I was  initially disappointed. Escape wasn’t one of my favourite themes on the list. But, as it was 3am in the morning for me, I went back to sleep.

I had a longish car journey the first day too, so that set my back a few hours, and by the time I could finally get started, it was 4 in the afternoon, 13 hours gone. D:

Luckily, that car journey had given me time to think of an idea I liked – the idea of drugs, and them being your ‘escape’ from reality.

What went well – Got an idea fleshed out

What didn’t – Lost 12 hours of time.

Part 1 – The Base code (16:00 – 21:30)

I started by creating a simple platformer base. One of the things I had in mind to do was to create a system where you could walk through things, but jump on top of them too, if that makes sense. Somehow, this took me about 4 hours, and it didn’t even make it into the finished game.

I then started work on the hand – this turned out quite well, but again, I wasted a lot of time debating about the best way to do it – in the end I ditched the walking animation completely and ended up coding the punch animation. However, having the hand as a separate entity worked in my favour later.

What went well – Got a well fleshed out base code written.

What didn’t – Messed about doing features I didn’t need and took ages.

The Doctor Spritesheet.

Part 2 – Enemies (21:45 – 00:40)

I then started work on the enemies – I used quite a lot of the code from the player, which saved a lot of time. I took a break from 22:00 – 22:30, then started working again.

I bumped into a few problems with the hands – before the enemies were introduced, the hands were referencing the player directly. However, the enemies needed hands too, so I thought instead of having 2 hand classes, have one, and make it reference a new class, HasHands, which the Player and Enemy will extend from. I love OOP.

I finished up the enemy code, then headed off to bed.

What went well – Created robust enemy code.

What didn’t – Spent a lot of time on polish that could have waited.

Part 3 – Sleep (00:40 – 8:30)

ZZZZZZZZZZZ (etc.)

What went well – ZZZZZZZZZ

What didn’t – ZZZZZZZ

DRUGS

Part 4 – DRUGS! (8:30 – 10:20)

Woke up refreshed after a good sleep and willing to start working again. I started work on the main point of the game – the drugs. I made the enemies drop them, and when they did, I made them fly out. Again, this polish could have waited, but in the end I think it was worth doing.

I also created the explosion effect you see when you punch a doctor whilst on drugs – again, this is polish that could have waited, but it was something I always wanted to have, and I think it adds quite a lot. I ran into some problems getting the colours correct, and in the end, I ended up creating three different explosions all of different colours at the same time to give the impression of different colours. However, thanks to Flashpunk’s Emitter class, this was a doddle.

What went well – Got another piece of the main game done.

What didn’t – Got stuck on the explosion code for a while.

This place is beautiul.

Part 5 – Walk #1 (10:20 – 11:45)

I’m on holiday on the Isle of Skye at the moment, so we went out for a walk for a bit.

What went well – I got some fresh air and a break.

What didn’t – Lost time.

 

 

Part 6 – Finishing gaps (11:45 – 14:00)

I finished up most of the core game code here – made enemies able to hit you, made you able to pick up drugs, etc. I probably should have done this slightly earlier, but hey, at least I got it done. I got stuck on a bug, but it all worked out.

What went well – Got things neatly finished up.

What didn’t – Wasted time squashing bugs I made by trying to save time.

Part 7 – Walk #2 (14:00 – 17:00)

Went on another walk.

What went well – I got some fresh air and a break and some ideas.

What didn’t – Lost lots of time.

Part 8 – Fail hour (17:00 – 18:00)

This was probably my worst hour in this whole process. With 10 hours to go, I decided it would be a good idea to completely revamp the base game code and do something I’d never done before – pseudo 3D/2.5D or whatever – basically, I decided to try and add another dimension to the game, so it resembled the flash beat em ups you see.

To make a long story short, I failed. Miserably. I wasted an hour. Luckily I had made a backup, as I had an inkling this would happen.

What went well – Nothing.

What didn’t – Everything.

How I made the trippy background.

Part 9 – MORE DRUGS! (18:00 – 20:15)

Feeling a bit let down by my fail, I decided to create the background I had wanted – white tiles normally, and flashing coloured tiles when high.

To start with, I tried having the Tiles tint a random colour, then use alpha to fade them out. This ended up lagging the game hugely. I mean a 60fps to 30fps drop. This obviously was not the way to go.

After dinner to think about it, I tried reducing the explosion size, thinking that could have something to do with the lag, but no.

I then tried having the 18 predefined tile colours you see up there, and selecting one of them randomly, but no, that didn’t work either. I then realised that it was the alpha that was the problem (which I should have realised, duh), and so created 10 tile sized white squares, each with a reducing alpha, and layered them over the top of the tiles. Horrah! It worked!

I then finally started work on the effects of the drugs, which was really fun (in my timelapse you can see my playing the game for quite a while :’) )

What went well – Regained my urge to work on the game, and created a nice looking background.

What didn’t – How long it took me.

Part 10 – The aim of the game (20:15 – 22:30)

Running around punching doctors and getting high is all very well and all, but the game needed a real aim. So I added in the Craving Bar. The real pain here was making it balanced – having drugs restore the right amount, etc., but I think I got the difficulty ok.

(I also had a pokemon battle against my brother here.)

What went well – Had an awesome Pokemon battle.

What didn’t – Took ages to get the balance right.

Part 11 – EVEN MORE DRUGS! (22:30 – 00:30)

Having three different drugs wasn’t really enough, so I started adding more. I ran into some problems with Flashpunk’s code – the screen’s xScale affected the whole screen, but with some quick poking round I was able to fix it.

I also played the game a lot here. Which is a good sign, as it means it’s fun… or maybe I was just sleep deprived.

What went well – Added a lot more fun to the game.

What didn’t – Wasted time playing it.

Path 12 – Death & Polish (00:30 – 3:00)

I realised I hadn’t actually made you die, so I hastily coded that in.

I created a title screen, and added in some instructions that appear at the beginning.

With about half an hour to go, I felt like just surviving wasn’t enough. I quickly added in a high score system in for collecting drugs, and with about 15 minutes to go, I had finally finished. I gave it to IRC for some testing, fixed a few bugs, submitted it and collapsed into bed.

What went well – I finished!

What didn’t – I had to rush to do it.

All in all, I think it went very well. And I just realised this turned into a 1300 word essay. Ah well. Have a cookie for getting through it: http://www.techbusy.org/wp-content/uploads/2011/04/web_browser_cookie.gif

Tags: post-mortem, postmortem

Daily Fourth? O_o

I somehow managed to get the Daily Fourth on Newgrounds yesterday. I’m amazed

Well, the title says it all really. Anyone interested in doing a relaxed collab for the October challenge? (http://www.ludumdare.com/compo/2010/09/27/the-october-challenge-begins-a-guide/)

I’d be primarily interested in collaborating with an artist, seeing as my artistic skills are very lacking, but I think it’d be nice to work with someone else, regardless

I work in AS3, so if you’re a programmer too, I’d obviously prefer if you did too. 😛

Oh, and if you want to see some of my stuff just check out http://natpat.net 😀

For the third time running, I’m IN! Whooo!

For the last 2 LDs, I’ve been using AS3 with FlashPunk (which is an amazing engine). However, I’d like to branch out and widen my AS3 knowledge. I’d really like to use just AS3 without anything else, but I may go with Flixel or something else. Your thoughts?

Which means I’m in!

I’ll either be using FlashPunk, or my own personal library that I’ve been building up for a while, which I will declare closer to the time if I do intend to use it.

Either way, I’ll be using GIMP for graphics, FlashDevelop as my IDE and I’ll be drinking so much coffee.

As I couldn’t enter the last LD due to illness ( ), I will be attempting the sidequest I proposed last time.

Good luck to all, and may kittens finally be chosen.

Link

I’ve been adding to a bare bones AS3 engine for a while now, which handles all the boring stuff. Here it is. I may or may not use it, (probably not), but just in case.

I have a solid base for my game. Now it’s on to graphics and gameplay… which I still have no idea about. I’m thinking an RPG. Possibly. Don’t really know.

This is what I have right now.

We have keyboard and baking cat, and a countdown to boot!

http://twitch.tv/LiteralGames

 

ASCII games in flash say whattt?

http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=3501

 

As the main programmer of Literal Games, I spent most of my Ludum Dare weekend figuring out how to draw pixels to a texture in Unity and writing bad cellular automata. You can now watch my progress over the weekend in a condensed, timelapse form!

https://youtu.be/oKq72juHeec

I had a blast this Ludum Dare, and I've had a great time reviewing games as well. If you fancy giving Bonsai a go, click here. It's a slow, peaceful game about growing and taking care of Bonsai!

I'm in the process of writing up a post-mortem as well, which should be coming soon. I've got lots of things I want to write about - how the bonsai growing and rendering works, why we spent so much time on transitions, and what we got wrong in terms of time management.

As usual, I participated in this Ludum Dare with a couple of friends. Usually, it's a good excuse to spend a weekend together, whilst being creative and producing something we're proud of. For obvious reasons, it wasn't like that this time. So, how did our first all-remote Ludum Dare go? This post-mortem will go through my weekend, showing what went well (:slightsmile:) and what didn't (:slightfrown:).

:slight_frown: Staying up until 2am is harder on your own

Usually, we stay up until the theme is announced (2am UK time), and do an hour or so of brainstorming before bed. I find it's a really helpful exercise - as you're drifting off to sleep, ideas crystalise in your mind, and you wake up with something to get started on in the morning. Sadly, it didn't quite work out this time. Our artist (who usually pushes us towards the more interesting ideas) was slightly ill and couldn't stay up. Neither me nor our other team member (our very talented musician) were very enthused by the theme, and spent an hour fruitlessly brainstorming. Discord made this even harder. We ended up trudging to bed with a vague idea that neither of us were really committed to.

:slight_frown: Not having a concrete plan

We reconvened in the morning, and fleshed out the idea slightly. A "frantic houseplant tending" game, based loosely (or exactly?) on Overcooked. However, we struggled to make it work out - what else do plants need other than watering? In the end, we decided that we wanted to make something calm, peaceful. A relaxing escape from how the world is currently. A little tree growing simulator. A way to express your creativity and be close to nature. For gameplay - you'd be given an outline to shape your tree into, and judged on how well it fit.

:slight_smile: Cellular Automata

I've been interested "evolving systems" since learning about Conway's Game of Life. I love seeing how complex movement and growth can be encoded in such simple rules. L-Systems and Cellular Automata are two common techniques to achieve this that I've experimented with in the past. I was excited to see how I could utilise these to make a "tree growing" system. Once I'd figured out how to draw pixels to a texture in Unity, I set about making an extendable base for the tree growth system.

To make sure it was working, I implemented the Game of Life. Once that was set, I turned my attention to how trees grow. I tried a few things, but fiddling around with various variables was slow, and I couldn't get something I was happy with. A few failed experiments are below.

:slight_smile: A team to bounce ideas off

Even though we were remote, our team was in constant communication through Discord. A quick voice chat revealed the solution to my tree growing woes - let the player grow the tree instead! Instead of trying to build a complicated, natural looking tree growing system, part of the gameplay would involve the player deciding where branches should grow.

This simplified my life considerably, and I got to work implementing the interaction.

I haven't done a solo LD for a while, but I think not being able to step back and consider the larger picture is often one of my weak spots. If I was working on my own, I think it would have been easy for me to work myself into a corner and get nowhere with an automatic tree growing system - and then still not have any gameplay to speak of. Working with a team keeps me in check, and ensures I can focus on what is actually important.

From here, a few things fell into place. The tool for adding branches was added, as well as the ability to cut off branches. (The GIFs below are from the finished game, but the interaction is the same)

:slight_frown: Cellular Automata

So branches were done - but branches do not make a tree. Leaves were next! As leaf growth was not going to be controlled by the player, I thought cellular automata would be perfect here!

It was not. At this point, I still had Game of Life and strict rules about how leaves/cells should grow in my head. I wanted the leaf growth to be simply defined, yet have rich, emergent properties. Plants seem to follow simple rules and instructions when they grow - maybe those rules could be codified? If they can, I don't know how - I do know how to make a bush though!

:slight_smile: Flexibility in roles

In the end, I gave up for the night. Our artist, who had spent the day making the player sprite and background, asked if he could take a look. He's a competent coder, and understanding that the game we were making probably didn't need that much more art allowed him to move onto this task. In the end, he ended up implementing all of the rest of the tree growing logic. I'm glad he did - not only do the trees grow leaves in the final game, they're actually interesting to look at!

So what did I end up doing for the next two days? Partly fighting with Unity (the Pixel Perfect Camera is still magic to me, why can't Unity get VCS right, and no one can convince me the scale in Unity's UI system makes any sense), but mainly I was working on what could be grouped into the "interface", as well as polish.

:slight_smile: Interfaces

There are two core interfaces in the game - the bonsai itself, and the computer.

The Bonsai interface is pretty straightforward. The icons are clear and simple, and use the purple colouring that's consistent throughout the game. The "Finish" and "Back" buttons say what they mean, although the "Finish" button isn't completely clear: it scores your bonsai and then removes it. The one part that was tricky to get right (and I still don't think we have) is the translucent shape showing what shape you need to grow your bonsai into. Once the tree is grown into the shape, it becomes difficult to see exactly where to trim. One could say that it's part of the game and the artistic expression, that users should "feel" where the outline to the shape is - but in practice it just becomes a bit annoying.

The computer went through a few redesigns. We felt from the start it was important to store the players highest scores on each shape to give them a sense of progression and achievement. Some of the shapes also start out LOCKED, and are released one at a time once the player finishes a bonsai. I think this gives the player a sense of forward motion in the game, and a small drive of curiosity to see what other shapes there are.

The computer went through a fair through changes in UI. Some people may not think UI is a good thing to spend time on in Ludum Dare, but I think it's a great use of time. A good, cohesive UI makes a game feel so much more complete and polished, and goes a long way to make people think your game has more going on.

:slight_smile: Polish

A lot of the game we made is strictly unnecessary. The game opens on a player standing in a room, and you can click to make him move around and interact with things. Clicking on the computer opens the computer UI, which scales in and out. There are four places to put a bonsai, and you can choose where each tree goes.

When you click on a bonsai, the camera pans and zooms into the tree, and enters the bonsai UI. The icons fade in, and the player fades out (as he's standing in the way). None of this was necessary, and some of it took a fair amount of tweaking. However, I really think it takes the game from a slightly janky tree growing simulator, to a charming, complete little package.

To top it all off, my favourite part of the game is what happens when you press the "Finish" button. Your bonsai is graded on a percentage scale on how well it fits the shape given. The value ticks up, and does the classic "slow down to the final number". And then the game just stops for a few seconds, and lets you admire your creation. The shaded overlay of the shape is removed, and you get to see what you created.

Again, the end screen went through a number of iterations before being finalised. At one point, the score took up the whole screen, until our artist pointed out the bonsai should be the focus, and the score should be secondary.

Conclusion

Well, this post became a bit longer than I anticipated. I'm extremely happy if you've read this far. In a way I'm mainly writing this for myself - my first Ludum Dare was LD20, and each LD I participate in I find myself rereading my previous posts, and enjoying the memories. I'd encourage everyone to write up at least something - if only because I enjoy reading them!

If the post has piqued your interest to try the game, you can check it out here. There is also a timelapse of my development below!

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

I'm the main programmer of Literal Games, where we made Chicxulub in 72 hours with pico8. I made a timelapse of the two and a days I spent on the game. Have a watch!

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

Chicxulub is a "bullet hell" game where you play as the asteroid which wiped out the dinosaurs. There are dinosaurs in spaceships and screen filling bosses - if you're interested, you can find it here: https://ldjam.com/events/ludum-dare/47/chicxulub

I'm in the process of writing a more detailed post mortem, especially around how we managed to get the entity movement and waves set up.

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

PICO-8 is a fantasy console for making, sharing and playing tiny games. We used PICO-8 for the first time this LD, and absolutely loved it - I wanted to share what awesome things you can make with it and hopefully have a few more PICO-8 games next time round!

I spent a couple of days playing all the PICO-8 games I could find that people have made for this Ludum Dare, and listed them here. Try some out and see what you think about PICO-8! If I've missed any (and I'm sure I have!) please let me know and I'll add them to the list :slight_smile:

All of these games are playable on the Web, as well as on mobile!

Domain of the Time Wizard

A little action adventure game where you must find the three time orbs to finally beat the evil time wizard!

Soulbound

An action/puzzle game where you must retrieve the Soul Gem from its underground lair. But what strange powers does the gem hold?

Mines of Movania

A puzzle game about redirecting minecarts to the correct exit, only using the track you currently have - which the cart is probably using!

 Stuck in the Sewers

You play as a rat who just wants to go on vacation - but sadly you're stuck in the sewers! Make your way through a labyrinth of pipes to eventually reach your holiday!

Flying Saucer Scramble

Draw loops around the enemy spaceships before they shoot you!

Breadcrumbs

A small puzzle game about finding your way out of a maze. Use the breadcrumbs to mark where you have been - beware the birds don't eat them though! And - did I just see a person...?

Super Jump Guy

Make sure you play this years hottest new platformer! Maybe once more! Again?

For { }

A fiendishly hard Sokoban type puzzle game where programs are executed based on where the blocks are in the world. Packed full of fun little features!

Orbitary

Orbit around the planet for as long as you can, picking up data packets. Lightning, asteroids, comets and more will make your job difficult - how long can you last?

The Loop

A small demo made in a few hours - circle around, picking up the right colour circles to grow big!

Not Enough

Your attempts at escape are good, but... NOT ENOUGH

Disco Loop

A Sokoban type puzzle game where you must move to the beat - disco style!

Pico Arena

An arena based fighting game where you must fight various gladiators/enemies to escape... or not?

a nice place

A story based game about waking up on an island, and finding yourself.

Bad Panda vs The Cursed Maze

Help Bad Panda escape from the Cursed Maze! A small memory game.

Red Venom

Blast the aliens and destroy their villainous leader to bring peace... or not?

Stuck in Orbit

Another space shooter - avoid enemies and orbit faster and faster until you escape the planet!

Swing-by

Another orbiting game - this time escape an exploding core by using planet's gravity to increase your speed! Swing round and jump from planet to planet.

Swop

Get to the flag by pushing around bubbles that can swap the path you can walk on. The puzzles get pretty tricky!

office hours

Anything can happen in office hours... play as the manager in this office simulator. Deal with customers, wipe up spills, call the guards, pick up a knife...??!!?

Chixculub

(self-promotion alert - this is the game I worked on!) Play as the asteroid that wiped out the dinosaurs in its final moments - avoid the dinosaur onslaught to reach the planet!

I finished putting together the timelapse of my part of development of Deep Sea Phishing!

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

The game is a hacking minigame bonanza, where you must hack deeper and deeper into the CIA from your deep sea submarine to prove aliens exist. Play it here!

Deep Sea Phishing is a game about hacking into the CIA from a submarine to prove that aliens exist. It's my 11th (!) Ludum Dare entry and 7th time entering with a group of my friends.

I like to write a post-mortem of the weekend after each event. This is mainly for myself to look back on in the future, but I also enjoy writing other peoples, and I hope that more in-depth, long form content on this feed will encourage others to do the same and possibly avoid more low-effort self promotion.

So how did our 7th LD go? What were the highlights and lowlights? Where did we go right, and where did we go wrong?

A good theme

Staying up until the theme is announced is something we always do. Being based in the UK, this was 2am for us. In the past, this has worked out quite well, but after a long week of work, having to stay up until 2am wasn't the easiest or most fun thing to do. Nevertheless, our team assembled. Our second programmer had just come back from the pub :beers:, so we were mostly in high spirits.

The theme was announced: "Deeper and deeper". For once, I didn't think it was a completely awful theme! The sentiment was shared by some of the team. We began with our usual brainstorming (or more accurately, writing down all our shit ideas until we find one we don't hate).

In the past, it's taken us a while to come up with a good idea. For LD46, we didn't even manage it until the next morning. This time, however, we struck gold early. One of us wrote down "Deep Sea Fishing", and, in a stroke of genius, our inebriated friend joked "What about Fishing with a PH?". And "Deep Sea Phishing" was born.

I think this is the first time ever in a LD that we've came up with a title at an earlier point than the last half of the last day. It's certainly the first time we've produced an idea solely from a good title. But from there, everything seemed to slot into place. You would hack "deeper and deeper" into some organisation. It would be set in a submarine. The hacking would just be stupid minigames. And there would be some silly story to drive it forwards and to tie it all together. We went to bed after half an hour of brainstorming, satisfied with our idea.

Tired

I woke up tired. In my excitement about our idea, I had set my alarm early to get up and get started on the project. After staying up until 2am, that potentially wasn't the best idea. Still, I got myself to the computer with a large cup of tea. The rest of Saturday was painful though. I ended up taking more time off than working on the game, as I was tired and slow and my brain was foggy. If I had been better rested before the weekend, perhaps staying up until 2am for the theme would have been fine, but I was tired from work and general life and it was not a good idea.

Still, I knew when I was beat and ended up going to bed at a reasonable time on Saturday evening to ensure Sunday would be productive.

Picking a resolution

One of the first things we did as a team was decide on a resolution for the game. This may seem like a bit of an odd thing to decide on so early on, but I've found in the past that trying to make Unity's UI system work at different resolutions and aspect ratios is just not worth it for LD. Especially with the game shaping up to be fairly UI heavy, it let me lay things out on the screen as I wanted them, and not worry about having to deal with scaling or relative positions. It also let our artist decide exactly how things should look.

Knowing your tools

This was our third LD with Unity. The more I use it, the more I enjoy it and understand how to get things done. I leaned hard on prefabs for the minigames. Each minigame is just its own prefab that we can initialise and destroy as necessary. Co-routines and callbacks were also extremely helpful to easily set up sequences of events (minigame ending -> robot comment -> new minigame). I also learnt some new cool things - sprite masking was very easy to get set up and really sells the windows that contain the minigames.

A good plan

We had a fairly solid plan from the get go, and it really helped us focus. We had a good split of work, a lot of things that could be worked on asynchronously, and good communication when one of us finished a task. We stayed on Discord for almost the entire weekend, and screen shared most of the time as well, which allowed an easy way to show and get feedback on progress.

One thing we only started doing on the last day was an actual Google Doc of the tasks we had left. We'd just been typing them in discord, which worked to an extent, but the tasks kept getting lost. A little bit more organisation could have been better.

Scope

On the first day, our other programmer planned out some of the minigames we could make. Around 10 were planned, but we ended up with only 6 in the final game. On the final day, I was itching to add another minigame to the mix to ensure there was enough content and that things wouldn't get stale, but our artist talked me out of it. He was definitely right - the time we didn't spend on another minigame we ended up using to ensure the game was tight, had a good flow, and was really polished. In the end, 6 well polished minigames in a solid base is better than 7 or 8 less good minigames with some bugs.

This also applied to the minigames themselves - I spent a bit of time on the firewall minigame trying to include notes you had to hold for the right amount of time, not just press at the right time. At the end of the first day, I realised that it was more complicated than I had time or energy for, so I simplified. In the grand scheme of things, not a huge loss!

Playtesting

Getting people to play our games on the last day was a good idea. We realised some controls were janky, or that there were some bugs that we just hadn't found. One thing that changed a fair amount due to feedback was the robot's directions before the minigames. They are very explicit and repeat instructions a few times, which was not how they were written to start with, and still makes me feel like they're a bit verbose. However, no-one seems to be confused about how to play the game, what they need to do, or why they should do it. I'd rather the instructions are a little bit wordy than someone being frustrated with the game or confused what they need to do.

Polish

I really enjoy making LD games feel really polished. It takes a fair amount of work, but making sure transitions are smooth, that things look clean, and that everything feels reactive and fun to touch is so worth it. Things like the bubbles and fish through the submarine window, the robot's words of encouragements after each minigame, the sound effects, the multiple music tracks and how they switch - all of this took up valuable time, but helps sell the world, pace the game properly, and set the tone more than the whole rest of the game. Hell, the whole submarine console is completely unnecessary, but the game would so different and (IMO) much worse without it.

Difficulty

The game is easy. There is a small increase in difficulty in the penultimate mission, but almost no-one I've watched play has actually failed due to time constraints. This is something we've learnt from previous jams - we'd much rather have people experience everything we've made, and have a fun time doing it, then really challenge or frustrate the player. The story and the stupid minigames are the driving forces, not the difficult or technical gameplay. And that's fine! Sometimes games should be challenging, sometimes not.

My favourite point about this is that in the last level, when fighting the alien, there is no alien health bar. We don't track how many bullets you shoot. We trust that players will assume that's what they need to do. You win the fight when you hit the spaceship with 20% or less of the time remaining. This was our artist's idea, and I think it's genius. We want a thrilling, close finale. People aren't going to play the game and look for deep strategies - so why bother even trying to balance it? Fake it! Make sure it seems close, and people will enjoy it, and not think too much about it. Some people might say it's cheap - I think that's the point. It was quick and easy to do, and it nails what we wanted. Why would we do more?

Conclusion

I woke up the morning before LD really excited. I feel really strongly that the games we make during LD become part of us and our past, and I love the experience of having no clue what I'll make over the weekend, but knowing that I'll have made a game, and that it will have taught me something and be something I can look back on fondly.

For all my complaints about LD to my team over the past few weeks (I still think the rating system and blog needs to change), it's a great experience. Deep Sea Phishing is definitely one of the best games we've made. There's almost no better feeling that watching someone play and enjoy something you've made, and I got that so much over the last few weeks. I'll see you all next time :smile:

If you'd like to play the game, you can do so here. There is also my timelapse of development:

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