The Value of Reverse-Engineering Classics?

Aad031f1015a22a9a8a428dcc0558dd5
0
TheUndesigner 101 Apr 20, 2013 at 23:50

EDIT: It appears I have made a poor choice of terminology here. I should clarify: by ‘reverse-engineer’, I mean conceptually, not in terms of coding. I would not, in fact, try to learn game design by examining how classic games were coded, though it is a very interesting thing to look at in its own right. By ‘reverse-engineer’, I meant taking a game apart into its component conceptual elements - layouts, behaviors, and such - in order to figure out what kinds of choices developers were faced with and ultimately made when they set themselves certain goals, or alternatively what kinds of things went into making certain player experiences. If it is less misleading, perhaps the term ‘reverse-design’ would be more appropriate? I mean to imply something more in-depth than mere critical examination, of which there is a great deal online at this time. My direct inspiration for this undertaking is this fascinating feature on The Game Design Forum, if that helps.

So, I’m going to be up-front here before I do anything else: I’m starting this thread to shamelessly self-promote my new blog at www.theundesigner.com. It’s relevant to the topic. That being said, I’m also doing more than that, so if you’re not offended by my moment of selfishness, please read on.

Okay, so about a year ago I and a friend decided we would try our hand at making a simple platformer game. We were going to do twin mini-games with similar engines and simplistic design, a throwback to the old-school days. We got our engines hammered out and my friend managed to put out a couple of tolerable designs. I fell behind due to some work woes, but once I got started, I discovered I had an even bigger problem:

I didn’t have a single clue how to go about designing a level in a platformer.

Mind you, I was quite aware before I started that level design is hard. I wasn’t expecting things to be easy. But it wasn’t a matter of difficulty at all; I just didn’t have an idea even where to start. I didn’t know where to look for advice; most of the game design resources I know cover programming, basic mechanics, and some elements of design philosophy. I don’t know of any that provide basic techniques for combining design elements into coherent experiences. I’m sure it must be out there, but I’m not connected in the game design world (I’m nothing more than an enthusiastic amateur, though I am pretty well educated) and I had nowhere to start looking.

I’m taking matters into my own hands now by reverse-engineering some classic games, starting with the Mega Man series on the NES; my view is that since old-school games managed (sometimes) to create lengthy, satisfying experiences with relatively few and simple design elements, they would be the best place to look to observe and codify techniques for level design, especially since games in that era often found ways to teach and train players through level design and difficulty curves rather than tutorials and guides.

But, what do you think? How much value do you think there is in taking apart old games and theorizing about what the developers were trying to do? After all, games in the NES and SNES days were made long before there was a ‘science’ of game design; they knew what they were doing, of course, but it was a much less structured form of art. If you were to reverse-engineer a game from that era (or any era, for that matter), what game would you choose, and what would you be looking for? How much of what you learned do you think would be applicable to your own efforts, or the efforts of other designers? And why do you suppose it is that this sort of analysis isn’t a fairly common thing already? Or, am I wrong - i**s it a common thing already, and I just missed it? I’ve seen a couple of blogs that do it, notably Jeremy Parish’s brilliant and insightful Anatomy of a Game series, but it’s not as common as I would think it would be. I’m interested to hear what you people think.

4 Replies

Please log in or register to post a reply.

A638aa42130293f319eda7fa4ba121f4
0
fireside 141 Apr 21, 2013 at 01:53

It’s good to analyze old games, or any games, and try to figure out what makes them good. I don’t think reverse engineering is important at all for the process and I doubt it would help. It’s mostly a matter of pacing and adding new elements of game play at the right stages to keep the experience fresh. Copying is an essential part of the learning process, but if you never take that next step and do your own designs, you really haven’t done anything. One of the best tools for learning design is to make a game, let people play it, and open it up for critique. There isn’t much about it because it’s so wide open. As soon as you define rules for design, it becomes formulaic.

Aad031f1015a22a9a8a428dcc0558dd5
0
TheUndesigner 101 Apr 21, 2013 at 03:42

@fireside

It’s good to analyze old games, or any games, and try to figure out what makes them good. I don’t think reverse engineering is important at all for the process and I doubt it would help. It’s mostly a matter of pacing and adding new elements of game play at the right stages to keep the experience fresh. Copying is an essential part of the learning process, but if you never take that next step and do your own designs, you really haven’t done anything. One of the best tools for learning design is to make a game, let people play it, and open it up for critique. There isn’t much about it because it’s so wide open. As soon as you define rules for design, it becomes formulaic.

Those are excellent points, and ones I certainly intend to keep in mind. It isn’t my goal to ‘copy’ anything; what I want to do is learn what kinds of decisions highly successful developers made when faced with certain goals and their associated difficulties, to see what techniques and insight I can learn from it. I suppose I’ve been influenced by my education - I’m a Liberal Arts major and learned to study by dissecting the works of classic and influential thinkers in order to guide and inform my own thoughts and efforts. But the thoughts and efforts remain my own. It’s possible that this method isn’t really suitable to this subject; if so, I’ll try something else. And I certainly intend to get player feedback when the time comes to try my own ideas out. I’ve done a bit of it already, but it’s hard when you aren’t connected with any game development communities - which is, of course, another goal of my efforts.

B5262118b588a5a420230bfbef4a2cdf
0
Stainless 151 Apr 21, 2013 at 09:15

I’ve reverse engineered a hell of a lot of games. Mostly it was when I was working at freeloader.

Freeloader had the idea of buying publishing rites for games and giving them away for free making their money from advertising.

My job was to remove the copy protection, split the game into downloadable modules, insert our own code to link to the website, and fix any bugs in the original game.

Not an easy job when all you have is the exe file, but I enjoyed it.

I’ve also extensively reverse engineered a couple of my favorite games, Starflight for one.

Starflight was an amazing game for it’s day. Nearly a thousand planets, multiple races, comms, a story line, all in 360K bytes.

It was written in Forethought, a variety of Forth. One of the side effects of this is that it is very easy to get source code from the exe file.

I learnt a lot about Forth from that game.

I really doubt you will learn anything about game design from reverse engineering games. You will however learn a hell of a lot about compilers and what visual studio does to your nice clean source code.

Not that that is a bad thing, knowing what your code will produce is a very useful skill and will make you a better coder.

Now I spend most of my time porting games. I get full source code for each game, but still need my reverse engineering skills. You would be amazed how many games ship full of bugs and bad code. Often I have to reverse engineer the resource generation system in order to get the game to build.

Aad031f1015a22a9a8a428dcc0558dd5
0
TheUndesigner 101 Apr 22, 2013 at 00:18

That’s actually really interesting, Stainless, but it also reveals that I have been communicating poorly here. I should have realized that the phrase ‘reverse-engineering’ would have a specific and specialized meaning to someone involved directly in the process of coding games, but as a matter of fact I meant it in a more conceptual way - rather than breaking a game down into its code, breaking it down into its choices: specifically, the choices of its developers in order to achieve the player experiences they wanted to create. But this misunderstanding is going to be common as long as I keep that term around, so I am going to change my post to reflect it. I’m sorry for not communicating clearly.

As it happens, though I lack the hard skills and software resources to reverse engineer a game myself, I did do some research on how the Metroid cartridge was coded back in the NES days; I don’t know that I learned much about game design from it, but it’s pretty fascinating how clever developers could get back in the days of limited space to compress and format their data to get around limitations. Crappy hardware is the mother of invention, I suppose.