Working on a game in Objective-C/Cocoa for OS X, and I finished the prototype as much as it’s worth being finished. It’s a mess of code, being my first game, but everything works. I’ve been reading up on the best way to put things together, and MVC seems to make the most sense, but I’m a bit confused.
Where does it start? With the controller? That seems to make the most sense to me, but how is it started? In my mess of a prototype, I have everything starting from the init of the view and going from there. Would I just do the same for the controller, and put what’s needed in the init? Or is there something else I can use to do this? If it’s started from the init, how do I init the controller?
How would I set up the game world? I currently use two arrays, one for the world (Walls, Floors, Doors, Water, Lava, etc.), and one for the items (I’ll be adding a third for characters). The map (a .plist) is loaded, and then the objects are created and added to the array it belongs to. Where do the arrays go? In the prototype, they’re also part of the view, so I guess you could say I combined the two (View and Controller) together. Would there be a Map object created for each map? Would there be a Maps object that contains all of the maps?
How does it all work together? The player presses a key, which moves the character in the game. The view would be handling the input, right? Would you send that to the controller, which would check for everything (walls, monsters, etc) in the map/other arrays, and then return the result? Or would you send it to the player, which would go to the controller, which would do all of the the checks, and then return the result?
I thought I had it pretty nicely laid out in my head, but the more I think about it, the less solid my ideas become and the more confused I get. By all means do not hesitate to draw something up if you think it will get the point across more efficiently.
If you’ve taken the time to read all of this, thank you for your patience. From what I’ve gathered, most people that write code don’t use any sort of design. After reading up on this, I can see why some people would avoid it, it’s confusing and people seem to think it isn’t worth the time. I personally think that the advantages totally outnumber the disadvantages (are there any?) and it only makes sense to keep things organized in a way that you won’t have to do a total rewrite every time you want to implement a new feature. You wouldn’t build a house, car, or an appliance without a design, why would you write a complex program without one?
I asked this question because I want to do it the right way, instead of hacking and half-assing my way to “victory”.
You may be interested in a presentation I gave to ACCU ’09 – “Adopting Model-View-Controller in Cocoa and Objective-C“.
Create a new Cocoa app project and you’ll see that there’s already a controller class provided by the template – it’s the app delegate class. Now look in
MainMenu.xib. There’s an instance of the app delegate, and it’s connected to the “File’s Owner” object’sdelegateoutlet. In this case theNSApplicationis the File’s Owner; it’s the thing that wantedMainMenuto be unpacked. So this really is the delegate of the application.That means we’ve got something which is a controller object, can talk to the
NSApplicationinstance, and can have outlets to all the other objects in the XIB. That makes it a great place to set up the initial state of the application – i.e. to be the “entry point” for your app. In fact the entry point should be the-applicationDidFinishLaunching:method. That’s called once the application has finished all of the stuff needed to get your app into a stable, running state – in other words Cocoa is happy that it’s done what it needs to and everything else is up to you.-applicationDidFinishLaunching:is the place where you want to create or restore the initial Model, which is the representation of the application’s state (you could also think of it as representing the user’s document, if that analogy is suitable for your app – document-based apps are only a little more complex than the default) and tell the View how to represent things to the user. In many apps you don’t need to load the whole Model when the app has launched; for a start it can be slow and use more memory than you need, and secondly the first View probably doesn’t display every single bit about the Model. So you just load the bits you need in order to show the user what’s up; you’re Controlling the interaction between the View and the Model.If you need to display other information in a different View – for example if your main View is a master view and you need to show a detail editor – then when the user tells you what they want to do you need to set that up. They tell you by performing some action, which you could handle in the app delegate. You then create a new Controller to back the new View, and tell it where to get the Model information it needs. You could hold the other View objects in a separate XIB, so they’re only loaded when they’re needed.
We can work out what objects we’re modeling by analysing your statement above – you may not realise it, but you’ve sketched out a specification :-). There’s a world which contains walls, doors etc., so we know we need objects for those, and that they should belong to a World object. But we also have items and characters – how do they interact with a world? Can a place contain water and a character? If so, perhaps the world is made up of Locations, and each Location can have a wall or a door or whatever, and it can also have items and characters. Note that if I write it like this, it seems that the item belongs to the location, not the location to the item. I would say “the mat has a cat on it” rather than “the cat has a mat underneath it”.
So simply think about what you want your game world to represent, and the relationships between the things in the game. This is called domain modeling, because you’re describing the things in the game world rather than trying to describe things in the software world. If it helps, write down a few sentences describing the game world, and look for the verbs and nouns like I did in the last paragraph.
Now some of your nouns will become objects in the software, some will become attributes of other objects. The verbs will be actions (i.e. methods). But either way, it will be easier to think about if you consider what you’re trying to model first, instead of jumping straight down to the software.
I like to follow the “tell, don’t ask” policy, which says that you command an object to do something rather than asking it to give you the information to make the decision. That way, if the behaviour changes, you only need to modify the object being told. What this means for your example is that the View handles a keypress event (it does because they’re handled by
NSControl), and it tells the Controller that this event occurred. Let’s say the View receives a “left arrow” keypress, and the Controller decides this means the player should move left. I would just tell the player “move left”, and let the player sort out what happens when moving left means bumping into the wall or a monster.To explain why I want to do it that way around, imagine that you add in game 1.1 the ability for the player to swim. Now the player has some
ableToSwimproperty, so you need to change the player. If you’re telling the player to move left, then you update the player to know what moving left over water means depending on whether they can swim. If instead the Controller asks the player about moving left and makes the decision, then the Controller needs to know to ask about being able to swim, and needs to know what it means near water. As does any other controller object in the game that might interact with a player, as does the controller in game for iPhone ;-).