Archives March 2021

SolOTility #3 – Beta

In the previous post I wrote regarding SolOTility I mentioned that I expected to be able to release a beta-ish-version of this program within a week’s time. Needless to say I misjudged the time estimate, alot of time this week has been spent working on Demox, and on top of that I found some bugs in SolOTility that needed to be fixed before releasing the first version aswell as some new features that were added!

Appending Images to Work Items

I’ve added functionality to append images to work items within the user’s solution. It can be either added manually by writing the filepath to the image within tags ( eg. <img>C:\Program\SomeDir\myImg.png</img> ) or by clicking the “Add Image” button in the Item Editor, which will auto-generate the previous code.

There’s also been alot of fixes for the Item Editor, most in order to make it a little more user-friendly and help the user avoid making wrong decisions by mistake. (Such as closing items without saving changes, etc. )

The new appearance of Solution Catalogs and Items in the Item List

Solution Interim Goals

I added a feature to allow the user to set up their own interim goals, it’ll be useful in cases if the user would like to keep track of progress of the project, a specific build or of a group of work items.

It’s a quite simple system, the interim goals are set up to compare the amount of closed items ( completed, obsolete & deprecated ) against other items ( inactive, active, prioritized ). When all specified items are closed the interim goal is completed.

The user can currently set up interim goals to either track items with a specific build name or items with a specific item tag.

Example of an image appended to a work item’s content.

Work item control’s appearance has been updated to make it easier to identify item type, and the catalogs shown in the Solution Outliner panel are now color-coded aswell. The Dashboard is colored red, Navigator nodes are colored blue and common catalogs use one of four available green colors. ( The green color is shifted depending on at what level within the catalog node tree a catalog is placed. )

Another minor change, Mindmap Editor is opened in Full-screen mode.
The Project Overview screen, displaying all user-created interim goals and solution progress.

Last but not least, another widget was added called “Message Board”. The message board will display the most recent messages or comments that have been left in an item, the idea is to have these messages act as a reminder.

All that remains before I upload a beta release now is to figure out how to create a setup / installer file. I’ve created such files before but all of them have been sort of broken in one way or the other, so this time I was thinking that I probably should do some research and get things right for once .__.’

And before we part ways, don’t forget to follow me on @Twitter for more news, artwork and whatnot!

Demox AI #1


So to start things off, let’s go through my primary goals for the AI in Demox.


DPM, or “Decisions per Minute” is a simple AI behaviour system I put together for Loot Burn Kill Repeat, which I have continued to build upon for Demox aswell! The name comes from a property field I’ve assigned to the AI character code that determine how many times per minute the AI avatar will calculate a new decision, I guess a less confusing name for it would be “Intelligence”… but… err, yeah!

Worth to note is that despite the AI calculating a decision at regular intervals, the process won’t always end with the AI actually deciding or changing any current actions, since the decision is controlled by multiple aspects concerning the current situation of the AI. I’ve improved the AI’s situational awareness and the DPM system extensively for Demox, compared to what I had in LBKR. Among other things, the AI will check it’s own status,

A check will also be done for the AI’s party members, to determine how many are wounded, escaped combat, have been killed and how scattered the party members are on the battlefield. These are the primary things that are impacting the decision, furthermore, each decision behaviour have tailor-made awareness checks.

AI triggering an alarm, decided with the AI decision behaviour system.

To describe what these “decision behaviours” are, they are basicly instructions for the AI how to determine if the behaviour should be used, aswell as how it is to be executed by the AI. The instructions include simple things like escaping combat, changing target, changing position during combat aswell as more complicated tasks such as triggering traps and alarms, or aiding party members.


When improving the AI awareness there were, as with everything else, some issues to solve, first and foremost- how would I make the AI select the most appropriate action? This morphed my old DPM system into what I now call DPBS, or Decision Point Behaviour System. And yes, again, why not just call it “Intelligence“? … I’m a hopeless case…
When the AI is calculating a decision, all decision behaviours are iterated and compared with each others. They are individually scored depending on the current situation and the best scored behaviour will be selected at the end of the process.

Below is an example from one of the implemented decision behaviours, multiple aspects of the current situation are checked and affects the score of the decision before said score is sent back to the member calculating the AI’s decision.

/// Gets the current score of this decision
///<returns>The score.</returns>
///<param name="agent">Agent Reference.</param>
public override int GetScore( CombatAgent agent ){
    int score = 0;

    if( agent.main.CurHealth > ( * .5f ) || Time.time - agent.alarmAgent.LastEscape < agent.alarmAgent.minEscapeDelay ){
        return ImpossibleScore;   //If the AI is comfortable with it's current health value, or we recently escaped, return a score that prohibits the AI from chosing this decision

    if( !agent.main.canAttack ){
        score += 5;    //If AI is unable to engage in combat, increase score

    if( agent.main.CurHealth < ( * .5f )){
        score++;    //If AI health is less than half of max health value, increase score

        if( != null ){
            for( int i = 0; i <; i++ ){
                if([i].IsDead ){
                    //For each member of the AI's party who has died, either increase score, or decrease it. (Enemies should be able to be enraged by their friends dying)
                    score += Random.Range( -1, 1 );

    if( agent.main.targetDistance < agent.safeDistance.Sqr() ){
        if( agent.main.CurHealth < ( * .35f )){
            score += Random.Range( 0, 1 );    //If at unsafe distance from target, increase score

        if( agent.main.CurHealth < ( * .2f )){
            score += Random.Range( 0, 2 );    //If health value is critically low, increase score

    if( Time.time - agent.main.LastDmgReceived <= agent.DpmThreshold && agent.main.CurHealth < .4f){
        score += Random.Range( 0, 1 );   //If at relatively low health and recently received damage, increase score

    return score;    //Return calculated score.
Decision behaviours available can be customized for each AI character from the editor, since not all characters will have the same options nor priorities.

This improved handling of AI awareness also helped me improve the AI attack system, which has been created in a very similar fashion. To give an example, in LBKR enemies would always attack the player with the most powerful attack that was not in cooldown, they would take no regard to the distance to the player and only checked their maximum attack range to determine if they could not possibly hit the player.

This created a weird behaviour though where AI’s with ranged attacks would fire at the player from point-blank range alot. With DPBS I’ve implemented a ‘Reposition‘-behaviour that will determine if the AI is at the most appropriate distance from the player, taking in considering a whole lot of properties ranging from current situation as described above, aswell as presets of what ranges the AI is most and least comfortable with aswell as check if they have a clear line of sight to their target. Hence, the AI will adapt their position continuously.

This alone didn’t solve the point-blank ranged attack issue described though, since the AI only make use of the Decision Behaviours at certain intervals. But as I structured the attack system similar I, among other things, added attack range limits and preferences for each AI attack to prevent them from beeing used in certain situations. Also all AI with ranged attacks have a minimum of one melee-attack to allow the AI to attack in close quarters if repositioning is not possible.

.Party interaction

All AI in the game belong to a party, the sizes of each party differ from each other, some contain only two characters while another party can contain 10 – 20 party members. The AI party is used primarily for the AI to be able to interact with eachother, as described in the topic above, DBPS, AI party status is checked when making decisions, how dependant a decision behaviour is of the AI’s party is different for each behaviour, also how an action from a decision behaviour is performed can be modified by the status of the AI’s party.

Take the “Escape” behaviour for example, if the AI for some reason become scared and decides to break contact his action can be either to run away and try to hide, or if the AI know about nearby party members who are not in combat, the character will escape to those party members and rally them, then returns to the battle with his fetched friends.

The combat role assigned to the AI also determine how much it will interact with it’s party, the roles I’ve currently implemented are classed as “Assault“, “Ranger“, “Support” and “Berserk“. Assault characters will most commonly only use the party to find AI to help them when they’re in trouble, ranger’s will be more bold when Assaulters are nearby. Support are generally the most party-fixated characters, they will keep a close eye on it’s party members to know if they require their attention, eg. resurrection or healing of a party member, or summoning new minions. Berserkers pay least attention to it’s party, they are focused entirely on destroying their enemy.

Combat roles in action- Support classed Bone Wizard (Staff-carrying guy) focus on resurrecting and healing his party, while the Rangers and Assaulters engage the player
Example of a hybrid-class, the Corpse Warden is a mix of Berserker and support, agressively attacking it’s opponents but if needed it will prioritize resurrecting and aiding it’s party members

Solotility Mashing

Spent ridicilous amount of time, mashing code like a madman, for my new program SolOTility this weekend. I did make some good progress though! I’ve begun some more intense testing of the program today and I think that I’ll have a functional build released next weekend. I’m going to resume work on Demox this week aswell though, and I still got my day-time job so I’ll make no promises! 😉

New widgets implemented for the Solution Dashboard

Mindmap Node Editor

The user can now create and edit mindmaps with the built-in Node Editor.

The Node Editor used to edit Mindmap items

Start Screen

Created a Start Screen for the application. At this time the user can chose to either create a new project or load an existing from this screen, In the future I’ll add Template Projects that the user can use as a solution setup for a new project aswell as some Tutorials and documentation.

The new Start Screen


I’ve created widget control objects that the user can add/remove to the solution’s dashboard for a more personal work flow.
Currently there’s only three types of widgets but I intend to add more as need be.

“Search Widget” that allow the user to search for items with matching date keys or tags.
“Item Chart Widget” to give the user a better overview of the project.
“(Advanced)Item Filtering” that allow the user to only load items with matching states or types.

The new ‘History Log’ dialog.

Solution History Log

Added options to allow the user to save more item-change log messages, the full history log can be read by clicking the “History” button in the Dashboard screen.
( Previously only saved 3 change-log messages for display on the Dashboard, now the user can select to save everything between 3 messages to up to 500 )


I’ve had a break from working on my primary project “Demox” the last two weeks in order to work on a side-project that I call “SolOTility” (or Solution Organizer Utility).

I’ve wanted to try create a non-game application for quite some time but haven’t really made the effort to actually start, or decide what the program’s purpose should be either for that matter, until now, that is!

So what can SolOTility do and what are my goals with the project?

It’s basicly a program to maintain order for my personal projects and my (and anyone who find interest in it aswell, for that matter.) game design documents along with concepts, ideas, issues and tasks. My goal is to make it easy to use and with a fast workflow. There already exist a whole lot of great programs and web applications that serve the same and/or similar purpose though, so to double back, my main purpose with this program is to code something else than a game- in case anyone would find use for my application aswell that’s a bonus!

Solution Catalog Tree
The project/solutions are structured with tree-node lists, the user has full control of catalog management.

Work Item Editor
A text editor for managing and creating work items. The user can add tags to the text to format or colorize encapsulated parts of the text with customizable controls. The editor also include a dialog to link related work items for quick access from within the editor dialog.

Work Item List
The list that display all items placed within the selected catalog. Work items are color-coded depending on the type of item and the item icons also display what state/progress the work item is in. (eg. Inactive, Prioritized, Completed etc.) The user can also filter items by item type(s) and item state(s)

Work Items
So what are these work items actually? There are currently two primary types of work items- text files and mind maps.
The text file work similar to regular text files, you enter text into the “Content Writer” panel- the text can also be colorized by certain special characters. The text-type work items are split into four sub-types aswell, “Bug“, “Feature“, “Task” and “Note“. While the editor does not handle these types any different from one another, the sub-type help identify the item in lists by changing icon of the file.

Mindmap items are node-based objects that allow the user to draw mind maps! (… who could’ve guessed? -__-)
The editor will allow the user to drag and drop shapes into the editor panel, add some descriptive text to them, and connect them with one another.

I’m soon done with everything that I’ve intended to implement for v0.0.1, and will implement the tool into my workflow for “Demox“. A beta version will be available to download when I feel that the program work good enough! I’ll also create a page here on my website dedicated to this program soon, for further updates aswell as more in-depth information regarding the program’s features etc.

Until then, don’t forget to follow me on Twitter!