That's an interesting point of discussion ... In the last game i developed (something like 2yrs ago and with one of the competitors :p) I structured the whole application with PureMVC (i had a bunch of other areas which were game-related) but when I had to develop the game itself i found that the actors (view, rederers, cameras, objects, etc) were too much "coupled" to let PureMVC's structure get in the way. Also, I feared that separating too much those objects would have had a negative impact on performances (which weren't great at the time).
So now after 2yrs, other developers are managing the rest of the app quite easily, but when it comes to the 3d or the physics I've to step in and handle the new requests, which is quite painful :) It would be great to find a wat to better "structure" also this part of my applications .. so if anyone has some advice or use cases to share i'm sure everyone would appreciate :) Bianco Alessandro 2011/3/22 Darcey Lloyd <[email protected]>: > Hi, > Anyone got any examples and source available of a simple Away3D setup using > RobotLegs? > A Hello Robot Cube example if you like? :) > Much like with the PureMVC I am not happy with how and where I have my code > to manage the camera, view.render, primitives and most of all > the interactivity of 3D primitives especially if they are considered > separate views/components. > I've quizzed some guys in both RobotLegs and PureMVC google groups & forums > but they come back with answers I'm not 100% sure about and I don't think > they are 100% sure with what is correct either, especially when it comes to > using 3D within these frameworks. > > An example: > If I was to have the following views: > Away3DView (away3d init) > Away3DMediator (Listening for notifications - turn lights on or off etc) > Away3DCameraView (camera init) > Away3DCameraMediator (Listening for camera notifications: lookat > number3D/vector/object3d etc) > Away3DRenderer (rendering on enter frame) > Away3DRednererMediator (Listening for notifications - enable / disable > rendering the view) > Away3DCubeView (just a cube of default size and at a fixed location) > Away3DCubeMediator (Listening for notifications: collision) > Away3DSphereView (just a sphere of default size and at a fixed location) > Away3DSphereMediator (Listening for notifications: collision) > > If you click the cube a notification is sent which the camera mediator > picks up and tweens to look at the cube, same for the sphere. > Now if I was to process logic requiring the monitoring of 2 or more objects > in the scene, where would this logic be placed? In the good practises > documents I've read for each of the frameworks it is recommended that a view > manage another's view. If I was not using these frameworks and my usual > simple modular based design comprising of singleton, factory & observer > patterns I would do all this in the renderer, breaking it down into multiple > classes as 1 to many child classes for managing each specific task. > eg: I wouldn't use the case statement for the code below, I would do it all > in 1 file but to example if I had many many things to check and at different > times in a larger application. > Away3DRenderManager.as > private var _collision:Boolean = false; > private function render(e:Event):void > { > Switch (mode) > { > case "check collision between cube 1 and cube 2": > _collision = new Away3DRenderCubeCollisionCheck(cube1,cube2); > break; > // Lots more case statements calling various different classes for > their specific functionality all on 1 enter frame > } > //Code to animate cubes > view.render(); > } > > Away3DRenderCubeCollisionCheck.as > private function Away3DRenderCubeCollisionCheck(cube1,cube2):Boolean > { > // Collision code > return boolean; > } > > > What's your thoughts on this? > > Any of you got an example or willing to cook up a quick RobotLegs example > using Away3D to collide 2 cubes and on collision reverse their direction? > Thanks > Darcey
