During Spring quarter at the University of Washington Bothell in 2013 (April 2014 to June 2014), I opted to become a scripter and create a prototype of a game that already has an existing prototype. In this project I worked with another classmate who took on the role of a game designer. I reasoned that this would be a great learning experience due to gaining familiarity with an engine of my choice, along with learning some basic process of scripting events and game logic. The engine I chose to work with for this project was Unity as it is one of the easiest high end development tools to get into. Also, knowing C#– a programming language that’s used more or less like a scripting language Unity, would be easier to transfer to other projects should I decide in the future to continue learning C#. Before this project I knew of Unity, the basics of how it worked and how to move within it’s interface. The part that I hadn’t learned about as of yet was how the code interacts with the engine, and therefore the game. Also, I knew very little of how to code. I knew how to put things together but not in a clean and neat way that functions perfectly all of the time (To gain that knowledge in my current situation as of this post, I’d have to double major in CSS…Not happening).
What went right?
Setting up the game’s front end was probably the easiest part, both in Unity and in C# code. Setting up how player movement, the placement of the objects within the scene and setting there relation to each other through code came the easiest to me. This is mostly because prior to taking this project I took a crash course on scripting in Unity through Digital Tutors before begging to do the project. The concept of the game was solid enough that I was able to easily translate the mechanics that were present into the new prototype.
What were the challenges?
There were tones of challenges with this project that spanned from both the design aspect to the coding itself. The Biggest challenge that I had to overcome was that I Could Not do the design of the game! My partner was the designer and so as the “scripter” I had to build my prototype to his design (This seems like an arbitrary hindrance to the project but the reason behind this is so that he could get experience being a game designer.) When it came to the team work aspect, my partner and I had a clear idea of how the game worked, but after a certain point in time our ideas began to diverge from each other and meetings would then become discussion about simplistic functions of the game. How many shots or turns does it take to add a new row? What power ups will be in the game? How do the viruses move and when do they spawn? These were questions that I asked a lot during the meetings that weren’t given particular answers. So these features weren’t implemented correctly. Coding in C# was easy as far as User Interface and setup went thanks to the aid of the Next Gen UI plugin (NGUI) for Unity, it took a lot of the hard word out of it and allowed me to set it up fast and get results that my stakeholder (my professor and boss in this simulation) wanted to see. As I delved into the interaction and game-play programming things began to get tough. I had no prior knowledge of how match three style games worked when it came to matching, and no prior information on how to get a proper grid working. In Unity, I used a series of “List” objects in order to generate the grid at random and in order to have the player fire blocks randomly. It was at this point that I asked for the help of several programmers I knew I’m going to be completely frank about their responses, they insulted my code–hard. I got snide comments that ranged from “Your code sucks” all the way to “Your code @#$#ing sucks.” I had only a few people who were able to help me through the problem of adding blocks to the grid–which turned out to be a simple function that sets the object’s transform property from one parent to the other on collision, and the biggest problem of creating matches from three or more blocks from a grid. I attribute this success to my friend John “RebelMoogle” Mclaughlin, a talented programmer I met a few years back during a Global Game Jam! This problem was solved through a simple recursive routine that adds the blocks to a list as well as itself, then having the master list that it’s added to delete itself. Something else I want to highlight in this challenge was the team work aspect. communications between the designer and I were down a lot. This caused me to create a prototype that functioned slightly different from what designer had intended due to the communications being close to non existent. Referring back to the design document that the designer crafted often lead to me asking questions that were often not answered in a timely matter, if at all. My biggest mistake was taking things into my own hands and putting together loose ends to try and form a coherent experience. Even though this seems rather heroic, it’s not a good idea as it inevitably leads to more communication errors between the designer and the programmer.
What have I learned?
I learned what I had suspected to learn (How to think more logically, how to see the inner workings of a game, how to communicate better with programmers) and so much more. I learned about the deeper aspects of logical thinking when it came to how mechanics worked an interacted with each other due to having to work deep into the interaction aspects of the game. I also learned how to relay these aspects to my partner who in turn produces designs that matched (occasionally). I learned about and familiarized myself more with Unity3D and it’s interface. I feel more confident than I did a quarter ago about working in Unity 3D and C# by proxy because of this experience. Speaking of C#, being able to spend all ours of my evenings alone, and completely immersed within the Unity-specific use of C# game me a better foundation on how to create scripts, use functions in an optimal way, and interlink scripts so that my scripts can talk to each other and become aware of one another. I leave this project overall with a more confident feeling than I had at the start of the quarter when it comes not only to being able to build a prototype of a concept to show, but also when it comes to thinking logically when it comes to my designs.
What can you learn from what I’ve learned?
If there’s anything that you could take from this experience it’s that asking for help is a great strategy to solving a problem. Doing so does not make you weaker or incompetent-actually quite the opposite. In the long run, it’s a lot better when in a bind or a crunch to find someone who has knowledge of the problem and a possible solution rather than to bang your head against a wall trying to solve the problem yourself. Another thing you could take away from this is to watch how you set things up! In my haste I didn’t pay attention to the way I set things up in my development environment. This inevitably lead to much frustration on my part as I searched through lines of terribly written code to find my problem. The last thing you could take away from this is Communication is important- extremely important. You could have the most elaborate design that elicits a specific response out of a player, but it’s not going to mean anything if you haven’t communication exactly how this experience works, or how to set it up to the programmer. If there are communication errors, address them immediately! It allows everyone to better synchronize their thought processes around a specific task, product, etc.
Corrupted will be developed out into a full game, but without me at the helm as a scripter, I may instead join as a associate designer under one of my coworkers or classmates. I will however move forward with the knowledge I’ve gained from this experience, Not only can I confidently say I know how to create scripts within a development environment, but I have samples of it to show as well. In my future projects I will learn how to better set up environments, and look a little more into code optimization.