AS3 OOP Game Development Structure

I'm wondering what is the best practise for gamedevelopment for actioncript 3. I'm currently in the progress of creating a tile-based game, but I'm already having some troubles using seperate classes.

This is the current situation:

Main class

• Generates the tiles
• Adds player class
• Adds interface class

The interface class contains all interface elements. For example, there is an option to spawn an object into the game. This object could be placed on a selected tile.

Now the problem is a followed: The spawned object is placed within the interface class, how should the spawned obje开发者_Go百科ct be able to communicate with the tiles? This same problem arises with several other parts in the game. Like how should the player be able to interact with the spawned object? Everything is in different classes making the communcation between all these things so difficult.

Is there any standard procedure regarding game development which handles this problem?I was thinking of making a "world" class where every object should be placed somehow. But it's hard for me to actually make this with the little knowledge of this sort of structure that I posess. This is all sort of new to me, so I would appreciate it if the explanation would be as noob proof as possible. Thanks in advance!

You can use event dispatching for your objects to communicate with one another, there are several approaches available, one of the simpler approach would be for you to create a controller class whose sole responsibility would be to dispatch & listen to events, in order to inform the relevant classes of what's occurring within your game

A better approach could be to use a framework such as Robotlegs, the learning curve is a bit steeper but worth the extra effort.
http://www.robotlegs.org/

You should easily find examples & tutorials for Robotlegs.

Try to imagine the organization of the parts of your game in a slightly different way. In the first place this World class you mention could contain both the Map object also contain the Unit objects for the spawned player or creatures. The Map object which also contains Tile objects which each one have its own information as terrain and attributes. Also the Unit objects would contain the information related to each spawn. For the interaction with your player you could have a Game object that contains both the World and a representation of your player, namely a Player object, and this Game object would communicate the instructions from the player towards the World as to make things happen. As you can see each object contains other objects of finer detail, the World contains the Map that contains the Tile's, this way the higher object uses the lower finer objects and makes them all communicate between them.

This could be a good approach to start something quickly or to learn while you experiment. More complex situation require other ways of arranging all the information of the game like the Model-View-Controller structure, but you probably should not worry to much about it until you have learned enough as to know you need a better solution.

I would suggest to read a little about design patterns. A singleton Dispatcher class can help in your case, you just bind everything to it and send events from one entity to another.

The reason why not use the built-in events is that you would need your objects to be on the display list.