Project Midway Point

I know we’ve already been detailing our progress through stand-ups and our project midway assignments, but I also thought this would be a good opportunity to document my experience with the project thus far in my own way, adding my thoughts on certain aspects of the experience. It will serve as a sort of retrospective for myself, and a deeper discussion of what we have done and where we stand for readers.

Team

For our project, my team is made up of two students, as opposed to most team’s three. This poses some challenges of course, as we have a third less the amount of developer resources to work with as was intended for this project. However, it does also provide a few advantages. Communication is easy with two people. Planning meetings only takes the two of our schedule’s into account. Potential for conflict, I believe, is reduced. I can see two people not getting along, but I feel that having more people adds more opportunity for power struggles and the like. When the quarter started, I was kicking myself for not reaching out to people beforehand to form a group. That being said, I have been super happy with my partner. We work well together and have fun doing it.

Project Description

My team’s project is a 3D mobile rhythm game. It’s required to run on either Android or iOS, needs to keep score, track hot streaks, update the UI when a hot streak is entered or exited, and show the player their score and other stats during/after the game. We decided to go with a circular structure opposed to the top down approach used in classic rhythm games like Guitar Hero and Rock Band. The idea is that we have a ring structure take up most of the screen and nodes fly toward it from a distance. As they near the ring, they appear to move out towards the edges of the screen to give players the ability to anticipate when to tap the screen to “hit” the node/ring at the right time. We hope this will be a fun and engaging approach for players.

Unity Research

I had to spend a good amount of time researching Unity: its layout and features, how projects are set up and run, and how it interacts with text editors/IDEs. It was a lot to take in and took me a good week spending time with Unity Hub, YouTube videos, and online forums to begin to get a feel for it.

Menus

The first thing I worked on was a menu layout. In our project plan, I laid out a start menu that had buttons to start a new game, view high scores, and a song selection screen that followed the previous two. After working on it for a while, I realized that I wasn’t using the right tool for the job. I was using a 3D scene to make menus and it didn’t seem right. My first adjustment idea was to use a 2D scene instead. I still think this is a good option. Another idea floated through my head to see if the Flutter framework (that I have experience with through my Mobile Application Development course) was compatible at with Unity games. Lo and behold, there’s a package for that! Using Flutter for app logic would make menu traversal, list views for songs and scores, and persisting data a cinch. Upon looking back at our project spec though, I realized all the menu features were stuff I made up and not actually required for the project. While I still want to pursue this, it’s going to have to take a back seat, for the time being, to other game features.

Status

Right now we have a ring centered on the screen. We have nodes that fly from a distance to the four inter-cardinal spaces around the ring. It’s not synced with music, so, for the time being, we have nodes instantiating (existence and movement) at regular intervals, cycling through the four contact points. Players have the ability to tap the ring and, if a node is within the collision box of the ring, the node will be destroyed and a hit registered. If nodes aren’t tapped, they simply fly through the ring and are destroyed. Currently, the entire ring serves as a collision point and a player can tap anywhere, regardless of the where the node is coming into contact with the ring.

Unused Ideas

Initially we thought we’d have to create game objects that we didn’t end up needing. One game object was an origin point from which the nodes could come from. We used a second ring object placed at a distance from the first ring, far enough that it looked like a large dot on the screen. This was useful for getting a feel for where to originate nodes, but ultimately, it was unnecessary to have because all we needed was a good spot to move towards the player viewed ring from, which can easily be based off of the dimensions and position of the player ring itself. Similarly, we thought we’d have to create a sort of “track” that the nodes could use to travel between the origin point and the ring object. This too was unnecessary, as all that needs to be done is to translate the ring a certain distance every frame along a single axis (Z, in our case). Doing so restricts movement of a node along a single line trajectory, which was the goal.

Moving Forward

I have shifted gears away from worrying about menus and data persistence; “nice to have”s that can be implemented later. In the meantime, I’m going to work on scoring. I’ll approach it first by entering a text field on the game screen that will display the score to the player. I’ll add to the tapping logic to add a certain amount to a class variable when a user successfully taps a node. I’ll also add a variable to track how many nodes have been hit in a row, resetting in when the player misses one. Constants that defines what constitutes different streak thresholds will be helpful as well. The text field on the screen will need to be updated, so I’ll need to figure out how to make the score variable available to it in its script. Beyond that I’ll work on graphical changes that trigger when score streaks are reached. My partner will be working on separating contact points for tap registrations so players have to tap the node where it comes into contact with the ring.

I am really happy with the work we’ve put in so far, and it is cool to see the beginnings of the project come together. I regret not referring back to the project description as often, because I probably wasted about a week looking into menus. Moving forward, I’ll be checking back in with it to make sure I am focusing on what matters. Hopefully there will be time at the end to implement an app that embeds the Unity game within it, but that won’t be the focus for now. Regardless, I am continuing to enjoy working on our game!

Print Friendly, PDF & Email

Leave a comment

Your email address will not be published.