Code Trinkets are a Bad Idea

Often when engaged in the construction of some piece of software, be it a web application or a native computer game, we get the Feature Fever. Our brains are trained by years of computer use to judge software by its polish. The tendency is misguided at best, and we try to think past it when fairly evaluating a prototype. But the fact of the matter is that even one or two polished aspects of a website makes it look better.


When you imbed a YouTube video or add rounded corners to your buttons, you are deceiving yourself. When you look at the screen, your eye is drawn to these familiar, visually impressive elements. Consequently, you subconsciously ignore or undervalue the unfinished parts of your project.

This leads to two things. First, you think you are farther along than you are. But more importantly, it makes you hungry for more features. Since one or two polished aspects look good, why not add more? Now you are on the hunt for short-term fixes that give big rewards in terms of visual polish, rather than working on the code that actually makes your program work.

If you start polishing before your core functionality is complete, you can get pigeonholed. When an interface element is polished, or some other unique feature looks amazing, you reflexively want to protect it. Even if the rational decision is to get rid of it and integrate the functionality somewhere else, you will keep the feature there. Letting form overpower function is a deadly trap.

The easiest way to add a polished feature is to search on the internet for code trinkets. Code trinkets are little snippets or blocks of code that you stick into your programs. Code trinkets are encapsulated, so all you have to do is paste and reload. Suddenly a beautiful new feature is completely finished.

Unfortunately, code trinkets have two downsides: they restrict your feature to exactly what is written, and they don’t leave you any smarter. Unless you take the time to figure out what ever line of the trinket does, and would be able to write it yourself (at which point it stops being a trinket), don’t use it!


Into the Unknown: UDK Part 1

I tried this before, but ended up quitting. I believe now that my exit was premature. I refer of course to my adventure into the Unreal Development Kit, a free version of the Unreal Engine that allows developers to create their own games in the Unreal Engine.

My reason for embarking on the adventure was to recreate the gameplay from Halo: Combat Evolved on an updated platform. The bonus is two-fold. For the longest time, I have had a Halo custom campaign in the works, but have never really gotten the Halo Editing Kit tools to work for me. Secondly, I have always felt the need to learn how to use a 3D game development tool. After exploring Unity slightly and having dabbled in CryEngine 2 (and somewhat 3), I decided it would be good to experience the Unreal Engine.

Posting updates on this blog serves two purposes: One, it keeps me from giving up again. Second, it helps me quantify my successes and organize my thoughts. Hopefully I can post an update on this project every two or three weeks, with either video or pictures to show off new milestones.

Without further ado, I want to outline some of my goals for the upcoming project:

  1. Learn how to create:
    • particle effects
    • weapons
    • vehicles
    • characters
    • AI behavior
    • scenery
    • level geometry
  2. Learn what else I need to learn

Computer Mysticism

Last weekend I installed two different versions of Windows on two computers. One was a brand-new PC I built myself, and one was an HP that needed a reinstall. One needed a VPN connection to the MIT network to validate. The other one needed to have its proprietary drivers backed up and restored.

There’s a certain magic to computers when you start getting into the low-level stuff. I don’t mean programming-wise. Reinstalling Windows is more of a mystical art than a straightforward process.

Ancient forum tomes are filled with archaic tutorials. Software is a moving target, and complex formulas and hacks are prone to break down over time.

But even worse is the amount of superstition that gets poured into computer maintenance. Each user has rituals that they are convinced ward off errors. Actually, we see this in all sort of technology usage; people have rites designed to improve buffering speed, battery life, and disk readability. I know a group of people who have a running joke that involves standing on one foot when doing any complex computer maintenance to make it work.

The reclusive Linux alchemists mix their own potions (disdaining the draughts pushed by the shops in town), but use indecipherable notation in their recipes. Elixirs are delicate brews, and the average person doesn’t have the same instincts that let alchemists be productive.

Yet after going through the ordeal of reinstalling Windows or constructing a computer from scratch (and having it work!), you have a lingering feeling of power. The minor incongruities and annoyances that plague modern software usage no longer make you feel helpless. You are an empowered user, able to conquer any confounding roadblock. You may not be a mage, but you aren’t completely powerless under the whims of the wizards in the grand Corporate Tower.

%d bloggers like this: