Blogs - udellgames

A lot of designers build their games based on the idea of what a game should be (and I'm no different), and not what a game can be. This leads to unoriginal thought and the use of certain recurring themes (tropes) that aren't always necessary and can often be a detriment to the game. In this series, I'll bring to light my personal opinions on a number of the most egregiously mis- and overused of tropes.

Death as a punishment

Why not start with a controversial one? Hear me out. Death does not need to be the end of every single game. I get that in a shooting game, death often makes sense as a punishment, but is it needed every time? Think about Mario. Does the game really need death and restarting? A Mario game is a fun experience of exploration and timing, they're fairly easy games and most of the fun is from sheer joy at the magical level design and the wondrous worlds created. It's not a reflexive twitch shooter, it's an adventure. An adventure that doesn't need a game-restarting penalty. Think how hard it is to game over in Mario Galaxy. They don't want you to see the game over screen ever, they want you to have fun and not get frustrated, so why not finally pull the trigger and remove death entirely?
And even when death makes sense as a penalty often the way a player experiences death is handled appallingly. Darksiders is a perfect example of death done wrong. Death is the go-to fail condition where surely it's less a final verdict and more a meeting of old work colleagues. Instead it might have been more fitting to have the horseman Death appear, taunt you, and perhaps aid you in your quest. Of course the lore might need a little massaging, but it wasn't exactly grade A material to start with.

Death as a torture

Even worse is the restart that takes place before a cut-scene - skippable or not. Nothing kills the mood better than being forced to sit through a bit you've already done, and this goes double for when that bit is non-interactive. I remember a point in Darksiders where I climbed a building, killed 3-4 low-level enemies with one hit each, crossed a few treacherous jumps over a set of roads and sat through a cut-scene which amounted to a large monster essentially jumping a couple of times only to lose the next battle and have to repeat that entire sequence again. At what point in the game did those minions become crucial to the flow of the experience? Why did I have to see this monster jump up and down at all? Let alone each time I died. It was frustrating and I nearly didn't get past that section through sheer annoyance. It's 2013, people. If you're spending millions of dollars making a game, make your cut-scenes skippable.

More recently, there's a wonderful video review of the latest entry to the Need For Speed series by TotalBiscuit, in which failure to complete the tutorial in one sitting causes the game to make you sit through all the opening cinematics and tutorials again. Check out his extreme frustration and heed the warning; developers and potential customers alike.

Death done well

I don't want to just focus on the downsides and pretend that all of gaming amounts to failures so I want to end on a high note. Let's celebrate some games that try to do something different.Far Cry 2 - for it's many, many faults (seriously, I hated playing it) - has an amazing approach to player death. If you've managed to make a friend in your travels, a total loss of health causes you to blink in and out of consciousness, across the screen flash fleeting images of your friend arriving, shooting in the distance, dragging you to safety and then pulling you to your feet. You restore a bit of health and then they join you in the fight. It's an excellent way of balancing difficulty automatically. Is a section too hard? We'll let you try it yourself, but if you fail we'll send in back up. Of course, if you die again after your friend has rescued you, you die for real, but repeating the process might be a bit ridiculous.

Demon's Souls had possibly the most ambitious and clever use of player death I've ever seen. The game consisted of two forms, body form (normal) and soul form (after you died). When in soul form, you have half HP, but some character types will deal bonus damage. To return to body form the player has to kill a boss in soul form, or enter another player's world and either help them kill a demon or kill the player.

Know any games that make an excellent use of death, or that have gotten rid of death entirely where one might expect it? Got ideas for future Tropes articles? Disagree with me and want to call me names? Post a comment!

Note: Quick observers will see that there's actually nothing stopping you from using inheritance with an entity component system, and that's perfectly true (in fact an entity component system would be hard to create without some inheritance) but this is merely a beginner's guide and those versed in inheritance will hopefully know how to get the best out of both worlds after reading this.

Unity, as those of you who have worked with it before will know, is an Entity Component System. The best way to illustrate the differences between a system like unity and an inheritance hierarchy is with an example. Most people like to use cars as examples when explaining inheritance, and I'm highly unoriginal, so let's follow that. Bear in mind that if your project has been well-planned from the start, you won't encounter this problem when creating your classes, but it may arise when it comes to refactoring, performance optimisation or balancing.Say you want to create a car. If you were using an inheritance architecture you'd create something like this:

public class Car
{
	public string License; //The license plate on the car
	public Color color;
	public float speed; //Miles per hour

	public Car(Color color)
	{
		LicensePlate = DMV.Instance.GetLicense();
		this.color = color;
	}

	//Apply acceleration. Acceleration is metres per second per second
	public void Accelerate(float acceleration)
	{
		//Accelerate
	}

	public void Drive()
	{
		//Go places
	}
}

That's great, but what if we also want boats? Well, we'd move a lot of the code from Car into Vehicle, perhaps, and then we'd add float instead of drive, obviously, and maybe we'd add a function for calculating buoyancy and floating. The result looks like this:

public abstract class Vehicle
{
	public Color Color;
	public float Speed; //Miles per hour

	public Vehicle(Color color)
	{
		this.Color = color;
	}

	//Apply acceleration. Acceleration is metres per second per second
	public void Accelerate(float acceleration)
	{
		//Accelerate
	}
}

public class Car
{
	public string License; //The license plate on the car

	public Car(Color color): base(color)
	{
		LicensePlate = DMV.Instance.GetLicense();
	}

	public void Drive()
	{
		//Go places
	}
}

public class Boat : Vehicle
{
	public float Weight; //in tons

	public Boat(float weight) : base(Color.Grey)
	{
		this.Weight = weight;
	}

	public void Float()
	{
		//Just bobbin' around like it ain't no thing.
	}
}

The codebase has grown substantially already. Let's add guns and let's say that guns share nothing in common with a vehicle except that they also have a colour. We'll pretend we decided boats were so big they needed textures instead of solid colours. What have you got?

public abstract class Vehicle
{

	public float Speed; //Miles per hour

	public Vehicle()
	{

	}

	//Apply acceleration. Acceleration is metres per second per second
	public void Accelerate(float acceleration)
	{
		//Accelerate
	}
}

public class Car
{
	public string License; //The license plate on the car
	public Color Color;

	public Car(Color color)
	{
		License = DMV.Instance.GetLicense();
		this.Color = color;
	}

	public void Drive()
	{
		//Go places
	}
}

public class Boat : Vehicle
{
	public float Weight; //in tons
	public Texture2D Texture;

	public Boat(float weight, Texture2D texture)
	{
		this.Weight = weight;
	}

	public void Float()
	{
		//Just bobbin' around like it ain't no thing.
	}
}

public class Gun
{
	public Color color;

	public Gun(Color color)
	{
		this.Color = color;
	}

	public void Fire()
	{
		//Pew pew!
	}
}

Now it's getting messy. We've broken the principles of DRY just to give guns colours. Now if we change how colours work (perhaps to add transparency) we'll have to change it in two different places. It's also worth noting that actually modifying the fact that boats no longer have a solid colour took a lot of work. We had to remove color from the Vehicle class, we had to add it manually to Car. We had to change the constructor for Vehicle, and all the inherited constructors. All this for a car, a boat and a gun. You can imagine that Grand Theft Auto must be a lot harder.

Depending on your language, the solution here might be multiple inheritance. Simply make Car inherit from Vehicle and ColouredItem and make Gun inherit from ColouredItem. Multiple Inheritance has its own problems though, but I won't go into them.Unity's solution is to use components. Each game object is the same class (handily called GameObject) that handles some base functions and manages the component system. Each GameObject holds an array of Component instances which all dictate the various behaviours of the object. Here's our example using the Entity Component System:

public class GameObject
{
	public List Components;
	public GameObject(List components)
	{
		this.Components = components;
	}
}

public abstract class Component
{
	//Runs at game start
	public virtual void Start()
	{

	}
}

public class Driver : Component
{
	public float speed;
	public void Accelerate(float acceleration)
	{

	}
}

public class License : Component
{
	public string license;

	public override void Start()
	{
		license = DMV.Instance.GetLicense();
	}
}

public class Floater : Component
{
	public float speed;
	public void Accelerate(float acceleration)
	{

	}
}

public class Colour : Component
{
	public Color Colour;
}

public class Gun : Component
{
	public void Fire()
	{
		//Pew pew!
	}
}

Admittedly this has led to the code being a little longer, but in the long run - with fewer non-DRY code segments and wonky inherits it'll be a lot smaller and a lot easier to maintain. Want to change how colours work? Just change the Colour component. Anything with a solid colour will immediately be updated. Also, how code is executed has changed. In order to execute Accelerate() on the Driver component on your GameObject you must first find the Driver component (or use a pre-created reference to it) and then call the Accelerate function on it. In Unity, the code to do this looks like this:

GameObject car = new GameObject();
Driver driver = car.GetComponent();
if(driver != null)
{
    driver.Accelerate(5f);
}

In Unity, however, each Component comes with a set of functions (Start() ,Update(), etc) which allow components to be fairly autonomous. In this example, the Driver could listen for input in the Update() function, which is called once per frame, and call its own Accelerate() without external interference. It is important to note that this is not the case with all Entity Component Systems.Another great feature is that functionality can be modified on the fly. Say you're James Bond and you have an amphibious car. I'm not sure how I'd model that with inheritance, but I'm certain it would be wonky at best and have stronger code smells than a Fish class. If pressed for time, I'd probably create two classes, one for when the car was in the water and one for when the car was on land and swap between the two. With an Entity Component System however, all you have to do is remove the Driver component and add the Floater component. In fact with Unity, you can simply add both components simultaneously and enable or disable the Floater or Driver behaviour on the fly. Much easier.

However, It's not without its drawbacks. With complex scenes, an Entity Component System can be much slower, because typically the list of all entities is enumerated for any given system, such as collision detection. In Unity, acquiring a component from an entity (for example when one component needs to talk to another) can be slow, and the Unity docs recommend that you do this once at the start of the level, and a reference kept for the rest of it.

If you're interested in this topic and want more information, check out these pages:
The Entity Systems Project's Wiki
Wikipedia's page on Entity Component Systems
Boreal Games' guide to Understanding Entity Component Systems on GameDev.net

Text adventures are unique in that the inputs are constrained only by game developer's imagination. A player could try to bounce a ball at an enemy, or perhaps undo their belt with magic, and if you've thought of everything, the game will be a delight to play. However in a game with infinite scale, it's easy to take forever to make your game.For projects of phenomenal size it's best to look at a game that has done scale well. I took inspiration from The Elder Scrolls series. The Elder Scrolls games have always featured huge landscapes and hundreds of dungeons and quests. How did they do it? Did they use a team of thousands and thousands working for a hundred years? No. In fact the size of the team working on Oblivion's dungeons was just one person, and for Skyrim? 8. While they have both a large budget and team available to them, Bethesda's real strength lies in their tools. The Creation Kit allows you to build dungeons and landscapes by placing intersecting chunks of themed levels. The results are many but repetitive dungeons made quickly and easily.And yet, if we look at the dungeons - particularly in Skyrim - we see that there is a lot of variation - even with a relatively small set of pieces. How can we learn from this? There are three tricks that I have observed Bethesda use to make their small subset of pieces seem like varied and vast dungeons.

Clutter

The developer fills each room with different instances of small, trivial items: chairs, plates, bowls, ceremonial equipment, whatever. These different configurations of clutter add a sense of randomness to the otherwise repetitive configurations, and in some instances add new interactivity to the scene. One example is the hanging ceramic lamps positioned recklessly above pools of flammable oil in Skyrim. They're not part of the norma level pieces, but they add to the aesthetic, and help to break up the gameplay by adding options to the player's arsenal.

Low visibility

Dungeons are dark, what does this let you do? This lets you keep details to a minimum. Add clutter into the light areas and the brain imagines it in the dark ones too. This is a great way for 3D games to conserve polygons, but there's no reason we can't prioritise in this way either.

Distractions

Enemies, quests, characters. All these things are added layers of distraction that keep the player from noticing that they're in an ever-repeating set of the same corners and wall pieces. You're not going to notice that you've seen a particular stone column before if it's being peppered with arrows fired by a malicious orc, and the wall of fire chasing you at speed is going to take your mind off the familiar coffin shapes. A sense of urgency is often best for this, time limits - however enforced - leave little time for the player to explore or take in the view, but use these sparingly; as the audience will appreciate chances to let their hearts rest.

What to take away from this

Naturally, a text adventure is different to Skyrim, you can't "see" anything, for one thing. It isn't wise to fill your locations with clutter either as each item must be enumerated on-screen. However there are certainly some lessons to be learned.

Highlight the important areas with variable clutter

Instead of filling the location with clutter why not mention it when the player inspects an important item?This blade of grip and growth lies among a bric-à-brac pile of crumbled stone and dust. You can discern of nothing useful in the pile. The blade shines with hot fury.

Vary the things the player can see

You're in a cave, I get it. That doesn't mean every cave needs one pillar to the East and a glowing chest in the centre; make each room's contents variable. In fact this is a good time to consider procedural generation.

Always have other things on the player's mind

They can't check the rock pool because a dwarf has a gun pointed at their heads or the cave is about to collapse. Be careful here though, while a time limit may appear novel to text adventures it's for a good reason. If you had only five seconds to escape that cave and you accidentally made a typo then you'd be one frustrated player. Similarly those with difficulties ruling out spelling will be instantly turned off of your game. A better approach might be to use turn-based mechanics while showing some leniency towards spelling errors.There's a lot we can learn, as game developers, from the big hits and small flashes alike, and I'm sure there's more to learn from Skyrim than just the measly portion I've included here. I can think of no better advice than to simply play as many games as you can and really think about what went through the designer's head - in both the good places, and the bad - and how they got away with engine or hardware limitations and how they dealt with scope. Remember: if you're enjoying a part of the game, then it stands to reason that you're not alone. Understand why you enjoyed it, and take that advice to heart.

Good artists borrow, great artists steal.