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.

2018 Goals

05 Mar 2018

I set myself some goals at the beginning of this year. Now seems like a reasonably good time to reflect on why I’ve chosen them and how well I’m progressing with them. I want to figure out if they’re realistic and if they’re worthwhile. If they’re not, I want to figure out what I should change.

Let’s get down to it.

Read 20 Books

I’m not reading as voraciously as I once did, and I’d like to fix that by building my habit back up. Technical stuff (e.g. a book on how to approach certain programming problems) not included in the count as I don’t read those linearly.

Not including short stories and comics, I’ve read 3 novels so far, but I need to read 2 books per month to be on-track. I need to catch up!

My current book is Ursula Le Guin’s The Disposessed and am itching to read some of it whenever I get the chance, so it’s not that I lack motivation. The thing I lack is time.

Go Vegetarian

I’ve been sort-of vegetarian for a few years, avoiding meat and eating it as an occasional treat or when it’s the only option (e.g. at family meals). I’m curious to see what happens when I push the boat out.

I haven’t noticed the switch, to be quite honest. Life has continued much as before. I’ve eaten meat once because my brother invited me around for dinner and I forgot to tell him I’d gone fully veggie.

Learning Swedish

I’ve been learning Swedish using Duolingo for a couple of years now, and I’m still not a confident speaker or reader. Clearly, work is to be done.

Reach 100% fluency on Duolingo
Read some Swedish books
Hold conversations in Swedish without running away

I’ll manage this one.

Do Some Short Courses

Last year I enjoyed attending a couple of short courses run by Edinburgh University, and would quite like to do some more this year. I’m not sure if this will happen, but I’m okay to let it slide.

Post On Here Every Week

Posting makes me feel good, but I suck at getting on with it. This is another case where I just need to manage my time and focus much better. You know, it’s that simple…

Release Quarrel on itch.io

This is a big one, I hope not too big. There will be some small variety of enemies to shoot, some small number of levels, and some sort of story for people to complete.

Release Quiver 1.0

Another big one. Hopefully once I’ve released Quarrel I will be able to say ‘this is version 1 of Quiver’ and feel comfortable packaging a release up and inviting others to make games with it. If not, the release of Quarrel will still be a big milestone and a good point at which to start using some kind of versioning system (I guess SemVer?).

Make a Podcast

Me and Natalie have had this idea for a podcast in which we sort-of ‘Let’s Play’ our way through various Choose-Your-Own-Adventure books such as Fighting Fantasy classics like Deathtrap Dungeon and Citadel of Chaos. To make this achievable, I minimized the requirements:

5 episodes
Each about 30 minutes long
Released when we get them done rather than on a schedule

Natalie, we need to work on this!

Miniatures!

Finish assembling and painting my miniatures pile o’ shame. Then I can get new ones! And paint those! I have no worries about this one. If there’s something I reliably find myself wanting to be doing, it’s hobbying.

This year’s going to be a very busy one professionally and personally, so I fully expect a few of these to slip (even more, in some cases). We’ll check back in June.

ChillJam

13 Feb 2018

On Saturday I attended Edinburgh Uni Game Dev Society’s ChillJam, a one-day game jam with a relaxed atmosphere. I teamed up with Norgg to make a little game about making a cup of tea.

You can play it here.

It’s very broken, as you’d expect for something made in about 9 hours, but I’m quite pleased with how it turned out. I really like the idea, too – I think it would be lovely to someday make a webpage people can visit and simulate making a cup of tea (or some other kind of beverage!), filled with all kinds of nice, rich interactions. A warm, comforting place on the web.

If you’re curious, you can check out the Unity project source on GitHub. My favourite commit message is “Added steam integration”.

Also, Norgg’s daughter helped by drawing the pictures you can see on the mug and kettle, which was the sweetest thing ever.

Enormous thanks to the organizers of the jam for creating such a fantastic event and to all the other participants for sharing their amazing creativity. I am already looking forward to the next one!

Finally, you cannot drink the tea. Don’t worry about it.

Tutorial: Maya 2015 Plugin Development with Visual Studio

04 Feb 2018

Another resurrected old post, I’m afraid. Hopefully it is still useful to somebody.