What is Squillamorph?
Get the game on Steam Early Access!
Join the official Squillamorph Discord: Squillamorph Discord Server
Below is the development log for Squillamorph. It is GIF heavy and it might take a while to load them all.
Hey everyone, it's been another week of good progress! I've mainly focused on getting the tutorial level working properly. I did do some documentation again but as I've been talking about that a lot over the last two posts I won't be talking about it in this one.
While I haven't spent much time on this, I have added some minor additions that should help teach the player how to play. I've done quite a lot of research into tutorial methods now. What I found is that making a good tutorial hinges on finding the balance between direct instruction and player discovery. I've decided to only show the player how to use the basic mechanics and then let them experiment with them to discover how best to use them, at least until I get some feedback on this. Another aspect of the tutorial that I'm going to push is mechanic reinforcement, which ties into the previous point. Once taught a mechanic, I force the player into a situation where they must use it multiple times to progress so that they can get used to it. I cannot say whether this actually works, but I am fairly confident it will.
You can see it in the above GIF, but I should probably mention that I've made the 'Helix' dash cooldown effect more noticeable. Now, instead of just the player's edge colour changing to white, the whole character changes colour. I'm not sure if it will stay as a white colour but it makes the cooldown a lot clearer either way.
In the last post, I mentioned that I would work on some more level designs. I've managed to get an initial design for the Flop Shark tutorial level. However, I'm still working on getting this setup so it isn't ready to show yet. I expect there will be something to show in the next post though!
I thought it was about time that I work on the combat. The first thing I added was a stun effect. This was very easy to add and should prove fun to use in combat. However, it will need thorough testing once fully implemented to ensure it isn't overpowered. Then I added in functionality for a skill element in the combat. Every third player attack will deal double damage. I don't have a proper indication of the skill attack yet so I've added a placeholder effect for now. While adding this skill element sounds simple, I ended up overhauling the combat system I've also added a more evident particle effect to the enemies for when they take damage and it looks much more satisfying. In addition to this, I've added a freeze frame effect for extra satisfaction. This only triggers on skill attack hits and enemy deaths so it isn't overused.
Now because I was working on the tutorial, I had to teach the player how to use the Test Dummy enemy. When I tested this for the first time after making changes to the combat, some bad bugs happened. These bugs were much worse than those I mentioned in the last post. Making the aforementioned combat changes completely broke them. So, I spent a day ironing out as many of their issues as I could. The most frustrating issue was the joust problem where they get stuck in the ability state, moving around uselessly. It took me hours to find that a single line of code meant all of the joust ability logic was ignored. Needless to say, I was very irritated by this but pleased I had finally fixed it. In an effort to make my life easier in future, I cleaned up the Test Dummy script. Thanks to the combat system changes I was able to remove a substantial amount of code from the script.
Something I've wanted to have in the game for a while now is better control over time. I wanted to have a system that allows me to control the speed of time for individual elements of the game. So, I attempted to make it this week. However, I had not done any research into this sort of system and as a result I failed to make it work. I then did some research into it and discovered how hard to make and unnecessary this type of system is. In short, I've scrapped this system and instead created one that gives me a bit more control over Unity's time system, which has more than enough functionality. Anyway, it was a good lesson learned.
That's it for this post! The next one might be slightly different because I'd like to start doing video development logs. These would be monthly video updates to go along with these weekly posts. However, I cannot confirm that this will happen next week but you can look forward to this, or at least something like it, happening in the future at some point! Anyway, thanks for reading!
Hello everyone, I hope you had all had good Easter! It has been another good week for progress. Again, last week was mostly spent on improving the level designer and documentation but this is now pretty much complete. I won't talk about this much because I covered it in the last post.
One of the documents I worked on was a world guide. This is basically an aid for anyone designing a level. It describes each region of the game world, including information like enemy types and environmental hazards. One of its main purposes is to list the layout of levels within regions. The layout we now have might change, depending on player feedback. Each region will start with a mini level to give players the chance to get used to a new enemy type without the wave based combat. From this level you can access 3 different level pathways. Each pathway corresponds to a difficulty. We're not yet sure if players will be able to switch between the pathways once one is chosen. Again, that will need testing. Of course, each region will have a boss level at the end of the pathways. Bosses will have difficulty levels that correspond to the pathway taken by the player.
I've made a new design for the tutorial level! This is entirely based on feedback I got at Rezzed and research I've done into tutorial methods. I'm quite pleased with how its turned out so far. It definitely needs tweaking but I'm on the right track now. Something new that I've added in to make this new tutorial is destructible objects. These objects can only be destroyed by player attacks at the moment. I will be using these objects sparingly because they can cause problems if overused. This is because I am not using my physics system for them. Instead, they use Unity rigidbodies so that they appear more dynamic; my system does not allow for rotating collision shapes. Another issue with my system is that my physics objects cannot push rigidbodies, but can be pushed by them. This means that I've had situations where enemies have been pushed into the floor and get stuck. While they are a cool addition, they will not be appearing too often. Also, it's probably important to note that I've added in a new wall jump ability, applied with a mutagen pick-up! This was something heavily requested at Rezzed.
Since redesigning the tutorial, and implementing the destructible objects, I have noticed several problems with the Test Dummy enemy. I won't lie, I did throw them together rather hastily so I knew there would be some issues. To get the destructible objects working, I had to change the way combat worked. This is now a much better system but it exposed so many faults in my enemy systems. Sometimes, a dummy will continue to deal damage even after an attack. Other times, they get stuck in their jousting state, unable to follow the player like normal but also unable to deal damage. I haven't had the chance to fix all these issues but I am very tempted to remake them again, given how janky they are!
In regards to the enemy combat, I have started to improve this. Enemy attacks now use a hitbox collider, rather than distance based checks. This is a much needed improvement as it gives me more control over attack shapes. We also intend to make the attack animations much more dynamic so that we can better indicate enemy attacks.
I'm going to be working on a few combat improvements and level designs this week. Hopefully, I'll have some interesting stuff to show in the next post! Thanks for reading!
Hello everyone! There isn't much to show in this week's post because all of the work I've done is on the level designer and documentation. Anyway, as the title suggests, I will be doing the development logs on Mondays now.
I've been working really hard to improve the documentation for the game. Mainly, I've been making documents that allow anyone on the team to create art assets and design levels. It also allows me to double check how to use the level designer if I forget how to use it (I know I made it but this did happen). Not going to write much about this as there isn't much to it! There's also nothing visually interesting about it to show, but I thought I'd briefly talk about it anyway.
I've spent most of my time this week improving this, so that it is much easier to use. The level design process starts with designing a level in Photoshop, where one pixel equates to one tile. The image is then put in the designer Unity project and translated into tiles. This is done with a script that assigns a colour to each tile, reads the colours of pixels in the image, and places tiles in the scene based on it. Then I render the level and the normal map of the level from Unity to a PNG. I talked about this before but didn't cover the full process.
This used to be a laborious process. Each art asset had a single Photoshop file; to render both a colour image and normal map, I would have to edit each art asset file to switch between the green colour and normal map versions of them. Then I had to switch between cameras, one for the colour image and one for the normal map. I also had to change the output file name on the render script to match which image was being rendered. This process caused me to make many errors that cost so much time. Not only that but I have to do this for each layer of the scene; foreground, background, and any parallax layers.
I have now got this process working with a single button press and without having to edit any art asset files. It is so much faster and easier to use. Now the only time consuming part of it is making new art assets that work with it. Each art asset needs a green colour version and a normal map version saved separately. Then a material needs to be made for the asset which takes in both these images. The shader for this material allows me to switch between the normal map and colour image whenever I need to. That is how I am able to render out each layer, with both normal and colour images, using a single button press. The process is shown in the above GIF; it cycles through each layer, switching between the green colour and normal map, of each asset material, and renders both. It has taken all week to get it working properly, but it was worth it.
The only thing I still have to do for the level designer is implement the background assets I showed last week. These are currently added in the final level scenes and, as there are lots of sprites in one space, it ends up making a mess of them. I would also like to make background 'machine' prefabs, so we don't have to build as many new 'machines' out of the small background assets for each level.
It's not as lengthy as the last one but I think I covered everything in this post! There might be some new level designs, or redesigns, to show in the next post. I'll be working on finishing the level designer and some tutorial related things this week so we'll see what happens. Thanks for reading!
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 very soon. Stay tuned for updates!