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.

Hello everyone! I'm excited to tell you that Squillamorph now has a Steam store page! That means you can now add it to your wishlist! I can't wait to get the game out there for you all to play and I hope you are excited about it too.

As I've already mentioned, the Steam store page is now live! Go add the game to your wishlist and tell your friends about it too! I am ecstatic about this as it is one of the final steps before the Early Access launch. I also now have a launch date! The soonest I am able to release it is Sunday the 17th of November, so that's when I plan to. I know it is slightly later than I've been saying, so I apologise for that. Nonetheless, I hope you are as excited as me for the Early Access release!

The first update I want to talk about first is to the local leaderboard. The plan is to convert it to a Steam leaderboard, but this will happen some time after the Early Access launch. Until then, it will remain a personal local leaderboard. At EGX, the leaderboard showed progress by percentage, total play time, and total points gained. The board was sorted by the completion percentage, showing players who got further through the game first. However, as more levels will be added over time, this sorting method isn't preferrable. So the leaderboard will now be sorted by points, and percentage complete will become region reached. This will display the initials of the region the player got to, i.e. 'Waste Processors' becomes 'WP'. I have also removed total play time for now. The total number of view-able leaderboard entries has increased as there is now a scrollbar for the leaderboard on the menu.

In regards to region names, I realised that I never state the name of the regions in the game. So, I've added an intro screen that appears when the player enters a new region. I think it does the job of introducing a new region quite nicely. I might add a few extra bits to the intro as time goes on but I like its simplicity for now.

The rest of the past week's updates were mostly optimisations, bug fixes and improvements. I also rewrote the leaderboard saving method to fit in with the same saving and encryption method as the player data, which I discussed last week.

I wanted to show a couple of new level designs since it has been a while since I showed any. This is what all levels look like when I am designing them in Photoshop. I've created a couple more preliminary designs along with these but I didn't want to show them yet. It's important to note that these levels are not guaranteed to be in the game at launch. These levels are for the Reactor K region and will feature the Kobold enemy type. Designing them was a refreshing break from the tweaks, tests, and improvements I've been doing recently. I can't remember discussing much of the process of how I design a region for the game, so this seems like a good opportunity to.

Before I create a new region, I'll make the enemy that inhabits it. Depending on its abilities, this can take as long as making a boss but is usually much faster. Earlier in development, I made a rough design for almost every level in the game. I'll take the rough of the level I want to make and detail it out, taking gameplay mechanics into consideration. Once transferred into the game, I then test it to find and fix any obvious design flaws. Once all of the levels of a region are in the game, I'll test them in sequence to find remaining bugs or unintended choke points. Then it's time for the boss level, which takes the longest to finish because I need to create the boss for it. Then it's a case of repeatedly playing through the region until I get rid of all the bugs I can find and feel as if it is fun to play and replay. I'll add in scenery assets and make region specific assets throughout the process.

Last of all, I implement the mutagen upgrades and the reward level that is found at the end of the region. I usually do this once I start work on the next sequential region as that is where the upgrades have the most impact.
So that's a brief insight into how I develop a region for the game. I hope you found it interesting!

That's it for this week's post! Don't forget to wishlist the game on Steam! Stay tuned for more exciting updates!

​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! It won't be long now before Squillamorph launches on Steam Early Access. I've been working hard over the past week to get the game ready for it. Keep an eye out on social media, as I'll have the Steam page done very soon.

The main focus of the past week has been on implementing the feedback I gathered at EGX. A lot of the changes are for balance reasons. One of the most prominent balancing issues was a combination of two mutagen upgrades. The dash cooldown reduction and kill enemy on ejection mutagens allowed players to farm enemies for points, as they spawned in. This meant that not only was there no threat of the player dying, as the enemies had no time to attack, but they could very quickly build up points. While I really enjoyed seeing players discover this, I do not want it to be as powerful as it is. To make it less rewarding, I've decreased the number of points the ejection kills give from 100 to 10. If it turns out that it is still too strong I will tweak it again.

There are many other tweaks, and a lot of optimisations. I've removed the preview video/GIF from the main menu, something which was there just for EGX. I find it funny that doing this reduced the size of the build to 1/3rd of its previous size. I also profiled the game, trying to find the most performance taxing elements. I expected it to be the ray-casting done by the physics objects, which I still intend to optimise. To my surprise, it wasn't. The biggest drain on performance is the lighting, which is unfortunate because there is not much I can do to improve it except remove the lights. I will look into more solutions for this a bit later down the line. Maybe some quality setting options are needed.

After the optimisations, I tested the game on my old laptop again. The game ran much better on it this time and this means I have an estimated minimum spec that can run the game, which is required for the Steam page. I expect some lower spec systems will be able to run the game but I cannot currently confirm this. I will be working to get the minimum requirements lower, but probably not before the Early Access launch.

Something I've been meaning to do for a while is work on the way I handle save data. Until now, I have used a method that saves data to JSON text files. This method works really well and I use it for both player saves and the local leaderboard. However, it is incredibly easy to edit the files and cheat the game. So I decided to find a more secure way of saving data. The easiest option was to switch to a binary format, which makes it slightly harder to edit the files. Doing this made me realise how badly I'd implemented the previous saving method. It relied on so many different scripts to function and took ages to unravel. So I've made sure that the new method is much cleaner and easier to alter. It took some iteration, but I got it working nicely.

The new method is slightly harder to cheat with. Even so, I knew it wouldn't be too hard to edit the files after a bit of research. This prompted me to look into file encryption. I did not expect this to be quite as complicated as it is. After a ton of research, and confusing myself to no end, I found a simpler method that I understood and implemented. Now it requires much more effort and research to cheat the game, which I hope puts most players off.

After tweaking their attack fire rate, I decided it was time for another variation of the Kobold. There is already a tank variation, so I thought a weak variant was needed. The upside of this variant is the fire rate, which is considerably faster than the other two variations. This makes it a harder enemy to deal with but it is fun to infest.

I've tweaked a few things to do with the big crushers in the Flopalodon boss room. They were the main source of bugs in the EGX demo. The most visual but bizarre bug was to do with their collision, which caused the player to be crushed when they weren't touching them or near them. Turns out this was because the player was able to move their colliders without visually colliding. A simple changed of a few parameters on the crushers fixed this. I also had to change the way their animation worked as they got stuck in a loop if the player failed to crush the boss. Hopefully, they will work properly now!

There is now a particle effect on active vents, similar to the one used for the level exits. This was added mostly because some players couldn't tell if a vent was active. I have also increased the size of the level exit effect as players did not notice it activating before. Fingers crossed that both of these will be more noticeable now!

That's it for this post. I hope you are excited for the Early Access launch! This week I will be doing more preparations for it and maybe add some new levels. I might have a solid launch date by next week, so stay tuned!

​​​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!