Planking Boarders is a game about keeping a ship afloat by juggling two tasks: repairing cannonball holes on the bottom deck and fighting navy boarders on the top deck. Its a very frantic, silly and cartoony experience! It is also my entry I submitted to a game jam my university hosted in my first year of my course and managed to win it!

I am very proud of what I achieved with Planking Boarders. After competing in 10s of game jams before starting my course, it was extremely fulfilling to have all that past experience lead me to win this jam in my very first year!

 If you want to you can play it on my itch.io - no downloads required!

The rest of this post and following posts are essentially a small devlog of the first half of how I made my entry including the design process, any issues I faced and how I resolved them.

Day 1

During the first year of my game design course, I attended the yearly GameX conference. Guest speakers from across the game industry - developers, designers, voice actors - are all invited in to talk and answer questions about their experiences in industry. This was already a really fun and educational experience, but the real cherry on top personally was learning that as part the games course lecturers were hosting a game jam open to all students!

I knew I had to enter it. I decided I would try tackling this one solo. I had done several game jams before this one alone and felt that I would find it easier to do this one alone too, mainly to avoid communication or team management problems that I couldn't afford in a the short 3 day deadline. 

Brainstorming and Planning

On the last day of the event, the theme was unveiled - 'Boarders'.

Usually when I am told it's theme, I like to create and suggest a few ideas for a game jam entry. Then, I/we pick the teams overall favourite and focus on just that one. This time, however, I immediately had two ideas before I even left the conference hall that felt like they would work perfectly together.

1. Boarders as in people boarding a pirate ship Pirates of the Caribbean style.
2. Boarders as in people desperately boarding up cannonball holes in a ship to keep it afloat.

The game loop I was imagining was meant to be silly and stressful at the same time, like something you would see in an animated kids cartoon. The rules of the game were:

• The goal of the game is to keep the ship afloat as long as possible.
• To achieve this goal, you must successfully complete tasks such as repairs to delay the ship sinking.
• Each task takes time to physically travel to.
• The game is single player, so you must decide what order every task is approached
• The difficulty comes from prioritising what order to do tasks on the fly as new ones pop up faster and faster.
• A minigame should be present for each task to add more skill to the game

I laid out a few more quick aesthetic design choices that enforced this intended experience, such as making the game 2D and the characters anthropomorphic animals - really just hone in on the Looney Tunes vibes!

Programming wise, it was a 3 day game jam with no restriction on tools used. This meant I was almost certainly going to use the Godot engine as the game engine and GDscript for the code due to my personal experience and preference. Godot is also very lightweight to allow for quickly iterating on, building and testing my games mechanics.

Game Design

As the main goal of the game is managing your time based on where you are and how long it takes to get somewhere, I started by designing the physical space where all of these rules would take place - the ship!

I realised here that I could have one task for each of the two decks. This keeps the game simple to make as I only need to write code and make assets for two tasks, but also keeps the game easy to learn for people who are quickly trying out all the game jam entries. Below is an update the diagram above, with sketches and text to explain what the two tasks are and what the loss condition is.

This was where mentally visualising the game became much easier. I imagined a player patching a leaking cannonball hole before dashing up to whack a boarder of the ship, only to immediately run back downstairs to patch another hole that just split open again.

To add a little more complexity to the game, I added planks and nails as physical resources used when completing tasks. This may have been one of my bigger mistakes as it created new UI, variables and assets I was already going to struggle to get done. It was like adding a new task but for the creation of the game, not the game itself! However, it did make the game more complex without adding minigames which would have been even worse.

The planks were the most important resource, and would be used to either repair a hole or whack a boarder off the ship completely. The catch was that you could only carry one plank and only use it once before needing to return to a wood barrel to restock. Nails were similar, but had multiple uses and would delay rather than complete a task. This was reinforcing your wooden repairs in the bottom deck, or laying out nail traps to slow the boarders on the top deck - the latter never saw the light of the day due to running out of time. 

Prototyping

Ship Hull and Platforms

With the design now fleshed out, I started the whiteboxing process of making it in the game engine. To save time, I just worked with collision shapes which I could make assets for later.

The pink boxes are platforms, which can be passed through by pressing a 'crouch' key. This lets you walk up the stairs and over the front of the top deck without making the lower deck inaccessible. As Godot supports one-way platforms by default, all i had to do is disable the platforms collisions when the button is pressed, and re-enable it once the player has passed through.

Interior Water

Next I worked on the water filling the ship. As i was using Godot's Polygon2D nodes, it was quite easy code-wise as I could just modify the top left and top right points of a rectangle to slowly rise

# 'start_height_marker' is a 2d marker for where the water height should start
# 'final_height_marker' is a 2d marker for where the water height will cause a
# game over.
# I chose to lerp between positions as I could make the variables time based
# rather than guessing how long it would take based on a 'pixels per second'
# basis.

func _process(delta: float) -> void:
 	var fill_this_frame = get_fill_per_second(current_hole_count)
 	water_progress = clamp(water_progress + fill_this_frame * delta, 0.0, 1.0)
 	
 	var water_height : float = lerp(start_height_marker.global_position.y,
 	final_height_marker.global_position.y, water_progress)
 	
 	water_poly.polygon[0].y = water_height
 	water_poly.polygon[1].y = water_height

Cannonball Holes

I wanted cannonballs to stay static and keep breaking apart rather than new ones forming. This helps keep the game a bit more predictable when playing and also when designing the conditions for the endless difficulty as there is no random 'spawn locations' each time a hole appears that could make that hole much quicker or slower to repair.

Repairs

Cannonballs have 3 states - open, boarded and boarded and nailed. The last two ended up being essentially the same, as nails only add some time before the board breaks, with the only difference being the sprite. The ship only fills when it the hole is open. Because of the calculation below, most of the code associated with each cannonball is just changing the sprite and adding the UI to show your current materials. 

Fill Speed Calculation

As shown in the previous water code snippet, there is a function for calculating the fill progress per second. If I just multiplied the speed of water filling the ship, x, by the number of holes, it would linearly increase - one hole would do x% per second, two holes would do 2x% per second and zero holes would not fill the ship as 0 * x is just 0. This is fine, but quite unforgiving if multiple holes break open in quick succession.

Instead of linearly increasing, the fill speed is calculated based on a predetermined curve. The values below are the array that the get_fill_per_second() function uses.

# stops multiple holes being unfairly quick (2x, 3x, 4x etc.)
var fill_speed_multiplier : Array[float] = [
	0.0, #0 holes
	1.0, #1 hole
	1.6, #2 holes, so on..
	2.0
]

First Assets

To finish day one, I started making some assets for the player. Doing nothing but code was tiring, and it was nice to get a big complex task like animating all the walking and jumping done ASAP.

I knew the characters resolution would be about 128x64 pixels due to the collision shapes size. I also quickly decided on using Aseprite to make the pixel art for the game as it is both familiar and very good at creating sprite sheets to add animations in the engine.

Now knowing the sprite fits, I moved on to animation. I created the character with basic and disconnected round shapes as it is much easier to animate their limbs since i only need to move the position of each layer (left hand, right hand etc.) and slightly alter the shape to give a convincing motion effect. Below is an example, with each of the 6 layers given a different colour 

Halfway Point Progress

This was how the game looked half way through, about one and a half days worth of progress compressed into one little gif. I was happy with my progress, but very wary that I had the whole top deck to do still, along with alot of time needed for drawing the ship and making a nice title screen and finalising the game loop with loss conditions. Notice how the 'finalising the game loop with loss conditions' was the last thing on that list. I should have prioritised that task much higher, as you will find out in the last half.

You can find the second half of this devlog here, where i go over some of my favourite features and the most terrible bugs of the entire experience developing this game!