Hey, Most of what you've written here sounds good. You definitely have the ideas right. A couple of the questions you're asking that can only really be answered in context of your game further down the line. One of the best things about OOP dev is that you can always keep tweaking the relationships your objects have with relative ease.
I think you should just dive in and start making it happen, evolve it as you go. The more OOP projects you do, the better you'll get at judging the relationships before you begin. Specific answers below: > Hi there > > I am making a rugby game in Flash 8 and am trying to get to grips with AS2 > and OOP structuring of the code. > > > > For example, the balloon is animating continually so would need to know > the > current wind speed and direction say every 1/10 of a second. > > Therefore would I need to get my balloon object, query the current weather > conditions every 1/10 second? > > Or would it be better to have the balloon object to have its own wind > speed > and wind direction property which is updated only when the weather manager > makes a change to the wind speed and direction? > This sounds better. Look into event listeners. It'd be best to have all these objects have their own wind speed properties, and to listen for updates to the weather object. This can be done with an event dispatcher and listeners. > I guess it would be a similar situation for all the other weather > influenced > objects hence they would all have properties for wind speed and wind > direction - does this sounds a good approach? > > If the weather manager is responsible for updating the wind speed and > direction properties of all these objects, do I first need to create these > objects then pass a reference to them to the weather manager when I create > the weather manager? Or is there a way to broadcast a change in the > weather > conditions that all objects can receive? > > With regards the weather manager changing the weather conditions > periodically, would it be better for it to have some sort of internal > timer > that decides when a change is made This sounds best on paper. Again, you might find you need to evolve it later. Good luck! _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
