What is Squillamorph?
Squillamorph is a 2D pixel art platformer. Gameplay consists of wave-based survival action, with the player fighting off a range of interesting and dynamic enemies. The player controls a small parasitic creature with the ability to 'infest' enemies, taking complete control of them. Find more information about the game on the About page.
Below is the development log for Squillamorph. It is GIF heavy and it might take a while to load them all.
Below is the development log for Squillamorph. It is GIF heavy and it might take a while to load them all.
Hello everyone! Over the past week, I've been hard at work on the next boss. It has a long way to go yet, but I hope you enjoy seeing the first bit of progress on it.
The boss for the Reactor K region is based on the boss that was in the proof of concept demo. The boss was designed to be similar to the much smaller Root-Toot enemy, which was the predecessor of the Kobold. At the time, I did not have an official name for the boss but referred to it as the dragon. As I am remaking it, I have come up with an actual name. It might still change but for now it is called the Kragon. At the time I could only give it one attack, which you can see in the GIF above. It was quite a complex fight though. To defeat it, the player would have to infest a spot on its back, which they could only do when launched out of a vent while the boss was shooting. The new boss fight will not be like this due to the number of players who struggled to understand the original.
A Big Kobold
The boss is essentially a big Kobold, in the same way the Flopalodon is a big Flop Shark. This means I had a good base to start building the boss from. However, I found it particularly difficult to get the core things setup. This was partly due to me forgetting how my boss template works, and partly due to several challenges I had making a larger humanoid. I had big trouble with positioning the body parts in the right places. For some reason, they kept wanting to be in very different positions to the ones I specified. It felt more challenging than it should have but I finally managed to get the essentials setup and working.
It is difficult to put the body parts in the right places without having artwork, so this had to become a priority. I have not done the artwork for a boss before, Connor made the sprites for the Flopalodon and the original dragon boss. Things were made easier because I could use the old sprites as a base but they still needed to be reworked to fit the new art style. Even so, certain parts had to be completely redone, such as the legs. The sprites are not finished yet, I haven't even begun altering the head, but I am pleased with the direction they are going in.
Some Legwork Required
I have previously discussed that the legs of the Kobold are a big challenge to get working; I still need to work on the leg movement for humanoids. To get the same leg style for the Kragon, I simply took the Kobold leg code and scaled it up a bit. This worked perfectly, but it wasn't a good thing. Making the legs bigger exposed the problems with them. Limbs with one joint, the Flop Sharks arms for example, are relatively easy for me to make. When another is added, it gets more complicated. Unlike most other parts of the creatures, the knee and elbow joints are not physics objects. This means I can't connect them in the same way as everything else. For the Kobold's legs I came up with some position calculations that worked well enough. There is some stretching that occurs but it looks alright. This didn't work for the Kragon, so I started again from scratch.
I've made some new calculations that mean the legs cannot stretch apart and it looks so much better. I am very pleased with the new method, which I will probably start using with the Kobold. However, doing this created a new problem to solve, The legs will appear further than the feet at times, meaning that when the feet are on the floor the legs will be well into the floor. It took me a while to work out a solution to this problem. I had to draw some diagrams to get my head around it. The solution does create a tiny bit of stretching in the leg if the foot becomes too close to the hip, but it works well enough. So that's one leg issue solved; the next is making the boss look as though it is able to support its weight by positioning the feet properly.
That's it for this post! I know the content wasn't as varied as normal but the Kragon took up most of my development time this week. Nevertheless, I hope you enjoyed seeing the recent progress!
Follow Squillamorph on Twitter, Instagram, and Facebook to stay updated. Don't forget to tell your friends to check out the game too!
Hey everyone! I've made some decent progress over the last week! This week's post contains piles of rubbish, a Kobold variation, and more ways for the player to die.
I thought it was about time to give the Waste Processor region a bit of beautification. Until now, the levels in this region have just used the base scenery assets, which are designed to be used in any level. This looked good but I felt the level needed more thematic elements. Seeing as this region is supposed to be a waste processing centre, I needed to make some trash related assets and machines to process it. I did some research into real waste processing facilities. This gave me a ton of reference and inspiration as to what I should create. This past week, I have managed to make multiple trash/rubble piles and chunks that I have placed throughout the levels. I have also made a couple of machine sprites to make the piles of rubbish make sense. I find that the new assets improve the level aesthetics and lend to the atmosphere of the levels.
I found these assets fun to make but very challenging to normal map. I don't think I've talked about normal mapping for ages. The last time I talked about it I'm sure I mentioned that the normal maps have to be drawn by hand to get the crisp lighting on the pixel art. Usually, I don't find it too difficult because most of the scenery is mechanical and uses straight angles. However, a pile of rubbish is a mess and uses all sorts of angles. To normal map these assets, I attempt to make sense of the obvious edges and block shapes. Then I basically make a mess of the normal map for the rest of the asset to add some randomness. However, I still have take into account the direction that light will hit or the piles won't look right. They have definitely been the most challenging assets to normal map so far, but I'm sure I'll have need for something just as challenging in the future!
My focus has now shifted towards the Kobold enemy and levels. I have made some good progress on these elements. The first thing I decided to do was to create a HUD animation for them. I found this animation much harder to work on than I did the Test Dummy animation, which is the first HUD animation I worked on. I think this is because the Kobold HUD symbol is slightly more complex. It took a lot of tweaking and testing but I believe I ended up with a decent transition.
Having become used to the varied gameplay of the Flop Shark and its variations, I found the one Kobold enemy much less interesting while testing. So I made it a priority to make the first variation of it. While it is not drastically different, I have made a tank variant of the Kobold. I think I might revisit the sprites to alter them further than I have, to make them feel more robust, but I like the colour difference. The only mechanical differences are the increased health and lower damage output. Just adding the one variation has improved the Kobold gameplay to no end. I look forward to creating more variations of the enemies.
I have managed to implement the environment hazard for the Reactor K region, the Kobold levels, this week. As I mentioned last week, this hazard is the cold pipes, which will slow and freeze the player on contact. This took some time because I had to consider the difficulty this could add to the levels; the Kobold gameplay is already quite challenging. I got it setup so that the pipes would slow the player down but they could escape with the dash. However, this was proving too easy to avoid compared to the previous region's hot pipes hazard. So I made it that the player cannot dash while being slowed/frozen. I think it still needs a bit of tweaking, but it is good enough for now and adds another interesting dynamic to the Kobold gameplay.
Hello everyone, I hope you've been enjoying the last little bit of the summer holidays, or just enjoying the last bit of August in general! I've been busy making lots of progress on Squillamorph, adding features and fixing issues.
If you missed last week's megapost, I looked back at the first year of development. If you want to see how the game has developed, you can find it here!
I've started working on the next region of the game, Reactor K. This region is home to the Kobold enemy. One of the important updates to the Kobold is the leg movement. Leg movement, or arms for the Flop Sharks, is driven by the feet, or hands. Until now, I'd used the same method the Flop Sharks use for their arms for the Kobold's legs. As you can imagine, this doesn't look right because the legs will 'grip' things above the Kobold. Now though, the Kobold prioritises grip positions below the hips and will only go above them if necessary. I've also improved the feet syncing method to get them to try and move one after the other. I'll admit the leg movement is still not perfect but it looks much better than it did.
As for the new region, you can see the current colour palette I'm using for it in the GIF. Not set on this yet though. There's the beginnings of a new tile-set too, which I've given a scaffolding-like design. The general layout of these levels will contrast to the Flop Shark's; those levels had lots of vertical elements, whereas these will be more horizontal. The environment hazard in these levels also contrasts to the previous one. While the existing hazard is hot pipes, that kill the player on touch, the new one is cold pipes, which will slow/freeze the player on touch. I haven't implemented the effect yet but you can see the beginnings of this hazard in the GIF.
I've recently noticed a dramatic increase in the time it took me to save the project. I was seeing save times of up to 10 minutes. I became quite infuriated, especially when I found no similar issues online. What made it more irritating is that it didn't happen every time. I spent a day trying to find the source, which was more like half a day because of the amount of time wasted saving the project. I discovered that the long save only happened if I pressed play, but was none the wiser to the cause. I took a break to clear my head after a mind numbing period and just before I went back to work, something occurred to me.
I remembered that I force the editor to save two scriptable objects related to the current level data. This only happens if I had entered play-mode. For those interested, the function that lets me do this is EditorUtility.SetDirty(myScriptableObject). Thing is, I don't need this to happen unless I've changed the tile placement for a level. I thought I had made sure it only happened when I specify with a boolean, but apparently not because it happened every time. So I changed it and now it only happens when I specify. Oh boy, the save times are now glorious. It now takes only a couple of seconds to save and even when I need to forcibly save the scriptable objects it only takes a minute or so. The amount of time wasted from this is painful to think about, but at least it won't continue to happen!
You will have seen this enemy if you read through the 1 year megapost last week. For now, I am simply calling it the Spit Fly enemy. This is descriptive of its ability, which I have yet to work on. Everything else is setup though. Interestingly, this is the first enemy that I've created the sprites and animations for. I think I've managed to maintain the visual style of the Kobold and Flop Sharks. Connor did make some Concept art for them early this year, which made the process slightly faster. I've recently finished getting its infest mode working and being able to fly around is a bunch of fun! I also find it really satisfying just to watch them flying around the test level. I think this might be my favourite enemy so far!
Working on this enemy revealed a problem that has been in the game since I added the Flopalodon boss. I found out that the air tiles weren't updating properly for the pathfinder system. As I've described before, my pathfinding system works with a flowmap-like method. I have two 'maps' setup; one for ground based enemies, and one for air based enemies. This meant the issue didn't affect ground based enemies. However, it did affect the Flopalodon boss, which has to use the air map due to its size. I'd been having a bug that caused it to get stuck in a corner of its level. Seeing the behaviour of the Spit Fly made me realise the issue and I've since been able to fix it. Now any air based enemies are free to fly wherever they like!
I'm the game developer for Squillamorph! I'll post here on the devlog as often as I can.
I'm currently looking at an Early Access release this summer. Stay tuned for updates!