nesdev.org

A couple of days ago I improved the camera in my game to make it less obnoxious. What seemed to work is changing the "camera panning adjustments" from 1 pixel per frame to 2 pixels per frame. It makes camera adjustments draw less attention to itself.

What still needs improvement is fixing it so it doesn't adjust every time the player turns around, so you could make micro adjustments to the character. So we can discuss how to fix that problem, how to implement it, and write a tutorial about it on superfamicom, with well written example code.

So far I think the behavior should work like this:

-When the character is moving in a direction, the camera should be about 32 pixels ahead of the player.
-When the character turns around, the camera stops and allows the player to walk backwards for up to 32 more pixels without moving.
-When the character moves more than 32 pixels backwards, the camera adjusts itself at 2 pixels per frame, until it's 32 pixels infront of the player.

You might find this Gamasutra article to be useful for some ideas.

This depends on the design of your actual game, but my first thought:

Delay the camera pan based on time. (or NMI counts to be more precise)

If your game is designed to have enemies on either sides of the player, the player could turn around to fight enemies on the left, and still desire the camera to pan that way without needing to move very far.

A player could turn left for a brief moment, perform an action, and turn back to the right without triggering the pan.

This way, after a period of time, the computer could recognize that the player has "committed" to turning left without them having to take steps.

Essentially, this would always keep the camera at the last direction the player faced for more than X seconds.

psycopathicteen wrote:So far I think the behavior should work like this:

-When the character is moving in a direction, the camera should be about 32 pixels ahead of the player.
-When the character turns around, the camera stops and allows the player to walk backwards for up to 32 more pixels without moving.
-When the character moves more than 32 pixels backwards, the camera adjusts itself at 2 pixels per frame, until it's 32 pixels infront of the player.

This is pretty much the exact behavior of Super Mario World. What darryl.revok mentioned is similar to what Yoshi's Island does.

tepples wrote:This is pretty much the exact behavior of Super Mario World. What darryl.revok mentioned is similar to what Yoshi's Island does.

I think each style is probably best suited to their respective games.

Super Mario World would require you to move to the left in almost any instances that would put your attention there.

Yoshi's Island has (more) projectile combat that would put a player's attention to the left even though they may not want to walk that way.

RT-55J wrote:You might find this Gamasutra article to be useful for some ideas.

Was going to link this article but couldn't find it. Thanks, I think it covers most things you'd need to think about in camera design.

I just implemented a SMW style camera. Something that is becoming more obvious to me is the lack of acceleration in the player's movement. I need to think about fixing that.

Here is code for a simple camera that adjusts every time the character turns around. I think it can be simplified a little bit.

I think what I find more annoying than the camera is the fact that every time the camera adjusts itself it respawns enemies that were just killed. I think it would make more sense if the spawning window wasn't tied to the camera.

psycopathicteen wrote:I think what I find more annoying than the camera is the fact that every time the camera adjusts itself it respawns enemies that were just killed. I think it would make more sense if the spawning window wasn't tied to the camera.

Do you really want enemies to respawn? I know some games gain from it like ninja gaiden, but mostly it's just annoying.

If the player can gain powerups from enemies (Mega Man or Kirby), the player might want them to respawn after having moved a reasonable distance. But I'd say don't respawn if the player hasn't moved a screen's radius away, that is, a 2-screen-wide sliding window centered on the player.

One of the reasons my spawning engine is so sensitive is because when I was doing my Gunstar Heroes port I noticed that in the original game the enemies respawned without moving the camera to prevent the screen from being empty.

I think that maybe it worked in Gunstar Heroes because it had one way scrolling, and maybe a timer to delay the respawning by a couple of seconds.

psycopathicteen wrote:when I was doing my Gunstar Heroes port I noticed that in the original game the enemies respawned without moving the camera to prevent the screen from being empty.

Parts of Contra, an older one-way scrolling run-and-gun, do the same thing.

I think I'll implement delayed respawning, with the spawning window being defined by the player's position, instead of the camera.

Maybe I might eventually implement groups of enemies, like how goombas were often arranged in groups of 2 or 3 in SMB.

tepples wrote:If the player can gain powerups from enemies (Mega Man or Kirby), the player might want them to respawn after having moved a reasonable distance. But I'd say don't respawn if the player hasn't moved a screen's radius away, that is, a 2-screen-wide sliding window centered on the player.

Megaman X frustrated the hell out of me in one particular spot near the end, where you have to climb up a bunch of moving platforms over a lethal drop. The enemies there seem to respawn if you move their spawn point even one pixel offscreen, making you kill the same stupid things over and over and over...

I'm having trouble deciding how to spawn enemies in my own game. I'm still working with the 64x64 rooms (with size-16 tiles) plan which I kinda like as a model for pretty much the whole game. I'd thought I'd be able to get away with just spawning everything on entry, but it really only takes a handful of objects in existence before things start to lag.

One thought I've had is to spawn everything on entry, but keep things deactivated until you get close enough. My system can handle 64 objects, which shouuuuld be enough to cover a whole room? Though that includes projectiles and platforms and pickups and everything, so then again maybe not. (P.S. I hate sprite platforms so much.)

I'm not sure how to handle when things go off screen, whether to disable them or despawn them completely, or just ignore collisions... One way or the other, constantly comparing everything to the screen/player position to see if it should be active or not sounds like a lot of extra processing on its own.

I haven't really gotten into much enemy design, AI or management yet... It's just the part of the remaining process that intimidates me the most.

I wonder... Has anybody ever programmed a game that deliberately detects and avoids slowdown? Like put a scanline interrupt right near the bottom of the picture where, if processing isn't complete by then, it cuts short everything remaining somehow to keep a constant framerate, at the expense of some objects not getting updated regularly? Sounds... possible, at least. I mean I can see engineering it to never go over the limit by design, or to alternate processing between frames, but, that sounds like it'll take a painful amount of calculating and planning.

Don't mind me, I'm rambling again.