New Youtube channel is up!

Hello fellow Unity adventurers!

To correspond to my new blog / website - our new Youtube channel is now online and featuring a pretty funky overview of my current Unity development.

To save you a click, here it is!



You'll notice that We prefer 'Privateer' is the continuation of my earlier Airborne/Gyro project.

So please, take a look, comment as you see fit - and if you'd like a rundown on how we achieved certain things, feel free to ask! I'll blog it up for you toot-sweet.

To give you a small rundown:

1) Kill Zombies 2) Buy Bread - is an action game built on a dynamically-generated map of buildings, roads and crossroads. Zombies are spawned at incrementally shorter intervals, and scale in difficulty as days progress. Fog gets thicker as time goes on.

Don't Tread on Me is built on the same map system, but includes a path generator (using the A* algorithm) in order to allow the robots to navigate from start to finish.

We Prefer 'Privateer' is built on the scrolling world system that I discussed earlier (allowing you to fly forever and never leave the map). The control system also handles quite nicely.

Eskimo Shuffle is built on the same scrolling world system, and includes an 'active cameraman' feature that selects camera angles according to your actions, to give it a little filmic quality.

Can YOU Dig it - probably our most ambitious project - generates a full three dimensional cave system according to your actions, including caveins and the ability to climbs walls.

All of these are built and run nicely on the iPhone / iPad.

Interested? Excited?? I hope so!

I look forward to your feedback and questions.

Direct them to our new blog if convenient, I'll see them sooner.

Or reach us on twitter if you feel like it.

The Other White Meat

Hello party people!

For those of you seeking Unity game information, updates, design/coding advice etc, may I kindly direct you to my new, shiny, corporatesque blog?

I'm always keen to discuss or assist with game development and design, so please - drop us a line on our Twitter, Blog or so forth - and I'll write a blog juuuust for you.

To re-iterate: If you have development questions -

How do I do x in Unity?
I have a problem! Unity is telling me x!
Etc

Then by all means, send it to me. I'll answer that badboy publicly.

Neat huh?

Huh?

Uh-huh.

And to seal that deal quite nicely, here's a little montage from one of our current developments.

I'll see YOU there!

Doppler Interactive, de'Zoo - and all things commercial

And a massive 'Hello' to you, my fine feathered friends. After an absence that - we can all admit, was obviously coming, I am back for a BAM BAM comeback fight, like George Foreman. Or the new Rocky. Which I haven't seen.

Party people - it is with some deal of pride that I announce to you the launch of our website!

Doppler Interactive

www.dopplerinteractive.com

  

Yes, I have partnered with one extremely funky designer to launch a multimedia apocalypse.

Our first series is called de'Zoo -  a collection of cute, pop-inspired, vaguely-unsettling animal characters.  

You know those machine where you put a coin in, and use a claw to take a toy? And the claw fails? And you get angry and kick the machine, and security beats you up??
You know those toys?
Yeah, we love them too.
I once won a giant fish, and all these fairly hot girls were giving me the eye like "You could win me in a claw machine any day baby"



This is the fish:

First time, everytime. Fishtime.

We're talking web comics, we're talking videos, we're talking Flash games, we're talking 3D games, we're talking Mobile apps (note: I just got the new Samsung Galaxy with Android. It's beautiful!) we're talking all of these things.

So our website is up! There's an overview on our blog of how we put it together - as a long-term fan of the Google range of products we heavily abused their kindness.

We have combined Google Sites, Google App Engine and Blogger into a beautiful, organic dance of love and sensual caressing.

So stay tuned! I've released Part 1 of X in the "How to make a Free (ish) Website for your Business" and I will continue adding to this over the next weeks.

Thanks for your readership! Stay posted, I will continue to update this blog with Unity code and hints as soon as I have moved back into the 3D development space.

Kicking it live EVERY time
JF

Contact Details

The MojiKan - Virtual Social Game World: Rent-paying passtime that put me in proximity of Unity.

Gooooood evening/afternoon and morning everybody in b-b-b-b-b-blogspot land.

This is a work-related, barely work-endorsed, but definitely work-funded blog entry to give a brief albeit tantalizing summary of my cash-money paid work on an upcoming Virtual World called The MojiKan. Or... just MojiKan. One or the other.

I designed it, and yet I don't know.

Moji: Emote
Kan: Place


I am Project Team Leader on this business - formerly Lead Engineer.
We're in the midst of a mad rush to Beta, tagging Alpha along the way.

And here's an executive summary!

The MojiKan is a:

Virtual - Intangible
Social - Multiplayer and Socially-motivated
Game - Entertaining, with a distinct purpose, and action adventure and romance!
World - Vast... space.

But as the man who designed the premise (to requirements, mind you - not from thin air. The requirements were: Make me a Virtual Social Game World, and I comply) - here is my rundown for you:

The MojiKan is a virtual world in which you compete and cooperate with players from around the world - in a bid to become rich, successful and powerful - much like the real world.
Buy land, Buy businesses, Run for Government, Create an organization... and so forth.

And on the other side, the MojiKan is populated by tiny pets - Moji and Obaki. They are your tamagotchi-styled companions who offer the more action-oriented gameplay. Run, jump, fly and smash with wood and stone. All of that business. In a lush, full 3D, browser-based... browser-based MMO.

In Unity!

And to cap it all off?

You talk to your pets, and they ... fully... talk... back. With words. Legible, sensible, hilarious words. All thanks to a fairly sophisticated natural language processing backend.

So that's that. My rent-paying occupation.

I manage that glorious mess.

In the interim, the promotional side of the team has developed a small desktop widget to give people a taste for the pets and the language. It's not done in Unity, so my apologies.

And, on the other side - my beautiful design team, under my near-Fascist leadership, has put together a quite nice teaser trailer to outline the story of the MojiKan.

So, feel free to check it out, and anticipate an incremental release over the coming year - first snippet - September!

The Youtube video is here: MojiKan Teaser Trailer

Register for release news and such at the website here: MojiKan Website

And hell, why not join in on Facebook? You know ALL the honeys be trippin' for the MojiKan.

The Facebook Page: MojiKan Facebook Group

Actually, you seriously should. Because yours truly - your completely 100% reliable narrator - will be blogging on that badboy! And... also... making a fake account with an unsettling username and posting falsified bug reports!

Example:

Pet died during the day.
Woke up and Pet was sitting on the end of my bed.
It opened its mouth but no words came out.

Its mouth grew wider and wider, until everything went black.
When I woke up, I was very cold.
Is this a bug?

Can YOU resist????

As a little bit of an extended monologue - I've also been playing around with SEO a bit.

And guess what? I'm competing with our Community Manager in getting a highly-ranked website for the word 'Mojikan'.

What word was that?

MojiKan!

What was that again?

MojiKan... 

World State - Servlets for Servers, P2P, iPhone efficiency and You.

Hello people,

Prepare yourselves for an update of monolithic proportions....

Although I thiiink a monolith (mono) is singular, correct?

And I intend to put up multiple updates...

So that's not really correct, right?

Oh no, it's correct like this: We consider the entire update process as a single Unit, and that Unit is a monolith, composed of smaller parts. Easy.

Here's a little bit of what you can expect:

• A* Pathfinding in Unity. 3D, of course.
• Using pre-determined (automatically generated) walk maps, and pathing over coordinates.
• P2P networking. 
• Uh-huh!
• Servlets.
• Google App Engine for gamestate? Can it be done?!?! You know it can, brother!
• iPhone.
• That's right! I'm allll about the iPhone. Got my (our) first alpha build up two nights ago. Greatly impressed.
• Maybe some other things too. I just can't remember them all!

Take it easy, everybody. Feel free to follow this blog, to join the Youtube channel, or whatever you like. I'm always keen to assist, time permitting, in your Unity or wider development adventures. I have many many scripts to share if they're needed. I'm just that kinda guy!

(Kinda)

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.