He is NOT using QBasic, it's QB64. He gets instant access to some pretty sweet functionality that was never in QBasic. Transparent PNG support, resolutions with more than 16 colors above 320x200, double buffering, TCP/IP, and the list goes on.
Regardless, this guy is getting some awesome press with the QBasic thing. If you want to make money with games, it's all about the marketing.
I'll give him a little more credit if he used that tiny dos-box blue editor that comes with QB64 to code the entire game tho :)
> used that tiny dos-box blue editor that comes with QB64 to code the entire game tho :)
And had a screen at an EGA text resolution of 80 x 25 chars with each character being in a box of 9x14 pixels. (With pixels means 'dots on the screen'.)
And saved the result on 5 1⁄4-inch or 3 1⁄2-inch discs.
And fiddled about with FOSSIL drivers and kermit or Xmodem or Ymodem and ProcommPlus to upload the game to a BBS. At 9600 baud.
QB64 also has multidimensional arrays, functions, while loops, "user defined types" (structs) ... apart from the lack of pointers, it's not all that far from C or Pascal once you ignore the syntactic sugar. (Or as pg calls it, "Algol with a funny hat".)
Not to downplay his achievement - I'm sure making the game was a lot of work either way ... but implementing it in Basic doesn't seem especially praiseworthy.
Hey, guys! I'm the guy making this game! :D
Yeah, I compile it in QB64 and use the SDL hooks in it to actually make it run on windows/mac/linux. But yeah, QBASIC has all those things you mentioned already.
I'm a little offended that you call this building a game in QBASIC when it clearly would not actually run in QBASIC. I built games in QBASIC growing up, and definitely didn't have access to the stuff you have in QB64. I was excited to hear about someone building such an impressive game using that toolchain, so it's a letdown to find out that it was a lie.
It's cool that you put constraints on yourself by using the BASIC syntax, but it's really dishonest to pretend this is being built in classic QBASIC and leverage it for press without making any distinction between the tools you're using and the tools people actually had available to them in QBASIC.
Quote from the PC World article, that is supposedly from you:
"It would show that even old, abandoned tools and the most basic pieces of software can still be put in the hands of someone who wants to create their dream and result in beautiful things happening."
This to me suggests that your goal is to show that actual QBASIC, the abandoned programming tool from the DOS era, can be used to build cool games. A noble goal. Using QB64 and SDL and a bunch of modern tools, however, does very little to achieve that goal.
Maybe this is just nit-picking, but QBASIC is a very specific name - the name of a particular BASIC interpreter that came with versions of DOS. You could have easily been more general and said you were building the game in BASIC, and been completely accurate, but then I suppose that wouldn't have gotten you an article on PC World.
And to give some context, I have in the past encountered people who were ACTUALLY building cool modern games in QBASIC. They did this by writing commands out to disk from their QBASIC game and then running windows apps to do the work of talking to libraries in order to do MIDI playback or read from game controllers. This, at least, counted as using QBASIC, and was quite a feat of engineering - even if those games weren't pure QBASIC.
I think you're being a little harsh on him--regardless of what language this game was written in it looks great. This is obviously a labor of love and not something made to get press attention. If someone wanted to get a story written about them in PC World I would venture there are much easier ways to do it than spend a year slaving away at writing a modern game in basic.
I think he's being quite fair as he's acknowledged the hard work behind this game (any modern game written in any language is impressive work), he's just saying that this project is getting a lot of media attention because it's advertised as using certain tools which it actually isn't.
If I'm honest, I feel the same way as the aforementioned poster. Writing any modern game in QBasic is akin to A-Team style engineering (building a rocket launcher out of an old shoe and some duct-tape). QB64, however, is basically just like any other modern scripting language. The former would require massive hacking and "outside the box" thinking to build even the basics of the game engine; where as the latter is just Python written in the syntax of BASIC.
That all said, I can't blame him for misleading people a little (whether that's intentional or just dumb journalists not understanding the distinction between QBasic and QB64) as making a project visible can be as hard as the actual development process. So at least he's hard work will see some reward. Plus he's offered to release the source because of public interest - which is quite honorable.
The confusion here stems from the fact that the term QBasic is ambiguous. On the one hand, it refers to the IDE and interpreter included with later releases of MS-DOS. On the other, it refers to the language accepted by that interpreter. Since QB64 is specifically designed to accept that same language (FreeBasic has a mode for this as well), I don't think it's unreasonable to consider QB64 a QBasic compiler. Would you find it similarly unjust if someone claimed to write a game in Python but they really wrote it in PyPy?
> QB64, however, is basically just like any other modern scripting language.
QB64 is not a scripting language. It compiles the QBasic language (with a few extensions) to C++ and passes it on to gcc. It seems like you're making a lot of assumptions about QB64 when you could instead be looking for facts.
> The confusion here stems from the fact that the term QBasic is ambiguous. On the one hand, it refers to the IDE and interpreter included with later releases of MS-DOS. On the other, it refers to the language accepted by that interpreter. Since QB64 is specifically designed to accept that same language (FreeBasic has a mode for this as well), I don't think it's unreasonable to consider QB64 a QBasic compiler. Would you find it similarly unjust if someone claimed to write a game in Python but they really wrote it in PyPy?
But the BASIC dialect that QB64 compiles is more than just QBasic in much the same way that QBasic was an advance on QuickBasic/BASIC.
I'm not familiar with PyPy (from a developers perspective) so I can't comment on that comparison.
> QB64 is not a scripting language.
I didn't say it was. What I said was that it's LIKE a scripting language. And the context of that (which you've kindly cropped out thus distorting the point I was making) was in terms of the way how the language is extended via additional libraries (eg Perl libraries can be Perl modules or bootstrapped from C++ - and QB64 libraries have that same 'feel' to them) and the nature of the language (it compiles to byte code rather than machine code†, the relatively limited scope of the language without the C++ libraries and it's performance, etc).
† It's also mentioning here that most scripting languages compile these days too, it's just that few offer a standalone ELF / PE with the runtime included (there's a limited need for the latter unless it's a niche language).
Just to be clear, saying something is LIKE something else is a comparison, it's not the same as saying something IS something else. And the very nature of comparisons is that there will be elements of the comparison which are not equivalent (which is why comparisons rarely work in arguments as the opponents will focus in the differences rather than the similarities)
> It compiles the QBasic language (with a few extensions) to C++ and passes it on to gcc. It seems like you're making a lot of assumptions about QB64 when you could instead be looking for facts.
I've played around in QB64, compiled and decompiled binaries in it and browsed it's source. Where else would you suggest I "be looking for facts"?
> But the BASIC dialect that QB64 compiles is more than just QBasic in much the same way that QBasic was an advance on QuickBasic/BASIC.
The QBasic language is almost exactly the same as QuickBASIC 4.5. Every version of any Basic that Microsoft release had advances over previous ones. Furthermore, modern additions to the standard library hardly constitute a language change.
> I didn't say it was. What I said was that it's LIKE a scripting language.
You're right; I read into that too much. Though I still contend QB64 is no more like a scripting language than QB45 was. I didn't mean to imply that scripting languages cannot be compiled or that all interpreted languages are scripting languages. In my mind, something is a scripting language if it's primarily used for (read: makes easy) at least one of two purposes: automation or extension. Of course, nobody agrees on what constitutes a scripting language just like nobody agrees on what constitutes anything in programming.
> I've played around in QB64, compiled and decompiled binaries in it and browsed it's source. Where else would you suggest I "be looking for facts"?
Those are good places to look. Documentation is also a good place. I don't mean to be spewing condescending crap, but a lot of the comments in this thread seriously irked me. It's a problem with programming as a field that many (maybe even most) terms are ambiguous or nebulously defined.
>I'm a little offended that you call this building a game in QBASIC when it clearly would not actually run in QBASIC. I built games in QBASIC growing up, and definitely didn't have access to the stuff you have in QB64. I was excited to hear about someone building such an impressive game using that toolchain, so it's a letdown to find out that it was a lie.
A lie? QB64 IS a QuickBasic derivative. It's no more a lie than saying Scheme and using Guile, or Lisp and using Clojure.
It is possible to compile QuickBASIC code (i.e. a variant of BASIC that contrasts with (among others) GW-BASIC) via QuickBASIC 4.5 and PDS.
Often at the time, you could write some code using the free QBASIC which came with MS-DOS and then decide that you need to purchase one of those other programs to compile it prior to distributing it as a standalone executable.
I hadn't realised there was a non-free version of QBasic.
Also, I went to download QB64 and compile a very basic app then opened that inside a hex editor to see if the it was just a standalone exe interpreter with the .bas attached as a resource (a bit like how self extracting zip files work) and appears that QB64 does genuinely compile the code.
So I stand corrected on both the old and new instances of QBasic.
There is some strange stuff inside the QB64 generated exe though. References to automation.whatismyip.com (stranger still, that sub-domain isn't DNSed).
QB64 is definitely a Window app that's written to look like it's running in DOS though. There's even a character map compiled into the exe so that the fonts look native to DOS. It also looked quite fun, so I can see the appeal of using QB64 for personal projects.
I know why it's using it. My point was firstly that it's odd (though not unforgivable) that the compiler links to those procedures even though my source .bas wasn't calling any networking APIs; and secondly that the sub-domain doesn't even exist for the DNS lookup to work:
$ whois automation.whatismyip.com | head
Whois Server Version 2.0
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
No match for "AUTOMATION.WHATISMYIP.COM".
>>> Last update of whois database: Wed, 17 Apr 2013 10:58:41 UTC <<<
I even disassembled the binary so I could see the full HTTP header just in case the domain name was a red-herring.
> My point was firstly that it's odd (though not unforgivable) that the compiler links to those procedures even though my source .bas wasn't calling any networking APIs...
It's pretty common for compilers for niche languages to statically link the runtime library by default. Many think it eases distribution.
Yes I know this (and it's not just compilers for niche languages that does this either). But again, that wasn't my point. My point was this:
1. it's statically compiling in libraries for APIs that aren't even being used (again, I know this is pretty common as well - it was more said as a side issue since I was already on the topic of it's runtime). But most importantly:
2. because automation.whatismyip.com DOES NOT EXIST. The API is broken because it calls a non-existent sub-domain name. The sub-domain has no DNS record. It does not ping nor curl because it's completely imaginary....and so on. (sorry for the flippancy of the post, but this is now the 3rd time I'm having to reiterate myself so I just want to be clear that everyone understands my point)
automation.whatismyip.com used to exist; it's what whatismyip.com suggested you use when making a large number of easily parseable requests. I assume since the redesign (read: monetization attempt) it's disappeared.
Honestly, I've never heard of automation.whatismyip.com until today. But after Googling around a but, it looks like they've only taken that domain offline two or three months ago. So I guess the QB64 devs haven't been made aware yet (or haven't had time to update their WAN IP library yet).
No, QBasic is also a language variant. QBasic has functions, user-defined types, no line numbers, and a pretty big standard library that plain BASIC did not have.
Yeah I'm familiar with what QBasic is and many of the other BASIC dialects that preceded it (I'm old :P). I'd agree that it's a language variant / dialect. My issues is when people talk about QBasic as if it was it's own single entity. But then I guess where do you draw the line? eg by my same logic, C++ just a variant of C, yet it's clearly sane to describe them separately. So perhaps I was being overly picky.
As a side note, QBasic does support line numbers - albeit for legacy reasons and not recommended syntax. And some dialects of BASIC did support functions - though the syntax was awkward so I usually just used GOSUB / RETURN when I needed procedures with no return values.
The compiled point was wrong, I'd already conceded that. But that doesn't mean I have no idea what what you're doing. I just wrongly assumed that the QB64 devs would just embed the .bas inside the PE as a resource file rather than going to the trouble of writing a compiler. Honestly, I'm impressed they bothered given the niche appeal of the IDE and number of other BASIC compilers on the market (FreeBASIC, PureBASIC, PowerBASIC, VisualBasic, etc) - some of which so closely resemble QB64 that I had to disassemble the compiled binary just to make sure there wasn't some plagiarism involved.
> Honestly, I'm impressed they bothered given the niche appeal of the IDE
It reminds me a bit of the freepascal project. Beautiful compiler, tons of extensions (including generics: http://wiki.freepascal.org/Generics), graphical RAD IDE (Lazarus) ... yet relatively few people use it because C++ does all of that and more. Ultimately, I guess syntactic preference isn't really enough of a justification for yet another compiled imperative OOP language...
I know exactly what you mean. I used to love Pascal back in the 90s so installed Lazarus a few months ago with the intention of writing a few Qt apps. I think I spent 10 minutes in there at the time, thought "this is fun", and have never touched it again since.
QBASIC allows for functions (as well as subroutines), looping (while, for, do-while), structs (type) as well as multidimensional arrays. That said, all I really remember from my QBASIC days is abusing the crap out of GOTO.
Apparently QB64 can directly access C header files as well as Windows DLLs [1], although I don't think the author used any external modules. The source is described as being a solid monolithic block of 12k lines worth of BASIC, which in and of itself is fairly throwback-worthy.
Yeah QBASIC has multidimensional arrays, functions, while loops, structs. But I agree with your point, QBASIC is pretty much like C or Pascal without pointers.
I also wrote little games in QBasic long ago. The biggest limitation was the memory limit. That would prevent making a game like this. So if this is QB64 (which I never heard of before) then I guess that explains it.
Just realised, same indentation and no-end-character rules as python :)
Although I've been writing qbasic back in the days and now writing python for fun, I've never realized this before...
Nearly every programming language follows those same indentation rules. And it's pretty common for languages not to have line termination characters too. What you're describing is pretty normal rather than a delightful coincidence.
The IDE forced those formatting conventions on you, but QBasic doesn't actually have any indentation rules at all, and IIRC that stuff was also configurable.
I learned how to program by reading through the code for qbasic gorillas (the game in the video in the article) back when I was a wee lad. Therefore, gorillas is the best game ever to me.
That said, qbasic was maybe not a best first language - I became a much better programmer when I learned C++ years later. Still, I really really appreciate that as a young child I had access to a fun game with the source code revealed. It changed my life.
I am also very thankful for the source for Gorillas and many simpler BASIC games before it. I started out by adding color to many existing text BASIC games and then moved on to writing my own.
Years later a friend of mine and I added modem support to Gorillas so we could play each other from our houses. Of course Scorched Earth would have been better, but we didn't have the source to that, nor the programming ability to add it at the time.
I was always amazed at the guys on CompuServe/AOL (and later GeoCities) who were writing RPG's in QBasic. I guess I was mostly impressed by the graphics they made, but they kind of proved to me you could write more than hangman or Nibbles in BASIC.
Yep. The author was Milo Sedlacek (aka Gradius). If I remember correctly, he finished Monospace something like a year before he died. I only knew him through IRC, and I recall how weird it was for everyone to go through it at the time. Most of us were just kids and didn't really have any experience with someone "our age" dying.
Hah, reminds me of back in my grade 8th grade (equivalent - ~13 years old?) 'typing' class (circa 1995) - a friend made a 3d engine in QBasic that let you fly a wireframe spaceship around. It was pretty amazing, all things considered.
A friend of mine also made a 3d engine with QBasic that was a racing game when we were in 9th or 10th grade. I remember as he was developing it he was referring to a trigonometry book for a class that he hadn't yet taken. It was totally ridiculous and awesome.
I wrote a game in QBasic when I was 10. At the time I didn't understand the concept of a sub routine _returning_ after being called. So the end of each sub just called another sub (perhaps even the calling sub to create loops). You won by beating the game before getting a stack overflow.
I also used QBasic as a child, I had some GWBasic book as references which rooouuughly matched the Syntax and provided functions. But I also remember not really understanding sub routines... Anyway, this was my experience with goto and good old fashioned spaghetti code ;)
Not QBasic, but this was my first PC programming "experience" [1]. I got tired of typing these in, so I would con my Dad's secretary to type these in because she could type (I didn't really understand at the time that a secretary typing wasn't the same as a programmer typing :P).
Some worked, some didn't and I think I wasn't really old enough at the time to understand why they wouldn't, but I have a lot of fond memories and pride at getting these to work.
Wow, as someone who played with making games using QBasic on a 486 as a pre-teen I am seriously impressed. I have to chuckle at requiring such a fast processor to run well though. Assuming the author doesn't rely on too many DOS game programming tricks (I remember having to peek and poke various memory locations to trigger esoteric video resolutions, etc.) it probably wouldn't be too hard to convert this to run on visual basic & a .net wrapper of SDL or some basic graphics library.
He's already using SDL. Plus, QBASIC64 isn't a DOS environment.
In fact, when you look at the specs for QBASIC64 then it's a little less impressive than first made out. It also makes me wander why he didn't just learn VB anyway (as the libraries in QBASIC64 would have required additional learning anyway). Even VB classic would have made more sense.
Anyhow, this at least reminds the language elitists that a language is only as powerful as the developer who's wielding it.
It's still impressive, though as you say, much less impressive than it seems at first glance.
Doing anything useful in QBasic was such a major pain; from what I recall, to use the mouse(which wasn't supported), you needed to write an assembly procedure byte by byte, do a CALL ABSOLUTE to jump into that procedure and re-read the cursor position from memory.
QB64 appears to compile to various platforms, while VB does not.
Also, VB is pretty GUI and event-centric. QBasic is a pretty good local maximum of being quite expressive while still being a strictly procedural language.
> QB64 appears to compile to various platforms, while VB does not.
VB.NET does compile to other platforms via the Mono framework. In fact Mono is actually available for more platforms than QB64 is.
Classic VB is Windows only AFAIK though I've had a 100% success rate with VB under WINE. But suggesting VB6 was pretty dumb on my part anyway; aside scripting variants (eg VBA), it's a pretty much a dead language.
> Also, VB is pretty GUI and event-centric. QBasic is a pretty good local maximum of being quite expressive while still being a strictly procedural language.
VB.NET supports procedural CLI apps. But if you could equally write an OpenGL / DirectX game procedurally if you wanted (events are there to be used, but you don't have to create event handlers). However I don't really see the point in wanting to avoid using events; he's using a mouse, so it makes sense to have a mouse click event. The code would be a lot cleaner and the interface more responsive than having a looped procedure checking for mouse button states (believe me, I've had to do both - and the one thing I don't miss from writing DOS GUIs in Pascal was having to create a psudo-event wrapper to handle input devices).
That's pretty awesome. I wrote a SCREEN 13 graphical version from scratch. IIRC, the snake sprites were gradient blocks that were procedurally generated, and then used GET and PUT to pick and place them.
Wish I still had a copy of that stuff that I could put on Github!
In case anybody also wanna review those classical QBASIC games, I've just found Boxer.app[1], a free DOS emulator on Mac. And there's also a big collection of DOS games for free download[2].
I can't find anything definitive but I suspect it would be less confusing to say "created by Microsoft" than "created by IBM". It seems Microsoft developed it but IBM somehow wound up with the copyright. en.wikipedia.org/wiki/Gorillas_(video_game)
Back then Microsoft was working for IBM, so it's not that surprising that IBM ended up with the copyrights for QBASIC. What's more surprising is that IBM didn't end up buying the whole of DOS outright (but that's another topic entirely).
Also, I seem to recall reading (or seeing a video interview) where Bill Gates said QBASIC was his last ever coding job.
Oh, I see. It still seems lamesauce for an article that's targeted toward techies to say that IBM created it. Seems like it's a journo looking for a story rather than someone who really cares about the subject matter. Oh well, it was interesting, but I'd rather read a blog post about it than a MSM magazine article.
> Seems like it's a journo looking for a story rather than someone who really cares about the subject matter.
Welcome to the world journalism. It's full of people who either aren't technical enough to work in the field they're reporting on, don't care that much about such industries (they're reporting on it for the love of journalism/writing), or have to dumb stuff down so much to appeal to a wider audience that the article loses accuracy / objectivity.
Lots of memories there. Fun fact - the programmer of that game went on to contribute to the Allegro graphics library. Going from QB to DJGPP+Allegro seemed like a natural progression, and quite a few people in the QB community followed a similar path.
This was the first programming language I was taught. I got super excited with it, by the second class I already had a working etch-a-sketch. By the third I was writing a roguelike based on Moria. At the point my teacher told me to do my own thing and went back to trying to get the other less enthusiastic students to learn. I had a blast that semester, loved that class.
