Day 5 - 7 & Beyond!
Link to a google drive folder of our game: https://drive.google.com/drive/folders/0B1tlADeMhjwaZnFRZU5pYU42d0E?usp=sharing
Helter Skelter
What a busy few days...
We missed a few days of blog posts as we were too busy getting things to work and couldn't pull ourselves away. So i'm going to try to cover everything that happened along the way as best I can.
After day 4 the panic was starting to set in, we still had so much to do and the clock didn't wait for us. I was stuck trying to learn and build a working third person controller while Moofle was busy with getting interactable barrels to work. Those would be used by the AI to knock them down and slow you if you were chasing them.
At this point I was busy trying to get ground collision and walking to work. I made this work using raycasts to check how far the player was from the ground. The raycast was from the character's origin straight down with an extra variable in place so that we could change the height of the character to account for different model sizes. if that raycast failed I had 4 more in each cardinal direction so that the character could be on the edge and not fall off, making them more than just a single point. there are still places where this could fail with weird terrain but that's an acceptable constraint for the time being. if they were on the ground then using a state manager they would have an idle state and be set as on the ground. if there was forward input from the player (w key) then that would set them to moving and the animation controller would transition them to walking.
Now if they aren't on the ground I set them to inAir and start a counter to check their airtime (used later to drive the type of animation when they land, could alternatively save the position they were at and then when they land and calculate the distance which could also be used for fall damage, however this doesn't account for jumping.) while they're in the air I turn off jumping ( could be tweaked to allow air/double jumps). At first I used horizontal input from the A & D keys to drive their rotation however due to the camera we created to drive the player's rotation based on the camera's view made things a little complicated. Ideally I would have the player control the rotation with the camera and then strafe with the directional keys. however this wouldn't work for all game types so I might do away with this in the future if it doesn't work well.
Next I added running which is driven by the shift key. The shift key drives the forward velocity and the animation state changes to running when the forward input is greater than the walking magnitude. within the controller I setup a blend tree to handle running in either direction. Due to animation limitations and not wanting the character to slide I implemented a limit to the amount in degrees that you could turn while running, If you exceeded it then the character would stop and make the turn. This doesn't feel great with the fast paced nature of the chase, so it's first on my list of things to fix.
After running I implemented a state change to go from running to idle, with a small animation that has them slowing down before stopping, this looks way better than going from running to 0 in 1 frame. Alternatively I could just transition them back to walking before going to Idle but I think that will take too long in the animation phase and look weird, but stuff to experiment with after.
Next I worked with jumping and falling. jumping has an addVelocity function attached to it which I can tweak in the inspector. Along with this I do a check using the position of the feet to see which leg is in front and then mirroring the jump animation to make the transition a little more natural.
the in air state is basically and opposite of on ground and while it's doing that it has a counter, if it's greater than a threshold then it will play one of two animations. One for falling normally from a great height and the second if the player is inputting for the character to move then it will do a roll when it lands which they can transition to walking and then running. I might implement one for running after the roll in the future if I get a good animation.
That's the basic functionality done. most of that was done in day 5 and some in day.
While I was going crazy with the movement controller Moofle was busy figuring out raycasts for clicking on objects to interact with them in some way. He started with barrels, whcih when clicked would send them flying in the opposite direction from the player, think of this as the player running up to a barrel and kicking it. This took a while to setup mostly because he didn't want to do it the quick hacky way and wanted to make it easier to add interaction to other objects without having to write a script for each type of object. this worked well until there were more than one object of the type in the scene it would send the first one flying. After some fiddling and brainstorming we got that to work in the intended manner. Next he worked on a castle portcullis that would open and close with a little animation when clicked on (ideally it would be a lever close to it that would drive this) this took a little longer as he learnt about animation controllers and animating in unity as well as needing to alter one of the models as they portcullis was attached to it. It was quite an experience but I think he learnt a lot. We also configured it to work with the navmesh as an obstacle so when it's closed the AI would know they couldn't go through it.
Day 6
Day 6 was more environment building for me as well as adding things to my movement controller and getting the model and animations setup correctly. Moofle on the other hand worked on some more interactables, one an informant that would let you know where your target is on your minimap and the other that goes up to them and slows them down, or stops them if their paranoia is low enough.
The next thing I added was walking on an incline. Using more raycasts and math to check the angle of the surface you are walking on, if it's not too steep then the character would be able to go up or down them, albeit more slowly and with a specific animation. This worked well but didn't look that great when you stopped as the other animations didn't work so well with inclines. This will be fixed when I add foot IK into the mix.
I had some available time (not really but I went for it anyway because it was cool) I worked on adding vaulting over thin enough objects, that way if there was a fence they could just hop over it. This was done with - you guessed it - more ray casts. There is already one sent outward to check for obstacles, now I added one higher up that would go forward to the max vaulting range and then cast downward, if it doesn't hit the ground then it's too thick otherwise it's ok for vaulting. There's also a check for the angle so that if you're running next to it or at a steep angle you won't just vault over it. I had to fiddle quite a while to make the animations work nicely, I have one for walking and another for running.
Learning from my work Moofle implemented raycasts to check if the informant or agent can see the player and if they in range then they would do what they're supposed to. This works really well and we have some cool agents that would go up and stop or slow the target down for the time we set and others that would follow the players position if they in range and can see them then they would be displayed on your minimap. I'm making it sound easier than it was, it took quite a while to make everything work and look great and work together without breaking the game, he did a good job.
Day 7
The final day hit and we still had a mountain to climb infront of us.
I finished up enough of the level and got the navmesh to play nicely. Moofle set up all the waypoints for the AI to go to. Next was a few hours of merging our different parts and making sure we got rid of game breaking bugs. it took longer than we thought and was filled with frustration. But we got things to work together for the most part. The last thing was driving the target's paranoia and setting it to full when the player is in range and the AI sees them for long enough ( a second or two)
In the end we didn't manage to use the portcullis and there was still much of the level that was unfinished.
Unfortunately we didn't have time to add a kill assassination sequence in it for when you reach the player and we were also having trouble with the win condition of touching the target. So for now when you get close to the player you win the game and it quits. Not quite what we wanted but it's somewhat functional.
We rushed to get everything done and built and then submitted.
It was late we were exhausted but we did it for the most part...
It was a great experience and we will definitely be doing it again! We both learnt so much and we now have a list of what not to do when doing a game jam. But for our first one we're both quite happy with the work we did an what we got out of it.
From here on we're going to keep working on the controller and probably the AI too to get a much more functioning and fun game.
Thanks to everyone that got this far and joined us on our adventure!!