Category Archives: Unity3D

Katastrophe! goes gold

After 12 weeks of planning, scheduling, managing, meetings, designing, codings, bug fixing, optimisations and for me multiple weekends and after school hours meticulously tweaking, researching specific areas until my tasks behaved as I envisaged my parts to behave, e.g. Mirror reflection and controls, Collectable AI, Puzzle FSM, Save and load manager, shaders development, XML Achievement system, GUI creation facilitated by NGUI and Occlusion tuning, Dimidium Games is proud to present the final release version of Katastrophe. Post mortem to follow. For the time being you can grab a copy of the installer here.

screenshot screenshot1screenshot2 screenshot11screenshot13 screenshot14 screenshot20 screenshot23 screenshot25 screenshot31 screenshot32 screenshot36 screenshot38 screenshot40 screenshot43 screenshot47

Storing encrypted strings in memory

Whenever you want to store values as string in memory, whilst at the same time prevent external tools from either finding the value and changing it. e.g. changing high score values. You can use the built in System.Security namespace to do so, the following code shows an example of this.

using System.Security;
using System.Runtime.InteropServices;

SecureString secureStr = new SecureString();

int Score
{
    get {
        var bStr = Marshal.SecureStringToBSTR(secureStr);
        var scoreStr = Marshal.PtrToStringBSTR(bStr);
        Marshal.FreeBSTR(bStr);
        var score = int.Parse(scoreStr);
        return score;
    }
    set {
        secureStr.Clear();
        var chars = value.ToString().ToCharArray();

        foreach (var c in chars)
        {
            secureStr.AppendChar(c);
        }
    }
}

The caveat to this is that its only supported currently in desktop, so if you’re planning on using this code inside unity it wont work for mobile and web as they dont have Marshalling available within their JIT compilers.

If desktop is not an option, alternatively you can hide the value using simple crytography. In its simplest form this can be achieved by means of XOR’ing the value. To allow it to work, a random secret private key is chosen and this is then used to encrpyt and decrypt the value. The following code snippet shows how

private int key = 9999;

int score;

int Score
{
    get { return score ^ key; }
    set { score = value ^ key; }
}

An even better way is to randomise the key when you store the value, as shown below

int Score
{
    get { return score ^ key; }
    set { 
        key = GetRandom(1, 9999999);
        score = value ^ key; 
    }
}

int GetRandom(int min, int max)
{
    Random rnd = new Random(); 
    return rnd.Next(min, max);
}

This way even if they do stumble across the value, the next time they look for the same value it will have changed. Its fast and its also available on most if not all platforms.

Prototype Week4 – Bug Off!

Due to technical difficulties from last weeks presentation, none of which was our fault thankfully. We did however go out feeling a little robbed of all our efforts. So to make amends we decided to investigate the same game some more. Some of the other teams had done so already with one of their prototypes and granted it was within the rules to continue and expand on an existing prototype, we felt this was the game that required this need. The only caveat was we decided to step it up a notch, which wasnt as bad as it seemed as we had become more familair with unity over the weeks, which also built up our confidence with the tool. We were also becoming much more comfortable with each other and their abilities, so the time was right to spread ourselves more thinly and onto new unfamiliar areas. Firstly, it was time to delve further into the story and experiment on existing mechanics, either polishing them up or adding to them on the programmers side, while on the art side, more detailed models and texturing would be their next stage.

For my task I personally took on the responsibility of creating an in game fly through camera, something I have wanted to do for a while in unity, also investigating if a rewinding feature could be implemented. This rewind action would be called via a button press, namely ‘r’ this would then being the process of reversing the characters movement until the button was depressed, it was designed to remove the need for a life system giving the player a softer punishment rather than a harsh one of restarting from a designated checkpoint. I always thought any type of fly through camera was a better form of narrative in explaining or emphasising points of interest. In our attempt, we utilized this technique by indicating where the character should go next from their current location. It would be implemented as an extra camera that would follow a path, smoothly until it reached its end point, in which event it would switch back to the main camera. The flythrough was borrowed from a google search and massaged into our code. I discovered that the system was using time to calculate the path to follow and this would cause issue when run in game. Basically once started, the flythough camera played. So when the cameras are switched we had not way of pinpinting the position of the flythrough camera which was already making its way around its designated path, which and was also looping back to the start once it completed its full path. So the cheapest workaround with the least rewrite overhead in getting around this was to position and save a prefab in edit mode and save it out as a prefab, later instantiating that prefab with initial positions set automatically. The prefab would then appear and run as if it had been set to run from the beginning, of course some may say, why didnt you just reset the time to zero. Well this is because it was using system time and this is read only. In any event this workaround fixed the issue and was enough to get our point through during presentation time.

The rewind feature on the other hand took a lot long as this idea was quite rare and there was little information on how to do it, I had only seen one game using unity, called Time donkeys and they weren’t doing it as an in game rewind rather a replay system. After 2-3 days of research and coding I came up with a solution that worked, only problem was when time to test I discovered that it did not work as intended against a moving platform. The issue arose due to the rewind not being able to indentify the existing trigger and script that allowed the character to attach and follow a moving platform, so instead you would warp to whatever collider was below. What was most pressing about this bug was that our starting platforms in the game were those that moved, and due due to time constraints I wasnt able to come up with a feasible and stable solution to fix and present. I literally got the rewind functionality working 2 hours before presentation and even then it was in a rough basic form. So we decided not to show this feature and continue with only showing the other things we had added. As for the art we did see some new additions, for example a new model for the character which was created and textured. We managed to get it to perform basic ragdolling, only problem was the ragdoll was applied to another model so it just looked weird when you died and the main character would then swap from the current to an army dude while also going all limp, still got a cheer from the crowd so happy with the result.

prototype-week4

Prototype Week3 – Bug Extermination

This week was back to normal in terms of time allowed, we were back to 3 days instead of 2. Last week being interupted and shorter due to a public holiday. Another change was made to the team, another new artist was added and we were now 5 artist strong. This week extra day allowed us to experiment more with mechanics, but what was alleviating us going into this week was a concrete game idea. A few arose, but in the end we were undecided upon two game running of the bulls, my top pick and a rocket jumping game similar to quake in mechanics but with puzzle elements. I prepared a mini prototype going into the week but it wasnt enough as the team decided upon the rocket game that later evolved into a bug extermination game 3rd person puzzler. Similar to tombraider but with bugs as enemies and the main character wielding a rocket laucher instead of dual pistols.

prototype-week3 prototype-week3-1 prototype-week3-2

Prototype Week2 – Hurricane Derby

Due to a shorter week, we knew we had to choose a game from our list that was both fun and achieveable. The game with simplest mechanics was deemed Hurricane Derby and it was the game we set forth to make. A small change this week as well to the team. A new member joined from another team, as this was within the rules of prototype week we decided to give the new guy, who happened to be an artist, a try. His skills in creating realistic greybox assets in short time really helped see this particular prototype come to fruition very easily. Mainly because one of the other artist was beginning to show his reputation of slacking off.
The idea was simple, you are a tornado and it’s your job to destroy as many objects in the game as you can in the fastest possible time you can. Points are awarded for destroying multiple objects chained together. Health is restored by finding the golden cow. The game ends when nothing else remains in the level to destroy or when the timer runs out. What we realised after naming it Hurricane derby was there was little hurricane and more tornado, however, since we didnt want to redo our branding that had been created by the concept artist, the name stuck so we kept it.

prototype-week2-1 prototype-week2-2

 

Prototype Week1 – Text N Drive

Game engine month

Not only is it Movember, it also seems to be the month when the major vendors for game development are publishing revisions and updates to their game engine.

  • Epic, makers of Unreal engine released their November SDK
  • Crytek, makers of the Crytek engine have released their version 3.4.3 SDK
  • and finally Unity, makers of the Unity 3D game engine have released Unity 4.0