Sign in to follow this  
  • entries
    72
  • comments
    104
  • views
    45399

Life is good.

Sign in to follow this  

169 views

Ok I haven't posted for some time (one month to the day) so here's a recap of what I've been busying myself with.

On the boring side I've had to do some farming for that money-resource which pays the bills, at the expense of part of my soul. No however I have a few weeks off from it all, no school, no work, just game development, some catching up with myself and later a hiking trip to the south peak of Kebnekaise (2100 meters above sea level, whatever that is in sock-wrapped units you can tell me).

Life is good. [smile]

I've spent a few days working on Citizen's entity system, and fixed it up so that entities can have child entities attached to them, forming a tree instead of a flat list. The conceptual motivation for this follows from the problem that components are properties and not objects and as such can't have individual positions within their entity. They share data with the entity and the other attached components; one position, one velocity, one mass, etc. So if I want to place a particle emitter or a gun at the wing of an enemy ship this have to be a separate entity since it has an offset position. Here it makes sense to make it a child entity which is geometrically local to the parent, with a transform hierarchy to resolve its world position.

This is now done and working.

The system is not difficult, but I probably rewrote the tree organization code five times before I was satisfied with how it was designed. I probably couldn't have avoided this since the design issues didn't show up until I tried it. The idea is that the parent entities don't create or destroy their children. This has to be done by the entity manager in order to register and unregister them properly with the component managers. Anyway after some hard beating it now runs like clockwork.

Then I did another three rewrites of the geometry code. I was originally convinced I should do it with transform matrices "because that's how it's always done". I hadn't really thought that one through. When I was almost finished I realized it was stupid since I wanted to convert back to position vectors and angles anyway to input into the sprite drawing system. The matrices went out the window and it all got much cleaner inside. I'm glad I don't have a deadline.

The pretty picture shows some children entities attached to the corners of the usual drone contraptions.


Sign in to follow this  


2 Comments


Recommended Comments

Ah! I hadn't thought of the tree structure, offset designs and such for a while, definitely since I wrote my component system (which I detailed to you.)

*starts scribbling furiously* Yes, this will be cool. Now, instead of convoluted garbage collection on my Marbles, They can just percolate upwards until their handled or hit the root, at which point a warning gets logged and it gets deleted. In light of this image I might rename my "Marbles" to "Bubbles".

(This isn't going to make sense to a lot of people since it relies on information I shared with Staaf elsewhere. However, if you're interested, I have a writeup on it. Just email me at QRebound@gmail.com)

Share this comment


Link to comment
The only downside I've found so far with the tree organizaton is that it doesen't allow for as fast searching for entities as a list does (or rather a data structure organized for fast searching like a map or hash_map.) However I plan to remedy this with some caching scheme for previously located entities.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now