I've been trying to figure out some high-level technical constraints. Here's what I've come up with so far:

1. I'll draw using an extremely narrow subset of OpenGL. I'll use an orthographic projection and some discrete set of layers in the depth dimension. Each layer will be composed of geometric primitives, drawn without any texturing. I visualize myself relying mostly on rectangular elements but can see myself using point and line primitives as well. These choices are based on an intention to make my own minimalist custom editor for the visual content and also on the fact that I'll be doing the rendering by hand and don't want that part of the project to overwhelm everything else.

2. For physics, I'm looking at using Chipmunk. I considered two alternatives: (1) do the physics myself using crazy, ad hoc hacks; and (2) Box2d. I prefer Chipmunk over Box2d because it has a C interface. I prefer it over my own hacks because the results should be much more believable and the interface looks simple enough that I can figure it out in the time I have.

3. The levels will be hand-crafted rather than generated.

4. Enemies will wander about until spotting the player. Their response to seeing the player will be to charge him with guns blazing. Pretty typical.

5. The one visual aspect I really want to get right is the impression of damage. Characters should get bloodied, leave a blood-trail as they move if they are injured, and finally, gibs should be generated and they should be animated nicely. Another part of this is that bullet (and potentially, explosion) impacts should push characters around.

6. Sounds and music will be important but I'll focus on visuals and gameplay first.

So the next thing to do is probably to draw up some kind of roadmap. Early steps probably include implementing fullscreen mode and figuring out how to work with the Cocoa event loop.

3. I started thinking about motion blur and came up with an idea for
simulating it by using simple 3d volumes to represent the sweep of
each 2d shape over an interval of time. Calculating volume thickness
per-pixel from depth buffers and translating to opacity should produce
a nice motion blur effect in my layered 2d world. I'm not sure
whether I'll be able to make it work but I'd like to try.

4. I read through the Chipmunk documentation, skimming the parts
about spacial queries, constraints, and joints.

5. While I was evaluating a bunch of communication protocols I
realized that it might be quite convenient to use google protocol
buffers for storing game objects.

6. I discovered that there is a play from medieval times called
Everyman. Oddly enough, it is about events preceding his death. So
my game's title has turned out to be very closely related to a
strange, and very old, play.

ericbb Wrote:If I'm not careful, I can see myself spending all my time playing around with effects and forgetting to produce a game.

(Jul 11, 2011 01:49 AM)ericbb Wrote: 3. I started thinking about motion blur and came up with an idea for
simulating it by using simple 3d volumes to represent the sweep of
each 2d shape over an interval of time. Calculating volume thickness
per-pixel from depth buffers and translating to opacity should produce
a nice motion blur effect in my layered 2d world. I'm not sure
whether I'll be able to make it work but I'd like to try.

I'm really excited to play this year's shooters! Looking forward to a playable build

Heh. Me too. I've been wandering around the Cocoa Framework Funhouse and feel approximately as lost as when I started. As a beginner to OS X coding, the ratio of making to exploring is pretty low.

Right now I'm experimenting with a design where one window alternates between an OpenGL view and a Webkit view. I've verified that both views are responding to events and I can export Objective-C methods into Javascript.

I have uncovered nextEventMatchingMask:untilDate:inMode:dequeue: and startPeriodicEventsAfterDelay:withPeriod: and I'm thinking that, to start with, I'll just poll all queued events after each vsync without worrying about periodic events unless I get time to experiment later.

(Jul 20, 2011 12:30 AM)OneSadCookie Wrote: Why not just override the NSResponder methods? It's a lot easier, and a lot less likely to cause subtle or not-so-subtle breakage of other standard behaviors...

When I was reading the NSTimer documentation, I found this: "Because of the various input sources a typical run loop manages, the effective resolution of the time interval for a timer is limited to on the order of 50-100 milliseconds".

Obviously, 10 FPS is not an acceptable frame rate. But then again, it appears that people *are* using NSTimer so maybe I will just ignore Apple's warning and try the simple thing.

In fact, I just discovered NSObject performSelector:withObject:afterDelay: so I'll try that and if the time resolution is good enough in practice, I'll stick with it.