This is a brief rambling about what I've learned about fast prototyping.
This all started with an offhand comment, and ensuing disagreement, that
Gradius (you know, the side-scrolling space shooter from the Ghetto
Nintendo?) would be a better game with mouse control.
I wanted to explore the idea, but I really didn't want to rewrite Gradius
from scratch. Mostly all the effort would be thrown away as soon as I had
a "yes" or "no" result, so all time spent is wasted time. I mean, we all
know I've got loads of free time, right?
Just to give you an idea of the (ahem) fine craftsmanship that went into this,
here's a screenshot of the final prototype:
...So here are my notes after about a day of hacking on this.
* I tried this with FreeBASIC (http://www.freebasic.net/). I wanted to know
if a "high-level language" (and not high-level in the way that C is
"high-level") would help, and BASIC is widely-considered to be a Rapid
Application Development language, and this was the first thing that
looked appealing to me when I Googled for "SDL language bindings". Some of
this will be talk about FreeBASIC itself and not BASIC in general.
* As painless as FreeBASIC was to use, compilation of the prototype source
was a pain in the ass. I miss QuickBASIC's startup time when you hit F5.
* The compiler only reports one error at a time, so fixing syntax bugs was
even slower.
* FTE (the editor I use) doesn't have a BASIC syntax highlighter or function
regexp, so editing was slowed down, too.
* FreeBASIC is x86 only, since it generates x86 asm that it then assembles
into an object file, so I can't work on my powerbook, which limits my
development comfort, etc. It DOES work on Linux and Windows, though, which
was nice.
* The totally clean C integration was great; it ships with SDL support, and
I could wedge any C-callable shared library into it by adding a few lines
of BASIC code. So if I wanted to use PhysicsFS in the prototype, or, say
BSD sockets, I could. That was great. It actually worked well with gdb,
too, which was a huge plus.
* Remembering BASIC syntax was a slowdown. I haven't written any BASIC in 10
years, so there was some amount of slowdown in getting back in the groove.
I still forget to stick a "then" at the end of my IF statements after a
full night of working with this.
* FreeBASIC added a bunch of stuff to what was more or less QuickBASIC or
VBDOS...basically, all the stuff that was becoming problematic to not
have in QuickBASIC that made me switch to C back in high school...notably,
you can use and manipulate pointers. This makes the C integration much
easier, and it really does make some tasks cleaner even within BASIC
itself...I would have _loved_ to have this package 10 years ago. However,
this led to one of the main problems that you use BASIC to avoid. I
actually had a bogus pointer dereference (my fault!) and had to spend
time tracking it down, removing some of the benefit of using BASIC in
the first place. However, being able to turn on runtime exception
handling for array bounds checking, etc, was nice to have...but having
access to real pointers became a wicked temptation. You really have to
think in terms of BASIC to do this right, even if you know that
deferencing that array every time you want an element is "way slower"
than just keeping a pointer to that element. Once a C programmer, always
a C programmer. It might be better to remove the temptation altogether.
* The real issue with rapid C development is probably memory management,
and string manipulation, which is a specialized form of memory management.
But for this prototype, there wasn't a lot of either...very few strings,
none with any meaningful manipulation, and two dynamic arrays. One of
those arrays I could have (and should have) done without, and the other
introduced the pointer bug...and could have been static with an assert
if it overflowed, if we're being practical. So in this case, memory
management wasn't a big win for BASIC, but in other programs, it should be.
* The prototype (an extremely basic shoot'em'up) turned out to be about 500
lines of code. Easily less than 100 of those are actually specific to the
game and the rest were more generic...maintaining actor state, blitting
stuff to the screen, etc. In this case, the whole thing really turned out
to be, line for line, what I did in BASIC with SDL and what I would have
done in C with SDL. Prototyping is more about the framework than the
language, perhaps.
* Prototyping is about making bad design decisions as a tradeoff for time.
It should be a mess of inefficient code and corner cases and "!!! FIXME"
comments that will never really get fixed. I spent way too long trying to
be abstract and elegant, when I should have been expecting to throw this
out and design it right later.
* A sort of unspoken benefit of BASIC is that I won't ever ship this
particular code as a serious project, since the compiler isn't optimizing
and it locks me out of the Mac, etc...and hey, it's BASIC and I Have My
Pride and all that. The end result? This guarantees that, no matter what,
the first draft gets thrown away, which is good, since it lets you get the
bad choices out of the way early.
* It's important not to write a game when writing a prototype. In this
exercise, I wanted to know, "is Gradius better or worse with mouse
control?" This can be determined without rewriting Gradius. The source
has stubs for rendering terrain and such, but really, all I needed was
some sprites to come from the right side of the screen that I could shoot
at. Keeping focus on the specific goal trims out a lot of work and time.
* To Summarize:
- Automatic memory management is good.
- Interpreted languages are good. Removing the edit-compile-link-run-debug
cycle is good.
- Frameworks are good. More important than the language that uses the
framework.
- Implementing the bare minimum is good.
- Throwing out everything at the end is good.
* I haven't looked into Torque2D too heavily, but I suspect if the
learning curve is extremely low, it'd've been perfect for this
endeavor...even if the final product was rewritten in something else.
* Comments are welcome. I'm interested in refining my thoughts on this.
Oh, and if you want to laugh at the program, here it is:
http://icculus.org/~icculus/dotplan/gradius-mouse-prototype.zip