The best QBasic game ever?
pcworld.com
pcworld.com
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 :)
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.
(I'm not taking anything away from the game! )
Lucky bastard.
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.
Also, yeah, I use the big ugly eye-burning white-on-blue screen. You can see a photo of the development box here: https://twitter.com/manfightdragon/status/319786194395357185
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.
The game looks cool, though!
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.
> 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.
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"?
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.
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's not like he said QuickBasic but used C++.
Also you're not compiling anything. It's all interpreted at run time (which is why performance is dog slow).
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.
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.
$ 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 <<<
It's pretty common for compilers for niche languages to statically link the runtime library by default. Many think it eases distribution.
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)
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.
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...
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.
[1] http://en.wikipedia.org/wiki/QB64
edit : checked an old QBASIC manual to confirm whether or not multidimensional arrays (2+) were supported
DIM cube(3,5,4)If I get on Steam, I'll be able to use the DLL features to implement SteamWorks API
I happen to have an old QBASIC book (pub 1993) next to me, and was skimming through it shortly before coming across this article.
Random file I/O :
OPEN filename$ FOR RANDOM AS [#]filenumber LEN=recordlength
Drawing 2-D "staircases" diagonally in both directions across the screen :
PSET (0,0)
FOR p = 1 TO 25
LINE -STEP(25,0)
LINE -STEP(0,15)
NEXT p
PSET (639, 0)
FOR p = 1 TO 25
LINE -STEP(-25,0)
LINE -STEP(0,15)
NEXT p
END
http://www.amazon.com/Absolute-Beginners-Guide-Qbasic-Perry/...
Amazon doesn't have the cover art, but it was very similar to this one:
http://ecx.images-amazon.com/images/I/51VswbyvRHL._SL500_SS5...
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.
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.
You can see a video from there with some actual code: http://www.youtube.com/watch?v=y2nBge7wq6c
It actually doesn't seem that bad of an environment, which is a reminder that we haven't gotten that far with programming since the QBasic days...
http://www.reddit.com/r/IndieGaming/comments/1bqegf/i_put_my...
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.
[1] http://www.amazon.com/BASIC-Computer-Games-Microcomputer-Edi...
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.
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.
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 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).
[and probably loads of bugs]
Wish I still had a copy of that stuff that I could put on Github!
[1] http://boxerapp.com/ [2] http://www.dosgamesarchive.com/
>Black Annex requires at least a 2.6GHz processor due to the scope of the project and the unoptimized multi-dimensional arrays.
Also, I seem to recall reading (or seeing a video interview) where Bill Gates said QBASIC was his last ever coding job.
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.
This looks like it might take the title though.
I learned programming by turning Gorrila's in to a game with buildings that moved every turn, and changing the graphics.
Putting a screenshot of the game above a video of Gorillas, and then claiming they're both written in the same language, is misleading.
I loved QBasic.