Thought I'd update you. I recovered the project files! Took some digging but I found out how to restore them. I can't tell you how relieved I am. I can't do the real update now as I have run out of day and the build still doesn't work but hey, I've got the assets back!
Hey everyone, sorry about missing a post last week. Just didn't get time to write one up properly. Anyway, there was going to be lots of cool things to talk about in this post but something rather depressing happened today. It seems to be my fault and something to learn from but it still sucks.
The Squillamorph Unity project has corrupted. I transport it around on a hard drive, which is always a risk, but luckily the rest of the files on it are fine. I really don't understand how or why it happened. I tried to load the project up today and was presented with a bunch of errors. Upon further inspection it seems that half of the game files are gone without any reason. If any of you have experienced this before with Unity please let me know. I also had a build I made last week which I was going to extract some things from but turns out that has also corrupted, no idea why.
Luckily, I did make a backup after the last post. So all of the performance changes I previously made are intact within that. I think I will attempt to move the project to a cloud based system so that I don't have to worry about the hard drive being responsible. To the game developers amongst you, I cannot stress how important it is to backup your work on a regular basis.
I apologise for this unexpected interruption to the development log but there isn't much I can do about it. I was going to show you a GIF of the build but it turns out that is also corrupted. Hopefully, I'll have more to show next week!
It’s a new year, woop! Sorry I missed a post last Sunday, I’ve been really busy. Nevertheless, I've got lots of interesting things to discuss!
Level Images & Colour Palettes
Firstly, I've made some small changes to the overall colour in the level by making the background slightly lighter. I decided that we need a method of creating the levels that gives us more control. The tilemap system is fantastic for actually building the levels with but I would like to be able to change the colours of tile sprites without replacing them. Sometimes I have also found myself wanting to edit the tile sprites in way that isn't possible, for example putting a big claw slash through them. I could of course do this with an additional slash sprite but I came up with a more direct approach. I found a way to 'render' the entire level to an image. I am only able to do this because the level is small enough to fit in an image smaller than 8192 pixels, Unity's largest image size. Now I will admit that these images do increase the file size of the project quite drastically. If this becomes an issue then I will have to find another solution.
The system works by making the level in a separate scene using tilemaps, sprites and image effects. I then have a camera set to exactly the size of the level which outputs to a render texture. A script then saves the render texture to a png file. I can then edit the final image as I like in Photoshop before putting it back into the game. What makes this system even better is a simple shader I've created to use a switchable colour palette. This means that all sprites to be included in this system must be drawn in green colours as this is the colour value the shader uses to replace colours. You can see an example palette above, the green upper row is the palette we use to draw in and the lower row is what the green colour is swapped for. This process has to be repeated for each layer of scene we want including parallax layers and normal maps.
I don't think I've discussed this for a long time. Up until this point there have been many stutters in the game's framerate, I'll discuss this later. This has bad repercussions for my physics objects system. The collision is done in a way I've seen before many times. I use raycasting to detect colliders upon colliding with I then stop the velocity and set the position of the object. This works quite well. However, when moving at fast speeds or encountering the stutters, the raycasts can miss for one frame allowing the object to move inside any collider. Then occurs the issue of multiple raycasts in different directions detecting a collider at the same time. All the code to set the velocity and positions triggers and ends up conflicting and the object travels quite quickly through the solid obstacle. I have tried many things to fix this but to no avail.
Then the other day, I had a brainwave. Surprisingly I never found this solution online despite my desperate searching. I have now changed my raycasts to go further than the edge of the object so that I can store a position to jump back to if the object ends up inside a collider. There are also a few more checks to see if there are any conflicts but no more raycasts than I already had. I now have absolutely no objects which go through walls, that aren't programmed to anyway. Now we move onto the thing that has caused me much annoyance.
Here we go again. I know I've continuously talked about this but I think I'm finally getting somewhere. As you may know, the game has some performance issues ranging from not bad to severe. I've had to use the profiler to try and find the source of the issues as I have no idea what is causing them. It has been so confusing. One day it's one thing causing issues, the next it's something else entirely. Although I still cannot work out the cause of the main stutters I have drastically improved performance. I reduced the number of raycasts I use by optimising the collision method; I also discovered that one of my cameras, the one for the shadow layer, was one of the main constant perpetrators. See the spiked section on the right of the above image? That was when the shadow camera was turned on... so yeah, that's gone now.
All in all the game now runs near perfectly on my computer. However, I am yet to test it on my old laptop which will actually tell me if performance is better yet.
One of the things I tried to overcome in the last week when fixing the collision was making the sharks collide. Annoyingly I can't currently do that because each shark would have to be on a separate layer otherwise each segment of the shark would collide with each other and bad things would happen. So what I have done is made the sharks push each other away. This actually works really well for combat. To attack another shark the player must move close enough to be pushed away which makes fights much more fun. I've also added in slow motion and a reduced cool down time for the dash after being kicked out of the infest mode to make combat more exciting. If you manually leave a creature you don't get the slow motion otherwise it would be slightly overpowered as the gameplay currently stands.
I hope you liked this week's update! There shouldn't be any more long gaps in the updates. In the next update I should have more combat mechanics and possibly a new level, or something like that.
I'm the game developer for Squillamorph! I'll post here on the devlog as often as I can.