| Brandon J. Van Every 2004-10-24, 3:57 pm |
| Philippa Cowderoy wrote:
> On Sun, 24 Oct 2004, Brandon J. Van Every wrote:
>
>
> That suggests to me that it matters a lot less what language you
> choose so long as you don't end up breaking your monitor in
> frustration -
That's somewhat true. My main frustrator is when I can't get the
performance I want. I'm a low-level performance kinda guy. Languages that
won't let me get down to the metal irritate the piss out of me. Or that put
futzing steps in the way. OCaml has a clunky C FFI, for instance.
The other main frustrator is so-so tools support on Windows. I like good
editors and libraries, not so-so half-broken ones that maybe build, maybe
work, maybe have people using and maintaining them. I'm surprised at the
degree to which tools issues have come to dominate my thinking. Bad tools
tend to negate the perceived benefits of research languages.
> myself, I have a tendency to use Haskell as my design
> language, so the ability to refactor and rearrange is important for
> me. I also seem to be a lot more tool happy than you are - I'm quite
> happy to spend the next few years researching how to build better
> tools as long as somebody pays me enough
> to live on (a comparatively modest sum).
I certainly don't value tools for their own sake. I'm mainly interested in
the results that can be obtained from them. I haven't stumbled into a tools
domain that pleases me yet. Maybe this is career accident. I spent very
little time in industry, only one 3D device driver job really. 1 year of
that was enough; I did 2, so I quit. If I had the temperament for being
someone else's employee, and bouncing from "gee you could do this, gee you
could do that," maybe I would have run into a tools job I liked. I imagine
I would have had to try many jobs though. Much as I've tried out many open
source languages and tools. Anyways, I went straight for what I wanted to
do: games. *My* games. Thus I haven't been 'tools guy' for my games. I've
been 'game design guy'. For that, pencil and paper is by far the best tool.
> Erik's suggestion of writing
> the speed-critical bits in C then gluing them together with whatever
> tickles your fancy seems appropriate for you - in fact, I'm tempted
> to suggest you try Haskell, as I know a number of people who like its
> FFI.
There was a time at which I wanted more than that. I wanted builtins for
important ASM operations, like SSE instructions. I also wanted a good C++
bridge, since there's so much legacy C++ code out there. I eventually
discovered that neither of these was gonna happen. Not while meeting all
the other goals, like performance and good Windows support. So I backed off
on my expectations.
*But*, I kept going through the same drill with every language I'd evaluate.
I'd read all the docs. I'd check out the community. I'd get the tools up
and running. When I started digging deeper to actually *do* something, to
actually code, I'd always be looking at the C FFI. And then I'd run into a
PITA. I did this enough times to realize, this is important to me. I have
all these low-level structural ideas of what I want to do. I don't want a
language that interferes with it.
In other words, Erik's 'suggestion' comes rather late. It's an odd
suggestion, given that I listed "an excellent C FFI" in my laundry list of
required features nowadays. But perhaps here's the difference. Some people
think it's acceptable to have high performance C / ASM code tied together by
a low performance systems language. I do not! I want to get as much
performance done in the systems language as possible. I've got a *lot* of
stuff I want to be high performance. I'm writing 3D engines and AIs, not
Microsoft Office. The low level core RISC operators are very important; so
is the performance of the systems language.
I also think some people underestimate the importance of the HLL <-> C
bridge. Easy to do if you make infrequent use of it! I'm not coding "a few
critical bits here and there." The bridge is core to my design methodology.
I'm always intermixing high and low level views of a problem. What I want
is pretty simple: to get in and out of large arrays of smallish C structs
quickly. The bridge needs to be easy to work with, and it needs to be fast.
> But either
> way, write some code dammit! I may be tool happy, but at least I
> write the damn tools...
Yes but you found happiness in Haskell. You've had, like, how many years of
university experience to dink around with it and decide you like it? Aside
from ASM, I've yet to find happiness in a language. It is a precondition to
me writing any code. My list of "what I must have" is now very well
focused, at least. Lotsa iterations on what I can and can't live without.
Lotsa experience with the open source language landscape.
I've got tons of *designs* for things. I've got all sorts of AI designs and
driving problems that I don't talk to people about. I don't sit around
trying to please the Eriks and Christers of the world. I don't even bother
to have AI conversations with *nice* people, unless it's over beer. Why
should I? I haven't run into any stumbling blocks about it. I know what I
want, I've done a lot of work on it, and I don't talk about it.
Some people just crack me up. I spend 6 months working on various aspects
of my problems, I have this *huge* mental inventory of what I've been up
to... and some people react like I've been daydreaming for 2 days or
something. Maybe I just don't post enough anymore, LOL! Anyways, I know
where all the time went. I know what was a waste of time and what wasn't.
I've made public reports on the real blunders, like thinking I could get
open source people to do anything. So much doesn't get said, but people
make their own assumptions.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
|