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.