Classic error with 3D platformers is to have a curved stair case, have the camera pan to side on, which denies the view to control the x axis relative to the character and the staircase, also the distances of jumps and edges are harder to determine. Super Mario Galaxy, top 5 3D platformer for me, made by some of the best devs in the world, has this kind of error a lot (I’ve played that game a lot, 242 stars). If I was controlling the camera, I would never place it where the developers place it, it would be over the shoulder where it would be in almost all situations in a 3D platformer. If you pan out like that in a 3D platformer, turn it into a 2.5D platformer like Giana: Twisted Sisters or Trine, so you can only control the character on one axis.

All these kind of errors are never to serve gameplay, they’re always to show an environment, or to make a game like a movie. Games are not movies, they have strengths that movies don’t have, they shouldn’t pretend to be movies, whenever a game developer tries to make a game more like a movie and forgets gameplay the game suffers. If your environment is interesting, you won’t need to force me to look, if you want me to view an environment from a particular angle, find a way to get the character there, the original Tomb Raider is great at this, you view an environment from one angle but you get a completely different idea from another perspective without removing the camera from the player.

Hey trust me, we get it! I play a whole darn lot of these Video Games and I study and analyze this stuff all the time.

But I wanted to point out that it’s not always just to show the environment. Sometimes (like a couple points in WB), we had to do something bad to the camera to make the controls make sense.  Like, there’s a part where you need to be able to climb a rope while swinging back and forth on it. The camera being free during this section would mean some pretty weird controls; should up and down move you forward / back, or should they let you climb the rope? Should left right rotate you around the rope or let you swing back and forth? We opted in this case to have the camera fixed during this sequence so you can swing left and right and climb with up and down, but basically no matter what we do here we’d be screwed. With a TON of time for playtesting and prototyping JUST the rope swing we’d probably have been able to come up with a better compromise, or at least a better fixed camera angle, but there are only so many seconds available across those two weeks!

Similarly, there’s a part where you’re on top of a giant metal ladder-like thing that you can swing left or right. Since we didn’t have a ton of time to plan out every camera shot for these animations, the character was animated facing one direction while it was expected by the level design for the camera to be behind her. Normally we’d catch this sort of thing while doing storyboards and would have animated her facing the other direction, but since things were wayyyyy too fast and loose for that we had to swing the camera around so the cutscenes of the ladder swinging made spatial sense (otherwise you’d see it falling left when you pressed right, or whatever).

But yeah, with a whole lot more time, we’d have built a way radder camera system. But time is short and hopefully you’re happy with the final version soon!

Sands of Time used a button to swing, up going up, down going down, left and right to rotate. Game convention always suggests up should go up, down should go down, because of ropes, poles, columns, and ladders in most other games. Sands of Time is probably my favourite 3rd person 3D platformer, although they did love to fix the camera at a 45 degree angle on rope/pole/column jumps making it way harder to judge than was necessary.

For that first wonky camera angle at the rope swing, you could rig it so that the player always jumps to one spot, but that’s pretty limiting. You could move the camera so it looks very slightly back at the girl to at least give the player some depth when jumping. That way the controls still make sense for up as up instead of forward and side to side as swinging.

With more time, I know you’d have perfect camera movement/placement, so I can’t really complain.

I do have to go with DF benburbank on fixed camera in some instances for platforming controls. I think my biggest complaint with some aspects of Psychonauts control was because of the free camera control(especially since it was on the computer, and not as intuitive as it would have been with a controller) when it came to the platforming(accidentally shifting the view would also mess up the speed of moving the acrobatics). Also doing the fixed system gives it a 2.5D platforming, while still expanding the game in an actual 3D space rather than Trine that’s 3D in a strictly 2D space.

I feel like the camera does a really good job in this prototype. Whenever the path is clear and the game focuses on platforming you can adjust it any way you want. A static camera indicates well whenever the game wants to point you towards something (and especially it tells you when you are an a sequence with limited options).

What I feel needs tweaking instead is player-acceleration (not sure if there is any at all). Also I think there is some transformation to inputs trying to predict what the player wants. The result is that you push in some direction and off she goes without giving you any chance to change it based on visual feedback. I think a really slow acceleration would work well in this game, because it doesn’t require you to get off the spot quickly for anything anyway.

We had to make a lot of compromises with our camera to get this thing out the door. Please bear with us on that. ordinarily I would rather not have a lot of authored, scripted or fixed cameras within this length and size of gameplay space. There are places that make me wince a little too but the lesser of two evils is generally the maxim in this situation - we did not have the fully developed camera system this kind of game would need, there wasn’t the time to review and tweak the path enough to avoid some of the problems we have - often massaging the path is a simpler fix than trying to make a camera that can do all things for all players.
The rope situation is an interesting one for the points that Ben raised - having the follow camera behind you as you approach would obviously make hitting the rope easier but once you’re on the rope that’s the worst possible place for it to be.
Also - don’t forget that the code system that gets the player to find and then attach to the rope is a factor in this situation and we had that in a state of flux right up until the end.

-A

I do think a lot of our critiquing has the fallibility of us not quite deciphering all of what was intended, versus the limitations of time and resources of two weeks of development. :D

After playing through the prototype three times, I didn’t die on the rope bit but it felt awful. The other problematic area was the bridge, but I won’t criticize it because I saw the video and its clearly an unintentional mistake that was already acknowledged but you didn’t have time to fix. There were other areas where the camera was less than optimal, I would much prefer it if I could choose to control the camera at all times. I feel as if you’re fighting a losing battle, I’ve never played a 3rd person 3D platformer that hasn’t had many faults with its camera, even from the biggest and most well resourced teams.

DF Andy - 14 December 2012 07:14 PM

...but once you’re on the rope that’s the worst possible place for it to be…

-A

What’s the problem with having the camera behind when on a rope? Sands of Time, it’s one of the best platformers around, has an “action” button to swing the rope. The trapeze in Psychonauts was fine, and that’s basically the same principle. There’s no problem with judging the jump if the camera is behind, that’s where the camera is in most 3D platformers when judging jumps.

If you have to have the camera side on, limit the gameplay to 2 dimensions like New Super Mario Brothers, Giana: Twisted Sisters, Ancients of Ooga, or Trine 1/2 (which has great rope swinging mechanics) for these segments.

DF Andy - 14 December 2012 07:14 PM

We had to make a lot of compromises with our camera to get this thing out the door. Please bear with us on that. ordinarily I would rather not have a lot of authored, scripted or fixed cameras within this length and size of gameplay space. There are places that make me wince a little too but the lesser of two evils is generally the maxim in this situation - we did not have the fully developed camera system this kind of game would need, there wasn’t the time to review and tweak the path enough to avoid some of the problems we have - often massaging the path is a simpler fix than trying to make a camera that can do all things for all players.
The rope situation is an interesting one for the points that Ben raised - having the follow camera behind you as you approach would obviously make hitting the rope easier but once you’re on the rope that’s the worst possible place for it to be.
Also - don’t forget that the code system that gets the player to find and then attach to the rope is a factor in this situation and we had that in a state of flux right up until the end.

-A

Hey there, Andy!

I played through the prototype and I loved it! I do have a couple of recommendations for you, though!

The rope section, as above, can be fixed by integrating a long narrow tunnel to the rope, so you can simply press “Left” on the analog stick, or “A” on the keyboard and then jump to get to the rope. The little edge helps, but it looks like you have to jump at an angle to get to it. I suspect some sort of narrow tunnel will help with the issue of completely missing the rope.

The bridge is fine. I say you can leave it as it is. Couple bug fixes I’m sure you already know, but I think it is a fair puzzle.

The other difficult section will be the crane. I had some difficulty since I had the urge to jump on the platform first, bypassing the crane. I think this could be fixed by deleting a section of the crane on the left, and another section after the platform to jump onto the crane. Not too sure how to make the crane section to climb easier to identify, but making it impossible to go any other way will help.

Great job, Andy, on creating the prototype all around, and all to your great team members. Jane and Dave come to mind instantly since I’ve read some of their posts here, and I’m sorry I forgot everyone else’s names. But I say “Great job” to everyone on this project!

I went back and played the Tomb Raider trilogy Legend, Anniversary, and Underworld and the way the grapple hook and rope work in that game is fine. The camera is player controlled, so I have it at the back slightly above the head. Press forward and back to swing, which also gives you analogue control, press Y to climb up and B to climb down. It works a bit better than the Sands of Time system, although I never liked the lack of moment in the Tomb Raider games, it’s more like jumping from a point of the swing unlike Sands of Time or Trine where you felt you are flinging yourself using the rope.