Almost Ready

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.

---

Attacks & Other Additions

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.

---

Options & Optimisations

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!

---

Trials & Tribulations

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.

---

That's it for this week's post! If everything goes as planned this week, the next post might be a bit different, but we shall see what happens. Thanks for reading!

Don't forget to wishlist the game 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!