Game Development: Playing to Strength

Posted by Rampant Coyote on March 7, 2013

When I first started programming the Commodore 64, I was coming to grasp with a more complete version of the BASIC language. And, slowly, coming to grips with the limitations of the C-64. While in comparison to my previous computer (a Sinclair ZX80) it was overwhelmingly powerful, writing action games in BASIC would bring you very quickly to some of those limitations.

For those who don’t know, BASIC (at least as traditionally implemented) is an interpreted language. This means that there’s a language interpreter parsing your code while it runs. This means that every step of the way, there’s a complex program trying to understand what your code wants it to do, and then executing. By comparison, most applications you run today are compiled languages, which means that you run a compiler on your code in advance which does all the interpretation into the machines’ own native language. So at run-time there’s not as much overhead.

So anyway – BASIC was slow. And I wasn’t quite to the point of teaching myself machine code (or Assembly, the much easier-to-use Next Best Thing). So I found myself writing games that took advantage of the strengths of the language (and the computer) rather than the weaknesses.

Probably the best example of this was printing and scrolling. On the C-64, moving a bunch of character-sized things around on the screen could get very slow. Putting a three-character block that looked something like this [=] on the screen involved six interpreted lines of code telling the machine what memory location to use and what value to put there (three for the shapes, three for the colors). If you were to move it, you’d have to include at least three more lines of interpreted code to erase the three pieces at their previous location.

Obviously, you didn’t want to move too many objects around on the screen like that. Even in machine code, there were limits. Now, for larger objects, there were some built-in hardware-controlled sprites – a total of eight that could be on-screen at a time – which could be combined with more static backgrounds to make a pretty decent game.

But when I hadn’t quite mastered sprites, there was another trick of the hardware and BASIC interpreter I took advantage of . I wrote a particular game multiple times (a little better each time) taking advantage of the strengths of the interpreter. For one thing, while moving an entire screen’s worth of character objects was a massive hit, there was (IIRC) some hardware performance shortcuts that made scrolling pretty fast.  And while having the BASIC interpreter draw objects one at a time was really slow, the “PRINT” statement – designed to render lines of text – was pretty dang fast, with rapid machine-code handling of a chunk of data. Likewise, string manipulation – while not fast – was still faster doing it with built-in BASIC commands than trying to do it “by hand.”

So I wrote a car game. In the game, you controlled a car at the top of the screen. The road was actually created by a series of print statements which would print the road using a subset of a string (a line of text) like this:

"                     [=]   [=]"

I’d use a keyword to eliminate some of the spaces at the front of the string, and just print it out. So I’d get a track like this:

           [=]     [=]
          [=]     [=]
         [=]     [=]
        [=]     [=]
       [=]     [=]
        [=]     [=]
         [=]     [=]
          [=]     [=]
          [=]     [=]
         [=]     [=]
        [=]     [=]
       [=]     [=]
        [=]     [=]

To make the entire screen scroll, I’d just print a new line at the bottom.

It made for pretty jerky movement, but it worked. Then the car could be moved by using the left or right arrows (or the joystick). As difficulties increased, I could use a different string that narrowed the road, or throw in the occasional variant string that had an obstacle in the middle of the road.

For collision detection, I just kept a couple of arrays of values that I’d rotate through to keep track of which road piece had been used, which would tell me what the left and right boundaries were (or if there was an obstacle). Since it was all blocky with integer-based movement, it was fast and easy.

It wasn’t a great game. And an arcade gamer would  be really put off because it played “upside down”. But it worked pretty well, and was easy to write.  Easy enough to write in a single afternoon, and to write multiple times (with various enhancements).

Why do I share this?

I think there are a few game development lessons to be derived from this example from now-ancient technology:

#1 – Start simple.

Especially when you are first learning a platform or just learning to write games, it’s a lot easier to learn with simple examples than being bogged down with industrial-strength crap. For one thing, it’s easier to figure out if the problem is in your (limited) code, or if it’s an issue with the platform. And you can get the basic stuff done quickly to move on to the more advanced topics. Like – in this example – with the basic “prototype” game so easy to code, I was able to focus on learning how to do sound effects or joystick control.

#2 – Play to the engine’s strengths, and take advantage of what you are given.

Here’s the thing: There’s no such thing as a “perfect” game engine or API. All of them come with limitations and trade-offs. While it’s easy to go off and scream, “design is law” and feel all heroic bending the engine to your will, it’s often far, far better to take advantage of the power of the engine and simply avoid playing to its weaknesses. With a few exceptions, those battles you choose to fight because they will definitely raise the awesome factor by a good three notches.  Use the advantages of the game engine to your own advantage, even if it means modifying your game design to match.

#3 – There are many ways to skin a cat.

Pardon the expression, cat-lovers. But there are usually several different ways of accomplishing your goal in making a game, particularly if you can be flexible on details.  If a particular approach or implementation seems pretty cumbersome given your tools, try to think outside the box and see if there’s any other way to accomplish something close enough. You may even find your “Plan B” approach is far better than your original!

And my favorite:

#4 – You don’t need to be an expert to start making games!

This was one of my very first (if not THE first) action-games I ever wrote. I didn’t know much about programming. But it was something really fun and motivating I could work on as I was learning, and I know of some indies out there who have done okay with commercial releases of their products that they learned-while-making. The bottom line is that you don’t need to complete any kind of degree or even a six-week course to get started.

 

I think these principles are just as applicable today on modern game systems as they were in 1983 on the C-64.

Filed Under: Game Development - Comments: 12 Comments to Read



top