Knowing When to Hack

Aug 24, 2009

Hacking as Rushed Programming

The word “hacking” doesn’t mean to programmers and software developers what it does to laymen. It used to mean committing computer crimes, but today that is more often referred to as cracking, or with an extra preposition added in the phrasing “hacking into” a computer. When people first started editing commercial videogames, like Command & Conquer or Doom, using homemade tools that the commercial game developers didn’t officially endorse, that was what hacking referred to for awhile… but these days that’s called “modding.” So when we use hacking here, we’re using it’s most common usage among modern programmers: writing sloppy, on-the-fly, rushed code that’s the bare minimum to accomplish the task at hand.

Proper Engineers Hate It

Hacked code is known for being difficult for anyone to understand other than the person that wrote it, for being inconvenient to update/maintain, and for generally not reflecting good habits and principles of scalable programming.

Any reputable Computer Science or Engineering education will develop a scornful disdain for hacking in every student that passes through its doors. Researchers and professors and systems professionals will frown upon the idea strongly. If the habits of hacking seem deeply ingrained in a potential employee, a recruiter or interviewer may find a person unemployable.

Good Devs Know When to Do It

Videogame development is not exactly like research. Nor is it like programming an operating system, compiler, telecommunications satellite, or missile defense system. Those projects have extremely strict requirements in terms of functionality, stability, maintainability, and code readability. The time and money that go into those serious projects is often tightly bound by business calculations, without much passion or love or creativity from team members pulling extra hours from their personal lives to cram more love and cool stuff in. If something goes wrong with that serious software, then someone’s degree is at stake, or businesses will lose millions of dollars in missed business opportunities, or soldiers will be killed. If something goes terribly, terribly wrong in a videogame, the player may have to replay 20 minutes of something they hopefully enjoy doing anyway, and it’ll lose a few points in reviews.

What this means is that there absolutely, positively, without a doubt, is a time and place for hacking in videogame development.

But when?

Once, It Was the Only Way

The original videogames in nearly every genre were only possible because of absurd amounts of awkward hacking. That includes the first videogame ever. That also includes Adventure, the first action-adventure videogame, from 1978 by Warren Robinett (PDF presentation slides, mirrored as PDF version of a PPT from Warren’s site). It’s true too for each of the major innovations in first-person shooters John Carmack created with id Software (Catacombs 3D, Wolfenstein, Doom, Quake), which were notoriously made possible through Carmack’s willingness to write hard-to-read code when it was the only way at the time to render 3D-looking worlds on such early hardware. That was the only way due to factors relating not only to machine optimization, but also programmer communication overhead, budget limitations, and time potentially taken away from polishing other features of the games.

Tradeoffs and Circumstances

Beyond basic requirements, what can be done in a videogame is determined by tradeoffs, or opportunity cost. Opportunity cost is estimated based on time and staff required to make something possible. If it can be done by 1 person in 2 hours the “wrong” way (getting in the way of doing future things the “right” way), but would take 5 people 3 days to do it the “right” way (easier to update, more predictable effect on the rest of the system), then there are a few important considerations as to which path is preferred:

  1. Is the project near completion, with no sequel in sight? If the hacked method involves writing code that will be cryptic, or hard to build a wide variety of features on top of, this is more of an option near the end of the project when the readability issue will be in code that may never be seen again, and your team is out of time to add any unplanned features atop the hack anyway.
  2. Are you certain that the game is definitely better with the feature than without? If there’s a chance that it won’t look, play, feel, and act in a way that benefits the game – and sometimes there’s no way to know until the feature is in – then consider doing the 2 hour hack implementation to try the feature out. Information gathered from having it working in-game can then be used to inform whether it’s worth investing 5 people for 3 days to get it done right, or just backing out the changes with the added certainty that the path isn’t worth exploring.
  3. Are you certain that the “proper” method will really offer any advantages in the context of the project’s needs, or that it accomplishes the same goal as is possible by the hacked implementation? There are many cases where properly organized, highly readable, professional patterned code may be best for human eyes, but less-than-optimal for machine computation in terms of memory or processing time. What you don’t want to do is dedicate the time and development staff to implementing a feature the “right” way only to discover for some reason that it’ll need hacks anyway to perform fast enough for inclusion in the game. (Disclaimer/warning: not all hacks are faster, and some classic hacks if used with modern compilers are redundant or detrimental.)
  4. Smart engineers feel guilty about writing “special case’ code. Special case code is a bad idea a lot of the time, because it’s time and energy that cannot be effectively re-used elsewhere. But in the case of videogames, we must ask, “Is this a special case?” Should only 1 boss in the game do this? Does this effect only happen in 1 level? Do all other powerups disable when this bonus level is entered? Special cases in the game warrant special cases in the code, and those special cases are what can make boss fights in Mega Man so distinct, as opposed to the not-so-special-cased (but rather cost-effectively generalized) 4 types of bosses used 50 times in Superman Returns.
  5. What else will you be able to do with the time saved by the hack method? Only if you’re out of polish or features that you would like to add to the project – and it’s worth noting that this is virtually never the case – then there’s no opportunity cost of other cool features or polish that could be accomplished with the time. (Unless, of course, that time is going to get burnt up fixing bugs introduced by the hack method.)

Are there times when hacking something in the fast way can come back to cause you trouble? Absolutely. Is it dangerous if overdone? Of course. Though wouldn’t it be foolish to pretend like it isn’t one of many options at your disposal, to be utilized when the risks are understood and can be reasonably mitigated? Yep.

Sometimes the race goes to the driver willing to do push their car a bit further, a bit faster, through spaces that are a bit tighter, than the other people on the track.

(But that option is only viable provided that the rest of the car is built well enough to survive being pushed that far.)

(Originally posted as Vol. 5 Sec. 3)

Este artículo está disponible en español. Traducción por cortesía de Andrés de Pedro.

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!


  1. […] Vol 5 Adv – When to Hack […]

  2. […] mentioned this point before in Knowing When to Hack, but it definitely bears repeating: “special case” is often treated as a bad word by […]

  3. […] before (as opposed to re-implementing someone else’s game), your source code is going to be a bit of a mess by the time the game is finished. You’re firing a machine gun of code at a rapidly moving […]

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.