Body Jumper

Body Jumper Postmortem

This project has definitely been a huge learning experience. Not just the hard skills gained from all the bug fixed and figuring out how to implement features, but also the soft skills of communicating with team members and learning some of my current limits.

Overall I'm very pleased with how the project went and what I was able to accomplish as a leader. The game got it's core mechanics done very quickly allowing us some good polish in the last couple of sprints, no crunch was needed to get our projects together, and I think my team has grown as developers as well. 

Additionally, I'm very happy with the gameplay loop we made. It was very sped up, but the idea could definitely be used in much greater capacity in a long-form game. There is more that can be done with this idea, and the design is a bit lean, but the prototype I think accomplished it's goal.

Another win for this production time was the communication. We met usually twice a week to work on the project which I think really helped to ensure that we didn't lose work due to GitHub conflicts. This was something I very much wanted to focus on with this project because it sounded like the bane of many teams last semester both here and in more advanced courses. Having our repository tidied up and everyone knowing how to work in their own branches really helped smooth over many of the logistical issues I had seen come up before.

One issue that did pop up in this project was the ordering of tasks from my end. I did try to be conscious of which tasks needed to be completed before others and make notes on the cards if it has prerequisites, but I often didn't prioritize tasks in the backlog correctly. I should've had the needs be a lot smaller, focusing on exactly what I wanted to get done. In my head I wanted to put enough into needs to fill out everyone's sprints when in reality I should've made it smaller than that to guarantee certain sections of tasks get completed.

Another issue that came up was that with the camera. This was a core feature of the game because our game was a fast paced, 3rd person action game and making sure the camera wasn't in the way was very important. That being said, it took up a lot of time to get the camera in a working condition. Because this was not a feature we could cut, we had to take the time loss on the chin. What I think we should've done sooner was search for outside help. Even though we weren't able to make the camera work in exactly the way I wanted it too, we at least got something functioning in a way that was playable once we got help with it.

In future projects I think I'll continue to put a focus on making sure our GitHub repository is working correctly. I think that worked well for us, and will continue to help us avoid bumps in the road later on in production. I also think the amount of communication and planning was also good as it kept the whole team on the same page about what was being worked on and when. However, I think in future projects I'll definitely be looking to optimize the way I doll out cards to my team members so that there's less confusion of what card comes first and to also prioritize the backlog better so that there's less back and forth for me trying to keep my tasks up to date. I also will be more proactive with my team members suggesting outside help when they get stuck working on core features that the game needs. With all those changes, I'm sure my next project will not only run smoother, but be able to achieve much more in the same amount of time.

Sprint 4 Review

This sprint was a hard one. A few things came up that were impossible to foresee that affected me outside of my normal working routine and I don't have as much work done as I would like. More over, a lot of the work that I was doing for this sprint was also just bug fixing, and thus, not available for cards. However, I did still get work done, so lets get into all that.

First task I did was a bit of a shorter one. I made a script for doors and windows that will give them a chance to be open upon starting the game. By "open" I mean turned at 90 degrees. For this I just made a couple cubes in Maya so that I could control their pivot point, brought them into Unity, and away we went. Nothing to fuss about here except that the camera doesn't seem to respect them like it does the walls, so I have to figure out how that was coded to see what's going on with that.

The second task I did was to make a tutorial splash screen so that I could teach all of our players how to play the game. I wanted to introduce them to the goal, the premise, and what all the different cubes meant so that they had an understanding going into it. A couple things about this had some hiccups, but it was only seen after we started playtesting. Firstly, the UI was built for 1920x1080 and we played on an ultrawide monitor, which completely broke how the UI was set up. For that one I had to make a build that set the resolution so that players saw how I wanted the UI to look. The second one is that the players didn't read it! I should've guessed players weren't going to read a tutorial, but I figured for a prototype in our prototyping class that they would! Many players loaded into the game and assumed it was like the last version where you infected people just by jumping to them, and didn't remember the control from the second screen telling them to hold the right mouse button to infect. I guess I need to make the tutorial more available, or actually put it into the game as a reminder of how to infect humans, just so I have an appropriate amount of redundancy.

The last task I completed this sprint was to make a working build. This one turned out to be a lot harder than I expected because there were just a number of little things that were out of place that I had to diagnose and bug fix. The UI of the player would overlap text on the upgrades screen, for some reason the game manager would disconnect from the player when loading in the play screen the second time around, even though it said it was connected to what was there, the upgrades screen would keep reloading for some reason, all these little things made the build not work and had to each be individually addressed. The UI I had to child to the game manager and turn off and on when entering or exiting the play screen. The game manager disconnecting I solved by literally just telling it to reconnect everything when it reset the game and that seemed to solve it's issue there, but that took a long time to come around to as everything in Unity was telling me everything was connected just fine. The upgrades screen constantly reloading actually came from a bug involving the health decay. The player loses health a little bit every tenth of a second and we used an InvokeRepeating function to do it. However, because the player was still active in the upgrades screen, this function would run and find the player was at zero HP and then triggers all of the dies logic over again which included reloading the upgrades screen. It took me a while to parse out that is what was going on, leaving me confused for far too long. All I had to do for it was stop and restart the repeating function when the player died/ started a new run and it was good to go but my goodness did I have a hard time getting there.

After all that bug hunting and making the build, I still eventually had to make a second build after some of our initial playtests because I couldn't test to see if the build I made had a consistent resolution or not. It didn't, so then I made one that did for reasons stated above and everything worked out just fine.

Unfortunately this is the extent of my work for this sprint. It ended up being a very light one, that's for sure, but it was still very important and very needed work and ultimately lead to a very well received playtest. Overall though, I'm very happy with where the project is at, as we have a fully functioning game now! It's very short, the gameplay is thin, and there are still bugs, but it's a complete loop which makes me very happy.

Sprint 3 Review

This sprint I was able to get a lot more core functions in the game up and going. I was really happy with where we ended up and the work we all got done overall. It's getting really close to being a whole game loop and so that gets me really excited!

The first task I worked on was implementing out "navMesh" into the first map so that all the humans had ways to move around. This ended up being a lot more tedious than I first expected as the way I had it coded and shown, a line would be drawn when one spot is connected to another, but that line could be just one way, not allowing the human to travel backwards. This meant I had to mark each of the marks that I had completed paths for so that I could keep track of which paths I had fully completed instead of just half. That's what all the green dots are the map are as they gave me a visual for completion.

Next I made sure to get our playtest form updated so that I was asking more appropriate questions. Some of the questions on it were meant to be asked for every playtest and those stayed, but others were meant only for the paper prototype. This time around I wanted to know more about the feel of the movement mechanics and how fun they are, what parts are and aren't fun, etc. This ended up giving us great feedback for later so I was really happy with the questions I asked.

The next task I worked on was making functions for upgrading stats. There were a couple parts to this. The first was providing public lists that allow us to control what upgrades a player got. Making it public lists also meant that we could see all of the available upgrades at once and change them very easily. After that, I made functions that would not only upgrade the chosen stat by the given public amount, but also would check to make sure the upgrade was only the next upgrade for the given upgrade path. This was so if the UI layout we ended up with allowed the player to view all the available upgrades the player wouldn't be able to buy upgrades that aren't the next upgrade.

This one I'll admit, I overengineered. What I wanted was a way for the player to see when a human was within range of the player so that they didn't get frustrated trying to jump to humans out of range. This end product is effective for what it needs to do but took way too much effort as compared to a crosshair that changes colors. I didn't even think of it when I was doing this task and I have no idea why. If I were to do this again, I'd definitely have some sort of crosshair change on Raycast hit within range rather than turning on and off a marker sphere.

The next thing I had to do was make a working build for the game, and in order to do that I had to make a spawn manager so that we have humans roaming all over. This was originally assigned to another team member but because they were busy on their own card I decided to take it on as it'd be easier than manually placing 95 humans and attaching them to patrol points. I also had to make sure that the player could die and respawn and restart without the game breaking. It did eventually break in a playtest later, but I was able to figure out what what triggering the break as more playtesters encountered the bug.

The last series of tasks were all about making the infection process more layered. From the beginning I knew I wanted infecting to take both time and health from the player to add not just more categories the player could upgrade, but so that the process of getting points and avoiding hunters was more dynamic and had a bit more tension and challenge, so that's what I worked on making happen. First I started with making sure the player didn't infect immediately and actually had to press a button. After that, I made it so the player had to hold that infect button. I made sure to also add a UI element of a bar filling up so that the player had some feedback as to what was happening while they were infecting the human. 

With these contributions and other team members adding things like correctly working camera and an upgrades screen, we are so close to having this prototype totally complete! Next sprint should have all the pieces coming together for this awesome prototype!

Sprint 2 Review

This sprint I did a lot more in making the actual game and it felt good to get into it. I also got to work my design a little bit for what I think will be the better and I'm happy for that. The game is now in a place where it's basically playable, it just needs a map more interesting than a flat plane and maybe getting the upgrades system going but other than that, you can look around, jump from person to person, get points, and eventually die. I'm pretty happy with that!

First thing I got going was to make the player input system as I thought it would make putting in additional controls later much easier to do. What's interesting is one of my other team members actually ended up implementing some of the input system in trying to debug their code, so I went in and set up what I thought would be an appropriate 3rd person control scheme for our game just to get the groundwork done.

The next thing I worked on was pretty fun, even if it was short lived. I wanted to design a system for the player to gain back health during a run in response to some of our player feedback. I really enjoy working out design puzzles for player mechanics. As per usual I started with what I wanted the system to do and what I wanted it to not do. I wanted the player to be able to heal but not indefinitely, something that wasn't abusable or infinitely repeatable. I first thought that maybe the player could gain health if their host was near something in the environment that healed, but I figured that might cause more frustration than fun. Then I thought about a health pickup the player could run into with their host, but I didn't want there to be a requirement of moving the host to get health. What I eventually settled on was a new class of human called "Vulnerable" that the player would gain health for infecting. I liked this because it was more dynamic in the world and allowed the player to take initiative in choosing their health. I also liked it because it was something else we could have in our upgrade system where the player could gain more and more health from vulnerable people but could limit how many are spawned at a time.

I next wanted to continue onto making Hunter enemies so that the player had some obstacles but I first needed to make a damage system to actually make them a threat. I implemented a very quick system that triggered "damage" from pressing the spacebar. I left the system flexible to work with our healing mechanic later though. So instead of the function strictly taking health away, it could be called with any number and simply adds that number to the current health, checking if the player would hit their max HP for heals or die from damage.

With that out of the way, I could focus on making Hunters. I made them red because I wanted to really make sure they stood out from the environment and other humans. That and we don't really have an art style for this prototype besides programmer art, which works for me. I added a logic script for the hunters what would handle all their damage and movement. Because I'm thinking we're eventually going to have all the humans spawned through a spawn manager, I made the script as a part of the human prefab, but told it to nuke itself if it wasn't on a human type "hunter". The damage on contact wasn't a very big issue, just an OnTriggerEnter that calls the damage script with whatever the hunter's damage value is. The movement was a little more tricky. Because we have a node based movement set up, I tried to make it so the hunter set it's nodes equal to the player's host's nodes, but that didn't end up working out because the hunter would end up sending itself off to space. That's just how the movement was made so I made a work around that I actually ended up liking more. Instead of using their traditional movement, I had a hunter switch over to a chasing movement when they detected the player. This not only worked as I had control over this new movement but it also allowed them to follow the player not on the lines of the nav grid. I liked how, almost uncanny, this seemed in a world of straight movements and made the hunters feel even more threatening.

Next sprint will be a playtest of our electronic prototype so I'll be excited to see what we can pull off for the first playtest and what kinds of feedback we'll get. I'm hopeful it'll be positive and people will like the game mechanics but I guess we'll have to wait and see.

 

Sprint 1 Review

For this sprint, my focus was on making the paper prototype. As the lead designer and having not a ton of documentation or time to convey my vision to my team members, I thought it best that I take this on myself. I thought that it might also be a good way for me to help show my vision to my team a little bit more, and help cement the correct idea in each of their heads as to what this game was going to be. This being a paper prototype of a real time, 3rd person game though, it was a little challenging adapting it for paper form. I couldn't think of a good way to have the gameplay run in real time, so I made it turn based. Player jumps to a human, humans move, repeat. The point of the play test was to see if the general concept of moving by "jumping" from moving person to moving person was a fun idea or not. With all this in mind, I went about making the paper prototype.

After deciding on the rules this is the initial map I came up with. I wanted it to be generally pretty small as to not give too much complexity to the movement and also to make less work on the AI (me) in moving even more humans each turn. I set up some obstacles, buildings with walls the player couldn't jump through, things like that just to give some interest to the space and give at least some blockers to the player's progress through the level.

Next I scoured around my house to try and find some little game pieces I could use. I wanted to find a piece for the player that could fit with the humans somehow so that it would be easy to "jump" their piece from human to human. I ended up finding these tiles that I had painted a while back that came from a game called "Upwards". All the tiles stacked perfectly on top of one another so it was a great find for the playtest!

There were a couple of other things I had to sort out, upgrades the player was going to buy, the player's base stat sheet, etc that I had to do, but I was basically ready for the playtest, and boy did that give us some awesome information.

We got 4 playtesters for this prototype and they gave me some valuable information regarding our movement mechanic and the game as a whole. Players really liked being able to jump from person to person. They only wished they could jump more often. Players all said they had fun, all were very interested, and the two who responded to the survey said that they'd like to play more.

This was all great news for the prototype moving forward and it got me excited, but I also learned a lot about the map layout and player movement as compared to human density.

With the player stuck only moving based on where the humans moved, the overall density of those humans on the map was huge. Too many, and the world is your oyster, too few, and there's nowhere to go. Also, the players are naturally going to gravitate towards the bigger, more open areas because that's where the most humans can be, uninhibited by the terrain. This will be something to keep in mind when we move towards building out the map in the electronic prototype, that open areas are naturally going to be hotspots for players to want to go and stick around to get the most infections possible. If we want to pull them away from those areas, say with a VIP person that gives more points, we'll have to account for those public areas giving a lot of points per minute compared to traversing the level for one particular human. It's possible we might have to make a second currency that these give just so make them important enough to pursue.

Another tidbit I picked up on during the playtest was the player pathing, or really, lack thereof. Because there wasn't quite enough humans, and the player was limited in how fast they could move, they were almost always forced to jump to whatever human was closest and just see what happens. For our electronic game, we'll need to be mindful that with lots more options of people to jump to, players will be trying to plan their jumps between people. If the people move too erratically, they could get frustrated, feeling like the game is punishing their planning. We may need to introduce some modifier to the player's current host that makes them pause for longer, or make the pathing of the AI more predictable so as to mediate this potential frustration.

Unfortunately, I made this annotated map before we conducted the playtest, so I didn't have that data going in to make better judgements of how the maps should flow. However, I think my core idea in making the map still stands, so I'll explain my reasoning behind it.

I split up the map into four quadrants. For each one I wanted it to focus on a different kind of human movement pattern or a different way the player would have to interact with the humans. I tried to vary things like the open, outdoor space vs the indoor space, access between buildings and the outside, verticality, and visual obstructions so that each space played a little differently. I marked where I wanted there to be doors (ways humans could cross between outside and inside) and windows (ways the player could cross between outside and inside). I also tried to vary the location of the player spawn by how close/far the player is from open spaces or possibly well travelled areas.

For now we'll just block out the first, upper left zone to use as a playtest area, as it has all the key components and helps focus our implementation and playtesting more. Perhaps if we have time, maybe we'll be able to fill out the other areas and see how those map changes affect player decisions and how the game flows. Even if we don't, that first area should give us plenty of data as to what we should strive for and what we should avoid when it comes to the map.

Something that I'm giving myself as homework in this next sprint is something that actually came from a couple of the playtesters. 2 of the 4 playtesters expressed wanting some way of gaining health while they're on a run as the infection. In my head, I figured the player would be only getting upgrades between runs that would effect how long they could stay out. However thinking about it more, having a way for the player to gain health on the map would give more decisions for the player as to where they should go, more points of interest for them to weigh. I originally was going to have VIP people do that, along with Hunters that give the player areas they're trying to avoid, but places the players can restore a little bit of health would be it's own incentive. I'll have to come up with how that will look in game. I don't want the players to be able to indefinitely prolong their run, but I also don't want it to be a hassle to acquire. Playtesting will surely give us the precise data we need, but I still need to craft a system that gets us in the ballpark without breaking anything fundamentally.