Category Archives: C++

hxE2 + Entity Systems

[Update 2016.01.26] hxE2 is now deprecated in favour of Eskimo. If someone wants to try and fix issues, sure why not, but I’m not actively using or maintaining this!

[Update] hxE2 has been released in Alpha status here. It corresponds to the topics and improvements to hxE mentioned in this post. All feedback and comments are welcome! :)

I like talking about Entity Systems. And unlike most things I’ve talked about on this website, I have actually finished several implementations of different ECS designs.

My first one was pretty much a port from the Artemis ECS, which I’ve mentioned before, called hxE. But this design was very limited. Each System could only process 1 type of entity, and because of this, it could over complicate simple tasks like checking the distance between “Item” entities and “Inventory” entities. Ideally I would have looped over all <Item, Transform> entities, and checked the distance between all <Inventory, Transform> entities. Simple. The System limit of 1 entity type meant I needed to have 2 systems processing each type of entity, as well as some sort of communication between those systems, or further, generalize the concept of collisions which means more components…etc. etc.

[For those that didn’t understand much about what I just wrote, I recommend reading through the T-Machine blog posts on entity systems. He brings up the core concepts of how they work, as well as addressing common questions.]

Summed up, my ideology is a complete separation of Data and Logic. Systems are logic, and Components are data. What this means is that most components are PODs (Plain Old Data) with no functions, except where they are only helper functions in processing the data of that component. A System can be considered as anything that does work on components, though I usually formalize this concept as a class in most of my engines, simply to provide a common interface/reduce work required to have it running in the engine.

Moving onwards from hxE’s design, my current entity systems have the entity filtering detached from the systems. So now a System is just an empty shell with some function hooks to override (onWorldAdded, onWorldRemoved, process(delta:Float) … ). This means that a system can take in as many entity types as it needs to:

var items = new View2(world, Transform, Item);
var inventories = new View2(world, Transform, Inventory);
for (item in items.entities)
for (inventory in inventories.entities)
{
     var item_transform = items.get1(item);
     var inventory_transform = inventories.get1(inventory);
     var dx = item_transform.x - inventory_transform.x;
     var dy = item_transform.y - inventory_transform.y;
     if (dx * dx + dy * dy <= distance_to_pickup * distance_to_pickup) // add item to inventory and destroy item entity.
}
//var example = new View4(world, Transform, Mesh, Material, Input);

Not only does this make Systems much more flexible, but this also separates the concept of System, and a View into the World. At this point, System classes are helper classes rather than essential parts of the engine – a system can be anything the user wants it to be, interaction with the world is much more direct using Views.

Internally, things are setup to work well in a multithreaded environment. Each View holds a list of updates to process – once this point is made threadsafe, the rest of the interaction with the EntityWorld always happens through the View. This update pushing is also a slight concern for performance, but I will work on having performant, single threaded implementations at a later time if this happens impact projects more than I’m expecting it to.

Over the next few weeks I have a project that will be based on hxE2, and could be interesting to people using it. As I’m doing that, I’ll try to go into more details about specific parts of the hxE2 implementation, focusing on parts I get questions about etc., but for now, this is just a quick introductory post for hxE2 and my way of implementing an ECS!

Enjoi :)

P.

New stuff: NeuroPulse and Umbrak

Boy has it been a while. I have a habit of not having a habit of posting here. Lots has happened though, so I hope this will be a mildly interesting read!

First off, NeuroPulse! Me and my good friend Edib0y (that’s a zero) have been working on the prototype, and you can see what it looks like:

We have a Tumblr sort of going, but as NeuroPulse progresses, so will the blog. Important though, is the latest post, which is HERE. Read through that to get a better understanding of what NeuroPulse is and isn’t, and our hopes and plans for its future! I’ll post a few theory things and thoughts I have going on about it here, but mainly we’ll try to keep everything NeuroPulse related over there!

A bit of technical meat, NeuroPulse is based on the Ogre3d engine, using CEGUI as its GUI front-end, and an entity system as its game logic backbone. So far, everything is coming along pretty neat, though we’re in the middle of a big refactoring, which I should finish soon…but I’ve been sidetracked…

Which brings me to the mysterious name, Umbrak! 2 days ago I got the urge to make a small, little, quick, fast horror game, but as everyone who’s ever developed a game knows, that doesn’t happen. I started programming, dropped in my entity system, dropped in my screen system, but still a lot of the engine meat was incomplete. So I got started on that, but also wanted to focus as much as possible to make it easy for me to change things, add things, etc., and so I ended up with 2 fancy dev tools in the engine.

First thing I implemented was live asset reloading, which means that I can reload all dynamically loaded assets whenever. In the game engine, when it reloads graphics, it will replace those graphics as soon as they’re loaded, and so I can swap out graphics for new graphics without even restarting the level I’m testing, which should be really handy for artists who need to have that one thing look just right in that one spot. This has a ways to go in terms of optimizing the graphics, like baking all static assets onto a bitmapData, but so far so good!

Next thing I went to do was implement scripting! I used hscript, which is a scripting language for Haxe, and it looks like Haxe, and works like Haxe…so in my scripts I’m very free in what I can do, the only limit is I can’t declare new classes, and other things which are listed on the hscript gcode page. What does this mean? First off, I have a little console through which I call the asset reloading functions, world reloading, screen reloading, etc. etc.. I basically have everything accessible to me, and I plan to implement simple level editing capabilities too.

Then, I also use scripting for world initialization, as well as object creation. The world initialization declares object types, and the associated scripts it should use when finding such an object, and object scripts simply setup the entity with all the components. It has actually proven to be pretty useful and dynamic, since I can easily change the radius or brightness of a light, reload the level, and bam, see the changes applied! In fact, another thing I plan to do is make it so I can reload specific object scripts, so I don’t even need to reload a level to see changes applied to updated objects! Snazzy…

Oh, and why Umbrak? Well, I was thinking horror game, so naturally what came to mind was Penumbra. Which went to Umbra, and thought that sounded too simple so I added a “k”. Not sure if it’ll actually turn into something, but time will tell! Screenshots would be a bit pointless, since it’s basically my lighting engine patched together with NAPE physics, but if things get interesting, I’ll try and show something!

As always, if you happen to be reading this, and have a question, comment away! :)

P.

NeuroPulse! Working on the alpha.

So it’s been a long time.

I heard about Microsoft’s Imagine Cup (www.imaginecup.com), and me and a friend thought, “why not?”. So we picked up C++ and got down to it, and so far it’s been a really fun ride!

First the game idea, NeuroPulse. It’s an idea I had ages ago, but since we started thinking it through it’s changed a lot. You can think of it like a neural network simulator with an RTS built on top, or something like that. The basic idea is that there is an environment, and the way you do things is by working with the environment, and of course pushing the environment to do what you want it to do more. Nodes are the main objects in the game, where energy goes and they also emit pulses once their internal energy is over a certain threshold. Certain nodes have a reactor, so they constantly generate a small amount of energy. From this comes out a hopefully emergent behaviour of the whole system. You control nodes by building a hub on them. Around the hub you can build buildings that do stuff and modify incoming or outgoing pulses. The way you build on another node is by sending pulses with building instructions attached, to build a hub, and then afterwards you can just build more buildings easily. To capture an enemy node, you first need to overload the node, by sending lots and lots of energy. Each overload will damage all buildings on a node, until they’re destroyed, at which point you can send your build instructions to the node.

We’re using the Ogre3d engine for the display, and it has been a suuuper awesome ride with it! Really easy to set things up and get going, so we’re really happy with that. And now it’s all about tying in a GUI and some interaction with the whole system and stuff.

Next time I’ll try upping some screenshots!

P.