 
|
|
|
| 4/26/99 |
|
Last week I received an email from one of our fans, asking me an interesting question. So interesting actually that I'd like to share my thoughts on the issue with all of you. "Why is everyone using C++ to develop games these days, instead of Assembly language that used to be so popular before? Doesn't Assembly create much faster code and wouldn't that be a solution to get more out of older generation processors?"
This is one of the most intriguing questions I have been asked in quite a while, because there is a lot of truth in it, and explaining the reasons is not really a trivial thing. I don't even know where to start, and by the time you read this, I have erased and re-written almost every word of this post three to four times. Let's just start somewhere… and please excuse if this is getting a bit lengthy. The switch from Assembly to C++ was a rather progressive one, taking us from Assembly to C and then to C++. This development happened over the past 12 years or so. Probably all of us who have programmed computer games in the early 80s were complete machine-heads. We programmed in nothing but machine language and hex-dumps. When you program in machine language you literally encode everything you want the computer to do in hexadecimal numbers! I am not lying here, trust me. When I started programming I had the entire command set of the 6502 processor in my head in numbers and I was faster at doing calculations in hexadecimal than in the decimal system. When I programmed I usually had a monitor program which allowed me to write these numbers straight into the computer's memory. Then you saved the memory content to a storage medium, and voila you had your computer program. As you can tell, this technique was not only overly prone to error because all you saw on the screen were bulks of numbers, but it was also very tedious and time consuming. The dawn of Assembly language came. Assembly allowed us to use the same commands but instead of writing them down in numbers, we used shot names for the commands, like LDA, STY, INC etc. Much easier, but still tedious as hell. The advantage was that you had full control over every single byte in the computer. Then came C along - the revelation. Everyone was looking into different kinds of programming languages from Forth to Pascal, from Prolog to Lisp and back again. None of them gave you remotely the flexibility and control of Assembly, until C surfaced. This language had high-level constructs like IF-ELSE, WHILE, FOR-NEXT etc., while also maintaining the subroutine approach that made Assembly so interesting. On top of that C allowed you to directly work with memory and as such gave you full control over what you were doing. Powerful tools that usually came with the C-Compilers were helpful in tracing bugs faster than on the Spartan machine language debuggers, and with the right approach, C-code ended up being very tight, to the point that it could not be outperformed by an Assembly program any more. If need be, you could always use C's own inline assembly capabilities, which allowed you to embed Assembly language right in the C code. All these features made C an extremely popular language among game developers… until C++ came along. As programs become larger and larger, teams sizes also increased. In 1980 when I wrote my first computer game, I did it all by myself. Every line of code I wrote was mine, but as time went on and games had to live up to the demands of the ever-changing, ever-growing market, more and more people got involved. All of a sudden it took a team of programmers to write a game, because there was so much to be done and so many things needed to be very sophisticated. Gone were the days of text-adventures, or block character-set based graphics that were easy to control and manipulate. More colors, more resolution, more depth, more content and better AI were the buzzwords, and all this takes time to do. There was no way to manage such a game in Assembly language - it would take forever. C++ addressed these problems quite efficiently. Through code encapsulation and other methods it was easily possible to have multiple people work on the same project without them interfering with every line they write. C++ enforces a protocol that determines how certain parts of a program interact with others. It didn't matter any more who wrote what, or how it really worked, as long as the interface and the protocol was maintained, which made C++ instantly interesting for game developers. The promise of true "object oriented" analysis, design and development came on top of it. It allows you to tackle large problems on a level that resembles much more the way we humans think, than the way you would have to dissect it to make it understandable to the computer in Assemble language. This benefit came at a price however. Slack! C++ was not nearly as tight and fast as well written C-code or Assembly language. There are ways to maintain good C++ performance, but it requires you to go back and think on a machine level, which pretty much defeats the purpose of the language's object oriented approach. As a result many developers used C++ advantages and blended it with their traditional coding styles to make sure their applications run as fast as possible, while allowing them to work with a large number of programmers. Fortunately the hardware specs grew too, and all of a sudden it wasn't so important any more to squeeze every little byte and CPU cycle out of the machine. We could actually afford some slack! So, to make this long story short and to answer the original question, writing games in Assembly language these days would indeed result in faster games, and it would allow us to make better use of older processors. However, these games would probably never see the light of day, because it would take too long to write these games and it would be a nightmare to maintain and to debug the code. Development times would rocket to thew sky and so would development costs. As game developers we are answering to two entities. The gamers obviously, who buy our games, make them successes or failures, and want value for their money, and the people who finance these games in the first place. Developing a title like "Torment" runs into the millions, and it is my responsibility to make sure we make the best games with a limited amount of money. Balancing these two factors is a juggling act, and taking a good look at development techniques is crucial in today's market. While C++ might not be the perfect solution to create games, it is certainly one of the most viable, given all the variants and influences we're facing. The last game I was writing completely in Assembly language was "Spirit Of Adventure", an RPG back in 1990 - and that turned out to be a truly masochistic experience. Ever since I have used Assembly only to spice up time-critical parts of my programs.
Guido Henkel |
| Planescape: Torment & Design: © 1998 Interplay Productions. All Rights Reserved. © 1998 TSR, Inc. All Rights Reserved. Planescape, the Planescape logo, Advanced Dungeons & Dragons, Torment, the AD&D logo, and the TSR logo are trademarks of TSR, Inc. and are used by Interplay under license. TSR, Inc. is a subsidiary of Wizards of the Coast, Inc. Interplay, the Interplay logo, Black Isle Studios and the Black Isle Studios logo are trademarks of Interplay Productions. Exclusively licensed and distributed by Interplay Productions. All other trademarks and copyrights are property of their respective owners. |