Corrupted: A Prototype Post Mortem

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.

Moving Forward

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.

Corrupted: A Mid-term Check-in

For the first part of my Studio Elements III Practicum class I was assigned the task of taking a prototype, and recreating it using the Unity Engine. At this particular point in my career I had never used Unity more that simply placing pieces at designated points and creating simple JavaScript (read UnityScript) code for extremely basic interactions. I was eager to take this project on as I had reasoned with my professor and boss that having a prototype of something to show in an interview can reflect very positively on your chances of getting hired for a job due to the gained competency in the chosen engine. I was assigned a partner who was to handle to design document of the game itself. So here’s a check in on my progress of corrupted from the beginning all the way up to the mid-term presentation.

 

What is Corrupted?

This is the original prototype of the game. Coded in Java by a coworker of mine in mid 2013

 

Corrupted was a game originally designed by one of my coworkers at the lab, The project was part of a series collaboration with the National Science Foundation. The project includes an educational version and a commercial version of the game itself. In Corrupted originally, The player takes on the roll of a ship…or triangle…you what I’m not really sure what that red thing is. Anyhow, a giant corrupted image appears before them and they must battle the corruption by shooting pixels at the image and creating matches of 3+ pixels. As they work to save the image from becoming completely corrupted, viruses appear that can halt the player’s progress by corrupting pixels, creating blocks that the player can’t create matches from- like stones that you can’t break. the play of the game is designed to be more of an arcade style game where there isn’t much of a story and the experience of battling viruses in this unique way is all that would really matter to the user.

 

The Goal

The goal of this project for me personally was not to create a brand new game, but to gain competency in using and understanding an engine of my choice. Through this understanding I would gain more knowledge of how to manifest game design on a physical plain via a more well constructed design document rather then a meta physical one with just words and abstract images. The choices I had were Unity3D, Source and Unreal 3. Unity3D is the most used at the Digital Future Lab and is the underlying framework for the majority of the games and projects the lab produces. Not only that but it offers a very robust and round-about way of visualizing game development. As a designer at this point, my logic when it came to things like puzzles, and game mechanics was there, but not exactly honed in a way that makes logical sense. Learning how to use an engine to set up puzzles I theorized, helps ground your logic as you have the limitations of the engine itself to cling to rather than being left with nothing but the blue sky.

 

The Process

This is the basic setup I created using Unity 3D and the NGUI framework.

 

From the beginning of the project until this post I had spent most of the time setting up the project. Putting in basic elements of the game and coding them to make sure they had similar functionality to the prototype before. a major challenge with this process alone was cross-interpreting the code. The original prototype was created using straight Java. Java is a programming language by all means, but Unity approaches things through Scripting. I couldn’t use any language like JavaScript due the the possibility of a second developer taking this prototype and improving upon it. So I took the plunge headlong into C# and began teaching myself how to set up components, reach components through code, how to use scripts and how to access scripts from other scripts. All of this was intertwined with how to properly set up the game in a way that could not only be readable from a players perspective but also from a developer perspective.

When constructing this prototype I emphasized speed over quality as I wanted to convey the concept more than have it look pretty. To this end, I forwent using base unity code for the Next Gen UI (NGUI) framework) for it’s ease. In my mind as long as it worked, I was satisfied (and so was my professor). A setback within this logic though when it comes to development is that it leads to some major coding laws and process that aren’t implemented right, broken or are simply frowned upon. I endured a lot of finger-wagging and in some cases, straight up cursing as I asked others for help when I got stuck. comes with the territory I guess.

My Bitbucket repository for the game Corrupted

 

The Result (So far)

Right now I’m at a point where I have player movement setup, and a grid that spawns random blocks in rows. I can fire blocks up at the grid and have then stick to the grid but I can’t create matches yet. I’ve never approached the idea of creating matches before so it seems mind boggling to me as I search and search for possible methods of incorporating this core mechanic One possible way I thought of was to simple draw raycasts in each of the cardinal directions for every block and check once per frame to see is a match exists. This method proved to be both time consuming and expensive on the CPU. So right now I’m at square one  with matching, setting it up and looking for way to make this interaction work.

 

What have I Learned thus Far?

Other than gaining a more knowledge of how to use Unity and NGUI together, I’ve gained a few insights as a designer :

  • For good puzzle logic stick to the script.

    • For some reason I find it a lot easier to approach puzzles when I think about how I could set them up through scripting. For comparison, before hand I was using the “blue sky” approach where I put things together rapidly in order to create dynamic I wanted without intrinsically understanding how the mechanics worked together. Now I have a little bit more of an understanding of how to construct puzzles.
  • Asking for help is NOT BAD!

    • This seems like kind of an obvious one but before hand I had it in my skull that If I came to a problem, I had to solve it and that I would keep banging my head against the wall until something happened (no not literally). The fact that I couldn’t solve many of the problems I came across during this first half of the project actually began to bore a bit of a hole in my self-confidence as a game designer. I thought that if I couldn’t do it by myself then I wasn’t cut of for the industry. That’s a very defeatist attitude that doesn’t solve the problem at all. By asking for help, I was able to not only get the parts I needed help on finished, but I was able to learn more about C# scripting practices from more experienced developers (you know….after they were through insulting my code).
  • Teamwork makes the dream work

    • I couldn’t have gotten this far without bouncing most of my ideas off of my stakeholder (my professor) and my fellow designer who managed the document. Together all three of us were able to create a learning experience I would deem essential to any design student (whether it’s of games or general purpose software) to have. Being able to weigh the perspectives of my stake holders and what they want out of the product along with my coworkers and I, served a lot to help me get a grip on what the project was, how the rules of said project worked, and how to create ideas that matched the dynamic that both parties wanted.

What Happens now?

Since the quarter isn’t quite over yet I’m going to continue working on the prototype to get as far as I can. The most important thing to me right now is making sure the core mechanic works (matching blocks). Once that works, I’ll be able to add virus behaviors into the grid to oppose the player. The challenge though gets a lot bigger as I work on making things interactive (which isn’t something I’ve focused on much before).

© 2014 Kaylin Norman-Slack

Theme by Anders NorenUp ↑