Chat!

Quick quick update -

Checking over my Google App Engine account, I notice: 'Whoa, somebody has been playing with the very very very very early alpha build of a chat program I not-so-cleverly hid at the bottom of my blog'

So kudos to whoever found that!

And here is a brief rundown of what it is:

Multiuser chat, Unity presentation layer, Google App Engine backend.
Net result: A completely free-to-host chatroom, running on Blogger, Unity files hosted by Google Sites, backend hosted by Google Apps.

Sweetness itself, correct??

Follow this blog if you want to know more!

Airborne - A browser-based, multiplayer plane combat game in Unity3d... probably now called Gyro

Hi everybody. All prospective 5 readers per-day. Hi! Have done so little development recently that it is with some form of shame that I post a pure-text blog: no videos, no code samples, merely a prosaic overview of what I'm currently developing. Questions welcome.

Working on a few Unity development tasks recently. The largest is Airborne - the plane combat game featured in weak weak alpha in the video currently above (as at April 2010).

I haven't done a huge deal to it, but let's break it down:

Multiplayer!

Yes sir. The multiplayer aspect was theoretical and barely-tested previously, but the game is now multiplayer (peer to peer) and working quite well.

No huge technical details to recount regarding this - most of the challenges were logic-specific.

So I'm currently doing two things in preparation for a small beta release of the game:

1) Graphics. It probably needs some. I'm currently using unity primitive cubes, painted red, as a basic test plane, but I assume that this won't cut in for graphics. So we'll see how we go there. I can't see huge difficulties - planes being largely static, no animation required. I will enlist the assistance of http://warduckdesign.blogspot.com to paint the textures, and we will be OK.

2) Re-developing the code base and logic. This is a pure engineer compulsion. The game started as a very late night 'Beautiful Katamari'-inspired effort, and as such was done in a very agile manner. I've since refined certain aspects, but it is put together in a way that doesn't lend itself to longterm maintenance, in my mind.


So yes - graphics and refinement, and we will be good for a beta release.

On a pure gameplay note - doing some basic testing of the plane multiplayer, I'm struck by a very dire gameplay function requirement: radar and altimeter. Most of the time was spent flying around looking for the enemy. Not exactly twitch gameplay.

So the plan is to create a few different radar mechanisms, and we will be good.

Back soon with videos and such.

Mesh Combine at Runtime - Unity.

Sooooooo busy. And also - I got a promotion! Figure THAT out. 

So I've been trying to create a ... "thing" .... in Unity, to combine meshes at runtime, so I can make a large, realtime-updating world in which to do "stuff".

So say, for example, our procedurally-generated map is 20x20 tiles, and each tile is a type of environment.

That is 20x20 draw calls, 400. Tooooo many, given we'd be looking at an upper-bound of 500 draw calls.

So we'd want to combine those similar meshes into single meshes, get the calls down to say, 5, instead of 400.

Now, I started out doing exactly that, using the CombineChildren.cs script that comes with Unity.

And it worked. Just fine. Performance overhead? Yeah, but it worked.

However, it worked for only 3 minutes, before crashing out.

The cause? Huge memory leak.

I tried Destroy() on the meshes, the gameobjects, the meshfilters, but no - it stays in memory.

Now, long story short:

1) Here's a link to the forum post and the... case history: http://forum.unity3d.com/viewtopic.php?t=46369

This includes the final script that works, and an actual rundown of how the thing works.

But this, being a blog, i'll SHOW you how it works:

Ok, so above:

That's the world. It's many tiles as you can see. 5 different type of tile, 20x20, potential 400 drawcalls, down to only 5.

Framerate: That's the framerate during a combine frame, normal framerate: 2000+.

Projectview: They are my "Tile" prefabs and their respective Materials.
Hierarchy: Combined GameObject contains 5 dynamically created parent objects, under each of which the tiles are parented. These are the parent objects that the MeshCombine (see the forum link for the code) will be called on.

This is the object containing my Tile types. As you can see, each object contains every possible Tile type, with all types that currently aren't in use, deactivated. There's probably a memory overhead on it, a little one, but i took performance over memory.

At runtime, this will activate/deactive the relevant tile types (man, i think i found a bug in the above screenshot), and thus make the tilemap shift and change.

Hope this is useful to you all!

And... here's the code:

using System;
using System.Collections;
using UnityEngine;

public class MeshCombine
{
    public void combineMeshes(GameObject parent)
    {
        MeshFilter targetFilter = null;

        targetFilter = parent.GetComponent();

        if (targetFilter == null)
        {
            targetFilter = parent.AddComponent();
        }

        MeshRenderer targetRenderer = null;

        targetRenderer = parent.GetComponent();

        if (targetRenderer == null)
        {
            targetRenderer = parent.AddComponent();
        }

        MeshFilter[] meshFilters = parent.GetComponentsInChildren();
        CombineInstance[] combine = new CombineInstance[meshFilters.Length];
        int index = 0;

        int matIndex = -1;

        for (int i = 0; i < meshFilters.Length; i++)
        {
            if (meshFilters[i].sharedMesh == null) continue;
            if (meshFilters[i].renderer.enabled == false)
            {
                continue;
            }
            else if (matIndex == -1)
            {
                matIndex = i;
            }
            if (meshFilters[i].Equals(targetFilter)) continue;

           
            combine[index].mesh = meshFilters[i].sharedMesh;

            combine[index++].transform = meshFilters[i].transform.localToWorldMatrix;
            meshFilters[i].renderer.enabled = false;
        }

        targetFilter.mesh.CombineMeshes(combine);

        targetFilter.renderer.material = meshFilters[matIndex].renderer.material;

    }
}

...and that is exactly what I will do. Unity Game Logic Visualisation Tool.

Kinda.

As briefly mentioned in the last post, I would ideally like to create an extension for the Unity Editor to visualise State Management in a friendly, easy-to-manage fashion.

I am currently working on a large-scale project in a rent-paying fashion, utilizing State management and synchronization between many clients and a master server (using the model outlined in the previous post) but the large number of active states, and the manner in which they are natively displayed in Unity, makes maintenance and development extremely difficult and time-consuming.

The design model itself is good, I believe. It's abstract and modular, but management of the game logic is tricky.

To test this theory, I wrote the Plane game (I'm calling it Gyro now, previously Airborne) in a purely 'dev-styled' manner. All code, no States. But it quickly became obvious that things that are achievable utilizing states are much trickier in a straight-forward class-and-code fashion; especially given Unity's event-driven model.

And thus we are back where we started, with an issue: management of many many States, Actions and Entities.

And so I present a very small, very primitive initial overview of my State Management Extension for Unity.

In eight easy screenshots....

(Easy maybe. Copy - mspaint - paste - copy to: file - open that file - save as - jpeg - repeat. Damn man.)

State Management - in the Window menu.

 

The Spartan State Management Window - Note the currently-empty Hierarchy.

 

 A project has been created, and the State Management window will now default to inspect it.

Note that the project has appeared as the parent node in the hierarchy, and it currently has No Entities.

Creating another Entity. Note that the Entity Plane has been created already.

GUIDs are generated to uniquely identify components from the server, and the client if required.

Adding a Function to Entity Plane.

Functions are basically a container for States and Actions in the Hierarchy, to keep them logically ordered and observable.

 

Inside the Plane Entity, with Function Engine added. Note that No States or Actions have been added. 

 

 Adding a State to the Engine Function. Note the types of State available (enumerated and expandable) and the value field, which changes according to State type.

 

Plane, Engine - Speed State has now been added, all existant in the Hierarchy for use in game logic.

So that's what I've been working on. We'll see how it goes. There's always a point of hesitation in working on any form of workflow-improving mechanism:

Is the cost of improvement less than the savings that the improvement will bring?

Or is the improvement redundant?

And a minor update on Gyro, prev: Airborne - I've put together a little app that I will publish once it's pretty (e.g: has a skybox and trees) so that the public can tweak and test my plane control scheme in a manner that you like. It will upload the scheme to my online database (ooooh, there's a story to tell there) and we'll be good to go.

Out.

State Management - Unity game logic approach

A quick update people, to give you a graphical example of how I handle State Management within Unity.

I've tried a lot of different ways - I've tried "just getting it done" via ... coding context-specific logic; but for every method, I've found that re-writing and logic debugging and such become unmaintainable.

This method, which is extremely modular, separates most of the game logic out into a single inherited class (Action) and all logical connections are formed graphically - in Unity.

Hmm... I wonder if you can read that.

Just a diagram I threw together really quickly, to give a very fast overview:

An Event is a situation that sets a State to a value. (e.g: Jumping = False)
A State is a variable that can hold information (True/False, a number, a sentence, a word)
A State will check its own value and - if it meets certain criteria, will trigger an Action
An Action is where all of the game logic is stored; It will do things that actually affect the game world (e.g: Character move, character animate).

Edit:

To further give an idea of the lifecycle of States:

An Event is triggered by, say... user Input.
An Event changes a State to a value.
A State, if it is a certain value, will trigger Actions.
Actions, upon completion, trigger Events.

And around we go.

Take a look!

My ideal scenario is to have enough time to integrate this system into a modified Unity Editor window - it would be beautiful.

Airborne - Gameplay - a multiplayer air combat game in Unity.

A breakdown of the prospective gameplay roadmap of this plane combat game.

Overview:


As the player, you control a plane.
The plane can be one of many types - each with different weapon layouts, and controls.

Controls that will change are:

• Roll speed
• Pitch speed
• Bank speed
• Thrust speed
• Dive speed

The Weapon Layout is made up of three parts:

• Primary gun (e.g: machine gun)
• Projectile weapon (e.g: bomb)
• Tactical item (e.g: smoke cloud, boost)

The Weapon Layout elements that will vary between planes are:

• Primary gun
• Rate of fire
• Power of each hit
• Scatter range
• Projectile weapon
• Rate of fire
• Radius of effect
• Power of effect
• Axis of operation (e.g: drop straight down, fly straight forward) 
• Tactical item
• Custom behavior 

This should lead to enough variety between planes to make selection a tantalizing and game-making choice.

See the earlier game overview post with video for an outline of rate-of-fire and scatter range.

Objective:

Single player:

• Destroy all targets on the ground in the fastest possible time.
• Dogfighting - potentially, we shall see the AI complexities of this. 

Multiplayer:

• 1-to-1 dogfighting.
• Many-to-many dogfighting.
• Team match (e.g: 5 vs 5)
• All of the above should be functionally identical, no custom code required.
• Protect and attack
• One team / player must destroy as many ground targets as possible, while the other attempts to stop them.
• Potentially: defender may use ground-based anti-aircraft guns.
• Stunt run
• I would love to implement a stunt run, awarding points for things like... flying close to the ground, buzzing buildings, diving, etc.

That's more or less the vision at present. It will clearly be implemented in a priority order (e.g: single player before multiplayer)

Let's see how it goes.

Questions, comments?

Airborne - Notes on a Plane control system in Unity.

Notice my not-so-subtle use of context-specific keywords in my blog post headings?
Take THAT Google.

So as the videos allude to - I'm working fairly heavily on an air combat game.
Absolute no idea why, I just sort of - woke up and decided I wanted to do that.

For your interest - I originally attempted a physically-accurate representation of Plane control - using forces (Drag, Thrust, Lift, Gravity etc); but - along with being a tweaking nightmare, it felt unwieldy.

What I really want, is to make a responsive, tactile twitch-action game - in planes.

From a control perspective, think Crimson Skies - like a first-person shooter in the air.

So I've reverted a more simplified control model:

• Your plane with always move forward at a minimum speed (i.e it doesn't just drop out of the sky like a stone).
• Your plane can bank, roll and pitch up and down, as normal.
• Your plane will gradually right itself if your roll is close to flat (to avoid that annoying tweaking to achieve horizontal required otherwise).
• Your plane will gain speed if diving, and this speed will gradually decay when you pull out of the dive.

 I'm using a CharacterController here, and not a rigidbody. Whether this is a good call, I cannot speculate - but I made a choice to keep all Unity physics objects (CharacterController aside) out of the game - so as to not confuse the situation.

Good choice? Perhaps - it's a choice made in ignorance.
I'm not 100% familiar with the physics system of Unity.

Although I'm fairly glad to say that the intensive use of Unity over the last.... six months or so has definitely given me a very thorough working knowledge of the Unity engine - please, ask away if you have questions.

Airborne - A Plane Combat game in Unity

Busy, Busy - said that guy from Cats Cradle, and it's true - and succinct, if not fairly trivial.





Feverishly working on a Plane combat game in Unity, for no reason apart from one evening thinking "I wonder how hard it is to make a plane control system that feels nice?"

The answer - fairly hard, fairly hard.

So please, by all means, take a look at the video. It's a small snapshot of the progress thus far (one week of evening programming).

Here's a short rundown of things to observe, and their respective explanations:

1. Custom Spring camera - I found this gave a more tactile flight feeling, and a more explicit feeling of movement in the plane. The camera will constantly attempt to align itself with an "ideal" position (a gameobject bound to the back of the plane), at a defined easing rate, to loosen or tighten the spring.
2. Controls - no real originality here. I originally attempted to use physics (gravity, drag etc) but opted for a more action-y feel (think Crimson Skies). Controls are as follows:
1. Roll
1. Roll will gradually correct to horizontal if it is between both sides of 70 degrees. (70 and 290 degrees)
2. Pitch up/down
1. If the plane is angled downward at less than 35 degrees, it will gain momentum, leading to a decaying speedboost after correction of the game.
3. Turn left/right
4. Thrust
1. The plane will continually move at a defined minimum speed, but may be accelerated (at an acceleration rate) to a maximum thrust.
5. Fire
1. See below.
3. Firing System - this will trigger, at a specified rate (defined by rest intervals between viable shots) - a raycast from a defined 'gun' location. This gun will be arbitrarily rotated within small defined bounds (currently 2 degrees) to give a nice scattered pattern of shots.
4. Hit response system - when an object is struck by a Fire ray, it will:
1. Take the type of the shot (e.g: Machine gun shot)
2. Look through its defined responses to this type of shot
3. Respond.
1. E.g: Spawn fire particle.
5. Procedural Scenery - tricky tricky tricky. The entire scene is encapsulated in a large array, with integers defining the contents of that location on the map. E.g: 1 = house, 0 = nothing
1. The game will take the planes coordinates, convert them to 'map coordinates', search around those coordinates for scenery that should be drawn, instantiate them, and destroy all objects that should not be displayed. Tricky!
6. Seamless world - You can fly around the world seamlessly. This is really all I wanted. Here's how it's achieved:
1. There are 9 terrains in the game, each representing one node in a 3x3 grid.
2. The plane is kept always in the centre of this grid, and terrains are shuffled accordingly, to assure that they roll smoothly.

Check it out, enjoy, it's looking OK.

Currently working on Networking this badboy up for some multiplayer air combat. Get excited. More to come.

Unity - Water Tidal Effect

A ninja-update here with a tantalising bit of code you may or may not be interested in.

The water / tidal effect script from the previous post.

It could actually be used for anything requiring an up/down motion (....no comment) - e.g, moving platforms or such.

Enjoy, and use it in the spirit in which it was created:

using UnityEngine;
using System.Collections;

public class TidalEffect : MonoBehaviour {

    void Start () {
        initial_y = gameObject.transform.position.y;
    }

    public float upperBound;
    public float speed;

    private float initial_y;

    float current = 0.0f;
    int direction = 1;

    void Update () {

        current = Time.deltaTime * speed * direction;
        Vector3 move = gameObject.transform.position;

        move.y += current;

        if (move.y > initial_y + upperBound)
        {
            direction *= -1;
            move.y = initial_y + upperBound;
        }

        if (move.y < initial_y - upperBound)
        {
            direction *= -1;
            move.y = initial_y - upperBound;
        }
        gameObject.transform.position = move;
    }
}

Simple Living Unity Scene - Breakdown

Paying the rent precludes me from giving you the full attention that you so clearly deserve - accept this breakdown instead.



A simple Unity scene, with a few simple scripts and elements added to give it a more dynamic, interesting feel.

Here's a breakdown of what's in there:

Water.

The water is made up of a large plane with a Transparency > Diffuse shader, and the standard Water texture applied. Alpha is at around 70%.

To achieve the depth / shallow appearance of the water, I used a crazy simple technique:
Painted underneath the 'deep' sections with black, and underneath the 'shallow' sections with sand.

Easy, and achieves a relatively nice look.

To achieve the ebb and flow effect, I created a basic script that will raise and lower the water plane within bounds, given a provided (very slow) speed.

Light Cycle

Very simple light cycle - achieved by applying a simple rotation on Update() to a Directional light.

Living Skybox

Another very simple effect - achieved by applying a texture to a giant cylinder, and rotating it on Update().
Also, the cylinder will align it's x and z coordinates with those of the player, so they maintain a specified distance at all times (best to correlate the clip distance to this).

Ripple effect

Probably the most complex effect - but still very basic - the ripple effect is the following:

A simple plane with a transparent background and a white circle painted onto it.

It will start at a scale of 0%.

On Update(), it will roll a random number - and if it is within specified bounds, it will initiate a 'ripple'.

This will effectively scale the plane at a specified rate, until it reaches a certain size, at which stage it will disappear.

The ripple will also lower its alpha as a proportion of it's progress to maximum size.

Too easy!

So what do you think? Relatively 'pretty' for two hours of coding and playing around and such.








Want the code or the prefabs?

Subscribe or comment! Or subscribe to my Youtube channel. Perfect.