Some games are known for the horrible "player control", like "Total Recall". Other games have gotten good marks for really good player control... which I'm drawing a blank on right now... But I'll say that I've always found the player control on the original Zelda game to be good, and although I dislike the Super Mario Brothers games, I imagine that Nintendo did a reasonable job with player control in those games too.
Poor player control makes a game suck (worse than a bad story line, IMHO). Characters who don't move when they should, or move too much, or jump off platforms into the abyss on a whim is the kind of thing that I'm driving at.
As developers, there are some obvious things that we should consider:
1) Storing character position with sub-pixel accuracy.
2) Trying to keep motion and animation as smooth as possible.
3) Try to be smart about acceleration and deceleration.
4) Issues involving jumping: "fake physics" like in Mario vs. jump height has nothing to do with how long the button is held down (Castlevania? Crystalis), to being able to change position in mid-jump (or not).
Before I delve into player control in my own game, I wanted to get the community opinion:
1) Which games come to mind that had excellent input / player control? (They might be worth reverse engineering to learn from).
2) Which games were ok but could have been better (and how specifically)?
Many you have a lot more experience playing, hacking and designing games. What should us newbies do (or not) when we try to implement "player control" in our games?
Player control
Moderator: Moderators
I've always thought SMB2 US had exceptional play control. And the sprite physics...oh, man. The way enemies and bombs rebound off of floors and walls (and each other!) is amazing.
- BMF
RuSteD LOgIc
RuSteD LOgIc
-
never-obsolete
- Posts: 403
- Joined: Wed Sep 07, 2005 9:55 am
- Location: Phoenix, AZ
- Contact:
Oh Mega Man games have awesome control. Casltevania jumps and stairs seems terrible at first, but after a long while of playing, you get 100% used to it. Also the frist times I played Batman : Return of the Jocker I found it to have terrible controls, now I'm perfectly used to it too. Altough I agree it's better if you don't have to "get used to it".
I don't think it's required to reverse engineer anything to figure out how to make good control, because this will be more complicated than trying to do it by yourself.
To avoid bad control you should :
1) Avoid putting more than one frame of delay between when a button is pressed and when it takes effect (unless in special cases)
2) Make the hero react as quickly as possible. For example if you crouch, you don't want it to take many animation frames to crouch slowly (like in Batman : ROTJ), but you just want it to crouch immediatley (like in Contra), even if this is unrealistic.
3) When the player get hit, it may "jump back" a little but never too much, and you'd want to be able to take control of it very quickly after the jump back time.
4) When the player get hits, it should be invincible for a sufficient amount of time so that he may get in a safe area.
5) Either the speed or the acceleration of the player should be constant when there is no changes in the button presses (any unpredicable movement should be avoided), and that on both axises.
6) Every enemy that appears on screen should only appear once (it has nothing to do with the controls but I guess I'd mention that rule too, so many games could have been better following that rule).
I just made these 6 rules up, but I think they should be pretty accurate to describe the difference between good and bad control.
I don't think it's required to reverse engineer anything to figure out how to make good control, because this will be more complicated than trying to do it by yourself.
To avoid bad control you should :
1) Avoid putting more than one frame of delay between when a button is pressed and when it takes effect (unless in special cases)
2) Make the hero react as quickly as possible. For example if you crouch, you don't want it to take many animation frames to crouch slowly (like in Batman : ROTJ), but you just want it to crouch immediatley (like in Contra), even if this is unrealistic.
3) When the player get hit, it may "jump back" a little but never too much, and you'd want to be able to take control of it very quickly after the jump back time.
4) When the player get hits, it should be invincible for a sufficient amount of time so that he may get in a safe area.
5) Either the speed or the acceleration of the player should be constant when there is no changes in the button presses (any unpredicable movement should be avoided), and that on both axises.
6) Every enemy that appears on screen should only appear once (it has nothing to do with the controls but I guess I'd mention that rule too, so many games could have been better following that rule).
I just made these 6 rules up, but I think they should be pretty accurate to describe the difference between good and bad control.
Useless, lumbering half-wits don't scare us.
I've always thought that Contra had great controls. Such as:
- the ability to fire in all four cardinal directions, as well as diagonals
- the ability to manipulate your direction while jumping
- manipulating firing direction while jumping
- quick animation between crouches, jumps, etc.
- accurate hit detection
- smaller body surface while jumping
Some of these reiterate Bregalad's rules, but he's right on with his list.
Look to the NES port of Dragon's Lair for what *not* to do.
- the ability to fire in all four cardinal directions, as well as diagonals
- the ability to manipulate your direction while jumping
- manipulating firing direction while jumping
- quick animation between crouches, jumps, etc.
- accurate hit detection
- smaller body surface while jumping
Some of these reiterate Bregalad's rules, but he's right on with his list.
Look to the NES port of Dragon's Lair for what *not* to do.
This is called mercy invincibility. It's good to consider pretty much everywhere but in a karate game, where mercy invincibility would keep me from pulling off a big phat combo on my opponent. The difference between karate games and pretty much the rest of the gaming universe was the basis for some episodes of the webcomic Kid Radd, around the time when they recruited Eliot from Mofo.Bregalad wrote:4) When the player get hits, it should be invincible for a sufficient amount of time so that he may get in a safe area.
Does this include things like autorepeat style motion? When the player holds left or right on the Control Pad in Tetяis, Tetris, Dr. Mario, or Tetramino, the game moves a falling piece by a small amount and then waits 10 to 20 frames. If the player is still holding sideways, the piece moves quickly. But then this is still predictable.5) Either the speed or the acceleration of the player should be constant when there is no changes in the button presses (any unpredicable movement should be avoided), and that on both axises.
How much memory would it take to remember every defeated enemy in a game the size of, say, Super Mario 2? And without the ability to go back and kill the same enemies over and over to extract item drops from them, how can a Mega Man or Kirby player power up?6) Every enemy that appears on screen should only appear once (it has nothing to do with the controls but I guess I'd mention that rule too, so many games could have been better following that rule).
You can find a detailed discussion of the elements of a platformer in TV Tropes: Platform Game.
-
Celius
- Posts: 2159
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
To remember all the enemies killed, all that you'd need is one bit, where 1 = alive, and 0 = dead. So 8 enemies are in one byte, and you could have 32 bytes for 128 enemies. That seems like a lot for little memory.
In my game, enemies are brought to life only when you enter a new room (small collection of screens usually about 2x2 to 3x3 screens). If one dies in a room, and you remain in that room, they will remain dead until you re-enter. A big reason for this is because all enemies in a room are handled even if they're off screen.
In my game, enemies are brought to life only when you enter a new room (small collection of screens usually about 2x2 to 3x3 screens). If one dies in a room, and you remain in that room, they will remain dead until you re-enter. A big reason for this is because all enemies in a room are handled even if they're off screen.
Back when I was limited to the stock 2KB of RAM, I had a table like this, where every object had it's own alive/dead bit. But there were cases where they needed to remember more than that, so there were a few extra bytes that these special objects could make use of. The definitions of these objects in ROM contained a pointer to the byte(s) of RAM they could use for remembering extra stuff.Celius wrote:To remember all the enemies killed, all that you'd need is one bit, where 1 = alive, and 0 = dead. So 8 enemies are in one byte, and you could have 32 bytes for 128 enemies. That seems like a lot for little memory.
As an example of desirable information to store I can mention the new coordinates of a block that can be pushed by the player, in case you want that block to keep it's position after it's been pushed.
I do the same with my chest, where I have a table where each bit represent a possible chest, and a '1' would mean the chest is oppened.Celius wrote:To remember all the enemies killed, all that you'd need is one bit, where 1 = alive, and 0 = dead. So 8 enemies are in one byte, and you could have 32 bytes for 128 enemies. That seems like a lot for little memory.
Since I don't know where the chest will be loaded, I have such memory for all possible objects, so I could also remember if monsters are dead, but I don't do that for now because it would make the game a little to easy, and it would be impossible to kill monsters again and again if the players exept to be rewarded with score and healing items.
Useless, lumbering half-wits don't scare us.
