CAGD 370 Video Game Development

Postmortem

Overall, being a level designer was very exciting, and I expected someone unique to create the most straightforward, functional, and exciting things. This postmortem of a prototype meant a lot to me because I will always imagine the wholesome feeling of creating a game by having an outstanding team in forming a simple foundation. It is a 3D platformer with unique movement mechanics no other match can ever think of doing relating to the game's premise in general. I appreciate my teammates' hard work and dedication to helping one another and surpassing any obstacles that might hinder our project's completion. I would always wonder if I was a programmer and not a level designer and thank god I wasn't. There might be a variety of bugs unfixed for the final project. I am not a strong programmer, but I do have some knowledge of it, not as a professional but as an average.

Everything was just the basics of working toward a strong progress development as we planned for the first Sprint. In general, we communicated very well by understanding the needs of what type of a "game" we as a team wanted to create into an electronic prototype rather than the paper prototype we expected from the beginning. From blocking out level one and the basic movements, we needed an objective and obstacles for the game to be interesting for those who like to be a cat in a simulation and destroy everything in its path. Little by little, my team wanted to imply different mechanics and add some art, which was optional because it was a prototype, not an actual game. Ultimately, we must eliminate the art process and ensure everything works as the basic mechanics. I tried to lower my expectations, but it was difficult for the main reason this prototype was successful.

As I mentioned, we started strong but slowly escalated because we did not know what to do afterward. This prototype was straightforward and did not involve complicated things, which other groups tried to provide with their game. Some make sense, while the rest is just a sit back from the lack of tasks and points each group member tried to accomplish gathered in the end. We had to improvise if we were creating this game for any reason; we needed to model, texture,  bonus levels, more items to destroy,  more enemies, etc. It backfired when adding the statistics of all the points gathered in the end "wasn't meant" for the end of Sprint five. As some say, "Make till you fake it," which we did by adding tasks we weren't going to accomplish in the very end.

I would like to have manageable time management and be patient without rushing to conclusions. For example, I was tasked with creating a bite and a pick-up mechanic but received bugs and a broken system. I felt rushed and unfamiliar because I needed clarification about making these simple mechanics in a 3D platform, which I struggled with, especially with the new update of Unity from the previous. I made two controller plug-ins, like a keyboard and a gamepad, which made coding the new input system difficult. Within weeks later, I realized we weren't supposed to imply with the gamepad, just the keyboard, which I wasted a tremendous amount of my time and the process. I did not realize it too late; all of my work went to waste and became unusable by the end of this prototype. For the next project, I would powerfully communicate with my teammates what input system mechanisms we use rather than just going overboard. For some reason, if I'm in charge of a programming task, I have to start reading through the Unity document before adding an unfamiliar code from a tutorial video and later receiving a bug I cannot fix. Lately, I have to have patience no matter what causes my frustration because I want everything perfect, and for every reason I don't, I get a block and give up mid-way. I would have had the worst experience in my previous programming and modeling projects. I don't have the desire to accomplish a task without a perfect and functional product, which I felt happy about in the end. I am changing my perspective of being perfect for once, which will significantly help me in future projects and my career.

Download Prototype Game

Sprint 4

Recently, it's been different because I needed to have the tremendous number of tasks I had hoped from the beginning. This prototype wasn't what I expected: story and core mechanics. Some other teams have unique periods, which makes sense for their progress throughout these Sprints. We had to do other things, such as modeling, texturing, rendering, etc. So, knowing no ART made it impossible to have different tasks, but it worked by focusing on bugs before the playtest. 

The only problem I encountered was implying the proper code script for the mouse. There were multiple examples of how to make an enemy follow and attack the player, which I was trying the opposite. For instance, if the enemy follows the player in an addition equation, then the subtraction. I figured out the right solution to move the mouse while the player is far away. When the player gets close, the mouse stares until the player gets a little closer, and then it runs away. The only issue I faced was destroying the object, so I asked my teammates to find a solution without causing other bugs. I tried collision enter and tag but found a new stay method. While facing this chaos, I ensured the audio worked, so I had to fix the MixerMusic by creating two different volume bars into Music and SFX. It worked, but only the pause menu SFX music wasn't working, which wasn't a big deal to begin with this Sprint.

This Sprint Kickoff was short and minimal. For the reason of what other task I can provide without causing another coding issue. So far, our primary focus has been fixing bugs and having playtest sources outside of class. Nothing can compare to how, as a team, we improve with this "prototype" game to work with function core mechanics. I wanted to challenge myself by monitoring the mouse as an object for the player to interact as a prey catching the mouse. I mentioned adding a bonus level, but that would be for another occasion as a wish task rather than a need for the meantime.

So, I completed and fixed some old work to represent an actual gameplay ready to playtest. I fixed the menu system by adding a level selection by menstruating the two levels we have to playtest. I set the setting system by adding fullscreen, resolution, graphics, music volume, SFX volume, and a shot key. Lastly, I created a new form to earn more points by adding a mouse into the level as catching a mouse as a further gameplay interaction. This process took the majority of my time, but I had it working before the playtest.

The only thing I should have completed on time was the playtest source form outside of class, but I'll make sure to have multiple playtests with each new update before the final.

I'm currently working on something other than waiting for the new Sprint with the final attempt to improve without focusing on art, but if I had enough time without any significant task, I would start doing the wish tasks.

Sprint 3

I can only imagine how complicated a single mechanic is to experience errors or issues for the first playtest. Unfortunately, it happened in Sprint 3 when the first level was to playtest for another player's first experience gameplay. If one item or obstacle fails, the whole process discontinues failure. We have a backup before it crashes during maintenance to achieve savings and use our previous method. Thankfully, this mechanical prototype is just the player's automatic movement, not the whole game. Another great idea was having another spectrum of the core mechanics besides the basic but still needs to demonstrate the actual environment functional for the playtest.

Since I am the level designer, I had to organize and see if the first level had any errors before the playtest. I encountered one mistake after another:

• Missing some scripts from objects.

• Not having the whole prefabs from others' creations.

• I am trying to add others' scripts, yet I need help with GitHub.

My team met before class started, so we needed to figure out what other solution we could come up with for this impossible problem. Meanwhile, I was still organizing the level, and the programmer tried to figure out what caused the issue of the misfunction in these early stations. The programmer tried to emerge the dev branch into GitHub, but he was getting errors containing some missing scripts, causing the main scene to be nonexistent. The only good thing was I had a backup, but I had to start all over and encountered another problem with the scratch mechanic. Before, it was working, but when I added the team's scripts, it wasn't working at my end as well with the lead's perspective level. The programmer made the basic gameplay for the playtest as a last resort by focusing on the most straightforward core mechanics.

For this, Spint's kickoff was the first to be reviewed in front of the class. The only backlash was the block log, which differed from the high expectation of needing more tasks for any upcoming Sprints. Even though this was meant to be a prototype, not the actual game, finding other jobs to work on while the basics are done for this basic game is challenging. 

My work was fixing and organizing the first level and its functionality. I also improved the counter score and the leaderboard score save. Even though my team can support me, I am still figuring out what I can do, but I want to ensure I get all the significant mechanics that get impact errors. I am currently working on the options and managing the game as the actual game looks alike.

Sprint 2

The process has been impossible because I need more time management if dividing my work into a single day. As I mentioned before in the previous post, I am not a programmer, which causes me to use one single process involving any coding source that can last more than a day. I have developed a constitution to organize myself by defining and investigating how the actual coding can function in a simple player movement without causing any errors until complying with the other scripts.

By the chance I encounter any errors, I have three different options, which I consider the steps of a solution to this upcoming problem. One is rewriting the code again in the same script or starting a brand new script until it works for the moment. If the first option doesn't work, I look for another coding source similar to our group's new input system. Although not all are updated, I have to maneuver myself by cranking up the code into consideration, implying the player's action works. The final option is to suggest help from my teammates, especially the programmer. This situation would only change after the minute if I added more scripts to the player alone.

The only issues I encountered in this Sprint were the pick-up, toss, and eat or bite, which I had been the person added to since the previous Sprint. I had to ask for help, considering it took a step back from the progress of continuing forward. The only solution is to leave it aside so that another teammate can imply the cause of the problem, but until then, I encounter another issue. Without the pick-up and toss function working, I couldn't add the leaderboard by not having the player break items without these functions to earn points. The other minor issue is the pause menu because the player would move despite pausing the game. I considered making the pause menu into another scene, but I'll fix it later because it wasn't necessary.

The Sprint Kickoff wasn't, for I needed to figure out what other tasks I, as the level designer, could do without any significant coding. I mentioned that I might add the point system, the timer in UI, the pause menu, the leaderboard, the game over, and the victory scene. Throughout the two weeks, I asked if I could add audio and the number of points of each destruction of the items caused by the player. Also, I wanted to be in charge of making the first level functional for the next playtest.

So far, I have completed UI and Audio functions: the pause menu, points, high score, timer, gamer over, and victory scenes.

From the first Sprint, I was assigned to model a cat and add an NPC to track the player's movements by observing from not destroying the items around their surroundings. I wanted to make the model at the end because it is optional. This game is just a prototype, but I would like to leave a reference on how the cat should have looked, as well as the other NPCs.

I am indicating the items to be destroyed as the player can earn points while gameplaying to victory. I am also fixing the timer to display whether the player is completing the level. Hopefully, for the next Sprint, we can conclude what the players expected our game to be with the playtest summary.

Sprint 1

In group 4, we are called the Feline Production, and the title of the prototype game is Cat-astrophe. I was the designer and, for the most part, a programmer. This game is based on a simulation of you as a player, a cat trying to demolish every item available before getting caught by the cameras or the owner. 

 Creating a game from scratch was difficult because of how many videos I had to watch for a specific program I had applied. I am not a programmer, but I wanted to help as much as possible. Programming for more is a profound step I still need to face because it complicates things, which is complex for me as a perfectionist. It's time-consuming, and if I don't over-achieve it, I have to start all over, which complicates my other tasks. This process helps me realize I can do it at my own pace, and it might change in the future for the better practice I can conquer today.

Some of the issues I encountered were the player's movement and the prominent camera placement. This 3rd person's point of view was a hassle of following along with the player without clicking off the screen. I had to apply my codes to continue my tasks of the pick-ups and other player interactions for the gameplay. I told my teammate about the issue I was facing. The person in charge of the programming fixed the problem, and it did help for most of the part. I was tasked with climbing and sliding and encountered the same issue, but this time, it was the player's movement. I mentioned this to my teammates and switched my task to the programmer. I didn't want to miss around with the player's actions, which could cause a major downfall to the game, so now it's the programmer's job to find the issue and fix it without causing another error through the process, even though it is still in the first Sprint.

Unfortanly, I wasn't present in the first Sprint Kickoff because a couple of days prior, I hurt my lower back, so I couldn't attend that day. Even though I was in pain, I still completed my day task: annotate a map and block out the level. I completed my duties as soon as possible by creating and building a genetic-level living room design. I asked the lead for her ideas and applied them to more tasks. In the second meetup, I mentioned the issue I faced from the climbing and the sliding due to not changing any player's movements. While doing so, I had some cases with the activities, so my teammates helped me fix the problem.

In Sprint 1, I completed six tasks out of four in total. The six tasks I met were the annotated map, the block out, the pick-up, the toss, the eat or bite, and the main menu, which is still in progress by fixing it in our theme. Even though the main menu is done now, I still need to finish adding the option menu, pause menu, and the game over UI. The four tasks I still need to complete are the NPC movements, the cat model, and the climbing and the sliding. I was blocking out, so I had to switch them to our programmer. So before the kick-out for Sprint 2, I'll be working on the NPC movements and the cat model as simply as possible.