Thread: [Algorithms] Ideas for an AI scheme
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Stuart G. <gda...@gx...> - 2009-12-15 20:05:24
|
Hi, 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? I'd like to make sure I'm not over-engineering it (it's not something I've tried before) :) What I'm thinking of is a hybrid hierarchical FSM / behaviour tree scheme. The hierarchical FSM structure would be defined in XML, and each state/transition could be defined either to reference a state/transition coded in C++ or a script. A state would yield a behaviour when executed (possibly a composite behaviour, which is where the behaviour trees come in). The behaviour could either be one defined in C++ or a behaviour tree defined in XML which has C++ behaviours as its nodes. A behaviour should ultimately yield object commands, such as "accelerate in direction d", or "fire weapon", etc. Steering-related behaviours (such as going to a particular position) could delegate to a steering pipeline. Does this make sense as a scheme? I realise there's a lot to code there, which is why I'm asking beforehand - but is it a sensible way to go? Also, does anyone have any alternative suggestions please? Cheers, Stuart |
|
From: Jon W. <jw...@gm...> - 2009-12-15 20:35:28
|
Will you have tools to generate the XML, or will game designers code the XML by hand? Have you looked at existing middleware packages with state machine set-ups, like AI.Implant, SimBionics, xaitment etc? (I don't think Kynapse is that high leve, but I could be wrong) Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz < gda...@gx...> wrote: > Hi, > > 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? I'd like to make sure I'm not > over-engineering it (it's not something I've tried before) :) > > What I'm thinking of is a hybrid hierarchical FSM / behaviour tree > scheme. The hierarchical FSM structure would be defined in XML, and each > state/transition could be defined either to reference a state/transition > coded in C++ or a script. A state would yield a behaviour when executed > (possibly a composite behaviour, which is where the behaviour trees come > in). The behaviour could either be one defined in C++ or a behaviour > tree defined in XML which has C++ behaviours as its nodes. A behaviour > should ultimately yield object commands, such as "accelerate in > direction d", or "fire weapon", etc. Steering-related behaviours (such > as going to a particular position) could delegate to a steering pipeline. > > Does this make sense as a scheme? I realise there's a lot to code there, > which is why I'm asking beforehand - but is it a sensible way to go? > Also, does anyone have any alternative suggestions please? > > Cheers, > Stuart > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Stuart G. <gda...@gx...> - 2009-12-15 22:10:12
|
I had been planning to write the XML files by hand (it's a hobby game, so the only game designer is me) - but judging by Indy's response it looks like I should think about writing a tool. I'm hoping to write the code myself for this game rather than use middleware because I want to understand how it all fits together (part of the reason I'm writing the game is to make sure I've seen how to write as many different subsystems as possible, because I want to understand what everyone else is doing ultimately) - but I'd be interested to see how it's done properly nonetheless. I'll take a look :) Cheers, Stuart Jon Watte wrote: > Will you have tools to generate the XML, or will game designers code > the XML by hand? > Have you looked at existing middleware packages with state machine > set-ups, like AI.Implant, SimBionics, xaitment etc? (I don't think > Kynapse is that high leve, but I could be wrong) > > Sincerely, > > jw > > -- > Americans might object: there is no way we would sacrifice our living > standards for the benefit of people in the rest of the world. > Nevertheless, whether we get there willingly or not, we shall soon > have lower consumption rates, because our present rates are > unsustainable. > > > > On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz > <gda...@gx... <mailto:gda...@gx...>> wrote: > > Hi, > > 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? I'd like to make sure > I'm not > over-engineering it (it's not something I've tried before) :) > > What I'm thinking of is a hybrid hierarchical FSM / behaviour tree > scheme. The hierarchical FSM structure would be defined in XML, > and each > state/transition could be defined either to reference a > state/transition > coded in C++ or a script. A state would yield a behaviour when > executed > (possibly a composite behaviour, which is where the behaviour > trees come > in). The behaviour could either be one defined in C++ or a behaviour > tree defined in XML which has C++ behaviours as its nodes. A behaviour > should ultimately yield object commands, such as "accelerate in > direction d", or "fire weapon", etc. Steering-related behaviours (such > as going to a particular position) could delegate to a steering > pipeline. > > Does this make sense as a scheme? I realise there's a lot to code > there, > which is why I'm asking beforehand - but is it a sensible way to go? > Also, does anyone have any alternative suggestions please? > > Cheers, > Stuart > > ------------------------------------------------------------------------------ > 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... > <mailto:GDA...@li...> > 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 > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list |
|
From: Nicholas \Indy\ R. <ar...@gm...> - 2009-12-15 22:19:16
|
It also depends on the scale of the FSM, I've been able to hand manage a FSM of about 10 different states before without a too large problem, which may be closer to the count in a hobby game then the FSM we used in the last game I worked on, which I think shipped with with over 100 states, and countless transitions. Indy On Tue, Dec 15, 2009 at 2:09 PM, Stuart Golodetz <gda...@gx...> wrote: > I had been planning to write the XML files by hand (it's a hobby game, so > the only game designer is me) - but judging by Indy's response it looks like > I should think about writing a tool. > > I'm hoping to write the code myself for this game rather than use middleware > because I want to understand how it all fits together (part of the reason > I'm writing the game is to make sure I've seen how to write as many > different subsystems as possible, because I want to understand what everyone > else is doing ultimately) - but I'd be interested to see how it's done > properly nonetheless. I'll take a look :) > > Cheers, > Stuart > > Jon Watte wrote: > > Will you have tools to generate the XML, or will game designers code the XML > by hand? > Have you looked at existing middleware packages with state machine set-ups, > like AI.Implant, SimBionics, xaitment etc? (I don't think Kynapse is that > high leve, but I could be wrong) > Sincerely, > jw > > -- > Americans might object: there is no way we would sacrifice our living > standards for the benefit of people in the rest of the world. Nevertheless, > whether we get there willingly or not, we shall soon have lower consumption > rates, because our present rates are unsustainable. > > > > On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz > <gda...@gx...> wrote: >> >> Hi, >> >> 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? I'd like to make sure I'm not >> over-engineering it (it's not something I've tried before) :) >> >> What I'm thinking of is a hybrid hierarchical FSM / behaviour tree >> scheme. The hierarchical FSM structure would be defined in XML, and each >> state/transition could be defined either to reference a state/transition >> coded in C++ or a script. A state would yield a behaviour when executed >> (possibly a composite behaviour, which is where the behaviour trees come >> in). The behaviour could either be one defined in C++ or a behaviour >> tree defined in XML which has C++ behaviours as its nodes. A behaviour >> should ultimately yield object commands, such as "accelerate in >> direction d", or "fire weapon", etc. Steering-related behaviours (such >> as going to a particular position) could delegate to a steering pipeline. >> >> Does this make sense as a scheme? I realise there's a lot to code there, >> which is why I'm asking beforehand - but is it a sensible way to go? >> Also, does anyone have any alternative suggestions please? >> >> Cheers, >> Stuart >> >> >> ------------------------------------------------------------------------------ >> 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 > > ________________________________ > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ > 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 > |
|
From: Stuart G. <gda...@gx...> - 2009-12-15 22:30:27
|
I think my FSM's definitely going to be nearer to 10 states than 100. All the same, it would be nice to write a GUI tool at a later stage - sounds like an interesting project :) I guess integrating the scripting might not be such a bad idea either. Nicholas "Indy" Ray wrote: > It also depends on the scale of the FSM, I've been able to hand manage > a FSM of about 10 different states before without a too large problem, > which may be closer to the count in a hobby game then the FSM we used > in the last game I worked on, which I think shipped with with over 100 > states, and countless transitions. > > Indy > > On Tue, Dec 15, 2009 at 2:09 PM, Stuart Golodetz > <gda...@gx...> wrote: > >> I had been planning to write the XML files by hand (it's a hobby game, so >> the only game designer is me) - but judging by Indy's response it looks like >> I should think about writing a tool. >> >> I'm hoping to write the code myself for this game rather than use middleware >> because I want to understand how it all fits together (part of the reason >> I'm writing the game is to make sure I've seen how to write as many >> different subsystems as possible, because I want to understand what everyone >> else is doing ultimately) - but I'd be interested to see how it's done >> properly nonetheless. I'll take a look :) >> >> Cheers, >> Stuart >> >> Jon Watte wrote: >> >> Will you have tools to generate the XML, or will game designers code the XML >> by hand? >> Have you looked at existing middleware packages with state machine set-ups, >> like AI.Implant, SimBionics, xaitment etc? (I don't think Kynapse is that >> high leve, but I could be wrong) >> Sincerely, >> jw >> >> -- >> Americans might object: there is no way we would sacrifice our living >> standards for the benefit of people in the rest of the world. Nevertheless, >> whether we get there willingly or not, we shall soon have lower consumption >> rates, because our present rates are unsustainable. >> >> >> >> On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz >> <gda...@gx...> wrote: >> >>> Hi, >>> >>> 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? I'd like to make sure I'm not >>> over-engineering it (it's not something I've tried before) :) >>> >>> What I'm thinking of is a hybrid hierarchical FSM / behaviour tree >>> scheme. The hierarchical FSM structure would be defined in XML, and each >>> state/transition could be defined either to reference a state/transition >>> coded in C++ or a script. A state would yield a behaviour when executed >>> (possibly a composite behaviour, which is where the behaviour trees come >>> in). The behaviour could either be one defined in C++ or a behaviour >>> tree defined in XML which has C++ behaviours as its nodes. A behaviour >>> should ultimately yield object commands, such as "accelerate in >>> direction d", or "fire weapon", etc. Steering-related behaviours (such >>> as going to a particular position) could delegate to a steering pipeline. >>> >>> Does this make sense as a scheme? I realise there's a lot to code there, >>> which is why I'm asking beforehand - but is it a sensible way to go? >>> Also, does anyone have any alternative suggestions please? >>> >>> Cheers, >>> Stuart >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >> ________________________________ >> ------------------------------------------------------------------------------ >> 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 >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > ------------------------------------------------------------------------------ > 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 |
|
From: Nicholas \Indy\ R. <ar...@gm...> - 2009-12-15 21:30:46
|
The largest problem I see is that XML (or really any text based format) is terrible for design and editing of any complicated FSM, I think a FSM is one of the instances where a graphical editing tool actually makes sense. Indy On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz <gda...@gx...> wrote: > Hi, > > 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? I'd like to make sure I'm not > over-engineering it (it's not something I've tried before) :) > > What I'm thinking of is a hybrid hierarchical FSM / behaviour tree > scheme. The hierarchical FSM structure would be defined in XML, and each > state/transition could be defined either to reference a state/transition > coded in C++ or a script. A state would yield a behaviour when executed > (possibly a composite behaviour, which is where the behaviour trees come > in). The behaviour could either be one defined in C++ or a behaviour > tree defined in XML which has C++ behaviours as its nodes. A behaviour > should ultimately yield object commands, such as "accelerate in > direction d", or "fire weapon", etc. Steering-related behaviours (such > as going to a particular position) could delegate to a steering pipeline. > > Does this make sense as a scheme? I realise there's a lot to code there, > which is why I'm asking beforehand - but is it a sensible way to go? > Also, does anyone have any alternative suggestions please? > > Cheers, > Stuart > > ------------------------------------------------------------------------------ > 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 > |
|
From: <lei...@co...> - 2009-12-16 00:02:57
|
I actually dumped all my xml except for exporting assets from XSI. I switched to lua. Even if you have a tool to edit the files you still have to write code for DOM and/or SAX parsing. I found I could just get more done much faster with lua. Leigh Nicholas "Indy" Ray wrote: > The largest problem I see is that XML (or really any text based > format) is terrible for design and editing of any complicated FSM, I > think a FSM is one of the instances where a graphical editing tool > actually makes sense. > > Indy > > On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz > <gda...@gx...> wrote: > >> Hi, >> >> 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? I'd like to make sure I'm not >> over-engineering it (it's not something I've tried before) :) >> >> What I'm thinking of is a hybrid hierarchical FSM / behaviour tree >> scheme. The hierarchical FSM structure would be defined in XML, and each >> state/transition could be defined either to reference a state/transition >> coded in C++ or a script. A state would yield a behaviour when executed >> (possibly a composite behaviour, which is where the behaviour trees come >> in). The behaviour could either be one defined in C++ or a behaviour >> tree defined in XML which has C++ behaviours as its nodes. A behaviour >> should ultimately yield object commands, such as "accelerate in >> direction d", or "fire weapon", etc. Steering-related behaviours (such >> as going to a particular position) could delegate to a steering pipeline. >> >> Does this make sense as a scheme? I realise there's a lot to code there, >> which is why I'm asking beforehand - but is it a sensible way to go? >> Also, does anyone have any alternative suggestions please? >> >> Cheers, >> Stuart >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > ------------------------------------------------------------------------------ > 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 > > |
|
From: <der...@he...> - 2009-12-16 00:28:46
|
I've been playing around with Lua for AI HFSM and state implementations and I'd also suggest it as a good match for the OP's case. A code base I worked with a lot recently used Ruby to generate CPP files and data structures offline and that could have been used very elegantly to build AI. The only thing I'm unsure of there is whether Ruby is a useful runtime option. At least with Lua you know that it can and has been significantly used at runtime on some not particularly powerful platforms. On the topic raised, the scheme the OP is proposing to implement sounds like a solid approach to me. Cheers Derek Sent via BlackBerry® from Vodafone -----Original Message----- From: "lei...@co..." <lei...@co...> Date: Tue, 15 Dec 2009 17:02:04 To: Game Development Algorithms<gda...@li...> Subject: Re: [Algorithms] Ideas for an AI scheme I actually dumped all my xml except for exporting assets from XSI. I switched to lua. Even if you have a tool to edit the files you still have to write code for DOM and/or SAX parsing. I found I could just get more done much faster with lua. Leigh Nicholas "Indy" Ray wrote: > The largest problem I see is that XML (or really any text based > format) is terrible for design and editing of any complicated FSM, I > think a FSM is one of the instances where a graphical editing tool > actually makes sense. > > Indy > > On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz > <gda...@gx...> wrote: > >> Hi, >> >> 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? I'd like to make sure I'm not >> over-engineering it (it's not something I've tried before) :) >> >> What I'm thinking of is a hybrid hierarchical FSM / behaviour tree >> scheme. The hierarchical FSM structure would be defined in XML, and each >> state/transition could be defined either to reference a state/transition >> coded in C++ or a script. A state would yield a behaviour when executed >> (possibly a composite behaviour, which is where the behaviour trees come >> in). The behaviour could either be one defined in C++ or a behaviour >> tree defined in XML which has C++ behaviours as its nodes. A behaviour >> should ultimately yield object commands, such as "accelerate in >> direction d", or "fire weapon", etc. Steering-related behaviours (such >> as going to a particular position) could delegate to a steering pipeline. >> >> Does this make sense as a scheme? I realise there's a lot to code there, >> which is why I'm asking beforehand - but is it a sensible way to go? >> Also, does anyone have any alternative suggestions please? >> >> Cheers, >> Stuart >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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 |
|
From: Jon W. <jw...@gm...> - 2009-12-16 00:43:25
|
An alternative form of structured data is JSON. Especially if you use Flex or SpiderMonkey or V8 for scripting... (which is a real alternative these days!) The benefit is similar to Lua, except with some of the JavaScript implementations, you get a GUI system free with adoption! (thinking of WebKit or the Mozilla stuff here) Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. On Tue, Dec 15, 2009 at 4:28 PM, <der...@he...> wrote: > I've been playing around with Lua for AI HFSM and state implementations and > I'd also suggest it as a good match for the OP's case. > > A code base I worked with a lot recently used Ruby to generate CPP files > and data structures offline and that could have been used very elegantly to > build AI. The only thing I'm unsure of there is whether Ruby is a useful > runtime option. At least with Lua you know that it can and has been > significantly used at runtime on some not particularly powerful platforms. > > On the topic raised, the scheme the OP is proposing to implement sounds > like a solid approach to me. > > Cheers > Derek > > Sent via BlackBerry® from Vodafone > > -----Original Message----- > From: "lei...@co..." <lei...@co...> > Date: Tue, 15 Dec 2009 17:02:04 > To: Game Development Algorithms<gda...@li...> > Subject: Re: [Algorithms] Ideas for an AI scheme > > I actually dumped all my xml except for exporting assets from XSI. I > switched to lua. Even if you have a tool to edit the files you still > have to write code for DOM and/or SAX parsing. I found I could just get > more done much faster with lua. > > Leigh > > Nicholas "Indy" Ray wrote: > > The largest problem I see is that XML (or really any text based > > format) is terrible for design and editing of any complicated FSM, I > > think a FSM is one of the instances where a graphical editing tool > > actually makes sense. > > > > Indy > > > > On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz > > <gda...@gx...> wrote: > > > >> Hi, > >> > >> 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? I'd like to make sure I'm not > >> over-engineering it (it's not something I've tried before) :) > >> > >> What I'm thinking of is a hybrid hierarchical FSM / behaviour tree > >> scheme. The hierarchical FSM structure would be defined in XML, and each > >> state/transition could be defined either to reference a state/transition > >> coded in C++ or a script. A state would yield a behaviour when executed > >> (possibly a composite behaviour, which is where the behaviour trees come > >> in). The behaviour could either be one defined in C++ or a behaviour > >> tree defined in XML which has C++ behaviours as its nodes. A behaviour > >> should ultimately yield object commands, such as "accelerate in > >> direction d", or "fire weapon", etc. Steering-related behaviours (such > >> as going to a particular position) could delegate to a steering > pipeline. > >> > >> Does this make sense as a scheme? I realise there's a lot to code there, > >> which is why I'm asking beforehand - but is it a sensible way to go? > >> Also, does anyone have any alternative suggestions please? > >> > >> Cheers, > >> Stuart > >> > >> > ------------------------------------------------------------------------------ > >> 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 > >> > >> > > > > > ------------------------------------------------------------------------------ > > 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 > > > > > > > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ > 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 > |
|
From: Jose M. <jos...@ya...> - 2009-12-16 10:02:09
|
I agree! Lua it's a great choice to represent AI (and other things) in a game. Google FSM Lua and you will see some implementations samples, like this one: http://lua-users.org/wiki/FiniteStateMachine By the way, I'm replacing all my XML stuff by Lua tables. Much easier to handle. --- Em ter, 15/12/09, der...@he... <der...@he...> escreveu: > De: der...@he... <der...@he...> > Assunto: Re: [Algorithms] Ideas for an AI scheme > Para: "Game Development Algorithms" <gda...@li...> > Data: Terça-feira, 15 de Dezembro de 2009, 22:28 > I've been playing around with Lua for > AI HFSM and state implementations and I'd also suggest it as > a good match for the OP's case. > > A code base I worked with a lot recently used Ruby to > generate CPP files and data structures offline and that > could have been used very elegantly to build AI. The only > thing I'm unsure of there is whether Ruby is a useful > runtime option. At least with Lua you know that it can and > has been significantly used at runtime on some not > particularly powerful platforms. > > On the topic raised, the scheme the OP is proposing to > implement sounds like a solid approach to me. > > Cheers > Derek > > Sent via BlackBerry® from Vodafone > > -----Original Message----- > From: "lei...@co..." > <lei...@co...> > Date: Tue, 15 Dec 2009 17:02:04 > To: Game Development Algorithms<gda...@li...> > Subject: Re: [Algorithms] Ideas for an AI scheme > > I actually dumped all my xml except for exporting assets > from XSI. I > switched to lua. Even if you have a tool to edit the > files you still > have to write code for DOM and/or SAX parsing. I > found I could just get > more done much faster with lua. > > Leigh > > Nicholas "Indy" Ray wrote: > > The largest problem I see is that XML (or really any > text based > > format) is terrible for design and editing of any > complicated FSM, I > > think a FSM is one of the instances where a graphical > editing tool > > actually makes sense. > > > > Indy > > > > On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz > > <gda...@gx...> > wrote: > > > >> Hi, > >> > >> 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? I'd > like to make sure I'm not > >> over-engineering it (it's not something I've tried > before) :) > >> > >> What I'm thinking of is a hybrid hierarchical FSM > / behaviour tree > >> scheme. The hierarchical FSM structure would be > defined in XML, and each > >> state/transition could be defined either to > reference a state/transition > >> coded in C++ or a script. A state would yield a > behaviour when executed > >> (possibly a composite behaviour, which is where > the behaviour trees come > >> in). The behaviour could either be one defined in > C++ or a behaviour > >> tree defined in XML which has C++ behaviours as > its nodes. A behaviour > >> should ultimately yield object commands, such as > "accelerate in > >> direction d", or "fire weapon", etc. > Steering-related behaviours (such > >> as going to a particular position) could delegate > to a steering pipeline. > >> > >> Does this make sense as a scheme? I realise > there's a lot to code there, > >> which is why I'm asking beforehand - but is it a > sensible way to go? > >> Also, does anyone have any alternative suggestions > please? > >> > >> Cheers, > >> Stuart > >> > >> > ------------------------------------------------------------------------------ > >> 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 > >> > >> > > > > > ------------------------------------------------------------------------------ > > 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 > > > > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ > 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 > ____________________________________________________________________________________ Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com |
|
From: Stuart G. <gda...@gx...> - 2009-12-16 12:39:50
|
On a scripting language note - I'm using AngelScript at the moment (+ a home-built wrapper to make the binding process easy), just wondering what you guys think of it as a viable alternative to Lua? It seems ok for a hobby project (and I actually thought it seemed easier to integrate than Lua when I was making the decision), but is it suitable for a commercial game? (I've come across performance and ease-of-scripting as potential downsides - just wondering whether those are the key issues when you're deciding. For my purposes, the ease-of-scripting wasn't really an issue because I'm a programmer working on my own, and the performance wasn't a killer problem because my game's not cutting-edge, so AngelScript seemed like a good fit.) Cheers (and thanks for the feedback), Stu der...@he... wrote: > I've been playing around with Lua for AI HFSM and state implementations and I'd also suggest it as a good match for the OP's case. > > A code base I worked with a lot recently used Ruby to generate CPP files and data structures offline and that could have been used very elegantly to build AI. The only thing I'm unsure of there is whether Ruby is a useful runtime option. At least with Lua you know that it can and has been significantly used at runtime on some not particularly powerful platforms. > > On the topic raised, the scheme the OP is proposing to implement sounds like a solid approach to me. > > Cheers > Derek > > Sent via BlackBerry® from Vodafone > > -----Original Message----- > From: "lei...@co..." <lei...@co...> > Date: Tue, 15 Dec 2009 17:02:04 > To: Game Development Algorithms<gda...@li...> > Subject: Re: [Algorithms] Ideas for an AI scheme > > I actually dumped all my xml except for exporting assets from XSI. I > switched to lua. Even if you have a tool to edit the files you still > have to write code for DOM and/or SAX parsing. I found I could just get > more done much faster with lua. > > Leigh > > Nicholas "Indy" Ray wrote: > >> The largest problem I see is that XML (or really any text based >> format) is terrible for design and editing of any complicated FSM, I >> think a FSM is one of the instances where a graphical editing tool >> actually makes sense. >> >> Indy >> >> On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz >> <gda...@gx...> wrote: >> >> >>> Hi, >>> >>> 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? I'd like to make sure I'm not >>> over-engineering it (it's not something I've tried before) :) >>> >>> What I'm thinking of is a hybrid hierarchical FSM / behaviour tree >>> scheme. The hierarchical FSM structure would be defined in XML, and each >>> state/transition could be defined either to reference a state/transition >>> coded in C++ or a script. A state would yield a behaviour when executed >>> (possibly a composite behaviour, which is where the behaviour trees come >>> in). The behaviour could either be one defined in C++ or a behaviour >>> tree defined in XML which has C++ behaviours as its nodes. A behaviour >>> should ultimately yield object commands, such as "accelerate in >>> direction d", or "fire weapon", etc. Steering-related behaviours (such >>> as going to a particular position) could delegate to a steering pipeline. >>> >>> Does this make sense as a scheme? I realise there's a lot to code there, >>> which is why I'm asking beforehand - but is it a sensible way to go? >>> Also, does anyone have any alternative suggestions please? >>> >>> Cheers, >>> Stuart >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >>> >>> >> ------------------------------------------------------------------------------ >> 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 >> >> >> > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ > 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 |
|
From: Adrian H. <ad...@ad...> - 2009-12-16 15:06:44
|
Hi, I know little about AngelScript, but from memory, I remember being told that it provides an option to convert directly into C++ code that can then be compiled (and if necessary manually optimised) as a solution to any speed issue? Adrian Stuart Golodetz wrote: > On a scripting language note - I'm using AngelScript at the moment (+ > a home-built wrapper to make the binding process easy), just wondering > what you guys think of it as a viable alternative to Lua? It seems ok > for a hobby project (and I actually thought it seemed easier to > integrate than Lua when I was making the decision), but is it suitable > for a commercial game? (I've come across performance and > ease-of-scripting as potential downsides - just wondering whether > those are the key issues when you're deciding. For my purposes, the > ease-of-scripting wasn't really an issue because I'm a programmer > working on my own, and the performance wasn't a killer problem because > my game's not cutting-edge, so AngelScript seemed like a good fit.) > > Cheers (and thanks for the feedback), > Stu > > der...@he... wrote: >> I've been playing around with Lua for AI HFSM and state implementations and I'd also suggest it as a good match for the OP's case. >> >> A code base I worked with a lot recently used Ruby to generate CPP files and data structures offline and that could have been used very elegantly to build AI. The only thing I'm unsure of there is whether Ruby is a useful runtime option. At least with Lua you know that it can and has been significantly used at runtime on some not particularly powerful platforms. >> >> On the topic raised, the scheme the OP is proposing to implement sounds like a solid approach to me. >> >> Cheers >> Derek >> >> Sent via BlackBerry® from Vodafone >> >> -----Original Message----- >> From: "lei...@co..." <lei...@co...> >> Date: Tue, 15 Dec 2009 17:02:04 >> To: Game Development Algorithms<gda...@li...> >> Subject: Re: [Algorithms] Ideas for an AI scheme >> >> I actually dumped all my xml except for exporting assets from XSI. I >> switched to lua. Even if you have a tool to edit the files you still >> have to write code for DOM and/or SAX parsing. I found I could just get >> more done much faster with lua. >> >> Leigh >> >> Nicholas "Indy" Ray wrote: >> >>> The largest problem I see is that XML (or really any text based >>> format) is terrible for design and editing of any complicated FSM, I >>> think a FSM is one of the instances where a graphical editing tool >>> actually makes sense. >>> >>> Indy >>> >>> On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz >>> <gda...@gx...> wrote: >>> >>> >>>> Hi, >>>> >>>> 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? I'd like to make sure I'm not >>>> over-engineering it (it's not something I've tried before) :) >>>> >>>> What I'm thinking of is a hybrid hierarchical FSM / behaviour tree >>>> scheme. The hierarchical FSM structure would be defined in XML, and each >>>> state/transition could be defined either to reference a state/transition >>>> coded in C++ or a script. A state would yield a behaviour when executed >>>> (possibly a composite behaviour, which is where the behaviour trees come >>>> in). The behaviour could either be one defined in C++ or a behaviour >>>> tree defined in XML which has C++ behaviours as its nodes. A behaviour >>>> should ultimately yield object commands, such as "accelerate in >>>> direction d", or "fire weapon", etc. Steering-related behaviours (such >>>> as going to a particular position) could delegate to a steering pipeline. >>>> >>>> Does this make sense as a scheme? I realise there's a lot to code there, >>>> which is why I'm asking beforehand - but is it a sensible way to go? >>>> Also, does anyone have any alternative suggestions please? >>>> >>>> Cheers, >>>> Stuart >>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >>> >>> >> >> >> ------------------------------------------------------------------------------ >> 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 >> ------------------------------------------------------------------------------ >> 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 > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 |
|
From: Stuart G. <gda...@gx...> - 2009-12-16 15:25:04
|
I know you can save compiled bytecode and reload it, although the generated bytecode isn't cross-platform. Not sure about compiling it to C++. I'm not at the point where it might be a performance bottleneck yet (since I'm still designing the AI), so I haven't experimented too much with the compilation approach so far. Stu Adrian Hirst wrote: > Hi, > > I know little about AngelScript, but from memory, I remember being > told that it provides an option to convert directly into C++ code that > can then be compiled (and if necessary manually optimised) as a > solution to any speed issue? > > Adrian > > Stuart Golodetz wrote: >> On a scripting language note - I'm using AngelScript at the moment (+ >> a home-built wrapper to make the binding process easy), just >> wondering what you guys think of it as a viable alternative to Lua? >> It seems ok for a hobby project (and I actually thought it seemed >> easier to integrate than Lua when I was making the decision), but is >> it suitable for a commercial game? (I've come across performance and >> ease-of-scripting as potential downsides - just wondering whether >> those are the key issues when you're deciding. For my purposes, the >> ease-of-scripting wasn't really an issue because I'm a programmer >> working on my own, and the performance wasn't a killer problem >> because my game's not cutting-edge, so AngelScript seemed like a good >> fit.) >> >> Cheers (and thanks for the feedback), >> Stu >> >> der...@he... wrote: >>> I've been playing around with Lua for AI HFSM and state implementations and I'd also suggest it as a good match for the OP's case. >>> >>> A code base I worked with a lot recently used Ruby to generate CPP files and data structures offline and that could have been used very elegantly to build AI. The only thing I'm unsure of there is whether Ruby is a useful runtime option. At least with Lua you know that it can and has been significantly used at runtime on some not particularly powerful platforms. >>> >>> On the topic raised, the scheme the OP is proposing to implement sounds like a solid approach to me. >>> >>> Cheers >>> Derek >>> >>> Sent via BlackBerry® from Vodafone >>> >>> -----Original Message----- >>> From: "lei...@co..." <lei...@co...> >>> Date: Tue, 15 Dec 2009 17:02:04 >>> To: Game Development Algorithms<gda...@li...> >>> Subject: Re: [Algorithms] Ideas for an AI scheme >>> >>> I actually dumped all my xml except for exporting assets from XSI. I >>> switched to lua. Even if you have a tool to edit the files you still >>> have to write code for DOM and/or SAX parsing. I found I could just get >>> more done much faster with lua. >>> >>> Leigh >>> >>> Nicholas "Indy" Ray wrote: >>> >>>> The largest problem I see is that XML (or really any text based >>>> format) is terrible for design and editing of any complicated FSM, I >>>> think a FSM is one of the instances where a graphical editing tool >>>> actually makes sense. >>>> >>>> Indy >>>> >>>> On Tue, Dec 15, 2009 at 11:35 AM, Stuart Golodetz >>>> <gda...@gx...> wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> 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? I'd like to make sure I'm not >>>>> over-engineering it (it's not something I've tried before) :) >>>>> >>>>> What I'm thinking of is a hybrid hierarchical FSM / behaviour tree >>>>> scheme. The hierarchical FSM structure would be defined in XML, and each >>>>> state/transition could be defined either to reference a state/transition >>>>> coded in C++ or a script. A state would yield a behaviour when executed >>>>> (possibly a composite behaviour, which is where the behaviour trees come >>>>> in). The behaviour could either be one defined in C++ or a behaviour >>>>> tree defined in XML which has C++ behaviours as its nodes. A behaviour >>>>> should ultimately yield object commands, such as "accelerate in >>>>> direction d", or "fire weapon", etc. Steering-related behaviours (such >>>>> as going to a particular position) could delegate to a steering pipeline. >>>>> >>>>> Does this make sense as a scheme? I realise there's a lot to code there, >>>>> which is why I'm asking beforehand - but is it a sensible way to go? >>>>> Also, does anyone have any alternative suggestions please? >>>>> >>>>> Cheers, >>>>> Stuart >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 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 >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>>> >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> ------------------------------------------------------------------------------ >>> 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 >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> 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 > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 |
|
From: Ryan J. <rya...@gm...> - 2009-12-16 06:02:57
|
Given that you mention building a "composite behavior" from the tree, I'm assuming you are looking to build a concurrent hierarchical finite state machine rather than a standard HFSM. In a concurrent HFSM, a node in the tree might have multiple active child states running at once. I've used concurrent HFSMs on multiple titles in the past. The heaviest use of the system was from a third person shooter. The ability to reuse and combine small sub-states to create more complicated behavior proved very useful. For example, different behaviors of moving, aiming, and reloading could all be built separately and then mixed and matched based on higher level transitions (e.g. on a vehicle, hiding in cover, fighting from cover). It was also fairly easy to append new concurrent behaviors onto an agent. There were two main downsides to the system that I recall. The first was related to the complexity of it all. In a non-concurrent system, you are only in a single branch at any given time. This makes it much easier to visualize what is happening in the agent as well as debug how you got to a given state. It is also a bit easier to grasp the behavior design in a non-concurrent system. By the end we had ambient animals, enemies, scripted allies, vehicles, bosses, and so on all able to start mixing and matching these behavior building blocks. It wasn't that fun to digest. The second issue was related to different concurrent behaviors fighting for control of a similar feature (e.g. movement). When new features are added, it is easy for conflicts to crop up which require messing with the hierarchy a bunch to work out. To alleviate this nightmare, we ended up supporting multiple "requests" to different systems. For example, if one behavior was telling an agent to move towards cover and then another behavior was telling him to evade an incoming vehicle, the commands from the vehicle evasion could be set as a higher priority. I don't think this is the best solution, but it was much more successful in creating a stable game on schedule than trying to constantly rework the hierarchy. As for editing the state machines, it was all in the custom scripting language used by the rest of the game. Having a graphical interface would have been great, but the priority of it never worked its way high enough up the todo list. The states were basically just data structures (similar to the XML approach you suggest but probably much less verbose with syntax). At least 99% of the transitions and states were written in C++ for performance reasons although we did support scripted ones. If you are doing a smaller indie game, I think it would be fine to text edit stuff and the system as a whole should work. As for doing a very large scale big budget game, I'd definitely weigh all your options. I've since become a fan of systems where the transitions were automatically generated for lower level AI behavior - something like a goal/action approach. - Ryan |
|
From: Stuart G. <gda...@gx...> - 2009-12-16 13:01:41
|
Ryan Juckett wrote: > > Given that you mention building a "composite behavior" from the tree, > I'm assuming you are looking to build a concurrent hierarchical finite > state machine rather than a standard HFSM. In a concurrent HFSM, a > node in the tree might have multiple active child states running at once. > To be honest, I hadn't got much further than the design I originally suggested (well, I have a few more diagrams this end). By "composite behaviour" I guess I effectively meant branch nodes in a behaviour tree. I'd realised there were going to be some concurrency issues involved when I got round to building the behaviour trees, but I hadn't really come across the idea of a concurrent HFSM. I think it possibly sounds a little over my head at this point :), but it does seem an interesting approach. Are you thinking that a standard HFSM won't be ideal for what I'm trying to do though? I'm trying to come up with something I can do in the time really (I'm writing up a PhD thesis at the same time and trying to get the game up and running so I can use it as a demo for job interviews among other things, although I ideally also want it to be quite flexible). > > I've used concurrent HFSMs on multiple titles in the past. The > heaviest use of the system was from a third person shooter. The > ability to reuse and combine small sub-states to create more > complicated behavior proved very useful. For example, different > behaviors of moving, aiming, and reloading could all be built > separately and then mixed and matched based on higher level > transitions (e.g. on a vehicle, hiding in cover, fighting from cover). > It was also fairly easy to append new concurrent behaviors onto an agent. > > There were two main downsides to the system that I recall. The first > was related to the complexity of it all. In a non-concurrent system, > you are only in a single branch at any given time. This makes it much > easier to visualize what is happening in the agent as well as debug > how you got to a given state. It is also a bit easier to grasp the > behavior design in a non-concurrent system. By the end we had ambient > animals, enemies, scripted allies, vehicles, bosses, and so on all > able to start mixing and matching these behavior building blocks. It > wasn't that fun to digest. > > The second issue was related to different concurrent behaviors > fighting for control of a similar feature (e.g. movement). When new > features are added, it is easy for conflicts to crop up which require > messing with the hierarchy a bunch to work out. To alleviate this > nightmare, we ended up supporting multiple "requests" to different > systems. For example, if one behavior was telling an agent to move > towards cover and then another behavior was telling him to evade an > incoming vehicle, the commands from the vehicle evasion could be set > as a higher priority. I don't think this is the best solution, but it > was much more successful in creating a stable game on schedule than > trying to constantly rework the hierarchy. > > As for editing the state machines, it was all in the custom scripting > language used by the rest of the game. Having a graphical interface > would have been great, but the priority of it never worked its way > high enough up the todo list. The states were basically just data > structures (similar to the XML approach you suggest but probably much > less verbose with syntax). At least 99% of the transitions and states > were written in C++ for performance reasons although we did support > scripted ones. > > If you are doing a smaller indie game, I think it would be fine to > text edit stuff and the system as a whole should work. As for doing a > very large scale big budget game, I'd definitely weigh all your > options. I've since become a fan of systems where the transitions were > automatically generated for lower level AI behavior - something like a > goal/action approach. Automatically-generated transitions sound interesting - any useful links by any chance? (I tried Googling for "fsm automatic transition generation goal action" but got a load of stuff on automatic code generation instead unfortunately...) Cheers, Stu > - Ryan > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 |
|
From: Ryan J. <rya...@gm...> - 2009-12-16 19:55:15
|
> > To be honest, I hadn't got much further than the design I originally > suggested (well, I have a few more diagrams this end). By "composite > behaviour" I guess I effectively meant branch nodes in a behaviour tree. I'd > realised there were going to be some concurrency issues involved when I got > round to building the behaviour trees, but I hadn't really come across the > idea of a concurrent HFSM. I think it possibly sounds a little over my head > at this point :), but it does seem an interesting approach. Are you thinking > that a standard HFSM won't be ideal for what I'm trying to do though? I'm > trying to come up with something I can do in the time really (I'm writing up > a PhD thesis at the same time and trying to get the game up and running so I > can use it as a demo for job interviews among other things, although I > ideally also want it to be quite flexible). > > I simple HFSM should be fine. Lots of games have used that approach. It might have some more code duplication between behaviours, but has the benefit of being very explicit. Don't overcomplicate things until you find a need for it. > Automatically-generated transitions sound interesting - any useful links by > any chance? (I tried Googling for "fsm automatic transition generation goal > action" but got a load of stuff on automatic code generation instead > unfortunately...) > What I was refering to was somthing like a mix between a HFSM and the GOAP ( http://web.media.mit.edu/~jorkin/goap.html) stuff from F.E.A.R. It can maintain the explicit higher level transitions and let the system automatically figure the rest out. Regardless, a non-concurrent HFSM should be fine for what you are doing. - Ryan |
|
From: Stuart G. <gda...@gx...> - 2009-12-16 21:38:53
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ryan Juckett wrote:
<blockquote
cite="mid:e86...@ma..."
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
<div class="im">
<blockquote type="cite">To be honest, I hadn't got much further
than the design I originally suggested (well, I have a few more
diagrams this end). By "composite behaviour" I guess I effectively
meant branch nodes in a behaviour tree. I'd realised there were going
to be some concurrency issues involved when I got round to building the
behaviour trees, but I hadn't really come across the idea of a
concurrent HFSM. I think it possibly sounds a little over my head at
this point :), but it does seem an interesting approach. Are you
thinking that a standard HFSM won't be ideal for what I'm trying to do
though? I'm trying to come up with something I can do in the time
really (I'm writing up a PhD thesis at the same time and trying to get
the game up and running so I can use it as a demo for job interviews
among other things, although I ideally also want it to be quite
flexible). </blockquote>
</div>
</div>
</blockquote>
<div>I simple HFSM should be fine. Lots of games have used that
approach. It might have some more code duplication between
behaviours, but has the benefit of being very explicit. Don't
overcomplicate things until you find a need for it.</div>
<div> </div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">Automatically-generated
transitions sound interesting - any useful links by any chance? (I
tried Googling for "fsm automatic transition generation goal action"
but got a load of stuff on automatic code generation instead
unfortunately...)<br>
</div>
</blockquote>
<div> </div>
<div>What I was refering to was somthing like a mix between a HFSM
and the GOAP (<a moz-do-not-send="true"
href="http://web.media.mit.edu/%7Ejorkin/goap.html">http://web.media.mit.edu/~jorkin/goap.html</a>)
stuff from F.E.A.R. It can maintain the explicit higher level
transitions and let the system automatically figure the rest
out. Regardless, a non-concurrent HFSM should be fine for what you are
doing.</div>
</div>
</blockquote>
Cheers for the link :)<br>
<br>
Stu<br>
<blockquote
cite="mid:e86...@ma..."
type="cite">
<div class="gmail_quote"></div>
<br>
- Ryan
<pre wrap="">
<hr size="4" width="90%">
------------------------------------------------------------------------------
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
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/verizon-dev2dev">http://p.sf.net/sfu/verizon-dev2dev</a> </pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
GDAlgorithms-list mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GDA...@li...">GDA...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list">https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list</a>
Archives:
<a class="moz-txt-link-freetext" href="http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list">http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list</a></pre>
</blockquote>
</body>
</html>
|
|
From: Johan G. <spi...@gm...> - 2009-12-18 09:36:24
|
Hi just wanted to share how we did it for a very small project which was more or less a hobby project aswell, the AI was very simplistic and the way we chose to implement it was also very simplistic and was based on a binary decision tree, within code we created a number of decision nodes, we had 2 kind of nodes, binary and unary. This didnt prevent us from having multiple choices since we simply added branching nodes that depending on the input would branch left or right, by stringing them together we could create switch like statements. The neat part about this solution was that we created a graphical tool that allowed us to drag & drop nodes on a blank sheet and create both very simple or more complex AI brains very fast. This solution will not suit more advanced AI but if your game is not that demanding of the AI I can really encourage you to try it out. You also get to write a simply GUI editor! It could also be very interesting to expand on the concept and incorporate the decision trees into states etc, we never took it that far though. |
|
From: Jon W. <jw...@gm...> - 2009-12-19 01:51:13
|
First: Why don't you make your runtime support scaling? Second: If you can't do that, then what you said you were doing would be the right thing to do, assuming you implement it correctly. For the hierarchy: Remove scale from the node transform (times parent extracted scale) Bake scale into any attached geometry foreach child: do the same, passing along any scale you've extracted Extracting scale from a matrix is easy as long as there is no skew or rotated scale center; simply measure the length of each of the basis vectors (X, Y, Z) and normalize to 1. No full decomposition needed. Sincerely, jw -- Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. On Fri, Dec 18, 2009 at 3:11 PM, lei...@co... < lei...@co...> wrote: > Hello everyone. > > My XSI exporter supports exporting a small hierarchy of objects. One > of it's uses is to allow the game to find parts like the tracks, body, > wheel, turret etc. All works fine until I purchased some models that > are the wrong scale and I decide to scale them in XSI to 1 unit is 1m. > Now my hierarchy has scaling in it. This becomes a mess with bounding > volumes on parts and frame of references having scaling in it. I > finally found an option in XSI to freeze all the scaling but I was > wondering how can I have my build tool do the same thing so that I won't > have problems down the road? Also its bugging me. > > I tried resolving all the nodes into model space and then using inverse > transforms to resolve the local transforms on each part. It didn't work. > > Leigh > > > > > > > ------------------------------------------------------------------------------ > 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 > |
|
From: <lei...@co...> - 2009-12-19 02:06:51
|
Thanks Jon. Its a j2me game with very limited resources so I am not supporting anything I don't need. I realize that a matrix mul is a mul whether there is a scaling in it or not so there isn't really a performance issue for rendering. It's more for the game logic where I am using basis vectors for direction or determining distance between parts. Also I hate debugging data that requires me to remember everything is scaled for no good reason. As it turns out XSI's freeze scaling leaves all the pivot points unchanged so it's of limited use. For now I am going to fix up the pivot points inside of XSI since the project is small enough. I will cut and paste your suggestion into my build to since I do want to get it going correct at some point. Thanks again! Leigh Jon Watte wrote: > First: Why don't you make your runtime support scaling? > > Second: If you can't do that, then what you said you were doing would > be the right thing to do, assuming you implement it correctly. For the > hierarchy: > > Remove scale from the node transform (times parent extracted scale) > Bake scale into any attached geometry > foreach child: > do the same, passing along any scale you've extracted > > Extracting scale from a matrix is easy as long as there is no skew or > rotated scale center; simply measure the length of each of the basis > vectors (X, Y, Z) and normalize to 1. No full decomposition needed. > > Sincerely, > > jw > > > -- > Americans might object: there is no way we would sacrifice our living > standards for the benefit of people in the rest of the world. > Nevertheless, whether we get there willingly or not, we shall soon > have lower consumption rates, because our present rates are > unsustainable. > > > > On Fri, Dec 18, 2009 at 3:11 PM, lei...@co... > <mailto:lei...@co...> <lei...@co... > <mailto:lei...@co...>> wrote: > > Hello everyone. > > My XSI exporter supports exporting a small hierarchy of objects. One > of it's uses is to allow the game to find parts like the tracks, body, > wheel, turret etc. All works fine until I purchased some models that > are the wrong scale and I decide to scale them in XSI to 1 unit is 1m. > Now my hierarchy has scaling in it. This becomes a mess with bounding > volumes on parts and frame of references having scaling in it. I > finally found an option in XSI to freeze all the scaling but I was > wondering how can I have my build tool do the same thing so that I > won't > have problems down the road? Also its bugging me. > > I tried resolving all the nodes into model space and then using > inverse > transforms to resolve the local transforms on each part. It > didn't work. > > Leigh > > > > > > ------------------------------------------------------------------------------ > 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... > <mailto:GDA...@li...> > 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 > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list |
|
From: Jeff G. <jef...@ho...> - 2010-11-09 17:40:24
|
I am making a dx9 ao shader. I have the ao greyscale image in a texture, and the rendered scene in the backbuffer. What blendmodes (dx9 fixed function pipeline) would I need to multiply the ao texture against the backbuffer. something like this : backbuffer=backbuffer*aotexture I currently have the following, but it is not blending with the backbuffer. gRender->SetRenderState(D3DRS_ALPHABLENDENABLE,TRUE); gRender->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_ZERO); gRender->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_SRCCOLOR); gRender->SetTextureStageState( 0, D3DTSS_COLOROP, D3DTOP_MODULATE ); gRender->SetTextureStageState( 0, D3DTSS_COLORARG1, D3DTA_TEXTURE ); gRender->SetTextureStageState( 0, D3DTSS_COLORARG2, D3DTA_DIFFUSE ); gRender->SetTextureStageState( 0, D3DTSS_ALPHAOP, D3DTOP_SELECTARG2 ); gRender->SetTextureStageState( 0, D3DTSS_ALPHAARG2, D3DTA_DIFFUSE ); Is it even possible to blend a texture with the existing backbuffer? Thanks |
|
From: Fabian G. <ry...@gm...> - 2010-11-09 19:33:04
|
On 11/9/2010 9:40 AM, Jeff Gooloolie wrote: > I am making a dx9 ao shader. > > I have the ao greyscale image in a texture, and the rendered scene in > the backbuffer. > > What blendmodes (dx9 fixed function pipeline) would I need to multiply > the ao texture against the backbuffer. > > something like this : backbuffer=backbuffer*aotexture > > I currently have the following, but it is not blending with the backbuffer. > > gRender->SetRenderState(D3DRS_ALPHABLENDENABLE,TRUE); > gRender->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_ZERO); > gRender->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_SRCCOLOR); This blend setup looks right for what you're trying to do. > gRender->SetTextureStageState( 0, D3DTSS_COLOROP, D3DTOP_MODULATE ); > gRender->SetTextureStageState( 0, D3DTSS_COLORARG1, D3DTA_TEXTURE ); > gRender->SetTextureStageState( 0, D3DTSS_COLORARG2, D3DTA_DIFFUSE ); > gRender->SetTextureStageState( 0, D3DTSS_ALPHAOP, D3DTOP_SELECTARG2 ); > gRender->SetTextureStageState( 0, D3DTSS_ALPHAARG2, D3DTA_DIFFUSE ); Did you double-check whether the diffuse colors are set up correctly? Also, what is the effect you're seeing? If you're only using texture stage 0, did you remember to disable stage 1 (which also auto-disables all following ones)? > Is it even possible to blend a texture with the existing backbuffer? Yes, certainly - way back before even double-texturing texture hardware, alpha blending was the *only* way to do this. This is not really an algorithmic question though - consider asking such questions on the directxdev mailing list. Cheers, -Fabian |
|
From: Stuart G. <gda...@gx...> - 2009-12-16 12:40:09
|
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 |
|
From: <lei...@co...> - 2009-12-18 23:12:37
|
Hello everyone. My XSI exporter supports exporting a small hierarchy of objects. One of it's uses is to allow the game to find parts like the tracks, body, wheel, turret etc. All works fine until I purchased some models that are the wrong scale and I decide to scale them in XSI to 1 unit is 1m. Now my hierarchy has scaling in it. This becomes a mess with bounding volumes on parts and frame of references having scaling in it. I finally found an option in XSI to freeze all the scaling but I was wondering how can I have my build tool do the same thing so that I won't have problems down the road? Also its bugging me. I tried resolving all the nodes into model space and then using inverse transforms to resolve the local transforms on each part. It didn't work. Leigh |
|
From: Jonathan H. <web...@cl...> - 2010-10-12 16:44:06
|
I intend to create a server side application to handle incoming connection requests. I want the server side AI (non-cut scenes) to be a local connection on the server. What programming languages do you recommend (preferrably on a Linux based machine, but I am open minded) for handling these 'telnet' type connections to receive commands from the client? Do you know of any existing frameworks for this that are capable of handling a numerous number of connections? I would be able to separate the number of connections based on region (and therefore separate the servers) within the game (which would all access a centralized database), but I want something where each zone of the game can handle at least 100 player characters and the enemy NPCs would connect locally. The difficult part is that I would need each connection to be able to access many variables of the other connections or to somehow share information to report back player locations, orientation, customizations, current animations, etc. for the client side. I am only accustomed to each connection being entirely separate and unique. Have any of you seen an implementation of this that can be used as an example? Jonathan Hickman |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X