Getting Started in Game Programming - Part One

  • warning: Creating default object from empty value in /home/buckman/public_html/neo/modules/advanced_forum/advanced_forum.module on line 492.
  • warning: Creating default object from empty value in /home/buckman/public_html/neo/modules/advanced_forum/advanced_forum.module on line 492.
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

rednight (not verified)
Amiga Basic options

The original BlitzBasic -- it's free now
AmiBlitz Opensource continuation of Blitz Basic
AMOS - also free now

There is also AmigaBasic that came with and requires WB 1.3 but it's buggy and doesn't run on newer versions of the OS,.

davyK
davyK's picture
Offline
Joined: 05/21/2006
There is a lot to be said for

There is a lot to be said for starting with BASIC since as Shawn says, lots of complexity is hidden from you which you can move onto with Java or C / C++ later. It's best going for a language that compiles to native code and is cross platform - and there are BASIC compilers that do that.

No matter what the language - compiled native code will run at least as fast as any game maker package and in all liklihood faster. The big upside of game makers is speed of development but there is a downside - possibly speed but there will be other limitations imposed by the game maker architecture as to what you can design. Not being able to look "under the bonnet" is a big limitation if something isn't working right either.

When writing your own code the only limitation is your imagination. The alarming lack of coding skills in the young is what prompted the likes of the Raspberry Pi - too many so-called smart computer kids are really only clever consumers - not really creating anything genuinely new. Nothing wrong with being someone like that of course - the whole ethos of SOA and APIs can make coders highly productive by stitching together libraries of code that don't need to be endlessly recreated - but we need people whio can code "in the raw" as well - maybe not as many as time goes on - but we need them - and starting this way will be an advantage later on when using packages or off-the-shelf APIs or code.

I've used BlitzBasic Plus which was nice for me as I started coding in BASIC on an Apple IIe back in 1980 or so - so learning the concepts and the syntax wasn't an issue. It does handle screen buffering which is a good concept to get and is very easily done in the language. So if anyone is looking at BB as an option it does the job very well and there's quite a big community too.

RuThaN.. (not verified)
Basic isnt good idea

I think, that future is only in C# or other modern lang (i hope that i will be not Java), without manual memory managment and with box of advanced tools.
If someone will start with bBsic, he will atfer that only confused by modern lang and tools.

Bill Loguidice
Bill Loguidice's picture
Offline
Joined: 12/31/1969
True, but...
RuThaN.. wrote:

I think, that future is only in C# or other modern lang (i hope that i will be not Java), without manual memory managment and with box of advanced tools.
If someone will start with bBsic, he will atfer that only confused by modern lang and tools.

All valid points, but it's not really something someone can learn and use casually. That requires a serious commitment, particularly if you want to get anything useful out of it. With that in mind, BASIC and its derivatives are fine alternatives when you just want to produce something and not be a pro programmer...

n/a
Matt Barton
Matt Barton's picture
Offline
Joined: 01/16/2006
I think I have to agree with

I think I have to agree with Ruthan on this one. You can learn enough C# to do whatever you'd be doing in BASIC anyway, and once you have it down, a whole world of stuff opens up. It's not like you have to do the advanced OOP stuff (bit of a rabbit hole IMO for beginners like us to get all mixed up with that stuff anyhow). If you're using something like UNITY, you need very little c# to get by. But even a little bit goes a long way.

n/a
Bill Loguidice
Bill Loguidice's picture
Offline
Joined: 12/31/1969
It's a tough call in my

It's a tough call in my opinion. You can be passable in a "hardcore" language or an expert at a "hobby" language. Each has its own positives and negatives, particularly if all you want to do is create.

n/a

Comment viewing options

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