Defect process clof code#
Debugging has also been fairly straightforwards during development, being able to reason about isolated sections of code with a high degree of confidence is very useful.Having a strong static type system helps a lot here. Refactoring has been pleasant enough during development, even for major changes.It's more useful to think of functional purity in haskell as something that enforces disciplined management of state (among other consequences), rather than something that doesn't let you do anything.The goal wasn't to make something only possible with haskelly bits, but worth mentioning nonetheless. It's extremely possible to have written this game in any of a number of other languages.This is an illustration of how that could look, for comparison. It'd be possible to write the whole game with this "direct approach", but messier. These are essentially debug commands, so the code here is intentionally separated out from the usual flow. The in-game dev console commands ignore the message passing technique described above, in favor of a more direct approach. Performance hasn't been an issue during development, but it'd also be fair to point out that the game isn't really computing a ton of stuff. There's likely a decent amount of low hanging fruit to optimize. In testing the game has always been GPU-bound on weaker systems, so there hasn't been much profiling work done on the haskell code yet. Minimum spec for this game is an x86-64 machine that can handle rendering from multiple 4k textures, which effectively limits how slow the CPU is going to be. For some types of games that could potentially be the case, but not this one. This post indicates that long pause times don't start to happen until the GHC runtime is managing many gigabytes of memory. That flag isn't critical however, the default -copying-gc behavior is also fine in testing (< 1 ms pauses). This game uses the recently implemented -nonmoving-gc garbage collector, which avoids stop-the-world behavior that could cause stutters. It's kind of a basic 2d engine, not that much interesting to talk about. The game engine code is mostly contained in src/Window/. Windowing, rendering, and input are implemented with:Īudio is implemented with C bindings to FMOD. The simulation runs at a fixed 120hz but renders at any refresh rate, implemented as described in Fix Your Timestep!.
Defect process clof full#
The full implementation is more complicated but the core idea is as described above, see src/Msg/ and src/World/Main.hs for the relevant code.
Defect process clof update#
This allows different game entities to communicate with each other while keeping their own update functions clean. Particles' <- updateParticles allMessages particles Player' <- updatePlayer allMessages player ParticlesMessages = thinkParticles particlesĪllMessages = playerMessages ++ particleMessages ++ levelMessages The main game loop is a tail recursive call, which simplified looks like: The partial source code is available on GitHub. Documentation of the haskell code for Defect Process, a 2d hack n' slash game on Steam.
0 kommentar(er)
