[ Login | Register ]

The Shining Source

« previous next »
Pages: [1] Print
Component based game entities   (Read 36557 times)
Old Post October 04, 2012, 08:32:26 pm
#1
Ty
Administrator
Shining Sideburns *

Posts: 836

Logged
Component based game entities
I've been working on a system for component based game entities for ages now, and I've gone through a lot of notes, papers and lectures on the concept. The basic idea is that instead of constructing objects through inheritance (e.g. GameObject Class -> Actor Class -> NPC Class) you create game objects from a bunch of components (e.g. BodyComponent, InventoryComponent etc).

I took this approach in one of my game jam entries (Ineptia), and it made adding new objects much easier. It also made it easier to add behaviour from one object to another.  For example, exploding crates have a BodyComponent (which contains their HP), TargetableComponent (so the player can target them), and then have an Inventory which lets the game know what to spawn when they 'splode.

At the moment I've settled on something based on this approach, where entities are just an identifier, components are dumb blocks of data and all the processing happens in "systems" that register themselves as processors for one or more components.

This way of doing things made me pretty uneasy at first, especially as code that operates on components is stored in a system rather than the component itself. However, one hurdle I kept bumping into when code was in components was "which bit of behaviour goes where?". For example, when a crate is destroyed, which component controls spawning particles? What about making the item within fly out?

The components = data, systems = behaviour model does make sense after a while, as a single piece of data in a component may effect behaviour in several different places. What you end up with is more of a database (entities + components) and a bunch of stuff that operates on it.

What I've got right now is a template system for storing entity compositions, which can then be spawned by name. For example, here's the (slightly outdated) template for a wooden sword:

Code:
/**
 * A simple wooden sword.
 */
[t:template,n:weapon_wooden_sword] {

doc = "Wooden Sword";
specializes = base_weapon;

equipment:attack = 3

[item]
{
display_name = "Wooden Sword";
icon = "demo_5.icons.weapons.wooden_sword";
description = "The most basic kind of sword.";
base_price = 75;
}


}

The "specializes" keyword allows a template to inherit data from another template. So the wooden sword inherits from "base_weapon", which inherits from "base_item" - that way defaults can be moved further up the template tree. The sword has two components: item (which holds things like the price, icon and name) and equipment, which holds equipment type, ranges, stat modifiers etc.

This approach makes spawning a little slower, but most of the heavy lifting can be done when templates are loaded and the template tree is processed. It also makes adding new weapons a heck of a lot quicker, and because it's all data it can be reloaded on the fly.

Like I said, there's still plenty of things that I want to fix, but I'll keep this updated as I figure things out and eventually split it into another article.

Here's a bunch of things to read:


As always, questions & comments are much appreciated Smiley


Old Post October 04, 2012, 09:14:13 pm
#2
Administrator
Shining Spammer *

Posts: 1,208

Logged
Re: Component based game entities
To be honest, I think that the templates should be far more minimalistic. Effort and man hours are the big limiting factor in non-profit games programming, so every character people have to type less in order to add an item will result in people being more eager to add items and more progress to be made.

I've tried in several places to minimize development effort in BABS by using tiny syntax or by using string substitution commands (e.g. by typing "[hi]" to throw in a fancy way to say hello). Of course people can also go the long way, but the short way speeds up development for them. (of course another one is the grid/brick pattern cheat buttons in the SMEE tile editor Smiley)

Perhaps I should write an article about that topic at some point Wink.

Devlyn

Great news for Shining fangame developers! Wink

Correcting your non-working <img> tags since 1982 Wink


Old Post October 04, 2012, 09:43:27 pm
#3
Ty
Administrator
Shining Sideburns *

Posts: 836

Logged
Re: Component based game entities
Yeah, it's a little more verbose than I would have liked, but it's very flexible so I guess that's the price you pay. Every object in the game, from inventory items (medical herbs, potions) to triggers (touch triggers, inspect triggers) is built with this method which is pretty nice. But hey, at least I didn't use XML this time Wink

Inheritance cuts down on a lot of typing, and tere's a couple of of other shortcuts you can take, such as using a component: prefix rather than a [component] block. E.g.

Code:
// Long syntax
[item]
{
    base_price = 160;
    icon = "demo5.icons.weapons.wooden_sword";
}

// Short syntax
item:base_price = 160;
item:icon = "demo5.icons.weapons.wooden_sword";

Although I guess that actually adds more keystrokes - so an article on taking sane shortcuts would help someone like me who can't stop typing Wink

I haven't found them too time-consuming to make, and it's usually just a case of copy-paste and changing a few values. Perhaps adding 100 weapons could get a bit tedious, but then I'd probably cheat and write a tool to either generate them automatically or translate a CSV into a template file format.


Old Post October 05, 2012, 08:52:20 pm
#4
Blahian *

Posts: 8

Logged
Re: Component based game entities
I'm checking out all the stuff you linked. It looks like good stuff so far. I'm a big dungeon siege fan, so reading those articles was fun. I'll post again when I have a more coherent opinion.


Old Post October 07, 2012, 02:07:25 pm
#5
Blahian *

Posts: 8

Logged
Re: Component based game entities
I've been out of commission the last couple days with food poisoning, but after having read all the articles you posted, I like the idea of entity systems very much. Since I was going to use a database anyway, I probably would have been using an entity system without much of a system. I think this is a valuable design model and I'm surprised I've never seen it before.

Good stuff!


Old Post October 09, 2012, 02:56:51 pm
#6
Ty
Administrator
Shining Sideburns *

Posts: 836

Logged
Re: Component based game entities
Ouch, food poisoning is not pleasant Sad

I've worked with component based entities before, but never in the way outlined here (with components and systems). It takes a little more work, but the system-based approach makes sense to me as object behaviour isn't always mapped 1-to-1 with the data.

I'm still working on things, but hopefully I'll get some time this week to experiment with adding some interactive entities.


New Post September 25, 2013, 05:58:11 pm
#7
Ty
Administrator
Shining Sideburns *

Posts: 836

Logged
Re: Component based game entities
Just updating my notes here - one of these days I'll get around to writing an article (or book) on all of this.

It turned out to be surprisingly easy to switch to an entity/system approach. The current version of the engine only has two systems running:

  • ActorSystem -- This takes care of any entity with a "body" component, and updates their movement depending on what's in their movement queue.
  • PlayerSystem -- Handles moving the player. Works in tandem with the ActorSystem, so it sets the "player" to moving and the ActorSystem handles the actual movement.

It's worked out really well so far, and once I got over the initial overhead of figuring things out it made life much easier. Admittedly none of what I've done so far is particularly complex, but the more I work on it the more I like it. Which is a good thing when a project takes this long Wink


Pages: [1] Print 
« previous next »
Jump to:  

Powered by SMF 1.1.21 | SMF © 2013, Simple Machines