Mark Sachs (ksleet) wrote,
Mark Sachs
ksleet

  • Mood:
  • Music:

Yet more Run Don't Walk stuff.

Many thanks to the anonymous commenter who suggested adding fire to the game. I'm totally digging that concept. No video today because I'm feeling lazy, but I've implemented pools of oil and spreading fire. Oil will catch on fire if it's adjacent to a burning tile, and goo cannot cross fires of any sort (plus any infection in progress will be destroyed if a tile catches on fire before being fully consumed.) Of course, the fire will go out after a few seconds... In addition, I have decided that the main character shall be carrying around a flamethrower, which can be used to temporarily halt the flow of goo or just set things on fire for kicks. Hmm, I should get on that character design already. And maybe, you know, actually add the player-controllable character to the game?

This does raise a secondary problem I've been trying to avoid coming to a conclusion on. If this is purely a puzzle game, then it should play out in a deterministic fashion: every time you run the simulation, it should proceed in a completely predictable fashion -- goo spreading at a fixed rate, fires burning out at a fixed rate, et cetera. But unfortunately, that leads to a very mechanical look to what should be more organic-looking processes such as fire. It would look a lot better if fires burned for a random period, tiles took a little more or less time to succumb to goo, that sort of thing. But in turn this makes puzzles just that littlest bit less deterministic. I'm leaning towards the view that I should do this anyway... move away from a 100% puzzle-focused design and instead design levels that have some room for error and flexibility in them.
Tags: programming
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 4 comments