On Sun, Jun 21, 2015 at 10:18 PM, Neil Toronto <neil.toro...@gmail.com> wrote: > 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.
In my existing games, I do two major things. First, I typically use a giant functional hash table with gensym allocated keys and without the ability to iterate through them. This gives abstraction and pretty nice flexibility. The other thing I do is make each entity & system in the game be a separate cooperative thread, so that I can capture most of the state in the continuation and the recursive arguments. A really simple example is here: https://github.com/jeapostrophe/dos/blob/master/dos/examples/win.rkt The mouse-tracking-ball uses the recursive argument for its radius and the decaying-ball uses its continuation to storage where in the count-down it is. This all implemented by the DOS package, primarily the "win" library. http://pkg-build.racket-lang.org/doc/dos/index.html > (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.) I'm presently working on an entity-component-system library that supports abstract state and processors that is compiled to large homogenous arrays and batch processing. But it's a ways off. > 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.) This is how my current sound system works. The main interesting thing is with the naming of sounds. Rather than naming a sound or getting a handle returned for it via a function like "create-sound : audio-info -> sound-name" and being able to move and control it with functions like "sound-stop! : sound-name -> void" etc. Instead, when you create a sound you give a function that looks up all the state "create-sound : (world -> (audio-info x position x playing?)) -> sound-handle" and then big-bang loop is responsible for calling "sound-update! : sounds world -> sounds" periodically. This will cause all the inner sounds to be updated with the new world, which could do something like look for the new position of the missile in the world to change the position of the sound. The library: https://github.com/get-bonus/get-bonus/blob/master/gb/audio/3s.rkt The simplest example: https://github.com/get-bonus/get-bonus/blob/master/games/tennis/main.rkt#L187 > #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. I personally have found this relatively easy to deal with if I try to think about allocation rather than JUST convenience. Jay > 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. -- Jay McCarthy http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 -- 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.
