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

-- added tab navigation to the dialogue editor (i.e. you can navigate between text input fields by tapping the Tab key). This makes working in the dialogue editor much faster.

-- when clicking a predictive text suggestion in the dialogue editor, the editor now auto-selects the parameters text field, allowing you to immediately start editing parameters without having to click into the parameters input field first.

-- added tab navigation to nearly every window in the map editor (i.e. you can navigate between text input fields by tapping the Tab key). This makes editing map, unit, or point light properties much faster.

-- when opening the procedurally generated unit window in the map editor, the editor now auto-selects the name text field, allowing you to immediately start editing properties without having to click into the input field first.

No time to make an April Fool's joke this year--too busy working on my very much for-real game!

-- updated the targeting reticles in battle to show the current affected stat for each target, just as with the reticles in Telepath Tactics. (But of course, these new ones use symbols instead of just text for greater readibility at a glance.)

-- pulled back the battle camera about 10% to provide an easier view of the whole battlefield.

-- added the RemoveSpawn script action into the game. As in Telepath Tactics, this action strips a unit's spawn data out of the battle, preventing it from spawning on a later turn--however, this action now has more parameters to allow precise targeting of the particular spawn to be removed. Parameters: (1) Load ID (using : in lieu of /), (2) Army Number (optional), (3) Y coordinate (optional), (4) X coordinate (optional), and (5) Spawn Turn (optional).

Optional parameters can be left blank or filled in with -1. If the Load ID doesn't matter, use -ANY-.

-- the game now saves any spawns removed during a battle in mid-battle saves, and upon reloading the battle, will reapply the spawn removal.

-- new special character: -CONV ID-. The game will replace the special character with the Conv ID of the current dialogue, if there is any. With this change, RemoveConv subsumes RemoveCurrConv.

-- if the MoveChar script action doesn't find the named character, it now simply does nothing instead of freezing up the game.

-- fixed: if there were characters in your army who came pre-spawned on the battlefield, you could select them, move them, and act with them as if it were a normal turn during unit deployment. Clicking on such a character during deployment now merely shows their move range as if they belonged to another army.

-- fixed the camera positioning for focusing on characters situated on elevated terrain.

-- the ForLoop action (discussed in the last post) is working!

-- scripted a new event type that occurs at the end of the evening instead of at the beginning.

-- created a new quasi-randomized battle for a late-night event in which the camp is attacked by thieves.

-- new script action: SetListEntry. This changes the value of an existing entry within an existing list at a specified position within the list. Three parameters: (1) List Name, (2) Entry Position, and (3) New Value or Operation.

You'll most likely be using SetListEntry in combination with ForLoop (and ToList actions) to quickly make batch changes to things. Here is an example (collapsed into a spoiler to save space):

Spoiler

I've created a battlefield representing the player's camp, with 18 tents dotted around the battlefield, each with an ID[] tag ranging from 101 to 118. However, I want there to only be one tent per character on the player's army--I want to remove each excess tent from the battlefield. Here's how I approach it:

Code: [Select]

<Action>UnitsToList/PlayerArmy,0</Action>
<Action>SetVal/StartAt,=,LASTINLIST[PlayerArmy]</Action>
<Action>SetVal/StartAt,+,1</Action>
<Action>SetList/RemoveTents</Action>
<Action>ForLoop/-A-,-VAL:StartAt--18,1,AddToList,RemoveTents,-A-</Action>
<Action>ForLoop/-A-,0-LASTINLIST[RemoveTents],1,SetListEntry,RemoveTents,-A-,+:100</Action>
<Action>ForLoop/-A-,0-LASTINLIST[RemoveTents],1,RemoveUnit,ID[LIST{RemoveTents,-A-}]</Action>
The first action gathers up every character in the player's army into a list; the second and third actions set a VAL equal to the size of that list. The fourth action creates a new list, RemoveTents, which will store the ID[] of every tent we intend to remove.

Then come the loops! Our first loop starts at the first number past our total army size, and counting up to 18, it creates a numbered list entry with each iteration. (If the map has 6 player characters, for instance, it'll fill the list with numbers 7 through 18.) The second loop goes through our newly populated RemoveTents list and adds 100 to each entry via SetListEntry. Lastly, our third and final loop goes through RemoveTents and removes each listed tent using its ID[] tag.

-- improved the positioning of animated bars during camp activities.

-- creating and removing units from the battlefield during OnLoaded dialogue no longer spawns smoke clouds.

-- fixed a bug in the game's attack mapping algorithm that could glitch the game out when finding attackable spots on long, skinny battle maps.

-- fixed: the game would immediately close any dialogue occurring on the cut scene frame immediately following camp activities.

-- fixed: the game's camera boundaries would prevent it from moving to focus on characters at the very top of the map during dialogue (as they would end up totally obscured by the dialogue box).

-- fixed: you could glitch out the game by generating a unit with only a first name.

Gave artist feedback on new cut scene backgrounds in progress for the Psy Academy and Somnus.

-- units now take damage from being shoved/thrown/kinetically gusted/etc. against the edge of a level.

-- for the map editor, created new Edit Unit and Edit Object modes so you can start editing unit and object properties without having to open (and then immediately close) the New Unit or New Object windows.

-- implemented the RemoveUnit script action, which replaces RemoveChar and KillChar. Takes two parameters: (1) unit name (or ID[]) and (2) whether to treat the removal as the unit dying (true or false -- if true, the unit's health will be automatically set to 0 before removal, they will drop an item sack, and death rules not dependent upon the amount of damage taken* will apply).

-- fixed: running multiple scripts at once with the same Run command would queue up their actions in the wrong order.

-- fixed: if under Permadeath rules, the death of a destructible object associated with an army would produce a morale loss among characters in that army as though it were a character.

-- fixed a really stupid typo in the map editor code that would prevent you from placing objects or characters on spaces with a y coordinate greater than the map's width.

-- started working on a unique script action: ForLoop. If you know programming, then you already know exactly what this does: it lets you set up a counter that runs a specified action a set number of times, with the ability to use the counter's value within the action itself. Parameters: (1) Integer Name (a string that must be a unique sequence of characters and cannot contain commas or forward slashes); (2) Integer Range (start and end values delimited by a hyphen, e.g. 0-5); (3) Increment By (the value added to the integer with each iteration of the loop); and (4+) simply type out the name and parameters of another action, delimiting each with a comma.

For instance:

Code: [Select]

ForLoop/-A-,1-3,1,SetVal,Number-A-,=:-A-
This will run SetVal three times, producing three custom values: Number1 with a value of 1, Number2 with a value of 2, and Number3 with a value of 3.

This one is still in progress, so there might be changes pending further testing.


* i.e. you'll still need to set wound levels or make the character lose morale yourself using SetStat

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.)

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.

-- updated the attack sequence panning-and-zooming code so that so that everything remains clearly visible onscreen even with attacks targeting far away for the attacker. The game pans closer to the target as the attack is targeted further away, and when targeted beyond 4 tiles away (as with super-long-range skills like Arced Shot), the camera now simply doesn't zoom in at all.

-- sick characters will no longer engage in forced group activities--they will instead rest.

-- busy characters will no longer engage in forced group activities.

-- wrote some new procedural character dialogue.

-- wrote a new camp event in which a character develops romantic interest in another character.

-- events that don't eat up time (like a character falling ill or developing a crush) no longer prevent the player from throwing a gathering.

-- in the AI, characters that can move after using a skill now weigh the danger of their destination space less heavily in direct proportion to the amount of steps they'll have left.

-- updated the sprite-set naming for premade Dark Spriggat units.

-- fixed: red spriggats were using the dark spriggats sprites for some reason.

-- fixed: the LASTINLIST[] special character could sometimes return a list length of -1.

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

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?

-- received new character portrait: Praetor Nero. Created his portrait data.

-- added the three cave entrance backgrounds into the game.

-- running out of food will now give all characters in camp a negative mood for 0-3 days.

-- moods can now be tied to specific character memories (meaning that the game can know why a character is in the mood it's in).

-- if a character has a sufficiently negative reaction to an ally's death, they now get a memory of that character's death as well as the mood "Mourning" for a number of days proportionate to the depth of their grief. The mood is tied to the memory.

-- if a character has a sufficiently negative reaction to an ally's dismissal, they now get a memory of that character's dismissal as well as the mood "Upset" for a number of days proportionate to the depth of their reaction. The mood is tied to the memory.

-- wrote more dismissal monologues for characters with different personality traits, as well as for golems and spirits.

-- fixed: the game wasn't increasing character movement after equipping items that boosted speed.