CAGD 370

 

CAGD 370

Video Game Design

Post 5 Postmortem

During this time, my teammate and I finished making our game prototype called Pull Yourself Together. I was the producer on this project but also helped to code and design the level. Our goal was to have a fun prototype that had fun mechanics that could be built upon for the future iterations. Overall, the prototyping process was both rewarding and challenging, and it taught me a lot.

What Went Right

One of the strongest aspects of development was the successful creation of core gameplay systems like movement and grappling. I was assigned to focus on character movement and camera movement. This was a great start to the project and I was able to get back into coding. During sprint 2, I made a health component that could be attached to the player or any damageable actor. This meant the player’s blueprint was not as crowded and I could simplify the code. This decision made later systems, like enemies and environmental hazards, much easier to implement.

 

Another thing that I am happy with is the HUD and UI. It took a lot of time to get it working but the final product was worth it. Figuring out how to make the HUD reference the currently possessed player and update itself when the player respawned made me test my abilities in coding. Doing it was rewarding and it ensured that UI elements such as the health bar and health text stayed in sync with the correct player instance, even after the old character was destroyed.

The respawning system was also successful. I used the gamemode to handle respawn and possession of the new player to make the player character’s code neater. Spawning a new player pawn, possessing it with the existing player controller, and updating the HUD reference created a clean loop for death and respawn. This was also then used for the checkpoint system. It used the initial spawn point of the player at the start of the level and set it as the spawn transform. Then when a player would enter the checkpoint, that would be set as the new transform in the respawn function. Building these systems on top of each other prevented messiness. 

Enemy prototyping also went well overall. The turret enemy used many important gameplay concepts like player detection, tracking, projectiles, and visual feedback. Using the collision box I was able to trigger the enemy’s loop of turning red, tracking the player, and firing projectiles at them. Implementing dynamic material instances to change enemy color based on player proximity to the enemy also added clear feedback for the player. It was important to let the player know how to avoid being damaged by this very dangerous enemy. Other  environmental hazards like spikes were also easy to create using the existing health component.

What Went Wrong
After sprint 1, we were down 1 teammate so it was just 2 of us making this. This meant I would be doing a lot more coding than I thought and also rethinking the scope of the project. I am not great at coding so this project was very difficult for me and took a lot of troubleshooting. One recurring issue was reference management, especially when working with spawned actors. Many runtime errors such as “Accessed None” happened because references were not valid at the time they were being used. This happened frequently with the HUD, portals, checkpoints, and widgets. I eventually fixed these issues using print statements to find the errors and using validity checks so the code would not run and give an error. 

UI development, particularly the menus, was another challenging area. For example, certain widgets would only appear when a print string was placed before the Create Widget node. This was due to the code not running unless something like a delay or print statement activated it. These bugs were hard to fix because the logic was correct, but the behavior was inconsistent. I had to figure out how to open the controls menu from the pause menu without the controls menu still interfering. This was fixed by adding a delay before creating the controls widget.

The Thwomp was a movement based enemy that was pretty hard to make. At first, I wanted it to detect the player and only fall down when the player was in range. However, this was too complicated and did not make the gameplay much better. Instead, I made it move up and down continuously, doing damage when colliding with the player. However, managing alpha values, direction switching, clamping, and jitter-free movement took a lot longer than expected. Errors such as resetting values incorrectly or clamping thresholds at the wrong time caused it to get stuck or behave unpredictably. Using trial and error I was eventually able to solve these issues.

Lastly, github caused a lot of issues during the project. At first, we were not using branches and worked on one branch. This caused some issues and we had to redo some work. When we started using branches, merging into the main branch caused even more problems. There would be missing files and a lot of things would not work. We had to keep resetting to older versions of commits and redo a lot of work. Thankfully, it was saved in another branch so we could at least copy the code instead of rewriting it.

What I Would Do Differently in the Future

I have learned from this project so there are some things I would do differently in the future. One of the biggest changes I would make is planning systems more intentionally before implementation. We did not have much time to preplan the game so I was making many things as I went and later regretted how it was made. By having a plan from the beginning, I could have more easily had everything come together. I would also do more research into github and figure out why these errors kept happening. I also feel that I used casting too much when there was probably a better approach. However, this was the only way I knew how to reference other blueprints without breaking the code. The level design also took me a long time because I did not have an annotated map ready. Making one would have probably saved me a lot of time. My biggest issue was the lack of pre planning which is something I will definitely do more of in the future.

Post 4

For this sprint, I focused on making the game feel more polished. I added menus, UI navigation, and polished player interactions with hazards and enemies. While Sprint 3 was about main systems like health, respawning, and checkpoints, this sprint was more about user experience and creating a more complete game. My lead designer was assigned to continue working on the grapple system to make it polished and bug free. 

My first task this sprint was creating spikes that damage the player when they touch. I had already created a health component in the previous sprint which I used. However, I learned that applying damage on every frame of overlap made the spikes drain the player’s health instantly. I wanted there to be more of a cooldown so the player had time to react. To fix this, I added a canDamage boolean. When the player overlaps the spike, I check CanDamage is true and do damage. Then, I set the boolean to false, add a delay, and set it to true again. 

Last sprint I made a turret enemy that could shoot projectiles but they did not damage the player. The player was just being knocked back instead. To fix this, I turned off physics simulation on the projectile and set the collision to be query and physics. Then on component hit, I cast to the AC_Health component and applied damage to the player. This solved the issue of no damage. 

The biggest gameplay feature this sprint was creating a Thwomp-style enemy that moves up and down continuously and damages the player when they’re underneath it. I store the thwomp’s position at the start of the level and set it. Then I have a boolean checking if the thwomp is currently moving up or down. Depending on which one it is, it uses a lerp to move the thwomp the other direction using an alpha of 0 to 1 and then reversing. Getting this right took a lot of debugging. First, the enemy would move down, not up again. This was because my alpha was not being clamped and would go past the number instead of reversing when it reached 1. This was fixed by clamping. Another issue I faced was that my thwomp accelerated upward forever. This was again an issue of not clamping at a different spot and forgetting to switch the boolean. Once I fixed those, it worked perfectly and also damaged the enemy on impact. 

I also worked on the pause menu. I wanted the player to hit the ESC key at any time and open a menu that freezes the game and allows them to resume, view controls, or quit to the main menu. When the pause menu is open, I set the mouse cursor to be visible and then turn it off once it is in the game. Unreal’s editor was messing with my testing because clicking escape would close the game. I changed what button the play editor used to quit so I could test my escape function. Sometimes the pause menu would trigger multiple times when I clicked escape and I added a boolean to check if it was already open to prevent this. 

The main menu has a button for play, controls, and quit. The buttons were easy to set up but none of them worked. It was still using the other gamemode which had the health bar UI. To fix this, I added a new gamemode for the menu. Once I set GM_MainMenu inside the level’s world settings it worked. 

The controls menu was also pretty easy to set up. However, I had a weird bug where the controls menu only appeared when a print string node came before the create widget node. By adding a small delay before the creation of the pause menu widget, I made it work. I assume this has something to do with the function not running unless given a wake up input like the delay but I am not sure. 

I am happy with the work that I did this sprint. It took a lot of time and effort to get everything working but I am proud of the work I did. Next sprint is the final one so I will be polishing a lot of things and making final mechanics. 

Post 3

For this third sprint, my main focus was to make a health system, respawn mechanics, and a basic turret enemy. Last time I worked on movement controls so this time I wanted to expand on game mechanics. At kickoff, my lead designer/programmer was assigned work surrounding making the grapple chain mechanic work and making a playable prototype. 

To start off this sprint, I created a health component that I could attach to the player and anything else that I would want. I had done this before but had forgotten some of it. I added a function to take damage and also add health to whoever had the component. To make the health visible, I made a health bar and text that updated anytime the health changed. The UI itself was simple to make. I added a progress bar and text to display the health and added that widget to my HUD. However, getting the UI to update whenever the player’s health changed was difficult. I created a custom HUD that I added a health update function to. This would link the variables of health from the health bar to the health variable in the player. This took a couple tries to get everything working. I called the HUD health update function in the health component and got it working.

Next, I create a turret enemy. It has a function called start shooting which spawns an arrow projectile at the spawn point I set. The arrow has a projectile movement component on it and I set the speed. Back on the turret enemy, the projectile is set to spawn every second and it loops. The turret has a sphere collision around it and whenever the player touches that collider, I call the spawn projectile function. When the player leaves that sphere collision, stop shooting is activated which stops the projectiles from spawning. After that I started working on making the turret look at the player and rotate when the player was in range. It takes the location of itself and then the player. Then it rotates towards the player’s location using a find look at rotation node and setting that is the z rotation of the turret. 

The last thing I did with this enemy is make it change color when the player came into collider range. First, I made a material for the enemy and added a dynamic instance as the color so I could change it when I wanted. Then when the player starts the game, the color of the turret is set to dynamic. When the player then comes into range of the sphere collision, the color is changed to red and then back to the default color when the player leaves the range. 

I also worked on respawn mechanics this sprint. When the player’s health hit 0 in the health component, I set the player to destroy and make the player unable to control it. Then in the gamemode, I made a respawn function. This would spawn a new character, get the player controller to gain control of it, and possess that new character. This would allow the player to control the character again once it got destroyed after dying. The place it would spawn is the initial spawn point from the player start. I ran into an issue where the HUD would no longer update because it was referencing the old character’s health. To fix this, I had to make a reference to the player character in the HUD blueprint and then set it as whatever character the player currently controlled. This way the player referenced in the blueprint would update whenever the old character was destroyed and a new one was spawned. 

Finally, I made a checkpoint system. I created a flag with a pole and a sphere collision and made it a checkpoint. If the player entered the collision area, the checkpoint would cast to the gamemode. In the gamemode, the spawn transform which is used to set the spawn position of a new character after death, is set as the place where the player first entered the area of the sphere collision. Then a raise flag function is called. This simply takes the flag which is set under the pole and raises it to the top using a timeline and interpolation. 

I am proud of the work that I did this sprint. Next sprint, I want to focus on making another enemy as well as spikes for the environment. I also want to add a main menu and pause screen. Overall, I hope to continue this momentum and make the game fun to play.

Post 2

For this second sprint, my main goal as a producer was to have the movement mechanics and basic grappling done by the end. Since we did not get programming work done last sprint due to a member having to leave, we needed to catch up this sprint. I focused on the moving, sprinting, jumping, and camera movement. At kickoff, I assigned the lead designer stories focusing on getting a basic grapple to work as well as having an area to test it. I assigned myself the tasks I mentioned above. 

I had an issue with the unreal project that was set up last sprint and it kept giving me errors. I could not figure out how to fix it and had to set up a new project and github. Once this was done, I started with a blank scene and no templates. This meant I had to make a character that could act as the avatar and be controlled. I watched some tutorials on YouTube to help me get started since I am not great at coding. I also looked through some of my old projects from the previous coding class to refresh myself on where to start. 

I started by making a character blueprint and giving it a basic mesh. To that, I added a spring arm and camera so that I could set up the 3rd person view. After talking with my lead designer, I was able to tweak it so it looked how he wanted. After this, I moved onto making the basic movement. For this, I had to create inputs for each action and create an input mapping context so the player could use those inputs. To move forward, backward, left, and right I used an add movement input node and connected to my WASD buttons. This was simple to do and I could then add sprinting. This was done through a simple function where the sprinting speed I set would replace the walking speed whenever the left shift button is held down. I tried a few different sprint speeds but for now I have it set to 1200. For the jumping I just added a simple start and stop jump node. For the camera, I added an input action for looking into the character blueprint. When the player moves their mouse, it is triggered. Moving the mouse then also moves which way the camera is rotated. The player will also move in that direction. 

A problem I had this sprint is that my laptop stopped working suddenly. I have it working now

but for about a week I could not do work on it. I

borrowed a laptop from the library to use but it cannot run Unreal and we are not allowed to download anything onto it. I used a computer in one of my classes to get some work done while on campus. However, I do commute over an hour so I was not able to get any work done on days I was not there. I did get most of the things done before my laptop stopped working thankfully. Now that it is repaired, I should be able to catch up and do some more work next sprint. 

Next sprint, I want to focus on adding a health system to the game and an enemy. This will be important to make the game feel more fleshed out and also fun to play. I will add UI for health and make the enemy move around as well. Also, the grappling mechanic will be improved through chaining. By the end, we should be able to test the movement mechanic fully. 

Post 1

I am a producer on the game Pull Yourself Together. My teammate is Justin Vang and he is the lead designer. It is a single player 3D platformer where the player shoots from their bow and hooks onto grappling points. This is my second time being a producer in this class. My teammates have not taken the media pipelines course and are less familiar with producer work so I was ok accepting the role. 

The first thing I had to do as the producer was understand what the plan for the game was from the designer. We talked about it and I asked the designer to expand on his ideas so it could be a fully fleshed out game. This would help me come up with a timeline and user stories for this project. I created the backlog with 3 types of tasks in mind: programming, designing, and modeling. I assigned myself some design and modeling work, the lead designer the design tasks, and the programmer the programming tasks. However, I made sure each person was alright with their tasks and emphasized that nobody was forced to stay in that one task category. 

I ran into a problem as the producer around the end of week 1 of sprint 1. The programmer of the game had to leave the class for personal reasons which complicated things. After discussing with the designer and the teacher, we decided to continue as a group of 2. I went back to the trello board and reassigned the programmer’s tasks to be split between the 2 of us. This added more work but a lot of it could not be done within the sprint since we found out so late. I also went to the backlog and rewrote some user stories to make it easier to divide the programming work between us. 

This sprint I assigned myself design tasks because I did not know about the programmer leaving. Otherwise, I would have given myself more responsibilities around programming. For the paper prototype, I designed the tokens which would act as the players. Originally, I wanted to do more elaborate designs for them but decided it would be best to use my time elsewhere. Then, I designed a bow concept art for the paper prototype. We decided to use the lead designer’s art of the bow so it could be simpler to print. Another thing I worked on was a test room for the game in Unreal. The room is basic with differently shaped and sized objects. This is just to test out the character’s jump height and maneuverability. 

A task that took me a few hours to complete was modeling the character for the game. I am familiar with modeling in Maya but used Blender for this task as it is easier to make characters with it. I followed a tutorial since I had not used Blender in years. I chose to do a low poly character so the game had a more cartoony feel. The character is very simple and needs more design elements added to it but for right now it is an okay placeholder until more programming can be done. 

I would have liked to get more work done this sprint but I had a lot going on and losing our programmer was unexpected. I would have liked to set up a character movement controller as well as the camera. The premade character in Unreal is alright for testing but I would like to code my own so it plays how I want it to. Overall, next sprint my goal is to get the character movement done and start on the health component. Then I can start to make the game feel more complete.