Jump to content
  • Advertisement
  • entries
  • comments
  • views

About this blog

The trials and tribulations of 2 developers way in over their heads.

Entries in this blog


Week of Awesome Day 5-7 and beyond!

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!!




Day 4 Week of Awesome

Day 4 Keep On Movin   Man what a day! We achieved quite a bit but we really would have liked to have done more. Of course nothing ever goes as planned but we got there in the end...   Our main focus for day 4 was navigation for the AI and adding all the modifiers that go with it so that he goes to his main objective but as his paranoia goes up the chance to make some less efficient decisions goes up too. On top of this we wanted to add the player in as a factor for the AI to get away from.   I apologize that this is more of a technical and somewhat boring post dealing with what we did and how we did it in a little more detail.   With our basic navigation setup so that he would head towards his objective we added nodes (empty game objects) where we think his decisions would be made so for instance at a fork in the road. He would then check to distance(path distance not straight line) of his current waypoint and the waypoint he wants to go to and add the distance from that waypoint to the goal waypoint. All the waypoints in range were put into a dictionary - the waypoint object and the total distance - and sorted from low to high. Phew quite a mouthful. Basically it looks at all the possible nodes he could go to in range and sorts them from shortest to longest. To start out we just took the first in the list and had him go there. That was our first milestone and it worked great. From there we tweaked it a little, increasing the range to search for nodes and also adding a buffer so he searches for and chooses his next node before he gets to the existing one that way he wouldn't always walk to the middle of an intersection before turning.   So far so good we had a basic system up and running and he was going where he needed to. Next we needed to add the paranoia element. So as his paranoia goes up the greater chance of him taking a route that isn't as efficient. To do this we needed to take all the nodes in the list and calculate a percentage for the chance that they would take that route based on their distance, the shorter the distance to the goal the higher the percentage that they would choose that route. This alone is a pretty good system for adding some random behavior to the AI instead of him always taking and knowing the best route available to him. However this doesn't activate unless paranoia is greater than 0. The tricky part is using those percentages and then modifying them. The way we did random was to start with the first one and add their chance to a separate number starting from 0 until all of the nodes were added, the last one being 1. then we would get a random number between 0 and 1. Then using that number we would check which of the nodes percentages are closer and that would be the one chosen. OK great we have some random decision making on the next node to go to. Next we need to modify those percentages as the AI gets more paranoid. So to do this we took the deviation from the mean and divided it by the paranoia modifier. then we would add that to the mean to get the new percentage. What this does is bring everything closer to the mean so that at max paranoia he would have equal chance to make a bad decision than a good one. From there we added the player modifier so that the AI would try and go to his objective but also try and stay away from the player. This activates when the paranoia is at 1 indicating that he's not paranoid anymore and that there is actually someone chasing him. Now to make nodes less desirable based on how close the player is to that node we just divided the total distance (current node + next node + goal node) by the distance that the player is from the node. On top of this we also added a threat modifier which is based on how close the player is to the AI within their threat range. We then turned that into a number from 0 to 1 so that if the player is at the edge of the threat range it wouldn't have much effect on the percentage chance that a node is picked but if they are it would effect it greatly. In our tests if the player was close to the AI and the player was close to one node and the AI at equal distance from 2 nodes the AI would only have around 10% chance if not less to go to the one the player is standing at. On top of this we added a ban list for any node that has already been traveled to, that way the AI won't double back and will stop them running between 2 nodes which happened more often than we were comfortable with... There were quite a few bugs as expected one really annoying one was that using the Contains function for a list (checking to see if a node is in the ban list) is a bit finicky when it comes to game objects so we had to change to using the name of the node rather than the object itself, This was ok since we already used what we needed from the object. Man, when we got that to work it felt amazing! seeing the AI head towards their objective but turn the other way if the player was close was really cool. Now we need to adjust and tweak a few things. for instance it might be better that if a player is at a node then there should be almost no chance for them to go there( we still want some so that on some off chance the AI will try to charge the player thinking they can get past them or through them :D.   That was a long day and we had some headaches forming so we headed to bed straight after and left this blog post to the morning. It was well worth it but we would have liked to get it done sooner as we're running out of time.   I've attached some pictures of the basic level and lighting so far. still a lot to do but at least we have some visuals Up Next:  - Add interactables for the AI to slow the player down ( also used by the player but in a different way) We're going to start with some barrels that can be knocked into the path and if the player collides with them then it'll slow down their movement for a second or 3. Moofle will be working on this. - Additionally I'm going to be working on improving the movement adding some nicer animations with root motion as well as adding jumping onto higher platforms and vaulting over smaller ones if I have time.   Along with all these we sometimes take breaks to work on other things like level design and UI.

Thanks for reading and I hope you're enjoying the journey along with us, until next time, have a good day!




Ludologists - Day 3 Week of Awesome

Day 3 Runaway Another morning meeting to summarize today's goals and we were off to the races! AI pathfinding and movement was the big cheese on the agenda today but prior to starting work on that we wanted to have a basic play area finalized. I started working on terrain sculpting and placing assets into an environment, along with my lighting prefabs I'd made from the night before. Disaster struck however when a miscommunication between me and Moofle caused a loss of progress on one of the collaboration merges. We would have to be more careful in the future! During this time Moofle started to work on our game's minimap with a degree of success, we plan on culling most of the rendered objects on the minimap and overlaying (or is it underlaying? :thinking:) a hand drawn map when we have our final area done.   Once the above was done it was time for the big cheese. We had to figure out exactly how our target would act when trying to navigate the walled castle city when trying to escape from our player controlled assassin. This being a very important structural pillar of our design we spent a decent amount of time simply going through the would-be scripts to be and conceptualizing them with comments. I believe this helped immensely when push came to shove and we started to code. We did a classic peer programming approach where I was the observer/strategist and Moofle was the driver (although he came up with some colorful terminology for this role). By the end of the session, about 5 hours in, we had something demonstrable of our original goal, which was a big win and improved morale - which, admittedly had been flagging as it usually does so far into a development session.   I wanted to continue working, but Moofle 'suggested' it was better to rest up and prepare for tomorrow then continue into the wee hours.   Up next - Quashing a few bugs in the current version of the AI - Creating a Navmesh/Waypoint system on our newly created environment.




Week of Awesome V - Day 1 + 2

Intro This is the first of many to chronicle our journey through the Week of Awesome V game jam starting 07/08/2017 to 14/08/2017. Thanks for reading, we hope you enjoy the ride with us!   Please excuse the long list of mistakes made as I'm low on sleep, concentration and annoyingly ill at just the right time... Day 1 Blue Monday  We got a late start due to delayed flight but we got what we wanted to done.
I managed to have a quick look at the themes in the morning to start getting the ideas flowing and the cogs turning in the back of my head. Chain Reaction | Assassination | Alien Invasion | Castles Not bad, definitely not what we were expecting, though we didn't really know what to expect as this is our first game jam. Our process was to split them off into all possible combinations and pitch as many ideas to each other as we could, write them down refine them and then whittle them down. There was a fairly even spread of ideas in the different combinations except for Alien Invasion, we couldn't seem to come up with anything too interesting or original. Not a problem still 3 other themes to play with. After an initial pass to refine the ideas and make sure we both had a concrete understanding of each of them with eSach took turns nominating ones to be removed from the list. I feel like there could have been a better way of doing this, maybe a round robin followed by a knockout stage but time was limited after I got back late and we wanted to settle on a theme before the end of the day. Eventually we whittled the list down to 2 finalists, surprisingly an Idea from each of us. we then each chose one and made an argument as to why we shouldn't make that one. with great confidence we both nominated our own ideas to be cut it took a while and we went over all the pros and cons of each, in the end we had one we were more excited about and we managed to remove a negative from the equation which was the amount of resourced needed to create it. All hail the asset store! We ended up going with his idea using the Assassination and Castle themes. The basic premise being a chasing with the intent to assassinate a target before they get to their destination in the large castle city. not that interesting at first thought however we're placing emphasis on the gritty and messy nature of hunting down and assassinating someone in a large environment filled with twists turns and intractable objects that can help or deter your chase. You won't end up killing your target in one hit as you jump off a 3 story high building gracefully landing without a single scratch or broken bone. Instead it's going to be an uphill battle where things don't go as planned or expected. We plan to make the AI as smart as possible with the objective of escaping you through erratic pathing through packed city blocks and using what they can in the environment to slow you down or injure you. You will use your reflexes, planning and resources to slow them down, steer them in the wrong direction and ultimately catch up with them to fight tooth and nail to put an end to them before they reach their objective.

Our biggest worry with this idea were the potentially high amounts of assets we'd need to make it look and feel good. However after doing a little research on the asset store as well as looking at the standard assets provided with unity we were confident that we would be able to make a great game with decent assets while having very little artistic skills as we're both programmers. Time was also a large factor so having access to great assets to quickly prototype and get our game playable was essential. We ended the night making sure we had fleshed out the idea enough and gotten everything written down coherently and set up a Trello board so we could easily plan and keep track of what needed to be done.   Day 2 Motion Blue After being awake for nearly 24 hours I crashed and got a late start to day 2. Nothing a strong cup of coffee couldn't solve.

We started the day with a meeting to make sure we knew what our current focus was and to make sure we were all in approval of what was discussed and decided upon at 3 in the morning the previous night. We started trying to figure out Unity Collaborate as well as Scene Fusion. No simple task. We had conflicting unity versions as well as Scene Fusion only working with the older 5.6 version instead of the new 2017 version so it took a while to get up and running as well as figuring out how it all worked and what the drawbacks were. Scene Fusion is great for playing around in the scene together to work on level design as well as talk about concepts more easily by following the other person's camera. however whenever a file or script change is made and needed to be uploaded using collaborate we'd have to restart the sessions so making small changes to a script to see the changes would take a little extra effort and frustration. But we're getting used to it and it brings a lot to the table and adds to our experience of creating together in Unity. First major goal - make something playable to see if this is fun or not... we started by taking the standard character model, controller and camera provided by unity and teaking them until we had something pretty basic to run around in and have a feel for what we wanted. Most of the work ended up going to making a decent 3rd person camera that felt nice to explore the world with. After getting some decent terrain and buildings in the scene without much regard for position I worked on the lighting for the scene while my colleague worked on the camera.

We decided on night time for atmosphere/mood lighting reasons as well as not needing large crowds to make it feel alive and the complications, time and effort the bring with them. Some quick tweaks to the skybox, main directional light - color and intensity - and I began adding some environmental lights such as braziers and torches near and on some of the buildings. We also tweaked the movement and jumping of the character so that now he not only felt good to run around with but also to jump over things. The camera took a lot of work and was filled with quite a lot of frustration but we got there in the end... Our camera is over the shoulder where rotating the camera where holding right click rotates the character with the camera, and holding left click is a more free look camera so you can see around you while moving but then snaps back to the direction of the character when you let go. There were quite a few interesting bugs and whenever we squashed one 2 more popped up. One interesting one set the camera a random distance and direction away from the player after using the free look camera while another one snapped it back to the last position you let go of for the free look camera if you clicked left mouse button again. We slowly got rid of them through trial, error and some oft underrated luck. What we're left with is a smooth, intuitive camera that gives the player a large amount of freedom and control. On top of that we had a bit of fun with the character's gravity and jump strength to make for a convincing and fun superhero, definitely something to play with for future game ideas!   Thanks for reading this far it's been quite fun and interesting. I can't wait for tomorrow!
Up next - Finishing off a basic environment to test in.
- Adding in the target and working on its AI.



  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!