Devlog 4

Note: I submitted on mylo as normal but actually forgot to hit save here... (good thing I didn't close the tab lol).

Hi so yeah, this is the fourth devlog in which the topic was presentation and graphics will be covered.

Summary:

So this week, quantity wise, not a whole lot was done, but quality wise, a huge improvement. Although not all (or really most) of the graphics are done, the hardest ones are done. A lot of bug fixes were done as well, to make the game better to play. I pretty much didn't touch the single player aspect of the game, so everything talked about will be in the multiplayer aspect.

Camera improvement:

The first thing I worked on was the camera, as the feedback I received from the previous week said. It was too zoomed out and you couldn't really see ahead of yourself, eg to get to the next platform. So to fix this I zoomed the camera out, and skewed it to the right. However, this messed up the ui in the character selection part of level 1, so I only zoomed it in. I reckon I can have different camera adjustments for different levels though.

Character graphics:

So the next thing I worked on was NOT the character graphics, in fact the character graphics was one of the last things worked on this week. However, I wanna show you some gifs of the things I wanna talk about, but I can't do that because I haven't made the gifs, yet, and the things I talk about involve showing the characters. So I'm gonna go through the process of making the character graphics now so you don't get spoiled (I guess).

Purple character (character 2):

So I'm not an artist or an animator so I was mostly just blindly shuffling around trying to make the best thing I could. It doesn't help that I'm also colourblind making use of colours that much harder for me. So I decided to start off with making the purple character which I deeply regret as he is by far the hardest one to do. To see the concept art I based this off, see the game design document I have previously made. In order to fit the 2d aesthetic of a platformer I decided the purple character needed to be side view, rather than whatever it was before.  I started with creating the outline so I would have a rough understanding of what to make. (and totally didn't spend half the day trying to make the feet/legs to look how I want it to lol)

Figure 12: Proto-Proto Frog thing

I wasn't too happy with this as it wasn't wide enough compared to the sprite in unity so I decided to make a wider version, this time I added colouring to help me envision it better.

Figure 13: Proto-Frog thingy

I realised that this was far too wide for the poor frog, so I bit the bullet and decided to make him a bit thinner, even if it meant resizing the hitbox later. I'm sure that won't cause any problems though...

Figure 14: Frog thingy - now finished

I later changed the eyes to be more straight (as they are in figure 14) to give his expression more of a 'ugh I don't wanna be here' sort of expression. I also did my best with shading, giving him more of a round shape by darkening the lower areas of the body. With this idle render done, I needed to make the walking and jump animations.

For the walking animations I had really no idea at all how it would work, without the character bouncing around over the place. So I realised the best solution was to kinda make it look 3d, which was extremely difficult, and again, not a great one to start off with.

Figure 15: Walking animation for Char2.

At the time I didn't realise a problem that would waste hours of my time later, which I'll explain later. In terms of the jumping animation, I found it fairly easy to do, although I wasn't really sure what to do for the arms.

Figure 16: Jumping animation for Char2

It's a bit more obvious what the problem is here, but thankfully, it isn't all that noticeable, and, if anything, makes it look better lol. I had a thought (I know, rare right?) of how the falling animation would work, ie after the jumping animation plays, what would happen afterwards. There's probably a much simpler way to deal with it than what I did, but I basically created a new animation in unity that was just 1 frame (the last frame of the jump animation (which is the one where his legs are tucked in (it will be more obvious when you see the sprite sheet))) and that is played over and over until he hits the ground (in which the idle frame is played). In terms of the animator controller in unity, 2 parameter are set up, a walking bool and a jumping bool. 1 checks to see if the character is walking (ie when the left or right key is pressed) and the other checks to see if the character has jumped (ie after the jump key has been pressed). The jump bool becomes false again when the character hits the ground.

Figure 17: Char2 sprite sheet

Character 1 graphics (red guy):

The red character is quite similar to the purple one, in terms of what to do. I started with trying to draw the idle frame based off of the concept art I had made, However, the arms were a bad colour and the limbs were waaaay too big.

Figure 18: Proto-Red Guy

After adjusting the limbs (by making them a better colour and size), and slightly adjusting the body and mouth, I created the idle frame for the red guy:

Figure19: Red Guy Idle frame

Next was the walking animation, which was easier to do, especially because the red guy has actual joints in his knees and elbows. When I finished it, I realised that I should've made more of a running animation rather than walking, as it looks like he's speed walking for some reason. Also his arms probably come out too far forward but oh well. 

Figure 20: Red guy walking (no it's not sped up)

I'm not too happy with the jump animation for the red guy, as it doesn't really look like his legs are pushing of the ground. Also, his legs move too far forward, but it looks fine if you're jumping forward.

Figure 21: Jumping animation for Char1

I'm also not too happy with the fall frame, but it works well with the current jump animation so I guess it's fine.

Figure 22: Fall frame for the red Char1

If you had noticed, the problem earlier with the purple character has been largely fixed in the red character (not perfect but it's not noticeable  so it's fine). Essentially the problem was that unity was centring the sprite based off the centre of the sprite (yeah duh) rather than the centre of the body. This meant that if the legs or arms went outside of the body, then the centre would be off. So I spent about 3 or 4 hours trying to perfectly centre everything perfectly in a sprite sheet, just to realise that I could have moved the pivot in unit. The pivot is essentially what tells unity where the centre is. So if I move the pivot to the centre of the body, then everything centres the way I want it to. But hey, you gotta learn somehow right?

Figure 23: Char1 sprite sheet

White char3:

This character was a LOT simpler to make, so I regret not starting with it. I started off as usual trying to make the initial render:

Figure 24: Proto-White Character

This was pretty much what I wanted, so I remade it, making sure to make it look a little better. I changed the lasier to be an arm coming from the side rather than the centre, added an eye glass thingy, and made the connector to the wheel seem magnetic or something.

Figure 25: Character 3 finished.

I'm actually gonna show you the sprite sheet next, as it shows how a lot of the animations work. Essentially I decided that this guy only really needs a moving animation, so I made the wheel spin around and called it a day. As for the rest of the animations, the only thing that needed to be done was to make the lasier move up and down, along with the head. This was done by attaching them to their own parents, which are children of the gamebject. The head's parent is centred where the head connects to the body. This was done to make the rotation rotate around that point instead of any other point. Something similar was done for the lasier too.

Figure 26: Char3 Sprite sheet

Thankfully no pivot nonsense was needed here, only a moving animation that you can barely see because of a small the character is (you can kinda see it when zoomed it)

Figure 27: Char3's body moving animation (wow that's a lot of figures.

And with that, the graphics are done for the characters, I think it turned out pretty well, but I defiantly see room for improvement.

Work on the lasier:

The lasier, which is the white character's laser was improved AGAIN. Previously, it was quite glitchy when spammed, so I added an actual cooldown as suggested in the previous week's feedback. Also, I changed the controls from pressing 2 buttons, to 1 button. How does this work? Well I needed to make sure whatever the controls are, they can fit in a small enough space so multiple people can play at the same time. So I set the button to the button to the left of the top button. Aka, the fire button is E/O. This makes it a little simpler to control and still fits in the small keyboard constraint. 

Figure 1: Showcase of the lasier having a cooldown (I was holding the button down the whole time trust me)

More work on the lasier:

I also decided to make it so the lasier can't shoot through multiple players at the same time, ie the end point of the ray cast (and line) is where the player was. This was probably done to make it more obvious a player was hit, but tbh I don't really remember why I did this. I also decided for whatever reason that the lasier should burn through all burnable blocks it hits, and not just end at the first one it hits. Because of this I had to go on a 5 minute coding adventure, as I should really think about moving onto making the graphics. Anyway, 30 min later, if the laser hit an object with the tag 'burnable' it destroys that, then casts another raycast in the exact same spot. It does this until there are no more burnable blocks left. This was possible because I moved the shooting laser part of the script from Update() to its own function. I did this because, if it hits a burnable object, it simply re-calls the function again.

Figure 4: Showcase that the lasier stops when it hits a player, but keeps going when it hits a burnable block.

Level 2:

I decided to work on level 2, as to have more to play in the multiplayer section. I know I need to make the graphics, but surely that won't take that long right? Plus I can't have something to present if I don't even have a level to present in the first place. I figured I should make 5 levels in total. The first level (which is already done) should just explain the controls. The second level should be more parkour focused, getting the players used to the controls and not having much threat of death. The third level is where mist gets introduced and becomes the main focus of that level. This was done because up until this point, the purple character has just been a downgrade, slower and jumps less, an overall pain. However, level 3 should be a walk in the park... literally! Anyway, the fourth level introduces spikes, and is heavily focused around them, and the last level, level 5, has a combination of all the themes shown.

Making level 2:

While making level 2 I realised the white character can't really do much at all, being unable to jump and all. So I decided to add a trolling aspect to this level. The platforms that the purple and red characters will be jumping on, will be burnable blocks. This means that the white character can destroy these platforms with the lasier. However, I realised that I don't have a way to get the burnable blocks back after they're destroyed.

Buttons:

To solve the problem I thought of an idea where, a button respawns them once you step on it. However, I haven't coded this yet and I really should make the graphics. But surely the graphics won't take that long right? So I decided to have a quick 5 minute coding adventure making the functionality of the buttons. I wasn't entirely sure what to do for them, until I realised that I could treat the burnable blocks like how I treated killing the player, ie disabling hit colliders and sprite renderers, and re enabling them. So after about 10 minutes I recoded the way the lasier destroys the burnable blocks (now it disables the components rather than destroying them). Now to code the button, after about 30 minutes I figured out that if something enters the button's hitbox (set to trigger) it re enables components in the button's children. This would allow me to easily make multiple instances of the button for different burnable blocks. I easily made the burnable blocks I wanted, children of the button by using the hierarchy window. 

Figure 2: The many, many children of a lone button. (Dunno why the image is so big lol)

Figure 3: Showcase of the button working.

Bonus button:

Because the button worked so well I decided to go on a quick 5 minute coding adventure to make a slightly different button with a completely different functionality to the other buttons that only appears 1 time in the whole game. I wanted, for whatever reason a (very small section) where if you fall down, you actually can't get back up. I didn't really want to make a small parkour part to get back up like I had done at other parts because that would negate the punishment of falling down in the first place. So I placed a button down there, where if something enters its hitbox (set to trigger) it teleports it to a specific location. However, I didn't want the white character to get teleported because he needs to move past there in order to progress, so I went on a quick 5 min going adventure to make sure that if the game object that enters the button has the component 'isChar3' (which is only unique to char3, it acts like a tag) then it doesn't teleport. 

Figure 5: Showcase of that one button working (yes there really is only 1 of it (totally wasn't a waste of time))

Other button fax:

I just thought I'd mention that later in level 2, there's a section where 2 different buttons respawn the same burnable blocks. Because the buttons only re enable the components in the button's children, I can't have the burnable blocks as children of 2 different blocks. So to fix this I essentially just duplicated all the burnable blocks I needed and set them as the other buttons children. This works because it's impossible for the lasier to destroy 1 copy of the burnable block without destroying the other.

Making a cool bridge section:

I know I've talked a lot about the white character in terms of level 2 but that's because the other 2 characters just having boring parkour like normal. I guess I did make one part where the parkour is kinda hard for the red guy specifically, but this path is optional and, most importantly, has platforms that aren't made of burnable blocks (just in case the white character trolls too hard, it's another option). But other than that, the more interesting parts of level 2 are showcased in the white character (probably because I was forced to be creative due to the constraints of the white characters controls).  So up until this point the white character basically just destroys some blocks that are in front of its face. In order to change things up a little I decided to make a bridge made of burnable blocks, where if you miss a shot and accidentally destroy part of the bridge, you have to reset it. However, I realised that the white character doesn't have a possible way of moving up, after it falls down (other than riding on top of other character's heads, but I can't rely on that just in case both players pick the white character). So I figured I could use slopes to get the white character back up, as this will cause not problems at all whatsoever.

Figure 6: Showcase that the bridge and slope works.

Making the bridge:

I initially decided to make the bridge out of multiple burnable blocks as this proved to be more of a fun experience. However, it was kinda glitchy, as the white character would get caught on some sort of subpixel and be unable to move past it. Even though I zoomed in as much as possible to make sure that the bridge was completely even, it didn't seem to work. There was probably something I coulda coded to fix this, but at this point it had been many days, so I just decided to make the bridge one large burnable block.

The slope problem:

Making the bridge was the first time I used a slope, but I would use more slopes in future levels. This led to me discovering that the slopes are kinda glitchy, but even though I think I know how to fix it, I never got round to it. At the moment, you can't jump on slopes and the falling animation always plays while you're on it. 

The turning around problem:

Previously up until this point, each character did not have the ability to turn around. This was especially annoying for the white character because it is kinda important to have the ability to shoot backwards. This was first realised when making the single player level, but now, here in level 2 in order to get back up, after falling down from the bridge (at that point the bridge was still made from multiple burnable blocks meaning:) you needed to turn around to destroy the burnable blocks in the way. So to fix this, I had to touch the ancient player movement script that I had made all those many weeks ago. When the left key is pressed, the x coord of this.transform.localScale becomes negative. All this does is flip the game object on its vertical axis, thus turning it around. However, with the method I was using, it meant I had to make 3 different checks, depending on if the game object had the isChar1 (or 2 or 3) component or not, due to the fact that everyone's x coord was different, I didn't think to just multiply it by -1. Now everyone can successfully turn around and THANKFULLY the lasier shoots in the way I want it to! Except there was 1 slight problem that led to another 5 min coding adventure.

Finally finishing that damn lasier:

When facing left, the parameters for moving the lasier too far up and too far down, were broken, as unity looks for if the coord is smaller than 45 (if it's too far up). However, the angle 45 is on the other side of the body of the white character. This meant I had to have seperate parameters for when the white character is facing left in order for the player to not aim too far up or down. This also meant I needed a boolean to keep track of if the white character is facing left or right. After 30 min I was done, and it worked, at least for now...

Figure 8: Proof that turning around is flat-I mean works.

Making level 2 great again:

Other than having the ability to troll players, and destroy burnable blocks, the white character can't really do a whole lot (yes I know I'm talking about the white character again). This really limits the amount of things I can do to make playing the white character interesting, so I decided to add 1 final thing to level 2. This would be a showcase of a target system, where if you hit a target with the lasier, it opens a door. 

Making the targets:

The target, for now, is just a circle with a circle collider. I also gave the circle the tag 'lightable' (called that because the target has the ability to be lit up by the lasier, kinda like redstone in Minecraft). I then made a door, (which is just a rectangle) and set it to be a child of the target. In the firing lasier code, if the hit collider has the tag 'lightable' it disables all of its children's sprite renderer and collider components. This basically means when the target is hit, a door opens.

Figure 7: Showcase of the target working.

Finishing level 2:

Now with all the gimmicks coded I finished off level 2, it's kinda small in size but it's dense with parkour and trolling capabilities. After I finished I found some other bugs relating entering level 3, which I fixed, and also adjusted the camera to be skewed to the right.

Figure 9: Level 2 finished.

Level 3:

Holy heck I wrote a lot for level 2. I'm gonna try and shorten it for level 3, but I didn't really add anything new like I did for level 2, so it'll probably be naturally shorter anyway. So the theme for level 3 was the mist. When designing this level, I mostly kept the red character and white character in mind, as the purple character is immune to dying from the mist. I just made sure to make it possible for the purple character to reach the end. I started the level off with introducing the mist, not making it a threat but still showing it exists. I then added checkpoints which I didn't really make sure they worked until much later.

Getting the checkpoints to work:

I'm kinda time travelling here, but at the time, I just had the checkpoints in their broken state while making level 3. However, as one of the last things I did this week, I made sure that they successfully respawn each of the players at the checkpoints position, and made sure to update only when both players are on the checkpoint. The most painful was getting the checkpoint to activate when the total number of players were inside (which was information carried over from level 1), and in hindsight I probably should've just hard coded these to wait until 2 players were in the checkpoint, and just have a seperate prefab from the single player level.

Finishing level 3:

Level 3 is split into 4 sections, one is the introduction part I've already covered. The second is a section inspired from the single player level, as you'll see in the image coming up. The third section splits the red and white characters up, the red gets a fairly easy parkour section of some mist, while the white gets a tricky shoot the targets section. This section quite cool actually, as you are needed to enter the mist for a short period of time to shoot the target. However, while testing this, I realised the current dying to water code is kinda rough and doesn't work well.

Improving the dying to water script:

Instead of using a coroutine, I made an integer counter that would increase by 1 each frame as long as you're in the water and decrease  by 1 for each frame you're not in the water. This change was done because before, if you were in the water after 1 sec had passed, it doesn't matter if you quickly entered then left then re entered, you would still die. Now there's a constant timer that decreases and increases making ‘drying off’ more realistic and fun. 

Level 3 is done now:

The last section of level 3, again split the white and red character up, this time, it is easier for the white character, but harder for the red character. The white character just has a simple duck in and out of the mist section (like earlier). Meanwhile the red character has to carefully navigate around a big block of mist, ducking into and out of pockets of air in order to get through. 

Figure 10: All of level 3.

Level 4:

So I really wanted to finish all 5 levels before moving onto the graphics, and honestly it would've been fine if it weren't for all the 5 min coding adventures. I made a very basic start on level 4 by adding a few spikes and a tunnel for the white character to move around the spikes. I was planning on having a fairly long section without any checkpoints, that isn't too hard just kinda long. I was considering making a unique checkpoint for char3 only but I couldn't afford to go on another 5 min coding adventure. At this point it was about halfway through Thursday and I needed to finish the graphics before Friday's tutorial or whatever it is. I reckon it's doable, the graphics shouldn't take that long right?

Making the graphics:

Hopefully at this point you've read the part on me making the graphics, so yeah I made the graphics, woohoo. However, I didn't explain how long it took me... The purple character took the longest, being the rest of Thursday and all of Friday. The Red character then took all of Saturday and a bit of Sunday. Then the white character took a small amount of Sunday too. 

Speedrunning as much as I could:

It was about halfway through Sunday, specifically and I needed some feedback to work on, so I needed to make a stable build of what I had and upload that to the discord. I first needed to go through ALL of the single player level, multiplayer level 1, 2, 3 and 4 as EACH character to make sure their new hotboxes worked. After that, I tried to finish off level 4 and 5, but I didn't get enough time. In level 4, I made the white character section, the purple and red section, and the part that joins them back up. The white character has an interesting section where, similar to the bridge part in level 2, you had to try and hit the targets, without hitting the bridge that you were on, as this would destroy it and you would fall into a pit of spikes. This was the best way I could think of that could get the white character involved with the spikes somehow. The red and purple characters have a more boring section (as usual lol), with some fairly tricky jumps that involve a bit of precision. Again, I didn't want to make it too hard due to the lack of checkpoints. I also split up the red and purple characters into their own sections to make it a bit more interesting for each of them (specifically, having the red character jump over large spikes, and the purple character dodge ceiling spikes). And with that, I got half of level 4 done.

Figure 11: Half of level 4's completion.

Continuing to speedrun:

Entering the afternoon of Sunday I went through as many bugs as I could find and made sure everything worked properly, which it kinda did. I ended up finding a few other small bugs which I fixed but as it started to get late I uploaded my build onto itch for any feedback on discord.

Feedback:

Throughout the whole process of making levels finding bugs etc, I used feedback from family members that play tested the game for me when I showed it to them. However I thought I needed some feedback from the class so I uploaded a build to discord anyway. I didn't receive a lot of feedback but I was told that the animations work well for the characters and that the game was coming along nicely. I also received feedback on various bugs and problems in the single player level, such as a mysterious purple dot, and the initial respawn being slightly off. I have decided to leave those in the game, as they don't break the game at all and are kinda just funny. 

Closing thoughts:

As it nears midnight on Sunday, I have made a very prominent mental note to start writing these devlogs sooner as I don't really want to cut it this close every time. I also realised at the start of this devlog I said that this wasn't very quantity heavy but that's because most of my time this week was spent on doing the graphics, I never really realised I had made quite a bit quantity wise. I also totally wrote way more than I should have, I will definitely need to trim it down in the future. Anyway goals for next week include: finishing level 4, making level 5, making graphics and ui for as much as possible before Friday.