Categories
Uncategorized

Cleaning The Codebase

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.

Categories
Uncategorized

Review Review

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.

Categories
Uncategorized

A Rough Start, But a start

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.

Categories
Uncategorized

Developing In (Dis)Unity

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.

Categories
Uncategorized

Collaboration Station

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.

Categories
Uncategorized

Shad(er)y Business

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.

Categories
Uncategorized

Good Team Bad Team

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.

Categories
Game Development

Problematic Problems

As seems to normally be the case, here I am on Sunday night, trying to get everything done that needs to be done, and there is so much more that could be done. However, it feels like a rhythm is starting to develop in our workflow, decreasing stress and panic greatly. Communication in the group has been great this week.

I was required to write a problem statement paper for our VR Rhythm game, which was particularly difficult to me. What world problem is solved by creating a video game? How can a problem statement be written for the creation of a game? I decided to try to explain that there is a demand for new games, and so the creation of our game would help meet that demand, and thus solve that problem. It was a stretch and flimsy at best. Receiving an 80% with notes saying that I didn’t properly hit the prompt, I decided I would resubmit.

So, after many hours of debating with myself, some guidance from the professor, and forcing my wife to listen to my complaints, I selected a new approach and tried again. Unfortunately, my original could not be salvaged. I needed a complete rewrite. And it paid off! I have now received full credit and glowing comments from the professor.

My advice for writing a problem statement for a video game project:

  • Look internally for the problem! The problem should not be something external to the game, but instead should be a problem that you expect to encounter in developing the game.
  • Look to other developers for solutions! Chances are other games have faced similar problems to your own. How did they address the problem? Would that work for your game?
  • There may be multiple solutions! My whole team ended up addressing very similar problems, and we all came up with different ways to solve it. Ultimately, combining portions of all of our solutions will create more novelty than any singular solution.
  • The whole project is not the solution! You don’t need to find a way that every piece of your game is tied in to solving the problem. It could be solved by a single system, or it could be many, but don’t try to force your entire project to be the solution to one problem.

Writing problem statements, and requirements documents aren’t very fun to me. However, I can already see the benefits of having these available when we start developing in earnest. Looking to the future, developing plans for how to address problems, and outlining specifications: it’s all making me excited to make something!

Categories
Game Development

Project Assigned

So, this week has been a crazy dash to get things done. Midweek we were assigned our capstone projects. I was hoping for something in game design, and I can’t be happier with the results. I will be working with a team of two other people to create a VR Rhythm game.

So far, communication with the team has been somewhat difficult. One of our teammates is in a different timezone, but I’m actually glad because I want experience working with people around the world. I like the idea of working remotely, and this is an excellent opportunity to develop teamwork skills. So far I have learned that it is very important to have the whole team decide on a method of communication as soon as possible, and a standard for how frequently people should response. We decided on a 24 hour turnaround on any communication, meaning if someone sends me a question, they can know that I will respond within 24 hours at most.

The contact for the project happens to be the professor for the capstone class. This simplifies things in many ways, but at the same time I would typically communicate with a professor in a very different way than a client. For instance, I may talk to a professor for advice on how to communicate with a teammate if they are not being helpful, but that sort of communication would be very inappropriate and unprofessional to send to a client.

We had our first client meeting just earlier today to discuss some of the specifics of the project. To my surprise, it is extremely open to our own creativity. There is no specific look, or game play loop that is required, other than for it to be in VR, work on the Oculus Quest, and be a rhythm game. My mind is buzzing with possible options. With only 9 months to build the game, it is going to be hard to implement too much. I can already tell scope creep is going to be a struggle. It would be easiest to make some sort of BeatSaber clone, but we want to take it in a different direction, doing our own thing, developing something new.

I’m excited! Let’s have some fun!

Categories
Game Development

Undeclared Identifier

Video games are still a relatively new medium. They are different from books, paintings, and film in that the people observing the art created (the video game) interacts with it and feels as though they themselves are the ones engaging in the story. You may hear someone mention that at the end of a game Mario saves the princess, but you are more likely to hear them say “I saved the princess!”

I have been fascinated with video games since I was young and our family purchased our first Nintendo Entertainment System. I believe this medium of expression opens up new modalities to play, learn, and grow. Through video games, we are able to put ourselves into the shoes of someone very different from ourselves, in a way we would not be able to in our regular lives.

So, I love games, and the vastness of experiences that they can offer. I am currently pursuing a degree in Computer Science, with a focus on video game and simulation design. As I go into my senior year, I will be chronicling my experiences with my capstone project. I am hoping to work on a project that directly relates to game development, but if not I will be trying to see how what I am working on and learning can be applied to game development. It should be a wild ride, lets have fun with it!