Hey Kinoko fans!

Today, I have lots more to share with you on our game’s recent progress, and also some thoughts on the thing that everyone’s been really patiently waiting for: the potential, first ever demo release! Firstly, though, it’s been exactly two months since I last shared a proper update on the game’s progress, so let’s start there.

When I wrote the last update on 30th April, I’d just begun working on the game’s inventory system. Though it’s not particularly pretty, that’s functionality complete. It doesn’t really do all that much at the moment, since there aren’t many items you can actually obtain yet, but it does what it needs to do, and we can build on it easily. You can review what items and equipment you’ve got, and each item comes with a short description which tells you (in an ‘in-universe’) context a little more about it. Now if we can just improve the look-and-feel of the user interface a bit, we’ll have a perfectly good inventory system!

But with the inventory working on a functional level, I was ready to move onto another part of the tablet. The concept art we shared last time hinted at lots of different tablet functionality, but not all of it’s essential for a demo. Outfits and skill trees, for example, are things that won’t be developed in time for our first demo. Put simply, when you discover something new, you use Kinoko’s tablet to scan it, and then it appears in the codex. (If it helps to visualise it, it’s not too dissimilar to the Pokédex in Pokémon, but with manual rather than automatic entries.)

Implementing the scanner meant implementing weapon-switching much earlier than planned. We only have one weapon at the moment, which is Kinoko’s standard raygun, and we don’t expect that to change for a while yet. However, because of the way in which the scanner works, it made a lot of sense to treat it as a weapon, and have it share the same controls as the raygun. This is strongly inspired by the three most recent, mainline Tomb Raider games, in which there are four main weapon types which you can quickly switch between using the D-pad. Similar functionality now exists in our game: ‘up’ for the scanner, ‘down’ for the raygun.

With the scanner equipped, actually scanning a discovery is very simple. You hold down the ‘scan’ button, which requires Kinoko to stand perfectly still, and a large circle begins to pulse around him. The scanner quickly charges up, which takes two seconds, and any scannable entity inside the circle once the two seconds are up will be scanned. A ‘success’ notification will appear on the screen, and then – just like that – the discovery will be registered in Kinoko’s codex.

The following video includes a demonstration of this functionality.

If you watched the video above, you might’ve also noticed that we’ve taken a new approach to summoning starsprites. Just to refresh your memory, starsprites in this game serve as both Kinoko’s hitpoints and his power-ups. With no starsprites, Kinoko has no hitpoints, and he’ll die in a single hit, but (alongside providing him with passive perks dependent on their colour) each starsprite he acquires will provide a single-use shield, protecting him from harm once before flying off to recover. Inspired somewhat by the ‘Aku Aku’ masks from the Crash Bandicoot games, these starsprites were found inside crashed meteorites, and accompanied Kinoko when freed.

Now that’s been the system since we first implemented starsprites last year, and it worked fine, but I began to feel dissatisfied with this approach recently and wanted to try something different – something that puts the player in control, and gives them more choice over how, and when, they use the starsprites. Chelsey’s artwork demonstrates perfectly the relationship between Kinoko and the starsprites, and I wanted the game to better-reflect that. Starsprites shouldn’t be something that Kinoko stumbles into randomly – they should come to him when called. Not only that, but I was trying to think ahead a bit too to the unlockable skills we plan to eventually add, and how we can build a system that can be progressively upgraded.

The answer? Giving Kinoko the ability to summon starsprites!

Giving Kinoko the ability to summon starsprites required a new kind of currency, so I added one and called it ‘starlight’. Starlight is obtained by killing enemies, and once you’ve got enough of it you’ll be able to instantly summon a random colour of starsprite to your side, in exchange for a significant amount of starlight. This is a complete replacement for the old system, so the meteorites which existed for this purpose before have now been removed from the game. As you progress and unlock new skills, the amount of starlight that you’re able to carry will increase, and so will the number of starsprites that can be summoned at a time.

Like I said, the primary reason for this change is that we want the player to feel a certain level of power over the starsprites. The relationship that Kinoko has with them is one of mutual respect, and they’re there for him just as he is there for them. Making it so that Kinoko can summon them – and progressively summon more of them whilst unlocking more of their powers – ought to be a much better way of demonstrating that.

So, that’s the major stuff – the inventory, the scanner, the codex, and the reworked starsprites. We did a lot of other things too, including the first few interactable obstacles. We have fungal vents now, which can kill you if you get too close, and we also have breakable platforms which must be hit with force to break through. The most interesting of these, though, is probably the new giant toad enemy, which – being much too tough to harm with the raygun – can only be displaced with the help of the large heavy boulder that is perched conveniently in the tunnel above his head.

What else? Well, we got Chelsey set up in Godot finally, so she can contribute to the game files directly by implementing levels herself. We’ve jumped suddenly from two levels to about eight, and she’s also switched us over to a tile-based approach rather than a polygon-based one, primarily because it gives her the ability to more easily prototype levels and them demo them as she builds. We’ve also introduced some basic lighting and shading to one of our levels. It’s not pretty at the moment, but I did it myself – once Chelsey has a mess around with it I’m sure it will look a hundred times better, as will all the various particle-based effects that I’ve added up to this point.

The final big new addition to the game itself over the past couple of months has been the addition of a developer console. With all the new levels we’ve introduced, I needed a way to quickly hop from one level to another mid-game, and whilst reworking the starsprites, I needed a way to quickly give myself more starlight. The obvious answer to both of these problems was the addition of a developer console! It’s perfectly simple: it just takes basic commands like “add_starlight(50)” and responds accordingly. We obviously won’t give the player access to this in the final game, but we might consider making it available in the demo.

And that, at long last, brings us back to the demo, which was supposed to be the primary focus of this blog post – although I guess it’s no bad thing that I had so much to write about in terms of progress!

This week, Chelsey and I both got into the game ‘Pizza Tower’ (which is great fun, by the way, even though Chelsey completed it whilst I only just managed to defeat Pepperman, after an embarrassingly high number of deaths), and I did some reading on its development. I never even heard of Pizza Tower until about a week before its release, so I never followed its five-year development. What really stood out to me was how early McPig released the game’s first demo build, and it made me think about how long we’ve been working on our game now with no opportunity for anyone to try it out and share their thoughts on it but ourselves.

Although we’ve been lucky enough to receive lots of feedback and ideas on our game on the basis of all our screenshots, videos and concept art, the fact that no one has played our game besides us means that no one actually knows how it feels to play, and that’s a risk, because for all we know it might be completely rubbish and we might be wasting months of lives going down the wrong path with things! The only way we’re going to know is if we get other people trying it out, and that means releasing some kind of demo.

And so that’s my focus now: breaking down what needs to be done in order to prepare a presentable, objective-driven demo. I’ve started putting together a list of things I believe ought to be done before it’s worth anyone else trying to play it, such as more enemy types, improved combat, starsprite powers, and a basic objectives system. The main thing is to introduce just enough variety into the demo that players can experience a handful of the core mechanics, even if the demo only takes about five minutes to complete. If I can achieve that in the next three to six months, we’ll have our first demo out by the end of the year.

The hardest part of that will probably be the game’s combat system, which we still don’t really have any concrete plans for, aside from wanting starsprites to be a major part of it, and wanting it to feel dynamic and fast-paced, and so that – alongside adding more enemy archetypes on which to try it out on – will most likely be my next priority as we head into the second half of 2024.

The objectives of the demo will be simple. Something like: defeat five enemies; scan five enemies to add them to the codex; free all the starsprites; locate all the hidden eggs. The idea is just that, by breaking the demo down into objectives like this, we’ll be able to ask players what they think about each individual aspect of the game and see which parts they like most, versus those which think need improvement, or simply don’t enjoy at all. We’re really keen now to start finding out what people think of what we’ve developed, so hopefully we’ll be in a position to release such a demo soon!

Until that time comes, we thank you very much for sticking with us this far. I’m well aware that this game isn’t happening quickly and that there are so many other things vying for your attention, but we’d both be so gutted for people to lose interest because they think we aren’t putting out enough content and updates, and so we’re so grateful that that hasn’t been the case for so many. As always, keep an eye on our social media feeds and Discord server for updates, and don’t forget that you can get even more frequent and in-depth updates – including my day-by-day development diaries – either by subscribing to us on Patreon, or boosting us on Discord.

Until next time, take care!