One of my first “missions” as Technical Evangelist at Unity was to present a 2-day workshop to absolute game development beginners in a town near Brighton. The attendees didn’t know Unity before, but had received some lessons in basic programming. As such, the easiest way to introduce them to Unity would be a step-by-step tutorial. But after the first day I decided that this approach wouldn’t allow them to express the creativity I saw they had right away. So on the train back I started working on a small framework that would allow them to build a variety of games, fast, and without necessarily knowing about programming.
The “Unity Playground” was born.
When I set off to create the framework, I had a few goals in mind. First, I wanted to teach people that making games can be fun. I wanted to give them the full game creation experience, but at the same time trying not to overwhelm them with the technical concerns that come with it. Most importantly, I didn’t want to constrain their creativity.
I also decided it would be cool to allow them to play with the parameters of the game, to allow some sort of game tuning and playtesting (game designers, yes!).
Another key goal was to minimise my intervention as teacher, since I quickly discovered that handling a group of 25 alone was impossible. The framework would need to prevent as many mistakes as possible, and guide the students.
So I came up with a small framework that revolves around a few cornerstones around which I make every decision:
Going into more detail, the Components are all simple scripts that perform mostly one task, so they can be mixed to produce more refined gameplay. For instance, you can use together the scripts RotateWithArrows and PushWithButton to create a character that rotates with the Left/Right keys and move forward with the Up key, such as a spaceship or a car seen from above.
Their inspectors are heavily customised with the help of Editor code and provide plenty of guidance in setting up. This component for example shows some tips at the bottom, and will hide the option Look axis if the Orient to direction boolean is unselected.
Talking about the UI, I made it a prefab that can be dropped into the scene without any setup. It will accommodate different kinds of gameplay, and will change depending if the game is for one or two players. This is its Inspector:
And this is how it looks in-game:
Additionally, it will automatically display a small inventory in the bottom-left corner for games that have objects that can be picked up. In this example, the player has 0 coins and 1 key:
After the first iteration proposed in the original workshop, I tried to give some structure to the Playground, so I came up with some key groups of scripts that try to serve specific classes of problems.
At the heart of the framework are the Conditions, which are basically if statements made components. They check for a specific condition and, if this is verified, execute some actions. The Condition scripts available for now are Area Conditions (basically triggers, enter, exit, and stay), the Collision Condition (fires on collision), and a configurable Key Condition to capture input. More may be added in the future.
In the first iteration, I grouped the actions under an UnityEvent. Despite its power though, the UnityEvent block in the Inspector is huge and complicated to setup, because it exposes ALL the public properties and methods of the target objects:
So, I decided to implement a series of mini-scripts that contain one action. Conditions now have a simplified block (made with the useful ReorderableList, check it out on Valentin’s blog!) where you can connect them easily by drag-and-drop. I grouped these scripts under the name Gameplay Actions, and they all implement the IGameplayAction interface.
Following this simplification, a ConditionKeyPress Inspector with the Gameplay Actions block looks like this:
The bool Use custom actions reveals another UnityEvent block to allow the most fearless students to get the full power of UnityEvents and access any variable or method.
Finally, some scripts are grouped under Attributes, as they effectively work as if they were mere properties of an object. For instance, adding a Resource Attribute to an gameObject makes it an object that can be picked up and stacked, shown in the UI as an icon or amount, and later on consumed by a ConsumeResource GameplayAction script.
The Scenes folder contains some example games, intended to showcase the variety of gameplay that can be achieved with the framework.
The Defender game shows how to shoot objects (the laser) or generate them randomly (the asteroids), and is also an example of a life-based game where the player’s health script is not on the character gameObject, but on a part of the environment.
The Football game is a 2-player football game that shows how to use ConditionCollision scripts to setup goals, and reset players and ball position when the players score a goal.
The Maze game shows the use of Collectables (for the coins), how to setup Area Conditions, and load another level through the LoadLevelAction.
The Lander game showcases an atypical setup for collisions, where only collisions with certain parts of the spacecraft will make it explode.
Finally, the Roguelike game shows how to create a small “crafting” system with Conditions and ConsumeResource actions. The merchant asks for three coins (which have a Resource script), and once you collect them, he will give the player a key (another Resource) which can be picked up to open the door.
I suggest to remove the example games before distributing the framework, so that users won't see them. We said this framework was made to make their imagination go wild, right?
Together with the rest of the evangelism team at Unity we have decided to release the Playground on Github. You can clone the repository, modify it in any way, and use it in your workshops.
I’m still working on the framework, trying to balance the addition of new scripts and possibilities while still keeping the whole thing accessible and understandable (for both the beginners, but also for teachers!), while keeping the documentation up to date with the changes.
Keep in mind that the project is maintained only by me, so for suggestions, doubts or (hopefully not) bugs you can ping me on Twitter.