I, for one, thought the idea of “OS” reads and writes from Get Bonus was a neat
abstraction, even if it is more or less just functional reads and writes to a
giant hash table. Obviously that’s more complicated than would be appropriate
for big-bang, but I thought I’d bring it up anyway.
On
I have for years hoped to find time to think about 'distributing state' over
handlers in big-bang because I am perfectly aware of the scaling up
limitations. Your hashtable idea might be worth exploring. Tony and I are also
considering his actor system as a source of ideas. This may also give
John Carmack:
My son's game has a level editor as well as a game loop, and we switch
between them. However, each new big-bang call creates a new window,
leaving the previous ones inert on the screen. How can we close the
windows?
Matthias Felleisen:
But people wanted it to stay
open
On Jun 22, 2015, at 11:31 AM, Jens Axel Søgaard jensa...@soegaard.net wrote:
John Carmack:
My son's game has a level editor as well as a game loop, and we switch
between them. However, each new big-bang call creates a new window, leaving
the previous ones inert on the screen. How can we
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
My son's game has a level editor as well as a game loop, and we switch between
them. However, each new big-bang call creates a new window, leaving the
previous ones inert on the screen. How can we close the windows?
--
You received this message because you are subscribed to the Google
It used to be that when you ran a program like this
;; isl+
(require 2htdp/image)
(require 2htdp/universe)
(big-bang 10
(to-draw (lambda (x) (circle (+ (* 10 x) 20) 'solid 'red)))
(on-tick sub1)
(stop-when zero?))
The window would shut down. But people wanted it to stay
open so that
On Jun 21, 2015, at 10:18 PM, Neil Toronto neil.toro...@gmail.com wrote:
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.
On Jun 21, 2015, at 2: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
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
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,
The enclosed big-crunch.rkt library provides a `big-bang/big-crunch`
form that is the same as `big-bang`, but it closes the window with
`stop-when` produces #t. (I wrote it for my son.)
;; isl+
(require 2htdp/image)
(require 2htdp/universe)
(require big-crunch.rkt)
(big-bang/big-crunch 10
Another option is to arrange that there is only ever a single call to
big-bang and there's a top-level data-type for the different modes of
the game:
World = EditorWorld | PlayerWorld
And when the Editor is ready it returns a Player. This can be a bit
awkward because of the need for a top-level
13 matches
Mail list logo
