Mutators

[Emdek]

Yes, engine in C++, game logic as scripts.

[aubergine]

So, I've spent all evening wading through C++ code and it looks like huge amounts could be ported over to much cleaner JS, performing massive de-crufting in the process.

For example, there is a mass of code just to deal with the various ways droids can die - recycling, crashed transport, blown up, off-world, etc. Most of that could be shrunk down to one clean function that just gets told why the droid is disappearing so it can do a couple of things slightly different internally.

There's also a herd of functions to handle the plethora of ways droids can be repaired, how they get to where they are repaired, etc. Again, huge scope for condensing all that down to much smaller amount of JS code.

I'm also seeing that there's a bunch of code that gets run regularly yet the return value could be cached as it will never change for a given droid. For example, if there is some code to determine the droidType then it's safe to say that droid will always be that droidType so the result can be cached and the more complex droidType determination code bypassed on future requests. And, should something get added to game that allows droidType to be changed, eg. ability to retrofit droids at a factory or something, then that could just clear the droidType cache for the droid so that the next check will call the determination code again, but then cache the new value.

Also, I found some amusing function names, for example:

DROID *reallyBuildDroid(DROID_TEMPLATE *pTemplate, Position pos, UDWORD player, bool onMission, Rotation rot)

LOL, I'm expecting to find a "pretendToBuildDroid" or "buildDroidHaHaILied" function somewhere soon.

[Emdek]

Some of the cruft are remains of unfinished or removed features, like units upgrading themselves when researching new technologies, AFAIR.

[aubergine]

Yup. And such cruft can be removed and added in again later if needed.

Oh, and I'm pretty close to having some code that will trigger events (but only if something is listening for the event) whenever anything changes on a droid

[Emdek]

Nice, events would be rough equivalent of actions (depends which form would be more efficient from performance point of view).

[aubergine]

actions as in DACTION? if so, once an action is complete then an event would be triggered. means that instead of constant polling to check what is going on, things can just listen to events and be told when they need to do something.

[Emdek]

No, as actions in WordPress nomenclature.

[aubergine]

Ah, well, not sure yet. Events could trigger actions. I'm still playing round with various approaches.

In a moment of insanity, I've now started creating a JS object to represent the map Why do I set myself all this work?!

What I'm looking at is a way to see if we can massively reduce the overheads associated with things like sensors, namely by making pretty much everything event driven! For example, if the map is split in to tiles, 4 tiles = quadrant, 4 quadrants = sector, then things can listen to the map for events at various levels of resolution. For example, a sensor can "listen" to quadrants it can see (and a few specific tiles for anti-aliasing heh) then when an object moves in to that area of the map, which triggers an event, the sensor will hear about it.

Is this enough to certify me as insane?

Also, I've been coming up with some interesting properties on game objects (I've ditched the idea of having different classes for droid vs. structure vs. feature!)...

Code: Select all

    .has{}      // system labels (eg. obj.has.weapon, obj.has.ECM, obj.has.CB, obj.has.leprosy)
    .can{}      // ability labels (eg. obj.can.hitAir, obj.can.transportDroids, obj.can.boogieWoogie)
    .is{}       // effect labels (eg. obj.is.burining, obj.is.smoking, obj.is.awesome, etc)
    .tag{}      // custom labels (use "obj.tag.whatever = true" to set, "delete obj.tag.whatever" to remove)

EDIT: We totally need weak map support in the JS environment - it will make a MASSIVE difference!

EDIT #2: We also need proxies in the JS environment too. I really hope the V8 stuff lands soon!

[Emdek]

Haha, sorry for "infecting" you with that idea, it is obviously taking you over.

For maps, why not, we would need to check what is better (as for performance), lots of events (possibly wasted when nobody listens too - I'm not sure how exactly they do implement that, but generating events must have some cost) or only polling when needed (or maybe first check if someone actually listens to an event before generating it?).

[aubergine]

There's no waste when nobody is listening, because:

Code: Select all

if ("eventName" in thing) { // <--- that's very fast
  thing.eventName(args); // <--- only happens if someone is listening
}

In other words, the event isn't even triggered if nothing is listening Although I'll need to create a special version of uTardis (or I believe more recent ECMA-262 implementations have proper stuff in for doing events?) to make sure that if there was something listening and it stops then the event handler is completely removed.

[aubergine]

Any idea when JS features like proxies and weak maps might make an appearance?

Weak maps are needed to help with GC, and proxies are needed for quickly exposing game objects to player (AI / Bolo scripts) with relevant permissions set.

[Emdek]

I doubt that there will be any changes before Qt5.

[aubergine]

So, I'm happy to wait for Qt5, but do you know how much of the recent ECMA-262 stuff would be implemented in it?

The only thing that I've not yet got my head round with the recent ECMA-262 stuff is Array Comprehensions, they are mad as a hat full of weasels.

[Emdek]

Not really, you would need to check their repository probably.

[aubergine]

The docu makes no sense to me, I'm not going to get very far with their repo heh.

OMG, just found that if you send VTOLs home on a transport while on an off-world mission, they get repaired and rearmed!