I don't see why you would use events for your view. The way I see it, is that the view handles the view and not the individual objects in the model. I feed the view coordinates and rotations and it decides what to render and where. If you use blitting to draw to the screen that's actually a performance boost instead of a loss. It also allows me to easily create a game with sprites (as in graphics, not the Flash container), just feed the angle and position into the view and it uses the angle that it got fed to select the right picture from the spritesheet and places it on the screen (if it is onscreen) using the coordinates. I also do this for parallax scrolling and tiles. Feed the screen coordinates into the view and it calculates what tiles to display where and where the parallax background should be drawn.
If I try to think a non MVC way to do that, the only thing I can come up with is have every object in your model have it's own view function. This is basicly the same, the difference is that the code is organised in a more decentralised way, but not that there's a performance cost.
Maybe my understanding of MVC is different. I have, for example a ViewPort (the main screen) and ScannerView (mini map) class that handle different visual displays of the game entities, and each handles scale and offset translation. The game entities are composite objects containing position, veloctiy, etc.
But I don't consider this to be MVC, because the entities are tightly coupled with the views-- the entities directly make calls to the view, as opposed to the view acting as an Observer. I cannot, for example, simply replace my viewport with a different viewer and turn it into, say, an ASCII text game without making changes to the entity classes.
But changing that would be really simple. Because the point of OOP is to not let other classes know about one another, and it's better to program to an interface than inheritance, then all you need to do is have a display function in your ViewPort/ScannerView that accepts a Vector/Array of display objects. Of course, depending on what it is, you might only accept Shapes or Bitmaps...
It's always better to have a separate View class. And hey, wouldn't it be cool to plug in in either 2d or 3d Views just like that?
@Squize: It's obviously never good to chop up code into tiny classes that don't do much, but it's always good to organize the code between several distinguishable classes.
Ha, I have the book they mention in the first sentence of their post. In fact, my brother lent it to me, and I just read it through, which has helped me with my understanding of course...good book...and good link! I recommend that xanderbeedle take a look!
It's definitely a helper!
It explains all of them thoroughly, and you really see uses for each one, especially since they have a case study you follow along through the whole book. Before they present any of the patterns, they describe how they want to make a text editor. Then, they relate all the patterns to individual parts of the text editor, and where/how they'd use them.
I'd say it's worth it unless you already know the design patterns quite well. Then again, the book (as they themselves say) is also meant to be more like a pattern catalog. If you need to know what to do, just flip through the book, read a few, and see which one fits best!
Thanks a lot everyone, it's been useful to see how people handle this.
The only thing I could suggest that would top this off would be some code examples!
Still don't want me to make an example? I don't think anyone has a simple enough sample of MVC to really help you out. Plus, if you're working with vector graphics, then Flash technically already has a built-in View (since you just need to call the addChild() methods on your root Sprite/MovieClip.
Trust me, I can probably make a simple MVC thing for BitmapData's in the next week if you really need something to work with.
I've got to be honest, I'm one of these people who only cares if something works, rather than how, so I've never looked at the source, but as the original is written in some form of c and the as3 version is quite a literal port, and there are no visual elements to it ( Aside from debugging ) then it's quite possible.
OOP is just a tool to do a job with, I really can't see the point in getting bogged down in semantics too much.
Doing "pure" clean oop is something people who write books and tutorials do, game coders need to get Flash performing more than writing clever code that no one will ever see.
Flash developers usually use MVC without even knowing it. It isn't on of those academy taught, "pure" clean oop, it's simply the name of what most people just used/did.
And box2d can't be MVC. It's simply a math library, which sorts out coordinates, etc. It doesn't have any of the MVC components! For example, the model of an application is where you do operations such as: a = b * c;
or box2d.checkCollisions();
Then for view...well, it's basically a class that translates functions into the visual components on screen. And control takes user input. Box2D doesn't even come close to doing any of these.
OOP is a tool to do a job with, and with every tool, there come techniques to be used with that tool to get that tool to do the best job it can! Think of it that way.
I will try to make something for you, xanderbeetle!
I tried to do as good of a job as I could in 10 minutes, but here's a small example. What it does is create a Sprite, draws some graphics into it, and then you addChild it to the View class, which is created, and then the Main class calls the view.update call, which goes through all the views children, and renders them onto itself (View extends BitmapData).
Then, the control class is where it detects keyboard input. The Main class checks with the control class if the Up, Down, Left, or Right keys are pressed, and then moves the player Sprite, whose reaction is shown in the view!
Originally Posted by TOdorus
Reply With Quote
