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.

Pitch to BPM

02 Feb 2018

Before this blog, I had another blog, and another blog before that blog, and so on until the beginning of time. At the moment I’m trying to dig up the best stuff I put on those old sites and re-post it here. This serves two purposes:

Maybe some of this stuff is actually worth preserving.
I get to put off writing actual new posts for a bit longer.

So here is a post I wrote in university, re-hashed a bit but otherwise unchanged.

Preamble

When we were making the musical platformer AMPS, I had a problem to solve.

Objects in the game world use a song’s beat like a clock. The song is a group of FMOD Events which function as layers, all playing at once. We wanted to speed up the song and thus speed up the clock. The problem is that the FMOD::Event class¹ doesn’t provide a method for changing the speed of playback. It does, however, provide SetPitch and GetPitch functions.

FMOD increases the pitch of audio tracks without worrying about smart pitch-shifting (no, I don’t know what the technique to increase pitch independently of tempo is actually called), so that increasing the pitch doesn’t just make the song sound higher, it makes it sound like it’s being played faster. Imagine making a record play faster than the RPM it’s meant to be played at.

So we can just modify the pitch to make it play faster or slower, but how do we keep our game objects in time with the beat of the song?

Event::SetPitch and Event::GetPitch measure pitch as follows: a pitch of 0.0 is the base pitch of the audio sample. Nothing has been altered about it. A pitch of 1.0 means the pitch has been shifted up by one pitch unit, and -1.0 means it’s been shifted down by one pitch unit. Obviously.

What are “pitch units”? Semitones, tones or octaves. It depends what you pass to Event::SetPitch or Event::GetPitch as the second parameter. The options are FMOD_EVENT_PITCHUNITS_SEMITONES, FMOD_EVENT_PITCHUNITS_TONES, FMOD_EVENT_PITCHUNITS_OCTAVES. e.g.

event->setPitch(new_pitch, FMOD_EVENT_PITCHUNITS_SEMITONES);

I use semitones. There are 12 semitones in an octave, so the stuff below should be adaptable to not-using-semitones.

You need to know the base BPM (beats-per-minute) of the track you are pitch-shifting.

Here’s the general formula to pitch up from 0.0 semitones to n semitones:

new BPM = base BPM * (2 ^ (n / 12))

e.g. pitching up by a semitone…

105 bpm * (2 ^ (1 semitone / 12)) = 111.24 bpm.

…pitching down by a semitone:

105bpm * (2 ^ (-1 semitone / 12)) = 99.11 bpm.

Pitching up increases BPM more than pitching down decreases it, because pitch scales logarithmically.

Additionally…

We’re using a ‘song-based delta-time’ for updating game objects. Normally the delta-time would be the time since the last frame, but in this case it’s the amount of time the song has progressed since the last frame, so basically the same thing. To account for music going faster or slower, we make world go faster or slower by multiplying this delta-time by a variable equal to (new bpm / base bpm).

BPM to Pitch

Where m is the number you’re multiplying the base BPM by to get the new BPM:

new pitch-shift amount (in semitones) = 12 * (ln(m) / ln(2))
new pitch-shift amount (in octaves) = (ln(m) / ln(2))

Link dump:

We were using the FMOD Ex API, I think (?), but I can’t find a reference online to link to. There is, however, this article about the differences between that API and more recent versions of FMOD. ↩