Hello PlanetKDE and everyone! 🙂
In this post, I’ll try to lay out details of my GSoC project, Integrating the SMARTS Game AI System into Gluon.
Gluon:
Gluon is a powerful library that aids in game creation. It is also bundled with a compact GUI called GluonCreator, that eases game development and a Gluon_qtplayer for playing games developed in Gluon. Gluon has immense scope to become a gaming haven for Linux users.
A GameProject in Gluon is a collection of Assets like Sounds And Images. Scenes, a type of Asset, contain GameObjects that are the characters or objects in the game, Components that define the logic that drives these GameObjects.
Game AI:
Game Artificial Intelligence, pretty much a self-explanatory term, determines the behavior of game-characters based on the game scenario. Its primary aim is to bring NPCs as close to real life characters as possible, by mimicking real-life thoughts and responses of that particular character. Take, for instance, a first person game in which, if you mess with normally-jovial people on the road side, they bonk you on the head in response, or an ingame dog which simulates a real one (like chasing cats instinctively). Pardon me if those were lame examples 😛
Computer Go would be a simple example of an AI implementation in gaming. It is similar to Chess, though Chess engines are more inclined towards brute force techniques(choosing the best move out of many based on the scenario). This is perhaps why Chess Engines can beat human GMs, and in contrast, the best Go Engine is still a novice.
Now, wouldn’t you want to play games with an interactive game character rather than a boring NPC which does the same stuff over and over? Wouldn’t you want to play against an NPC that shows natural intelligence and competitiveness rather than toggling its efficiency levels between ‘Easy’, ‘Medium’ and ‘Hard’? This is where Game AI pitches in! 😀
SMARTS Game AI System:
Game AI development techniques have been evolving over time, and each technique has tried to squash the drawbacks of its predecessor. With this trend comes Behavior Trees, a prospective technique that patches holes in the presently widespread (Hierarchical) Finite State Machines(HFSMs). I’m not going to go into what HFSMs are and how they work. I’m beginning to imagine you yawning already O.O
A Behavior Tree is much like a Directed Graph. It consists of a Parent Node which defines what the behavior is. Upon execution, it runs its Child nodes based on a specific algorithm and employing different types of selectors. And how is this particular behavior node selected? Based on the result of a Perception System.
Ok, example time. Mr.Dog is an NPC who generally wanders around. A Mr.Cat now wanders into the scene which is inhabited by, uh, Dog. Dog, your perception system just triggered off. You just perceived a cat, and you’ve been wired to react to the condition ‘A cat moves into your territory’. What is your reaction going to be? Oh yes, you should be running that ‘Attack!’ Behavior Tree, which runs its child nodes in the order ‘Bark’, ‘Chase’, and ‘Bite’.
Sorry for the sadistic example 😦 But that’s a gist of how Behavior Trees work. In SMARTS, this concept is implemented in the following way:
- All the behavior trees for the game are contained in a parent class called btBrain.
- The characters in the game, called ‘GameObjects’ in Gluon, or Game Characters in general, can use these behavior trees to exhibit behavior.
- The Perception System of the Game Character to external stimuli is contained in several classes which are subclasses of the btCharacter class. The btPerception class contains perception limit information as well as information atoms as instances of btPerceptionAtom, which reference bits of information found scattered throughout the game world, represented by instances of the btPerceptionInfo class.
In a nutshell, the btCharacter perceives its surroundings with the help of its perception system(btPerception, btPerceptionAtom, btPerceptionInfo), and exhibits a behavior accordingly by choosing a behavior from the btBrain class.
Stuff that I be doin’:
Hopefully I pulled that explanation off comprehensively, and that said, it would be easier now to highlight what I would be doing as part of my GSoC work for Gluon. As I said earlier, SMARTS uses the Behavior Tree structure, while Gluon is based on Components and Assets.
You’re going: “Oh yeah, you’re going to restructure SMARTS into a Gluon-like hierarchy, and then merge SMARTS into Gluon. So that Game Developers using Gluon would be able to incorporate the Behavior Tree technique in their Games!”
Right. If all goes well, and I don’t mess up. I intend to finish the project regardless of GSoC results, anyway. And oh yes, optionally, I would also be creating a KPart, a graphical frontend, for using the SMARTS Components and Assets. Kevin Whitaker’s awesome work in last year’s GSoC in coding a Node Creator Plugin for Gluon has ensured that the KPart would be an easy job. Thanks, Kevin!
Thanks loads:
To the Gluon Team, especially ahiemstra and leinir, who were patient with me and helped me through, and still help me all the time.
To the KDE Community, admins and mentors, for their help and confidence in me.
And to my friend Prasshanth who taught me Go 😀
Resources used and for further study:
SMARTS Homepage
Behavior Trees and why FSMs are losing market.
And of course, the wonderful Gluon Team’s help 🙂
I’ll be back with another blog post later!
See y’around, people! 🙂
Pranav Ravichandran 