This week I delved into properly designing the first main level of the game.
The main idea for the level was already established a while ago by the team and I. The level sits within the foundations of the tower and is the area the Flop Shark creature inhabits. Over time, this region of the tower has become a bit of a trash dump. The small area the level comprises is based around a trash compacter-like machine. I like the idea that everything in the level is centered around this because it gives the level a good theme.
Designing The Level
Having previously attempted to create this level in Unity with the 2D Tilemap system, I decided to design it in Photoshop as I find it quicker. At first I made the level really large as I thought it would make things more interesting. It was only after I translated this into Unity that we realised it was too large. The vastness drew focus away from the main focus of the level which is the trash compactor and just wasn't fun to explore. So I reduced the size of it and tried to put more interest into it. It still needs tweaking but its good to have something more substantial to work with.
The Design System
So to take the image I made in Photoshop and turn it into an in-game level I had to meet several constraints. These constraints are set by me to be used by a script to 'translate' the image; each tile equates to one pixel, air/empty tiles must be drawn with a colour that has a red value of 255 and any pixel that doesn't will be solid. This means I can draw the level in black and white, where white is empty and black is solid. I can use other colours but if the red value is not 255 then it will be a solid tile. I then give the script the level image and the Unity Tilemap I want to use. When I hit play it translates the image into tiles by looking at each pixel of the image and converting it into a tile according to the constraints. This system means that in the future I can setup different colours to be used for different tiles.
While not exactly perfect, the system is easy for me to use and makes it much easier to create and edit large levels. Of course I will still fine tune the placement of tiles within Unity because I cannot tell what a level feels like to move around in Photoshop.
That's it for this week! If you have any questions or feedback please leave a comment. Thanks for reading!
It's Sunday, which means its time for the next update! I'm much more excited to write this update than the last one. There's lots to show!
I've reverted the Flop-shark attack back to its original attack, after I realised that the grab attacks were not meant to be. However, this time the damage is not dealt when the player get close enough. Connor spent some time thinking about how to represent the attack and thought it would be better to do it with traditional frame-by-frame animation. I agreed as this means I no longer have to animate the jaw procedurally and it begins to achieve the mixed animation style we are going for. So now, the damage is dealt if the player is in range on the jaw closing frame of the animation. Initially, this made it too easy to dodge as the range was too short. I am still trying to find the best distance for this range but overall this attack is better.
Both Connor and I have been playing around with the visuals. The Shark now has some nice highlights and a bit of wear and tear. I've added line-renderers to better connect some of the more manoeuvrable parts of the shark and have tried out some new sprites on the shark arms. We also thought it would be a good idea to put some interest into the background again so I've thrown together a basic circuit-like tile set for the background.
I've had a go at making the particle effects I use for the infest orb more like Connors concepts. I reduced the bubbling effect and added in a swirling trail which makes it seem more spherical if you look closely. I have also changed the way it goes red. In the last post, I was just using an additive material to change the colourless orb that was already there. Now, I've created a duplicate of the colourless orb and changed the colour of the individual assets that make it up. I think it looks so much better!
The last thing to note is I've stopped doing 60fps GIFs. The main reason for this is that they always seems to play faster than the actual game and I can't figure out why they do this or how to fix it. Another reason is I can now make longer GIFs, yay! You can see the difference between the first GIF, which is 60fps, and the rest of them on this post, which are 30fps with a slightly tweaked playback speed. I will be tweaking the settings a bit more to get better accuracy.
Anyway, I hope you enjoyed this update! Leave a comment if you have some feedback and share if you like this development log!
This week I decided to try using some of the things I learned in last week's game jam. The team also did a presentation to the university course this week. Our artist Connor did a great splash for the opening slide, seen in the above image, which he intends to take further for future use!
I began by changing my current code to work with Unity rigidbody components so I could get better collision for free. The current collision doesn't work well in certain situations so that is why I wanted to change it. This solution would work by applying my velocity calculations to a rigidbody rather than the position of a gameobject. It seemed simple but I'll be honest, this did not go well. There are a multitude of reasons for this, one being that I would still have to use raycasts for mechanics such as detecting whether the player can wall jump. So I had to resolve my dodgy collision by improving the raycast system I already have.
I spent a day on improving the system and I finally had something that worked well for the player. Then I tested it on one of the sharks... It worked great at first. I noticed the sharks were getting stuck on the floor whenever they tried to climb a wall with their head against it. It seemed I had made the raycasting positions too close to the edge of each physics object that it was vertically colliding against a wall, essentially gluing the object to the wall (This is the conclusion I came too after being unable to find the actual cause of the problem). Reverting to the old collision system fixed this and unfortunately I had to do this to capture up to date GIFs for a presentation the team did for the uni course. At this point I lost all motivation to continue fixing the collision so moved on. (I will return to it as this is a part of the game that must be resolved)
The presentation we did went quite well and we got some good feedback from audience questions. One piece of feedback was that there is currently no way to distinguish which enemy you are infesting in the game. We do have concepts for what this will look like so I began implementing it in unity. As I was making the changes, I realised that the concept ideas might not provide enough visual information to the player about which creature they are infesting, especially when surrounded by other creatures. I have added a blob style outline, using the same metaballs method as I did for the player visuals, to highlight the creature better. I am unsure whether this works very well as I haven't tested it much but it definitely makes the creature more visible.
Other than that I've just been cleaning up the code. I know there wasn't much to show but the collision conundrum took up most of the development time this week so hopefully I will have more to show in the next post.
I hope you are enjoying this devlog, don't forget to comment if you have any feedback and share if you like it!
I'm the game developer for Squillamorph. I'll post here on the devlog as often as I can.