Week 1: (Thur 1/15) Project Proposal
Progress wise, our team has decided on the game concept of having a computer manipulator and a platformer game character work together in creative ways. As of now, our team has a general idea of how the game would work but specifics and details will be reviewed next week due to time constraints of our current required deliveries. At the very least, we have completed our project proposal and received critiques that do not require major revisions to the original game idea. Though production wise with respect to other teams, we seem to be a little behind when it comes to how much current thought the games we are working on have.
For contributions, the tasks I worked on are the content of the Title page, Timeline and Prototyping of the game proposal and the notes during the presentation. I digitally drew the rough image encapsulating the theme of our game, though realistically we won’t be using stick figures in our final delivery. I also took on the role of note taker during the presentation, not only recording critiques of our game but details and critiques of the other groups so our team can gather some inspiration and grasp where we are in terms of quality. As the one in charge of QA, I will make the effort to keep track of not only our game but the others as well to ensure our quality does not degrade when displayed with the other groups.
One thing I identified during this milestone was that our game heavily depends on the first impressions players get when they play our game. Players who are not invested within the first few minutes of our game will not have the motivation to continue to see the rest of our game.
Hence I suggest during our next meeting that we focus on the first initial screen and dynamics to keep our player engaged with our game. Another thing I identified was that although our game is simple progression wise, we also need to address the concern of having our players blindly check every interactable object in our game when they get stuck on a puzzle. My thoughts on this issue would be to incorporate the computer to make diegetic UI into the interactable object in a way that a computer user would think “Maybe I can drag this menu around” or “Maybe I should hit these boxes differently and see what happens”. The last major concern was that either the game character or the computer manipulator might not have the same workload as the other or might want to switch controls. Ideally our team would design our levels to give the same workload on average but changing difficulty based on the task. Or we could occasionally swap the roles but keep the controls, like the pc controller player controls the game (Like Arkanoid) but the game character is running around the pc environment.
Week 3 (Thur 1/29) Game Design Document
This week, our team focused on ironing out the objectives and core gameplay loop along with the completion of our Game Design Document. Since our game operated on two players performing different actions to work together, our team looked into similar styles of our game as inspiration to understand what works with this format. We also narrowed down the key objective of our game to be finding hidden dev backdoors through each level and to reach them with the help of the maker. As of now, our team has ideated some realistic additions to improve the engagement of our game given our current timeframe so we don’t feel like we placed too many features on our plate. But our team should prepare for the strong feedback that comes with our playable prototype of our game.
For my contributions within this timeframe, I worked on creating the functional flowboards and each additional image on it (except for the slime enemy):
Since I was more focused on demonstrating how the game works and how each player interacts, I created a simple placeholder character to bring our team’s vision to light. Realistically, our character designs would look less minimalistic than our flowboard so don’t take the images to be what the final product will look like. At the very least, I believe I have accurately documented how our game would work with minimal confusion. Or at least that’s the impression I got through the critiques after our group’s presentation.
Last milestone, we received some feedback for how each player would know what they can interact with and how would you balance the gameplay between each player. For the first critique, our team decided to use the idea of “Strangely out of place” assets to indicate that that item can be manipulated by the maker. They also have a yellow highlight around them to make it more visible if it wasn't obvious enough. As for how we chose to balance the gameplay between the mover and maker, we decided to go with a model that rewards success when the mover and maker work together to reach places. The maker would be in charge of creating structures or utilizing asset physics to help the mover to reach places. The resolution of our game is binary, you only win if you reach the dev backdoor of the level, so there’s a notion to assist with the other player. For the maker, they may want to stop enemies or obstacles from interfering with the mover. For the mover, they may want to take down nearby enemies to allow the maker to build a path to a suspicious area. Some critiques we will address is the concern that one player can just operate both roles and that some of our diagrams show resolution as separate between our players. The latter will be fixed in our next GDD and the first will rely on how we implement our puzzles. We most definitely are not going to complicate the control scheme just so ONLY 2 players can play the game.
Week 5 (Thur 2/12) 1st Playable
This week, our team has completed our playable prototype of our game and revised our GDD to take into account feedback based on our external playtests. At least from what our team understood from the playtests, the balance between each player’s gameplay and communication is a core part of our game. Hence our team will learn towards this idea to design our puzzles and challenges. Our revised GDD has incorporated a few diagrams for smart depth and playtesting to keep track of what core ideas and decisions work with our game. In terms of our game, the core systems work quite well in a multiplayer setting. Some things that need to be done is some reformatting of the code to be flexible to add to other levels and visual assets that can be prefabbed into our game world.
For my main contribution this week, I hosted one of the three playtests with an external playtester so our team could revise the game based on our feedback. Our main design questions our team wanted to verify if our gameplay was once sided between the two players and if the controls and mechanics made sense.
Based on the feedback that I collected, the gameplay during the playtest involved a good amount of communication between the two players, which clears out the concerns about one-sidedness in our multiplayer game. As for controls and mechanics, our assumption was that players would automatically try out the different buttons and learn what they could do based on that. However, the mouse player would often ONLY use the left click button, which meant that we needed a way to clarify that they could use the scroll wheel and right click with the mouse. As for mechanics of the puzzle, the most prominent one was the buttoned door puzzle. Although the cause is not quite clear, many players seem to struggle with the thought that the maker could drop a box on the red button to open the door. However when they overcome the puzzle, they have an aha moment and a short celebratory session, which could be an argument that the puzzle was good design.
As for reflection, many parts of our game need to be polished up before the alpha code for the next milestone. However, I personally think there’s an issue that our team does not have a clear vision of what we want our game to be. This coming week I want to resolve these ambiguities as soon as possible so I will prepare some potential designs and assets to ensure our team has a solid design pillar to work with.
Week 9 (Thur 3/11) Alpha Code
This week, our team has completed our alpha build, which is a single linear level meant to teach and test the players' understanding of the game mechanics. Our assets fit well with the narrative and the game is enjoyable to play with other people, as evaluated from our playtests. Our revised GDD that focused on level design documented the various ideas and patterns we felt our game would make use of as we go towards our next builds.
My contribution for this week was focused on providing as much of the bare mechanics of our games as possible so that our other members can incorporate their additions to the game. In particular, I worked on the level design layout, Anticheat script, and animated the mover’s sprite sheet. For the level, I first started with a low fidelity figma prototype to gather ideas of how the puzzles can be designed. Then I quickly made the level in unity and textured the floor to give it a scifi look with the cyan highlights and mechanical yet simplistic time palette. For the mover’s Sprite, I grabbed Ally’s sprite sheet and modified the animation and bounding boxes of our first build to follow the character’s actions while fitting in the level. For the anticheat, I designed it with our group’s idea of following the player’s movement; copying the player’s sprite, turning it red. and applying an after image effect to give a sense of danger to the player.
From the feedback we got, it seems like most of my ideas conveyed well to the playtesters and the reactions documented were fun to read. One problem we found during our game development journey is that the anticheat has an overwhelming pressure for technical parts of our level. For our alpha build, we chose to increase the player’s headstart such that there is more time before the anticheat reaches the player. This idea on its own is good but I would like to try adding a way for the maker/puzzler to stop the anticheat by ragdolling them with platforms if the anticheat collides with them with their head. This would make the anticheat sections more forgiving as you can decide to knock the anticheat out for some time to get more time to think. Additionally, we were told the mover felt like they weren’t committing much to the game so we may consider giving them a new power for level 2.
Week 11 (Thur 3/26) Beta Code
This week, our team has set up our beta build, which fixes some issues and introduces level 2. The changes in this version of our game is focused on improving the functionality and engagement of our game based on feedback from our alpha build. For additions related to gameplay, we added a stun mechanic against the anticheat such that blocking/hitting the anticheat’s head with maker blocks stun him for a short period of time. The 2nd level also introduces a new mechanic in buttons to keep the experience fresh but not complicated. As for GUI, our team could not finish them in time but hotkeys for the controls are working (1- delete, 2 - 1st block, 3 - 2nd block).
For my contributions, my role focused on the functionality and feedback of the game elements. More specifically, I fixed the problem of ramps not allowing you to jump, implemented the stun mechanic which introduced different states to the anticheat, and added firewalls and laser pits in the chase sections of both level 1 and 2, and designed and built the layout of level 2. Besides the implementations in code, I also made some assets to go along with the added behaviors like stars when stunned, fire and bricks on a firewall, yellow triangle on the crashed characters, and a simple image for the ‘laser’ that the player is expected to drop the anticheat into. This more or less handles all the functionality of our game in the 2 levels, meaning we most likely don’t need to go back to fix things.
Anticheat Stun behavior
Interaction between firewall, anticheat, and laser
One thing I identified with our game is that as the game grew larger and our puzzles got more challenging, it became more difficult to properly playtest our games within the allotted timeframe. For the sake of time, we had our playtesters play the level starting from level 2. This choice brought the problem that our feedback might not accurately reflect the player’s experience from transitioning from level 1 to level 2. This issue also ties into one of our creative conflicts we had about how the chase sections behave, where some say they feel unfair that the anticheat speeds up a bit after stun, meanwhile I’m concerned about the anticheat becoming trivial to the chase if they are not given a catchup mechanic (following 1000 frames behind the player might as well not be following at all). This makes it difficult to verify whether we should adjust based on players who skip level 1 or played the whole game. My current implementation of the anticheat allows the player to stun when the anticheat is pursuing the player (drop a block on him) and has him rubber band through the player’s recorded movements when they are too far behind in the playback. I believe this preserves the pressure aspect of our chase sections without making the chase seem onesided, and I find it difficult to agree with the feedback that the rubberbanding should be removed.