sixten VS wordwarvi

Immutable data structures don't necessarily require more memory: they can avoid deep copies. They are also automatically thread safe without expensive (slow) locking mechanisms. They also don't necessarily reduce cache locality. The reduced cache locality in the case of Haskell (I think) mainly comes from the representation of objects in its implementation (improved STG) which uses extensive boxing and jumps that hinder both spatial and temporal locality (require review/comment from GHC/Computer Architecture experts, take it with a grain of salt). Objects can be much more efficiently represented if not for the need to implement lazy (call-by-need) semantics. See sixten and futhark for examples.

[Sixten](https://github.com/ollef/sixten): functional programming with unboxed data by default.

I can't answer this well and don't know of any resources, but I have seen it before in the parser for sixten:

    https://github.com/ollef/sixten/blob/60d46eee20abd62599badea85774a9365c81af45/src/Frontend/Parse.hs#L458

Sixten is a language that allows precise control over memory layout of algebraic data types.

For something more peripherally related, check out Sixten. Its focus is on using unboxed value representations, which is in spirit close to what you are proposing, and some of its ideas might be good inspiration.

Word War vi - side scrolling shootem-up kind of like Williams Defender.

At a very high level, set up an array of objects in your game. Each object has the ability to draw itself, and move itself. Each iteration of the game, move all the objects, and draw all the objects and sample user input. Set up a timer to iterate the game 30 or 60 times per second. Here's one game I wrote in C that works in this way: Word War vi If you dig through old commits in the repo you can follow the development from the very beginning, which begins with just creating a GTK window with a button). Almost every commit in that repo should compile and run. There may be the odd one here or there that crashes, but 99% of them should be fine, so if you want to advance through the commit history and see how the game progressed over time, you can do that. I wouldn't presume say the code is exemplary by any stretch, but it's fairly straight forward, and it works.

> Semantic Bovinator

Heh. A long time ago I wrote a video game[1] somewhat similar to Williams Defender, and casting about for some sort of "theme" for the game, I hit upon the "editor wars", the ancient storied battle between vi and emacs. You are ostensibly "vi", (a little spaceship vaguely reminiscent of the Vipers from Battlestar Galactica) cruising through system memory, evading system processes, GDB instances, etc trying to recover your ".swp" files. How to represent Emacs? Obviously, via a giant blimp! and I could display all sorts of messages on the side of the blimp, singing the praises of Emacs, and disparaging fans of vi. And the Emacs blimp had a "memory leak", which meant that pieces of the xemacs source code would literally leak out of the back end of the blimp, with the letters floating lazily away, like smoke. So that meant I had to take a look at the xemacs source, dig through it and try to find some funny bits to put in. Of course, "semantic bovinate" jumped out at me.[2]

[1] https://github.com/smcameron/wordwarvi

Honorable mention probably goes to Word War vi