My View on 2D Platformer Cameras

Everybody knows games live and die by their camera. It doesn't matter what the nature of the game is, if the camera isn't able to properly frame the action, the player will undoubtedly get frustrated and the game ceases to be enjoyable (obviously this is more common in certain types of games, for example I've never played a Tetris game where I was upset by the camera). This being said, talk of cameras is usually reserved for 3D games, and very rarely do you hear talk of how the camera is handled in a 2D game. Maybe this is because 3D camera work is inherently more complicated, or maybe even that relatively bad 2D cameras are usually not the end of the world and the games are still playable. Regardless, Internet, prepare to be enriched as I am going to post my dissection of camera work in 2D platformers as well as how all this applies to the game I am making.

Why is the Camera so Important?

As I said earlier, the camera is important because it frames the game. The camera, which is just a word for the visible area rendered to the screen, is the player's only gateway into the world you have them playing in. Skew their view too much in one direction, or make their character difficult to follow with a constantly adjusting camera and the play experience is seriously hurt. It's very simple: a player can't react to what they can't see, and a game is no fun when you aren't given the tools or time necessary to react to a situation, and is even less fun when you don't even know what that situation is in the first place. Nobody likes being killed by off-screen enemies or falling into pits that were hidden below their field of view.

How is it Usually Done?

First of all, we have to realize that there are two popular types of platformers each with their own typical camera system. There is the sidescrolling platformer, which usually uses what I like to call a floor-locked camera system, meaning there is little to no movement on the vertical axis and the floor is visible at all times. This type of camera system also usually strives to keep the player in the center of the screen on the horizontal axis (with some games allowing the camera to lead the player somewhat). This works very well in most cases, as the typical primary ability of a platformer character is jumping, which requires vertical visibility. This system is also elegant in it's treatment of the staple sidescroller danger known as bottomless pits as the player knows that any fall going past the bottom of the screen will result in death, avoiding the common annoyance a player faces of deliberately falling down a bottomless pit thinking they will survive (spoiler: they usually don't).  Obviously, as sidescrollers have grown in complexity over the years, the rigidity of this system has loosened significantly and minimal vertical scrolling has been introduced. However, the essence of the system, always keeping what the player is standing on in clear view, has not disappeared.

The NES classic Super Mario Bros. is a prime example

 of the floor-locked camera system

The other most popular type of platformer is the open-world platformer, where levels are non-linear and players are free to explore in every direction. The vast majority of these games use a camera which directly follows the player, attempting to keep him in the center of the screen (or near the center) whenever possible, I call this system player-locked. Often these games also have certain areas like boss fights or smaller rooms where the camera behaves in a more traditional sidescroler manner. In my humble opinion, this system is functional yet flawed. It is functional in the capacity that it allows the player to see equally in every direction, something that is important as the player can be expected to move in any direction at any given point. As a side note, this is much better than a heuristic camera (where the camera tries to predict where the player will be, based on his position and velocity) because it is predictable, something that is very important as an unpredictable camera feels chaotic and annoying. The system is flawed however, in that it very rarely frames the action in the most appropriate way. Typically platformer characters can jump very high and it is not uncommon for the camera to track them in such a way that at the peak of their jump the player can not see where they were standing. This makes any kind of horizontal jumping (jumping across a gap for example) needlessly frustrating as the player needs to remember where platforms are so that he does not overshoot or undershoot them. It is much more enjoyable for the player to be able to see his desired landing point for the entire duration of a jump. The other big problem with a player-locked camera is that it moves around a great deal and feels especially jerky during the typical rapid upwards acceleration of a character's jump.

Super Metroid for the SNES uses a mixture of the floor-locked and player-locked camera 

systems based on the type of room the player finds themselves in

What Happens When it Goes Wrong?

Though I've gone over why the camera is important and the problems a bad camera can cause for the player, I just wanted to use this section to present a concrete example of what a broken platformer camera looks like. Here is a video of Frogger Advance: The Great Quest, for the Game Boy Advance. The game is a sidescroller but uses the player-locked camera system and it seriously hampers gameplay. You will see in the video that it is extremely difficult to judge jump distances as when the player is in the air they cannot see the platforms beneath them. I would wager a guess that without the floating mechanic (where Frogger slowly floats downwards) the game would be unplayable due to the large amount of player deaths caused by the platforms being off-screen. It is worth noting that the camera is not the sole cause of this issue, the enormous character sprites on the small Game Boy Advance screen also add to the difficulty in seeing what is around the player. Earthworm Jim for the Game Boy Advance is another example of large sprites on a small screen with a player-locked camera seriously hurting a game.

There are very few videos of this game on YouTube, but this one
perfectly sums up the issued with the game's camera

So What Did I Do?

As I said yesterday, my game is a platformer with semi-large open levels in which the player can move in any direction. I did not, however, use the player-locked camera system because of the flaws I presented earlier. Instead, I opted for my own system (and this being 2012 I'm sure it's been used before, and has a name, and a wiki about it) that I call a platform-locked camera system. What I initially did was created a rectangle around the player (a window if you will) that could be moved by the player pushing against it's edges both vertically and horizontally. The camera was tied to the position of the window, not the player. This allowed the player some leeway in vertical and horizontal movement without affecting the camera, which I thought was important in making the camera feel stable rather than chaotic. I noticed, however, that this brought up an important issue regarding the rectangle's size. If the rectangle was too short, the camera would still scroll vertically when the player jumped  (again I don't want the camera moving that much). The obvious solution was to make the rectangle taller, but this caused the player to have too much vertical movement when falling before reaching the bottom edge of the rectangle, not offering the player enough downwards visibility. 

So what I have implemented currently is a mix between the floor-locked system and the window system. This system keeps the same functionality as the window system on the horizontal axis, but works differently on the vertical axis. Vertically, the camera keeps itself locked to the height of whichever platform the character was last standing on provided the player stays at that altitude or higher. If the player drops below the platform, the camera will follow him until he lands on a new platform. This allows the player to jump without the camera moving to follow his accelerated upwards momentum and gives a very smooth result (in my humble opinion). 

There was one last question, however, and this was where the player should be located on the screen (for example, the center of the screen as seen in the player-locked camera system). I decided to keep the player on the bottom portion of the screen (centered horizontally) and allow him to look downwards when standing on a platform (with the down arrow key). I chose this position for the simple reason that the player has more control when going upwards (as jumping is the primary means of movement) and should therefore be able to see more of what lies ahead. Given that the camera is locked to always allow the player to see any platform he is trying to jump to laterally (and downwards to a certain degree), the only time the player must move long distances downwards is if they are deciding to fall off a platform. If they chose to do this they can simply look down before committing to their descent.

This will all make more sense when you get to try the system, which incidentally happens to be right now. Keep in mind all art and sound and level design and everything else is place holder. (NOTE: There is a noticeable frame rate drop when uploaded for some reason, I will find the cause later and eradicate it)

CONTROLS:

Arrow Keys or WASD to move (Down Arrow or S to look down)

X and C for the two bullet types (explanation of this mechanic is in yesterday's post)

T to toggle visibility of the camera rectangle

EXTRA CONTROLS (you don't need these, but they are there)

Press Escape to toggle in and out of editor mode

Hold down F to enable fast scrolling

Use the mouse the place blocks

Hold control and click to remove blocks

Press E to clear the screen

Use Space-S and Space-O to save and open a level

And that's what I think of platformer cameras, I'd be happy to hear your thoughts on the subject in the comments (found below the post's title).

A Long Textual Explanation of the Game I'm Making

Hello lonely reader of my blog (I refer to myself when I say this) here is an update about what I'm doing. I've thought long and hard trying to find the perfect design for my game this summer (all the while working on a basic 2d engine as I said before) and I was struggling. Like I said earlier, I believe in video games as a medium perfect for emotional expression as well as artistry and I really wanted to try doing something in that vein this summer. In the end I've decided against it. Though I really want to create something which a player can feel emotionally invested in, I also believe that the gameplay absolutely can't suck (I'm looking at you hordes of retro flash games with touching storylines, haunting music and boring gameplay). However, this is a big task, finding a tale, a feeling that you want to convey and then creating meaningful gameplay that brings those things to the forefront. I am confident in my ability to do this and have narrowed out some basic ideas, but with such a limited time span and a workforce consisting of only me (have I mentioned I am unbelievably god-awfully bad at drawing anything even remotely more complicated than a scribble) I don't think I could make something that would not fall in the trap of just being not at all fun to play.

This is why I have decided to take another route, I'm focusing solely on the gameplay, building an experience that is just purely fun and challenging, letting everything else come second (hey, maybe I am good enough to do everything, only time will tell). The game I'm making is a platformer (yes, the indie dev FPS) that is a cross between a room based puzzle game (think Angry Birds or The Company of Myself ) and a more expansive platformer style like Metroid or Castlevania or Cave Story or Knytt or etc... The idea is to have semi-large explorable worlds as self contained levels that need to be completed one after the other. I have quite nailed this part down yet, but the game the way to beat each level is likely going to be to find all of the collectibles hidden within it (they would be sparse, easy to see, but hard to reach).

The primary tool given to the player is (apart from jumping) the ability to shoot two different colored shots out of his gun. These shots do not affect enemies, however they affect the environment. One color raises any block that is shot and the other lowers it. It's like gravity suddenly turns on for that block in the direction corresponding to the type of shot the block was hit with (note that I haven't decided any kind of setting for this game yet as I am focusing on gameplay, meaning the player may not have a "gun" and gravity almost certainly won't be the explanation given behind his level manipulation powers). Every part of every level in the game can be manipulated in this way, however given that the player can only shoot either left or right I have found it easy to make it so that the player can't fundamentally break the level (by removing the floor for example). Enemies must be squished to be killed and platforms must be rode to success. This is meant to be both a puzzle and action game.

Reading that last paragraph I realize it makes just about zero sense, or at the very least is hard to follow without some visual aid. I would embed the basic prototype here, which would make this post make a hell of a lot more sense, but I'm planning on making an awesome post about the camera system tomorrow, and I don't want two posts with the exact same embedded prototype. Since I don't have any readers, nobody will be here to witness the one day this explanation is without the prototype to aid in clarification.

More to come tomorrow on camera's in open-world 2d platformer games.

What I'm Working On

So, here it is, the game I'm working on this summer. I'm proud to announce: nothing. What I mean is I'm not quite sure yet what it is I'm going to make. I've toyed with a few design ideas, but so far nothing is completely set in stone yet, and thus not something I'm going to talk about.

See, here's what happened, I did a bunch of research right before the summer trying to decide what platform/development environment I wanted to use for creating this game I had in mind. I chose Unity for it's ease of use, built in multiplatform support and because I wanted to try out a more visual editor for a change. I also used the 2DToolkit add-on in order to support sprites (it's awesome by the way). After quite a bit of learning, and some quick prototyping of an idea I had, I came to the conclusion that for what I was aiming to make (a simplistic 2d game), Unity was just too good. That is, it had many built in features that I would never use, and I just felt like I was wrestling with the program trying to make it abandon all it's built in physics and collisions so I could just write everything myself. Sure it is doable, and I definitely want to use Unity in the future, but for this simple 2d project it simply wasn't the right fit.

So now I'm using FlashDevelop and Flashpunk, coding everything in ActionScript 3. So far it's been really awesome, allowing me more easily accessed low-level freedom and due to my familiarity with this sort of framework it's really sped up my workflow.

Now, as to what I am actually making, I can't quite tell you, as I'm not entirely sure myself. Thematically, I know where I'm going, and I have a few basic gameplay interactions floating around in my head, but I don't have anything absolutely concrete yet. Now, I'm not just twiddling my thumbs, in fact, the reason I don't have a clear design right now is because I spent so much time prototyping another idea in Unity that failed miserably (it was thematically identical to what I'm doing now, so I won't talk about that part of it). Let's just say I could not get the underwater-based movement to feel anything but absolutely floaty and arbitrary (you controlled the player character based on increasing/decreasing his weight). As a firm believer that in most cases, moving the player around the world needs to be a fun action, I abandoned the idea for now (maybe one day I can try to understand fluid physics better).

Just to clarify, I'm a big proponent for games as a medium perfect for emotional expression, and that's what I'm trying to do here (but sadly I'm going to have to try with bad art). That's why when I say that thematically I know what I'm doing, I mean I know the style and emotion I'm trying to bring across, but it's integrating it into some sort of meaningful gameplay that is actually fun that is slowing me down. Oh well, I love this process.

So for now, I'm making a 2d tile based engine in flash so that I get something done while I keep refining my ideas. As of now I've completed the level-editor, which is way more comprehensive than any editor I've made before. It's really cool in that it allows levels to be made on the fly during gameplay (pausing time in order to do it) as well as dynamic saving and loading during run-time. This will allow me to quickly test different level design ideas very rapidly and is also just super cool. Right now the editor only supports placing static "blocks", but adding different entities as they get made is trivial as the whole thing is modular and easy to build upon. Also, the levels are saved as xml's because, well, I like xml's.

So here are some screenshots, and yes, that is the sprite from Super Mario Land 2: 6 Golden Coins (awesome game) and the blocks are from Metroid (both are obviously placeholder).

So here it is in "play" mode

And this is "edit" mode, toggled with escape