On 06/21/2015 02:54 PM, Alexis King wrote:
I guess I could add a close-on-stop clauses for programmers
such as your son but it sounds almost like he's ready to move
on to racket proper, as in use the Windowing API directly.
FWIW, despite big-bang’s position as a teaching tool, I much prefer it over
using the Windowing API directly, considering it provides a pure interface for
working with real-time graphical applications. I like big-bang’s approach to
that problem, and I’ve found myself using it many times due to its ease of use.
In contrast, racket/gui is frustratingly imperative.
He may also be interested in Jay's variant of 'universe',
which is faster (and comes with sound) or Neil's (experimental)
3D version. I conjecture that they are both more open to extensions
than my teaching versions
Absolutely.
I’m aware of pict3d/universe, but I admit I haven’t heard of Jay’s version. Is
that what lux is? (Either way, it would be nice to get the docs building
properly on pkg-build, since currently the build fails.)
pict3d/universe supplies `big-bang3d`, which is like `big-bang` but is
slimmed down (e.g. no pad overlay) and takes keyword arguments instead
of special syntax. It also supplies game time and frame count to each
function, and makes explicit guarantees about threading and event order.
And it doesn't try as hard to tell you what you did wrong.
Jay's lux provides an abstract framework for game-like programs. It's
easy to make adapters for different ways to render games that plug into
it. (I've done it for Pict3D, for example.) The best thing going for it
is its generic interface, which saves programmers from having to do
top-level dispatch based on game mode in every callback function.
Anyway, I think it would be nice to have something like 2htdp/universe that’s
aimed at more experienced programmers. If lux is designed to be that, I’ll
certainly take a look. Otherwise, would it be worth spending some time figuring
out how to generalize and scale the ‘universe’ idiom to be a bit more powerful?
Jay's lux and my `big-bang3d` are both small steps in that direction.
FWIW, while `big-bang3d` is experimental, its current form will remain a
stable subset of the API, and it works well.
I'm working on a `big-bang3d` game intended to expose shortcomings in
universe-style programs when used at a larger scale than in the
classroom. Here are my main criticisms so far:
1. Adding new state is painful. Every time I add a little bit to track
something - a cooldown timer, camera momentum, a list of planes the
player collided against - I have to change a lot of unrelated code.
2. Adding a new game mode (e.g. menus, level editor) involves a lot of
boilerplate.
3. We don't have a good story for sound.
4. Paying the garbage collector can get expensive. Figuring out how to
not pay it so much is next to impossible at the moment.
For #1, I think we need nicer ways to reach deep into heterogeneous data
structures to read from and update them. Refactoring data structures
only goes so far. Game state is a big, messy thing with a lot of
interaction that defies neatly compartmentalized trees.
(It would also be nice to have support for batching all the updates for
performance. This could also make it easy to send state deltas over the
network.)
Having tried Jay's generics solution, I think it nearly solves #2. I
wish generics were better supported in both typed and untyped Racket.
I think we imagine #3 is harder than it really is. Quake III Arena's
engine API basically has just "start/keep playing this," "stop playing
this," and "move the source of this sound here." IMO the only real
design issue is figuring out how programmers name sounds so they can
refer to them later.
(Engineering-wise, we need a mixer running in a separate thread/place
that big bang programs can issue commands to over an async channel.)
#4 is a real-time Racket thing generally. I've managed to make Pict3D
trigger major GCs only occasionally, but only with a lot of guesswork
and behind-the-scenes imperative fakery. It would be nice if users could
avoid both.
Neil ⊥
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
