Summary of the problem of reusable AI?

I’ve tried to express this before, but with questionable success. In working with a student today I came up with this summary. I am also aware that I still have not completed the final part describing my Proc system (I kind of took a break from all this online community thing in June). I will get to it again in time for when I next teach my AI course. I have ported it to C# in Unity, by the way. That was an interesting  journey, which I hope to blog about too in the future. Anyway back to, once again, searching for a good way to explain my perspective on this whole problem of reusable behaviours and implementing complex behaviours in games.

Resuable AI (modular behaviour) is a desirable thing to have in game programming, which seems to present a greater challenge that it should. After all reusable code is what good programming is all about, and we don’t have to jump through hoops (if you will pardon the pun) to implement the reusability of a function in most programming languages.

It is indeed interesting that this issue does not exist in most modern programming languages, which are implemented on an FSM (albeit hierarchical) architecture. A point that is often missed is that these issues are reflected in the original problem of modularity in early computers. The solution to this was the invention of the subroutine, which became the first important abstraction in computer science (See “The Humble Programmer” by Dijkstra). This abstraction allowed for reusable code.

Often when programmers talk about Finite State Machines what they really mean is an implementation of a virtual (state) machine which suffers from the same kind of problems that would occur if computers did not have the necessary hardware to implement a subroutine. In fact, sometimes these virtual machines are so primitive that they even lack conditional branching (part of the basic minimal functionality required of any central processing unit).

So the problem is not in the concept of the Finite State Machine per se, but naive implementations of virtual machines implementing finite state mcahines which do not include the equivalent of a subroutine, and thus do not allow for modularity. A hierarchical finite state machine (HFSM) is what you get by default in all procedural programming languages, and this provides the ability to create modular code.

This therefore begs the question “Why do programmers create a virtual machine, and call it a (Hierarchical) Finite State Machine, instead of simply programming what they need directly in the HFSM of the native language?” The answer is simple: It is because of the need to support multitasking when working in a language that does not readily support it.

This causes me to ask “Why don’t we just build our computers and languages to support what we need in the first place?”.

 

 

2 Responses to “Summary of the problem of reusable AI?”

  1. Gianluca Musumeci Says:

    Dear Dino, I was wondering that actually you could release a conversion of Kick Off for iPhone/iPad. There’s a wonderful device called “iCade” that could be used to emulate the Kick Off controls and have a perfect conversion. Think it over. Ciao from Italy from a very old fan of yours.

    • Dino Dini Says:

      I’ve seen those, they are cool🙂 My problem is simply one of having the manpower to get it done without any budget. But I hope eventually I’ll get there…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: