CAGD 377: Mobile Game Development

Postmortem

This final sprint is the final stretch of completing this unforgettable chaos combat of developing this mobile game within six months from start to finish. As a level designer, I cannot believe the hardship my group faced in these last moments of a stressful environment. As a group, we conquer multiple failures after failures, but in the final days, we accomplish more than we ever imagined. We hope to add more, but that will be for another day or time when we group again. The only requisition we, as the group, needed was time management and communication because other personal issues interfered with the project from different classes and individuals. 

In development, we had some occasions where everything went in our favor, so we developed this production within our limits. We accomplished any block out from our meetings and gatherings by sitting next to each other and communicating during the process. The patience we had faced if GitHub, Android Studios, Unity, and Google publishing weren't in our favor, but we were, little by little, defeated in time for the final blow. For example, if, for some reason, GitHub or Unity had issues with merges or missing files, we planned to create another method of using Google Share as a backup for any interruptions, which did happen occasionally, especially during the final push. In some other cases, if something would work for the other person's project, we had to update and polish the mechanical functionality before encountering any bugs for a playtest. For example, I had to fix some issues we were experiencing with the player movements being different from any other I had ever seen. The player's movements were just for the y-axis without any horizontal movement, so it impacted with some errors if implemented with the new input system, especially with two joysticks, which we had to convert into one. It also calculates the UI interference of the player's savings with currency value and health. If one worked, the other didn't. We had to make some changes, especially to the shop logic. One of us had the idea to leave a button on view for the player to interact with to help increase health while playing. The only issue we could come up with was the need for more unorganized scripts and the difficulty of doing callbacks if the scripts were either interface, class, objective scribble, or singleton. As well as the variables' values of being a float, int, string, or even boolen. Toward the end, we updated and polished any unwanted errors we encountered during the playtest. We accomplish something by not making the standards of being unfun, entertaining, and exciting for players to experience.

Unfortunately, we did encounter some unwanted events limiting our wants and wishes in the backlogs. We plan to make more levels but encounter a minimal amount from the basic movements and limit the player's interaction. We had to improvise and minimize our efforts on a single level so we could focus on what could be fixed until expanding to another level. We planned to have a narration between the player and NPCs, lore within the game, and add other worlds, but we didn't get the chance due to the lack of resources and time. We also wanted to have a 3D platformer within the cave entrance and have the player existing in the vehicle, which implies adding other UI interface algorithms. All this was created during the first three sprints, but we had to back down from our limitations within six months. We had to limit ourselves due to technology issues for both computers and trying to implement everything from one program to another. Another issue we encountered was the SDK; we had to recheck if it was up to date, and it wasn't; we had to re-install everything in time before publishing it into Google. If it wasn't Unity, it was Google, but it was not pushing the correct version or completing the updated documents. These changes are necessary to playtest our game in time.

In conclusion, I want to be able to do everything we wish to add to the final sprints without any complications or issues we encounter for this mobile game. The only difference I would like to add is unlimited time and a work ethic for this project without interruptions. By the end of the day, this was a fun and exciting project so far. I enjoyed every last minute and would like to work with my team again. Our game runs smoothly on Google Play; if you are interested, search Idel Ores under new, and you can play as much as you desire. Thanks.

Sprint 6

This sprint was bizarre and overwhelming. Managing multiple assignments from various classes was overwhelming not only for me but also with my teammates. We had to make some sacrifices of what is our main priority of tasks or projects or the focus or not. For some other reason, one of my teammates struggled the hardest of all of us. Negative mentality forged into impact by the lack of sleep and motivation. Life is harsh and dreadful, but everything has a positive light beaming through the cracks within the shadows. I did not want to fail a class because playtesters couldn't get the fun out of our game and make it impact our brains to fix it no matter what. As a group, we needed to change the layout and elements to make this awesome game fun and exciting till the end. Meeting after meeting, we needed to change the algorithm and the aesthetic of it; we thought the game needed to be what it was meant to become. Although we were struggling with the game and publishing it into Google Play, everything became a symbol of engagement and a push to make a change. During Kickoff it was only me and a team member, we agreed to talk about what needs to be done for the gameplay core mechanics. We had to finish adding the logic of the shop and sell because it was causing a hassle to find solutions without any bugs and interference. Within the new list, it had saved idle, tutorial, and any fixes before the final publishing. The consequence alters the effect by making us motivated for the chance to change everything for the better. 

In this sprint, I completed 15 points, which I'm surprised by the amount of work I had done due to the previous lack of effort. I started by implementing the saving and loading data from the player's gameplay. I managed to imply the value of the ores and the money earned from the player by having it saved in a file but making it encrypted so no one has a choice to change any data for future gameplay. Unfortunately, for this beta playtest, the saving data wasn't based on the lack of script making in the build and hoping it would work when applied to different scenes and allowing the player to play the game as when left it or a new one. I also fixed the health bar by re-writing a new player's and the bar to impact the player's ability to heal when colliding with objects. I helped make the main ores and some rocks into sprites for the tutorial access for the playerplayer'smation about the game. I started rigging our game's protagonist, the dog named Rusty. We plan to use him for the tutorial and for future or further gameplay usage. In the meantime, I'm trying to animate the dog and put it in front of the UI, which is another cause of action to learn about. Lately, my computer has been the only one compatible enough to build the game without causing any SDK issues for publishing, so people can play it by downloading it on their mobile devices. I intend to be available for anything to complete this project within my abilities with my team and make this game a successful, fun game that everyone can enjoy until the next sprint. 

Sprint 5

This sprint was short-lived and unexpected. The only issue I would experience was the need for sleepless nights. I cannot understand how my team members can withstand the ability to be awake for more than 24 hours. The functionality of having the ability to be motivated by energy drinks and consent to doing crush work can make the person delusional. Meanwhile, my old computer wouldn't have access to the new one, and my project was intact. I couldn't make a copy of my project or transfer it to my other computer unless it was connected to Git Hub. Git Hub wasn't the only program I had to re-download, but the Andriod Studios for NDK and SDK. Other than re-installing programs, I didn't have technical issues. Also, uploading a new game version in Google Play went more smoothly than the previous adaptation.

The Kickoff went smoothly. We agreed to assign ourselves the tasks necessary for the game loop rather than create another level, which we could continue until polishing the first stage level before proceeding. So, I finished with what I started from the last sprint: combining all the sprites into functional menus and adding newer icons to symbolize the information so the player can identify what function works during gameplay. At first, I wasn't aware that the previous version of the UI concept was still in progress, but when I went over it with my teammates, there needed to be some changes. As you can see from the very top image, you can see the new version of the UI the player would interact with throughout the gameplay. Every button has an open panel response to a functional feature of the shop, sell, and pause menu. The only thing left is to put some logic into them, which my teammates are in charge of for functionality purposes and programming. The only issue we faced was the time to meet because our schedules colid to one another because of other classes, homework, and work. So, we had to divide ourselves into pairs per meeting because the producer and the programmer needed to contribute to help each other finish a part. In contrast, at different times, it is the programmer and the level designer or the producer and the level designer. Now, we need to compromise our time to meet after class or at the weekend, but if it's an emergency, it's a day to finish one assigned task.

So far, I can only complete 6 points in total, but I still continue to try my best to reach my goal even though my teammates and I have a tight schedule to keep up. I had to apply the menus so the player could go through them without complications. I also made part 2 of the feedback form sheet for a playtest outside class. I also had to make sure the functionality of the speed bar and the counterattack for the player can receive damage and be shown in the health bar. Even though it wasn't done, it was all I could do during the block I had from the beginning of the sprint. For the upcoming and last sprint, I want to finish all my tasks on time and maintain the game with no errors or bugs for the final.

Sprint 4

This sprint could have been more organized on my part. I should have followed the steps provided on Trello. I assign myself a job but skip it and start another more impactful one for the team. For example, the three different cave annotated maps were meant to be done from the previous sprint but needed to be more crucial on my part to focus on creating the level one foundation. I am a perfectionist because I cannot move forward until I am delighted without any errors or obstacles blocking my progress. It's a fall of a personality that I cannot control, and for that reason, I might seem behind others, but I see myself succeeding on my own.

Another example is that I had some problems with the touchscreen inputs because they did not let me open other panels in the same section. As always, the only solution I came up with was to start all over and re-write the code using a different approach. Although I was hoping it would work from a different perspective, I accidentally erased a code that helped implement the change of panel for a random tap of the main menu. Still, I was getting conflicts because I did not have an instance from other parents and scripts. Later, I realized the only issue caused by opening other panels was that the button functions were supposed to be moved to the bottom of the group in the hierarchy, which made sense. It's the layers from Photoshop; if the layers are at the bottom, the content is set in the background, and the top layers are in the foreground, but in Unity, it is reversed. The most superficial problems have the simplest solution. It would be best if you looked outside of the box.

According to the calendar, Sprint 4 was during Spring Break, which made it impossible to stick with the schedule by having an actual break and free time. My team needed more time and effort to keep a regular Kickoff and Stand Up. During Kickoff, we just complete past assigned tasks and fix any bugs before progressing to other new functions within the Trello user story cards. We still face some difficulty publishing the Alpha game on Google. One of my teammates wanted to submit it on his computer but got an error saying that Google could not accept this submission because the Key pass wasn't meant. Since we started, I was the only person who submitted because my computer was the only thing I could do then, but my only issue is that my CPU could be higher for these majors. Technically, it took a while to export and import it from one hardware to another. Although my computer was meant for this course, it was the last resort and the last resource within the team to publish this Alpha version for this playtest week. Unfortunately, we didn't test our game during class because it was submitted within the time, and Google Play only approves within hours. Thankfully, we had the opportunity to send our game through email and playtest outside of class for the result and the upcoming fixes before the end of this semester.

I completed a few tasks in this sprint, but it could have been better or planned because I wanted to do more. However, I was waiting for the new logic of the movement update for the player input system. So, I completed the UI element function of the main menu by implementing the UI sprites I had to recreate from 3D models into sprites because Unity doesn't have 3D models as UI. Within the UI elements, I fixed the game's solution so it can be opened on any device, from a phone to a tablet containing a Google Play Store, which doesn't change the scale of the game itself from others. I also apply the option for the players to adjust the level they wish to start with save progress, but I need to find another way to save progress and let players see their progress in case of curiosity. Lastly, I also apply the audio volume for adding sound in any way. I created a new Google form sheet for the playteplaytesters'nse to our game and am considering upgrading to beta for the upcoming game release. I finally finished the caves'caves'ated maps from the first sprint.

Overall, this upcoming sprint can be a very successful or a disaster aspect of trying this game and being fully playable for the public. In the meantime, I would work on map location within the game for the players' edge of where they are on the ground level. Nothing can overpass my aspect of the progress needed for this game to be fully completed until the next sprint.

Sprint 3

It wasn'twasn'test, and it wasn'twasn'torst experience. I expected it to be chaotic. The major issues were related to the build-up, especially publishing on Google Play. It took my group almost two days to figure out the most superficial aspect of the implements needed to push a single build into multiple versions. For a reason, it was chaos for both the build and the teammate.

Meanwhile, we were trying to build with one of our teammateammate'sters for the first time. It got corrupted, so they could only process the build with my help. I was their last resort. Even though my computer had all the hardware inputs it needed, it wasn't suitable for this situation. My CPU can't provide fast service like any other; my computer can access the lag and slow process. The impossible had become possible because my computer was the saver for this build-up. Another issue we faced was the outdated SDK, which we all thought we had from the moment I imported it to Unity. We had to re-install Android Studios to install the newer version for SDK and NDK. Even though the professor confirmed the correct version, he didn't think that the Android Studios would update at any moment without our knowledge, and we couldn't understand the frustration, not for my team face but for the class. We had to find a solution from outside resources, which took a while to obtain, and advised others to search without stressing out for unknown knowledge of a new system or anything in general. 

This Sprint Kickoff was another quick and breezy way of choosing tasks already assigned in the backlog. The difficult decision was picking or not picking the wishes because it was just art-related and wasn't the objective of having the basic core mechanics as being the level designer. I had to pick a random task that involved some programming, but I didn't miss the opportunity to create anything, so I tried to make the UI in a 3D model format. It would keep me busy for a few days to organize any other issues I could solve without touching any heavy coding. I volunteered to do the minimum for this sprint as a backup supporter because there might have been some issues that occurred by the end of this sprint. I wanted to be reliable and help others in my team by ensuring everything was OK with the input system relating to the player's player's joystick so my teammates could access the playtest on mobile before building it.

I completed some tasks that helped this sprint process to move as smoothly as I had hoped. I created the first level annotated map as an updated version of the previous annotated map, keeping the player moving only vertically and making a spawner for the objects to move toward the player. I constructed the 3D model of the UI through Maya and Substance Painter. I must only apply them to Unity and group them as individual menus. I made a Google form for the playtplayteplaytester'sssensesatch to match ur game's intention of being playful and fun from the player's perspective. Lastly, I helped build the core loop game and imported it into Google Play for testing.

Overall, this sprintsprint'sience was stressful for the team and others competing with Google Play'sPlay'sormat. It broke minds and self-esteem to develop positive energy for the following day—a way to describe a brutal industry that can produce or happen in our future careers. The moral of solving a problematic occasion can help achieve a better understanding shortly.

Sprint 2

 As a designer, this implies less work towards implementing the mobile gaming build-up took much work. I need help understanding the concept of GitHub not working from previous projects, or it can also mean my new laptop hardware needs to be compatible with this contribution. I had to create and start a side project to maintain my progress as a designer or program some mechanics so it could work for my end. Thankfully, my teammates understood the struggles I had been facing because I wasn't there, and I had to resolve a problem by thinking outside of the box. I couldn't understand our difficulties, especially how we needed to implement some files from Android Studios towards Unity by still requiring the proper information, even though it was for an older Unity project rather than a recent one. It would take me almost half a day to download a simple file from Android Studios to Unity because my hardware was compatible with an ordinary student business computer. The only thing I had to do was wait and be patient even though my teammates started with their tasks for the day.

Sprint Kickoff was a quick breeze because we planned ahead of what tasks were more important than the wishes. We had to focus on the core mechanics we would be working on before another playtest came upon us in the external introduction. We had to lay back on designing for the meantime and focusing on implementing the mechanics by the playerplayer'snics and the substitution of being an Android game. Even though my teammates were pitching great ideas for the type of game we were creating, I had to limit this idea as a wish because it was more of a design than the main mechanics. I was pleased with the tasks I was pointed out, but I had to lay back on designing and focusing on inputting the system to have the possibility of limiting access I had for this sprint.

For this sprint, I completed 9 points of the total 18 points from the beginning of the sprint. As I mentioned before, I was having some issues with GitHub, so I made another way to share our files in a Google Drive share to combine our work. I also played around with setting up the Android template in Unity and helped one groupmate figure out how to imply them so he could create a GitHub. I also played with the new input system mechanics for the touchscreen implements and future character movements. I also apply the touchscreen to the main menu with the level selection, options, and quitting. It took me a while to play with because every time I tried to press a button, it would change the pack to its original menu to what I wanted, so I had to change some button functions and the touchscreen manager in the different panel, which worked. I also made a UI reference to see what HUD elements would fit for this particular game. Lastly, I played with the health system of the UI gradient of changing color whenever the health drains from green to red. By playing around with the health system, I had to use the mouse button and the critical code because the simulation I used to see from an Android perspective wouldn't work unless it was only with the mouse button. The only tasks I still need to complete are more annotations and design, so I plan to finish these particular tasks in the future.

At the moment, I am working on the joystick, which I did at the beginning of this upcoming sprint. However, I have implemented it into the other scripts without getting an error before the upcoming playtest. The progress for the forthcoming sprint will be better than this.

Sprint 1

As a designer, I was overwhelmed by the fact I had to minimize the installation I had been creating for a PC game into a mobile. So far, this first sprint has gone so slowly. I need to update the engine for this course and a new program. Unity was the only reason I could n'tess; my procession needed a decent hardware device. It took a couple of days to fix this issue and follow along with the tutorial, even though it was outdated. Before all the hassle, I used the default mobile template, but the lack of necessary programs affected the progress. On the positive side, I wasn't aware of the technical aspect of coding, which didn't indicate any errors in creating a new project. Everything will be in my favor for the next sprint rather than the opposite.

For this Sprint Kickoff, it was unexpected how impactful this game will be by the end. We had so many wishes we, as the team, wanted to add, but first, we needed to focus on the technical aspects of the overall functionality of how the game should work smoothly. To make sure this ideal game was different from the rest, we needed to apply a plus point, which wanted to imply the character was able to interact with NPC and the ability to control the character in the limited space of action in a 2D environment. As the designer, I was confused about what type of environment the person who pitched this game wanted, if it was meant to be a 2D or a 3D, so we had to have multiple meetings to verify the overall conclusion of how the game was meant to look. We agree to have a 2D environment with 3D materials, introducing a reliable game like Paper Mario.

As I mentioned, I could not do my task before this sprint because Unity was not working. I completed the minimum of my ability to be in this team by creating a feedback form so the playtesters could respond to their experience while playing the paper prototype. I also produced two different versions of the annotated maps; in the first version, I added how the map would look if it were in a 3D environment. I implemented the collectibles, a close-up of how the player would move, and the UI. In the second version, I updated how it would look from seeing in a 2D view, and the UI agreed to use it. Finally, I could block out the annotated map in a 3D version, which I'll change into a 2D version. I couldn't continue working on the rest of my tasks because I was blocked from having time for updating purposes.

Overall, this sprint was the beginning of how impactful any other could have been with the functionality of a single software. I am currently working on the UI functionality of working before it gets playtestes and updating multiple annotated maps in a 2D environment. Hopefully, by the end of the next sprint, everything will move more smoothly than this one.

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.

CAGD 373 Game Asset Production

 Group Game Scene Project

Final Post

For this final post, I had to finish all the props from last week and this week with the correct UV sheets and send it to texturing. Lately, the most stressful was using the canoe itself, and the most time-consuming by not having any error geometry, if any, the texturing you be off-putting. I had to delete parts of the canoe within the top sides, in which the vertex and the edges weren’t connected towards one another, so to fix it, I needed to delete and start a new UV. Up close, there is a gap between the two sides of the canoe, the inside, and the outside shell, even though from far it looks good from the destination. The last prop I worked on was the trailer, even though it was meant to be part of the initial interaction with the player. I didn’t want to create the whole truck trailer but just the end half where the player gets off while entering the camp of the scene.

My computer had some issues, or Unity itself, because I did not have the correct final scene project. There were some errors involving GitHub, yet this was the first experience I faced throughout this project. At first, it went well, but the scene wasn’t the right fit, so I had to change it and contribute to the correct primary location, involving the environment, the programmer contributions, and the post-processing. I didn’t have the chance to see the final walkthrough until one of the group members sent a copy of the Unity package and the walkthrough video separately right after the due day. In my defense, Unity wasn’t the only one I experienced so far, yet this was a more massive part of this final project than just Maya and Rendering.

Overall, my contribution to this final game scene was the level design I had to merge from both references of the two campsites relating to the original game scene. I wanted to contribute to both maps by including the cabin, which in the original was involved while the other wasn’t. In other words, I needed to add and rely on the team leader (Alex) to verify if the blueprint layout was what he expected or if I needed to change before moving forward with the green light. While finishing my part, I started implementing the format into Unity in the terrain by just imagining how the size can affect the landscape and the environment from the scale. If necessary, I added other implications throughout the progress. I did face some errors from Unity, not having the suitable materials and textures related to the water, trees, and ground assets rather than just the pink material. In making this fix possible, I had to work with the programmer (Shawn) with GitHub, which caused some issues from itself. Lately, I have just helped with most of the props needed for this final project. As well as helping with eh Asset List and Unity together.

Sprint Review 4

This week wasn't the plan I expected, for I have dived my work into another project circulating all at once. For starters, I fixed the game scene, which was impacted last week with unwanted pink materials, especially the collaboration of GitHub, because it wouldn't let me import all the scene projects. So, I had to double-check my scene and the main scene and ensure both had to see if they mirrored each other. It took me almost a day to fix any tiny detail I had encountered throughout the progress, yet this scene isn't the final scene; it still needs the models, post-processing, and implying the program process. The video above proves the function and tendencies of how I rely on my annotated map as extruded by the leader's commands.

I also did some more side props, which would add more depth in the background near the water. At first, I thought the canoe would be the most difficult of all the props I constructed but somewhat durable, yet I only UV them once I completed all the props I was assigned with. The net itself and the rod were the most time-consuming because I doubted whether I needed the extra details even though it would not be the leading player itself. For the last week on dead week, I want to finally add all the models in the correct scale and add the main antagonist, the ghost itself, as some form of interaction with the main character. Yet, I still need to go through development with my groupmates for the final scene.

Sprint Review 3

 

                  

Unfortunately, this week wasn’t the plan I predicted to accomplish with the lack of leadership and some errors I faced in Unity. To collaborate on using the same project in Unity, we used GitHub, so we, as a group, keep track of our progress, and until the end, we can merge into one single project as the final scene. To do my part, I had to delete some files that GitHub wouldn’t let me publish for others to see my scene, so I had to make more space, but I feel I deleted a unique folder that effectively the water material in my scene. I tried to delete the folder containing the prefab of the water and reinstall, yet I still had the same error of the water being a pink material even though I had to change it to URP Lit or just the Shader Graph. I need to fix this minor error based on clumsy action by erasing files I wasn’t supposed to, so I had to see if I could retrieve any missing files or if I must do another project and begin all over. While facing this obstacle, I had to keep our progress somewhat organized even though it was the middle of the progress. I still need to determine what other 3D models must be done and use texturing before applying them to the Unity scene. The image above is the updated spreadsheet I made with an assist list of the progress rather than just second-guessing towards the end.

Meanwhile, I was still making more 3D models I was assigned to accomplish this week. The only obstacle I faced was the sleeping bag because I used the sculpture function for the 3D model to be more realistic in the scene and just the progress of creating and the UVing. Before adding it into Unity, I hope it doesn’t affect the texturing and backing. For the following week, I hope to finish all the 3D models, UVing, and texturing because I need to add everything into the Unity scene and all the program progression being added.

Sprint Review 2

For this week, I had to work with Maya, Unity, and Photoshop to complete this week’s assignment. I started by getting both concept art I wanted to reference based on both maps of the game’s campsite as a foundation of the idea I wanted to involve in this game scene project. At first, I was confused about the campsite layout because there were two different names, Windwood and Maple, the only difference between them were the cabin or lodge in the scene. The image above represents the final annotated map I will use for the level design, where all the cursed items would likely be located for the player to pick up, but it might change throughout the progress. With this, I started applying to Unity; I only added the terrain, ground material, a summoning circle (which might change its location), the skybox, and water physics. The Unity game scene is located below with the summoning circle, which the leader assigned me.

For the rest of the time, I started making more props in Maya; it might be interactable with the player if needed. The cookware was easy to model using cylinders, extracting, cutting edges, separating, and merging. Although the lanterns were different, they had the same concept; I combined them by UVing them into groups by props, not linking them. The only difference is using curve implements to extrude the “wires or cables” and revolving them to the proper form of the reference to the model. It’s hilarious how the UV is more challenging for my eye’s sight to contribute the coloration with or without adding the vertex color. For the next week, I plan to start some models which have texturing completed into Unity, more models to meet, and add some VFX or any special effects which it can help improve the scene.

Sprint Review 1

Based on the game, I had to model two tents this week since it is Phasmophobia Camp Woodwind. To begin with, I needed to find references for different types of tents that might be good for the mind. I was initially indecisive because another group mate and I were trying to figure out what kind of tents we needed to contribute as an inspiration for the game. One of the tents I picked was easy because it resembles one of the tent players who get to interact by finding items in this tent called a ladder. Even though it wasn't the same tent, it had similarities to the length and width of the game's blue, red, and green tents.

In comparison, the other tent was more reasonable for the player to hide inside away from the ghost. This was my first time making these models using a cylinder and a square. It still needs more detail to add, especially the ladder tent, because I want to have a source of interaction for the player to go inside mid-way and see through the open screen; yet again, I still need to limit my tri-count. I also double-check if I am using the proper measurements from centimeters to meters and changing the grid for a better size to work on. When I finish finalizing the ladder, I need to UV them into one set and check if I have any wrong geometry. For next week, I want to plan out the accurate floor plan of the level design and work towards unity. If not, I can still model other objects if needed.