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.
(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.)
The idea for this article was triggered by a several different things.
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:
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
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...)
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...
"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?
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.
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:
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.
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.)
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.
To be fair, I feel there is one exception to my statement, "VB pretty much sucks for development." If you were:
- Forced to develop a utility program for Windows...
- Under the gun to throw together a decent GUI for that utility program...
- 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.
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.
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).
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.
The main reasons I don't recommend the full-on retro-computer programming option?
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.