Sandblaster

Sandblaster (CSF Game-A-Week #9)

HOW TO PLAY:

Draw on the screen with your mouse. Click the UI buttons to change what is drawn and how big they are drawn. Click "Forward" to run the simulation. Click "Reverse" to step back in time. Note that you can only draw when in the Paused or Forward state. Finally, beware that this is not optimized, so don't fill the entire canvas with lava. :)

CONCEPT:

• Make a falling sand puzzle game
• Implement time dilation mechanics

WHAT WENT RIGHT:

Time dilation was trivial to implement and I had that working on day one thanks to the Command pattern. Falling sand simulators have been around for decades as well, so coming up with basic algorithms to try out was also easy to do. Loading an initial state from an image file was also somewhat easy to do after searching forums for the pieces I needed to implement. Finally, publishing to WebGL was easy because I have recently gained experience doing just that. This reinforces the underlying concept behind the fail fast approach at the core of game-a-week projects: extend your skillset with hands-on experience and learn what works without considering other external factors like code quality, marketability, and so on.

WHAT WENT WRONG:

Performance is a major issue when dealing with cellular automata at scale. If you write one line of bad code (e.g. I was calling `texture.Apply()` every time a pixel was drawn), then performance can suffer greatly.

There is no game here, just a basic simulator (and one that might freeze up if you play with too much lava, so beware). What went wrong is explained more in "what I learned" below.

WHAT I LEARNED:

I learned a few things this week, one of which is that there are a lot of issues involving the ordering in which cellular automata are processed and how that affects the state of the simulation per frame. 

I also learned that hand-waving major design decisions with vague statements (e.g. "make a puzzle game") is a disaster in a time crunch. There was and is ultimately no puzzle game here. I then thought that maybe a side-scrolling game would be fun. But that didn't work out either. 

Another important takeaway is that sometimes it is better to pivot when struggling with a design decision, rather than forcing something that just doesn't fit. For example, a version of this prototype had a "player" particle that could be controlled. It was a mess to implement and didn't add much fun by itself. When I finally stopped trying to force other game paradigms into this one, I finally let the prototype be a sand simulation, and more ideas started to flow when I embraced what worked (though too late to be implemented here).