To automate or not to automate

This post will be about a very simple thing to implement, but which can save a lot of time - data automation.
   
    The biggest hurdle to a game like Last of the Warlock Kings is the sheer amount of 'stuff' you need to put into the game.  When you combine this with the data driven approach (a necessity when you want to make the game very mod friendly) you quickly find yourself making a ton of data files, all of which share a lot of the same content.

To think or not to think

    This post will be delving into the journey from mindless inanimate characters to one of slightly stupid, artificially minded characters.  That's right, it's AI time!  Read all about it after the break (there's even a video for you lucky, lucky people!).
   

To effect or not to effect

    This post is going to talk about how the game uses a very generic form of script to provide effects or actuators on a wide variety of objects, performing a wide variety of effects, for a minimum of coding.

    Following on from the previous post where I discussed abstracting the myriad of actions available to the player, this discussion is about the same type of abstraction, but applied to a different game mechanic.

    Think, if you will, of a character in the game.  Let's say it's a smelly little goblin called Bog.  Bog, in the heat of battle, has been struck with a multitude of different magic spells - he is slowed down by a cold spell, he is on fire from that stray fireball, and his sword is currently heating up rapidly because of that damn fire witch!  Each of these effects require the code to change a different aspect of the character.  The slow effect needs to reduce movement, and the fire effect needs to apply damage over time.  The heating-up weapon means soon poor little Bog won't be able to keep hold of his sword and will have to drop it.  To code these up would normally be a bit of a pain in the backside, because they are three very different results, but there is a better way!

2Abstract || !2Abstract

    In the last entry, I talked about the multitude of actions that a game like this needs, and how it's difficult deciding what to cut and what to keep.  I then mentioned the term 'abstraction' and how it can help expand the number of actions available to the player without significantly increasing development time.  Now I'll delve into abstraction and what it means for game development.
  
    Abstraction is a somewhat nebulous term, and can be used to mean a variety of approaches within game design and development.  In this case, I use it to mean a kind of separation between objects and their interactions, and a move away from specific actions to a more generic form.  For example, one action can be used on many different items, without the need to code many different responses.