Getting Started in Game Programming - Part One

Shawn Delahunty's picture
Hello again everyone! This time I want to talk about something very near and dear to my own heart (and wallet): Programming. Specifically, Game Programming. I wanted to address the questions which young gamers always seem to ask, when they first seriously consider the idea of becoming a game programmer... "How do I get started? What language/tool/IDE/program should I download?"

As I've managed to make a pretty good living as an applications and systems-level programmer for nearly 20 years now, and since I've been programming either professionally or as a hobby for over 35 years, I think I'm grey-haired enough to have developed a reasonable opinion on the matter.

John Carmack, making bits behaveJohn Carmack, making bits behave

(In case anyone is wondering, no I'm not so grey-haired that I've gone senile and forgotten my third article on the concepts of "Randomness" and "Zero-Sum" as they pertain to video gaming. I'll get around to it, but hey... all things in good time.)


Stage Zero: Before the Beginning...

The idea for this article was triggered by a several different things.

  1. First up was my experiment back in February; to write a game for my old TRS-80 Model III computer which I'd dug out of my attic.

    Here are links to the articles, where I provide all the gory details:
    Retro-Zap! Article 1 of 3
    Retro-Zap! Article 2 of 3
    Retro-Zap! Article 3 of 3

    If you want to play around with the game itself, or mess with the BASIC code, I've hosted it right here on Armchair Arcade:

    Play Retro-Zap! online inside your browser.

  2. The second nudge came from the Ludum Dare 48-hour and 72-hour game development jams.

    For anyone not familiar with Ludum Dare, here are some links for your edification:
    The main Ludum Dare website
    Wikipedia entry for Ludum Dare
    Time-lapse programming session for Ludum Dare... #1
    Time-lapse programming session for Ludum Dare... #2
    Time-lapse programming session for Ludum Dare... #3

  3. The third nudge came from discovering the recording of a live-stream made by Markus Persson (Notch) last year.
    A 14 _hour_ session of Notch coding a nearly complete demo game.

    He wrote a little ray-casting demo game, inspired by one of the 48-hour Ludum Dare game jam events. In the video, you can see him interactively trying things; adding a bit of code, testing the result, changing a value, testing the result, adding a feature, checking for crashes and errors. Now Notch used (and still uses) Java for development, and the Eclipse IDE in this example. He is also using many features of the language which could frankly bum-fuzzle a newbie programmer.

    But the point of interest here is neither the programming language nor the specific IDE; it's in HOW he's using the tool. It is very much how we used to code ages ago, wherein you would "just code" and then "just test". He's not using the interactive debugger. He is not setting "breakpoints" inside the IDE. He is not "stepping through the code" with the IDE. He is not setting "watch variables" or "watch memory block" views.

    What does Notch do? He makes a small change to his code, and then immediately runs the game to study the result. This method is a tremendous thing. It is geared around the idea of near-instant feedback, which is an incredibly efficient technique for learning. This was inspiring to watch (though I didn't sit through all 14 hours of the thing) and made me very nostalgic for the days when I worked on this sort of project where immediate feedback was possible.

    (Nearly all of my programming efforts nowadays are incredibly complex and lengthy affairs, with little opportunity for this kind of tight, fast, iterative testing and immediate feedback. There are literally days and weeks of working out architectural concepts, defining interfaces, followed by just pounding out pages of code to implement the most basic of functionality. Then the lengthy and often tedious debugging process begins...)


Stage One: Where's the Starting Line?

The perennial first question is: What language should the potential newbie game-developer start with?

Ask on any gaming or game-development forum, and you'll get a startling array of different answers. Most of the time, I think the suggestions come purely from the biases of the respondents. If they started in Ruby, they'll recommend Ruby. If they started with Python, guess what? Yep, they'll likely chime in, "Use Python!" If they started with Java, then you get a coffee-flavored answer.

In that sense, at first glance I'm no different. I started with BASIC, and that's what I'm recommending here. But I'm not recommending BASIC because I started with it---I'm recommending BASIC as a starting point because that's what the language was designed for.

I can already hear the thousands of eyes rolling back in thousands of heads as I write this, but hold on a minute. BASIC gets a bad rap, and I think it's completely unjustified. (I'm absolutely NOT talking about Visual Basic here, in any of it's stripes. It deserves the bad rap. Beginners should be kept away from VB with electric cattle prods if necessary. More experienced folks tread on that ground at their own peril...)

I'll go even further with my outrageous statements about BASIC: Based on my experience, I firmly believe that folks who start with BASIC, tend to make much better low-level system programmers than those who started with Java et al. (I'll be exploring this controversial observation a great deal further in my hopefully soon-to-be-published book.)

The primary counter-argument starts with: Why not start with C++ or Java or something more modern?

You could start with those languages, and the common IDE's which support them have certainly gotten much better, particularly from the newbie's point of view. It's now pretty easy to just "Install & GO!" Yet there are slew of subtle and complex obstacles to comprehension and learning which those languages present to the beginner, and they also tend to encourage bad habits. I'm referring to things like the "Crutch/Toolkit Mindset"; wherein you spend far time figuring out what toolkits you'll need to "build against" and how to configure those external globs, than you do actually learning to program correctly.

What complications do those languages drop upon the hapless and unaware newbie? Ok, here we go...

*deep breath*

"Classes, inheritance, public vs. private members, volatility, concurrency, 'friend classes', polymorhpic calls, operator overloading, aliasing, linkers, libraries, pre-processors, forcing runtime garbage collection, events, objects, namespaces, exception handling, event triggering, instantiation, singletons, design patterns, templates (blech), threading, pragmas, imports..."

If you've done any programming at all, you understand what I'm getting at. If you've never programmed before, your eyes probably just glazed over as you read that list. Which is the whole thing I'm trying to avoid! Novice programmers have enough to figure out. Adding all that crap just yields unnecessary discouragement when facing an already difficult task.

(For the pedants out there; "No, you don't have to use all those features of more modern languages." There, I said it. However, if you're not using the language features, then you're missing out on some of the strengths that the language offers. So why bother using that language? It's like dragging an air-compressor, 80-feet of hose, and a jackhammer into some budding coder's bedroom, and then telling the kid to, "just hoist that all up in the air, and drive in a thumbtack to hold up that poster.")

The other problem is "intermingling of concepts". Many, many examples in those languages introduce those complex concepts far too early in a programmer's development. If a young coder goes and downloads a bunch of examples off the web, they're very likely to encounter programs which have those concepts jammed in every which way. The worst case is when the concepts show up in sneaky disguises---as "assumed knowledge". All this will only serve to confuse or distract the newbie coder from what they actually need to be focused on.

This is why I believe BASIC is a far superior introductory tool. If these advanced capabilities are not even a part of the language, then there's no possible way for our young padawan neophyte to get in hopelessly over their head.

With more modern langauges, there is also "The Feedback Issue" which has to be considered: How much code do you have to write before getting to, "just see what your program is actually doing?" The idea of using BASIC triumphs here, since preliminary exposure and teaching is what the language was developed for originally. BASIC provides a good introduction to all the principles of Logic which are fundamental to the study of Computer Science and programming languages. And BASIC does so without confounding and confusing the new programmer with a lot of extra "higher level" concepts that don't need to be thrown at them yet. (This is one reason that I think curriculum designers are buzzword-chasing dolts. I think the new de-facto standard of using Java for teaching introduction to programming is moronic.)

What does a beginning programmer really want to do?

  1. Figure out how to draw a colored dot on the friggin' screen.
  2. Make the dot move and shoot by pressing keys.
  3. Put up a little green "alien dot" which wanders around.
  4. Make it so that every so often the little alien greeny will shoot at you.
  5. Put up a message that says, "Yaaargh! I'm a pirate! Kiss my Booty!" when you successfully shoot the alien.
  6. Make the machine "Beep!" and "Boing!", and maybe play the sound of them burping or their dog barking when you lose.

Everything else necessary to become a good programmer can be built up and expanded upon from those basics. The key point though is that you've given the fledgling coder some immediate feedback and encouragement. They're likely to stay interested long enough so that you've got a shot at teaching them the rest. Looked at this way, the process seems simple, right?

But let me tell you, there's a large pile of cow pookey which has to be taught, and then executed correctly, before you can achieve the "simple goals" on that list when using C++ or Java or whatnot. (Yes, I'm aware of Python and PyGame and so forth. They still have too much extra crap which can overload the total newb.)

To achieve those steps in BASIC, is not very much code at all. Maybe 25 lines worth. I'll even prove it. Oh wait, I already did. And I didn't have to configure an external library. Nor set up custom compiler and linker flags. Nor dig in any API documentation.


Stage Two: Decisions, decisions...

I recommend that a complete beginner learn programming by starting wtih BASIC. The obvious next question becomes, "What are the current BASIC language programming options available to a newbie?"

Here is a brief list of possible options for getting started in BASIC programming:

  1. Dig up a copy of BASICA.EXE and run it inside of DOSBOX or DOSEmu.
    What is BASICA.EXE? This is the nappy, crusty, really really ancient "line numbered" BASIC interpreter from Microsoft. This thing shipped starting with eeaarrrly DOS versions. I wouldn't bother with the thing, simply because there are WAY better options available. But if you want to try it, don't let me dissuade you. (I actually still have a copy of this laying about on my hard-drive for giggles.)
  2. Dig up a copy of GWBASIC.
    While I don't support software piracy, I don't think Microsoft is really going to care much about this one if you go hunt down a copy on the seedier side of "The Inter-tubes".

    This was a later offering from Microsoft, offers a few updated features, and introduced a crude Integrated Development Environment of sorts, which made use of the Function keys. Once more, I wouldn't bother fiddling with GW-Basic, simply because there are much better options.
    Wikipedia entry for GW-Basic.

  3. Dig up an old copy of Microsoft QuickBasic or QBasic.
    This one was the successor to Microsoft's GW-BASIC. It was quite powerful, and got a LOT of use "back in the day". There were all kinds of in-house applications and utilities that were written with this development tool. It also was the first real "Integrated Development Environment" which I ever saw.
    Wikipedia entry for QBasic
    Wikipedia entry for Quick-Basic

    QuickBasic was the preferred one, because that version of MS BASIC allowed the creation of "standalone" executables. Which was great, since you could build and test the thing interactively with the DOS-based IDE, debugging to your heart's content. But when it was "done", you could actually "compile" the thing into an EXE that would run on other systems.

    I still have a few versions of this tool sitting around in a dusty digital corner of my Linux systems. It may sound a little nuts, but I've manually dragged forward the folders with those versions from one machine to the next, and cajoled them into working on each successively more modern OS. While I haven't used these tools for any kind of development in years, I simply have kept them around in case I encounter any old BASIC programs/utilities which I want to try. I also keep them in case I'm ever asked to port a piece of BASIC code to a more modern system and language. (Don't laugh--this has actually happened to me once! I ported some ancient HP-BASIC code to C, and stuck a nice GUI on the front.)

  4. If you have a little bit of experience with the "older" Visual Basic development IDE (not the .NET stuff), there is an open-source project named "GAMBAS" which you might want to look at.

    The GAMBAS project home page.

    I have actually GAMBAS installed on my Linux system to mess with, though I've never seriously considered using it for anything. The project was "inspired" by the original Visual Basic according to the creator of the thing, though VB source code is in NO way compatible with GAMBAS. And while it might be possible to "port" old VB programs to this newer project, you also face the added strangeness that the thing doesn't even work under Windows! (It runs fine under various flavors of Linux and BSD.)

    These dichotomies make GAMBAS an extremely strange beast, in every possible way. I personally don't recommend it, especially not for rank beginners.

  5. Dig up an old used copy of an "actual" Visual Basic version, on eBay or.. uh... elsewhere.
    This too is a bad choice, not just for the obvious "Pirating is BAAAAD, mkaaayy!" reasons, but also because VisualBasic suuuucks. Really, it does. Especially for anything which needs to be as dynamically interactive and responsive as a videogame. Why would you want to pay for a used copy of this scroddy setup? It was never a great development tool in the first place.

    CAVEAT:
    To be fair, I feel there is one exception to my statement, "VB pretty much sucks for development." If you were:

    1. Forced to develop a utility program for Windows...
    2. Under the gun to throw together a decent GUI for that utility program...
    3. Had to do all this in a single afternoon...

    Then VB worked great for that purpose. Just click and drag the forms and widgets you needed, wherever you wanted them. You could knock together a decent looking little app in no time flat.

    Just don't bother trying to get the VB to do anything particularly complicated.

    My big secret was, I simply never let the VisualBasic "code" do anything! I always just had the VB code "call into" a standalone command-line program which I wrote in C. The only thing the VB did was provide a way to capture the "clicky bits" and funnel them into the C-code. My command-line C-utility did all the heavy lifting. It would pass messages back out, and the VB "code" would display them in the pretty pretty windows.

  6. Get a copy of DarkBasic, BlitzBasic, Blitz3D or similar.
    Again, don't pull them off your favorite 'Warez' site or torrent either. I cannot and will not condone software piracy--please just don't. There are legitimate copies of these products readily available for very reasonable prices, and they are exceedingly capable development tools. Even a used copy of an older version works fine for getting started, so check on eBay.
  7. Free BASIC.
    This is one of the spiritual descendants of Microsoft's QuickBasic. It is a 'compiled BASIC', meaning you write your code with the text editor or IDE of your choice. Then, you start the BASIC compiler; it chugs and puffs and clanks and grinds, turning your BASIC source-code into a standalone executable. It has also grown quite adept compared to it's ancestor, offering a whole slew of improvements, add-ons, and support for new 'dialects' of BASIC. It is also free software, released under GNU licensing, and is available for DOS, Windows, Linux, BSD, and Intel Macs.

    It is an extremely capable project, and with all of the newer features, able to create some very slick and professional programs. There are screenshots in the 'Gallery' area of the project homepage.

    Here is the FreeBASIC project homepage.
    Here is the project download page on SourceForge.

  8. QB64
    This project is also a descendant of Microsoft's QuickBasic, but it's lineage is much more evident. Like QuickBasic, QB64 offers the capability to create 'compiled BASIC' executables, but also offers an interactive run/debug mode. The similarities do not stop there. QB64 recreates the look and feel of the old DOS-based IDE of QuickBasic. (In point of fact, you'd be hard pressed to tell QB64 apart from QuickBasic 4.5 at a glance.) QB64 does offer the convenience of supporting REALLY LARGE CONSOLE WINDOWS, instead of the scrunchy 60x30 view of the 'good old days'...

    QB64 has been much improved over time, with lots of new functionality added to the BASIC langugage dialect of it's forebear. It is still very actively developed, with tons of new features and extensions being put in on a regular basis. Versions are available for Macintosh, Windows, Linux (and probably BSD).

    QB64 homepage. You can download the language/IDE and read much more about it here.

  9. Buy an old 8-bit home computer system on eBay and program directly on that.
    While this option imbues you with an undeniable aura of "Reto Cool", clearly it isn't a realistic option for most people--for any number of valid reasons.

    As cool as it might be though, I don't recommend it for someone wanting to "get started in game programming." Trust me on this, I'm an authority on the topic. Earlier this year I posted a series of articles here on Armchair Arcade, about the coding of Retro-Zap!, a BASIC knockoff of Space Invaders which I wrote for my 30+ year-old TRS-80 Model III computer as a gag.

    Jump to my prior article links...

    The main reasons I don't recommend the full-on retro-computer programming option?

    1. It can be expensive to buy one of these systems.
    2. The thing might die on you from sheer old age. Repairing them can be costly.
    3. It's an ergonomic nightmare to work on these old systems for long periods. Your wrists, neck, spine, and eyes will hate you forever if you try.
    4. Why do you want to learn the details of programming for an OLD system? You want to learn how to make games that you can send to your friends and such, right? You want to make stuff they can play on their modern PC.

Aaaaaand, that's all for this time everyone. Rather than overwhelm folks with one of my monolithic "Wall O' Text" articles, I thought I'd be nice and leave you to mull over the various options I've presented here for getting started in game programming. Check back in a day or so for Part Two and the exciting conclusion! (Or was that 'concussion'? 'Commission'? No... no... we don't get paid for this...)

Please, chime in below with your thoughts. I'd especially love to hear about the different experiences people have had with any of the tools mentioned, or your experiences with other BASIC programming environments from bygone years which I didn't cover here. (Any AmigaBASIC nerds out there?)

As always thanks for reading, and may your Wand of Magic Lightning never go off while you're on the can! See everyone next time.

Comments

Felix Ple?oianu (not verified)
10. Install an emulator for

10. Install an emulator for an old 8-bit computer system and play with it. :P

Seriously, option 9 is how I started programming, back in the day, so I second your advice. And since you mentioned PyGame, that should probably be the second step, once the basics have been mastered. That, or Javascript in a browser, since going from Python to JS may seem like a step backwards to a less experienced programmer.

But those are already pretty high level. Good old Basic with GOTO and line numbers is very close to how the computer really works on the inside, and that perhaps more than simplicity is a good reason to start with it.

Shawn Delahunty
Shawn Delahunty's picture
Offline
Joined: 08/01/2011
Hey! You guys are getting ahead of me!

Maybe I should have waited and posted the huge "Wall O' Text" article after all... hmmm.

Heh, I'm tickled pink that there are folks who enjoyed the article enough to start contributing ideas like this! (Heck I'm happy that anyone even reads my articles.)

And your last paragraph is SPOT ON. It's that fundamental, almost instinctive understanding of "thinking in BASIC" which makes ex-BASIC folks so much better at low-level firmware and systems programming....

Cheers!
-Shawn

n/a
Matt Barton
Matt Barton's picture
Offline
Joined: 01/16/2006
Nice article, Shawn! Man,

Nice article, Shawn! Man, you're making me want to start working on my gravity orbit game again (I got burned out as predicted).

I always wanted to program whatever machine I had at the time, though I never went beyond BASIC until much later. Back in the 80s, you could do a LOT with BASIC, and it wouldn't necessarily look substantially different than the commercial programs. Hell, a lot of the best commercial games back then were done in BASIC!

I did some BASIC games on the C-64, usually space trading type games done in all text.

I was really disappointed, though, with Amiga BASIC. So friggin' slow! They really dropped the bomb on that. I had better luck with a product called "Visionary," which I used to make an adventure RPG. Relatively easy and did incorporate some elements of OOP.

GWBASIC was much better IMO. I remember programming all kinds of simple games and annoying little toys with that in the school's computer lab. Given more encouragement and access to teachers who knew what they were doing (mine had no clue), who knows what might have happened? Sadly, by the time I got to college, the only computer courses available were math or business focused. Bleh.

More recently I got into Gamemaker, which I think is a decent way for novices to get into game making. Really and truly, it's got all the power you need if you're just one guy doing this as a hobby.

UNITY's biggest asset (IMO) is the ability to make games that look comparable to commercial titles. As the community and third-party support for it grows, you get more and more access to assets that you can just purchase instead of trying to learn Blender or whatever.

Probably the biggest thing for me is being able to play the game in a web browser. That's because feedback is so critical. If you can't get anyone to play your game and give you feedback on it, it's just a big waste of time IMO.

The emulator idea is intriguing because you might appeal to hardcore enthusiasts of those old platforms who would be willing to try out your game just for the novelty of it. "Try out my new Amiga BASIC game." Hm. That would likely appeal to people who wouldn't give a rat's ass about your new FLASH or UNITY game.

n/a
Pressurizer (not verified)
A thanks and a question

Thanks for this article, it actually made me want to try my hand at Basic.
The next logical question would obviously be - where and how to learn the "basics of BASIC". I hope you'll soon give us some pointers on that.

Matt Barton
Matt Barton's picture
Offline
Joined: 01/16/2006
I'd suggest just diving in.

I'd suggest just diving in. If you try to learn the whole language before actually doing any programming, you'll never get there (trust me). Start with a simple goal, like just getting your name to print ten times. Then figure out how to put a small graphic on the screen, etc. Baby steps. Learn what you need to do each step as you go.

n/a
Shawn Delahunty
Shawn Delahunty's picture
Offline
Joined: 08/01/2011
Patience

Hold tight---I'll be posting Part#2 in a couple more days. It's nearly done--I've got a few other things I'm probably going to include, but need to think about a bit more. There WILL be some links to good tutorials and examples.

Thank you very much for reading!
-S

n/a
Pressurizer (not verified)
Very sound advice, Matt! My

Very sound advice, Matt!
My reason for asking was that literature on BASIC has become quite rare (except for VisualBASIC) in recent years. Another problem might be that there are so many different BASICs around, just take the ones Shawn mentioned. As a programming n00b, I was asking myself how different in syntax these BASIC flavors are, and whether a tutorial for one might work in another.

Bill Loguidice
Bill Loguidice's picture
Offline
Joined: 12/31/1969
Pure BASIC has been mentioned...

Just to play devil's advocate for a moment to the comments regarding using BASIC today... I think BASIC served a very real purpose prior to the post 1995 era. It was basically the one user friendly, universal programming language that we could count on since the 1970s, albeit with tweaks to syntax and how things worked a bit depending upon platform. Today, I don't really see its relevance. One is probably better off targeting something like a GameMaker, which allows you to both drag and drop and code in its specific language, or any of the similar offerings, like Unity, Monkey, GLBASIC, etc., depending upon starting skill level and intentions. They all do similar things to BASIC and let you target multiple platforms, while having the type of performance that BASIC never could.

With that said, on classic platforms, I still think it's a fun choice to work with.

n/a
Shawn Delahunty
Shawn Delahunty's picture
Offline
Joined: 08/01/2011
Not correct on speed.

Small correction Bill,

The reason I recommend QB64 is the fact that it is compiled to "native code", not byte-code or another intermediary. It's absolutely not an "interpreted on the fly" kind of thing, which is what plagued so many of the older versions of BASIC. So the executables really ARE executables. Hence the speed is actually very, very fast.

As for the rest, I have other reasons for recommending it for much more than classic platforms. Some I have elaborated on in the article, some I have not.

n/a
Bill Loguidice
Bill Loguidice's picture
Offline
Joined: 12/31/1969
Noted, but...
Shawn Delahunty wrote:

Small correction Bill,

The reason I recommend QB64 is the fact that it is compiled to "native code", not byte-code or another intermediary. It's absolutely not an "interpreted on the fly" kind of thing, which is what plagued so many of the older versions of BASIC. So the executables really ARE executables. Hence the speed is actually very, very fast.

As for the rest, I have other reasons for recommending it for much more than classic platforms. Some I have elaborated on in the article, some I have not.

Absolutely. I was more referring to BASIC in general. I think the argument against a BASIC like that (QBASIC by the way is the last BASIC I've programmed in, for a contest back in the 2004 timeframe) is more portability than anything else. I was trying to say that the other options, GameMaker, GLBASIC, etc., all compile these days to multiple platforms and offer similar benefits that pure BASIC's do in terms of ease of use.

n/a

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Images can be added to this post.
  • You may quote other posts using [quote] tags.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.