Friday, 25 July 2008

Microsoft buys Truespace, makes it free!

Yep you read that right, according to this article, Microsoft has aquired the respected 3D modelling package Truespace and re-released it as a free download. Yes let me repeat that. A free download. Microsoft, it has been a long time, but for this, I applaud you.

Thursday, 24 July 2008

Artificial Intelligence test

Last night, myself Chris and his young son Joe gave the latest build of Magefire a playtest. We were mostly testing the artificial intelligence routines that are now completed for independent creatures (see the earlier blog post Fun and games with designing AI for more details). It took me a while to program these because of the unusual approach I took that supports emergent behaviour, but it was well worth it. Some of the complex behaviours I wanted to be in there have indeed emerged. For example, because of the ruleset for the game, creatures that are next to each other become engaged and must fight to the death. The exception to this are flying creatures, who never get engaged to their enemies. So a valid a strategy for using flying creatures is to fly in, attack and then fly away again. This kind of behaviour was the sort of thing I wanted to emerge from the AI and it has, so I'm very happy with the results.


The overall playtest went well for the first game (which took place in my specially designed Deadly Arena level where pretty much nowhere on the level is really safe) but the following two games were marred with raising the dead bugs (in the game, Dark Imps can raise the dead as skeletal minions) so some work needs to be done on areas that we thought were already working. We managed to get a computer controlled wizard in there too, who uses the independent creature AI, but as predicted he didn't really perform too well. The next big step in the AI development is planning and unit coordination, both areas that the independent creatures do not require as they do not cooperate (except by accident).


So overall, the independent AI has been a big success and complex behaviours and strategies for individual units do indeed emerge.

Tuesday, 22 July 2008

Confessions of the Nuclear man

For anybody that might be interested, I have posted a new short story to the Creative Chasm blog, a long neglected creative outlet of mine.

Wednesday, 16 July 2008

To be honest, sometimes I just switch it off and on again

Does anybody remember the advert that ran on British television recently for a military technician type job on board a nuclear submarine? In it, a technician boldy proclaimed that sometimes he would just switch it off and back on again. At the time I thought it was quite a funny line of dialogue to put into a job advert and that it was probably true; but now I know it is.

Our nuclear subs, you see, actually run on Windows 2000. See Submarine Command System (SMCS) (United Kingdom), COMMAND INFORMATION SYSTEMS - MARITIME and SMCS ... which, when I read articles like this Unpatched Windows PCs own3d in less than four minutes it doesn't fill me with a lot of confidence! You see, you can garruantee that those subs are most definitely *not* hooked up to the web receiving OS updates from Microsoft...




Single threaded ranting

Now this is something that has bothered me for years; ever since I picked up .Net 1 and started to build applications for the office with it and learned how easy and straightforward the Microsoft dev team had made threading, I have wondered why on earth Microsoft office applications are often single threaded simpletons. The reason is likely to be legacy, but even knowing that this is the most likely cause, I cannot bring myself to forgive a multi-billion dollar corporation for keeping the old codebase and not refactoring it to improve it for its users. How much money does a product need to make before a company will improve the experience of using it?

I'll rewind a little here. Single threaded applications get busy when the business logic is busy, do not redraw themselves any more (often go white), do not respond to user input and generally appear to have crashed - even if they haven't actually crashed. Think about when Outlook gets busy and the UI stops responding, or Internet Explorer. The solution to this is to have the business logic spun off into a different thread to the UI - this means that when the business logic gets busy the UI stays responsive. This does not require multiple cores or processors to work thanks to the (semi-modern) pre-emptive multitasking nature of our operating systems, it just works. So why can't the largest software company in the world update its flag ship applications to take advantage of this?

Possibly because if you have a fast, snappy environment that responds to user input in a timely fashion (even if the underlying application is busy) then you won't want to buy a new computer and they won't sell another copy of their OS and / or office suite. I've heard it said that newspapers serve two masters: the readers of the newspaper and the shareholders. I think that applies here. Ultimately, the shareholders are in control. Sucks to be a consumer of the actual software.


Thursday, 10 July 2008

Fun and games with designing AI

We have got Magefire to a very basic playable point where we could test it. There were bugs in the engine with it being such early days but on our second playtest, nothing that was a show stopper. In fact a surprising amount of it worked properly and overall the engine is behaving itself.

We were testing line of sight code, initiative unit ordering, the combat system, map shrouding, ranged attacks and summoning of the basic units (various types of Imps) by the wizards, movement including flight and a points system to show who was winning. Also, the "replay mode" was tested as that has been built too, which replays back anything your units could see that occured when it wasn't your turn. Most of this did exactly what we wanted to do which got me thinking about what the next step should be. And, as what can be done at this point is very small in terms of actions (i.e. things such as move around, summon, attack, etc) I figured this was a good time to start on the single player AI (and by extension, the multiplayer independent creature AI).

Whenever you begin developing something from scratch - in any programming language or environment - you are faced with choices. How should the system be designed? Are you really building a system? Object oriented programming teaches us to think abstractly, high level, so we don't get bogged down in implementation factors when considering an overall design. A very useful skill. So I knew that generally the AI has to make decisions based on its goals. Thinking like that freed me up from thinking about FSM's, behaviour trees and so on. Instead I was thinking about what needed to be achieved. I recalled a new scientist article I had read recently where the author was suggesting that what our brains do is take a range of values, pick one and then feed back into it whether it was successful or not by adjusting the weights. Now I know that this is really just a neural network rephrased, but put into it's simplest terms in this way, got me thinking. To do that and support reinforcement learning, you don't actually need a structure as complicated as a neural net. You could have a rules based AI system.

The basic idea is this. Everything stems outwards from the actions that an individual unit can do. Actions include such things as walking around or attacking an enemy. The default weight on these would be zero. However, each action would have a number of requirements that must be met or the action is not considered by the AI system at all. A requirement could be having a ranged attack before the ranged attack action can be considered. Providing the action passes these checks, the AI then runs through a list of modifiers that affect how much priority the action has. A modifier could be, how likely is it that the ranged attack will hurt the enemy and how badly will it. So you have a whole bunch of these things and a simple stack that gets sorted by priority that determines what the unit should do.

Now this won't cover planning or goal oriented behaviours, but would be fine for individual independent units that only need to worry about their own safety. So this is the approach I'm going with and it's mostly done now. So hopefully in the next week we'll be able to stick independent creatures on the map and have their behaviour emerge (e.g. run away when injured, without having the circumstances specifically programmed for, instead a safety influence map gets selected as a target for movement with a higher priority as the creature gets more injured). In the future, the weightings on the modifiers could be in turn influenced by reinforcement learning.

Comment Spam Attack!

The Recursion King blog has been the victim of a random and bizarre comment spam attack. Fourteen of the more recent blog posts have been spammed with a list of links (most likely a link farmer trying to fool Google's page ranking system into moving them further up the searches and closer to page one). I didn't realise that the blog was popular enough to be the victim of such an attack... as it clearly is, I may have to blog a bit more often ;)

Tuesday, 1 July 2008

Windows in a virtual machine

Is the answer to every problem with windows (and as Microsoft put it, modern operating systems in general) to run it inside of a virtual machine? According to this article here,
Goodbye, XP. Hello, Midori , Microsoft are working on a long term project to have the OS as managed code. To some extent this is not a surprise (after all .Net has been a great success, as have other virtual machine implementations such as Java, Flash and Shockwave to name a few) as they offer platform independence (you target the virtual machine and not the platform itself), potentially increased security as the code can be checked and monitored before it is run and arguably very good performance (I had a conversation a couple of months ago with a games developer who said that if you know how the .Net garbage collector works you can equal C++'s speed with C#, and also look at how the Flash 9 player is very quick too).

But an OS running in a virtual machine. Is this the answer? If modern operating system architecture is too old, too designed for a non networked 24/7 age, then we better think about alternatives. Alternatives that include running the whole shebang using virtualisation on a seperate core to a lightweight OS that just gets that up and running. Or perhaps a version of linux on a ROM chip that lets you surf the web and chat like Asus are doing. Or perhaps an OS that boots from the web (kind of like switching to boot from network in your BIOS).

What will be the future paradigm for operating systems be?