Undeclared Identifier

Don’t wait to clean your codebase, keep it clean from the start.  Our team has had problems moving between branches and there are many reasons we have had issues.  Right from the start, none of us cloned the main branch before making our own branches, so we have no matching commit history, therefore we have been unable to merge branches together.

Additionally, we did the one thing that should never be done, we ignored the .gitignore.  Never do that!  Our repository was filled with personal preferences and config files, log files, library files, and large packages that had been downloaded from the Unity asset store.  This in combination with the fact that we started on distinct branches means that there were multiple copies of the files being uploaded and our free GitHub repository almost hit the size limit.  This also meant whenever we tried to change branches, we needed to spend thirty minutes to and hour downloading everything from the branch.  This has been a serious problem, and now is the time for it to stop.

So, this week has been a week of progress, but also a week of organization and cleaning the codebase.  I have spent hours cleaning, merging, and configuring gitignore files.

Configuring .gitignore:

Configuring these files were easier than I expected.  This page was very helpful in learning how via the examples provided: https://riptutorial.com/git/example/885/ignoring-files-and-directories-with-a–gitignore-file.

Cleaning:

Once the .gitignore files were configured, I was able to safely remove any of the files that were now being ignored by git.  If people’s local repository needed the files, it would not remove them, but it also meant that we did not need to download them when switching branches.

Merging:

Since none of our branches shared a commit history, merging was a bit more tricky, but I developed a method that works pretty well.  I simply created two Unity projects, one to be the one that in the main branch, and another that is temporary.  With the temporary project, I could pull any branch that needed it’s code to be merged to the main branch, then could navigate to the local repository and simply copy and paste the files into the main project.  This worked easily because none of us were working on the same files.  I did need to rename one scene before copying it over because it shared a name with the scene from the main branch.

All in all, I probably spent about 6 hours this week trying to clean the codebase.  We should have kept it clean from the beginning, but it has been a great learning experience.  But please, don’t be like us.  Keep your repository clean from the beginning, and above all, don’t ignore gitignore.

This week I did my first code review.  I have never reviewed anyone else’s code before, and this was an interesting experience.  At times, the scope of this project feels insurmountable, but this code review gave me a great amount of confidence that we will be able to complete it.

Xinpeng was responsible for writing code to create, move and destroy the note blocks that will be used for our rhythm game.  The approach he chose was different than I expected, and I think quite elegant, with a waypoint object storing destinations, and the move function causing the blocks to move towards those destinations.  This method could allow us to create unique movements for the blocks as opposed to just a simple straight line.  I had never considered an option like this, but immediately saw the potential.

This simple and elegant solution has given me a great amount of faith in my team, not that I didn’t have faith in them before.  But this has showed me that even when I am not involved at all in a portion of the project, it will be done well.  The code was clean and probably better written than my own.

I also feel I learned a lot from this short exercise.  I learned how important documentation is, because I had no idea what the purpose of the waypoint code was until I read the README file that Xinpeng provided.  I was able to read the code and understand exactly what it was doing, but without the documentation I didn’t know the purpose. 

I also learned about keeping the code clean and a way to structure code that should have been obvious to me.  In the code I reviewed, the Update method was used exclusively to call other methods.  Those methods were all very clearly and descriptively names.  This made it so easy to see what was happening, and in what order.  I am going to implement these as I go forward, because I don’t want others to have to read through messy code.

I was dreading the code review, and honestly didn’t have much faith in the process.  It seemed like it might just be a way to discourage people.  I am pleasantly surprised, and happy to say that I was dead wrong.

This term has been off to a bit of a rough start. We have become more organized through the use of Trello, but there have been unexpected problems that popped up. Last term the Oculus Quest was working well on our systems, and working with Unity. This term, we updated to the latest version of Unity, and have had issues with connection. Personally my system keeps telling me I have hardware issues that are preventing me from running the test environment.

At one point, I had figured out how to get it working, which was great! About 5 minutes later, the screen would go black instead of showing the environment. Other teammates have run into other issues, such as Windows deciding that the Quest is a multimedia storage device, and not registering it as a headset.

Despite the issues, I am confident in my team and our ability to get this all up and running. Soon, we will iron out these issues and be in full development. We have had pretty good communication so far, even though I forgot to post a blog last week.

This next week I am beginning to develop some of the UI elements, such as health and mana bars. Under normal circumstances, those would be very simple to program, but with VR, everything is more complicated. Instead of being a part of the display, the information must be part of the environment, so placement is key. It needs to be easily seen while the player is playing the game, but it can’t be so noticeable that it becomes obtrusive. It will also mean objects will need to be communicating with each other to receive and process information. As someone new to Unity, I will be watching a lot more tutorial videos. But, that is just an exciting excuse to develop new tools for my game development toolbelt.

Over the past few weeks my team and I have been working on developing a prototype for our game project.  I am hesitant to even call it a prototype because it is far from being a functional game.  In fact, we weren’t even working on the same code!  We decided to use this opportunity as a spike, to generate some answers to questions that should be figured out before we move into full development.

We each started developing on different versions of Unity because we wanted to evaluate the support and difficulty involved in integrating VR into a Unity project.  What we have found so far, is that there is not a lot of difference in the work involved, but the newest version of Unity does seem to have more support than other versions.

For most of our team, this is the first time we have used Unity.  I can’t speak for anyone else, but it is definitely the first time I have used C#.  I knew it would be a bit of an uphill battle to get over the learning curve, and I am sure I am still not over it yet, but the development so far has been okay.  I have run into many instances of silly mistakes on my part, such as changing the name of a variable in one place, but not everywhere, causing my code to fail. 

I spent hours trying to figure out what was wrong, assuming there was something wrong with my approach, or some setting in Unity was not configured correctly.  I had assumed that my code was definitely not the problem, but you know what they say about assuming things.

So, ultimately, using Unity has been very time consuming for very little payoff, but most of that is my own fault.  I was an odd mixture of intimidated by the new tool and over-confident in my own programming skills.  So I searched for the solutions in all the wrong places when it really was the need to go back to basics.

Ultimately, I like Unity.  I see that it can make certain portions of the project very easy to implement and I am excited for the work to be done in this next term.

This week we shared our design document with another capstone team, and we collaborated on each other’s work to give feedback, ask questions, and answer questions.  It was an interesting experience because I am often uncomfortable showing my work and ideas to people, especially before the ideas have become a finished product.

What I have learned is that I need to open my ideas up to people earlier.  The feedback I received was helpful and encouraging, even though there are some places that need improvement.  I think going forward this is going to be very important for, not only the capstone, but all game development I do going forward.

The feedback gave me an unexpected amount of inspiration.  Going into the assignment I assumed that having another group look at, critique and comment on my work would be disheartening.  Instead, the feedback was encouraging, and got my mind running with new ideas and new ways to approach the problems we were trying to solve.

Additionally, it was easier than I thought to disregard feedback that I did not think was right.  I assumed that it would be disheartening to read criticism.  This made me realize I probably need more criticism in my life, especially in my game development.

So, going forward I am going to try to test my ideas more often with other people.  I will make beta versions of my games and open them up at first to people I know and trust the opinions of.  Then, gather feedback and iterate on the process.  If those that I trust think what I have is good, then I need to open it up to a wider range of people, such as giving free beta versions away online.  Then, again, gather feedback and iterate on the product.  I know that no game will please everyone, but I am not interested in pleasing everyone.  I am interested in creating the best games that I can make, and collaboration and feedback is an important part of that.

It is always interesting how knowledge from other courses can be applied to game design, sometimes courses that would be least expected. Computer Graphics is not one of those courses. Computer Graphics is obviously going to be related to making video games, there is no surprise there. This week in Computer Graphics we have been learning about lighting and shaders, so the whole time I have been thinking about how I can use that knowledge and apply it to the VR Rhythm Game project.

Shaders are able to do some amazing things, and much more efficiently than other methods because of the hardware support of the graphics cards. As the person in charge of the User Interface, I feel that shaders will be especially useful to me. They can be used to make visual effects, warp objects and apply texturing. Best of all, Unity has built in support for the shaders, so creating shaders should be a simple process. I look forward to digging into shaders and learning how to get the most out of them.

Before this project I hadn’t realized just how all inclusive Unity is. The tools available out of the box make putting together a game much easier, if you take the time to learn the tools. And that, I believe will be the biggest difficulty for this project, learning the tools. I have every confidence in the team’s ability to write the code and get everything functioning, but for two of us Unity is completely new.

Despite the oncoming learning curve, Unity is definitely the right choice for this project. The all-in-one system will make it easier to manage the project, and the plethora of free assets means we don’t need to keep reinventing the wheel.

Never underestimate the benefit of good teamwork, but you should also never underestimate the encumbrance of bad teamwork. During this term I am taking four teamwork intense classes, and the difference between the teams I am on is stark. Let’s begin by examining the bad.

A team I am in was required to prepare a presentation, and present in front of the class. The presentation was prepared on Google slides. An interesting thing about Google slides, is that it records every change made by every person, so it is possible to see exactly how much different people contributed. I felt that I was doing a bit more than my fair share, so after the presentation, I checked the records to see how much each person contributed. There were two people who’s only contribution was literally adding their names to the slide deck. There were also two people who without notice did not show up to present. It only takes one guess to figure out which members those were. On top of that, the group is unorganized, and will not respond to communications in a reasonable time, if at all.

On the complete opposite end, you have the group that I am working with for the capstone project. They respond quickly. They actively engage to help. They have, in a short time, earned my trust. I know if they say they will get something done, it will be done. They contribute, a lot! When we are putting together the group papers, they do an amazing job of merging our ideas together, like putting puzzle pieces together to makes something greater than the sum of it’s parts.

This vast difference in group dynamic drastically changes how I feel about the course. The first class, I am now dreading. I can’t wait to be done with this term so I don’t have to work with them anymore. But when it comes to this capstone project, I can’t wait to be done with this term to so I work even more closely with my two partners. Here is to you, Zach and Xinpeng. I have hope that we will succeed in this project, because of the both of you.