Wee Boats May 2025 Progress Update

2025-05-25

Wee Boats is coming together!

The start of the year felt like slow going. The slog towards the end of the project. Setting up a sole trader company, trying to get the Steam page up and running and small progress on the game here and there. But now over the last month, the engines feel like they are running again and we are having fun with the boats once more!

A Maze

Holy Moly did we need A Maze right now. It is truly something special where I always come away with a drive to keep going. We submitted Wee Boats for a two hour demo at the Open Screens. Even though it was a small period of time, we got so much great feedback from everyone who tried out the game and we were buzzing. We then set up the game outside in the garden of Silent Green where folks could play in the fresh air.

We saw a lot of things that we can improve about the game. Fantastic! We are working on it now! Feels like the first time we are adding fun improvements to the game in some time.

People were excited about the game. Fantastic! That's been good for the old self belief. This is a silly, small game. I go through cycles of thinking that people are going to really not like it for its smallness but maybe there is a place for this too. Hopefully it translates to the Steam audience!

Steam

About a month ago we got our Steam page up and online as Coming Soon (You can go there now and wishlist :) ). So now we need to play the game of Steam and get them wishlists up! If you want a game to make any bit of a splash on Steam, you need a rake of wishlists. I feel like 1000 wishlists is the minimum you need for Steam to bother giving you a glance and between 7000-10,000 is when you may start popping up in some Discovery Queues or something like that.

We are currently way off those numbers but we are giving it a go to get the word out there!

How are we playing the wishlist game?

• We are on the TikToks babyyy
  • I've actually been having good craic putting together videos over the last month of the game and how we are making it. It's mad to see how the algorithms are ticking away doing crazy shit. I'll put up a video, watch an episode of Adventure Time, then look back at my phone and itll have gotten 1000 views in those minutes, but then it won't be seen by another soul ever again. We are going to keep plugging away at it and see if we can build up some interest.
• Festivals
  • I've been applying to game festivals as their submissions open up. We are going to be sharing our work at Spillkonventet in Norway in June and hopefully a few more in the coming months after that. Hopefully some of these come through and maybe come with a Steam featuring.
• Demo
  • We want to get a Wee Boats demo out over the summer! Test the wheels of the game out in the wild and sort out any server issues before the launch of the full game. This might help build a bit of momentum over the coming months that we can charge into the Next Fest with!

Boat Party

This coming week we are bringing the game onboard one of the boats that we are featuring in the game! Litteraturbåten Epos, which is a library boat that travels the west of Norway, is hosting a boat party in Bergen and we can join in! It'll be interesting to see how it goes down in a party setting with a crowd that isn't a gamer crowd. I'm hyped to bring it to the boat anyway!

Ok, right, back to it! Let's feckn go!

The Online Server Setup for Wee Boats

2025-04-16

In 2020, I came out with my first ever game which was FROG. It was an online where you could hop around and chat with text. While it worked, god love it, it wouldn't take much to make the whole game fall over. There is only a single server available and once more than a handful of players connected, things would get a bit weird. Frogs would lag and get disconnected all over the place. Luckily enough, its a rare enough occasion that there are more than that amount of players online and for how dodgy it is, it is still up and running 5 years later! That's a win in my book!

So now when approaching our new game, Wee Boats, we wanted to try and tackle some of the main issues to make it a tiny bit more resilient than that beautifully naive setup! The main issues were:

1. FROG doesn't handle load well. There is a single server with no limit. The more and more players that try to connect, the worse of an experience it becomes.
2. If a player connects to FROG in a part of the world far away from the server, they will have a very laggy experience. (And so will those observing that faraway player.)
3. There is no way to intentionally not connect to a server and have an offline experience.

In this post, I will outline some of the parts of the Wee Boats online architecture. It's by no means perfect but for a small game like Wee Boats, I think it will go a long way.

The Server Code

So the server code is made up of separate Bevy application running headless on a server. It uses the bevy_renet crate to handle connections and messaging from and to the clients. It runs at about 120 ticks per second and is constantly polling for new messages. This uses a trickle of CPU on my cheapest 4$/month digitalocean droplet.

This is a completely separate project to the main game but it's neat that both the frontend and backend use the same language and the same game engine. It makes life a simpler.

Multiple Servers!

To start us off, we have created a way to list currently active servers and allow the player to choose the one that appeals to them the most based on location or how many is online. This is crazy technology in comparison to FROG!

When the game starts up, it immediately queries an address that will send back a JSON document which lists the currently active servers. These servers are then listed to the player and they can choose which one they would like to connect to.

Example JSON:

{
	"servers": [
		{
			"name": "Europe",
			"location": "Europe",
			"ip": "X.X.X.X:XXXX",
			"online": "0 / 64"
		},
		{
			"name": "America",
			"location": "Europe",
			"ip": "X.X.X.X:XXXX",
			"online": "0 / 64"
		},
		{
			"name": "Offline",
			"location": "Offline",
			"ip": "",
			"online": "No"
		}
	]
}

How this looks in the game:

This is going to improve things a whole lot in comparison to the FROG days. With multiple servers I can have players connect to servers that are closer to them for a better experience. It also allows me to introduce new servers on the fly if there happens to be a lot of players online at one time.

How is the game synced?

Because we are not worrying about cheating in Wee Boats, we can use a networking model called Client Authoritative. What this means is that each game client is in control of its own boat and it will rapidly send updates to the server with new information about the boat. If the boat is moving, the client sends the message with its new position to the server and then the server will broadcast the new information to all the other clients that are connected. Same goes for if the player honks or sends a text message. An update goes to the server and then the server broadcasts the update to the other boats. This has its flaws but for a casual game like Wee Boats, it fits perfectly!

When a client receives position updates for a networked boat, it will smoothly move the boat from the old position to the new position. With updates coming in rapidly, this makes the networked boats feel like they are being controlled nice and smooth!

How to test 64 players online at once?

Well I haven't and I don't really know how with my current resources! The max that I have tested so far is 5 clients online at once and that works great so at the moment I'm crossing my fingers that it works that well at 64 players online! I know that this is a recipe for disaster! :D

Offline Option

Something that is important to me is that Wee Boats can run independent of the servers being online to help it run long into the future. Because of that, we have added an offline option where the player can experience the entire game, just without the online components. Even if the initial server list http request doesn't go through, the offline option will populate.

Potential Next Steps

Automatic Scaling

Currently, adding and removing servers is a manual process. I need to keep an eye on the numbers online, manage the online servers and keep the active server list updated that gets sent to the games.

I am not expecting a lot of players to be coming into the game but if this is something that happens, it would be great to have a script monitor the player numbers and manage this itself. I just want to be careful that I dont create something that racks up crazy bills!

That's all for now! :D

Steam account created!

2025-03-06

I have been extremely on the fence about putting Wee Boats up on Steam. That's where the real games go! I'm scared of being ripped apart with bad reviews and refunds! "What is this shit REFUND" "There was no game here REFUND" "This is way to short REFUND"! However, after working on this thing for 2 years now, I feel like I have to put it out there, even for the sake of putting it out there!

The worst case scenario is that I get a understanding for this release process and its also giving me an opportunity to break through some walls of setup work that I won't have to do for following projects.

Yesterday, I just got my Steamworks account accepted by Valve. It took over a week of applying every day and getting declined overnight for different unclear reasons. Setting up a Steam account is something that has caused me months of procrastination but now that step is done. I'm free!

Next up, let's make this Wee Boats store page and try get some wishlists in! The ball is in my court now!

You can read other Wee Boats updates on the devlog!

Wee Boats is a Short Game

2025-01-06

You can finish Wee Boats in under half an hour. You can spend longer with the world if you would like but you can get the full experience in a short amount of time.

Part of this is to make it realistic for a small team to complete a project like this. Right now, it would be almost impossible for me to create something of a larger scope even with infinite time. The drive required to bring a game project to its completion and release is all too easy lost at some point along the way.

Thankfully, this constraint goes hand in hand with the kind of games that I want to create. It allows for creating games that are concrete experiences. It allows us to focus on a small amount of ideas and explore those in a unique way. The games are therefore accessible to more people because it doesn't require a lot of commitment or complex learning from players to play the games.

Games can be 5 minutes long. If that's the amount of time for the experience to be felt then that's perfect.

Games don't have to make you feel something intensely to be valid. They can be subtle. Portray a random memory that you want to capture or something like that.

Games don't have to have an objective or a puzzle to complete. Gway with that.

Wee Boats is designed to be a short moment of exploration. A time of surprises that hopefully give you a couple of smiles, laughs and "aha thats gas!" moments while you play.

Others have written about the subject much better than I can. Some of my favourite writings on the topic are:

• Stuffed Wombat
• John Tryer (Link seems to be down :( ))

Introducing the Wee Wheel!

2024-12-26

Over the last few months, we have brought early versions of Wee Boats to two different events where it would be playable on an exhibition floor. This poses some challenges to make the game fit the environment. I personally have a tough time engaging with games or interactive pieces in exhibition situations.

I walk up to a game...

• What are the controls?
• Is the game in the middle of somebody else's previous play session?
• Do I need to go through a tutorial?
• What is the time commitment?
• Am I able take part without blocking out those around me?

With all these small mental barriers, I often will pass the games by with the aim of coming back when I am in the zone. I'm not sure if others feel the same way but if its something I definitely have noticed in myself at game festivals so maybe we can try and reduce that feeling for people walking past Wee Boats.

With this in mind, how can we make Wee Boats shine at events? We want people to be able pick it up at any point and feel like they can immediately take part. No controls to learn. No backstory or context required to understand whats going on. Just go boating and get lost in the exploration that comes!

Bring in the Wee Wheel!

The largest part of addressing this is with our handmade ship's wheel called the Wee Wheel! For exhibitions, instead of using a keyboard or a game controller, Wee Boats has been playable with this papier mache wheel.

We have found that people understand how to play from just seeing this at a distance. The goal is to signify that there are no complicated controls to learn, just grab the wheel and you are gaming! This has been extremely effective and has brought us a lot of joy seeing how people play with the game.

Laura and Brendan made the first version of the Wee Wheel that we brought to Berlin. This is us posing with our work of art.

Due to logistical issues with getting this wheel to Norway, I made another version of the wheel for the Piksel Festival. This means that now at the time of writing, there are two Wee Wheels in existence! What a time to be alive!

Handmadeness

The Wee Wheel is unashamedly toy like. It is made of cardboard, paper, masking tape and glue. It is playfully painted with acryllic paints and fat brushes. This is counter to the "gamer" style that computing is often associated with. RGB lights, hard pointed edges, neon green. Let's bring cardboard and duct tape into computing! DIY Punk computing! This scrappiness also is a signifier of a low barrier to entry and that this is something for everyone, not just "gamers".

In an upcoming piece, I will write a bit more about how we actually made the wheel. Little bit of techin' and a little bit of paperin'.

Wee Boats is not out yet but you can sign up to the newsletter (here!) to get a heads up when its coming out and you can check out the game page on Itch.io here

Online Boating

2024-10-28

Wee Boats is rocketing to the onlines! Buckle up...Its gonna get mildly social!

We are still working on getting Wee Boats ready for release. It's looking like it could be early 2025 at this stage but we'll see how we get on! We have been working on some online components for the game so I thought I'd give a little overview of them here.

First up, it will be possible to cruise around with other online boats! Oh god ya. Bring a friend or two along for the journey to explore the world! Encounter other captains making their way through the oceans. Get out of the way Sea of Thieves, Wee Boats is coming to town. We are not adding an in game chat but you will be able to honk at each other repeatedly and constantly. Sure what else could one ever need?

Secondly we have our messages in bottles. This is a way of ephemerally communicating with other future boaters. Find messages left by boaters past and cast out your own messages to wish future boaters well. Maybe pass on a secret that you have discovered?

It is important to us that our games can be played long into the future so Wee Boats isn't dependent on the online servers being online in order for the game to work. If we need to bring the servers down for whatever reason in the future, you will still be able to experience the entire game without these online components. The internet folk like to call this local-first computing I do believe.

Find the game page here and give it a follow

Sign up the newsletter here for the odd update (I still haven't mailed about anything. Its only for the big updates!)

Cool, thats it for now. See yis soon! James

Learnings from Playtesting Wee Boats

2024-06-23

Development on Wee Boats continues! Over the last few days, I have been asking a few friends to try out the game to see how they experience it. The great bit is seeing people having fun with the game. Whew! Great! The not so great bit is that the process has been highlighting some gaps in the onboarding of the game. I am going to try to come to terms with it in this post!

I have done a wupsie

I haven't been thinking enough about making sure players know how I would like them to play. Saying that, I don't want to force a style a play, in fact quite the opposite! It's amazing when players carve out their own game or try things I never would have expected. But what I absolutely don't want is for the player to be confused as to what is going on because I didn't explain it to them well enough. The player should know what tools they have available to them and how they can be used. Once I am happy that I've communicated those things, then the player is welcome to feck about and break all the rules that they want!

Wee Boats is simple and I probably was hoping that that simplicity would sort itself out and players would just understand everything from the get go. But the reality of a computer game is that there is a laptop keyboard there with about 100 keys and about 4 of them are useful to this game. Which ones are they? How are they used? Another reality is that the player can go wherever they want from the start of the game which opens it up for infinite possibilities as to what they see first. Often designers create boxed-in tutorial areas where the player learns how to play the basics of the game before setting off on their adventure. However, I want to try and avoid this because I feel like whatever I do there will feel heavy handed and forced. I want our world to feel open for exploration right from the start.

A note on Dredge

A game that I feel did this very well is Dredge. You spend time in the initial area, learning the ropes and you are kept there in a natural way because the outer world seems terrifying and your boat starts off as a piece of shite. Once you do break out of that tutorial zone, it feels like a natural part of the world. It is your safe home that you can return back to. I find it impressive that it isn't a tutorial area tacked on to the side of the game like these things often can feel like.

What have I been at?

I have found these onboarding communication problems to be just as hard, if not harder than the various technical problems posed by making a game. And I think it is because of this that I have been procrastinating dealing with them or even avoiding looking for them in the first place. I find it much easier to look for new fun things to add on to the game like "ooh lets add a social feature" or "ooh lets add multiplayer" or "ooh lets add a choose your own boat feature". This is also dangerous because for each new thing added, that is a new thing that needs to be explained and understandable.

Let's fix this!

I should have been testing those initial moments a year ago! And for future projects I will defo be keeping this more in mind. For now, I want to give this my best shot at fixing the problems that I am seeing before we call the game done. I have a list of about 5 things that are often problems at the start of the game that we need to sort out. I have some ideas for some but for others I am going to need to spend some time thinking! Let's go!

You can find the game page here which is where it will be downloadable when it's released: Wee Boats

Mind Your Memory! A Tiny Bevy Performance Investigation Story.

2024-04-17

I've spent the last couple of days trying to track down some performance problems with Wee Boats. It hasn't been a lot of fun but I have learnt some things and I want to write them down so I don't forget. Maybe I'm a thick eejit for not knowing this, and my conclusions are probably wrong in many ways but sure look, what can ya do.

For a little context, we are making Wee Boats using Rust and the Bevy Game Engine.

Main Learning

Files take up much more space when they are loaded into RAM than when they are on disk. An example is a jpg can expand to about 10 to 12 times its size when loaded into memory. :O

The Initial Situation

We want everything to load as fast as possible in Wee Boats. The easiest way to do this is to load all our assets into the game on startup and then everything is ready to go. Super! Our assets folder with images and music is currently around 200MB so my assumption was that we would be dropping about 200MB into RAM, and I was ok with that! I generally test on my desktop with far too much RAM for its own good so I didn't see any problems.

Ah shite, there's a problem?

It was only when moving to my laptop with 8GB RAM that I would notice the game really struggling on startup. I thought this was just the game being a bit slow to read from disk. My initial thought for solving this was just to pause running the actual game until we finish this loading process.

For the craic, I went to check the system monitor to see if it showed anything interesting and then I saw that the game would suddenly want to hog about 3GB of RAM, all in one munch. And then the stalling of the game was the laptop running out of RAM and needing to turn to slower SWAP memory.

3GB of RAM?

How is that even possible? That's a load and this is only a lil game.

My initial hunch was wondering if I was loading images several times into memory for every time it was spawned into the world. Turns out this wasn't the case as the asset_server.load() function in Bevy keeps track if the asset has already been loaded and returns back an id of the asset to you. Alright, I've learned something there.

I headed desperately to the Discord for help where I was told that files like .jpgs and .pngs are actually compressed on disk and expand by about 10 to 12 times their size when loaded into memory. Ah bugger, I didn't know that! I suppose that's a new thing learnt.

Change in Plan!

Well now I need to re think my "load everything on startup" strategy. I can't be at that any more. Knowing this, I now see the worst offender images and am in the middle of implementing a lazy loading system. For our logbook sketches, we will load in the images for the nearest pages that you're on and load and unload as you page through the logbook. Its a bit more of a hassle to implement but we now use about 600MB of RAM. I can defo still improve on that but we have the back broken in this now!

Profiling Troubles with Bevy

I find profiling with Bevy difficult. I have tried using Tracy but firstly its tricky to get running. I can't get it running on Linux for love nor money and then have to go to Windows where they have an easier to run binary. The time I did get it running, I couldn't understand what was going on with my readings. It was hard to parse the data at all to find actionable areas of improvements. This friction is enough for me to fall off from using these tools at all with Bevy which is a big loss. It would be class if Bevy made it easy to get into the details of how my game runs and where the problem areas are!

Submitting Wee Boats to A Maze 2024

2024-04-03

1 Week Before Submission

It is currently January 24 and we have a week left before the submission date for A Maze. A Maze is a small festival for experimental games and interactive art that I have attended the last few years.

Its very easy to feel like nobody is out there or trying your games when you release them online. In my experience, even with a nice amount of downloads, I hear very little back from those who do try out the games. Did they have a nice time? Did they hate it? Did it inspire them to do something afterwards? I'm not sure, because even if they did, that get's lost over the internet.

This is why I value the likes of A Maze because it brings like minded people together, to play cool games and share experiences. It felt like real people were playing the things that we made :O !

This is why bringing Wee Boats to the festival has been a big goal since the outset of the project. We want to get it into people's hands and feel how they experience it! However its not something that we can take for granted as we must first submit and be nominated for an award to be able to exhibit a project. It's a long shot with the quality of the games there but lets see how we go.

The game is not finished so we are doing our best to pull together a demo that we can submit that will portray the feel of the game. Its so cool to see everything coming together after about a year of the project looking quite janky in some way. We have lots of ingredients all over the place and now is when we start to put them together into a neat little package.

We have music coming in, logbook sketches and the world continues to be filled with life and new things to find!

Submitting it is also forcing me to think about a lot of the things important for releasing a game that I have not needed to think about over the last year. Some of these are:

1. Figuring out how to make builds for Windows, Mac and Linux.
2. Coming up with an app icon.
3. Making sure the window opens in the right way in full screen.
4. Explaining the controls.
5. User testing D:

Currently, I have managed to get a working build for Windows and for Linux. Mac has decided that it won't cooperate. This is an important one to have though so I am going to pray to the Apple gods and give this another go in the coming days.

2 Months After Submission

It is now April 3rd and I am back writing again to give a little post-mortem of the last months. We went hell for leather in the run up to the submission deadline. It was a week of late evenings Wee Boating. Its crazy the number of things that need to get done in order to prepare a game for any kind of a release, even for this vertical slice demo.

There is a lot of hidden work in getting a game ready for a new person to pick up it up and have a fun time with it. Creating builds, reducing build size, explaining controls, last minute features, testing on the different platforms, fixing bugs.

The Mac version of the game was being a nightmare so we threw that in the bin and went to focus on just the Windows version and getting that as robust as we could.

And of course, after a pretty chill year of dev with very few bugs, the last day is when a couple of humdingers came to say hello. The game would give a white screen and nothing else sometimes and sometimes the music wouldn't start. Super!

We managed to submit a demo that we were happy with but it fairly wrecked us! If you look at the picture below, you can see us scrambling in those dark green days at the end of January and then it goes dead in the subsequent weeks where I couldn't face the computer again. I'm still recovering from it to be honest and still trying to get back on the saddle.

In the end we didn't get nominated for an award which is a shame but it is to be expected because the game is still in quite an early state. While its charming now, I don't think it has that punch that a properly polished piece has yet. We do however have a 2 hour demo slot at the festival to show it off so that will be another milestone to aim towards and get some people trying it out.

Working on a New Area!

As a part of trying to wrap up development on Wee Boats, we are working on what we want the end game to be like. The goal is to have a nice surprise for those who stick around until the end and have it feel fulfilling in a Wee Boatsy way.

I am not going to spoil what that is yet but we have something in the works that we are pretty hyped about!

Working on the Wheel!

As a part of our on site demo, we have been constructing some of our own hardware to control the game! One of the pieces is a ships wheel to mount to the desk. The logic for controlling the boat is different to how we have so far been doing it with the keyboard so recently we have been doing little bits with getting that wheel experience nice. More specific info and videos will come for this soon!

Starting work on the online components!

While Wee Boats will be fully playable offline, we are planning on adding some optional online elements to add extra depth to the experience. The first part that we are working on is adding messages in bottles!

The idea is that you might come across a bottle from another player, dropped sometime in the past and see what their little message to the world was. And likewise, you can then drop a thought into the Wee Boats ocean for a future sailor to find.

We are programming our server and client code for this at the moment to save and update the messages. Its going well so far and we will then be moving on to implementing the UI and in game assets for it!

That's all for now

We have about a month until the demo in Berlin so the focus will be on bringing the game further and then polishing like heck again before that. Hopefully I will get some more pieces written for it because I have a growing list of things I want to share! See ye soon!

Creating our own small tools to make our games

2024-03-13

What's The Problem?

The Unity engine is a huge blob that I don't understand. The Godot engine is a smaller open source blob which is better but there are still lots of checkboxes to learn and scenes and nodes and stuff.

Even after learning enough to get by in these engines, I'm still only using about 20% of what they can do. The rest doesn't apply to me and is sitting there clogging up my game builds with hundreds of MB and draining me laptop battery. G'way with that.

A Nudge in a New Direction

I was listening to an episode (that I think was taken down because I can't find it anymore) of Gamedev Breakdown where the presenter Todd Mitchel spoke about creating games from the ground up using XNA. He also spoke about a fellow called Michael Hicks who creates his own games and also has documented some of his own self-made tools on YouTube that went into his process.

This resonated with me a lot and sent me down a rabbit hole that gave me a bit of hope. Still, for some reason it felt a little out of reach. XNA and Windows Forms, the tools talked about mostly here, were not my comfort zone and I didn't jump head first into them.

Enter Raylib

A little while after, I came across Raylib which felt perfect for making game tooling. It's very similar to XNA, except in C as opposed to C#. It has a simple little API which gives lots of neat functionality like drag dropping files onto the window and drawing shapes onto the screen. Saying this, Raylib isn't the point of this post. It could be anything. It was just the piece of the jigsaw that made it seem possible for me to make my own tools. If you're on a similar buzz as me and want to try out a different tool, use whatever gets you hyped!

My First Foray into Creating Tools

For the game that myself and my friends are working on at the moment, Wee Boats, we quickly reached a bit of a snag that was how we are creating our map. We are using a JSON config file that defines the locations of every structure in the world. This is read by our game and it constructs the world on launch. Each structure has a location associated with it that has an X and Y coordinate. Editing this in text was grand when we had two or three structures but when it went any larger than that, it was impossible to use.

Whats this? I hear a tool coming on!

Introducing the Wee Boats Map Editor! Come on ye'boya

Using Raylib, we made a simple program that would read our JSON config and give us a visual representation of our world and easy ways to edit it.

Here is how it looks at the moment:

Each circle represents a structure in the Wee Boats world and through here we can move them around, add new structures and do other common actions that we are building up over development. We can then export it and it updates the JSON config that is then read by the game itself.

Here is a small example of some of those structures in game:

What are the best bits about this tool?

• I understand how it works.
• It's small. It does exactly what we need it to do and speeds us up a great deal.
• We can quickly extend it to add new functionality.
• We can quickly adapt it to work with future projects.
• It was great craic to make.

A Small Toolier Future

Making this Map Editor and the game around it has been a blast so far. Of course I am not going to be able to build as large and amazing games as people might be able with Unity but the feeling of understanding and mastery I get from this is amazing.

The idea of working in C freaked me out before. It sounds terrifying needing to worry about memory and all of this jazz. But that has rarely been an issue in making these. In fact, I have been moving much faster than I am used to. I feel like I have been tricked into thinking that big tools like Unity make the process easier but in reality, they have been bogging me down all along.

Us game makers don't need to be dependent on a company like Unity to be able to create work that we are proud of. Fuck them. Lets make and own our own stuff.

Maybe I am in a honeymoon phase and I am cruising for some doomed pit but where I am sitting right now, I have never felt better about making silly games.

How we are using Sprite Stacking for Wee Boats

2024-02-11

Wee Boats was originally born out of wanting to try out an interesting technique that I had seen online a few years ago. I have seen it being called Sprite Stacking so let's use that name here!

Sprite Stacking is a way of creating pseudo 3D assets, using 2D horizontal slices that are stacked on top of each other. Especially when moving around, if you update the angle of each slice, it creates a convincing depth effect as you can see the asset from all sides.

Before I start to show any visuals, I want to say that all of the art used in this post was made by Brendan Hewson who is a part of the Wee Boating team!

Here is an example of what it looks like with one of our little boats:

It looks beautiful! :')

How Do We Make Our Wee Boats?

There are so many options here with how you could go about this! I am going to highlight how we are doing it but don't let that limit you! See what mad ideas you have!

Firstly, we make our sprite slices using Aseprite as if we were making an animation. Each frame represents a slice of our model. Each slice needs to be drawn individually which isn't the easiest to do. If you turn on onion skinning it can help to see the previous and next frames. When we are ready to try out our creation, we then export this as a sprite sheet that we can use in the game.

Here is an example of an Aseprite project:

This is an example of an exported sprite sheet:

And then the game stacks these sprites to create our pseudo 3D boat:

Here is a honk action shot that shows the slices slightly further apart:

Working with Challenges and Limitations

While I find this method quite charming, it also comes with some challenges. Not even pseudo 3D methods come without cons god dammit.

It can be difficult to have an overview as to what the 3D model looks like while you are drawing the layers in Aseprite. We have found external tools that let us preview the model separately which has improved the workflow a lot but is still an extra step. The best one for us has been Jon Topielski's Stacked Sprite Viewer.

Another challenge is that it can be difficult to model little details using this system since you are working with cross section slices. We have been able to work around this by using the top most layer in some structures as a normal 2D sprite. This can be drawn nicely and add character to the game.

Animations are another one that will be challenging with Sprite Stacking! Animating across slices would be a big pain and it was one that we didn't try solving. We have worked around it by using simple animations transforming the slices themselves. An example of this would be the bounce that the boat does on a honk, shown in the videos above. I think its pretty cute! Another workaround here was using that top most layer of the structures saved for a traditional 2D sprite. We made a system for animating this sprite to add even more pazzazz!

Here is an example of an island that has a base constructed using the sprite stacking technique and then a layer on top to draw our animated 2D sprites. If you see it in the game, these Penguins are bopping like made yokes!

We can also get in small details like windows on buildings by colouring edges of sprite slices.

The Programming

I won't get into this in too much detail here but I will give a couple of high level points as to how we went about this.

The engine we are using is Bevy which is open-source and written in Rust. This uses an ECS arcitecture which allowed us to get sprite stacking working with great performance.

A boat is an entity that holds data like the current angle within it as components. We then spawn children entities under that parent boat entity for each sprite slice. The systems then iterate quickly through each sprite slice and sets their rotation to match the boats current angle every tick.

I won't go into more detail on this right now but if some of those things sound new to you, and interesting, I recommend that you check out the Bevy Engine as a starting point for a simple entry into using ECS.

I am super happy with the performance that I am able to achieve with it. This screenshot was taken from my 2016 (7 years ago at time of writing) laptop with just an Intel i5 and I have hundreds of boats driving around at 60 FPS!

So that's it for the moment! We are still working on Wee Boats and will be posting updates here and on the Itch.io devlog. You can also sign up to the newsletter which I use for larger updates.

Go raibh maith agat! All the best!

Honk

The Middle of the Process

2024-02-11

I'm hitting a tricky part of the process with Wee Boats. We have made a lot of process and have gotten to about 50%~60% of completion, I would say.

At the start of the project, there were clear things to work on.

Then it becomes less clear as most of the elements are implemented to a certain degree.

What I am seeing as the main next parts to work on are:

1. Refactoring poorly written code.
2. Fixing bugs that have been lying around.
3. Improving poorly performing aspects of the code.
4. Improving features.

Making sure that the code is easily built upon is super important for my own motivation. If I can feel myself saying "Oh god, I'll have to tackle that" in a disheartened way, that's enough to put me off starting the job and then that's a cycle that will continue. At this point of the project, motivation is super important to me because I want to move the project forward and get it finished.

I tend to like refactoring my code. I find it rewarding as you chip away through parts of the codebase and you make things better. I'm going to take a small amount of time and put it towards improving everything that I have in front of me. Make it easier to fix bugs, improve performance and add features going forward.

I have heard people say that they refactor after every session of programming. I should probably do that a bit more.

• Sometimes lack of time makes that tricky.
• Sometimes its a higher level view when there are more pieces in place that make refactoring easier.
• Sometimes I will have learned something new after a period of time that I can go back and improve

Announcing Wee Boats

2023-10-12

Whats going on? We're making a new game! Wahey! And there's a crew of us putting this one together! Laura Ryder, Brendan Hewson and myself are working on this and we're going to make something class!

The game is called Wee Boats! I'm so hyped with how its shaping up and I want to share more about how it's coming along!

Wee Boats will be there to provide a short, calm experience that is more an ambient bob about a body of water than a game. It's pretty simple. You control a small ship and can explore a world that is full of character and little surprises. Your only other control is that you can honk. Honk to yourself. Honk at other boats. Honk at lighthouses. The potential is endless! We are also creating a logbook that will keep track of the things that you have honked at. A nice record of your time boating at a wee scale.

Over the next few months, we want to explore different aspects of the making of the game as it develops. I find it tough opening up about the development because its exposing this small idea out to the world. Some of my current concerns are:

• Is it cool enough to get people excited?
• Will we be able to get it finished?
• Will I be able to keep up posting about it?
• Will I have enough interesting things to talk about through the process of development?
• Aaaaaaaa

However, let's give it a whack anyway!

As an experiment and a challenge, I've opted to use Bevy as the game engine and write it as Rust. Its been mostly great and I'm now even happier with the decision after all the Unity shite. This is an open source engine and we own the game! I'll talk more about Bevy in another post because it's great.

So where are we at today? We first started programming the game in March 2023. 6 months, feck. There has been a couple of main areas worked on so far:

• Building out the systems to display the sprites using a method called sprite stacking to create a pseudo 3D look.
• Building out some small tools to make development flow a little easier.
• Adding animations and interactions for birds and structures.
• Adding a very primitive logbook and UI.
• Testing out audio directions for the soundscapes.

What's up next?

• Adding support for underwater creatures and things to pop up and say hello.
• Making the logbook look nice.
• Building more world!
• Adding interactions to all of the structures and animals added so far.

Cheers for reading. Sign up to the newsletter to receive the odd update about my work and I'll let you know when you can get wee boating!

You can also find the pre-release game page on Itch where you can follow the development.