It’s time for our July post! At this time of year we have a lot of admin to deal with, but we’re still making steady progress on both of our current projects! We’ll talk a bit about both of them; if you missed our post last month, definitely give that a read for more information on what we’ve been up to.
For our main project, we’re continuing to work mostly on networking code. A large chunk of our overhaul is now done, but there’s still a few bugs that need ironing out, as well as some more features to keep everything properly in sync. We’ll carry on with this throughout July, as well as working on some smaller features and fixes if we have time.
Progress on our second project is also going well, with both of us spending lots of time on all aspects of this project; this includes finalising several of our level designs, as well as continuing to replace our developer assets (as we mentioned in May). We’re hoping to have something more interesting to say within the next couple of months, so be sure to keep an eye out for more news!
Welcome to our June monthly update! We’re taking a bit of a break from our usual updates this month, to talk about what we’re doing as a whole rather than getting into the tiny details.
If you’ve been following us for a while, you’ll know that we’ve been working on our main project for years. This is the project that we’ve generally been talking about in our posts here. We’ve been doing this in our free time, taking a bit of time out of our evenings to make slow but steady progress. The idea is that this is a shared project, with both of us working on it equally.
However, as we’ve hinted at in recent months, there’s another project we’re working on too! This one is a bit different; we’re both contributing to it, but one of us is working full time while the other sticks to part time. So you can expect it to feel a bit different to our other games! The upside of this is that progress is much faster; while there’s still a bit of work to do, we’re looking towards a release in a matter of months, not years.
We haven’t publicly announced anything about this second game yet, except for a couple of assets appearing in posts on this blog (including this one). For now, we’ll just say that it’s very different to our other games, but if you’re a fan of games that combine multiple genres in unique ways, you might want to keep an eye out for future posts!
Going forward, our posts will include info on our main project as well as other things that we’re working on. We’re also planning to add some more pages to this blog, describing our current projects in a bit more detail.
Thanks for reading this weird post – we’ll be back in July with another update!
Welcome to our May update! We’ll keep things short this time; there’s plenty going on here but, as discussed in recent months, it’s a bit hard to talk about most of it!
On the programming side, things are moving along steadily. We’ve finished the enemy attacks that we mentioned last month, and have mostly continued working on the network changes we’ve talked about previously. There’s still not really any interesting stuff to talk about on that front, but it’s going well!
Again, we unfortunately don’t have much that we can share on the art side at the moment. But we’ve been working on a bunch more assets related to the UI as well as some the appear in the game world. We’re currently at the point where we’re replacing a bunch of our ugly developer assets with pretty, properly-drawn assets, which is always good for morale!
Thanks for checking in this month, we’ll be back in June. We promise we’ll have some more exciting stuff to talk about soon!
It’s the third of the month, which means it’s monthly update time!
On the programming side, we’ve carried on with the network improvements we’ve mentioned in previous months; in particular, we’re working on keeping both players in sync especially when randomness is involved, or when something can only be done by one player but both try to do it at the same time. There’s not really any interesting stuff to talk about yet, but it’s going well so far and we’ll keep you updated as we work on it. It’s a pretty tough and boring job though, so we’ve also been doing a few other tasks to keep things interesting, such as finishing implementing some of the weirder enemy attacks in the game.
Similar to last month, we can’t talk much about the art side yet, but our work has been very similar. We have a few big-but-important UI assets that we’ve been working on, which has taken up most of our time, but we’re continuing to work on a few other things where we can. We’re really hoping we’ll be able to talk about it more soon – we don’t want to leave you hanging any longer than we have to!
That’s all for now – things should be getting a bit more interesting in the coming months, so be sure to stay tuned!
It’s time for our March update! You know the drill by now – read on for an update on the last few weeks!
Last month, we mentioned how we were finishing off layering of sprites, including parallax effects. We said it would take a few more days, and as is often the case when we say that, it took almost the whole month! It’s working great now though, so we’ve moved on to planning networking improvements, as well as some tweaks to animations that use the new layering functionality. We’ll let you know how that’s going in more detail next time!
On the art side, there’s not much we can talk about without revealing… secrets. But the spoiler-free version is that we’re working on a bunch of complicated UI assets, as well as some in-game objects. Hopefully we’ll be able to go into more detail before too long!
Thanks for checking in this month, we’ll see you again in April!
Welcome to the February post! As always we’ll talk about a few of the things we’ve been working on since the last post.
We talked last month about our work on improving the networking code. We’ve been doing lots of planning and some minor improvements, but nothing too interesting. Instead, we’ve mostly been working on layering of sprites, i.e. which objects appear in front of others. This is because some of our new animations involve characters moving towards or away from the screen, which our code didn’t really support before. It’s mostly done now; we should get it finished in a few days, after which we’ll probably focus on networking some more.
Of course, we’ve been working on more art at the same time, particularly UI and visual effects. There’s still quite a few “developer assets” that we’re replacing at the moment; in fact, we have a huge spreadsheet with a list of files that need updating, which we’re slowly working our way through. Of course, we’re still adding more developer assets for new features at the same time, which makes this a daunting task. But overall it’s a “two steps forward, one step back” situation, so we’ll get there eventually!
That’s everything for now – we’ll be back in a month!
It’s 2026! After some time off around Christmas and the new year, we’re starting to get back to work. We’ve still got a few things to talk about though, and we wouldn’t want to leave you in the dark, so we’ll get right into it!
On the development side, we’ve carried on reworking a bunch of our code to get it working in network games. We’ve overhauled how “non-creature” inputs work, i.e. inputs that don’t control the player character (such as pausing and interacting with the UI). These inputs weren’t being sent across the network before, but they’re now implemented and are fully functional! We have plenty more work to do to clean up the networking code; we’ll let you know how that’s going next month!
There’s not much to talk about on the art side; it’s pretty much a continuation from earlier months. We’re making good progress on UI improvements, as well as some of the most complex animations for the main characters. We didn’t get around to getting these working in-game as much as we wanted to, so we’ll make that a fairly high-priority job for this month.
That’s it for this post, so thanks for reading! We have big things in the works for 2026, so make sure to check back later for more news. In the meantime, we’ll be back with our next monthly update in February!
The not-so-descriptive controls of Mooncat, from UFO 50.
Whenever I first start up a new game, one of the first things I do is jump into the options and look at the keyboard controls. Usually I’ll rebind at least some of them to keys that I’m more familiar with, but it depends on the game and the genre. RPGs and strategy games tend to be okay, but for others – such as platformers – you can expect me to rebind pretty much everything!
This is because, over the years, certain genres such as first-person shooters have developed a rough convention: you use WASD to move around, move the mouse to aim and left-click to attack, with other buttons varying depending on the exact game. This convention dates back to at least the 90s, when games such as Quake and Half-Life brought this control scheme into the mainstream. Check out this PC Gamer article if you’re interested in how WASD became dominant.
But for this article, we’re talking about other games, especially platformers and similar games that don’t need the mouse at all. Despite platformers being huge long before the FPS, there’s still no agreed-upon way to control your characters. So today, we’re going to discuss how to come up with a default control scheme for your game in a sea of inconsistency!
Let your players rebind keys!
Toejam & Earl: Back in the Groove is a great game, but this is all you get for the controls. Yes, the Z key and the Searching text box are completely different shades of green. And yes, if you’re colourblind this would probably be tough to understand even if the colours matched.
Before we start talking about defaults, the most important thing is that you let players rebind the keys as they choose! This can be a bit of a pain for various reasons (the UI components can get complex, you’ll need a way to detect and display every possible key, etc.) but it’s almost always worth it. That way, it doesn’t matter if your controls aren’t perfect; players can change them to whatever they want!
The only possible exception to this is if your game is very simple, and there are multiple possible keys for each action. For example, in Blockhead we allow both WASD and arrow keys for movement, with all other actions using intuitive keys (often multiple keys per action) that work with both movement methods. But we’d only recommend this for tiny games with simple controls; for anything more complex, the time you spend on custom bindings will absolutely be worth it!
Mouse or no mouse?
These controls look fi- wait…
Above is a screenshot of the default bindings for the Crash Bandicoot N. Sane Trilogy. Most of the bindings look fine to me, but there’s one obvious thing that stands out: usage of the mouse! It feels like they were going for some kind of parity with first-person games, since WASD to move and left-click to attack works well for those, and you’ll need your hand on the mouse to look around and aim. But for Crash Bandicoot, a third-person platformer with an automatic camera, the choice seems a bit odd. Right-clicking to slide/crouch is even more odd; that isn’t something I’ve seen anywhere else!
There’s nothing inherently wrong with using these controls; if it works for you, then go ahead. But as a default, it’s very unintuitive for a game where moving the mouse doesn’t do anything. A better option might have been to use keys on the right of the keyboard, such as J and K, or common action keys such as Shift and Control. This would also open up the possibility to assign other actions to nearby keys; if you’re using J and K, you can also use I, L and M quite comfortably. (But we’ll come back to that topic in the next section.)
One final consideration: if your game relies on mouse input, make sure the cursor is bound to the game window when your game has focus. Otherwise, anyone playing in a window is likely to start accidentally opening files on their desktop in the middle of an intense challenge! (Shout-out to this Reddit comment for pointing that out.)
Hand to hand
Apparently, (New) Super Lucky’s Tale has decided that your right hand is just for looking around… and maybe jumping if you’re feeling generous.
An important thing to consider is what each hand is doing. For the sake of comfort (and avoiding injury), it’s best if the player doesn’t have to move their hands too much during the game. For example, if your game uses WASD and the mouse, don’t bind important actions to the right side of the keyboard; bind them to keys close to WASD, or to other mouse buttons if available.
If possible, try to distribute important actions between both hands. In a platformer, it makes sense for one hand to deal with movement, and the other to deal with interactions such as attacking and picking up items. If a player needs to press lots of buttons at the same time (e.g. sprint-jumping at a front-right angle), you should make an effort to spread those out a bit. Aside from the limitations of how a player can move their fingers, you might also run into issues with ghosting (as demonstrated here). Make sure you test your default control scheme to make sure that it’s comfortable to use, preferably on lower-quality keyboards if you can.
You might also want to be aware of players using a laptop! This massively limits your options for mouse input, since scrolling or clicking the mouse wheel is usually very awkward (if it’s even possible) on a laptop. I’ve noticed that Palworld is nearly unplayable with a touch pad, since it requires the mouse wheel to cycle between weapons and tools, and that input can’t be changed for some reason. (I know touch pad isn’t exactly an optimal choice for a game like Palworld, but it’s still a problem that it isn’t an option at all.)
WADS of arrows
I had the game open for about 5 minutes while I was fiddling with the options and getting this screenshot. Zote’s “singing” starts to drive you crazy by that point.
As discussed in the intro, WASD is the standard for games that also use the mouse, and with good reason. It works fine for non-mouse games too, but arrow keys can also work just as well. As with everything else in this post, there’s not really a right or wrong answer; go with whatever feels more natural for your game, and feel free to take inspiration from another game if its gameplay is similar to your own!
One benefit to the using the arrow keys over WASD is that they are a lot more obvious to those that haven’t played many games, and aren’t familiar with gaming conventions. So if you’re targeting these players, using arrows as your default for movement will make it much easier for them to get into your game. These are also the players that are less likely to think to go into the options and rebind the keys, so catering to them makes sense. It also works better for players with different keyboard layouts, such as AZERTY, where the W and A keys are positioned differently.
However, WASD also has a lot going for it. Several keyboards (especially on laptops) have awkwardly-positioned arrow keys, often with tiny up and down arrows, so players with these keyboards may find this to be uncomfortable. WASD also more closely mimics the style of most controllers (with a stick or d-pad on the left for movement, and other buttons on the right), so might feel more natural for players that are used to playing with a controller.
Think about what other buttons you’ll use too! As shown in the Hollow Knight screenshot above, it’s common for games with arrow key movement to use Z, X and C, as well as keys from the row above if needed. For WASD movement, you can expect to see letter keys on the right being used, such as J, K and L. Both schemes might also use other, special keys for certain actions, such as Space for jumping, Escape to open the menu and Tab to open a map. There’s no universal standard that every game sticks to, but if your bindings are roughly in line with similar games, it will be easier for players of those games to pick up.
Conclusion
Nice to see that Tomb Raider 1-3 Remastered is still afraid of any keys above the bottom two rows (except End for some reason), just like the original. How nostalgic!
So, to summarise: there’s a lot to consider when coming up with controls for your game. The best mindset is to treat the defaults as a recommended scheme for new players: you want them to be as simple, intuitive and familiar as possible, especially to players in your target audience. It can help to look at the control schemes of similar games, and adapt them to fit your game’s mechanics.
Make sure your controls are comfortable to use, spreading actions between both hands where possible, and avoiding clumping too many keys together if they need to be pressed simultaneously. Make sure your game is playable on a variety of hardware too; consider the different keyboards that your players will be using, especially the positions and sizes of different buttons.
But most importantly, there’s no one-size-fits-all solution to any game’s controls. So make sure you let players rebind the keys to their own tastes!
Welcome to our December update! As the year comes to an end, we’re tying up some loose ends in preparation for a busy 2026. So let’s talk about what we’ve been up to over the last month!
As we mentioned in the last post, we’ve been working on getting some of our new mechanics working in network games. Naturally, this led us down the huge rabbit hole of fixing our networking code, which isn’t very robust at the moment. We’re now planning a couple of potential overhauls to make it work nicely, so hopefully by next month we’ll have made some good progress!
We’ve worked on a bunch of different stuff on the art side this month. Aside from more work on UI (as discussed last month), we’ve also started getting some of our big, complex animations into the game! The exact conditions to trigger the animations aren’t functional yet, so we’ll use some of our development time next month to get those working. We’ve also been doing some extra concept art and planning for various different things that we’re working on – we’ll share more when we’re able to!
That’s it for our final monthly update of the year – as with the last few years, you can expect another game development post later this month. But other than that, we’ll see you again in 2026!
It’s November, which means it’s time for another blog post! We managed to make some solid progress on our main project this month, so let’s get into a bit more detail!
On the development side, we’ve finally finished the world select menu we’ve been working on! It’s fully functional now; you can use it to view the available custom worlds (stored in a custom content folder in My Documents), and select one to unload the current world and start playing on the new one! The downside is that it only works in local games at the moment; there’s a few issues stopping it from working in network games. So we’re working on fixing that at the moment, which should be finished by the end of the month!
Moving on to art, we’ve obviously been continuing with our remaining character animations, including the few huge ones that have taken up a huge chunk of our time recently. As suggested last month, we’ve also been working on the UI; lots of the interface is still using old developer assets, so we’ve put together a spreadsheet detailing what’s done and what still needs doing. The spreadsheet has hundreds of entries, so we’ll work through them and see how much we can get done!
That’s it for this month; we’ll see you in December!
Loony Code Blog 
