[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re : [Chicken-users] 3D update
Re : [Chicken-users] 3D update
Fri, 23 Mar 2007 14:23:32 +0100
2007/3/22, Brandon J. Van Every <address@hidden>:
The Ogre 3D engine bored me to death. I spent 1 week reading the docs,
feeling pretty miserable about it and not getting any work done. All I
wanted to do was shove things into vertex buffers, and the engine really
wasn't adding any value for this kind of low level problem at all. Ogre
is oriented towards loading 3D models from modeling / animation
packages, and I just don't need that right now. I still think I'm going
to do a lot of game artwork with procedural content, even if I'm not
sure that procedural content actually buys me anything. I'd just rather
arse around with programming than with 3D modeling packages, even if it
takes the same amount of time.
I sought a kind of german demo which featured procedural content to
make a very small exe that holds everything. It was popular at the
time but I forgot the name.
I'm working on some kind of game in Scheme. I've adopted a prototyping
mentality, that this project isn't to prove that Chicken Scheme is
actually worth anything to anyone else. For the past few years I've
been guilty of "premature marketing" in much the same way as I am often
guilty of "premature optimization." Someone suggested that I undertake
a "7 Day Roguelike (7DRL)" style challenge, get some kind of game done
in 168 hours. I think I may do it, and I'll start the timer when I've
worked through a few more Scheme idioms.
That seems a good idea to me. And you can ditribute the gruntwork
later around part of already working code.
At some point when I actually have a working game, if I still think
Scheme is gaining me something, I'll refactor the basic 3D engine and
windowing code into some kind of useful library. This will supplant the
nascent gl-display project. I don't see any point in cooperating with
others about this right now. My problems are driven by my game.
Cool but I think the problems adressed by gl-display and a 3d engine
are quite different.
I've decided that C++ is not as important as I thought. I think, for
getting jobs in the game industry, it's more important to bill myself as
a hardcore 3D engine developer. Or game author, or AI jock, or
whatever. The language isn't important.
I can't help you here but your last mail on this list (about the
interview with a game company) said the contrary. I guess that if you
can show thing, the underlying language won't be important. But the
"thing" has to be there.
The main thing I'm trying to figure out right now, is how to replace my
C++ OO instincts with Scheme idioms. I don't really want to use
TinyCLOS, I want to be free of OO paradigms entirely. I honestly don't
think OO is worth anything. Every problem I've ever tried to address as
OO has eventually broken down. It is really always a relationship
between 2 entities in some environment, with no clear hierarchical
precedence or ownership between the entities. I think all I've ever
really used OO for is polymorphic interfaces. If I can figure out how
to get 3D geometry to shove itself into different kinds of vertex
buffers, then I don't need OO anymore. I'm currently going up the
Closure learning curve.
My view on OO is that it's just a way to organize things. But not the
only one, nor the best one. It all depends on the situation. Thus
using closure is just another tool.
Not the one true way. For that matter, purely functional style would avoid it.
I believe state Vs stateless (parameters threading from procedure to
procedure) are both good.
That's why I like Scheme : you can do what you want. (even if I don't
have lot of experience with it)
(And since I like also C, working with chicken is really enjoyable)
My guiding light, despite Scheme's complications, is that R5RS is only
50 pages long. I anticipate this will be my sales pitch in the future.
"It's only 50 pages, how bad can it be?"
Still "premature marketing" :)
Also, r5rs misses some data types (can't compete with stl or the big
java api -- am I saying something stupid here ?)
Anyway, the idea of having a small *working* prototype is a good one.