Alone at the Top Sprints

Sprint 1

       Welcome to the end of my first Sprint on the game "Alone at the Top." The process has been going well but has also been a bit slow for this first sprint. In comparison to the last game I was working on, the work I did for this game wasn't as much or as intensive. Then again, last game I was the level designer working on a maze that needed different sizes ready due to the physical prototype taking much less time clearing the maze compared to what we had planned for the digital prototype. This time around I'm the group's coder so instead of going all in working on the design for a level for a physical prototype, my job was to help out with the coding and make the materials needed to play our game. In the case of materials, I made the tokens seen below.

     In the token sheet there are three types of tokens: One player token, twenty-one enemy tokens, twenty-one collectible tokens. In hindsight if there had been another physical prototype, the amount of enemy and collectible tokens would have been cut down to one row of collectibles and maybe two rows of enemy tokens. Extras remaining are there for just in case something happens to the tokens you have at the time.

     With that being said making the token sheet went pretty well overall. Originally it was just going to be tokens with a symbol representing what they were which in a sense they still are. However, I came across the problem of the player needing to keep track of both their health and enemies health in battle as without a UI like in a digital prototype the player needs something to keep track of their hp. So, I thought about it and realized if you made the symbols smaller and pushed them a little up there was enough space on the token for a place to put a place for max health. For usability, the current hp placement (left of the /25) was left blank so the player could constantly change it with a pencil.

     Alongside helping by making the sheet and parts of the rules to do with the tokens, I joined a group discord made by Trevor (the level designer of our group) so that we could all communicate easier than messaging each other in private messages or a group message. The reason we decided on a discord over a group message was because we could use separate channels to keep things organized. A general channel would let us do normal messaging, such as talking about what and when we planned to do tasks alongside checking if what we had currently or an idea seemed good to the rest of the group. For ideas that were agreed on by the group, we had a second channel where we would store the ideas so they weren't drowned in General so we could quickly look back when putting the ideas into the prototype. The third channel was for ideas that were to make into the paper prototype, which tended to be more fleshed out since we were prepared to make use of them.

     While it is very simple, the entire group ended up being very active in the server so whenever there was something that'd need to be talked about or a need to meet via voice chat, we'd end up being there within an hour. This namely helped each of us with our portions of developing the project that much quicker.

     While not too much extra, its also worth noting I helped make the questions for the playtesters review alongside Payton. (The modeler and project lead)

     That being said while I did have parts to do for this prototype, this Sprint I'd argue I had the least to do. Or at least it felt like I had the least demanding parts which is why I ended up also helping a little with the rule sheet and the playtesters' form. Of course that's going to be changing pretty soon, as next spring I have a more important role in the process of making this prototype, I get to do the code for the digital prototype. This'll include making a working grappling hook, UI, hopefully battle system, and a bit more. It'll be a nice change of pace going from just helping a bit to having a sizable chunk to work on.

Sprint 2

      Welcome back for my second sprint review. This is the first sprint where our team has made progress on the digital prototype, and it feels like I've made pretty good progress on my part of the prototype this time around. Due to not making progress on the digital prototype last sprint, true to its name these two weeks have been quite the sprint.

      So getting right into it, the first and most important part I worked on was the code to make a playable player. This meant giving the player the ability to move, jump, grappling hook, collect key and gun. Moving left and right came about with next to no issues, after all I just needed to make the player move left and right. Above and two pictures down you can also see another part of the movement where the player is rotated depending on if you're moving left or right. In the picture you can see the player is facing left due to moving left prior. (Worth noting, the rotation wasn't just for the looks, it has an important function that I'll talk about later)

     Alongside the ability to walk as basic movement, the player was given the ability to jump so they could reach or grapple to higher places. This was about as easy as the walking ability, although came with a bit of a catch. Due to making the jump feature in a weird way, a glitch was noticed by another team member where the player could hold forward and jump at the same time to infinitely climb the walls. While trying to fix this bug, we noticed it actually worked pretty well with the game idea we currently had and found it quite. So, I ended for the time being leaving in weaker version of it. 

     For now, the player can climb a little higher if they jump onto the wall and then will start sliding down after a couple seconds of reaching their peak climbing height. This ability works together with the grapple hook to let player's climb up to higher places. I plan in Sprint 3 to clean up the code so that glitches like this aren't in the game anymore, however assuming we keep with our current plan the wall climb glitch will be coming back as a properly made wall climb mechanic in Sprint 3. 

("Properly made" since as of now the player can just let go of the wall and grab it again to refresh the climb as its a glitch. Its still being kept in the game in this state so we can test the feature)

     Up next, the royal pain of the player parts, the grapple hook which is currently the green square in the image above. This is both the main movement mechanic of the game, and also was the hardest part of the player to implement. In its current form, the player left clicks anywhere to the left or right of them and the grapple hook will be shot in that direction. If the grapple hook reaches its max length or reaches the place the player clicked, it will then fall until it hits the player's Y value. (or instantly disappear if shot below them) The hook will disappear if it hits a wall or an enemy, where if it hits a wall the player will zoom to that direction or if it hits an enemy it will kill the enemy. 

     The grappling hook started off with bugs where it caused the player to ignore walls, and wouldn't collide with enemies for a bit. The enemy glitch was a simple collider problem, but the wall glitch was very persistent. It once allowed the player to infinitely fly in a direction and infinitely climb a wall by getting in front of it. (prior to the wall climbing glitch, gravity options was the plan to let the player jump up off the side of a grappled wall) Once an alternative found, the grapple would then spawn to close to the wall causing the player to be pushed into the wall when they moved to the grapple hook position.

     As of now the place the player is sent is sent a bit farther away from the wall to weaken this glitch, however it is still possible to brute force yourself into the wall with a grappling hook. Alongside the jump code, this part of the code will be changed in the next sprint to hopefully stop the player from getting into walls.

     Up next are the final two parts of the player I worked on, player shooting and key pick ups. Player shooting is what it sounds like, the player will shoot a bullet (the yellow circle on the leftside of the screenshot) when they right click. The cooldown is low, the range is until it hits a wall, and bullet speed is high which makes it the ideal weapon for killing enemies in this game vs grappling hook. Its downside is you can't shoot if you're grappling, you can only shoot left or right, and after 5 shots it takes a little over double the time to reload making the grappling hook still a niche subweapon for the player to use that doesn't overshadow the gun.

      Overall it was simple and there's nothing too much to note about the bullet, aside from minor mechanic from before. The player can shoot left or right, and this depends on if they moved left or right last. This is the other reason i caused the player to rotate left or right when they moved, so the bullet could see where they were rotated and choose where to fire based on that.

     The other part of the image shown here is the key. (The yellow key shaped object to the right of the image) The player can pick up keys and count how many they have. Due to this, it was pretty simple as well, although was a bit of a pain due to neither naturally having colliders due to being models causing detection issue for a good bit. Overall however, was completed with no actual side effects.

     Now for what has been done and going forward. I've mostly gone over what I have done to this point, only missing certain parts such as giving the player health and the ability to die to zombies and setting up Unity Teams for the team. The only thing not yet put as complete is the ability to shoot and the ability to pick up keys as of the time of this blog post. By tomorrow however, our game manager has communicated those will be double checked and moved depending on how it looks.

    From here, the plan is to quickly finish up the doors either tonight or tomorrow morning, (as that is the last part of Sprint 2 that I have not yet finished that we added a little into Sprint 2) and then the plan is to move onto Sprint 3 extras until we do our proper Sprint 3 kickoff. One of these extras is quickly making a UI due to somehow forgetting a UI would probably help our character play this game since seeing remaining hp, bullets left before reload, and how many keys you have affects your gameplay a bit as a player.

     Aside from that, Sprint 3 currently is planned to be bug-fixing (Especially for grappling hook and jumping) and allowing the door to move the player to level 2. The rest of what I'll do will be discussed in our Sprint 3 kickoff to see where we are now compared to where we expected to be.

    Overall, much in contrast to Sprint 1, I feel I both completed everything on time for the work I was given, and I properly contributed my portion to the team. I'm looking forward to what Sprint 3 has to bring.

Sprint 3

      As Sprint 3 comes to an end, so comes another Sprint Review. As you can probably guess from last sprint, this was bug-fixing sprint where I fixed the bugs of last sprint. Alongside this we had a playtest of the game, so there was also modifications made to better suit the feedback we got.

     So starting on what got done, it was mostly bug-fixing, feedback, and some of the on schedule sprint 3 work. To quickly go over the on schedule work, the bottom (fourth) trello task was just the respawn from in between sprint 2 and 3 that I went over last blogpost. The third trello task of collecting collectibles meanwhile was just similar to a smaller collect key function so not much of either is worth going over. The one thing worth going over is that the collectible ended up being modified with the key this sprint so that they're both easier to collect by making it an is trigger object.

     So with those two out of the way, onto the feedback and bug-fixing. While the other tasks were labeled 1 pointers, these were labeled 3 pointers doing to being the long taskers in comparison. The first one to get worked on was the jumping code as I realized shortly after making it I could of made it much cleaner. How it works now is that once the player enters the jump button they'll rise to their jump height and then just start falling once they reach the top. The player regains their ability to jump once they touch a wall or floor beneath them, so basically just the ground.

     As simple as that sounds, it ended up making jumping much smoother alongside patching up a decent amount of glitches. The amount of spaces taking the player's jump got lowered, although there are still a couple of problem spaces where the player can be standing on floor/wall and the game will just say no.

     With that in process, it also drastically weakened the wall climbing glitch, again. Not intentionally though as we assumed the glitch died. The players may no longer infinitely wall climb up the walls. The downside is that wall climbing glitch is more just for aesthetics at this point since it can't help the player's climb to anywhere, including ledges. Alongside that it didn't get much testing during the playtest because we ended up completely forgetting about it during, and didn't tell the playtesters. Wall climbing as a feature is currently not being worked on either, if it does get worked on it'll most likely be in Sprint 4 as to make landing on the side of the wall with a grappling hook useful.

     That just leaves the grappling hook, which is somewhat improved. The grappling hook's ability to send people through walls has once again been significantly weakened. The grappling hook movement, has been made both slower and smoother. Alongside the jump was what feedback was noting the features needed, minus the slow down as one feedback wanted it faster. Due to speed being the main thing sending the player through the wall due to momentum, that wasn't possible with the current coding.

     The grappling hook now sends the player right where it lands, as before it shifted the player to keep them from going into walls. The grappling hook no recognizes if it lands on the top of the wall or while moving side to side, and due to this its able to know to let the player go through the wall or not based on where its sending the player. 

    One last thing before leaving the grappling hook, there was also a trail added for the grappling hook. This is due to people wanting it to look more like a grappling hook by letting there be a rope and an actual hook at the end. Although will admit, at this point it works more akin to a Wind Waker's hookshot with a thrown grapplehook physics. Although then again that's more of how real life climbing grappling hooks work, less swing more keep you steady as you climb.

    While I've completed those assigned tasks (7 points total unless you count respawn) there are still technically 2 still assigned and not completed. The first one, the UI, was on my to do list once the keys and respawn were both completed. Likewise, the player being sent to the main menu after losing was added during our sprint 3 kickoff. However, both were sent to the back once feedback came in and bug fixing/feedback took priority since we now knew what needed to be done this sprint. 

     The UI is currently being worked on and will be completed soon, however being sent to the main menu after losing was agreed upon to be done either at Sprint 4 or if I had time once the UI was done. Its still Sprint 3 as we assigned it in Sprint 3 so we knew better than to change it at that point.  Alongside this, a minor combat change is needed to where the gun needs to be nerfed in reload speed. Its very minor (as in a change to one line of code at most) but was something feedback asked for so its on the todo by the end of today.

     With that, that is this Sprint Review over with more or less. While I don't feel like I was as productive as last sprint, I do feel like I did about the same amount of work as Trevor our level designer. However, most likely still did less work than Payton as he seems to do the most work overall each sprint. Overall, I feel good with this sprint, but feel like I could've done better.

Sprint 4

      Sprint 4 is almost over at this point and has overall been a great sprint. This sprint was the Combat Sprint, where my focus was refining the combat aspect of the game overall. Alongside this we also ended up having a playtest at the end of the sprint which both added a time limit for what we wanted to get done at minimum by that point of the sprint.

     So for what was finished this sprint so far, a few things were finished. I made it so that the player could go from level to level with their data intact. This data included their current lives, hp amount, collectibles collected, and the level they were on. Alongside this the player could wall climb using the grappling hook. This fixed one of the biggest issues with the grappling hook last sprint where the player would be punished for grappling the side of the building. Now, when they grapple the side they can climb up to the top if they aimed high enough. Alongside this, the enemies reset on player death. This was to make it more challenging for players who have died and are getting back to where they went as players wanted increased difficulty.

     Alongside those comes the most important part of the combat sprint, the update to zombies. The zombies got multiple buffs to what they do, the biggest buff being a change in movement so they turn based on X position instead of collision. This keeps us from putting up boundaries that don't always work on zombies causing them to sometimes be stuck or run off the edge. Alongside this buff, the zombies now randomly jump which also happens to switch which way they move when they land making them much more of a threat when running around them. Their hp was buffed to now exist instead of dying in one hit, alongside they now do damage instead of killing the player in one hit. Overall, combat now exists compared to before where it could occur without any actual challenge.

    The flying zombie got similar hp and movement buffs. The main difference was instead of a random jump, the zombie now swoops randomly to attack the player. If hit with a grappling hook, its speed slows by 60% and it stays at swooping y coordinates to award the players for creativity.

     To close it off, here is a quick look at what hasn't been done. Adjusting the game based on player feedback and second type of health kit. The second type of Health Kit is part of the combat sprint and is actually something I plan to finish tomorrow at the time of this blog post. It should be done before the next sprint kickoff. The actual one that won't get finished before next sprint is adjustment based on feedback. However this is because we initially mistook the playtest for a week prior to when it actually occurred, and thought there would be more time for adjusting based on feedback. Due to the time being a week later, we chose to let that one stay until next sprint where we'll properly divide it out during kickoff.

    With that, overall this felt like a very progressive sprint. While the most points weren't completed (6 points this sprint vs the 10 last sprint) it does feel like I got just as much if not more done. The main difference is that none of the work I had this sprint felt big enough to justify 3 pointers. The groundwork of combat is laid down, and next week I should just about finish it alongside polishing the game. Next sprint should see as I noted polishing of the game alongside a quick update/nerf to the gun to top off the combat fixes.

Postmortem

      It is now the end of sprint 5, and as such is the end of the time period for working on Alone at the Top. As seen in the picture below, we ended up getting down with all the tasks we had prepared in the Trello board. So with that said its time to take a quick look back and see what worked and didn't work.

    With that said, there was a good amount of actions that went right within our game development. For starters, we had a great job selection where everyone in the team got put in a role they could make the most of, at least in comparison to how the rest of us could of made it. Payton was assigned the role of project lead. This worked great due to Payton being the person who came up with the idea in the first place, and the direction he wanted to take in learning from college being how to lead people to make a game. He was also assigned the role of modeler, which worked out since the prototype wasn't meant to be too heavily artistic in its early days letting him help out in both coding and level design where needed. I was assigned the role of project coder, which worked out as well due to coding being the job I'm specifically taking classes for. Trevor got the level designer, which worked much better than expected once he started putting together creative designs for the levels.

    Due to everyone getting jobs that best fit them, the actual game making process didn't really have too many issues. We were mostly on time with our assignments, and finished the prototype without working against the clock at the end. Of course, us getting the right roles wasn't the only reason for this. Alongside this we made a discord server to work together, constantly talking to each other on progress of what we are doing/getting done, getting opinions from each other, and of course letting each other know if a problem arises. This helped us get past blockades along with keeping each other from being blocked in the future by constantly seeing where we were and what we needed. Overall, definitely something we should keep doing.

     That being said there were some issues we had, two big ones to be more specific. Back in sprint 1 we had this issue where we focused too much on art for the paper prototype, and on top of that didn't give enough attention to the actual gameplay or assets that'd be needed for the digital prototype. While part of what we can do to not have that issue again is to focus less on artwork, an important way we can work on dealing with this issue is to also start working on the foundations of the digital prototype once the physical prototype is finished, even if its still the sprint prior. Speaking of, we had a second issue where we started sprint kickoffs typically on the Tuesday of, which meant our sprints typically were delayed for about 2 days until we began on them each weak. This means we did sometimes end up not doing much of the current sprint work each sprint until 2 days after it should of been started. A bit obvious, but a way we could better ourselves for this next time is to have our sprints the day that the sprint is supposed to start rather than waiting for the day of class where we were doing so before.

    Overall this was a great experience to learn from, and I look forward to the next group game that'll get worked on.