How to Create a Retro Game Boy in 3D: Part 2

Final product image
What You’ll Be Creating

Follow this tutorial step-by-step to create a retro Nintendo Game Boy that you can use in video games, graphic design and illustration projects whilst learning how to model in Cinema 4D

Some of the skills you’ll learn in this tutorial include creating basic 3D modelling, importing reference images and basic rendering techniques.

In this, the first part of the two-part tutorial, I’ll show you how to:

  • How to create Materials
  • How to Colour the Model
  • How to Render the Game Boy 

10. How to Create a New Material

Step 1

Located near the bottom of the screen there should be a material selection window. Click on Create > New Material to create a new material to use that you can edit. I’ll use the materials to colour in the various objects and parts of our Nintendo Game Boy.

Create a new material

Step 2

Double click on the new material to bring up the Material Editor. This is where you can adjust the various properties of your material such as the colour, transparency and reflectance etc. 

For this particular style we will only be interested in flat colour.

The material editor

Step 3

Untick the boxes for Colour and Reflectance and tick the button for Luminance. This gives us the flat colour look for our final image.

Edit the material editor properties

Step 4

To add a material to the object, drag and drop the material to the object using the mouse. 

You can also drag and drop the material onto the object listed on the right of the screen.

The same material can be used for multiple parts of the model. For example, you can use this one material for the front, back and middle parts of our Nintendo Game Boy model.

Drag and drop the material onto an object

11. How to Adjust the Material Properties

Step 1

In the Material Editor, click on the arrow button next to Texture and select Sketch and Toon > Cel from the menu.

Select sketch and toon

Step 2

Click on the new Cel button that appears next to Texture to bring up a new menu.

Select Cel

Step 3

In this new menu, adjust the settings as follows:

  1. Change the Diffuse to match the image at below. It should be greyscale with the colour getting light from left to right.
  2. Untick Camera.
  3. Tick Lights.
  4. Tick Shadows 
  5. Select Multiply from the drop down menu.
Editing the sketch and toon properties

Step 4

Select a colour by double clicking on the colour option box. 

The Material Editor gives you many different options for choosing and picking your colour. These include RGB, HSV etc. Choose whichever option you are most familiar with as a flat colour. Because of the Multiply shading mode, the different colour shades will also appear in the material.

If the material has already been applied to the model, the colour of the model will automatically be adjusted to the new material colour.

Choosing a colour

12. How to Adjust the Shading

Step 1

To get a better idea of the shading and how our render will eventually turn out, click on the small black arrow on the bottom right of the Render Button and select Interactive Render Region from the menu. 

Select interactive render region

Step 2

Adjust the window so that it fits around the Game Boy model. Look for the very small arrow on the right hand side of the window and use the mouse to drag it to the top (this increases the resolution). Decrease the resolution by moving the arrow down if you need to.

Increase the resolution

Step 3

To change the way the light source is facing go to Options > Default Light.

Add a light object to the scene if you are more comfortable working that way.  

Select default light

Step 4

In the Default Light window, click where you would like the light source to come from on the sphere and it will sync with the view port. Experiment with different lighting positions to come up with a lighting situation that you like. 

This can be adjusted at anytime.

Editing the default light

13. Other Lighting Solutions

Step 1

To set up the basic lighting, you’ll want to go to the Floor button located in the top menu bar. Left Click-Hold and then select Physical Sky from the menu.

Select physical sky

Step 2

Ensuring that Physical Sky is selected in the menu on the right, a new menu will appear on the bottom right of the screen. Select the Time and Location tab and choose a time using the left and right arrow keys. This will change the lighting of the scene. Choose a suitable time to light up the scene.

Editing the physical sky

Step 3

To add lighting to the scene, select the Add Light button in the top menu bar at the top of the screen.

This will create a Light Object which you can move around the scene. Move the light object using the Move Tool to a suitable position.

Select add light

Step 4

To customise the lighting further, experiment with the light object options in the bottom right of the screen. Here you can adjust the Intensity, Light Type and even Colour.

Editing the light properties

14. How to Colour the Screen

Step 1

Duplicate the material by holding CTRL on the keyboard and then using the mouse to click and drag the material to the side.

Duplicating the material

Step 2

Double click on the new material to open up the Material Editor and select Luminance. From there we can change the colour to the following:

  • R: 79
  • G: 222
  • B: 183

We can also click on Cel to change the shading properties of this material if needed.

Choosing a green colour

Step 3

Duplicate the first material again (hold CTRL and click and drag with the mouse).

Duplicating the material

Step 4

Double click on the new material to open up the Material Editor and select Luminance. From there you can change the colour to the following:

  • R: 111
  • G: 126
  • B: 135
Choosing the grey colour

Step 5

To create a flat colour, select Cel and change the properties of Diffuse to one colour.

Editing the shading options

Step 6

To apply the new materials to the object, use the mouse to drag and drop the materials to the object that you wish to colour. Drag and drop the material to the object list on the right side of the screen.

Drag and drop the screen material onto the Game Boy screen.

Applying the green material to the screen

Step 7

Drag and drop the dark grey material onto the screen border of the Game Boy.

Applying the grey material to the screen border

15. How to Colour the Buttons

Step 1

Duplicate a new material from the first material again (hold CTRL and click and drag with the mouse). Double click on the new material to open up the Material Editor and select Luminance. Change the colour to the following:

  • R: 232
  • G: 96
  • B: 32
Creating the red colour material

Step 2

Duplicate a new material. Double click on the new material to open up the Material Editor and select Luminance. From there we can change the colour to the following:

  • R: 165
  • G: 199
  • B: 219
Creating the light grey colour material

Step 3

Drag and drop the light grey material onto the button borders of the Game Boy.

Applying the light grey colour material

Step 4

Drag and drop the bright red material onto the main buttons of the Game Boy.

Applying the red colour material to the buttons

16. How to Colour the D-Pad & Small Buttons

Step 1

Duplicate a new material as you did before. Double click on the new material to open up the Material Editor and select Luminance. From there change the colour to the following:

  • R: 89
  • G: 98
  • B: 106
Creating the dark grey colour material

Step 2

Drag and drop the new material onto the D-Pad, Start and Select buttons of the Game Boy.

Applying the dark grey colour material to the buttons

17. How to Render the Game Boy

Step 1

Click on the Render Settings button located in the top menu bar.

Selecting the render settings button

Step 2

In the Save settings you can select the file location that you want to save your image in. Make sure you also choose the format (PNG) and tick Alpha Channel.

You may wish to tick Alpha Channel on, if you want to continue editing the image in another program such as Adobe Photoshop.

Choosing the save settings

Step 3

Under the Output Settings choose the resolution, height and width of the image. This tutorial uses the settings 1920×1200 72dpi.

Choosing the output settings

Step 4

In the Anti-Aliasing settings, select Cubic (Still Image) which can be found under Filter. This will ensure that your render is nice and sharp.

Choosing the Anti-Aliasing settings

Step 5

Click on the Render button to render your final image. Remember to make sure that you have selected the right view in your viewport (front, right, left or perspective etc.) and that you are happy with the camera angle. 

Choose a suitable angle in the viewport by navigating around the scene.

Click on the render button

Step 6

You can also create a camera if you would like greater control over the camera and render options.

Click on the camera button

The End Result

Wait for the final render to finish. Once the render is complete you can repeat the steps above and change the camera or the view port to create a new image from a different angle. 

Throughout the course of the project you have successfully learnt how to:

  • Import Reference Images
  • Prepare for Modelling
  • Model the retro Game Boy
  • Create Materials
  • Colour the Model
  • Render the Game Boy 

Feel free to share your own creations below. You can also export your image into Adobe Photoshop to enhance it further or to use it as part of a larger image.

Final Nintendo Game Boy Image


Unity Solution for Hitting Moving Targets

Final product image
What You’ll Be Creating

While developing games which involve an action element, we often need to figure out a way to collide with a moving target. Such scenarios can be typically called a ‘hitting a moving target’ problem. This is particularly prominent in tower defense games or missile command like games. We may need to create an AI or algorithm which could figure out the enemy’s motion and fire at it. 

Let’s see how we can solve this particular problem, this time in Unity.

1. The Missile Command Game

For this particular tutorial, we will consider a missile command game. In the game we have a turret on the ground which fires missiles at an incoming asteroid. We should not allow the asteroid to hit the ground. 

The game play is tap-based, where we need to tap to aim the turret. With human assistance, the game mechanics are pretty straightforward as the turret just needs to aim and fire. But imagine if the turret needs to automatically fire at incoming asteroids. 

The Challenges for Auto-Firing AI

The turret needs to find out how many asteroids are approaching the ground. Once it has a set of all approaching asteroids, it would then need to do a threat analysis to determine which one to target. A slow-moving asteroid is a lesser threat than a fast-moving one. Also, an asteroid which is closer to the ground is an imminent threat as well. 

These problems can be solved by comparing the speed and position of the incoming asteroids. Once we have determined which one to target, we reach the most complicated problem. When should the turret fire? At which angle should it fire? When should the missile set to explode after firing? The third question becomes relevant because the missile explosion can also destroy the asteroid and has a bigger radius of effect as well.

To simplify the problem, the turret can decide to fire right away. Then we need to only figure out the angle of firing and distance of detonation. Also, there may be the case where the asteroid has already passed the area where it could be hit, meaning there is no solution!

You should download the unity source provided along with this tutorial to see the solution in action. We will see how we derive that solution.

2. The Solution

We are going to do a little refresher of our high school mathematics in order to find the solution. It is very straightforward and involves solving a quadratic equation. A quadratic equation looks like axˆ2 + bx + c = 0, where x is the variable to be found and it occurs with the highest power of 2. 

Analysing the Problem

Let us try to represent our problem diagrammatically. 

diagram of the incoming asteroid and the predicted path of missile

The green line shows the predicted path to be followed by the asteroid. As we are dealing with uniform motion, the asteroid moves with constant velocity. Our turret will need to rotate and fire the missile along the blue path for it to collide with the asteroid at a future time.

For uniform motion, the distance travelled by an object is the product of time and the object’s speed, i.e. D = T x S, where D stands for the distance, T is the time taken to travel D, and S is the speed of travel. Assuming that our asteroid and the missiles would definitely collide, we can find the distance of the blue line followed by the missile in terms of time t. In the same time t, our asteroid will also reach the same position. 

Essentially, in the same time t, the asteroid will reach the collision position from its current position, and the missile will also reach the same collision position in the same time t. So at time t, both the asteroid and the missile would be at the same distance from the turret as they would be colliding with each other.

Enter Math

We can equate the distance from the turret to the asteroid and missile at this future time t in order to derive our quadratic equation with the variable t. Consider two points on a two-dimensional plane with coordinates (x1,y1) and (x2,y2). The distance D between them can be calculated using the equation below.

If we denote the turret position as (Tx,Ty), the missile speed as s and the unknown collision position as (X,Y), then the above equation can be rewritten as:

where t is the time taken for the missile to travel the distance D. Equating both, we get our first equation for unknowns X and Y with another unknown t.

We know that the asteroid also reaches the same collision spot (X,Y) in the same time t, and we have the following equations using the horizontal and vertical components of the asteroid’s velocity vector. If the velocity of the asteroid can be denoted by (Vx,Vy) and the current position as (Ax,Ay), then the unknown X and Y can be found as below.

Substituting these in the earlier equation gives us a quadratic equation with a single unknown t

Expanding and combining similar terms:

Representing the power of two as ˆ2 and the multiplication symbol as * may have made the above look like hieroglyphics, but it essentially boils down to the final quadratic equation axˆ2 + bx + c = 0, where x is the variable t, a is Vxˆ2 +Vyˆ2 - sˆ2, b is 2* (Vx*(Ax - Tx) + Vy*(Ay - Ty)), and c is (Ay - Ty)ˆ2 + (Ax - Tx)ˆ2. We used the equations below in the derivation.

Solving the Quadratic Equation

To solve a quadratic equation, we need to calculate the discriminant D using the formula:

If the discriminant is less than 0 then there is no solution, if it is 0 then there is a single solution, and if it is a positive number then there are two solutions. Solutions are calculated using the formulas given below.

Using these formulas, we can find values for the future time t when the collision will happen. A negative value for t means we have missed the opportunity to fire. The unknowns X and Y can be found by substituting the value of t in their respective equations.

Once we know the collision point, we can rotate our turret to fire the missile, which would definitely hit the moving asteroid after t secs.

3. Implementing in Unity

For the sample Unity project, I have used the sprite creation feature of the latest Unity version to create the necessary placeholder assets. This can be accessed with Create > Sprites > as shown below.

Implementing in Unity

We have a game script named MissileCmdAI which is attached to the scene camera. It holds the reference to the turret sprite, missile prefab, and asteroid prefab. I am using SimplePool by quill18 to maintain the object pools for missiles and asteroids. It can be found on GitHub. There are component scripts for missile and asteroid which are attached to their prefabs and handle their motion once released.

The Asteroids

Asteroids are randomly spawned at fixed height but random horizontal position and are hurled at a random horizontal position on the ground with a random speed. The frequency of asteroid spawning is controlled using an AnimationCurve. The SpawnAsteroid method in the MissileCmdAI script looks as below:

The Launch method in the Asteroid class is shown below.

As seen in the Update method, once the asteroid has traveled the predetermined distance to ground, deployDistance, it would return to its object pool. Essentially this means it has collided with the ground. It would do the same on the event of collision with the missile.

The Targeting

In order for the auto-targeting to work, we need to call the corresponding method frequently to find and target the incoming asteroid. This is done in the MissileCmdAI script in its Start method.

The FindTarget method loops through all the asteroids present in the scene to find the closest and fastest asteroids. Once found, it then calls the AcquireTargetLock method to apply our calculations.

AcquireTargetLock is where the magic happens as we apply our quadratic equation solving skills to find the time of collision t.

Once we find the point of impact, we can easily calculate the distance for the missile to travel in order to hit the asteroid, which is passed on through the deployDist variable onto the LockOn method of the missile. The missile uses this value to return to its object pool once it has travelled this distance the same way as the asteroid. Before this happens, it would have definitely hit the asteroid, and the collision events would have been triggered.


Once we implement it, the result looks almost magical. By reducing the aiPollTime value, we can make it an invincible AI turret which would shoot down any asteroid unless the asteroid speed becomes close to or higher than our missile speed. The derivation we followed can be used to solve a variety of similar problems which could be represented in the form of a quadratic equation. 

I would like you to experiment further by adding the effect of gravity to the motion of the asteroid and missile. This would change the motion to projectile motion, and the corresponding equations would change. Good luck.

Note also that Unity has an active economy. There are many other products that help you build out your project. The nature of the platform also makes it a great option from which you can better your skills. Whatever the case, you can see what we have available in the Envato Marketplace.


Class Design in Games: Beyond RPGs

Classes are
everywhere. Once the domain of RPGs, now class systems have been
pushed into every type of game imaginable. We’re all familiar with the tropes of Warriors and Wizards in high fantasy, but what can we learn about class design from other games?

The first question we need to ask ourselves is, “What exactly is a
class?” The term is pretty loosely defined in gaming, and there are several correct answers. In an RPG like Dungeons &
Dragons, classes are defined by the rulebook and present a list of abilities your character can have access to. 

If you want to be a stealthy assassin or a shapeshifter, you need to choose an appropriate class. The thing
is, there are other choices you can make as well: choosing your race
(elf or dwarf) and background (criminal or noble) which also affect
your gameplay options. What exactly is the difference between race
and class? If your character can breathe fire because they’re a
half-dragon, is that any different from being able to shoot magic
flame from your hands? We really have to look at these things as variations on the class concept.

So when we’re
discussing classes, we’ll be talking about not just standard RPG classes and races, but Starcraft armies, Street Fighter characters, and even Mario Kart vehicles. It might seem odd to lump all of these in
the same box, but they all share something simple: a choice you make outside of the game which determines your gameplay options within the game.

Age of mythology image
Age of Mythology divides its classes into races, and then further as individual gods.

Why Use Classes?

So why even bother with
classes? What do they add to a game? There are a lot of reasons, but
one of the simplest is adding content. More classes = more ways to
play the game = more ways to have fun. When you look at World of
Warcraft, it’s not uncommon to see players with several high-level characters. 

Tails was so popular as an additional character in Sonic that they later added Knuckles, Shadow, Cream, and countless others. Dungeons &
Dragons has a multitude of classes available for players, spread out
throughout optional rulebooks. At an extreme level, some games exist
solely because of their variety of classes—imagine Smash Bros with Mario as the only character. Fighting games are fun
largely because of the way different characters interact, meaning that every matchup has different strategies.

Another reason
classes are useful is because they promote diversity. This is
especially important in competitive multiplayer games, where
(generally speaking) everyone wants to be the best. If you wanted to
make an MMO where players can assign points to their skills, you might think
that the playerbase would create a range of different character types. What inevitably
happens, though, as shown over and over by MMOs like Ultima Online, is that players gravitate towards “best

Generally, a small selection of players who are
experienced at the game will do the math and post optimal builds, and
everyone else will just copy that. This “copy others” attitude isn’t unique to MMOs (Magic: The Gathering players have debated for some time the pros and cons of “netdecking”), and any game where you can choose your skills will have at least some discussion on best builds.

Of course, creating classes
doesn’t stop the issue—World of Warcraft, despite having multiple classes, has plenty of build discussion—but it at least creates a little bit of
variety. Instead of having a single “generic tank build”, you might
have a choice of playing a warrior tank, paladin tank, or druid

And lastly, it
reduces the gap between skilled and unskilled players. Being a new
player to a game can already be frustrating when everyone is better
than you, but if everyone is also using better characters then it
can feel doubly frustrating. New players might feel as if they are
being punished for their lack of knowledge,
whereas pro players might spend their time trying to find abusive
build combinations. 

New players also run the risk of “doing it wrong” by spending points on useless skills—the idea of “noob traps” is something we’ve discussed before. By forcing players into predesigned classes, you refocus the game back onto the gameplay, and away from character building.

So are there any
problems with classes? Well, obviously it can be a massive time investment. But from a design perspective, there’s really just one issue: class systems limit a player’s ability to experiment with fun builds or create specific ideas. Players love to be creative, and limiting that creativeness can limit the amount of fun to be had. 

For highly competitive games, it can be argued that “design your own” systems are an extremely dangerous idea, as all it takes is one overpowered combination to ruin the whole thing. But for some games, character creation is what makes the game fun in the first place.

Impossible Creatures image
Impossible Creatures, an RTS where players can fuse creatures together to create their own armies and engage in Mad Scientist combat. 

So, assuming we do want to add classes, how do we go about designing them? Well, it’s such an expansive concept that even if we limited ourselves to a
particular genre, we could write a novel and still only scratch the surface. So let’s focus instead on some general common issues that apply across the board.

Strict vs. Loose Class Design

The word “class” means
many things, so let’s introduce a new concept: the idea of strict and
loose classes.

  • A strict class is
    one that defines a player’s available skillset.
  • A loose class gives more limited powers or bonuses to certain playstyles.

Generally speaking,
the more complex a system is, the more likely it is to be

In Diablo 3, players can choose from classes like Barbarian, Monk, and Wizard. These classes have special abilities, and those abilities define what the character can do. Only the Monks have Cyclone Strike, and only Wizards have Hydra. The classes gain specific skills at specific levels, and can never learn skills from other classes. Diablo 3 is very firmly a strict system.

Compare to a game like Desktop Dungeons, which is a loose system. When a player chooses a class, it simply gives that player a minor advantage: Berserkers have 50% magic resistance. Priests deal double damage to undead. A Berserker can still do all the things a Priest does, but is better (or worse) in certain situations.

Obviously, there is no clear distinction between “strict” and “loose”, and there will be games which can be argued to be in either camp. Vampire: The Masquerade allows players to choose a clan, and although each clan has unique powers, these powers do not define the character and the game otherwise operates like a standard point-buy system. 

But what of other genres? Well, Hearthstone allows players to choose a class,
and this gives them a class ability they can use in game, such as producing minions or
drawing extra cards. Since this ability only gives a minor advantage in game, it counts as a “loose” class advantage.

However, Hearthstone also has
class cards which can only be used by certain classes. Cards like
Backstab or Sap are Rogue-only cards, but are theoretically useful
for every class. This limiting of cards means Hearthstone is “strict” class design, as every class will have a variety of options unavailable to other players.

So why does this all matter? Well, the stricter a game is, the more pronounced the
benefits of a class system are (as discussed above in “why use classes”). More variety between classes, fewer “noob traps”,
more fun for players. Additionally, strict design allows you to
create incredibly flavourful classes. In Hearthstone, playing
a priest feels like playing a priest (or at least, as close as you can
get in a card game). Each of the classes feels distinct, and this
distinctness allows the player to play the game in a variety of
different ways (hopefully finding one suitable to their playstyle).

The downside is, of
course, the same downside mentioned above—that the player is
limited to the playstyles defined by the developers. It doesn’t
really allow for exploration beyond that. And because each class has
a certain playstyle, there are times when you’re going to know how
the game will play out before the first move is made or card is

This can be pleasant (if you’re winning), or frustrating (if
not). If you struggle to beat rogues and continually get matched
against them, the game can become unfun very quickly. Depending on
what playstyles or meta is popular at the time, it might
mean playing a string of games against not just the same class, but
the same deck or character build—which can be pretty

Mechanical design is
just one aspect of character creation, however. We need to ask what players want from their games, and there are several answers. For most new players, they’re not thinking about the mechanics behind each class—most often, they want to play the cool soul-stealing ninja, or the alien that eats face. This side of character design, which includes things like backstory and visual design, is often referred to as “fluff” or “flavour”. It’s an important part of the design process, but it’s enough of a topic by itself that we’ll have to leave it for another time.

The other question players most often ask is, “Well, what does it do?” Sometimes the answer is obvious, sometimes less so—but generally, the player will be trying to find a class which allows them to play the game in the way they want.

South Park Stick of Truth image
South Park’s “Jew” Class is a non-standard class with powerful lategame abilities.

Fulfilling a Role

Generally speaking, the purpose of a class is to allow the player to play the game in a way that they enjoy. Not everyone enjoys playing magic classes, so it’s important not to force players into roles they don’t enjoy. Of course, for multiplayer games, some players will be pressured into playing certain roles, but generally speaking players will play whatever is the most fun.

In certain games (like MMOs), the ability to fill a role becomes doubly important. If your party is planning to fight the Dragon Emperor, then you probably need to have a strategy. Typically, tank/damage/healer roles are primary, with other roles such as controller, leader, tracker and so forth dependent on the game. 

Because available party slots are generally limited, it’s important that your team is able to get the most out of its available party slots—all healer parties tend to do poorly. Players will want to choose roles that complement each other to maximise their chances of success, and this means giving the players the option to choose classes that they enjoy and feel are useful to the team.

Regardless of the game style, you want to create classes that allow for an enjoyable gameplay experience. The classes you design will determine how the game is played. If all your characters are swordsmen, then gameplay is going to be focused on close quarters fighting. If you add a single sniper to the game, then suddenly the whole dynamic changes—environment and cover suddenly become more important, and rushing around in the open is no longer a viable tactic. 

You need to understand what you want from your game, and the roles and abilities you have should promote that gameplay style. If you don’t want a role being fulfilled, then simply don’t add it to your game. Don’t like the idea of healers slowing down gameplay? Remove them. It’s your game, so there’s no reason you have to stick to “traditional” design roles.

Despite many games using the traditional tank/dealer/healer design, there are plenty of reasons to avoid it. The most obvious is that if you design your game around those classes as a central idea, anything which does not fit into those criteria is bad. Imagine a Warrior, Rogue and Cleric being joined by a Banker or Farmer. There’s no reason that players shouldn’t be allowed to play those alternative classes, but the chances are they have no place within the “holy trinity” framework. Classes not only have to be balanced with each other, but within the game itself.

Balancing the Classes

Sometimes, however, we can get obsessed with concepts like balance—making sure every class is fair to use. While for some games this is necessary, it’s not necessary for every single game. Bad classes can provide extra challenge, or a balancing factor for experienced players. The Binding of Isaac’s “The Lost” can fly, but dies in one hit. Street Fighter’s “Dan Hibiki” is a popular joke character. These “bad classes” are simply more options for players who choose to challenge themselves. Additionally, if every class is perfectly balanced, then what does it matter which one you choose? 

We should also ask what we’re balancing for. Do we balance based on win rates? Or how they compare for 1 on 1 combat? Some games, MMOs in particular, struggle to keep characters balanced between the PVE and PVP elements. In the Binding of Isaac, damage is often considered a “god stat” for characters—not only is it incredibly handy to be able to one-shot everything in sight, but the game rewards fast play with secret bosses and going unhurt with “devil items”, powerful items that serve to snowball a good character even further. The slower, tankier characters like Magdalene look fine on paper, but simply can’t compete with the bonuses that high-damage characters get. Whereas The Lost is an interesting character because of intentional difficulty, Magdalene is simply a boring character.

Binding of Isaac image
The Lost, one of the many characters from The Binding of Isaac.

League of Legends embraces this and uses an idea called “perfect imbalance” to keep gameplay fresh. The game is incredibly complex, and trying to balance over 130 characters is basically an impossible skill. Not only do the designers have to contend with how the characters interact, but every time a small change is made it could theoretically throw everything out of balance again. 

They try to ensure that no single character is overpowered, but there are plenty of “bad characters”—and due to the evolving of the game, sometimes characters which are seen as bad suddenly become viable. The complexity and ever-changing nature of the game mean that players are constantly forced to re-evaluate the best strategies, ensuring that gameplay is never “solved”.

“Solving” is a problem for many games. When you look at classes, sometimes you can put down all the abilities on paper and work out what exactly each class is capable of. What this means is that in team games, classes are often judged by a single metric: how much damage you can output, how quickly you can heal, or how quickly you can race to the end. Your character has one job, and the best character for that job is whoever has the highest numbers. This raises an interesting question: is it better to have a class that is exceptional at just one task, or to have a class that can do everything satisfactorily? 

Specialisation vs. Flexibility

When we create a
class, we should generally have a rough idea of what we want from it.
In an MMO, the perfect tank is basically a granite boulder—something
that will just sit there and soak up damage while the rest of the
team throws flaming death. This creates a sort of “arms race”
which means the most specialised characters are (almost always) the
best ones for the jobs.

The problem with
this is that if one character is the best at the job, every other
character is (by default) not the best—and why would you
intentionally play a bad character? This is a problem for MMOs who
are trying to juggle balancing dozens of character classes. Why play
a rogue if mages have better DPS? 

Imagine making a game, similar to Civilization, wherein you try to take over the world. You can achieve victory through political, military, or cultural might. You can also choose a race, and each race has a benefit: elves are better at politics, orcs are good at military, and so forth. Why would a military fan ever choose anything other than orcs? Also, if you’re playing against orcs, why would you invest into political defence? The specialisation of the races restricts your playstyle and forces you into certain options.

Civ 6 image
The races in Civilization IV encourage players to use certain tactics without forcing them down any particular avenue.

This is the biggest problem with specialised classes. If
specialisation is doing one thing well, then it means not doing
anything else. If choice is a core component of gameplay, then
doing the same thing over and over again is bad design. This is a
problem many games face, and it’s a problem especially with regards to
healing classes

So what’s the
solution? As we discussed in the healing article, you need to
make sure the player has a range of options available during the
game. It’s one of the most fundamental aspects of game design: keep
the player engaged. If the player doesn’t have to make any choices for their actions, then they’re not engaged, and that’s when things become boring.

So when you make your class, make sure they’re able to participate in the game at all
times. If you’re designing an RPG, make sure the classes all have
skills for both inside and outside of combat, rather than creating a “skill-monkey” character. If you’re
designing a game with multiple paths to victory, try to make sure each race has the option of winning in different ways. 

Allow players to adapt to the flow of the game, and if they realise they need to change tactics, allow them. The more specialised a class or race is, the more likely it
can only do one thing, and the more likely it is to get stuck doing that thing over and over again. Choice is important.

Soft and Hard

Players like to win. In a competitive, class-based game, players will generally choose the best class. Best is often subjective—it depends on the player’s skill, playstyle, the map, and even recent gameplay changes. For most players, “what is best” is really just “whatever beats your opponent”. 

For some games, this means trying to anticipate what your opponent is going to play. For CCGs like Magic and Hearthstone, players talk about “the meta“—what the most popular decks are and what cards your opponents are likely to be running. A player might choose to play a deck specifically to beat the meta, running cards that shut down certain decks. In magic, some deck archetypes can be entirely shut down by a single card, meaning that playing the meta can be an effective way to win.

In other games, players take turns “drafting” their characters. Knowing what your opponent has chosen means that the ability to choose a counter becomes especially important. The tactic of trying to pick
a character or class specifically to beat your opponents is known as

Having counters in
games is generally a positive mechanic. It allows a certain amount of
self-balancing from the players themselves, as any player who uses an
overpowered class can expect to hit a higher share of
counter-classes. The existence of a meta-game allows players to discuss
the best tactics, the best counters to those tactics, and the best
way to play in the current environment.

The question is then
to what extent counters should be effective. Generally, counters
fall into the category of “soft counters” and “hard counters”.

Soft counters are
classes that have a slight bonus against certain character types. High mobility characters are generally a soft counter to snipers—although the sniper can win, they need to be skillful or lucky to stand a chance.

Team Fortress 2 image
Team Fortress 2s “Meet the Spy”. Some would argue whether the Spy is a soft or hard counter to the sniper, although it largely depends on the player’s skill and general awareness. 

Hard counters are
classes which completely obliterate another class with little to no
effort. Spearmen are often given as a hard counter to cavalry charges—although the cavalry could win, it’s more than likely not going to happen. The best answer here is to call in some archers.

So are soft counters or hard counters better for your game? Well, obviously it depends on what you’re aiming for, but for nearly every game out there the answer is simple: soft counters are better.

The reason for this
is simple: hard counters deny counterplay. Having a more difficult game
due to a counterpick is fine: being unable to do anything at all is bad.
Soft counters can generally be worked around, but hard counters leave
no room for creativity or tactical moves.

So can a hard counter
ever be acceptable design? Yes, under two scenarios:

  1. The player is
    able to change class midgame, allowing them to counter the counter.
  2. The player is
    part of a larger team and is able to “offload” the problem onto
    someone else.

That’s not to say
that hard counters are acceptable in these situations, but the
problem is less pronounced. The player still has some sort of choice available, and may be able to “avoid” the issue.

Boiling It All Down

So what can we take
away from all this? Really, class design isn’t all that complicated.
It comes down to a single idea:

Let the player play
the game in a way that they enjoy.

That’s it—the great
secret to class design. It doesn’t matter what sort of game you’re making, all that matters is that the players are having fun. 

The very essence of class design is, as we’ve said so many times, about choice. It’s about the player choosing to play something they enjoy, about being given meaningful choices throughout the game, and about how those choices interact with the challenges they face, be it enemy AI or other players.

And because new games often contain a world of information, it allows players to make choices more meaningful. A new player might be overwhelmed looking at 100 different statistics, but if you give them just a handful of choices—ask them which class they want to play—they can answer that easily. They don’t need to worry what the correct number of points to spend on vitality is; they simply pick a class and get stuck in.

Your class gives
players additional ways of playing your game, and in a way each class
is like making an entirely new game. As long as your class doesn’t stop other people having fun, it’s probably fine.

And remember, at the
end of the day, each game is different. There is no “correct” in game design, and there are no doubt many successful games that break some (or all) of these rules. Just try to consider them when designing your game, and don’t be afraid to break the mould and try something different. All of this is aimed at one simple idea: make your game fun.


Creating a Simple 3D Physics Game Using Three.js and Physijs

Final product image
What You’ll Be Creating

In this tutorial, you’ll learn how to use Physi.js to add game physics to a 3D scene created using Three.js. We’ll create a simple game in which we drive a cart around collecting items, using basic physics shapes and physics constraints.

This tutorial will be building on top of the concepts shared in my previous Three.js tutorial. I would request you to read it if you are new to Three.js and to its 3D scene creation. 

Due to a technical limitation in hosting web worker based solutions on JSFiddle, we are unable to embed the interactive game in this tutorial page. Please use the provided source code to check out the working example on any cloud-based IDEs or by self-hosting.

1. 3D Physics on the Web

There are multiple frameworks and engines currently available which can be used to create 3D content for the web with physics. Some of those worth mentioning are Turbulenz, BabylonJS, PlayCanvas, and the obvious Unity WebGL build. But when it comes to popularity and ease of use, most people like to use Three.js for their experiments. As Three.js is a rendering engine and does not have integrated physics, we need to explore additional frameworks to add the physics capability.

A very popular JavaScript physics solution is Ammo.js, which is a direct port of Bullet physics. While directly using Ammo.js is possible, it is not very beginner friendly and has a lot of boilerplate code for each aspect. Also, as it is not manually written but ported using Emscripten, the code is not easy to understand. 

An alternative solution is to use Cannon.js or Physijs. The interesting thing with Physijs is that the focus is always on making things easier, which makes it the ideal choice for beginners. It is built based on Ammo.js and even has a Cannon.js branch. This tutorial uses Physijs and Three.js to build a working game prototype with physics capabilities. 

Yet another option, although oversimplified, would be to use the Whitestorm framework, which is a component-based framework based on Three.js and Physijs. 

2. Setting Up Physijs

We need to have the ammo.js, physi.js, physijs_worker.js and three.js files within our folder structure or coding environment to use Physijs. Physijs uses a web worker to use different threads for physics calculations. So the first step in the integration process is to set up the web worker as below.

At this point, the setup is complete, and we can start using the physics framework. Physijs has made sure that it followed the coding style of Three.js, and most of the concepts are simple replacements of the corresponding Three.js concept.

Basic Steps

Instead of THREE.Scene, we need to use Physijs.Scene.

There are multiple meshes available in Physijs which need to be used in place of THREE.Mesh. The available options are PlaneMesh, BoxMesh, SphereMesh, CylinderMesh, ConeMesh, CapsuleMesh, ConvexMesh, ConcaveMesh, and HeighfieldMesh.

We need to call the scene.simulate method to do the physics calculations either in the render method or within frequent intervals. Let me remind you that the physics calculations happen in a different thread and will not be in sync or as fast as the scene render loop. 

Even the next call to scene.simulate may happen while the previous calculations are still running. In order to make it properly in sync with the physics calculations, we could use the Physijs scene’s update event.

In order to register a collision on a Physijs mesh object named arbitrarily as cube, we can listen to the collision event.

Within the above method, this will refer to cube, while objCollidedWith is the object cube has collided with.

3. Example Game Prototype

For this tutorial, we will be creating a very simple physics-based game where we will use physics constraints to create a vehicle. The player can use arrow keys to drive the vehicle and collect a bouncing ball which randomly appears in the play area. 

Interestingly, Physijs already has a special vehicle feature which can be directly used for creating vehicles, but we won’t be using it.

The Game World

Our game world is a vast ground with walls on its four sides as below.

ground with walls

We use Physijs.BoxMesh for the ground and the four walls as shown in the code below.

Notice the usage of Physijs.createMaterial to create the necessary physics materials by passing a friction value and a restitution value. The friction value determines the grip on the ground, and the restitution value determines the bounciness. One important thing to note is that when we provide a mass value of 0, we create a stationary mesh object.

The Vehicle

We are going to create a special vehicle which has two connected parts. The front part, which has three wheels, acts as the engine, and the rear part, having two wheels, will act as a carriage. The carriage part is connected to the engine part using a hinge joint implemented using a Physijs.HingeContraint

The wheels use Physijs.DOFConstraint, which is a degree of freedom constraint to be attached to the vehicle’s body while retaining the ability to rotate independently. I would invite you to read the official documentation on the various constraints available in Physijs.

The engine body and carriage body are simple BoxMesh objects like the ground shown above, but with a definite mass value. They are connected to each other using a hinge joint, as shown in the following code. A hinge joint restricts the motion of the connected object like that of a normal door.

The second part of the code applies limits to the rotation of the hinge, which in this case is between -Math.PI/3 and Math.PI/3

The wheels use a degree of freedom constraint which can be used to set limits on both linear motion and angular motion in all three axes. A method addWheel is created for adding wheels, which takes in multiple parameters. 

The parameters are the position of the wheel, the weight of the wheel, whether the wheel is big or small, and the wheel reference object. The method returns a newly created DOFConstraint, which is used for driving the vehicle.

The big wheels need to be attached to the carriage, and the small wheels are attached to the engine. The wheels are given a damping value so that their angular velocity gets reduced when no external force is being applied. This makes sure that the vehicle slows down when we release the accelerator. 

We will explore the driving logic in a later section. Each wheel mesh along with the car meshes are assigned the name of cart for identification purposes during the collision call back. Each wheel constraint has different angular limits, which are set independently once they are created. For example, here is the code for the front middle wheel of the engine, car.wheel_fm, and the corresponding constraint, car.wheel_fm_constraint.

The Ball

The ball is a Physijs.SphereMesh object with a lower mass value of 20. We use the releaseBall method to position the ball randomly within our game area whenever it gets collected. 

One thing worth noticing is the fact that we need to override the position values set by the physics simulation in order to reposition our ball. For this, we use the __dirtyPosition flag, which makes sure that the new position is used for further physics simulation.

The ball gets collected when it collides with any part of the vehicle which happens in the onCollision listener method.

Driving the Vehicle

We add event listeners for the onkeydown and onkeyup events of the document, where we determine the keyCode to set the values of the corresponding wheel constraints. The theory is that the single front wheel of the engine controls the turning of our vehicle, and the two wheels on the rear of the engine control the acceleration and deceleration. The wheels on the carriage do not play any part in the driving.

The DOFConstraint uses the enableAngularMotor method to apply angular velocity on the wheel which turns the wheel based on the axis value provided as a parameter. Basically, we only turn the wheels, and the motion of the vehicle happens due to the frictional response of the ground, as in the real world.

the completed game

We are unable to embed the working game in this page as mentioned at the start of the tutorial. Please go through the complete source to understand how everything is wired together.


This is a very simple introduction to implementing physics in your Three.js 3D world. The Physijs documentation is sorely lacking, but there are many examples already available which are worth looking into. Physijs is a very beginner-friendly framework, like Three.js, when you consider the complexity that is present under the hood. 

JavaScript is clearly popular for game development as well as web development. It’s not without its learning curves, and there are plenty of frameworks and libraries to keep you busy, as well. If you’re looking for additional resources to study or to use in your work, check out what we have available in the Envato marketplace.

Hope this tutorial helps you get started in exploring the interesting world of 3D web game physics.


Blender For beginners: Game Asset Creation

Blender for Beginners: Game Asset Creation

Aimed at beginners – or people who are new to Blender – this 5 hour video course will bring you all the way from learning to navigate in Blender to importing your own game asset in a popular game engine. In 8 well organized sections with 51 short videos you will get a complete introduction to Blender and how to create game assets.