History of Son of Nor – Part 2

In part 1 of this series I said that we were convinced by a friendly game development studio not to use our own 3D engine for Son of Nor. This studio had made its share of experiences and passed its wisdom on to us. Julian then evaluated a few engines out there whose license would work for us. This is what happened next.

Reducing Content

Changing the development environment was not the only thing that changed. Son of Nor should have been an RPG with lots of content and quests around the magic system we developed: telekinesis, terraforming and spells invoked by symbols you draw with your mouse (i.e. draw a circle to get one spell, draw a special line to get another spell and so on). This was the second thing we were talked out of. Creating content and huge worlds requires a huge amount of manpower. Modelers, texture artists, animators and so on. We were told to focus more and really only release a very well-defined piece of the game that concentrates on the basic mechanic.

I remember hearing a slight relief that evening, when we had our Skype conference and Julian informed us about everything that was discussed. Having a much narrower scope made the project not look overwhelming and the decision to condense the game to something that required less content was accepted unanimously. Son of Nor changed direction to become a player vs. player arena type game. We wanted to concentrate on game mechanics and player’s skill. We wanted players to use terraforming and telekinesis strategically in a limited arena space. We wouldn’t need to create so many environments and monsters, NPCs, AI and other characters. It all looked much more realistic now. Here’s one of the arena maps we drafted as a proposal.

OK, on to the tools.

First UDK

A few days later the decision was made to port Son of Nor to Epic’s Unreal Development Kit (UDK). It has a very generous license for start-ups where the tool is basically free and you only pay once your game sells well. We stayed with UDK for only a couple of days, though. Although the development kit was great (especially from a sound guy’s perspective, read my other article about UDK from my point of view), we quickly abandoned it. We don’t even have a video of a running version of Son of Nor. It was too complicated or even impossible to migrate the sand algorithm for terraforming to UDK, which has a not so flexible terrain model if I remember correctly. Also, the UDK editor could not be as easily extended as another solution the team looked at almost simultaneously, which was Unity 3D.

Then Unity 3D

Unity 3D is very extensible. Developers can quickly write scripts and surface the script’s variables and functionality in a simple UI for artists and sound guys like me. We only need to fiddle with knobs and sliders this way without having to dive into programming. It’s no surprise that the community for plugins and extensions in Unity is huge! Just take a look at the Asset Store marketing page. You can purchase models, texture packs, sounds collections, network optimization code and much, much more. But to be honest, this is also one of Unity’s main weaknesses in my opinion. The tool is very extensible, but also quite basic. To really work effectively with Unity, you first need to buy a few fundamental plugins if you don’t want to do it all by hand.

But put all of this aside, Unity 3D allows us to work in a team that’s spread all over the world, share code and assets via SVN and test the game individually as we go along. No need to compile builds and distribute them. The terrain is flexible enough to allow for things like our terraforming algorithm (even though it works way slower than directly on the GPU, as it was the case with our own engine). Everybody can use their preferred tools. The advantages of Unity for our game were many and the arguments to use it as our tool of choice very convincing. Here’s the first video of an early port that ran in Unity. A test level that already featured telekinesis, terraforming, spells, shields, but still had arbitrary player models (some shooter military model with a gun, lol) and very simple lighting.

No, actually, THIS was the FIRST port ;)

We went to Unity 3D with a happy and a sad eye. Compared to some features we had in the original engine, we’re still struggling from time to time. We developed a tornado simulation that was built upon hydrodynamics, real world physics, in our old engine. And we thought that it looked quite cool even in an unpolished early state. We have a video of it in the archives. Note how the tornado pulls in nearby sand and how the two tornados merge at the top and sand flocks down. Geek porn, not safe for work.

The Magic System

From the video above you can tell how our old magic system worked. Aah, good old history. At that time, Son of Nor came from a story-driven RPG background where you had to cleverly use magic to overcome different types of challenges and fights. Discovering all the magic and actually conjure spells took some time. And it was supposed to take time. We didn’t want it to be an action game, we didn’t want the player just click a button and the character does all the work of conjuring, waving hands, mumbling spells. The player should really conjure this spell by drawing the correct symbols in the sand with the mouse.

But, in a PvP type game that Son of Nor should now become, it quickly was a major source of frustration. Players, hectically running around to avoid each other had to stop for a long time to conjure some meaningful spells. We had to find a different way. So Julian organized a real-world development weekend at his place in Innsbruck where we were about to discuss a completely new gameplay for Son of Nor.

In the next article I’m going to write about this meeting and the next step Son of Nor took after it. See you in part 3.