Go to /Applications/Unity and Show Package Contents on the Unity.app. Navigate to Contents/Resources/ScriptTemplates. Here, you’ll find all the template Unity uses. Edit as you wish!

Note: I’m pretty certain these files will be overwritten the next time you update Unity.

Instead, we opted for a more Unity’ish approach (where you use GameObjects to add behaviour to the scene. And these GameObjects are placed in the scene. A bit like working with ActionsScript 1 and 2 -if anyone still remembers, where you put some AS-code in a MovieClip and put that in the scene). We created behaviour entities that we placed in the levels. These were never rendered, but provided an update loop that kept the level running, and the main file clean.

There are some benefits of using an approach like this:

• game.loadLevel() will kill all your entities when you switch levels. That way you don’t have to create any dealloc functions to clean up any mess.
• It’s easy to see when editing the level which behaviour this level has. And it’s equally easy to change the level’s behaviour.
• The code is separated from the main class and easily maintainable.

So, how do you setup a system like this? Let me show you.

We need two base classes that all behaviour and entity classes extend from.

BaseBehaviour

ig.module(
    'game.base.base-behaviour'
)
.requires(
    'impact.entity'
)
.defines(function(){
    ig.EntityBaseBehaviour = ig.Entity.extend({
        _wmScalable: false,
        _wmDrawBox: true,
        _wmBoxColor: 'rgba(196, 255, 0, 0.7)',

        size: {x:64, y:64},

        game: null,
        game_data: null,

        _ready: function(args) {
            if (args !== undefined) {
                if (args.game) this.game = args.game;
            }
            if (this.game.director.data !== null) {
                this.game_data = ig.copy(this.game.director.data);
                this.game.director.data = null;
            }
            this.ready();
        }
    });
});

BaseEntity

ig.module(
    'game.base.base-entity'
)
.requires(
    'impact.entity'
)
.defines(function(){
    ig.EntityBaseEntity = ig.Entity.extend({

        behaviour: null,
        game: null,

        _ready: function(args) {
            if (args !== undefined) {
                if (args.behaviour) this.behaviour = args.behaviour;
                if (args.game) this.game = args.game;
            }
            this.ready();
        }
    });
});

Main

loadLevel: function( data ) {
    this.screen = {x: 0, y: 0};
    this.entities = [];
    this.namedEntities = {};
    for( var i = 0; i < data.entities.length; i++ ) {
        var ent = data.entities[i],
        this.spawnEntity( ent.type, ent.x, ent.y, ent.settings );
    }
    this.sortEntities();

    // Call post-init ready function on all entities
    var behaviour = this.getEntitiesByType(ig.EntityBaseBehaviour)[0],
        entits = this.getEntitiesByType(ig.EntityBaseEntity);

    if (typeof behaviour !== 'undefined' && behaviour !== null) {
        // Pass reference to game class to behaviour
        behaviour._ready({ game: this });
    }
    else {
        console.error('Your level is missing the main behaviour');
    }

    // Pass reference to behaviour class to all entities
    for( var i = 0; i < entits.length; i++ ) {
        entits[i]._ready({
            behaviour: behaviour,
            game: this
        });
    }
}

Director

goTo: function(nick, options) {
    if (typeof options !== 'undefined')
        this.data = options;
    this.jumpTo(nick);
}

What happens here is the following:

Switching between levels is done using a Director class. With this class you can register levels with a keyword. That way you don’t have to load a level by making a direct reference to the level class. The Director plugin’s goTo function accepts two parameters: nick name for the level to load, and an optional options object for any data that you might want to pass from a level to another.

When you call director.goTo(), the Director will save any optional data in its own data property, and then trigger loadLevel (this is done in jumpTo(), where the Director checks to see if it has a level with the desired nick name).

LoadLevel will traverse all entities in the levels file and look for behaviours and entities. Once a behaviour has been found, all entities that extend from BaseEntity will get a reference to the behaviour so that they can access it via this.behaviour. Both the entities and the behaviour will get a reference to the main game class so that they don’t have to use ig.game (which doesn’t work well with Weltmeister).

Once the passing of references to the behaviour and the game class has been done, ready() is called on all entities. That’s where an entity can access the data object via this.behaviour.game_data.

Caveats

This implementation supports only one behaviour per level. I have some ideas for how to implement support for multiple behaviours per level. That would most definitely come in handy.

Create()

Most of the create function has been explained in the blog post Dynamic loading of assets, entities and levels in ImpactJS. Aside from what’s explained in that article, you could do other kinds of pre-initialization stuff here. Just make sure you end your create function with ig.main();

Destroy()

Input handlers

We made changes to impact/input.js so that the event handlers for input were not defined by anonymous functions. So instead of doing this:

ig.system.canvas.addEventListener('mousedown', this.keydown.bind(this), false );

We did this:

ig.keydownBound = this.keydown.bind(this);
ig.system.canvas.addEventListener('mousedown', ig.keydownBound, false );

That way we could later remove the event handlers by doing:

ig.system.canvas.removeEventListener('mousedown', ig.keydownBound, false );
window.removeEventListener('keydown', ig.keydownBound, false );

Game loop and other event handlers

The main game loop can be stopped by calling:

ig.system.stopRunLoop();

There are also two event handlers added for module loading that needs to be removed:

document.removeEventListener( 'DOMContentLoaded', ig._DOMReady, false );
window.removeEventListener( 'load', ig._DOMReady, false );

In order to make the next create() execute as expected, reset ig._current by doing:

ig._current = null;

Removing modules and levels

Next up, we removed all modules and levels that might be loaded the next time we run create(). We do this by traversing ig.modules, like this:

var deleteables = [];

for (var m in ig.modules) {

    var d = false;

    if (m.substr(0,11) === 'game.levels') {
        d = true;
    }

    if (m.substr(0,13) === 'game.entities') {
        var mod = m.split('.');
        if (mod.length >= 4) d = true;
    }

    if (d) deleteables.push(m);
}

for (var i=0, l=deleteables.length; i<l; i++) {
    delete ig.modules[deleteables[i]];
}

As you can see here, I delete modules that has a name which begins with game.levels. But for entities, I make sure to only remove those who belong to a subfolder since I don’t want to remove the shared entities that are used in all levels, and resides in the root entities folder.

Next step is to clean up the ig.resources array.

deleteables = [];

if (ig.resources.length > 0) {
    for (var res in ig.resources) {

        var r = ig.resources[res].path,
        d = false;

        if (typeof r !== 'undefined') {
            if (r.substr(0,13) === 'media/images/') {
                r = r.substr(13);
            }

            if (r.substr(0,6) === 'char1_' || 
                r.substr(0,6) === 'char2_' || ... ) {
                d = true;
            }

            if (d) deleteables.push(res);
        }
    }
}

for (var i=0, l=deleteables.length; i<l; i++) {
    var key = deleteables[i],
    r = ig.resources[key];

    if (!r.hasOwnProperty(key))
        return;

    if (isNaN(parseInt(key)) || !(r instanceof Array))
        delete r[key];
    else
        r.splice(key, 1);
}

This one is a bit more elaborate. I make sure to remove resources that only belongs to the game’s characters. That way I don’t delete the shared assets.

Finally I delete the levels by doing this for each level that might be loaded with the next create():

delete ig.LevelA;
ig.LevelA = null;

It took me quite a few hours to figure out this one, but it turned out to be quite simple. I just had to read and understand almost every line of code in the Impact engine to get this working. I hope this will be useful for you. Feel free to ask if anything is unclear.

Due to the way ImpactJS is structured, it’s actually quite easy to add dynamic preloading. Have you noticed the three functions module(), requires() and defines() at the top of each class? Did you know that when your files have been downloaded, all of these functions are executed?

These functions are executed so that ImpactJS gets a full list of all modules and the preloader gets a list of all assets to download. If you want to dynamically add a module, simply load it with XHR so that the browser can interpret it once it’s downloaded. When the download has completed, call ig.main() to start the preloader and the game. Simple!

Let me show you how I did it.

In main.js I have a function called ig.create(params). One of the params is called ‘character’. I load a baked js-file with all levels and entities for that character by doing this:

var char_to_load = 'characters/'+character+'.js';

var script = ig.$new('script');
script.type = 'text/javascript';
script.src = char_to_load;

script.onload = function() {};

script.onerror = function() {
    throw('Failed to load character ' + path + ' ');
};

ig.$('head')[0].appendChild(script);

This takes the character parameter, makes a full path to the baked file, creates a script tag and loads the file. You’ll se that I haven’t added any onload handler. Instead I use a timer to check for the length of ig._loadQueue.

When the file has been downloaded, the browser will interpret the file and execute any code that’s supposed to be executed. By default, ImpactJS will register the module, add any assets to ig.resources and by calling the requires() function, ImpactJS traverses all the classes you have in your baked file. So, to make sure ImpactJS has traversed all files before I call ig.main(), I set up a timer that checks the length of the loadQueue.

ig.loadReadyInterval = setInterval(ig.checkReady, 250);

ig.checkReady = function(){
    if (ig._loadQueue.length === 0) {
        clearInterval(ig.loadReadyInterval);
        ig.main( ... );
    }
}

Once the loadQueue has a length of zero, I call ig.main().

We would get the sprite sheets from Making Waves, and then it was our job to make the entities come alive. To make this process as flexible as possible, we needed a workflow that would allow the client to update the sprite sheets whenever needed. We could therefore not add any functionality to the generated entities. Otherwise, they would be overwritten during the next update. Instead, we turned the hierarchy upside-down. Generated entities would extended a parent entity that gave them a particular set of behaviours.

The PHP script got instructions for how to generate entities by reading the file names of the sprite sheets. Let’s consider the following file name:

thomas_player_character_2_4_idle.$jump.$jump.$jump.$wait.$wait.sit.crouch.png

thomas – Tells the script to save the entity in game/entities/thomas. Create the folder if it doesn’t exist.

player – Name the file player.js.

character – Load the entity definition template called character.

2_4 – Split the sprite sheet in 2 columns and 4 rows.

idle.$jump.$jump.$jump.$wait.$wait.sit.crouch – Define a set of animations, where the first animation is called ‘idle’ and uses the first index of the sprite sheet. Next add an animation called ‘jump’, consisting of sprite index 1, 2 and 3. Wait animation uses index 4 and 5, and lastly add two animations with one frame each, called sit and crouch.

The script was split up into several files where the most important ones were the template files. They had each a parser with a set of rules specific for that template, and a function that would merge the data from the file with a template file. Some templates could generate multiple entities per file. The other files would do things like calculating the size and offset of each tile in a sprite sheet.

The PHP script followed the following routine:

1. Scan media folder for valid image files.
2. Run the file name with the parser for each entity template to see if the file is supposed to be made into an entity. One can make the script ignore files by naming the file something that doesn’t match any of the patterns in the parsers.
3. When a template has been found, test it agains the class that splits the image into the desired number of rows and cols. If the image has the wrong size, abort the script.
4. Calculate each tile’s size and offset by looping over each transparent pixel from top -> bottom, right -> left, bottom -> top and left -> right until we either reach the other side of the image (all the pixels are transparent) or a pixel with a transparency level above a defined threshold.
5. If any animation has been specified in the file name, set up all the animations.
6. Merge all of this data with a template.
7. Write the file to the correct folder, overwriting any old entity.

With this routine, we generated about 50 entities in only a couple of seconds. If we were to manually create and maintain these entities we would spend hours each update, and it would be prone to errors.

In W’s config file, you’ll find a couple of lines that define which folders W will look for entities and levels in. You can change these if you’d like to edit levels that are in a different folder than the default lib/game/levels. The config looks like this:

wm.config = {
    project: {
        'entityFiles': [
            'lib/game/entities/*.js',
            'lib/game/entities/subfolder/*.js'
        ],
        'levelPath': 'lib/game/levels/subfolder/',
        ...

As you can see here, I’ve added two folders to the entityFolder settings. This makes W look for entities in both. In my case, this was exactly what I wanted, because at the root of the entities folder, I had all the common entities, and under each sub folder were all the level specific entities.

In order to make W open with the correct settings, I used a PHP script that edited the config file before routing the user to W. I’m no expert in regex, so I simply copied the default config file to a separate folder, added a couple of strings for where I wanted to insert the name of the subfolder, and then let PHP do a simple search and replace before overwriting W’s config file.

My template file looked like this:

ig.module(
    'weltmeister.config'
)
.defines(function(){ "use strict";
wm.config = {
    project: {
        'entityFiles': *[ENTITIES_DIR]*,
        'levelPath': *[LEVELS_DIR]*,

Here you can see the strings I added as placeholders.

The drop down menu was created by a PHP script that simply listed all the subfolders of the levels folder. When I clicked on one of the options in the drop down menu, the name of the subfolder was posted to a PHP script that created the new config file, and used PHP’s header() function to route the user to W.

To get back to the game, I added a play button to W’s toolbar that would route me to the index file.

I have no idea how much or little time this has saved me from either typing the full address of W or switching between browser windows and manually editing the config file, but it sure feels like a lot of time has been saved.

Caveats

When open W from the drop down menu, W will still remember the last opened level and open that. But when you save the level, it will be saved to the subfolder you clicked on the drop down menu. Very confusing! For now, you’d have to remember to load the level you want to edit once you’ve opened W.

Future features

I’d like the drop down to be able to list levels in each subfolder so that I can jump directly to a level without having to manually load it from W. I would also like the play button in W to not only take me to the game but make the game load the level I’m editing. That way you can switch between the game and the editor with two clicks.

Update April 2nd 2013:

Since committing to a git repo is a bit different than committing to svn, I have listed the steps here:

1. Create a code repo on github.com (or your own Git server).
2. Create a new project in Unity. Make sure to save it where you want to have your local copy of the code repo.
3. In Unity, go to Edit > Project Settings > Editor and enable Meta files for Version Control, and Force Text for Asset Serialization.
4. Quit Unity.
5. Delete the Library and Temp folder from the project folder.
6. And now, it’s time to make the first commit. Open terminal and follow the next 6 steps.
7. cd to/your/project/folder
8. git init
9. git add *
10. git commit -m “First commit”
11. git remote add origin git@github.com:username/project.git
12. git push -u origin master
13. Open your Unity project while holding down the Option or the left Alt key. This will force Unity to recreate the Library folder.
14. You can either contine to use git from the command line, or use a Git client like Tower or any other. In Tower, I would choose to Add Local Repository and point it to the folder where I created the Unity project. You don’t have to clone the repo because you already set up the repo when doing your first commit.
15. Make Git ignore the Library and Temp folder so that they won’t be pushed to the server. Add them to the .gitignore file and push the ignore to the server.

I still have the problem of resolving conflicts in the scene files, as they are binary. I guess I could build my games so that the scenes reads settings files and builds up the levels programmatically, but that would in many cases defeat the purpose of the Unity Editor. NOTE: There are others who have had the same thought of setting up the project with nothing in the scene files. Read the thread Version control workflow at Unity Answers for a couple of hints on how to do it.

Make sure you are signed in to Google. Search for something, click on one of the websites in the results (I don’t know if you even have to wait for the page load), hit the back button and you will see a new line under the website link you just clicked. It will say something like “Block abcdef.com from …?”. Click it and you’ll never see hits from that domain again.

Here’s how it’s used:

ChangeWatcher.watch(object, "property", handler);

Object – the object which owns the property
“property” – the property you want to watch
handler – the function name of the handler

Whenever the property of the object changes, the handler will respond. Quite handy, right?

Here’s an example for you:

Let’s say we have a class called WatchMe. Inside that class we have a public variable called ImBeingWatched. We’d like to trigger a function whenever this variable changes. To do this, we simply add one line of code:

package
{
    import mx.binding.utils.*;
    import flash.display.*;
    import flash.events.*;

    public class WatchMe extends MovieClip
    {
        [Bindable] public var ImBeingWatched:Boolean = true;

        public function WatchMe():void
        {
            ChangeWatcher.watch(this, "ImBeingWatched", doSomething);
        }

        private function doSomething(e:Event):void
        {
            // do something ...
        }
    }
}

The property that ChangeWatcher is watching must be [Bindable] and Public for it to work.

The first version of the datahandler used int’s as variable type for the values I recieved, and it would occasionally fail. After swithching to uint, things looked better.

I also had a set of 4 if-statements which I optimized by merging them into 2 if-statements.

To my surprise, this was the only thing I needed to do to make the datahandler parse the data fast enough.