I’ve been sick for almost a week now. Last week I was running short on sleep and could feel myself coming down with a cold. It finally hit Friday night. Despite being sick I still went ahead with my plans for the weekend and managed to get everything done that I wanted to (including a welding lesson from my Uncle). I did have one scary thing happen though – the nut on the top of one of my rear struts shot off while I was driving. I guess I didn’t have them torqued down enough when I replaced them myself. Luckily my uncle was able to get it reassembled without having to pull it off. There’s something to be said about staying cool when things aren’t (which I didn’t do).
On the game development related side of things, I have come across a few interesting reads. Here they are:
Programming sucks, or at least it ought to – an interesting read about writing business software. Not so much related to the game development industry, but still nonetheless a good read. It’s also a good reminder of the Rope Bridge Philosophy of Jeromy Walsh:
While I was working as the tools lead at Pandemic Studios I adopted what I call the “Rope Bridge” analogy, and used it to describe to my juniors the best way to proceed with implementation. Sit back, relax, and clear your mind as I illuminate for you an ancient and mystic method for implementing your projects.
A project is broken up into systems, systems are broken up into classes, and classes are broken up into methods and properties. Any time you are given a task, you are being asked to implement either a system, class, or some sub-component within a class. Understandably, your first instinct is to figure out where you are now, and where you need to be in order to call your task ‘complete.’ Now, there are two ways to do this. One is to begin coding from where you are, adding new functionality, building out your classes and systems, etc…until you eventually end up at your destination. This is, metaphorically speaking, the equivalent to standing on one side of a large chasm and beginning to build a large concrete bridge as you walk across. As most civil engineers will tell you, this is a very daunting task, and requires hair-line precision. An inch off in either direction can send your bridge off to one side or another or drive it into the side of the cliff. At the same time, concrete bridges are known for being sturdy, immovable, and well…just plain not very flexible. With programming it’s no different. Trying to get completely from point A to point B requires a good deal of foresight, which is made even more difficult when attempting to develop a system which is flexible. This leads us to the alternative…The Rope Bridge.
Imagine you are standing on the same chasm, and have been given the task of getting to the other side. Instead of working from beginning to end, developing a cement bridge, instead, build a rope bridge. A rope bridge is the smallest, most fragile form of passage from one side to the other. It doesn’t hold a lot of weight, doesn’t allow many paths from one side to the other, tends to be a bit low hanging, but damn it’s flexible.
From a programming standpoint, this means take the easiest route from point A to point B, with the least amount of code necessary to accomplish the minimum specification required. In other words…”Just barely get it working.” Once you’ve accomplished this, you’ve successfully built your rope bridge. This makes testing possible, allows for immediate user feedback, and gives you an idea of what you may be able to expect from your bridge (and the chasm) in the near future. Once the rope bridge has been built, your job becomes clearer. It’s time to add some suspension (stability) to it. This means making it safer. This can include assertions, or other debugging tools which helps to guarantee your code will be more secure.
Next, you must make the bridge wider. It’s great that you’ve got this little suspension bridge, but if it only allows the “Diamond in The Rough” to cross the bridge it wont prove very useful. This comes in the form over method/operator overloading, properties, conversion classes, and anything else which allows more methods of accomplishing the goal you’ve already completed. Why do this? Ease of use, and flexibility. Always design your systems to be just a bit more flexible than you think is necessary.
Finally, pave your bridge and make it solid. I’m not sure how this applies to the coding paradigm exactly, but the best I can guess, it means prepare the code/system you’ve created for higher volume of invocations, and make sure its stable enough to accept the most unexpected circumstances. How you go about doing this seems to be more case-by-case and depends on the type of system you’re implementing. In general though, this involves a bit of refactoring and cleanup. Always make sure your code is precise and concise.
So what’s the moral of the story? BUILD A ROPE BRIDGE!!
(I hope he doesn’t mind me quoting him).
I’ve also bundled up a whackload of links that I need to go through from my Favourites at work (and at home). I’m sure I’ve got a few hundred links I should post that talk about different game programming things, XNA, graphics programming, physics programming, etc.