3 ms·
Games are all about keeping the user in the 'flow'. Humans are really good at picking up on unpredictable timing. Action games are thus fundamentally hard-real
by marshray 8y ago
Games are all about keeping the user in the 'flow'. Humans are really good at picking up on unpredictable timing.
Action games are thus fundamentally hard-real-time systems.
- _bxg1 8y agoMy thinking was to have a top game loop that "ticks", and then passes the current game state + the time delta to a pure function which returns the new game state, which gets stored. Is the concern that Haskell's lazy-evaluation might lead to a higher level of variance in frame-rate than another language?
- marshray 8y agoRight. One technique used for writing games to run on GC'd runtimes is to avoid allocations entirely in the game loop. With a lot of work, you can preallocate everything you're going to need and just modify it as you run. This technique is not a good match for Haskell's primary design principle of avoiding mutable state.
- _bxg1 8y agoTo be clear, I'm not aiming to build the next Call of Duty; these days you can get pretty far building a medium-sized 3D game out of unoptimized JavaScript running on a web page. The GC optimization you mention is interesting to learn of, but probably irrelevant for the kinds of things I would be doing. Does that change your assessment of Haskell for this purpose?
- marcosdumay 8y agoThat depends on how large is your state. The GHC GC is normally fast, but gets slower the more objects you keep around. Lazyness can severely increase the number of such objects. If your game has real time dynamics, it's not worth it. If it's some turn-based one without animation, it's not a problem.