For Cocoa Game developers

Member
Posts: 312
Joined: 2006.10
Post: #31
But then, you lose portability in a sense. Say you want to create a line or path. You could put what I did (if it worked :/) in a method, create a BezierPath then a create a path from those points. Your way, you have to create the path in the View, and that loses the ability to use mouse event for saying creating a rect or circle or any other geometric figure without having a bunch of if-else if statements.

See how the view loses portability?

Edit - I would say in many other cases where you only need mouse input for one task, then that would be pretty portable.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #32
I really don't see what you're trying to get at. Could you clarify?

You get a constant supply of mouse coordinates and mouse downs and mouse ups as they occur in the view that is being worked with. You record where they happen in your model as you please, which can be used in any view that accesses that model. That seems pretty `portable' to me, but again, perhaps I don't understand what you're saying.
Quote this message in a reply
Member
Posts: 104
Joined: 2007.01
Post: #33
MVC is not the only way to do game design (which is the impression I get reading this thread). I've done nothing but OO design and programming for 15 years. I don't use the MVC pattern in my games or other programs, and yet they are quite portable. But then I'm relying on cross-platform libraries to take care of all the low-level details.

My OO design more closely follows the Bridge pattern. In my design, I have a graphics library consisting of a set of basic shape classes (rectangles, billboards, spheres, disks, cones, etc) that all inherit from a common base class. These classes encapsulate the OpenGL rendering, including lighting, texturing, etc. If I needed to, I could rewrite the internals of these classes to use DirectX, SDL, or anything to do the rendering, and the rest of my code would be unaffected. I can also reuse these graphic classes for any game, since they are independent of game type (2D, 3D, action, puzzle, etc).

I then have higher-level classes for the game objects that implement the game-specific object behavior (movement, AI, etc). The game object classes have graphic objects as class members (Bridge pattern). They also have separate methods for updating the object state and drawing the object (which I agree is desirable to keep separate), but in my design both methods are on the same class. The draw method just invokes draw on the low-level graphic objects.

This way, the game objects are completely encapsulated in a truly OO way, and yet the low-level rendering code is still kept separate from the game logic. As an OO guy, this feels so much more natural to me. I can call update() on an object to make it update itself, and I can call draw() on it to make it render itself. The game objects have access to the "world" or "map" object, so they can do their own collision detection and change their own behavior based on their environment. This makes then fairly autonomous. I can also serialize/deserialize each game object, which makes it very easy to save and restore the game at any point.

I think OO is quite suited for game development, and it works as well for games as it does any other kind of software development. OO is just a different mindset and a different way of programming.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #34
OOP and MVC are not different from each other. MVC is merely a conceptual technique to use. You don't *have* to use it. It's not a dogma. It's good stuff though, for various reasons already discussed. I never really gave a crap about it myself until I started multi-threading, where traditional OOP approaches that I used to use, like you describe them, broke down. MVC separation fit much better with multi-threading, and that's what really sold me on it.
Quote this message in a reply
Member
Posts: 104
Joined: 2007.01
Post: #35
I'm not knocking MVC. It's a fine approach to software design, for all the reasons that were given. But for the benefit of ThemsAllTook and others who are interested in using a more OO design, I just wanted to rebut some comments on the thread that gave the impression MVC is the only way. It isn't. There are a number of OO design patterns that will achieve the same results (namely, separation of responsibility).
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #36
Your proposed design does not separate all the responsibilities that I feel it is important to separate. I do not consider it an alternative to a proper MVC design, and I would not design any new games in that way.
Quote this message in a reply
Member
Posts: 33
Joined: 2005.08
Post Reply