Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[CraigStern]

Oooh, nice. I like it! (Also, I can see why you'd think there's a relation--this has a somewhat similar sound to the Ghost Waltz.)

[bugfartboy]

-- new special character, the double-semicolon (;;)! When this character is detected in text, the game swaps in a comma. This allows you to use commas in your script action parameters without totally screwing things up! (The game uses actual commas to delimit script action parameters--using the double-semicolon in script action parameters allows you to sidestep this effect.)

I have my guesses, but I'm curious how you're handling parameters internally, and what the processing order is. At what point in the process of reading/handling the XML node do you do your string substitution? Is it just once, or do you cycle through until nothing else can be replaced?


Is the new engine unicode-friendly? That is, if I type a '•' (U+2022) or a '≸' (U+2279) into one of the files, will it render correctly in-game? If yes, what's the likelihood of getting support for inserting the actual code for a character, such as "•" "•" "•" for a bullet point, and handing it off to be converted+replaced with the appropriate character?

[CraigStern]

Oooh, this is a complex question to answer! Text processing for most* special characters happens long after the XML parsing process is through; it happens right before the text is displayed or used, so that script actions in the same scene, conversation, or even the same dialogue branch can alter the values that certain special characters stand in for.

The order of special character swapping, as it now stands, is basically: (1) -NL-, (2) values reflecting the general game state that cannot affect, but which can be used to set or check custom variables (-SCENE-, -DAYSPASSED-, -AURA-, etc.), (3) number-getters (LASTINLIST[] and RANGE[]), (4) ID[], (5) custom variables (-VAL:-, then -STR:-, then LIST{}), (6) PICK{}, (7) BRANCH[], (8) all the triggering unit properties (-ARMY-, -Y-, -X-, -NAME-, -CLASS-, heshe/himer/hiser, etc.), (9) all the "CHAR2" secondary unit properties (for dialogue that triggers relative to a second character), and finally (10) basic character substitutions (**, --, and ;;).

Based on my testing, that order tends to work quite well. (Having the double-hyphen last is particularly important in order to avoid problems processing multiple special characters in a row, like -NL--NL-.) There's no cycling at the moment; it just does a single pass-through. I have yet to encounter a situation that requires more than one pass-through to work, though I'm sure one must exist. I'll make the necessary changes if I ever run into it.

...oh, and about Unicode: getting Unicode characters to work in Unity at all is kind of a process, unfortunately, so probably not. However, your question has inspired me to add support for a couple more ASCII characters I can foresee people wanting to use, so hopefully that'll do.


* procedurally generated dialogue in the engine has its own, largely distinct set of special characters, swapped at the time the dialogue is generated. This occurs much earlier on than swapping for special characters elsewhere in the engine, as proc gen special characters refer to values internal to the character being generated rather than current game state or custom variable values. I mostly haven't discussed proc gen special characters, so if you see me talking about special characters, 99% chance is that it's the normal kind.

[bugfartboy]

Thanks for the write-up! It's a bit more complicated than I expected, but I can't claim to have written anything as involved or complicated as a game engine.

...oh, and about Unicode: getting Unicode characters to work in Unity at all is kind of a process, unfortunately, so probably not. However, your question has inspired me to add support for a couple more ASCII characters I can foresee people wanting to use, so hopefully that'll do.

That's a bit of a bummer, but understandable. I'm glad we got a couple of new characters out of it!

-- a fun new feature I threw into the game: skills can now have scripts attached to them via the runsScripts attribute, just like items!

When used, a skill with runsScripts on it will run each script once for each target that the skill hits. (For purposes of special characters in skill-initiated scripts, the game will treat the attacker as the triggering character, and each individual unit hit by the attack as though it is the secondary character.)

This is more of a statement than a question, but this feature makes me inordinately happy. I'm having flashbacks of desperately logging what abilities the player has selected by using the OnAttackSelect trigger, just trying to activate specific scripts based on the character and ability the player had selected, to no absolutely no avail. I don't even remember what I was trying to accomplish (was it really years ago already?), just that I couldn't feasibly make it work.


How does the future look for custom status effects, possibly using scripts for custom behavior?

[CraigStern]

Custom status effects are something I started working on at one point, but that kinda fell by the wayside due to the sheer number of other, more essential things that have to get done.

Adding skill scripts was kind of a diversion; for the most part, what I'm trying to do now is polish what's in the game as much as possible (and on the modding end, make the existing tools as user-friendly as possible) in the interests of getting a vertical slice together. Adding in a zillion features with insufficient polish was a pitfall I fell into with Telepath Tactics, and I'm trying not to repeat the error!

[ArtDrake]

This is a bit of a broad question, but -- do you have a "guiding principle" or "personal rule" for deciding which aspects of your engine should be baked in / hard-coded, versus more modular in anticipation of modding?

An example would be status effects; it's not obvious to me whether the "right" thing to do would be to simply have a fixed number of status effects that appear in the game, and make sure that there're enough of them that their ability to model effects that modders might desire isn't too limited... or to lay down the framework for making more of them. You mentioned recently that objects are immune to mental statuses. It seems like one approach would be to explicitly list the statuses they're immune to, while another would be to give statuses "tags" like "MENTAL" or "SENSORY" or "ELEMENTAL", make objects immune to anything with the "MENTAL" tag, and let modders make their own statuses and tag them appropriately.

[This isn't, like, a suggestion or anything -- I'm just trying to give a decent example of the kind of difference in approach I'm getting at.]

In some sense it feels like a question of "where do you draw the line, when it comes to modularity?". The answer I've gone with so far in my own little projects is "when it becomes a headache", for lack of a more coherent principle, but that feels a bit... primitive.

[CraigStern]

My approach is pretty holistic; I basically just weigh three factors: (1) how essential is the feature to the task of being able to create a lot of different stories and scenarios in a campaign; (2) how much demand is there for it; and (3) how much of a pain in the ass will it be for me to implement? Even when I do decide to make something moddable, though, I usually start off with the feature hard-coded anyway just to make it quicker and easier for me to implement the mechanics which revolve around it.

[ArtDrake]

Before I ask a rather specific question about the AI logic in your new engine: is there a thread or a Q&A out there somewhere where you talk about your AI in depth that I should look for first, rather than ask you things here for fear you might've covered them elsewhere? Or are questions on that topic fair game?

[CraigStern]

I don't believe I've covered the AI anywhere in depth yet, so ask away!

[ArtDrake]

So, what I was wondering was: does the AI across a team act in coordination, or are each unit's decisions made individually/independently, albeit perhaps with their role within the team in mind?

It occurs to me that if, for instance, each individual unit that has yet to move considers its options in parallel, and then the unit with the best option of all of them is picked as the next to move, and executes that action (and then everyone else recalculates), that's a sort of coordination where the "best man for the job" gets used, even if the algorithm used to weigh each individual unit's options has only that unit really in mind (though that might not be what your algorithm does!). Just, considering all possible action orders within an army seems O(n!) complex with n the army size (and thus presumably infeasible, in general!), so my assumption would be that there's a greedy algorithm at work in making the turn order choice, instead.

Also, a question in a very different direction: does your AI code, when evaluating the merit of the different courses of action, make explicit use of parallelization to speed up the decisionmaking (on machines that allow for it)? I don't know how good the support for parallelization/multithreading is in the language / environment you're working in; most of my personal experiences with it have been low-level and hardware-specific, which is obviously no good for a game that's shipping to a wide variety of machines.

[CraigStern]

At present, the AI considers the moves available for any given unit in isolation, only considering its teammates if a given unit is badly injured and there's a healer on the team they can make a beeline for. There are two basic modes it uses: the "classic" Telepath Tactics mode, where turn order is simply randomized and each unit calculates its move only after the previous unit has gone, and the newer parallel mode which operates pretty much exactly as you describe here:

each individual unit that has yet to move considers its options in parallel, and then the unit with the best option of all of them is picked as the next to move, and executes that action (and then everyone else recalculates)... [and] the algorithm used to weigh each individual unit's options has only that unit really in mind

For obvious reasons, "classic" mode is preferred when the AI is in command of a large army whose members are not set to passive mode.

As for your second question: I'm not really familiar with Unity's support for parallelization/multithreading, so if the engine doesn't do it automatically, then at this moment in time, it simply doesn't happen at all. Instead, I mask much of the time needed to calculate the AI team's moves by calculating them asynchronously while the "Enemy Turn!" notification remains onscreen. (Although moves need to be recalculated after each character goes, some of the initial calculations--for instance, scoring each unit on the field in terms of its target value--only need to happen once, so the subsequent recalculations are faster.)

[ArtDrake]

I want to be careful with questions like this, because it's easy to come across as demanding something or creating an expectation when it really is just a question, but--

I was wondering, what kinds of control schemes do you plan on supporting with the new engine? Mouse only, keyboard only, hybrid mouse/keyboard? [I'd ask about custom keybinds, too, but that strikes me as the sort of thing it's a bit simpler to throw in once you have keyboard controls, whereas the ones I asked about are things that I would imagine UI gets built around.]

[CraigStern]

As of right now, the controls are very similar to Telepath Tactics, in that there is a mouse-driven interface with keyboard hotkeys that can be used in their place for most (though not all) things. (I have not yet implemented click-and-drag camera panning in combat, however, and instead currently have a "leave the mouse at the edge of the screen for a second to pan" solution.)

The biggest thing I want to add to the controls that I simply haven't had time to implement yet is gamepad support. Custom keybinds are possible, but a much lower priority for me at the moment.