CAGD 370 Blog Post 2

10/27/2024

Sprint 2 Kickoff

In Today’s blog post I will be covering my latest process I have gone through as a Programmer to create and design a project video game alongside my team. So far, we have been able to gather the feedback we received during our first playtest of our paper prototype and use it effectively in the last 2 weeks to be able to transition our paper design into a digital prototype. At the beginning of Sprint 2 I was assigned 5 cards, most of which were tasks dealing with programming aspects of course, along with general design stuff as well. Since the beginning of this project, I have gotten to build and gain some more experience with agile development so naturally this time around, I was much more prepared to tackle my work for this Sprint 2.

Work Completed

With that being said I started my work inside Unity which is the software we are going to be using this semester to create and design our digital prototype for our game called “Wisp’s Light”. As the group programmer I decided to take the lead in setting up the project in Unity as well as creating a GitHub repository in order for my team and I to efficiently be able to work on the project together. After that it was smooth sailing for me to work on the cards that I got assigned during Sprint Kickoff 2.

My focus this sprint was to be able to create a functional Player controller set up in unity, so that it could allow for some other features of our game to be tested by me and my group mates Hannah and Yasmine, as soon as possible. Another reason I wanted to tackle this right off the bat was due to the fact that for this project we are tasked with creating a unique movement that we can showcase as our main game mechanic. As for our game, we decided that our unique movement would be Teleportation for our player. Keeping this in mind, it allowed me to write a script that would cover our players basic movement using the WASD keys on keyboard to then be able to work on the teleportation.

After doing this it was a matter of figuring out how I could get a 3rd person camera to follow and work property just behind my character. In the beginning I thought it would be very simple however I quickly learned that it was definitely not as easy as it seemed. This was my second card assigned to me for this sprint, and it actually ended up being the one that I took the longest on. However, after some research and experimentation, I was able to finally get it to work to a certain point. Once it was working, I was able to shift my focus and start working on the rest of my cards assigned for the sprint. At this point I was able to accomplish my main goal which was to create the player's main game mechanic of teleportation. After this I was also able to finish another card assigned to me that had to deal with the sub character in our game following our main player.

Issues

As for issues this Sprint, there were 3 main issues I encountered. The first one was perhaps just some minor lack of communication between the team and me. I realized this was an actual problem when it led directly to my second issue encountered which ultimately came down to a merge conflict I ran into when trying to upload my changes to our repository. I got an error message when trying to do so and it caused me to go back and retrace my changes done to the project. My last and final issue encountered happened when working on my 3rd person camera. However, I was able to resolve this issue by downloading unity’s Cinemachine package that helped me create the 3rd person camera I wanted. Overall, I definitely got some progress accomplished towards this project and ultimately gained some knowledge on how agile development works.

CAGD 370 Blog Post 1

Hello everyone, my name is Angel Suazo and welcome back to my blog. Today I will be going over the process I have gone through so far in an attempt to create a digital prototype of a video game that stemmed from an idea. At first we were all tasked with coming up with multiple ideas that we could potentially pitch to a client that would be interested in developing a game project. After the pitching stage, it came down to deciding which idea we would like to pursue and ultimately see all the way through the development process. I quickly formed a group with my group mates Hannah and Yasmine and we immediately got to work. 

Kickoff
Once our group was formed, we all decided who would take on what role for our group and what skills everyone would provide to the group. Since we decided to work on Hannah’s pitch idea she stuck with the Lead Designer Role, Yasmine agreed to be our Team Producer and I was able to secure the Programmer role for our team. Afterwards we set our priorities for the project and the prototype in scope and we were able to quickly set up a backlog that would help us document all of our Needs, Wants and Wishes we would have for this project. Generally when we were creating these objectives for our project we definitely kept in mind what our players would want from our video game and decided to create these objectives based on user stories. We also made sure we would create enough of these by breaking them down as specific as we could to the point that it would provide and also cover a good amount of workload for our team's mission. At this point we as a team felt like we had established some good ground work to be able to start our first Sprint Kickoff. 

Challenges Faced
During Sprint Kickoff every person in our group got assigned 2 weeks worth of work. Our first goal however, was for our team to effectively create a paper prototype of our digital design. It was at this stage that we began to face some challenges in our project. We began to think about how we could creatively design a paper prototype that would perfectly envision what our digital prototype should look like. We began brainstorming some unique ideas and ultimately we stuck with the design down below. We figured that we could focus a little more on our game's main mechanic which is for the player to be able to teleport between spots on the map. So ultimately we decided to stick with this design along with our rulesheet we created in order to be able to playtest with people and hopefully receive some useful feedback. 

Playtest Results
During our Playtests, we were able to discover a few areas of our paper prototype that succeeded and a few that perhaps could use some more revisiting or improvement. One thing that playtesters really understood from our rulesheet was the whole movement of our player which was also our main game mechanic, so overall we felt that we explained that section and implemented it really well into our paper prototype. As for some stuff that we noticed went wrong were perhaps the implementation of sub character to our players role. For our game we decided that the player should protect another sub character at all times in order to stay alive in the game.This resulted in some confusion from our playtesters that ultimately created some frustration as well. Another thing we could have done differently was to shorten some areas of our rulesheet that also created some frustration in getting the game started. Overall this is some stuff we need to work on going forward in our digital design for our prototype and it definitely helped receiving this feedback right now during our paper prototype.

CAGD 270 Post 9

3D Game Level 2 v1 Feedback

Hello everyone, my name is Angel Suazo and welcome back to my blog. Today I will be going over the feedback that I received from the playtest on my 3D level 2 project. With this level we continued to work with the Unity engine to create it and we were also given a new theme and goals to work with this time around. Our new theme would now be Medieval and our new goal was to create a level where we can challenge the player leading up to a boss fight. With that being said, I immediately got to brainstorming a couple of different ways to implement our new theme and goals. When I landed on a couple of good ideas, I sketched up an annotated map to visualize it a little better and then I got to work. For the actual playtest we got into groups of 5-6 people in class so that we could get as much feedback as we could. 

What went right

This time around with my level 2 project, I honestly had high hopes of creating something good where I could almost picture it being perfect. Unfortunately while there were some areas of my level where I felt things went right there were also a few areas that went wrong in my level. I’ll start with the stuff that went right. During the playtest, almost every player told me that they could clearly see the critical path in front of them and that they did not have any trouble knowing where to go. They also mentioned that the way I structured my level was very cool.

One player really liked how I added some composition to my level to where I could show the player the path ahead or in this case the ending at the very beginning of my level. That was something that I intentionally added to my level so that players could see the finish line without actually knowing how to get there and it turned out to work really well. Another thing that I felt went right in my level was perhaps the interactable's placed inside my level such as the enemies, checkpoints, crystals, switches, doors and breakable cubes. All these things seemed to have been working perfectly during every single playtest and players did not have any problem with them at all. 

What went wrong

Moving on to the stuff that went wrong with my level 2, there were perhaps 3 major things that I noticed right away at the very beginning during the first playtest that needed to be addressed. Number 1 was that my level was very short. It did not take my first play tester very long before he could reach the end of my level. Even though I saw him die a couple times, It did not stop him from completing my level faster than I expected. Number 2 would have to be that I underestimated the level of challenge I presented to the players.

I had originally thought that by adding more enemies into my level it would create more of a challenge for the players. What I failed to realize was that I did not increase the health of the enemies. That could have caused the players to more effectively fight them and keep an eye on their own health. Another little side problem that I saw was that I did not add any health boxes to my level at all, which resulted in many of my play testers having to die from enemy damage and then simply just respawn at the checkpoints.

Lastly Number 3, was that I did not implement any boss whatsoever into my level. Originally, I had also thought that we weren’t supposed to create a boss but rather challenge the player leading them into a boss fight. I totally misunderstood that part of our goal for our level 2. Whatever the case may be, I can definitely say that I am going to continue to work hard to improve on these little and big mistakes and prevent them from happening again.