Noxico

Since I’ve listed Motor.Hunt, I might as well elaborate on that one a bit. Any hostile character with a non-null Target (a token because why bother serializing yet another property) checks for the target’s distance and visibility as long as they’re not in Hunt mode. Once detected, they switch. Presence may be ignored if they’re… shall we say, otherwise occupied, in any way really, and “hostile” includes when they’re not out for the target’s blood as much as something else entirely. During the hunt, their reasons for hunting might change, which is why what happens when they catch their target is decided upon at that time. Perhaps they originally went after the target to kill, but got all worked up for whatever reason along the way, so when they get there, they try to screw the target instead.

Man, imagine that happening in the Dungeons of Doom or whatever XD

Sexytimes object
Pros: presentation, encapsulation
Cons: serialization

Motor property
Pros: extendibility, in more than one way
Cons: presentation

With a Sexytimes object, a couple can be presented as a single tile, flashing between two participants with a <3 inbetween, like stacked characters in DF. Everything about it can be kept separate from the whole. But Sexytimes requires more trouble in serialization.

With a motor property, a couple can be presented as a single tile only if one occupies the same tile as the other, and they can’t flash between the two of them. On the other hand, the motor property is already serialized and the exact state can be done as tokens. Also, there is theoretically no limit on the amount of participants: a female character can be taken from behind as she gives head to a third person if we’re careful about tracking what each participant is up to. If this is done on the individual body part level, having multiple genitals on a single body becomes somewhat easier as we no longer have to write special Sexytimes states for it.

The motor property would be a rename of and extension to the Movement property, enum MoveMode:

public enum MoveMode { Stand, Wander, WanderSector }
public enum Motor { Stand, Wander, WanderSector, Hunt, Sexytimes, ...}

Yes, items can have per-instance colors. If there’s a color token on the item instance, any reference to color in the blueprint is replaced with it. If there isn’t the reference is removed. Therefore, a plain black shirt or red lacy panties. There’s a couple of grammatical variations on it, too: a plain [color ]shirt, but there’s also [color], [color, ], and [, color]. And adding more is easy as falling down the stairs.

Which reminds me, I haven’t gotten the color tag in for the actual descriptions yet…

Instead of defining a default set of clothes per body plan, which would limit things to just one default costume worn and the rest carried along to probably never be used, you can define costumes in a separate part of the Noxico XML data and refer to several of them in the body plans. One will be picked out on generation, its component parts filtered out on physical feasibility (no pants if you’re not bipedal for instance) and even then there’s some degree of randomness available. For example, you could have the system pick between plain and lacy underwear (you know, for the ladies), even though those come in two parts. And since recently, you can also predetermine up to a hundred random tokens, which can be used very nicely for color coordination. So not only will both parts of underwear be the same style, but they’ll also have matching colors!

This does of course go for more than just undies.

Roguebasin has an interesting article on Dijkstra maps that might help in speeding up hostile creatures’ hunting.

I placed a single NPC on the board, on the other side of the screen, and discovered that the crappy pathfinder I had written earlier was a bigger bottleneck than I expected. Which to be honest was indeed to be expected from a very cheap attempt at a Dijkstra-style system. I had originally written it to facilitate rightclicking on the board to automatically travel to that spot, and even then crossing the entire screen would lock the game up for a couple of seconds.

To get a Dijkstra map, you start with an integer array representing your map, with some set of goal cells set to zero and all the rest set to a very high number. Iterate through the map’s “floor” cells – skip the impassable wall cells. If any floor tile has a value that is at least 2 greater than its lowest-value floor neighbor, set it to be exactly 1 greater than its lowest value neighbor. Repeat until no changes are made. The resulting grid of numbers represents the number of steps that it will take to get from any given tile to the nearest goal.

In contrast with this stupidly elegant concept, my current system is so bad I’m not gonna bother describing it in anything other than SBAHJ terms.

To hunt for the player, a shared Dijkstra map would be perfectly suited. One character going after the player, having to recalculate the map every time the player moves, was okay if I limited the hunting range to about ten tiles, but imagine having a room full of them! Therefore, I’m considering using shared Dijkstra maps for hunting targets. If the target (which does not need to be the player) moves, the Dijkstra map associated with that target is updated. The map is stored as part of the target and never saved. Since Noxico is realtime, if the target stands still all the hunters can use the same map with no recalculation delays. Perhaps a “being hunted” flag could be added so the hunters’ own maps don’t get updated without due cause…

And if the new pathfinding map generator is less conksuck than what I have now, it can be used for rightclick travel too.

> Shadowcasting in C#, part 1.

I couldn’t make heads or tails of the Roguebasin articles myself, so let’s see if you can!

Going to use this as development material for stat-enhancement and calling unidentified items by other names. “Cheap piece of shit” is actually the identified name for this item – the alternative is just “broken sword”.

Thinking back, I might just remove the dictionary and go with a classic name generator. Doesn’t mean there can’t still be a language barrier as described before, but just that names won’t translate like they can and are now.

You can now wield two different weapons and wear up to eight different rings.

In other news, whereas wearing a cursed pair of pants would prevent access to the underpants semi-permanently (it’s semi because the pants might be destroyed some way), a cursed skirt or similar garment has no such limitation because you can reach underneath.

Unrelatedly, I’ve been thinking about adding a graveyard to show records of earlier adventures. It doesn’t make much physical sense when you consider the world is rebuilt for every new game, but what with the blatantly non-Euclidian dungeons…

Not saying this is something that’ll be in the game, but if it were, here’s how I’d do it.

Given a certain speaking character and a spoken line, if the player does not know the language the speaker uses, the line could be replaced by a vague reinterpretation. For example…

“I am Caquot Seggunullung. Prepare to die!”

Depending on how much of Bloody Belchbutt’s language the player character understands, this could become “he says something you don’t understand, but it sounds threatening enough”, or maybe “he says something you don’t understand, but you believe it involves death, and probably yours”.

Basically, you can pick the overall tone from certain key words like “die”, and work from there. By the same token, you could have the reinterpretation mix up given directions.