Re: [Algorithms] Ideas for an AI scheme

[Stuart G. <gda...@gx...>]

Tom Plunket wrote:
> Stuart Golodetz <gda...@gx...> wrote:
>
>   
>> I've been having a think about how to approach the AI for my game and 
>> was wondering if I could have some thoughts on the scheme I'm pondering 
>> before I sit down and implement it please?
>>     
>
> The approach I like to take when starting on an unknown task is to just start building tests for what I expect the functionality to do. Against a unit testing library like UnitTest++ this is really easy.
>
> In cases where you truly don't know what you want to do, just spew out one possible option at a time and see if it makes sense to code against. This happens to me regularly enough, especially in cases where the stated requirements are fairly vague. I may change directions after every test attempt, or I may even rough out something fairly complete before deciding to change tacks, the key is that the tests that you're writing serve as a prototypical client of your new code. The nice bang-on effect of making your API simple to reduce typing in your tests just sweetens the pot!
>   
I find the way I usually end up doing the actual design of the code 
architecture is to write a lot of stub classes (every method just throws 
an exception initially - I'm not trying to run the program) in a 
separate single-file test project and play around with them until they 
all fit together :) That's worked quite well in the past, actually, 
because shoving everything in one file for test purposes makes it really 
easy to change things without too much faffing around. The test code can 
become the basis for a proper unit test once the system's up and running.

The problem I tend to have more is one of not planning all the way to 
the end - i.e. not always considering future requirements when planning 
a system (sometimes it's not possible, but still). There've been a few 
occasions when writing this game when I've realised that a subsystem 
that worked perfectly well earlier for what it was designed for just 
wasn't up to the task for something I was doing now. Then again, I 
suppose you get good at refactoring that way... I guess being able to 
plan things to the end is something that comes with a fuller 
understanding of what you're trying to build.
> For what it's worth, hierarchical finite state machines are known to work for many problems, even when the data is represented by XML. While a graphical tool can ease development of medium-sized HFSMs, they can still get unwieldy fast.
>   
Thanks. The main reason I was thinking XML for the file format is 
actually because I have a parser for it already up and running and I'm 
getting fed up with writing new file loaders at this point...! I think 
my state machines aren't likely to be on an industrial scale, so it 
sounds like it should be possible to make it work.

Stu
> Good luck,
> -tom!
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> ------------------------------------------------------------------------
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list