370 Postmortem (Sprint 5)

This week I worked on putting the finishing touches on our game. This included finalizing the torches, the UI, obstacles, and generally polishing the game.

Trello Board

Finalizing the torches was probably the trickiest part I had to tackle for this assignment. For this, I looked into various timers and timing methods to use for the torches. Ultimately, I landed on the WaitForSeconds coroutine which was a bit tricky to implement but I was able to figure it out eventually. I made the torch timer a public integer so that it could be edited as we playtested our prototype and figured out the timing of the torches.

TorchPickup code

For the obstacles, I specifically focused on the foliage. The foliage was a fairly simple piece of code - a collider, tagged with "foliage", would decrease the players speed significantly whenever the player touches it. Jumping to escape this boundary reverted the speed back to normal. The method I used may not have been the most efficient but it worked for our needs. In the future, had I given myself more time, I would have utilized a more efficient and effective method for this mechanic. I would have loved to consult the programmer for Group 1's game, Sea and Snow, since their core mechanic revolves around a very similar premise.

For the UI, I simply added a Lives counter to be displayed, and a game over screen for when the lives hit zero. Additionally, I had to fix the code that linked the health bar and lives counter. I worked with Matthew to figure out his code, then began to work the two pieces together. It was a fairly simple process, but working out the bugs that came with it was probably the most complex part. The idea is that when the player's HP hits 0, they lose a life and they must respawn at the last checkpoint. It went back and forth between working with the health bar, to working with the checkpoint, to working with the lives, but never all at once. Eventually, after a late night call, I figured out the solution after explaining my problem out loud to another classmate who was more experienced and realizing my error. In the end it was a fairly simple fix (resetting the health bar when you respawn) and the basis for our game was 100% complete.

During our last-minute scramble to get everything completely finished for the final, we just went over all of our code to make sure that any functioning code still functioned, and anything that was incomplete was commented out or removed from our game entirely. Our sprites had already been added on at this point, however we just did a few last minute checks to make sure the sizing was right and that the sprites all still worked with their new colliders and such.

Looking back on this project, I think we did a pretty good job with our game. We got all of our basic mechanics completed for the final prototype, we had some art done, and it functioned well. Our group was in constant good communication, and we each worked on our equal share of the work, assisting each other in the tasks (especially the programming tasks), and critiquing and helping each other when we got stuck. 

I think our biggest weakness was time management. We definitely put things off and it affected our prototype, as it always ended up coming up short of where we wanted it to be. For example, for this last sprint, I think we could have fit in the powerup that I wanted to implement since the beginning had we started a little earlier. As we went on, however, we began using the point system which was very helpful in managing our expectations and getting things done on time.

Final Game - Level 1

Moving forward, I think spreading out the work more evenly earlier on would have been massively beneficial for us. Most of the heavy lifting landed on the programmer, and I (the modeler) and Amir (the level designer) got off with some easy work the first couple of sprints. This resulted in lots of tasks being delegated to Matthew (our programmer), so we decided to start taking on some of the programming work, and also share some of the tasks with him. Ultimately, this is definitely the method to use in the future for new group projects and working in a group in general.

ePortfolio 320 Spring 2021 Post

 Charcuterie Board: I was unable to complete this assignment. Due to time management issues, I did not complete the assignment. 

Tie Interceptor + Crate: 

For this assignment, I decided to texture the tie fighter to as close to the actual thing as possible. To do this, I referenced photos of toys, as well as concept art and other art from Star Wars artbooks. 

Originally I wanted it to look more like the tie fighters of the newer movies, however I thought this would be more accurate, and I ultimately liked it a lot better.

For my crate, I based it off of the crates from Super Animal Royale. I really like the original aesthetic, so I made a crate using the same colors and wear, as well as adding the SAR (rebellion) logo to it.

I’m really proud of how these two turned out. While I had problems UVing the tie interceptor, I was able to work through the problems, which turned out to be fairly simple, and completed UVing it with enough time to texture it. 

I think ultimately I created a project that I am proud of and would like to continue with texturing objects like this. I really loved the way my crate turned out, with how I placed my weathering (scratches, dirt) and the way I interpreted the original 2D design and created a 3D object out of it. The tie fighe also turned out super well, even with a couple of UV errors. I think I created an accurate recreation of the Tie Interceptor from the movies/books, and in the future I would want to add even more detail to it.

VW Bus/Final Project:

While I was unable to complete the VW bus at the original due date, I completed it in order to be able to use it for the final project. 

For the VW bus, I thought it looked a lot like the main character from the movie Robots, and was inspired by the colors, so I made my bus with similar colors. Since Robots had characters that were kind of grungy and dirty, I incorporated that into my textures to create an imperfect texture. 

I'm not sure why it reminds me of this.

One of the final renders.

Along with that theme, I decided to make it into a car wash/car maintenance scene for the final microscene project. I made up a list of assets I wanted to add (in addition to the 4 assets I made for the original assignment) that I could model easily but still fit the theme. My assets were:

• Bucket

• Sponge

• Gas/Jerry Can

• Squeegee

• Hose

• Building facade

• Wash rag/cloth

• Car duster

• Funnel

• Fluid Jug

• Tire

• Air canister

• Toolbox

• Spray bottle

In order to create these assets, I learned and mastered a few modeling tools that I have not previously used, like the multi cut tool (which I never felt I learned properly in previous classes, and this was a great opportunity to learn how to use it), or the symmetry tool. Utilizing these tools allowed me to create models I didn’t think I was able to without extensive knowledge of modeling. I’m proud of the assets I was able to create, and the textures I created for them. 

I definitely ran into a lot of issues. One of the biggest was UVs being missing, or flipped. I was able to utilize the legacy version of the Layout tool to target, flip, and unstack UVs, and it saved me a lot of time trying to find tiny little pieces that were flipped due to duplication and negative scaling. I had to reimport my objects several times before I was able to start texturing (which is why I was unable to turn in the original assignment), but ultimately I was able to texture my scene. 

Reap What You Sow

Over Winter Break, I had the pleasure of working on a digitized card game called Reap What You Sow. While we did not end up completing the project, I was able to design and draw several of the cards for the game. 

Reap What You Sow is a card game based on farming, with a fantasy theme. You must plan ahead in this game in order to guarantee your success later on in the game in order to collect the most money and win the game.

Since this project took place over the winter break, I was not able to finish each card I picked for the project, but was able to complete a good amount and start some as well.

Here some of my completed designs:

Cow card, including a Strawberry Cow, Chocolate Cow, and a regular cow. Design heavily inspired by the Harvest Moon/Story of Seasons series.

Crystal Card, an original design.

Magic Fertilizer card, with mild influence from the Harvest Moon/Story of Seasons series.

And here are some of my in progress ideas, approved by the project lead but did not get to finish:

Fountain of Life, an original design.

Goldhound, inspired by JennaMarble's Italian Greyhound, Kermit.

Sheep, also lightly inspired by Harvest Moon, with Cotton Candy, Black, and White Sheep variations.

Working on this project taught me a lot about time management, team project working, and good communication. I would love to work on a project like this again, but more long term. 

Sprint 4

 This week I worked, along with our programmer, on the code to improve upon the existing code that we have written for the game. Our movement was a big problem during our last sprint, and we wanted to fix that in addition to many other problems we had with the code.

Trello Board screenshot taken after Sprint 5 cards were added, blacked out new cards.

The first thing I wanted to jump on was creating a lives system for the player. While it did not make it into the final build, it still functioned in tests and added a consequence to dying in the game, rather than giving the player unlimited chances at beating it. This code still needs work, as integrations into the player respawn are being worked on. Currently, it does not work to give the player a game over, however it does count down the lives within the debug log.

Player Lives

This code counts down your lives each time you die (hitting an enemy, an obstacle, or falling off the level). Once you hit 0 lives, your character becomes inactive and you can no longer control the player. I will be building off of this code to implement a health system, as well as creating a game over screen with menu buttons to restart the game or exit the game.

I definitely ran into a handful of problems when creating this function. Even though the code looks fairly simple, I had to go into the player death code to modify some broken functions in order to make my code work how I wanted. There was also the issue of prefabs being messed up and needing to work with Matthew, our programmer, to get those resolved.

Torch Code

I also created the torch light system, with a little assistance from Matthew. To create this system, I built off of the existing torch system. The existing system made the torches a collectable item, but did not activate a light. It counted the number of torches collected as well. In order to make it so that the player was holding the torch, I duplicated a torch prefab, which I then childed to the player object and hid in the inspector. The code functions in such a way that when the player touches a torch object, it will unhide the torch object, and the player would then be carrying the light. In the future, I will be adding a timer to the torch so that it is only on for a certain amount of time.

We had lots of problems with the respawning system not working, and were not able to figure out these problems before the playtest happened. However, we were able to fix these problems in the few days after the playtest before the sprint was over and now have a much better working game. In order to fix these, I had to almost start the respawn code over from scratch. Originally, I had added the PlayerLives() function to the respawn code, but this broke the function and it did not work at all after that, even though it was only partially working at that point anyway. I read over the player death script and figured out what made the respawn work for obstacles and falling, but not the enemy, and created a new respawn code. It was fairly simple but working with code that I was unfamiliar with made it more difficult to work with. In the end, I created a respawn function that respawns the player to the most recent checkpoint they passed.

Player Death/Respawn

The last thing I created was a collectable item. Very simply, the player collects the item by touching it and the console prints "Item Collected". In the future, this will be added to the players save file and you will be able to view your collected items from the levels.

I ran into a lot of programming issues. As I am not a programmer, I fell back onto my 180 projects a lot to create my functions. A lot of the ideas that we wanted to incorporated into the game I had previously created in 180. I also found that whatever tutorials Matthew and Amir had previously used to create other assets did not do things in the most efficient or user friendly way, so I managed to simplify them and make a system that was much easier to work with in order to implement new systems and mechanics.

For the last sprint, I will be refining these mechanics, as well as adding essential ones (obstacles, for example) to the game. I want to create a timed torch system (a key part of the core mechanic), a health bar, and an official game over screen. I also want to add the UI so the player can see their lives and collectables, as well as add power ups and animate the sprites.