There are as many ways to conduct code reviews as there are to skin a cat. Some methods are more pleasant than feline taxidermy, some less so. At work, we’ve found a code-review method that has been relatively pain-free while still providing significant benefits: Check-in Code Reviews.
In a nutshell, before a programmer checks any significant code changes into source control, we have them get a quick (usually less than 5 minute) code review from one of their colleagues. In the process, they’re expected to explain roughly how their code works and why they implemented what they did. The reviewer than offers comments and advice (if they have any) and up the code goes to server-land. That’s pretty much it. It’s simple to the point of being trivial, but it has worked out well at work. Here’s why:
Despite what the title of this post may suggest, I’m not going to be talking about some recent trip to Borneo or Papua New Guinea (although how cool would that be!) No, instead I’m talking about my continuing dalliance with the plasma fractal I mentioned in my last procedural content post.
While I used plasma fractals to create variations of the floor tiles in my procedural cave, there are many other applications for plasma fractals. One of the classic applications of plasma fractals is generating heightmaps. By imagining the value at each cell of a plasma fractal as the height of ground at that point, it’s relatively easy to visualize the mountainous terrain that can be generated with a plasma fractal. Traditionally, people use heightmaps values to perturb a 3D mesh grid to create 3D terrain. Since I already had the necessary pieces at my fingertips, I decided to see how my plasma fractals would look when rendered with 2D tiles. Continue reading
Taking a little break from my usual diet of promoting my latest game and talking about procedural content, I thought I’d touch on a common trap that occurs in the process of designing games. If I had to give this trap a name, I’d call it the Mary-Sue Trap of Game Design. Basically, over-focusing on the abilities of the player character to the detriment of the rest of the game.
It’s surprisingly easy to Mary-Sue yourself during game design. When you start down the path of imagining what sort of abilities you want your protagonist to have, it’s very tempting to start pulling every neat gadget you can think of off the shelf and strapping it on. Where this can really get you into trouble is when you’re looking around for that “certain something” because your game just isn’t quite fun yet. You try adding a beam attack. Air-dashing. A counter system. But nothing quite clicks. You’re thinking about how you want to power-up your avatar as opposed to the whole game. That’s the Mary-Sue Trap of Game Design.
So, how do you avoid the trap?
Today is the 6th of March which means that it’s Michelangelo Buonarroti’s birthday. Happy birthday, Mike!
Michelangelo di Lodovico Buonarroti Simoni was born on March 6, 1475. In his lifetime, he created many of the world’s most famous works of art, including the famous statue of David and the Sistine Chapel Ceiling. He also designed great works of architecture such as the Medici Chapel and the Laurentian Library.
I’m telling you, they just don’t make artists like they used to.
In honor of Michelangelo’s birthday, “Michelangelo: The Game” will be free for the next three days.
You can get the game here on iTunes!