Videos

TOY BOXING in Unity

Check out this new concept I’ve been exploring in Unity that I like to call “Toy Boxing”.

Transcript

Lately, I’ve seen a lot of hype over scriptable objects.

And rightly so – scriptable objects allow you to write data-driven components that are both modular and highly re-usable.

They promote an approach to game code architecture that reminds me a lot of solid principles.

In case you aren’t familiar, the solid principles are five design principles that lead to, among other things, a more modular code base.

This is an important concept in the corporate world because most business applications require clear divisions between different modules that need to work together and yet still remain separate.

As game developers, we can model our own design process after this concept by creating components that can be dropped into any scene and function with complete autonomy.

Here’s a quick example, to help illustrate my point.

Let’s Imagine we’re starting a new project from scratch.

We’ll create, oh I don’t know, a first-person puzzle game like the witness.

We need to start prototyping the  key game mechanics as quickly as possible in order to test the viability of our game idea.

Add GameObject’s and PlayerController to the scene

So let’s slap together a really simple level using some placeholder prefabs and the player controller found in Unity’s standard assets.

Press play in the editor and walk around

Alright this is a great start, but I just want to tweak one or two things.

For instance, when I jump I feel like I’m playing a first-person shooter.

I think our puzzle game is going to be a little more slower paced.

So let’s kick up the gravity modifier a little bit.

Okay Much better.

Next, I’m starting to feel like the mouse movement is a little too sensitive.

Again, this is really feeling like an FPS, but I’m going for a slower paced, story driven experience.

So let’s make some adjustments to mouse look sensitivity.

 

Alright this feels a little better.

To be honest, I’ll probably end up tweaking it more as I start adding puzzles and game mechanics, but that’s not a big deal because all I have to do is make some adjustments to the values in the inspector.

And that’s the beauty of it, right?

Someone over at Unity did all of the upfront legwork work in the code so that future developers, like myself, could take advantage of an extremely easy-to-use and insanely flexible component that works right of the box.

Ryan Hipple of Schell Games gave a great presentation at Unite Austin 2017 called Game Architecture with Scriptable Objects.

In his talk he mentions his three pillars of game design – modularity, editability, and debuggability.

Modularity is achieved through writing components that are autonomous.

For example, the player controller that we just looked at works just fine on its own, but it’s flexible enough to interact with other components, as well.

Editability is achieved through writing components that are data-driven.

Again looking at the player controller, it’s behaviour is controlled via data that can be manipulated via the editor.

And lastly, debuggability is achieved through writing components that can be tested in isolation.

If the player controller is acting funny, we can easily just drop it into an empty scene and figure out what’s going wrong without any other components muddying up our testing.

Now don’t get me wrong, I’m not saying that any of this is new or revolutionary.

I’ve written plenty of components that meet these three pillars without even thinking about it.

But, because I wasn’t thinking about it, it took a lot longer to get there than it would have had I been more deliberate.

That’s why nowadays, as much as makes sense, I try to purposefully design my MonoBehaviours to be autonomous, data-driven components that I can just drag and drop into my scenes.

And It’s become such a topic of discussion on our public Discord server that the concept has even been given its own name.

We call it “toy boxing”.

I can’t take credit for the name, though.

That honor goes to Jason Storey, who you may know as “apieceoffruit” on Discord.

Jason is actually working on a collection of modular components, or toys, that he’s planning to release as an asset.

What you’re seeing here is a small subset of that collection working together to make some pretty impressive looking examples.

Each GameObject is it’s own component that’s responsible for a single task.

Luckily for us, Jason was gracious enough to grant me access to an alpha version of his asset.

So we’re going to use it to flesh out our first-person puzzle game.

Here’s the same scene I showed earlier but with a more sophisticated level design that I slapped together with ProBuilder.

Walking around the scene we can see that I’ve left a few places open for puzzle mechanics.

This opening right here seems like the perfect place for some sort of a door.

So let’s start with that.

I’m just going to create a GameObject called “Room 1” so we can keep our hierarchy organized.

And now let’s see what sort of toys we’ve got to play with.

Well look at that, there’s a “Doors” folder with a couple of prefabs already made for us.

Door Double Slide sounds promising, so I’ll just drop it in my scene and see what we’ve got to work with.

Not bad, it even fits perfectly within this gap.

Hmm… it’s almost like I planned this and I’m reading a script or something….

Whoa, too meta.

Let’s see what kind of options it has.

Looks like we can control the state and add handlers to a few events.

We can even control the open and close speed.

I’m going to position the main camera in front of the door so we can see what this looks like in action.

Check it out, in play mode we get access to open and close buttons that allow us to test out our door.

Press Open and Close

This is something that Jason likes to call “batteries included”.

The idea is that each of these toys should be able to work without any prior configuration.

To finish up Room 1, we’re going to need to add some sort of mechanism to trigger this door.

Let’s return to the features folder.

Well would you look at that, there’s a Interaction feature that also has its own prefabs folder.

Invisible Trigger looks like just the toy we need.

Now let’s take a look at what options it has.

Just like our sliding door, it has configurable event handlers.

Let’s cause the door to open on trigger enter and close on trigger exit.

Now a quick test…

Wow, could that have been any easier?

And the rest of the scene was just as easy to prototype.

Luckily for you, you can get access to the finished scene, as well as code example from my other videos, for just $5 on Patreon!

Plus you’ll be supporting the creation of content just like this.

Welp, hopefully I’ve made it easy to see just how powerful it is to write your MonoBehaviours as autonomous, data-driven toys that, when working together, are worth more that the sum of their parts.

If you enjoyed this video, please leave a like and a comment letting me know what you thought.

And for more Unity tutorials just like this one, please subscribe with notifications on.

 

Lately, I’ve seen a lot of hype over scriptable objects.

And rightly so – scriptable objects allow you to write data-driven components that are both modular and highly re-usable.

They promote an approach to game code architecture that reminds me a lot of solid principles.

In case you aren’t familiar, the solid principles are five design principles that lead to, among other things, a more modular code base.

This is an important concept in the corporate world because most business applications require clear divisions between different modules that need to work together and yet still remain separate.

As game developers, we can model our own design process after this concept by creating components that can be dropped into any scene and function with complete autonomy.

Here’s a quick example, to help illustrate my point.

 

Now don’t get me wrong, I’m not saying that any of this is new or revolutionary.

I’ve written plenty of components that meet these three pillars without even thinking about it.

But, because I wasn’t thinking about it, it took a lot longer to get there than it would have had I been more deliberate.

That’s why nowadays, as much as makes sense, I try to purposefully design my MonoBehaviours to be autonomous, data-driven components that I can just drag and drop into my scenes.

And It’s become such a topic of discussion on our public Discord server that the concept has even been given its own name.

We call it “toy boxing”.

I can’t take credit for the name, though.

That honor goes to Jason Storey, who you may know as “apieceoffruit” on Discord.

Welp, hopefully I’ve made it easy to see just how powerful it is to write your MonoBehaviours as autonomous, data-driven toys that, when working together, are worth more that the sum of their parts.

If you enjoyed this video, please leave a like and a comment letting me know what you thought.

And for more Unity tutorials just like this one, please subscribe with notifications on.