In the last dev log, I mentioned that Monumental Failure's camera would be controlled by the game, not the player. In this post, I'd like to take some time to discuss lessons I've learned working on game cameras. Before working on Monumental Failure, I had experience working on 2D game cameras, specifically with the games Battle Run and Super Battle Racers. In those games, the camera uses a few simple rules. The camera tracks the player character. If the character is within bounds, the camera asks the level where best to situate the camera. If the character is not within the bounds, the camera does its best to follow the character anyways. Though the actual implementation of this system would be represented by hundreds of lines of code and hundreds of points of information specified by the level designer, the key idea here is that 2D cameras are best left to the designer. As a side note, Mushroom 11 creator Itay Keren, in his massive treatise on 2D game cameras, essentially comes to the same solution. The question then is does a similar, level-design driven approach make sense for Monumental Failure, a 3D game? The simple answer is no. Battle Run and Super Battle Racers are concerned with tracking a single character who moves in 2D screen space along a level that is almost one dimensional i.e. you can move left and right, with little variance in up and down. The level designer need only provide a list of points that the camera then interpolates between. In Monumental Failure, I have a variable number of things to track - a piece of a monument, and the characters that are pushing it - all of which move in three dimensions of space. Trying to populate the levels with three dimensions of camera direction would be a nightmare. Instead, I need more general solutions, and need to be much more selective of the camera controls which I expose to the level designer. The first rule I impart to the camera is to find a relative forward/backward (depth) axis. I define this as the axis made from the target position to the pushed stone's position, removing any vertical change. The camera uses this depth axis and is placed at a distance behind the stone's position, as well as an angle up from the stone's position. The distance and angle are defined by the level designer. The camera attempts to maintain the angle and distance from the stone as the stone moves. With a little bit of smoothing, this method is very good for keeping track of the stone, but I need to do a little more to make sure you can see your push-people. To assure the push-people are seen by the camera, I call a function that returns their individual screen positions. If the function returns a number between 0 and 1, they're on-screen. If anybody is off-screen, I increase the distance that the camera is away from the stone until the characters are back on screen. To make this camera rule more graceful, two changes are needed. Instead of checking a range of 0 to 1, we instead want to check something more akin to 0.1 to 0.9, so if an object is maybe going to be off-screen, we are getting ahead of it and pulling the camera back preemptively. Secondly, the speed at which I pull the camera back needs to be able to accelerate in the case that something got off screen fast. When the player approaches the target for their pushed stone, the level designer has the option of rotating the camera to give the player a better sense of how lined up their object is. This camera feature was implemented very early in the game's development, and my play-testing has me questioning whether this is a helper or a hindrance to the player. Level designer Spencer says, "it depends." When I write it out, the rules for the camera may sound simple. The reality is that it's a living system that needs new features and tweaks as the level design informs them. Just this week, I needed a function that would allow me to provide an additional amount of positioning to better highlight action down-screen from the stone and people. Despite my previously stated concerns that handling camera controls on the developer's side would be a headache, it's actually been a satisfying challenge. I make it easier by providing relatively few handles to tweak it on the level design side.
While I'm sure there are still challenges to come and changes to make, the current camera is actually pretty great. Cheers, Spencer
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Archives
March 2017
Categories |