I'd like to point out that writing for a book is different than writing for a film and that is also different than writing for a videogame.

Things that work in one may not work in the other. For example, extended inner dialog works well in a book, but it becomes boring quickly in a movie, while it works in a game if it's not essential and it's done during an activity that is not too demanding (so the player can split his attention to both the task and dialogue).

As usual, all I can advise is to start small. Write a two page story GEARED TOWARDS GAMING (more doing, less contemplating and pondering), and then try to take it to completion.

I'm not much for big stories in games, but what I've seen that works is focusing on what is to be done and why. Don't stray too far into hypothetical future or ancestors or whatever, as it will be normally glossed over and forgotten, unless you're doing a big franchise, in which case you wouldn't be in here anyway

Having a backstory is nice, but you'll usually rely on it for better characterization. Resident Evil 5 does this well, serving "files" (text backstory) on each character, while the main game only shows the present and some hints of the past. This keeps things moving.

Love the style, angle, colors and concept.

Love the tower.

The hand seems to have some kind of birth defect. Also, the skin looks way too smooth and youthful for me, but that's your call.

Anytime "No" is followed by "Unless" says quite a bit...

It says I'm willing to reconsider.

Note how I follow Unless by another no.

So.... really, no.

I'd like to STRESS that 2D games in general are NOT made out of a single huge picture, as 3D games are not a single hulking 3D model.

Please. Research.

you can scale the position of a proxy object in the path

guess I'll stick with my distance-based filter instead of "is on-screen"

1) If they're animated, the animation still needs to be ticked along so when they come back they're showing the correct frame. If they only have one animation with one frame, though, I think an optimisation kicks in that does no processing at all, though.

Cool, so that decides whether I have two animations or a single zero-speed animation with two frames for my trees makes no difference for me, but if two animations is faster, then I'll use that.

Does "is on screen" account for rotated zoomed layer plus rotated zoomed system crazyness? 'cause I'm using a lot of that >_<

I guess I'll test right now.

Edit: it doesn't :s

My point is, how would something like "Pride and Prejudice" the game play?

You add zombies. And then, you drop-kick them.

Obviously each lane would need a path, but the object would need to be able to jump from path to path easily without relying on nodes as a point of changeover.

[...]

Having say 5 paths, with 1 car on each path that follow each other exactly around the circuit... then when a lane change occurs simply delete the car from path X and move to path Y, and throw in a "ghost" car for the lane change animation as such.

I'd say have a single path, since if you have many, nothing guarantees they'll stay in synch along the path (at a bend, the paths on the outside will be longer, and they might get behind). Just have a "pace car" object following the path and then place your car offset to the right or left of the proxy a fixed number of units. Make sure road art is sized accordingly and avoid hard turns, as Path Behavior does not do smooth bends and the cars outside the main lane will seem to jump around.

To smoothen bends, I've thought about making the "pace car" follow another proxy object with the path behavior. The "pace car" would follow the proxy smoothly, thus softening bends. How to do this without getting behind the proxy? I have no idea yet

I'll appreciate ideas on smooth path following, as I kind of need it for my game

Objects without the solid attribute, so they are not involved in collision calculations.

Since I want only to involve the onscreen objects and I'll have a rather complex zooming/rotating screen... I guess I could early-cull in every condition by making the first condition a distance test to the center of the screen.... would that work?

Something like this:

+distance from tree to screen center > threshold
+if player overlaps tree
-> bounce[/code:3kwm34dr]

would this avoid checking THE ENTIRE LAYOUT THAT'S CHOCK FULLA TREES and just check the trees that are visible or nearly visible? (provided a correct threshold)

This is a good idea for C2, but per pixel isn't much of a waste of resources. At 1 bit per pixel for a collision mask you're only using 128kb of memory for a 1024x1024 object, on machines which these days typically have well over 1gb physical RAM going spare.

I think he means processing time, which is significantly larger for per-pixel than bounding box.

Did you try dummy box objects? they are *exactly* what you're looking for.

Construct does not consider collisions on the z axis, as it is geared for 2D and objects are flat. You'll have to do that manually.