Emperor of the Eight Islands

29 May 2018

Imagine a more magical Game of Thrones set in a kind of medieval faux-Japan: you’ve got your tengu, your fickle forest spirits, your sorcerors and witches, but that stuff is just supersition and faith to the noble families who vie for power and the samurai who protect and serve them. This is the world of Emperor of the Eight Islands, which is the first book in a series I’m itching to continue with. It’s pleasantly compact and quick-to-read, at about 250 pages of flowing prose. I’m not looking for volume in my reading diet these days, so more bite-size books are much more preferable to 600-page endurance-fests.

I won’t go into specifics about the story other than to say that while it certainly sets up its sequel, there’s enough meat on the bones to be worth reading on its own. The book just presented me with a very engaging place to be and characters to be with, so I thought I’d give it a recommendation. It’s succeeded in making me interested in checking out some of its source material – Japanese folk tales and old novels – where games and anime and that sort of thing haven’t quite. So who knows – maybe I’ll be reading The Tale of the Heike at some point down the line. If you happen to know of similar novels/comics/whatevers that might scratch the same itch, please let me know!

Depak Ine

26 May 2018

There’s something really special about John Talabot’s 2012 debut album, Fin. Could it be the dreamlike vocals? Could it be the feeling of being transported into a different world through its dark melodies and beats? Could it be how the intoxicating density of each track forms a juicy new layer of flavour, as if it were part of a rich musical chocolate gateau?

Maybe it’s just that it begins like this:

You’re in the jungle. Not a jungle. The jungle. It is a place of immense sacred significance. Fingers of mist curl themselves around enormous tree trunks. The canopy above buzzes with a symphony of life. You brush through the shady undergrowth, stepping softly in sodden leaf litter and murky pools. You are searching for something here, something lost and ruined. You have been trekking for days. It is never light here. Each day begins and ends warm, wet and dark. Finally you catch your first glimpse of it through the trees, its lithic bulk almost obscured by verdant vines, leaves of gold and calm green grass: the ancient temple.

I’ll see you there.

Frostgrave

14 May 2018

Tabletop wargaming can be a lot of fun, but it’s a different kind of fun from what you’ll usually find in a videogame. It’s fuzzy. While in a videogame nearly every move you make, every interaction with the other players, can be unambiguous and clear-cut, the same just isn’t true when you’re measuring inches and moving oddly-shaped minis over the surface of a table. The minis fall over, and when they get back up they’ve slid an extra few millimetres. Even the buildings your soldiers weave between and climb on top of aren’t very solid - they jitter slightly from turn to turn as they are accidentally nudged by the players.

Some designers attempt to tame the madness. To create viable competitive games, they must stamp out any ambiguity about rules. The fuzz must be shaved away to leave a wargame that is slick and streamlined, or so fractally complex that it requires computer-like memory and processing power to execute the rules, and a puritanical attitude between players who police each other’s play and punish every infraction.

Other designers aren’t trying to make a competitive game. Players who are more interested in the simpler pleasures of miniature wargaming – the storytelling, the social contact, the consensual back-and-forth, the trust – will be best served by games that embrace fuzz. Games like Frostgrave.

Economics: The User's Guide

21 Apr 2018

Recently I read Economics: The User’s Guide by Ha-Joon Chang. As the title implies, it’s a kind of top-down beginner-friendly introduction and glossary that can be dipped into at random or read from beginning to end like I did. It talks about the history of economics, the many different things economists study and theorize about, and the multitude of different theories they come up with. It’s well-written, being concise, engaging and humorous throughout. It’s also carefully and considerately opinionated – which is a good thing!

Chang’s main thrust is that there are various economic schools of thought, and that it’s much less of a ‘hard science’ than many economists like to believe. Instead, it’s mushy, fuzzy, and political – it cannot be untangled from politics like mathematics and physics can. How we study, teach and research ‘hard’ sciences can be heavily political, but at the end of the day they bring us objective truths about reality that fields like economics simply can’t offer. Economics used to be known as ‘political economy’, which was much more accurate name. After all, its ultimate goal is to shape governmental (and non-governmental) policy and change the world. That’s a much more political thing to do than investigating quarks and leptons¹. The forward-thinking student should analyse and learn from every school, because each has its blind spots and dead ends along with all the valuable insights into how the world works.

He also gives the one of the best one-page overview of the many different meanings of the word ‘liberal’, and why ‘neoliberal’ means more or less the same thing as ‘neoclassical’, and why you should probably use the much less confusing word.

If you’re looking for a nice friendly ‘way in’ to economics, I can recommend The User’s Guide without reservation. I look forward to checking out Chang’s other books.

We can circle the drain on this a bit, I suppose: Physicists may study because they want to enable the creation of new technologies or improvement of existing ones, which will of course affect the world. For example they might make a discovery that may improve the efficiency of wind turbine technology, an act that has implications for the energy industry and everyone who ever uses a lightbulb. ↩

Quiver Overview: Entity Components

08 Apr 2018

This post is the first in a series (hopefully) about the way Quiver, my homebrew game engine, currently works. Today I’ll be talking about the different kinds of components an entity (game object) can be made up of. Note that I’ll also be referring to something called ‘Quarrel’, which is a game I’m developing using the engine. All the code and assets for both Quiver and Quarrel are up on GitHub, so please feel free to nose around.

Quiver makes use of the Component pattern, which is described well in Game Programming Patterns. A quick summary would be: instead of having a monolithic entity class, the entity class is just a container for instances of different ‘component’ classes. The component classes implement the logic and store state for different domains, like graphics and physics. If you proceed down the Entity-Component path you might end up in the territory of what’s known as the Entity-Component-System paradigm, in which Entities are made up of Components which interface with/are controlled by Systems. Eventually, the Entity doesn’t exist at all – you just have IDs. However far you go, the motivation is the same: to use composition over inheritance, and design in a more data-oriented and multithreading-friendly way.

Quiver exists somewhere on the spectrum between the monolithic entity paradigm and the full-blown ECS paradigm. The Entity class owns a handful of instances of different Component classes, which are each responsible for representing the Entity in different domains, communicating with different game subsystems, and giving the Entity some state or behaviour.

Here is Quiver’s Entity class, with everything but the member variables trimmed out:

class Entity final {
	World& mWorld;
	
	EntityId mId;

	std::unique_ptr<PhysicsComponent> mPhysicsComponent;
	std::unique_ptr<RenderComponent>  mRenderComponent;	
	std::unique_ptr<AudioComponent>   mAudioComponent;
	std::unique_ptr<CustomComponent>  mCustomComponent;
};

It stores a reference to the World it is a part of. The World class represents a ‘room’ or ‘level’. It owns all the Entities, who are addressable using an EntityId. The Entity also knows its own ID. Then it has owning pointers to its components, accessible to others in raw pointer form through getter methods. None of the Components are mandatory apart from the PhysicsComponent (which I am planning to make optional). All of them inherit from the Component class, which looks like this:

class Component {
public:
	explicit Component(Entity& entity) : mEntity(entity) {}

	virtual ~Component() {}

	Entity& GetEntity() const { return mEntity; }

private:
	Entity& mEntity;
};

So all Components store a reference to the Entity they’re a part of. If a RenderComponent wants to talk to the PhysicsComponent it does so like this:

PhysicsComponent* physics = GetEntity().GetPhysics();

The Game Programming Patterns chapter describes a bunch of other ways that entity components can communicate with each other, but simply allowing them to call methods on each other is good enough for now, and far, far easier than implementing e.g. some kind of event system.

Physics Component

This one owns and manages the Entity’s physical body. If you want to push the Entity around, or change what things it collides with, you talk to its PhysicsComponent.

Render Component

This one is responsible for updating the Entity’s visual representation. Its API contains methods for changing the Entity’s colour, texture, and talking to the animation system. I might rename it to ‘GraphicsComponent’.

Audio Component

This one is a bit of a stub at the moment as I haven’t had a reason to develop it much, but as you’d expect it manages any sounds the Entity might be making. For example: enemies in Quarrel make a noise when they shoot, so the AudioComponent does that.

Custom Component

This is where the engine code allows game programmers to inject behaviour into Entities. Want an Entity to move around on its own? Write a class that inherits from CustomComponent, override the OnStep method to make it do what you want, then attach an instance of your new class to the Entity as its CustomComponent. I want to make it possible to have more than one CustomComponent on an Entity at once, but I’m managing to work around the restriction at the moment in Quarrel so there’s no rush.

And that’s it for this quick introduction. I’ll probably go into more detail on each Component type in future blog posts, but for now you at least have a basic understanding of what a game object looks like in Quiver.