In a message of Wed, 04 Jul 2007 14:38:46 -0300, "Giuliano Vilela" writes: >------=_Part_146600_24953701.1183570726405 >Content-Type: text/plain; charset=ISO-8859-1; format=flowed >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >Definetly some of my concerns too... Looking foward to the posts here =) > >On 7/4/07, Andre LeBlanc <[EMAIL PROTECTED]> wrote: >> >> I've spent the past 24 hours or so looking through the source for the P >GU >> Engine and Phil's Pyweek3 example code, and its convinced me that I nee >d to >> do alot of re-writing. I'm trying to figure out how to best organize t >he >> various states of my RPG, but I'm a little stuck. should a state be >> responsible for all of the rendering at a given time? for example in t >he >> case of a top-down RPG, Walking around town is a state, being in a batt >le is >> a state, but what about talking to an npc or a vendor in a town? This >would >> have to bring up menus for the user to navigate, but the scenery in the > town >> should still be painting. NPCs can walk around while you are talking to > a >> shop owner, so should that be a separate state? I like the way the 'ro >oms' >> were subclassed and imported for the pyweek3 game and that's what I'm g >oing >> for, but how would you transition between these 2 states, if indeed the >y >> should be separate. >> >>
Ah, i think you want these to be views, not states. And the users should have the choice to 'bring up a walking around view' and 'bring up a haggling with storekeeper view' etc. Now if you are in location L3-the-volcano, and there is no shopkeeper associated with L3-the-volcano, then bringing up the shopkeeper view should probably prodice the 'there is nobody here to haggle with' message, but that is still a view. You want to keep your game state in this thing that is called your Model, and then have many ways to view (Views) your game state. Laura
