RagNoK: Post-mortem


     RagNoK was a game I worked on in a prototyping class last quarter. I knew from the start I wanted to work on a game using Unity as our primary engine. After using UDK for several projects in the past and seeing the challenges it offered I wanted to try something new and having studied Unity on my own for a few weeks I had an idea of the benefits Unity could bring to our student project.

What went right:


Bringing assets into Unity was incredibly easy and it made prototyping things quickly a piece of cake. The modular way in which game objects are put together made it really easy to swap placeholder art in and update existing models with textures or fixes as they were available.


The scripting environment in Unity made it possible to create almost anything we could dream up in a short amount of time. I also appreciate the ability to rapidly test code as opposed to something like UDK where it feels like you have to jump through a ton of hoops to get the engine to recognize your scripts and then you have to wait for everything to compile to see if it works. The drag-and-drop plug-and-play nature of Unity makes coding what it should be: a joy.


In the end my team ended up with a complete project that can be built out to play on the web. This is an awesome thing for a student project becasue it allows us to show our game to anyone with a web browser.

What went wrong:

Unfamiliar technology:

One of the hurdles we slowly overcame was everyone on the team being unfamiliar with Unity. Luckily the way the project ran the artists were able to simply work in their prefered 3d package but a lot of models needed to be rotated or resized due to the teams inexpereience with Unity. This ended up creating a bottleneck in the amount of time it would take to get assets into the engine.

Another issue we ran into was in the optimization department. By the end of this project I learned a lot about how things worked in Unity but didn’t realize how many places our game could have been better optimized. As with any new technology I feel like these are the kinds of lessons you get from the experience of seeing a project to it’s completion.

Time Constraints:

I’m sure this happens all the time but due to the amount of time we had to work on the game we had to cut a lot of our ideas. A big example of something that ended up on the cutting room floor was multiplayer. We also could have done more with our GUI and sound.

In the end the learning experience and the creation of a working game makes me proud to have been a part of this project.