Re: Best Practices for Code Organization
Re: Best Practices for Code Organization
- Subject: Re: Best Practices for Code Organization
- From: Seth Willits <email@hidden>
- Date: Fri, 27 Dec 2013 11:29:52 -0800
On Dec 27, 2013, at 8:19 AM, Alex Hall <email@hidden> wrote:
> So, that's the general idea. Now, how do you all suggest this be organized? Much of it is inter-related, which is where I am unsure.
There are 1000 ways to skin a cat. To me you've already demonstrated that you know enough about separating concerns that the other details really don't matter as much as actually finishing it. Game programming is a lot "messier" than application development because it's not at clear cut what belongs where. Everybody has their own opinions. As long as you keep the main systems as general as possible, the rest _can_ be ugly and still be fine.
That said…
> Take, for example, the player pressing up arrow to step forward.
>
> 1. Up arrow is pressed, and is detected by the Map object's keyUp method.
I assume this is a mistake? The keyUp will happen in your view, which generally (other than drawing) will do nothing but hand it off to something else.
Consider that your menus will use the Up arrow to do one thing, while the game will use it to do another. The game may use the spacebar but the menu won't. For some inputs, you only care about whether or not it was "pressed" this frame, (ie the jump key was pressed, so jump and the player can't jump again until the key is released and pressed again); Others, you will want to know how long it's being held and when it's released. You may also want multiple keys to perform the same action.
One strategy you can employ is to create an input mapping object which says these certain inputs from these devices are for this particular InputID. The InputID is your game-specific action, (jump, fire, whatever). The input map keeps track of the state of those inputs — when it was pressed, if it's still pressed, was it pressed *this frame* or not, etc, and can be queried by anything that needs to know the current state of the player's input.
Since different parts of the game will require the same keys to mean different things (ie menus vs in-game), there will be one active input map at any point. The view would simply (through some call chain perhaps) tell the current input map to activate (mouse/keyDown) or deactivate (mouse/keyUp) a given input.
Your game loop can simply check the state of the inputs to know what to do.
As I said, this is one strategy. Some people like an event-based approach, so your input map could call a selector on an object instead but I'm not sold on it. Also note that you usually don't want to run code *immediately* when the key is pressed. You want to run the code at the right time during the frame update because the timing and ordering of certain this is important.
> So, how do you all recommend this be organized? Should the GameController be "god" and know about everything?
Any way you can make it work, do that. ;-)
The GC knows about all the objects in the world and should move those objects, checking for collisions, resolve them, and fire any callbacks for those collisions and triggers entered. When the player collides with something, a callback can be fired passing in the two objects that collided, and the callback can sort out what to do about it. If one object is the player perhaps you call a more specialized player-specific handling method. If the other object is the wall, play the sound, which means calling a method on the AL controller. Since the player hit a wall, the player is also no longer moving, so you could tell the player to stop.
After the GC has done all of the object movement, then you can do "everything else." A common way to do this is to call update: on every object passing in (or otherwise making available) the time that has elapsed since the last update. In the player's update method you can have it check the inputs, and handle them. Check whether the footsteps should be played etc. If Fire was newly pressed this frame, then call the method which fires the weapon.
Etc...
Just get a general wishy-washy idea and start writing code and move it around as needed. There really is no wrong way. Don't attempt to adhere to MVC — it will fry your brain. Games are not applications and trying to make them fit is really awkward and inconvenient. (Been there done that.) The most important thing when creating your first game is to *actually create the game*. Forget about how you're doing it, and just get it done. When you start the second one you'll have a better idea of what to do differently.
Hope that helps,
Also: http://www.idevgames.com/forums You'll probably get much more help there than here.
--
Seth Willits
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden