Re: Ideas for an AI scheme
Stuart Golodetz <[email protected]>
| Newsgroups | gmane.games.devel.algorithms |
|---|---|
| Message-ID | <[email protected]> |
Tom Plunket wrote: > Stuart Golodetz <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list