Interactive Media Design One Year Reflection: From Chaos to Order

I’ve haven’t posted anything in quite a bit, and this has been rattling around in my head ever since May. I’ve always wanted to do a post on my experience with the Interactive Media Design (IMD) degree at the University of Washington’s Bothell campus. This degree was announced a couple of years ago as a degree that sought to merge the rigorous practices of Computer Science with the amorphous and ever expanding blob that is the media arts. The website boasts that graduates of the degree will be able to boast the following skills:

  • Demonstrate a solid understanding of core theories and learn advanced concepts related to the analysis, design, development and implementation of interactive media projects.
  • Use contemporary media design tools, technologies, processes and techniques.
  • Create a variety of interactive media projects that demonstrate breadth and depth of knowledge.
  • Focus on methods and approaches for effective team building and productivity.
  • Establish specialized knowledge and skills in a student‐defined, media‐related specialty area.
  • Experience intense team‐oriented projects that require working with faculty and media design specialists from a variety of disciplines.
  • Gain a thorough understanding of quantitative and qualitative analysis techniques used throughout the media process.
  • Develop a thorough understanding of technology infrastructure and systems required to support next‐generation media projects.
  • Practice effective communication techniques – including documentation, project updates, formal presentations to a variety of audiences, and creation of an effective portfolio.

Pretty tall order for a new degree. Especially one that looks to create competent designers who can master both the arts and the sciences. I am a student under this new degree and It has been a full year since I switched over to the degree from Media and communication studies. From my experience so far with the degree there are very profound differences between Interactive Media Design and Media and Communications.

The way the program works is that it has an assortment of carefully selected and often times custom created courses that are program requirements. These are courses are the Studio Elements class. The Studio Elements class has up to 5 different instructors teaching you different skills in modules. This isn’t at the same time though! For example, maybe the first 2 weeks you’re taught how to program something in Javascript, the next two weeks you are taught the basics of photography and so on until the end of the quarter. Each instructor has their own grading system and a grade from each instructor is worth about 20% of the overall course grade, meaning that you’d have to fail around 3 modules to fail the course! The Studio Elements Practicum class has one instructor and unlike the elements class focuses very little on theory and a lot on practical applications. You’re often paired up in a team and given a position. In every team as of this post, usually includes:

  • 1 creative director responsible for maintaining the creative vision of the project and interactive with the stakeholder.
  • 1 designer (Game, Interaction or something in between) who is responsible for working out how the product will work.
  • 1 Narrative designer/director who is in charge of creating the narrative.
  • 1 producer or project manager who is in charge of keeping everyone on track and making sure deadlines are met.
  • 1 product manager who is responsible for the marketing aspects of the product.

This structure isn’t exactly rigid. The IMD program mostly focuses on creating applications that match the University’s wants and/or needs with some focus on entertainment applications like games. There was a project I worked on back in September of 2013 where I was put in charge of writing the script. the project was a Tox map that described…something. When the project started there was no data to product a narrative from, which made everyone’s job difficult as we were grasping for straws on how to even make one work. We eventually figured it out–just before the discovery that a toxmap that had very similar functionality to what we had spent weeks designing already existed! In the end I learned a lot about team work.

So How did it go?

First and foremost, Interactive Media Design has you not only learning how to create media software, it puts you within a studio environment with your fellow class mates where you have to create software and various other media within teams. How is this different from the Media and Communications degree? Well, they both have you in groups creating projects but with the IMD degree, Teamwork is absolutely required! Almost all classes have you separated into teams working on the assignments that you are given by the instructor. Most students, who were reared through the K-12 system, have probably been in situations where they’ve been in teams and have either ended up doing all of the work, or not being able to do any for some reason. The IMD degree doesn’t ask, it demands that you become a productive member of a team- but not at the get go! Now as stringent and strict as this sounds (especially the way that I’ve typed it), It’s actually a very good thing. When I first entered the degree, I was not a team player. I withheld information, I was silent, I tried to keep my work to myself only to submit it at the due date completed. In a traditional system, this works just fine, but with IMD, even if you do things this way, you still run the risk of not passing due to the peer reviews that you might get from your fellow class mates.

My peer reviews were beyond terrible due to my inability to be a good team mate. This changed as I went on with the degree though.If there is one saying that summarizes all of the projects that I have done as an IMD student it’s:

“From chaos to order.”

Every project that I have been on starts out as a near chaotic mess, I was unsure of what to do or how to act or what my position even meant. As the project carried on however, I started getting used to my role, and my team.

Is it Worth it?

I’d say yes! It seemed off putting at first given the new environment that the degree created. This new environment however, mirrors the type of environment that you’d have with a professional studios. You’d have a pre-production period where you nail down the concept through designing out the document and rigorous meetings to discuss progress. You’d be learning “design tools,” which by that I mean a lot of programs that range from MySQL and similar database programs to creating web pages via HTML5 and Javascript. You’ll also learn a lot of digital art programs like Adobe Photoshop and Toonboom Storyboard Pro – a program that’s actually quite popular in the Animation and cartoon world! So all in all, the IMD program has a solid base, it’s clearly different in it’s expectations for student engagement. But not everything starts off with a smash hit! There are almost always has challenges and this was no exception.


The IMD program is extremely general, compared to say Digipen’s game design programs which are extremely specific. The theology behind the IMD program being so general though is that the graduates will have skills that can be applied to multiple disciplines. Though this theology is good, there isn’t enough yet to support it. Of the classes the students have to choose from it’s either experimental art forms or SQL databases and computer hardware. These things are changing though which is really good. To be fair these are good skills to have, but if I want to be say, a graphic designer, then learning the ins and outs of a computer, along with how to program an maintain a database wouldn’t interest me in the least. Vise versa if I’m into computer hardware and have to sit through a class where I have to animate something. Another challenge that it can have is that information is thrown at you in rapid succession- more rapid than you would normally have with education.

So how do I handle these challenges?

Well, as one of the 20 or so students that remain from the original 32, I’ve learned to utilize other sources in order to supplement my education and help guide me toward my goal. There’s also the Digital Future Lab, which offers internships to students sometimes that have them working on either games or interactive software! The nice thing about it is that it counts as experience that you can put on your LinkedIn or Resume to use when you apply for your first job! There’s also the various other projects I do that can help contribute to my resume.

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 ↑