If there's a universal thing to derive from this great article, it's:
"The point is, most of these ideas are simple and obvious in hindsight, but I had to make a lot of mistakes to find them. It's nearly impossible to coalesce good design decisions straight from the ether. The only reliable method is iteration and trial and error."
Still, my productivity increased when I consciously forced myself, when faced with some difficulties where I have failed once or twice, to resist writing more code, switch down the PC, go for a walk and think (or a good bath). Thinking hard for a few hours about a problem is underrated IMO.
I'd also add "no aspect of a game (or other piece of software) exists in a vacuum." 90% of the changes to the camera control were directly linked with changes to gameplay and user interface, which were only arrived at by iterating on the game as a whole rather than just the camera aspect. The whole article would have worked just as well if it were titled "How To Make A Game Fun".
This is probably my favorite article I've read on here all year. User experience is so important and so hard and so iterative (and requires so many new sets of eyeballs) that far too many people and organizations call it quits at the 10% mark without ever realizing it -- this is as true in web design as it is in game design. It's great how spending time learning lessons in one can translate into improved performance at the other.
Mark Rosewater, lead designer for Magic: The Gathering, likes to talk about how he looks for designers with experience doing things other than designing games because they can bring new perspectives and approaches that can help redefine their game design problems in new ways. I completely agree, and again feel like that same lesson can be applied in reverse—hire great game designers to work on your UX, assuming you can pull them away from their game designing long enough! It'll be good for them and good for you.
It would be better if it said "third person camera." I was let down because I thought the author had jury rigged two physical cameras to capture 3d images.
While reading about the evolution of the camera and pushing away from the wall (or not) it strongly reminded me of the game Tremulous. The initial alien class is a very short spider that moves very quickly and can walk on walls. When running into a corner the camera does a (user-adjustable speed) rotation. The same happens if you jump into a wall. But in this game the solution seems to be more direct- you are always headed straight for a wall, and there seems to be much less wall-walking as "wall-flinging."
Great post. When I hear people on social media complain about any given game, I think of how the development process of pretty much every single game involves complex situations similar to what's described in the article. Game development is tough!
Wow, I think this is an amazing example of how articles on the web aught to be written. Clean presentation, great typography, entertaining yet not too superfluous prose, and plenty of tasteful illustrations and visualizations. Hopefully this is the start of a new trend.
I love these lengthy write-ups packed full of fantastic commentary and examples but this is an especially good one and must have taken you an age to put together.
Slightly off topic, I once asked Scott Hanselman how long it takes for him to make articles like that, full of description and images in a way that pulls you into the text.
He told me that around 2 hours.
I guess that this is only true once you have a lot of practice and clearly knows what you are doing. When I write (not often) it can take a whole lot more to finish something like that.
I'm curious now as to how long it took by the author to complete the article especially to recover images and GIFs from old/previous stuff.
I wish there would be a site which collects such detailed technical writeups. There is just so much good stuff out there which is impossible to find again through Google.
You'd need a lot more space between them for that to be effective and it would not work for anything that moves because the images are also spread out in time.
That's why old school stereo cameras had their lenses much further apart and that's why they fired synchronously.
Would have to be a high FPS camera. Some cheap linear rails and a NEMA 17 motor. Of course you would have to get the "sync pulse" out of the camera, then you would probably have to do a delay move to move into position before the next snap.
Sliding it back-and-forth would create too large accelerating/braking forces. Easier approach would be to put camera on a rim of continuously rotating wheel and take shots when it reaches positions of 90° and 270°.
Good camera control in games is quite hard. If the camera is third-person, finding a valid place for it is tough in tightly bounded spaces. Letting the camera move through a wall is considered unacceptable today. (Second Life still does this, frequently. They're stuck in the 1990s there.) If the camera is too close to the character in third person, the player can't see what they're doing.
I'm not super interested in the topic, but the way you wrote the article (visual examples, using understandable language, not overwhelming with technical details) is awesome! Tech bloggers everywhere should take note. Overall, very interesting journey.
Great article - I enjoyed it and it makes me want to play more with 3D rendering!
The camera placement and black shading work seems excessive - I think it could be simplified by having the camera behave as a physical object that must obey collision rules in the game world.
So desired camera lcoation is displacement XYZ relative to the player, but the displacement is reduced by collisions as needed until at the player's location, yielding a first-person view if the player is right next to a wall.
Then the only blocking surfaces would be the player avatar itself, which could be rendered transparent as needed.
"The point is, most of these ideas are simple and obvious in hindsight, but I had to make a lot of mistakes to find them. It's nearly impossible to coalesce good design decisions straight from the ether. The only reliable method is iteration and trial and error."