Hello everyone! Thank you for the support and feedback! I've been working hard over the last week to make necessary improvements and fixes. This culminated with the first game update, which went live last Friday!
​Get the game on Steam now!
You can look at the changelog to see what was updated.

I didn't particularly want to have moments of invincibility/invulnerability in the game. Mostly because I didn't want to reduce the brutality of the game by using it. However, the majority of player feedback talked about how unfair things can be when dying after spawning or ejecting without a chance to do anything about it. I've become quite blind to this sort of thing in testing, but I started looking for it after seeing the feedback. I found that the need for it after spawning varies from level to level, but there are many situations where I was killed immediately after ejecting from an enemy. This was not fun and I realised that adding invulnerability would greatly improve the quality of gameplay. There are now brief periods of invulnerability after both spawning and ejecting from an enemy, represented by the flashing blue colour. It might need to last longer but I'm trying out a shorter period of invincibility for now.

In response to player feedback at launch, and my own desire to improve performance, I focused heavily on optimisation last week. The biggest area to tackle was reducing the impact of the graphics. I couldn't do too much for the low quality setting in this regard, apart from disabling more lights. However, the medium and high settings both have a layer of sprites in the background. This layer is made up of large panels of normal mapped sprites just to add a bit of interest to the dark background, which I wrote about in a previous post. This was exceedingly bad for performance because each sprite has to be rendered as many times as there are lights affecting it, and there can be a lot of lights.

I tried placing the panel sprites within a single quad using a shader and a colour pixel 'map' I made for placement positions, but I couldn't get it working. The only solution was to turn the square of individual sprites into an image, but this would take ages if I did it in Photoshop as I have to place both the colour and normal maps of the panel sprites in the same places. Then I remembered my old custom level editor and realised I could use the image rendering script from it. With that, I was able to place the panels in the same way as normal and render out both green colour and normal map images. That's it, now the background is made up of a single quad mesh. The performance toll from graphics was nearly halved by making this change. Excellent stuff!

I've also made another significant change to the structure of physics objects and creatures. I read an interesting article on the Unity blog and decided to give the manager system describe within it a go. All physics objects scripts are now managed by a single manager script and all creature scripts are managed by another manager script. I'll be honest, it did not make a massive difference but it did improve things slightly. I saw more of an improvement by optimising the way physics object check for collision, but it was an interesting test nonetheless.

While making the update and looking at player feedback, I started thinking about the effectiveness of the mutagen upgrades. After each boss, there is a room containing 3 mutagen upgrades. Players can only choose one, and when testing I always choose the dash cooldown upgrade at the end of tutorial. This was a mistake on my part. I recently tried testing the game with the other dash upgrades found there and found the difficulty increased dramatically without the shorter cooldown. This means that giving the player a choice of upgrades, while great for replay-ability, might actually be hindering some player experiences. 

So I plan to take the choice away, giving players only one mutagen after each boss. However, I still want players to be able to get the other mutagen upgrades that are currently implemented. I already had an idea for this, which would have been for mutagens not found in the choice rooms. Mutagen upgrade machines will be found within levels but are only usable after a certain wave of enemies. This should add a new fun but optional element of challenge to the game! Nevertheless, I do like the element of choice regarding the upgrades. To keep this a part of the upgrade system, I plan to limit the number of mutagens the player can have active at once. This means I will be making a menu system for them, perhaps something inspired by the charm system in Hollow Knight. We shall soon see how this develops!

To finish up, I'll tell you what I'll be focusing on over the next week:
- Finishing up the 'Reactor K' region and the Kragon boss is a high priority.
- Improving the mutagen upgrade system will take time to get right but is something I want to start on.
- I am also still working on optimisation as a priority.

​I hope you enjoyed today's post! ​Thanks for reading!

Get Squillamorph on Steam!

Join the official Squillamorph Discord server here: 
- Discord Server
​Follow Squillamorph on:
- Twitter
- Instagram
- Facebook
Tell your friends to check out the game too!

Hello everyone! The game is now out on Steam Early Access! I am so excited about the launch and I hope those of you who get the game enjoy it as much as I enjoy making it!

The game launched on Steam Early Access on the 17th of November and I am so excited about it! I was making last minute improvements right up until the moment I launched it to iron out as many issues I could find. As a sole developer, managing all aspects of my business and developing the game can be quite challenging at times. However, this just makes it that much more rewarding to see everything come together into a launch.

There were a few things I needed to add and change before launching. I had forgotten that the tutorials I made for controllers were specific to Xbox controllers. For the images this doesn't matter too much as most controllers have similar layouts. However, the text tutorials had to change. This proved to be more challenging to implement than I thought but I've got it working. The button text will now be replaced according to the name of the buttons on the controller in use. This is one of the main visual changes I made. However, perhaps the most noteworthy change is something no one would notice if I didn't mention it. The next few paragraphs are quite technical, so feel free to skip them if you aren't interested.

I discovered something last week that intrigued me. While researching how to build the game to ship it, I learned about a thing called IL2CPP. If you are interested in a full description of it find it in the Unity documentation. IL2CPP (Intermediate Language To C++) is a Unity-developed scripting backend that converts IL code from scripts and assemblies to C++. The main benefits of using it, rather than the default option, are performance, security, and platform compatibility. I switched to it just to see if I could and discovered that the game worked just fine. However, there was a small problem I had after implementing something recommended by Steam.

One of the things Steam recommends to developers is to pause the game when a player opens the steam overlay. This can only be done using the Steamworks API. To get this API in Unity I use Steamworks.NET. This is fantastic and it's relatively easy to integrate into Unity games. However, it does not work with IL2CPP. Rather than take the easy way out and use the default scripting backend, I decided to search for a solution. After scouring the internet, I eventually found a solution in a GitHub issue thread. It wasn't easy for me to get this working but I managed to in the end. In hindsight, I maybe wouldn't have spent as much time on it and just stuck with a little less security, performance, etc. In the long run it should be worth it though.

My main priority is currently optimisation. The more computers that can run the game, the better. I've discussed the main performance issues a lot recently, the main perpetrator being the lighting, and how I added quality settings to combat this. Even so, I still haven't properly optimised the game. Secondly, there are several improvements I need to make to certain gameplay elements. Making infesting slightly easier, preventing several unfair situations from occurring so often, and a few other bug fixes.

There's a lot to do but I'm doing my best to get it done! If you play the game and have any issues, please let me know. Either send me a message on social media or join the Discord server and let me know there.

That's it for this post! If you get the game, I hope you enjoy it! Thanks for reading!

Get Squillamorph on Steam!
​Follow Squillamorph on Twitter, Instagram, and Facebook to stay updated.
Join the official Squillamorph Discord server here: Discord Server
Don't forget to tell your friends to check out the game too!

Hello everyone! I'm in the final stages of development before the Early Access launch and I'm very excited about it! Over the past week, I've been focused on getting the last few things done before the launch.

There are a couple of changes I wanted to make to the game before I stop adding features for the Early Access launch. The first is something that I hope fulfils a bit of feedback I got from EGX; the Flop Shark attacks aren't really noticeable. What I've done is display an attack sprite whenever they attack, just like the Flopalodon does. They already had the ability to do this but only if infested and only every third attack, which I call the 'skill' attack and it does more damage. The 'skill' attack effect is now displayed with a white colour instead of red. I still need to do more to improve the 'skill' attack idea. Anyway, I think the attacks are now a bit clearer.

Talking of attacks, I've improved the Flopalodon's fire breathing attack. This was something else I've needed to do since EGX. There wasn't a clear enough indication that the boss was going to do this attack. I think I've come up with a visual solution that works quite well. As well as the mouth slowly opening, there are now particles that get drawn into its mouth and a glow which builds up before the attack. I am much happier with this part of the Flopalodon fight now that this attack is improved.

To get as much as I can into the Early Access launch version, I've added one of the Reactor K levels I showed last week. It's gone through a few changes since the initial design but I've really enjoyed testing this one. It is a challenging environment but fun to fight the Kobolds in! This brings the Reactor K reagion to about 50% complete in terms of levels, which I am happy to have reached for the Early Access launch.

I've done quite a few optimisations over the last week. This was mostly because I was, and I still am, concerned about how many people will be able to play the game. Ideally, most specifications of PC will be able to run the game but I cannot guarantee it. To take a step towards this, I've added some quality options in the settings menu. They are very simple and don't affect that much for now, just disabling certain lights and background scenery elements. However, this makes a big difference to performance in high impact situations where there are lots of enemies. I think I mentioned the impact the lighting has on performance in a recent post. Either way, disabling the main lights really improves things for me. Although great for performance, I didn't want lights to be disabled by default because the lighting is a major part of the visual style. So I found that adding quality options was the clearest solution. I hope they'll make a difference!

The past couple of days have presented an interesting issue to me. I was testing a build of the game on a different device to my development PC when I noticed something strange. The colours of gameobjects that use my colour palette shader weren't displayed correctly, which you can see in the above image. This isn't the first time I've seen the problem. The PCs I've used for the game at events ran the game using the integrated GPU by default, which also produced this issue. After some research, I discovered what I believe is the source of the problem. The device I was using uses OpenGL for graphics, whereas my development PC uses DirectX. For some reason, OpenGL did not like my custom shader and displayed the wrong colours from the palettes. 

Although I've discussed it before, I'll briefly describe how the shader works. Almost every sprite in the game is drawn using a shade of green. The shader then replaces the green colour with a corresponding replacement colour from a colour palette image. You can see an example of a colour palette in the above image. The correct output result is shown underneath the palette. The incorrect output is shown on the left side of the image. Note that I had the quality set to low so there are no lights enabled in these screenshots

Eventually, I realised that the output palette colours were being shifted one shade of green to the right. I still have no idea why this only happens on OpenGL graphics. Even after researching this problem extensively, I could not find a concrete reason for this. Luckily, there are ways to tell shaders what graphics API they are using. So I am now manually correcting the green colour value depending on the graphics. I am still worried that this might create other problems as I do not fully understand the problem. Either way, the game is unlikely to run well on platforms that use OpenGL in its current state but I am not sure. I still have plenty of optimisations to do.