About 25 years ago I did QA on the spreadsheet module of now-defunct office software maker Enable. On a lark, each of us on the spreadsheet testing team implemented a different casino game using spreadsheet macros. This was the old macro system similar to Lotus 1-2-3, with "/" invoking the menu and then using letters representing the hotkeys for each menu command, etc.<p>I took on blackjack, and built a whole Vegas-style game including insurance, doubling down, a configurable number of decks, etc. I was pretty proud of that, what with the self-imposed constraints. But that seems to be small beans compared to this project.<p>The number of bugs that we uncovered during this effort was pretty substantial. For example, we discovered that the PRNG implementation was a lot more P than it was R. We found that when the guy who'd written the craps game set it up to play automatically overnight, based on some simple heuristics. When we came back the next morning, his robo-player was rich, and we all know that's not supposed to happen in a casino. We re-ran the same test the next night, with the same result. It turned out that a quirk had rolls of 11 coming up more often than they should, which is a real problem for craps.<p>Anyway, trying to implement something non-trivial with self-imposed constraints sure isn't the most efficient way to accomplish the task, but it's a great way to stretch your understanding of a platform.
with GPU-accelerated spreadsheets (google: AMD LibreOffice Calc) it would be interesting to see more games use the spreadsheet as the engine for games with massively-complex 2D worlds with easily parallizable local interactions.