...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;
    }
}