Hey everyone, this weeks post is entirely about the feedback so far from the graduation show at UCA Farnham. I have not had a chance to work on the game since the first day of the show last week because I got ill. However, I did manage to get the boss ready for the show build of the game, which I was very pleased about! If you do manage to get to the show, let me know what you think of the game!
The instant people began playing the game I was noticing everything that could be improved. It always amazes me how much you see when someone other than yourself plays your game. The main aspect people could not get to grips with was the wall jump segment in the tutorial. I'll admit, I have not play-tested the wall jump prior to this and I had suspicions it would be difficult to use. The wall jump part of the level is a vertical corridor that is too long to helix dash up, so it forces players to use the wall jump. Unfortunately, it would seem that the physics based movement makes it hard to use the wall jump. Due to the number of players who struggle with it I will be changing the way the wall jump works to make it easier.
In the previous post, I described how pleased I was that I had got the game working with a controller. However, the first player to try playing with one revealed a massive bug. Whenever the player used the helix dash in an exactly vertical or horizontal direction, the screen would go black and then they would reappear at the spawn point. This is a big problem because I had no idea what could cause this. Upon further investigation I can reproduce the bug without a controller which means that the problem has been around since the dash has. It has happened before with the mouse but it happened so infrequently that I thought little of it. I have now found the cause of the bug and fixed it but it is very technical so if you are not interested in that, skip the next paragraph.
Turns out, the cause of this was a method I created to stop the player ending up in a wall at the end of the dash. In the method, I calculate the horizontal and vertical distances the player will be from surrounding walls at the end of the dash. Whichever distance is smallest will be the one I use to stop the player before a collision occurs. In these calculations I use the Cosine maths function. I found that when the direction is directly up, left, right or down, one of the output cosine values is tiny. If you are interested, that cosine value was cos(1.570796). The way I then use this gives me a huge negative number, which just so happens to be smaller than the correct value, meaning it is used. This makes the end position of the dash an astronomical distance away from where it should be and the player ends up outside the level, which is why they reappear at the spawn point. All it took to fix this was to check which value is smallest if they were all positive and then use that value. I hope that didn't confuse you too much!
Back at Rezzed in April, many people mentioned that they did not like the enemies being able to pass through the player's infested enemy. Nothing felt solid and this impacted their satisfaction. I agreed with this but could not see how I could implement it at the time. Through perseverance I got it working, but now I am seeing that it has created problems. To make the player's enemy collide with others I made all enemies push each other apart. However, I seem to have made this a little bit too strong. The enemies now block each others path and this makes gameplay really slow at times. The ideal solution to this is to have the enemies climb over each other but this is very hard for me to make work with the pathfinding at the moment. For now, I think I will turn down the force they apply when they collide with each other but I will strive for the ideal solution.
That's it for this week's post! I know it was quite a technical post but I hope you enjoyed it anyway. Thanks for reading!
Hello everyone! This week the University of the Creative Arts Farnham campus is having their graduation show. As part of the Games Arts course incubator studio, we will be showing Squillamorph there! If you are interested in playing it, and seeing a bunch of awesome student work, you can find the relevant information here --> UCA Farnham Show Details
If you do go, send a photo to us on twitter @squillamorph!
I've just noticed that in three days time it will have been a whole year since we officially announced Squillamorph. Crazy to think how much the game has changed since the prototype we had then! I haven't prepared anything special for this as I hadn't realised but I will do a special post for a year of development on the actual game, which we started work on at the end of August. Here's a quick GIF showing the change between the old prototype we finished a year ago and the current version of the game. Then it's onto the new updates!
One of the things I really wanted to get done this week was the framework for the HUD transition animations. The HUD will adjust colour and the character image to match any creature the player infests. Connor has done some great work on the animation which I have begun implementing. We are still working on certain aspects of it, the infest timer for example. I'm still not sure if I like the way the entire graphic changes from the creature colour to the yellow/green colour we associate with the infest mechanic. I'm just not sure about the blend of certain colours that result from it. Nevertheless, having the ring timer has really helped us clearly convey that there is a time limit for infesting.
Work on the Flopalodon has been good but slower than I'd like due to the work on controller support. Connor is working hard getting sprites made for it and I am working hard to get a version of it ready for the show! I won't be able to completely finish it for the show but there will be something done for it. The fight is still in very early stages but I wanted to show something. I won't explain how the fight is going to work because I don't want to give away too much. Nevertheless, I will be showing a bit more of it in the future!
I spent a large amount of time adding controller support over the past week. This was something highly requested at EGX Rezzed but I hadn't gotten around to it until this week. The main reason for doing it now is that I feel using a controller can be more intuitive for new players, especially with Squillamorph's control scheme. I think it would be good to have both options at the show.
One of the largest challenges for me with mapping the controls to a controller was the mouse aiming system. The solution seems obvious; instead of aiming with the mouse, use one of the joysticks. However, when the mouse button for directional abilities is held down, it displays a subtle aiming line. When the player releases the button, the ability triggers in that direction. So how do I do this with a joystick? The prototype's method was to hold down the left trigger to bring up a line, aim with the right joystick, and activate on the trigger's release. This was not very easy to understand or convey to the player. So, I've come up with a simpler solution.
To aim a directional ability, you push the left joystick in a direction. Moving the joystick brings up a line showing you the direction. When the joystick is pushed far enough the ability will activate. Confining this system to one control input rather than multiple has proven far more intuitive than before. Nevertheless, I have yet to test it thoroughly and I'm sure I'll have to tweak it.
To round off this section, I'll mention that switching between mouse and controller can be done in the middle of gameplay and any text or tutorial elements will adjust accordingly. You can see this switch happen in the above GIF. It's probably also important to mention that I have made quite a large change to the enemies. To stop things from getting over-complicated, I've removed the second ability that enemies can have. In existing content, this only affects the Flop Shark; they no longer have a tail swipe stun as standard. Don't worry though, this ability will appear in a variation of the shark!
I hope that wall of text wasn't too much! There isn't much to show when it comes to controller support so I've tried to explain it concisely. Anyway, I hope you enjoyed this post. Feel free to leave a comment and share on social media! Thanks for reading!
Hey everyone, this update contains some exciting new additions to the game! However, I need to start by saying that the video update won't be happening any time soon. I've talked about making one for some time but I've got so much to do for Squillamorph, and other projects, that I just don't have the time to make one to the quality I'd like. Nevertheless, the posts here will continue.
In regards to these posts, I'm trying out a slightly different layout because I think it makes things easier to digest. Anyway, onto to the updates!
The best change, in my opinion, is the new HUD! Connor finished creating it recently and it instantly made the game feel more complete. Obviously the game still has a long way to go but the HUD is one of the most important parts of it. I'll quickly explain the information it highlights. The highest piece of information is the current number of lives, made clear with a heart symbol. The middle number is the current wave of enemies, which uses a symbol we intend to utilise throughout the game to represent enemies and the wave system. The lowest number is the points count, which uses a symbol we will associate with points. Finally, the image will represent the current creature the player is infesting, or just the base character as shown in the GIF.
We may end up changing the placement of each element, once we've done some more play testing, but for now I think it works great.
Level Design Updates
I've now got all of the current levels up-to-date and working well. They still need testing but they are all working mechanically. Some of the levels have gone through some design changes. Let's take the second tutorial level as an example. This level introduces the player to the main wave-based gameplay after learning the basic mechanics. It is a simple level with a horizontal layout. The player would spawn and fall onto a door that blocked the level exit. They would then have to find what we call a 'fuse', an infest-able machine that they can deposit points in, to open the exit door.
The original layout of the level did not make this easy for the players to figure out. Now that I've made the changes, the player must use a fuse to open a door, which leads to the level exit, and then use another fuse to activate the exit. This layout should teach the player how the levels work in a more understandable way than before.
I've been working quite a bit on the enemies this past week. I've started making a new variation of the Flop Shark, a larger and slower shark with more health and a powerful bite, which will add another interesting dynamic to the shark levels. Perhaps the most important, but the least noticeable, improvement I made to the enemies is the hands/feet. I've changed the movement of them to be smoother and I've started attempting to make their placement better. This was especially important to do because I've begun to make a much larger enemy which needs good limb motion, the boss for the shark region, the Flopalodon.
We are not ready to show this boss yet but the fight is fully planned and it is beginning to come together! Ideally, it will be complete, in a rough form, by next week. Then I will be able to show a preview of it!
For some time, I have been thinking about ways I could make the camera more dynamic. We have camera shake which definitely helps but the camera is always locked to the player character. I did try having the camera smoothly follow the player but because of sudden movements, like the helix dash, it actually looked anything but smooth. We could have a track for the camera to move around on in each level, keeping the focus on the space the player is in, but this would mean we have to set one up for each level. I then decided just to stick to the fixed camera, but the other day I had an idea. I came up with a system that keeps the core camera movement locked to the player but moves around in the direction of the most open space. This is almost what a camera track would do but it dynamically adjusts to any space rather than being limited to a set path.
This still needs a lot of testing because, while it is more dynamic, it might make aiming slightly harder. So we might not keep this but I thought it was worth mentioning!
That's it for this post. I hope you are as excited about the progress as I am! Thanks for reading!
I'm the game developer for Squillamorph! I'll post here on the devlog as often as I can.