Lack of updates

I am terribly sorry about lack of updates, but as I didn't have any time to do anything, I decided not to state obvious and to not post anything.

As soon as I have some time, which hopefully will be just after Christmas, although that might be troublesome as I have quite big list of things to do for book keeping app, I will continue to work on Dragontorc and post news.

But for now, I'd like to wish you all Merry Christmas :)

Weekly update MS04x04

And again... almost nothing. This will continue until Christmas as crunch got even meanier (more hours and weekends).

I could only install SDL on one computer and it was fun, as usual with mingw. Although it is my fault as I probably didn't setup paths properly. I managed to start moving from GLFW to SDL but it is just start. There isn't even single SDL call.

Last time I did something with SDL was 6 years ago and now I can't remember what was better for displaying 2D graphics. I have strong suspicion that it was GL, but I still want to create proper display system and even if I do it now with SDL's surfaces, it will be easier to reimplement few things under hood later on. At some point I will have to do GL version but now I really don't want to go too much into reusing same texture by few sprites as GL textures have some restrictions on size and I don't want to waste memory.

Weekly update MS04x03

I didn't do anything. And I am a little bit too tired to be ashamed ;)

At the moment, after coming back home, I am working as support service for our application which after around 10 hours a day makes me just want to walk the dog and go to sleep. And talk to my wife for a while.

I was thinking a lot about tasks for this Milestone. How to approach everything. What works for me, is to outline big picture and fill it with smaller things. And if something doesn't fit, I am not affraid to modify work already done, if it makes sense.

For this Milestone I planned three things:

1. Proper rendering/display system.
2. Different regions of world.
3. Travel system.

I want to focus first on rendering system but while this task seem to be obvious, I will give more details on how system will work while I will be working on it.

Different regions of world will be just barely touched, as I plan to develop this idea during MS6. While I have code to handle different regions, I don't have anything to describe them, so that's what will be done now. And some little code to generate random maps.

Travel system (and map) is something that I want to give more time, but now I'd like to focus on just creating stub that I will develop later. This stub will be just some mini-game (as I am working on Dragontorc remake, this will be probably something very similar to original Dragontorc game). When I will start working on UI, I will add map, so if game designer desires, locations may be accessed in random order by player (with some limitations), as opposed to travel from one point to other through different locations. Or it can be used for cities.

Weekly update MS04x02

I dislike working with poorly designed and written code. Bigger it grows towards hate, the longer I work with it. And it is going on now more than a year. When we were shipping our previous game, I didn't mind working 12+ hours a day, 10+ hours on Saturday and sometimes on Sunday. I was tired, but I didn't have problems with that. Now I work mostly around 10 hours a day from Monday to Friday and I am just fed up. and tired even more than two years ago. Having other things to do after work gives me a relief. Same thing happens when I do some coding for Dragontorc but especially after few hours of coding Dragontorc during weekend, going back to work was really painful. And I didn't code last weekend, but working with code on Monday was as joyful as any other time.

Because of what I did on last Saturday I was exhausted and wanted to do something mindless on weekend. That's why my last week's work are just few minor things and didn't even test them:

• anchors are used for held objects
• added assistance when entering doors
• added global options mostly to try different scales
• for state machine decision rules when dealing if current/requested dir, it takes into account current appearance dir, not actual dir (it looks better)

What's wrong with scale?

I knew that there is something not right but I only understood it when I saw video I did for MS3. All characters are extremely small comparing to original games. In them, characters were jsut a little bit smaller than doors and in mine remake, they are half size of doors. That's also reason why I added assistance when entering doors, because even now it might be problematic to enter doors (you bounce off frame too often).

AI (AI BASIC)

As you could notice with AI behaviours, I like to keep things modular and hierarchical or in straight flow. I don't have now anything really high-level for AI (on second thought: some behaviour setups can make it work), but you can still divide AI logic into to separate layers. AI behaviour tree that manages behaviours and interior of every single behaviour.

I decided that I want something simple to write, read and run. Behaviours may run in parallel and I wanted to have system of messages (more on that later) and this can bring enough complexity into system, that having some strange setup of behaviour itself, would make whole thing useless.

All I needed were just commands "what to do" and some basic flow operations (if, goto is completely enough). I talked to my colleagues and they of course told me, that there is LUA, that there are other scripting languages. While I would like to have whole logic run on LUA in future, I wanted to experiment with modular design and after looking for a while after some nice scripting language, I decided that it might be much better to create my own one.

This decision let me create syntax that suits writing AI. Adding commands such as "move there", "wait until you get there", "find all enemies around" with just single line and as similar to normal english as possible was my top priority. At some point I considered creating something simplier, that would look like assembler but I dropped that idea. BASIC was the best choice. And  I am talking about normal, old school BASIC, not objective-based language with BASIC keywords. Just plan BASIC. If, goto, gosub, let and so on (sidenote: I don't have "for" nor "while" at the moment and I don't have need to add this, at least not yet).

I needed to write parser that translates code into p-code and something that will run that p-code. P-code resembles assembled code. These are just numbers and that works pretty well. Of course I had problems with parsing as some of keywords might be problematic in some cases. For example I have "to" operator that works as random operator. "2.0 to 3.0" translates into "a random number between 2.0 and 3.0" but it is used also in other places, such as writing recipent of message "to $someone". Yes, I have "$" in front of variables and only because it makes it easier to parse them...

But while I have just very basic subset of BASIC commands, I added much more to handle AI. I will give you an example now:

local distance
local circlingDir
; setup values
go sub ChooseDistance
go sub ChooseCirclingDir
Start:
movement clear
movement move to $MyEnemy at range $distance and keep
movement circle around $MyEnemy by $circlingDir and keep
movement face $MyEnemy
wait 1.0 to 3.0
if 25% chance
go sub ChooseDistance
endif
if 15% chance
go sub ChooseCirclingDir
endif
go to Start
; subs
ChooseDistance:
$distance = (1.0 to 2.0)
return
ChooseCirclingDir:
$circlingDir = (-90 or 90)
return 
What does it do? Circles around MyEnemy in random direction ("movement cirlce around") at random distance ("movement move to ... at range"). Both those values change from time to time (each chance happens at 1 to 3 seconds interval) with random chance of happening.

Simple, isn't it? I already used something similar with project I worked on. Although I just created functions that had some of functionality visible above. Syntax was a little bit more complicated and less flexible, due to limitations of language I worked with.

There are also priorities for behaviours, ending behaviours only at some priority level with some time allowance. You can even execute code in other behaviour or from other part of code (such as message handler).

And on messages I will focus next time.

AI (behaviour tree)

When I started to work on Dragontorc's remake, I wanted to do just a remake. Make it small and quickly. After first milestone I was driven off by animation system but then I realised, that I can do something great in that field in my current work, so why not go back to work on Dragontorc? And why not to make it bigger? To allow people modifying, adding new content.

That's why during MS2 I decided to extend events and items. And while I had plan for whole game created and didn't want to change it (because it doesn't affect anything but me), I decided to extend other things. And to make systems that I could use for other kind of games. It might be even possible to adapt system for space simulator (it will require implementing different movement, etc. although it is possible to keep whole AI code the same! Although spaceships may behave inappropriate as instead of being on enemy's six, they would be circling around, getting closer to fire and move back, but for TTP action game it will be just fine). This is also reason why I wanted to keep things modular. In future it might be possible just to change renderer, animations and interface and turn Dragontorc into 3D FPP, TTP or isometric adventure game.

So here is the background and reason behind my choice to spend so much time working on AI. And now the details, what's inside and why.

As I already mentioned, AI is behaviour based system with messages. What does it mean?

AIs mind currently is tree composed of behaviours - every leaf is a behaviour. Whole thing is set up in such way, that any leaf can be replaced, so it is really easy to reuse behaviours for different characters.

Main node might be a behaviour that decides what AI wants to do. Currently all AI characters choose between three actions:

1. Attack enemy (if there is enemy in current room)
2. Go to door (enemy could leave room and we go after it)
3. Idle (just wait patiently)

Main behaviour switches between children behaviours. If it notices an enemy, it chooses attack behaviour to be current one. It ends all other behaviours by doing so, but remains active (to notice if anything else happens).

And all children behaviours can be separate trees. For example Attack behaviour could have two children:

1. Attack enemy
2. Observe enemy

It may look at current situation or communicate with it's allies to decide wheter it should attack now or just observe and give way to anyone who would like to attack.

All behaviours may run in parallel. There can be even two (or more) instances of behaviour on same leaf node (although I would strongly advice against doing so).

Such behaviour system is quite modular and separating how creatures moves and attack from it, makes it even easier to have classes of characters. It might be even two basic ones: melee, ranged. Or it can have more variants - melee aggressive, defensive, cooperating, ranged that just shoots from time to time or tries to get to best location and shoot from there. But actual creatures may look very different, move different and have different attacks.

How? Well, behaviours just use references of different objects and those references are translated into proper objects using creatures look-up/translator/dictionary/library. At the moment wisp moves in zig-zags and appears to be floating, velocity changes over time, while skeleton seems to stand strongly on ground, velocity changes quicker. There might be an orc that moves slower than skeleton, has more powerful attack, but may decide on actions to make in the same way as skeleton (although it is tempting to make it possible for orc to disrupt skeletons' attacks with loud roar and charge into enemy instead of behaving just like skeleton, but with such system, it is easy).

What are other things that I gained by implementing such system? I don't need to recompile whole thing. I plan to make it possible to reload things while game is running to make it even quicker and easier to test. And of course people may alter behaviours and add new ones quite easily.

What are the problems? It is slower than AI driven purely by code and it took some time to create it.

I've seen quite few implementations of AI in my life and when I compare mine approach to others I have to say that while it isn't the most robust, it is probably the easiest to extend and few other approaches may be implemented with it (if not with behaviours, then with just AI BASIC code that is inside of them). One thing that is not possible for sure is stack of behaviours. I could do it and it could run in parallel and maybe, if I will have a need for that, I will do so, but from my experience, I know that this may end up with AI that constantly changes its mind or AI code is just huge mess of conditions, checks, etc. It is much easier to have separate layers representing different needs and switching between their children believing that each one of them will do their own role properly.

Queries

Queries are not mine idea. I "stole" it from my colleagues at work who got it from other places (that's how I learn about AI most of the times, via other people or recently at conferences).

Queries can be used to find any object or group of objects that match some predefined conditions. For example there can be query to list all doors in room we're currently in and sort them from closet to furthest. There can be query to find all enemies in front of us. There can be query to find anything that scaries us, so we could run away from it.

Query tests all given objects (it can be done for list of objects provided by other system or gather all objects in room, requester is, or do something else) by processing query elements on them.

Query elements can be broken into two categories:

1. Conditions - if condition is failed, object is no longer considered.
2. Weights - they do not throw away object, but just add "weight" value that tells how important is given object. It is used to find most interesting of few or sort many of them.

There are also passes. If in first pass no object is found, second pass (with different elements) is done and so on. As many passes as there were created.

I am still extending functionality of queries and more options are coming, but basics are there. It checks type of object, distance to it and wheter it is alive or not and if it is thinking object or not (AI or item basically). And there is two extra elements. Rating and Rating Rules. They work with Tagging and Rating systems and can be used to determine if we're scared of an object, if it is enemy or how much we like something or dislike.

Where querries are used? At the moment just for AI but not only by AI behaviours but also for actions/attacks. Attacks need to have enemy and if it would not be provided by AI, it would be found with query. And due to telegraph and possible enemy movement, target might be no longer valid when actual strike happens. That's why in moment of strike, query is used to verify if enemy is still valid.

Animations of Dragontorc (2)

I described some bits of animation system in Dragontorc already. That's why I will just focus on new things that were added since then. I might miss some things and I am starting to consider creating a wiki page to keep all details there. It will also work as a documentation for modders. But now, I will just shortly describe bits that I remember, in random order.

First I want to settle between 2D, 3D etc. I probably already did that but I this is also good place to mention in. I want Dragontorc to be done in 2D without any 3D stuff and actually without anything fancy - as far as I want to go with effects are alpha blends. This limits me a little but also focuses on particular things.

Anchors
Anchors are named points for any object. These points may have different functionality. "Point of attachment for held objects", "Point from where projectiles fly", "Point at which particular particle effect is played". At the moment they are used (in code, I had no need to do that for current characters) only for projectiles' starting position, but I want to add "held" anchor.

Animation moods
Mood is used to determine which custom animation should be played. Currently different parts of animation tree may force their own mood and when custom animation is requested, it will be chosen from few. Similary death animation might be chosen basing on particular mood.

Events
I try to keep things clean and to work with flow that AI orders gameplay systems to do something, for example action handler, action handler orders animation system to play animation, animation triggers event that goes up to action handler, that does stuff that affects other entities in the world. That's why I try to avoid AI doing anything that could be considered as physical activity. And that's why I like animations to do some physical stuff or at least to be physical instigator to it. What do I mean by that? Well, I don't want to adjust timing in AI when I want to do damage at particular time in animation. I don't even want to know what animation will be played. I just want to order animation to be played, other system will choose right animation and animation will know when to trigger something. And how it will trigger it? With events.

Limiting movement
Another thing I like to keep clean. Movement. It is up to animation to decide if it is appropriate or even possible to move at given time and what is possible. Movement module may order to move in any particular direction but animations may limit movement to be possible only forward or not possible at all. Or character should not rotate or should rotate at constant rate.

Movement styles
This is related more to movement itself but might be considered as part of Animation. With movement styles it is easy to affect path and speed of movement. Character may then look as it is drunk or is walking not on straight line.

Playback rate adjustment
Depending on current speed playback rate of animations changes, so if character moves faster, it will move its legs quicker.

State machine decision rules
I added also some new decision rules for state machines. They check movement styles, requested direction (in relation to current direction or movement or requested direction of movement) and few others.

This is short and not definite list of changes for animations. And it turned out when I was adding items, that it is in alphabetical order (with one exception, I decided to add Movement styles after I finished the list).

And now I am sure that I will have to create wiki page for all of this, as this is just mentioning of features but they will require clarification and examples of use (and someone to correct all my grammar and vocabular errors, and to be honest, my grammar isn't much better in my mother tongue, even my wife sometimes makes fun of me because of that).

Weekly update MS04x01

As you can see, MS3 is finished. I haven't started anything for MS4 and I will describe plans for it in a separate post, as well as different subsystems that were created, what went good and what went wrong with them.

First, quick list of things done during last week:

• fixed some AI BASIC bugs:
• behaviour related functions not working properly
• incorrect loading of message command which treated reciepent as parameter of random operator
• fixed stats stack not being setup (which resulted in not affecting damage done by or to wizard)
• fixed regional checks for projectiles shot by player (to have same behaviour as in original game)
• fixed missing relative dir in relateive direction state machine rule
• added error message when loaded type is not recognised (I spent some minutes on looking for a bug in code that wasn't there because I named few objects incorrectly in xml file)
• projectiles deal damage to objects just one time and should not hit someone who fired them
• fixed default height
• added "vanish" animation (used by wisp and wrath now)
• simplified some AI behaviours code

I noticed one thing when I created video for MS3. I haven't paid much attention to it, while I was working on that. I just had a feeling that something is wrong. Scale. All characters are too small (or rooms are too big). So one of the things for this week is work out better scale. This problem reminds me of one Jet Set Willy remake which was way off with movement and jumping. And everything seemed to look very small. And while I think that movement that I've done for characters in game has feeling of Dragontorc, scale is definetly wrong. Fixing scale will also introduce with other issues - it will be much harder to enter door, so I will have to do something now, although I planned to do it later - some little code that will assist characters while entering door (for player, when they're approaching door, for AI when they want to go through door).

And game is now... ugly? It has original graphics for some objects, but you can notice many problems with displaying them correctly. I want to create proper rendering system during MS4 - and again, I will share some thoughts on that as well. I should start working on it during this week.

One more thing - I want to track how many weeks have passed since beginning of MS. As I have more than 10 MS planned (but they should be shorter than MS3 :) ), MS number has two digits. And I expect that some MS may take less than 10 weeks but some will be longer, that's why week number has also two digits.

Dragontorc MS3

Finally, MS3 is here.

What has been done in this time:

• Basic graphics with animations and animation tree (part 1, part 2)
• AIs (hierarchical behaviours with message system) (behaviours, AI BASIC)
• Tagging and rating systems (link)
• Queries (link)

I will describe each of the systems in following days/weeks (and provide link here, and I see that I already described some bits). But for now, just watch video

What do we have here? Bugs with displaying graphics, but as MS4 brings proper display system, I didn't want to spend much time on that.

Enemies. All enemies have same main behaviour (attack, idle, go to door). Attack behaviour differs.

Wisp only goes through enemy giving damage while touching it.

Wrath circles around enemy and shoots fireballs.

Skeletons cooperate with each other, circling around enemy and one of them at a time attacks. After attack skeleton moves back and lets other skeleton to attack.

I will describe how it is done when I will be writing about AI.

At the moment I use original graphics with few changes and one new animation (skeleton attack).

I also want to change weekly updates to provide more info than just bare facts. So stay tuned.

Weekly update

This should be last weekly update for this Milestone.

I am almost there, few things to fix and tweak. I could show what I have now, as it looks ok and meets requirements I had for this MS but I really would like to fix and polish things as this will reduce amount of work in future.

And just as formality and to keep current shape of weekly updates (well, I am still going to do this in future, but focus also on other things):

• AI behaviours can no longer be chained (so child becomes parent of its own parent)
• added logging to file (I need to create utility to filter log file and to display objects)
• extended functionality of projectiles
• they can be fired exactly on spot or in general dir
• they can harm only objects with given rating (for example: enemies)
• more logging and minor tweaks and fixes

I plan to finish everything and post information about MS during this week.

Weekly update

Or rather another lack of :(

And again, crunch at work, issues related to other app, such as setting up server, creatign and signing contract, (which in my opinion at the moment lead to nothing good, but I hope that this will change) and finally, helping dogs. Yes, we spent few hours in forest walking dogs from the shelter. After first hour we were wet thanks to snow. And thanks to that snow only official volunteers appeared and my wife and me. No people who thought that it would be nice to help dogs. Probably because it was snowing and they didn't want to get cold. Forget the dogs! Eh. So we walked 8 dogs and the last one, deaf, quiet and friendly was probably sick. My wife talked to one of girls who helps vet hospital (that helps homeless and from shelter dogs and other animals) and that dog went to hospital and to temp home. I planned to work a little on that Saturday but when being tired we went home, we just ordered pizza and felt asleep.

I really want to get few hours during this weekend and finish this Milestone as in three weeks time it will be one year it has officialy started. And this just sounds ridiculous. I could install vala at work and do some work here but this would be a) illegal b) unfair towards my coworkers and my company. Even if syncing/compiling takes so much time. But... I could write some posts about various subsystems I have in game.

Weekly update

Lots of work... at work and at home (as we're preparing ourselves to sell our app on our own) and few other things kept me from working on Dragontorc. I was able just to fix few minor bugs (one of them being again private set; public get; issue.

Good thing: Skeletons now move nicely and only one attacks, other stay away.
Bad things: Their death animation is not chosen properly and wrath crashes game.

I am unable to tell if I do anything during this week. Weekend, maybe. I know that for sure at this point I need to stop adding multiple features and test every week or two and instead I should add feature, test it, add another and so on.

Weekly update

I did almost nothing during last week. But I had a chance to talk a little to one my colleagues at work and although I already wanted to change what I put here, on this blog, he gave me more ideas. When I finally finish this milestone, expect more stuff about how game works (even if it is going to change and change), more videos, more of everything ;)

Weekly update

Almost there. I have three enemies, but I need to test them.

I've run into few bugs that I have no idea, how I could make them. Maybe being tired or maybe writing after a glass of wine? Doesn't matter as it is closer and closer to Milestone and I really hope that I will just spend this week testing, fixing minor bugs and creating video. Of course there are some obstacles on the way, at least three: working longer hours, other project that needs finishing as publisher wants to move sales to e-shop, and a dog that we adopted on Saturday. With two dogs in home, both trying to focus our attention on themselves and our old Dafi being sometimes too aggressive towards Baltazar, it takes some time and after few hours with dogs I didn't feel like coding... I really would like for them to fully accept each other and won't be so envy.

But here's the list:

• updated some graphics
• added animation of attack for skeleton
• added "into ashes" animation
• extended "or" operator to also work as random choice between two
• added coordinated attack (only one attacker at the time, others just observe)
• added wrath (which will be now shooting projectiles, for testing)

Some of the graphics is grabbed from you tube walkthrough and look worse than in original game, but display system will change in next Milestone and probably then I will create some graphics that should give a taste of final style.

Weekly update

Not big update this week, so I keep it short:

• fixed default starting location for projectiles
• reorganised AI behaviours for wisp and skeleton, so they have one common base
• added original graphics for skeleton (I still need to add special animation for attack)
• added new state decision rule to determine in which direction does character move or wants to move
• added handling of different directions for forced movement
• added adjusting playback rate (and it works in relation to current or desired speed)

So it isn't much. I wanted to finish this MS month ago and here I am with few things to test and one more character to add. And graphics being the biggest issue here. I am now in something that I could call coding mode and don't want to work on content yet. At some point I will change my mindset and then it will be just adding more and more of content for actual game.

Weekly update

AIGameDev conference was great. I didn't find any time during my stay in Vienna to look into Dragontorc, but during weekend I managed to do few things, so here we go with the changes:

• fixed bug with loading bitmaps (vala's "private set, public get" is messed up for structs, I should report that)
• fixed lots of AI BASIC issues:
• fixed loading expressions
• fixed loading "wait" command
• fixed "or" operator
• fixed "offset" for movement command
• extended debug info that goes to log
• fixed incorrect usage of Unique Event Groups (bug allowed to unlock chest with any key)
• fixed using rating rule instead of rating for default query element
• added default movement style
• added default reference for library solvers
• fixed overlapping objects check
• fixed stats (gee's strange issue - it may only store int as value of map, it won't work with float but if you encode float as int (value of pointer to float pointing at int and vice versa), it of course works fine thanks to vala compiling to C)
• objects may be killed/destroyed (and fixed some bugs related to it)

And last thing means that both player and enemies may be killed now - I killed few wisps with missiles/firebolts and they killed me with just going through me for some long time.

With next Milestone (I am just that small bit (that grows into more small bits) from finishing this one! More time I will spend on getting graphics from original Dragontorc, even if it is just temporary graphics) I will give numbers to Weekly updates and I will provide some video more often.

Weekly update

Oh, I almost didn't made it. I am going to Vienna (not Venice as for few weeks I believed it was) for AIGameDev conference, so it is very unlikely that I will do something during the week.

But I did something during past week, but only something, as most of the time I spent at work and I had to do few things at home as well. Here's the list:

• improvements for movement (offsets and few minor things)
• AI BASIC:
• chance and percentage operators
• generalised usage and setup of AI Actions and AI Behaviours
• added mirrored bitmaps
• graphics!
• wisp (grabbed and added)
• firebolt/missile (grabbed, just two as temp, and added)
• skeleton (grabbed, just few frames, not added yet)

And compiled two weeks of work and fixed compilation, but some stuff does not work. I am making progress even if it is not as fast as I'd like it to be.

Weekly update

I did lots of small things during last week. Even with weekend spent visiting family. But I still did not finish the Milestone. And why? Because although many things that I did, I found useful, there were still some missing bits or some things that needed improving/unifying/adding. So, here's the list of things done last week:

• added damaging overlapping actors (so wisps can damage wizard, and in future it should be possible to easily implement "bane" spell)
• added stats rules to have some damage being ignored by default (most characters should ignore "astral" damage)
• some objects may be invulnerable
• AI BASIC improvements:
• "attack" command
• movement speed can be set with percentage
• added new AI messages (when someone is damaged, killed, when entering new room)
• behaviour or AI action may be accessed with "if" statement
• unified "waiting" command
• added "switch to" command (ends all other child behaviours, leaves or starts just requested)
• added "is here" operator
• added "random" operator
• some minor technical improvements
• renamed "action" to "interaction", so it won't be confused with AI action (I still have to find good name for "event" which was taken from original Dragontorc, but it should be "interaction event" or something like that
• some mingling with interfaces (renaming, adding new ones)
• all AI objects may be accessed through queries (not only actors and items, but also projectiles and doors)
• added wisp character (still work in progress)

Why I had to do it? And does it mean that I will spend so much time on everything?

I wanted to add some improvements, because I can and because it may make my life so much easier in future. Take a look at the wisp. Adding that little fellow took me few minutes but I had to struggle with some bits and decided to make it easier and cleaner and when big part of week was spent on that. I was going to add skeleton and some projectile based enemy during that week but decided that I will do it, when I will have all that I need. Probably adding the graphics will take most of the time (currently I am using Dragontorc's graphics but this will have to change).

Weekly update

During last week I did almost everything I planned. "Almost" because I forgot to do something. And it turned out that I forgot about it, when I started to test everything. On Saturday I finally took two weeks worth of coding and tried to compile it. And after some time (mind, not that long) I started to test stuff and run into two crashes  that were related to consequences of tested code, which means that new code was working just fine and the old one was broken because of two assumptions that I made earlier.

So when I was testing taking damage, death, animations etc. It was working as expected. I moved to test AI attacking me and as it was not doing anything, I looked into its AI BASIC code and then I realized that I didn't put any code related to attacks there. I looked into AI BASIC source, where I have nicely documented every AI BASIC command and... I didn't find one related to start an attack.

Plan for next week? Add that missing command, few minor things, test everything and start working on two types of enemies and I will probably use original graphics for now. Hm, maybe I will increase the number to three by adding wisp that would just randomly wander around map and from time to time attack player.

And now, as always, list of things done during this week:

• added collision handler interface (it is assumed that projectile does damage on touch/collision)
• added firing projectiles
• added max state values for stats and "vital" stats
• added play death info and death infrastructure (without AI messages, which will be important for AI to learn, who killed their allies)
• added few events for animation
• added condition for queries based on AI's rating (no assumption on ally/enemy/alignment in game framework)
• minor changes to allow multithreading safe (with added checks)

There is one more thing that I'd like to mention.

During last week I bought Avalon and Dragontorc. Finally. When I was kid, we didn't have access to most of original games. Even law in my country didn't prohibit piracy. It all changed in mid 90s and I never had a chance to buy Avalon or Dragontorc. And after all those years I didn't even think about buying them as I assumed that there are no more original tapes that I could buy. Until I stumbled upon www.retrogames.co.uk.

Weekly update

With article being finished, with crunch at work and after I bought Just Cause 2 (finally, as I was pretty reluctant about it, as I know that every game I buy or try will steal few hours of my life :) but I do like playing games, otherwise I would not be in gamedev) I did few important things. It is now obvious that I won't finish MS3 this week but it is closer and closer. And yesterday was lost to making dumplings (pierogi). I did 100 of them and could do more if I had more time :)

So here are the changes:

• some work on Library's combined stores (currently used for animations/animation sets and for attacks and possibly some other actions in future)
• reorganised interfaces for playing animation (separated context and requester interfaces)
• added attack types

Plan for this week? Add handling of projectiles to attack and code to handle death. If I do it, then I will start to work on actual enemies (now there is a testbed one but I will have to purge everything from it and write proper tests, so when I change something, I will be able to test it) and I plan to make at least two types (melee and projectile-based) with probably melee enemy working in group.

Weekly update

Ok, so to wrap up last week, I did some further work on library references and still need to do a little before I move on to add attacks (that should be fairly simple though).

And now, as I mentioned in previous post, I'd like to share some thoughts and ideas I had for Dragontorc.

Visual style / renderer

Most likely first implementation will be based on 2D graphics but I was thinking a lot about some voxel based renderer (it may not be proper voxel renderer, as it could be just normal triangle-based mesh created from voxel graphics) and in the end I would like to have it, but for the time being, I will stick to the basic 2D.

The reason for 2D is that I have some bits of it, it will allow me to focus more on gameplay itself. Having 3D with voxels make it easier for some people to work with than normal 3D and there is still that pixelated look. Voxels also help with having less data to be created than for 2D (4, 8 directions?), although each single frame of animation requires more work. But in future, if all data is in 3D then it might be used in more complex 3D game.

Versions of game

I am thinking about having at least three different versions of game.

1. Full game with modding support, documentation, maybe custom editors (although everything should be possible to be done with text editor). This would be most expensive one... Hey! I would still like to earn something ;) And by most expensive I mean most expensive of all versions. The prices still should be quite low. This version should allow people to add new content or even create new games. It will require something to make it easier to distribute people's work to make it as easy as possible for inexperienced players to try various stuff.
2. Remake of Avalon and Dragontorc. It would be great to have them as faifthul to originals as possible, but I don't consider it as necessity. Of course this version would be free.
3. New adventure that would make use of almost all engine features that I plan to have. Ideally this could be few hours long game that could be bought for some really, really small amount of money. Not extensible as full game but should give feeling of what can be achieved. Having this version free, could make no sense if it would be few hours long.

I don't know what will be order of releasing all versions. At the moment I don't even know when I will finish it. But yes, I want to make it a commercial product. Why? Take a look at the time it takes me to do anything. Weeks, months. Because I am working on it just few hours each week and even then I am not fully focused on it. If I had more stable situation financialy-wise then I could quit my current job and work on it full-time. But it may not happen anytime soon. Releasing it as commercial product could change it. Even if the success would be really moderate.

But now, let's finish this milestone!

Weekly update

Back from short holiday. As I had virtually no access to power source, I didn't do anything during my days off. But before I managed to refactor some bits and add few small things (hm, maybe not that small and very important and actually, very useful). Custom animations are still not in the game but are closer and closer.

During this week I haven't done anything and probably I won't as I have to work on the article and we will have some guests and there's lot of other things going. But I was thinking a little about ways of publishing Dragontorc as remake, original game, a mix of both, etc. I will share it on Sunday.

Weekly update

No code done this week. For various personal reasons.

I just had some time to think about how attacks, animations, ai code go together and I hope to do this during this week.

And I also found out that where I am going to the sea side, there will be very limited access to power, so I won't be able to do any coding. But - I will take my notepad. I haven't done such thing for ages now. Designing stuff without any access to computer ;) Of course I was writing down some ideas from time to time, but not actually designing anything.

Weekly update

More work on health / stats system was done and I started to connect various systems to interact with each other. At the moment it is only that animations may trigger events but very soon there should be more things happening between various systems. Although one more new thing I want to add during this milestone (gameplay-wise, because there is one more thing in technical department to be done). Attack types that use queries to find enemies (if not provided, or to check if provided target is still valid) and stats. And then AI will play animation that will trigger an attack.

Oh, that may be huge change but I think that it may work better for today's audience. All attacks will have animations, so they will be properly telegraphed etc. There will be still (for at least astral projection) damage dealt when moving through enemy, as it would be too easy to avoid damage by moving through enemy, but each character should have unique attack animation too.

Weekly update

Budapest is a beautiful city.

And is also a reason why I did so little during last week, just some little further work on damage / health system. In three weeks I am going to sea side but as there is not too much to do, I should be able to push Dragontorc forward much more than during this short vacation.

And I played League of Legends and I promise, it won't hurt development process.

Weekly update

Finally I decided to write and finish the article I wanted to write. Well, actually I had to, as tomorrow is the deadline.

But I still managed to do some work on Dragontorc. I started to create health/magic system which for Dragontorc's remake will be used in simplier form, but should give modders more freedom.

I will try to do at least something this week, although, due to trip to Budapest, it might be tricky.

Weekly update

And again. I spent more time on Dragontorc than on article. I still did some work on later and I hope to finish it this week, before weekend. But back to Dragontorc:

• more improvements on AI movement, better handling following to different rooms, etc.
• added "rating" operator
• expanded "wait" command (added "wait until condition") and unified code for it
• added "in" command to run command in other behaviour or action - nice thing to affect behaviour from message handler

I still have few important things to do to finish this milestone. Two most importants: damage/health system, appearance sequences doing stuff. Of course I have a list for few technical or minor things but I will keep it until some lighter milestone or I will have some small milestone in between. When I will finish it, I will write extensive note on why could/should I break it into few milestones but also why it is fine that I didn't.

Damage/health system's next. And even if it is really simplified for just Dragontorc remake, I want to have it a little bit bigger, so it could turn game into number-based RPG or even number-based action RPG. By the way, I now know what RPG stands for, it is not Role Playing Game. It is Rong Praying Grinding ;)

Weekly update

Instead of writing an article, I did some work on Dragontorc:

• priorities for actions
• added sending AI messages from AI BASIC
• added movement ordering from AI BASIC
• few small refactors

I should not write anything related to Dragontorc next two weeks to have article done. But I'd like to finish code related to movement and start working on attacks/skills. With that in place, I should have all subsystems done for AI and player characters. Which doesn't mean that all functionalities related to AI are finished.

Weekly update

During three following weeks I will have to work on something else (book article) so probably updates will be very small. This week's update is small for other reasons which also may affect few following weeks.


I only did some small refactor and work on making multithreading safer and in more control - separating internal AI logic from interactions.

Weekly update

I didn't do a thing during last week.

Point of having "weekly updates" was to make me do at least something every week, but I knew that this had to happen. At least I have a good excuse:

I took a week off, so I could spend some time with my wife and that we could do some stuff that we had to do (lots of various little things, mostly related to house). And we could spend some time together. I guess that we should do this from time to time.

But have no worries, I still want to work on Dragontorc and while I didn't do anything, I still was thinking a lot about it and planning few things.

Weekly update

Finally I had more time this week! So here's the list:

• added movement styles - they lay between locomotion component and movement module acting as a layer that modifies velocity (works great for both AI and player - created test movement style "drunken")
• added (well, still adding) actions - very similar to behaviours but without tree structure and comparing to behaviours, they are responsible for actual physical activity of an object. Behaviours are just logic, issuing AI messages, requesting movement, etc. but can't modify physical world. Actions can. And actions can also be triggered by player, while behaviours are just for AI.
• some work done on object/projectiles existence (objects may go into afterlife, taking their physical appearance out and leaving just basic info about them, so living objects may still reference them in their logic, etc)
• unified anchor/custom anchor for appearance and created simple hierarchy: appearance -> appearance atom -> bitmap, so defaults are provided at top level and may be overriden while going down (bitmap being at the bottom).
• some refactoring (most important: removal of code block executions is aware if given CBE is currently advancing or not and handling such situation)

In this week I hope to finish actions and do some more work on AI Basic as there are quite few important commands requiring implementation, so I could finally end this milestone ;)

Weekly update

During week I didn't do much, but luckily, when weekend came, I had some free time to do a little bit of work, so here we go:

There are now projectiles, flying around, hitting stuff etc (not doing any damage yet). I also added touch flags so it is now possible to touch specific objects but not collide with them (as it is case for wizard's astral projection and some projectiles). And because I have now first objects that can be destroyed, I had to solve the issue of advancing objects while some of them may disappear.

And I had time for some thoughts about threading. I don't support threading at the moment but I will surely do for at least some stuff. I'd like to have AI and Appearances multithreaded as any action in them is limited to this single object and if there is something that may affect other objects, such things like messages between AIs might be/are queued. Physical activity, such as movement, interactions, everything that may not be confined to a single object or can't or shouldn't be deferred, will be singlethreaded. Of course things that are singlethreaded should be limited to as small number as possible and should be quick as possible.

During next week I hope that I will bring projectiles to some usable level and I will start working on actions. And maybe think about something that could handle health, mana etc. I don't want to have such things for Dragontorc, but I'd like to have an option in code for that.

Weekly update

I really hoped that I will do more during this week and especially weekend but I didn't. In fact I just did some little refactoring (related to projectiles), created specialised movement module for projectiles and added library references.

That's it. I hope that the next week will be better :)

Weekly update

Not on Sunday evening but on Monday morning.

Ok, rating stuff is almost complete. It just lacks some interface in AIBasic, but it is not only thing that is missing there.

I started to work on projectiles. They are stripped down objects with better memory management. I could have normal objects (actors, items) being pooled but it really doesn't make much sense as life-time of each is much longer than projectiles (which should be active in most cases for a second or something).

I also added forcing velocity via animation which should give nice looking attack animations. Fun fact: I wrote most of it while waiting for my wife in McD's (she was upstair in language school) and there was small girl, who was very interested in what am I playing and then disappointed seeing black and white screen (on my netbook, after I installed Ubuntu, after few weeks I realised that I didn't set up vim for vala ;) ) and then she started to be interested again what is so interesting in that black and white stuff and why I type so much.

Weekly update

This week I did some more work on ratings and added AI Collective. A way to group teams, factions, etc. And to rate other characters (or items or anything else).

During next week I plan to finish working on rating stuff and do some work on code or actions and projectiles.

Weekly update

I had even less time than the week before, but still managed to add two important things. Tagging and rating. Idea behind tags is very simple and doesn't require much explanation. They can be used to describe any object (any library object at the moment). Each tag is accompanied with a number - relevance. This means that for some objects it might be more important that they are (for example) evil than for the others. If AI sees something that is evil, scary and a ghost, and is scared by it (because it killed its ally), it will learn to be affraid of something that is evil, scary and a ghost. So when it sees something similar, it will run away instead of approaching. How such reasoning can be done? With ratings component. It is used to interpret tags and to rate individual characters. During game it may modify and learn what is scary, what is good and what is evil.

It may sound as an overkill for such a game as Dragontorc, but as with other elements, I'd rather create something more extensible which I could use in future for other projects and which other people could use to modify and extend Dragontorc or to create something completely different. And it still should help working on Dragontorc's content.

Weekly update

Not much was going on during this week, as I was away for couple of days and had some other things to do, but here's the list (before I go to bed):
-added limit for number of simultaneously executed code blocks (limit per code block)
-added weighted queries. well, just one at the moment - distance - but the code's there and adding new ones can't be any easier
-added two operators: missing "not equal" operator (I have no idea how I missed that) and "tagged" - although tagging is not there.

Weekly update

Because current Milestone takes more and more time, I thought about writing weekly updates. Just to keep everyone interested informed and to "force" myself to do more and more :)

One thing: many details on "why" and "what" I will write on MS3 post. In weekly updates I will try to keep list short and put some extra thoughts there. So, here we go:

I realised that now I am writing code in batches. I write something, couple of things and then at one day I am compiling it and fixing. And I think that it works better than writing/compiling all the time. Especially when creating new stuff, as I focus more on functionality, implementation decisions (to make my life easier in future), etc. I'd like to have more time to work on Dragontorc, but I am able to spent just few hours a week :( And that also could be a reason why I work this way.

What has been done during that week?
-some technical work in BASIC - mostly about AI behaviours and organising variables
-added redirection of AI messages
-added priorities for running code, so it can be interrupted only by specific priority
-added critical sections - code that has to run fully before handling controls back
-added more BASIC commands - biggest one being "IF" that for some unknown reason to me, I was afraid to implement earlier
-and added "is" condition for objects (example: "IF $SomeoneWhoBumpedIntoMe is Enemy")

Ok. See you next Sunday and have a good week :)

Animations of Dragontorc

Feels like half of Milestone, as one new big system was added and is now functional. First, I didn't want to add this system at this point, as I didn't want to decide about look of the game (3D or 2D) until very far into the development, after all functional stuff has been done. But after thinking about future of the project during MS2 I thought that it will be best to have it done as 2D, as creating 2D graphics is much more straightforward for most people and it can be done much easier and faster (unless you have base of animations and you just rig meshes to same animations).

Gameplay and animations systems are separate beings and at the moment there is no need to have any interface between them, although I want to add something that may help keeping track of played animations etc. Currently animation system watches gameplay object it represents and tries to show what is going on. Example: Chest gameplay object may have three states: Locked, Closed and Open. By using certain key it may go from Locked to Open and then from Closed to Open and back. But animation tree for it uses just two big states: Closed and Open, since there is no difference between Locked and Closed. And there are also two extra states, one for chest being open and second for chest being closed (animations). As soon as animation system notices that gameplay object has changed its state, it changes state as well. As look doesn't affect gameplay, when animation for chest being open is played, it is already open and may be closed. So when this happens, animation is stopped and switched to animation of chest being closed. It is automaticaly synchronised correctly - with all data about synchronisation stored in animations, as at the animation tree level we shouldn't be bothered with such details (this is what annoys me with game engines that rather force high level systems with such tasks, even if most of the time animations are used for just exact one thing, and even if there would be need to use one animation for more than one function, it is better to have two animation objects sharing same data, but that's a thing to discuss in other topic). There was one thing I had some little trouble deciding how to approach it. As characters and items may face different directions, it was not so clear how I should store Animation vs Bitmap objects. Should I have separate animations for different angles? Or better have one animation with some atom objects and inside each different angles should be provided. At the moment I have no idea how I could think about first approach as it is pretty clear that it is much better to have single animation with bigger atom objects. Easier to maintain and change.

Ok, one more thing. I needed to have state machines and having in mind that I will use them couple of times (I am also using them for items now), I wanted to have pretty generic system but at the same time without some implications on use. And I decided to make a little experiment. Make state machine objects just a components of some arbitraty hierarchy. And it just works nicely and gives me freedom of implementation of other stuff. I have now two objects related to state machines. One is handler that allows deciding which state I want to be my current state (I call it "desired state"). It relies on some logic, decisions and/or copying state of owning object. The other is state itself or rather rules for state. It takes desired state as input, chews it and gives out state we need/may to go. How does it work? Well:

In example with chest we had three states Locked, Closed and Open. Handler copies state and replaces Locked with Closed. Then if state has changed rules tell that to go from Closed to Open, animation tree needs to go first to Opening. And Opening tells that it may finally reach Open only when current state has reached its end (in this case: when animation has ended). Or it may go back to Closed via Closing.

Ok, but that's enough. Now for some AI.