A Game Dev’s Story, Part V: Language Skills

Posted by Rampant Coyote on February 22, 2012

As I attempted to imitate my favorite arcade games on the Commodore 64, I found myself running up against a pretty major limitation: Speed. Specifically, the lack thereof when running my homemade games.  I learned a lot of tricks (most of which I’ve forgotten, now) to making my BASIC programs faster. But while those optimizations helped, and I could write some pretty fun little games, there was only so much an interpreted language like BASIC could handle.

What is an interpreted language? I’m glad you asked. Yes, you programmers reading this can snooze for three paragraphs – most of the readers here aren’t programmers and don’t know this stuff. 🙂  Okay, traditionally programming languages come in two different types (though we now have some extra variations): Interpreted and Compiled. The difference between the two is a little like the difference between someone creating a translation of a book from a language you don’t understand into your native language, versus you trying to translate it word-for-word as you read it.

In a compiled language, you use something called (wait for it…) a compiler which takes your human-readable code and translates it in the computer’s native machine code, which tends to be significantly more challenging for a human to read (and modify). While the compiler may not create machine code that is quite as optimized as a human being could do by hand, it is in the computer’s “native language” and thus executes as fast as the system can go.

In an interpreted language – which BASIC usually was back in the day – your program is run via another program – and interpreter program – which reads and interprets your program as it executes. This pretty obviously slow things down – a lot!  So why use an interpreted language? Mainly because it’s easy and often pretty interactive. If speed is not an issue, or you are just “experimenting” with a language (one of my favorite languages, PYTHON, is great for this), an interpreted language is really the way to go. Interpreted languages are also very portable – which is why they are used for web-scripting. In theory, at least, you can run the same interpreted language code on any system with a compatible interpreter (Javascript is a popular one) and it will run the same no matter how different the hardware may be.

There are a couple more variants on languages that are worth mentioning. The first is Assembly language. Assembly language is sort of an intermediate stage between machine code and a higher-level language. Assembly is specific to the CPU you are writing code for, and is indeed very  similar to machine code, with each statement corresponding to a machine code instruction. The advantage of assembly language it that it allows you to abstract some of the details – like using variables and labels, mnemonic opcodes, and relative memory locations. This means it still has to be “compiled” like a compiled language, but the process is so straightforward the compiling program is called an assembler instead of a compiler.  Everything’s one-to-one, so there’s no disadvantage (that I can think of) to using assembly instead of machine code.

Another variant – a relatively new one – is “bytecode compiled” languages, like Java. These languages try to straddle the gap between compiled languages and interpreted languages. In bytecode compiled languages, the program is compiled down not to native machine code, but to an optimized intermediate set of instructions that can be executed by a another program very quickly. You don’t get the level of interactivity you may enjoy with a fully interpreted language, but it’s theoretically just as portable and a lot faster.  But this is just an aside – I didn’t have this back on my C-64.

It became clear that to get speed on my C-64, I needed something faster than BASIC. This meant one of three approaches.

First of all: I could get a compiler for BASIC, to convert my BASIC code into machine language. I tried this. The compiler, unfortunately, sucked. It was unreliable, only worked on a subset of BASIC, and the results were very hard to debug. Something would work perfectly in BASIC but not work in the compiled version (although it was much, much faster), and all I could do was to start taking guesses as to what was malfunctioning and rewriting code until the compiler managed to get it “right.” After only a few attempts, I completely gave up on this option.

Both of the other options involved getting an assembler and learning to write in assembly. I’d experimented a little bit with a straight machine-code editor (which used symbolic opcodes), but it was nightmarish to use. When I finally got a decent assembler, things were pretty wonderful. My second option was to switch to writing my games in assembly. While it was certainly possible (that’s what all the professionals were doing), it was a really slow, painful process to get anything done. There’s a reason higher-level languages exist: programming down at the level of “the iron” takes a lot more work. I never got too far doing this, either.

The third approach – and the one I ended up actually getting things done using – was a hybrid: I could write the speed-critical parts of the game in Assembly – really tight “subroutines” mainly for displaying the graphics and handling things like collision and movement – and the rest of the game in interpreted BASIC. I did this a few times, and in general this worked pretty well. My biggest success came when I was writing yet another pseudo-3D first-person perspective RPG. I have a history with these things, don’t I? I had things like trees, fountains, and so forth that I wanted to display in quarter-screen-sized window, but they had to be drawn in the correct position and at a size that reasonably approximated its perspective. And everything had to be overwritten by anything closer. This was pretty slow in BASIC, but in assembly I whipped up a pretty decent rendering subroutine! You could still catch a glimpse of the entire world rendering – which meant you could basely see what was behind a wall, for example – but it was dang fast. Now, if I’d known better, I would have rendered the whole scene first to an off-screen buffer and then copied the buffer onto the screen so the player couldn’t even catch the glimpse of my lightning-fast rendering routine, but the idea never occurred to me at the time.

I never became an expert at assembly language for the 6502 processor (the chip inside the Commodore 64), though when I was required to take a course in college where we developed software in Assembly language, I got to be pleasantly amazed by how much easier it was to use the more advanced Motorola 68000-series chips used in the Apple Macintosh in the classroom.

So what did I get out of all of this?

I learned that tools are very important. The basic compiler and the early machine-code “editor” / monitor were pieces of junk that were almost of negative value to me. I was tempted to give up when I used these, and just assumed that anything beyond BASIC programming was just too hard for me. But once I got a decent book (okay, it actually wasn’t all that decent) on 6502 programming, and a good assembler, I was able to go on and do some great things. Using the right tool for the job really helped, too. Jumping straight into pure assembly programming might have discouraged me, but I found that I could take a hybrid approach which gave me some early success stories. Those helped motivate me to keep going.

How this applies to you: Get the right tools. Take baby steps so that you can get some early successes in under your belt to build confidence and familiarity while you are building your skills.

Next time: My brief early experience as an indie game developer, and a break for college.

Filed Under: A Game Dev's Story, Game Development, Retro - Comments: 5 Comments to Read



top