Dirty Game Development Tricks(gamasutra.com)
gamasutra.com
Dirty Game Development Tricks
http://www.gamasutra.com/view/feature/194772/dirty_game_development_tricks.php
9 comments
On the last page:
HR hacks -- Ben Burbank -- When I used to work for a very big company, one of the employees figured out that the best way to advance his career was to write negative performance reviews for as many co-workers as possible. This resulted in him receiving a higher annual staff ranking, which in turn led to larger bonuses and stock grants. It eventually becomes difficult, he told me, because you need to make sure to only review people with different managers, so nobody can catch on to your ruse. My trick for avoiding this cycle was to quit and go work someplace much smaller and awesome
Wow. Just wow. So far I have avoided working anywhere with a culture that evil.
HR hacks -- Ben Burbank -- When I used to work for a very big company, one of the employees figured out that the best way to advance his career was to write negative performance reviews for as many co-workers as possible. This resulted in him receiving a higher annual staff ranking, which in turn led to larger bonuses and stock grants. It eventually becomes difficult, he told me, because you need to make sure to only review people with different managers, so nobody can catch on to your ruse. My trick for avoiding this cycle was to quit and go work someplace much smaller and awesome
Wow. Just wow. So far I have avoided working anywhere with a culture that evil.
See also: "The Cool Cam"[1] on The Daily WTF.
1: http://thedailywtf.com/Articles/Classic-WTF-The-Cool-Cam.asp...
1: http://thedailywtf.com/Articles/Classic-WTF-The-Cool-Cam.asp...
Loved that article. I work as a UI developer, and sometimes it helps to remember that story. A couple CSS3 animations here and there always liven up a boring presentation of new features.
It's easy to think that you wouldn't, but in practice many companies have stack ranking systems that are effectively more or less equivalent, and encourage employees to game the system rather than just to do good work. But they are cloaked with more layers of bureaucracy which disguise their natures better.
Stack/Rank is the primary reason why I have never responded to Microsoft recruiters over the years. It results in teams being torn apart as they each try to force someone else to be the "5". And dysfunctional behavior like intentionally hiring a 5 in order to protect the other team members. So you never know if they're hiring you because they want what you can bring to the company, or because the manager needs a sacrificial lamb that year.
> This resulted in him receiving a higher annual staff ranking, which in turn led to larger bonuses and stock grants.
The joke's on that guy, given what EA's stock value and bonuses have been like lately.
The joke's on that guy, given what EA's stock value and bonuses have been like lately.
My favorite little trick of these was that the bushes and the clouds in Super Mario Bros. were the same shape (presumably to save space): http://www.todayifoundout.com/index.php/2010/01/the-clouds-a...
I would never want to enter the game development industry but I would love to shadow them for a few weeks. It sounds like a culture of required innovation (and, you know, eternal crunch time).
I would never want to enter the game development industry but I would love to shadow them for a few weeks. It sounds like a culture of required innovation (and, you know, eternal crunch time).
That's a little different from the tricks described in the article, though: Not a last-minute hack, but a deliberate space compromise of the kind that these games absolutely were built around.
Ever notice that a lot of old games have very repetitive worlds? Most of them are built around what some call a "room sprite": a prefabricated room that can be placed anywhere in the world. The world, then, is not much more than a big array of of indices into an array of expensive room sprites.
That's relatively straightforward, but it gets interesting when you store some information about an instance of a room separately from the "sprite" itself. Simplest example: If you store the hardware color palette and/or tilemap information separately, you can use the same basic room in different dungeons and make it look significantly different each time.
If a game has a generic "item room" (like the ones in Metroid or Zelda), you can bet that each instance of that room only needs to specify a single byte representing the item to be found in it.
A more interesting application are the doors in Zelda: They're not a part of the "room sprite" itself. Instead, for each possible north, south, east, and west door, there's a simple bitflag that enumerates a few possibilities: "no door on this wall, there is an open door, there is a locked door, there is a door that you must trigger an event to open, etc."
I don't know if Zelda does this, but it would be pretty easy to allow rooms to be flipped horizontally or vertically as well.
Just these few techniques, a dozen rooms, and thoughtful game design would probably be enough to get a few decent dungeons that would take hours to beat, out of a modicum of kilobytes.
My favorite example of this idea: If you really explore the original Metroid, you'll find a lot of hidden bombable paths that don't always lead anywhere. For instance, all item rooms have a pipe underneath them that can be entered by bombing a nearby block, but in most of the rooms, the pipe doesn't lead anywhere. If you don't know any better, it seems like the designers are just playing with your curiosity. In hindsight, it's totally obvious that this was a trick to let the game designers choose whether or not to put a secret passageway behind a particular item room just by lining up a different room next to it!
Once you get this, you see it everywhere in the world. You start recognizing different room sprites, and memorize the where their hidden paths are located. With that and the realization that the game only ever scrolls along one axis at a time, the seemingly impossible task of mapping out the entire world ("do they really expect me to shoot every single wall?") quickly becomes a simple effort of pattern memorization. Sadly, most people who try the original Metroid today get tired of climbing up those long vertical shafts and starting with only 30 health and quit before they even get a chance to discover this metagame.
Ever notice that a lot of old games have very repetitive worlds? Most of them are built around what some call a "room sprite": a prefabricated room that can be placed anywhere in the world. The world, then, is not much more than a big array of of indices into an array of expensive room sprites.
That's relatively straightforward, but it gets interesting when you store some information about an instance of a room separately from the "sprite" itself. Simplest example: If you store the hardware color palette and/or tilemap information separately, you can use the same basic room in different dungeons and make it look significantly different each time.
If a game has a generic "item room" (like the ones in Metroid or Zelda), you can bet that each instance of that room only needs to specify a single byte representing the item to be found in it.
A more interesting application are the doors in Zelda: They're not a part of the "room sprite" itself. Instead, for each possible north, south, east, and west door, there's a simple bitflag that enumerates a few possibilities: "no door on this wall, there is an open door, there is a locked door, there is a door that you must trigger an event to open, etc."
I don't know if Zelda does this, but it would be pretty easy to allow rooms to be flipped horizontally or vertically as well.
Just these few techniques, a dozen rooms, and thoughtful game design would probably be enough to get a few decent dungeons that would take hours to beat, out of a modicum of kilobytes.
My favorite example of this idea: If you really explore the original Metroid, you'll find a lot of hidden bombable paths that don't always lead anywhere. For instance, all item rooms have a pipe underneath them that can be entered by bombing a nearby block, but in most of the rooms, the pipe doesn't lead anywhere. If you don't know any better, it seems like the designers are just playing with your curiosity. In hindsight, it's totally obvious that this was a trick to let the game designers choose whether or not to put a secret passageway behind a particular item room just by lining up a different room next to it!
Once you get this, you see it everywhere in the world. You start recognizing different room sprites, and memorize the where their hidden paths are located. With that and the realization that the game only ever scrolls along one axis at a time, the seemingly impossible task of mapping out the entire world ("do they really expect me to shoot every single wall?") quickly becomes a simple effort of pattern memorization. Sadly, most people who try the original Metroid today get tired of climbing up those long vertical shafts and starting with only 30 health and quit before they even get a chance to discover this metagame.
I never heard the bomb-pipe strategy described that way. I figured they were just prepping you for that One Very Special Room where it actually did something.
Once you realize that long corridors in Metroid are just integers representing the same room repeated, it makes a lot more sense.
Once you realize that long corridors in Metroid are just integers representing the same room repeated, it makes a lot more sense.
And in Pitfall, David Crane basically used a random number generator with a predefined seed to generate the world (http://www.youtube.com/watch?v=MBT1OK6VAIU starting at the 22:12 mark).
Unstable, underpaid, overworked and extremely competitive market. Also, pinnacle of engineering in both frontend and backend; eats web dev for breakfast.
Writing your own games (either in your free time or as an attempt to make a living from it) is extremely fun though, and I would recommend that any developer pick up an intro to game dev book and have at it :)
Can you recommend a book on game dev for senior developers? IE I do not want to be hand-held through how to program, just the physics and concepts of good structure for game development.
As a senior dev who's just started to dabble in games I've found Game Engine Architecture by Jason Gregory to be very useful and high quality.
Oh looks like there's a second edition coming out at some point http://www.amazon.com/dp/1466560010
Oh looks like there's a second edition coming out at some point http://www.amazon.com/dp/1466560010
It's a fantastic book, for sure. Gamasutra published an excerpt of it when it came out, going over some of the section on the main game loop: http://www.gamasutra.com/view/feature/132587/book_excerpt_ga...
Woah, thanks!
What about web game dev now? We're almost seeing entire operating systems running in JavaScript.
Can we please just keep producing game binaries for the desktop where it actually runs like it's meant to? /rant
Can we please just keep producing game binaries for the desktop where it actually runs like it's meant to? /rant
Writing JS games is fun :) I've got a little html5 game engine I'm working on: https://github.com/joelmartinez/flatredball-js
Here's a live sample (that you can edit in real time) - http://joelmartinez.github.io/flatredball-js/#rain
It's not as much about reinventing things in JS, it's about exploring what is possible in that environment. I'm not a huge fan of the "compilers" that just take an executable and compile it to JS ... I'm more going for a "native web" experience.
Here's a live sample (that you can edit in real time) - http://joelmartinez.github.io/flatredball-js/#rain
It's not as much about reinventing things in JS, it's about exploring what is possible in that environment. I'm not a huge fan of the "compilers" that just take an executable and compile it to JS ... I'm more going for a "native web" experience.
Let's not pretend a bouncing ball is exciting regardless you see it in the browser or not. (Except if you're seeing your own stupid ball animation, of course.)
Writing games in any language is fun, so by all means keep doing what you enjoy. :)
But let's not forget all these problems JS implementations see have already been solved extremely well on the desktop.
Writing games in any language is fun, so by all means keep doing what you enjoy. :)
But let's not forget all these problems JS implementations see have already been solved extremely well on the desktop.
I hear this on HN quite a bit, but it's not that big of an issue. Most game developers don't need the raw speed of a native system. They do need to create something that can be played by everybody, and is easy to develop for.
The very fact that we're seeing so much html/js game dev (including games packaged with a browser as native apps)says it all. Game developers don't pick up a language/platform lightly, if they're making games for it, it's a good choice.
However, regarding mobile platforms, you can forget all I've said.
The very fact that we're seeing so much html/js game dev (including games packaged with a browser as native apps)says it all. Game developers don't pick up a language/platform lightly, if they're making games for it, it's a good choice.
However, regarding mobile platforms, you can forget all I've said.
It is not my concern that some indie developers use whatever they are familiar with. We've been playing those funny stick figure flash games on rainy days anyways. They can be fun to play and fun to develop.
However, it is the big studios that should not push to this platform. They had compile-time guarantees, insane ecosystem, known performance tradeoffs. And now some of them want a huge pile of (as in million+ LOC) game engine running on top of a broken scripting language. And for what in exchange? So that the installer's gone and assets are delivered on demand? MMOs have been doing this for years on the desktop.
In short, if you do it for fun, please use whatever feels good. If you do it for the money, please do your research and don't make my browser freeze -- I'll just go to Kongregate where the former publishes their games.
However, it is the big studios that should not push to this platform. They had compile-time guarantees, insane ecosystem, known performance tradeoffs. And now some of them want a huge pile of (as in million+ LOC) game engine running on top of a broken scripting language. And for what in exchange? So that the installer's gone and assets are delivered on demand? MMOs have been doing this for years on the desktop.
In short, if you do it for fun, please use whatever feels good. If you do it for the money, please do your research and don't make my browser freeze -- I'll just go to Kongregate where the former publishes their games.
"The very fact that we're seeing so much html/js game dev"
We are? Games that make money? Most games may not need the raw speed of native, but they do need the raw latency. If a game is being programmed in a garbage collected language you're gonna have a bad time.
We are? Games that make money? Most games may not need the raw speed of native, but they do need the raw latency. If a game is being programmed in a garbage collected language you're gonna have a bad time.
I'm currently developing a game using Impact.js, and it's no picnic having to work within the limitations of the browser.
Which is sort of my point. There's so much we haven't explored in the compiled world, but we're busy reinventing all the same things in a slow fragile sandbox.
Just the clouds you say? I count 12 distinct tiles on that screen. They were incredibly efficient with space-- the rom for that game is 40kb.. less than two uncompressed htmls of the front page of HN!
> They were incredibly efficient with space
Not saying they were not, but compressed 64 color graphics/palettes and 6502 machine code would usually not take an enormous amount of space.
Not saying they were not, but compressed 64 color graphics/palettes and 6502 machine code would usually not take an enormous amount of space.
I love the idea of the developer causing a buffer over-run to patch their own game. Does kind of make one wonder what other dragons lurk in that particular code set.
Seems like a hacker could exploit that to bootstrap in a loader.
Looks like many of these tricks steems directly from the lack of good debugging tools (paired with tight deadlines). Is console game development really that bad? The guy debugging with colored screens is a real WTF.
> Is console game development really that bad?
Well, that story was from 11 years ago. Even then, PS2 and XBox devkits weren't bad. Comparable to IDEs at the time, or maybe even a bit more powerful for debugging.
> The guy debugging with colored screens is a real WTF.
That's essentially the graphics equivalent of printf() debugging. It's all about quickly getting some insight into what's going on. If hacking some colors in there does it, so be it.
Note that this was a bug occurring related to handling user input while loading, so it's likely that pausing the game or stepping into a debugger would actually prevent the bug from occurring. In situations like that, you make do with what you can.
Well, that story was from 11 years ago. Even then, PS2 and XBox devkits weren't bad. Comparable to IDEs at the time, or maybe even a bit more powerful for debugging.
> The guy debugging with colored screens is a real WTF.
That's essentially the graphics equivalent of printf() debugging. It's all about quickly getting some insight into what's going on. If hacking some colors in there does it, so be it.
Note that this was a bug occurring related to handling user input while loading, so it's likely that pausing the game or stepping into a debugger would actually prevent the bug from occurring. In situations like that, you make do with what you can.
Seconding this, especially the bit about colored screens. Sometimes, you just need a simple way to get some information up on the screen at a minimal cost to runtime performance and code-complexity.
I'd find it hard to believe that anyone back in the day didn't use the "change the color of the background by manipulating the hardware color palette during different sections of the frame logic so you can 'see' how long each part is taking" trick.
I'd find it hard to believe that anyone back in the day didn't use the "change the color of the background by manipulating the hardware color palette during different sections of the frame logic so you can 'see' how long each part is taking" trick.
I'd never heard of it until I came across it mentioned/shown[2] in the [unofficial] C-64 Prince of Persia conversion[1] linked from some HN thread the other day.
I've done the Storage Oscilloscope + pin twiddling for profiling embedded stuff though, and for a few short minutes, was convinced I'd invented something brilliant. :)
[1] http://popc64.blogspot.co.uk/2011/10/part-one-why-hell-would...
[2] http://popc64.blogspot.co.uk/2012/01/part-nine-optimizations...
I've done the Storage Oscilloscope + pin twiddling for profiling embedded stuff though, and for a few short minutes, was convinced I'd invented something brilliant. :)
[1] http://popc64.blogspot.co.uk/2011/10/part-one-why-hell-would...
[2] http://popc64.blogspot.co.uk/2012/01/part-nine-optimizations...
This is how you debug parallel real time systems everywhere. No debugger can trace multiple processors (of different architecture and speed) simultaneously.
I love these kinds of anecdotes, this is one of my favorites: http://exile.acornarcade.com/devel.html
hmm, buffer overflow exploit via the EULA to patch the game since you shipped without the ability to patch, there's a game dev hack if I've ever heard of one.
Back on Wing Commander 1 we were getting an exception from our EMM386 memory manager when we exited the game. We'd clear the screen and a single line would print out, something like "EMM386 Memory manager error. Blah blah blah." We had to ship ASAP. So I hex edited the error in the memory manager itself to read "Thank you for playing Wing Commander."