kAI - a component based AI Tool

kAI - a component based AI tool

For my third year project for my degree, I developed kAI - a component based AI tools. kAI is a library and visual tool for developing AI’s specifically for games.

The way it works is coders produces code behaviours which designers can then import in to the tool. kAI behaviours are then a collection of these code behaviours and other kAI behaviours arranged into a network. 

The tool is similar to Kismet/Blueprint - the visual programming tool found in Unreal. The key difference is that is specialised towards AI. As a result, you can't use programming primitives like for loops (hence no programming style bugs and hangs). Instead, all behaviours can be either active or inactive and are updated accordingly. 

The update system (detailed in 3.2.2.1 in the report) means that what frame any behaviours become active is deterministic, despite the non-determinism of the order in which the nodes are updated. 

kAI also supports real time debugging using the editor. In this, you can see what the behaviours are doing in real time. The editor will show what nodes are active and what current values data ports have

An example behaviour from the editor

The project can be downloaded from GitHub (including pre-compiled executables) and it includes 2 example projects. The source can be found at https://github.com/thk123/kAI and the executables at: https://github.com/thk123/kAI/releases/tag/v1.0

The report is a lengthy document (~90 pages) that explains a lot about the project. Chapter 4 is a user guide and is probably the most useful part of the document. It contains detailed walk thoroughs of most of the features of kAI. The report is called ProjectReport.pdf and is at the root of the repository.

My final report

It was a lot of fun to develop and I developed some pretty neat code including operator constraints for generic functions that I'll tidy that up in to a standalone library at some point, and converting functions into nodes with ports. 

In-spite of the limited development time (which can be seen in the "functional" interface that the editor has), the tool proved surprisingly useful when creating AIs and the debugger is very powerful for this kind of thing. I believe kAI to be flexible enough that you could make just about any AI in it and still get some benefit (even if you just used kAI as a general purpose visual debugging tool).

Update

Long time no see. A lot has happened, I have some stuff I want to write about and in general I want to get back in to the habit of writing. I find that if I don't write for too long, my sentences start to lose non-essential words and everything reads like it was meant to be a series of bullet points.

I am currently working as an intern programmer at Born Ready Games! (nb, standard disclaimer about these being my views not those of BRG or any affiliates etc. etc.). As a small company, I have had the opportunity to try lots of different things. Our most recent game is Strike Suit Zero (Steam, GOG), which came out in January (I got my first hand experience of crunch).

Next year I will be entering my final year of my degree, and as such am required to do a 3rd year project. I have about a bazzilion ideas for this and all of them are too complicated to do in 5 years, but I am slowly zoning in on one (or more accurately, a linked pair). I plan to talk about these more at a later date and then when I start work on them, have my development diary up here too.

I've also developed a couple of games in some jams (eg, Global Game Jam). I am planning on setting up a basic site that'll support hosting of games since I've made now I have a few.

I'm going to blog about this TED talk by Amanda Palmer: The Art of Asking later this week. I am going to address how I think it relates to games, specifically indie games & the current trend of Kick Starters.

Front Row on Games

I while back I posted about how the BBC Radio 4 program Front Row doesn't cover video games. On Friday they ran this show:

Front Row - Naomi Alderman on video games

It is well worth the time to listen to it. Molyneux, as usual, gets a bit carried away! I always find these shows part reassuring and part frustrating. They have so much ground to cover and have to touch on so many issues that, as someone who is invested in all this, find infuriating that they spend so little time on things that warrant entire shows. However, the closing point is fantastic: Probably the main reason games don't get the cultural recognition they deserve is simply because critics find them too difficult. But instead of saying games should be made easier, she instead concludes that people should invest the time now so they don't miss out on the future of the most exciting art form of the moment.

Anyway, apologies for not posting, very busy with uni stuff. I took part in Global Game Jam 2012 and worked with a team of people from Lionhead which was very exciting. You can play Gloop here. It is a racing game made in UDK where the path you took on the previous lap determines the next lap. You are only allowed off the track for a certain amount of time. The aim is to race for as long as possible - you can increase your time by collecting power ups that are off the edge of the track. Sometimes they will be too far off to drive to collect and instead you must morph the track towards them.

I also took part in the Warwick Game Design Societies game jam where we made games for the Pirate Kart 2012. We made two games. The first: Magic Mooshrooms is a snake-esque game where you control and cow and the more mushrooms you eat, the more trippy the game becomes. The second (not yet published) game was called mad Cow Stacking Attacking defender (or something) and you had to fight off oncoming cows who would form a set of stairs to climb over your wall. These are both proof of how could XNA is at a tool - I worked with two people who hadn't made a game (certainly not in 48 hours) and we were able to produce two games that I am very proud of.

I will try and write up a post mortem for both jams but currently super busy. I am working at doublesix for my internship next year and hopefully, since I won't have piles of home work, will be able to blog a little more

The disconnect between story and gameplay pacing in RPGs

Soren Johnson has recently written a couple of posts about the disconnect between theme and mechanics. One example he gives is applicable to just about any free roaming RPG like the Elder Scrolls series. The theme, or story, is about being a hero and defeating some huge evil. However, the mechanics are about scavenging, hardly heroic stuff.

In this post I am going to consider another disconnect that occurs in this genre: pacing in gameplay and narrative. The story will be telling of an impending threat and that speed is of the essence; the gameplay will be rewarding you for taking your time and actively avoiding advancing the story. I must have played Oblivion for about 100 hours and countless in game days, I have become leader of the Mage's Guild, gone on a killing spree and numerous other things and the imminent threat still hasn't actually developed (except when I try to deal with it).

All of this stops the story meaning anything. The threat never feels genuine; yes it would be nice for you to defeat it, but if you don't, it's no big deal. Instead, I think that stories should be crafted to match the inherent gameplay pacing of an RPG.

One example that came to my mind recently is global warming. It has the same giant scope as a normal story - the end of the world - but the time scale is in terms of years rather than days. This will allow players to explore without feeling like the threat is made up. It could also be worked so that the gameplay of scavenging, or recycling, fitted with the theme as well.

A puzzle game - Weeping Angels

The basic premise of this game is based around the BBC drama Doctor Who. One recurring race (well, recurred once) of aliens are the Weeping Angels. They move incredibly fast and then kill you. The catch is, they can only move when no one is looking. While someone looks at them, they appear to simply be stone statues. This makes for some properly scary drama and feature in my two favourite episodes of Doctor Who. However, it also suggested quite an interesting strategy game to me.

Or a puzzle game. Troy Goodfellow describes strategy games as elaborate puzzle games (or something to that effect). I think it is more a gradient and this got me in to an interesting discussion on twitter about the merits and demerits of single solution puzzles. That for me is the difference between a strategy game and a puzzle game. In a strategy game, you are given a set of rules and tools and then you have to work out how to defeat the opposition: a puzzle to solve, but one with an infinite (or seemingly infinite) number of solutions and where there is very rarely a right or wrong answer.

At the other end of the spectrum is something like Braid where only one solution exists and you must work out what this is. Games like this are much harder to get in to - you can't just mess around and hope to achieve the answer (at least once you get to the more challenging end of the game)

Obviously you get in to hazy semantic battles here: is Peggle a strategy game; it does have multiple solutions. I would argue yes because you don't work out the entire solution; instead you analyse the situation and work out a logical next step.

The basis of the game would be you would have a set number of people who you have to get from one side of a room to the other. They would each be capable of looking in one direction and while the angles were in their line of sight.

So the question is do I make this a strategy game or a puzzle game (by the above gradient). Do I create each room so you have to move and place your people in a specific place to get across the room, or do I make it more tactical. It would certainly be possible to mix it up, or even choose something in the middle such as elements of the room that have to be solved in one way, but a lot of it could be done in a more free way.

Scale (Or "I am important too")

When multiplayer digital gaming was new, there were huge technical hurdles with everything developers tried to do. As a result, games blindly sought greater technological achievements such as number of simultaneous players. While these issues still exist, they are quickly becoming less significant with wide spread broadband and fibre optic cables quickly becoming main stream.

(For this post, I will assume we are talking about a shooter, obviously MMO games have many more simultaneous connexions, but that is something different).

Everyone likes the idea of hundreds of people all playing in the same game at the same time. You can truly create that war time feeling with bullets whizzing past you and players shouting. Suddenly it isn't you charging some enemies, it is you and loads of other people. It sounds really awesome.

However, I don't believe we should simply be going for as many people as technically possible. Halo 3 supports 16 players in a 8 versus 8 battle. I think this is pushing the limit for standard first person shooter mechanics. Already, you start to feel insignificant. In a balanced 4 versus 4 game in Halo, each death matters and each kill feels like cause for celebration. In Big Team Battle, this simply isn't the case. You charge in because one death is trivial; there is no tension.

I believe the more people you add, the worse the problem will get. Does this mean that I think that large count first person shooters are doomed to failure despite sounding awesome? Well, no.

Instead of giving up, a large scale game needs extra work to make the player feel significant. If every player is doing the same thing, then each players actions become virtually irrelevant: if they fail, either someone on their team will do it, or it won't be their fault because everyone failed.

Instead I think large numbers should be used as a backdrop for smaller games. You and a small group of people would be tasked to doing something. There would be an equal group on the opposite team tasked with doing the opposite. The players could still kill people who are not directly related to their mission, but it would not count towards the final score.

The problem with this is then you are not really a team, just lots of games going on on one map. Sure, you still create a sense of scale, but without a sense of being a team, you would feel no compulsion to attack the other team. I think this would almost completely counter balance the benefits. How many wars have enemies walking past one and another not shooting because they are not related to what they have been tasked to do. The player would be frequently and strongly reminded that they are not in a war, defeating the entire point.

The obvious solution is to have each teams success count as a point towards its team. The problem with this is then you get back to the original problem: getting that point doesn't matter, you won't win because of that point or loose by your failure. While it may not be a complete solution, I think it does reset the counting. If you have 8 players per team, then your kills don't matter. But if there are only 4 teams of 4 per side, then you have 16 players per side (so double) but you would hopefully have the tension of a 4 on 4.

Stillness

I was walking back from baby sitting tonight and I realised that late at night was actually one of my favourite times to be walking. Everything is so quite and still. I think the reason it is such a nice enviroment is because it is such a juxtaposition to the norm of everything moving and making a noise. It gives me a chance to reflect on the day, I don't have any music, there is no one else about, no rush and my mind is already winding down.

It got me thinking about how rare stillness is as a game enviroment. As we strive after ever more realistic graphics with more interactive elements, nothing is ever still. The idea of intentionally leaving an area empty of people, animations and sound is almost unheard of. Even the peaceful evenings on Assasins's Creed 2 still have people milling about.

One thing I have been thinking about is the idea of pacing in games. For a lot of games, the designers expect players to manage their own down time. Playing though Call of Duty for example, if you want a breather, you have to stop the game; the story doesn't have any slow paced sections. I think the idea of of stillness is tied to this: designers are unwillinging to provide a sensorly underwhelming experience in the same way they are unwilling to intentionally let of the action.

I hope anyone who went to GDC had a nice time, some very interesting talks and I can't wait for Fable 3.