PMD Experimental Dev Release 0.0.3
(c) Sean Kelly / Psych Software 2008
spkelly@andrew.cmu.edu

Minimum System Specs:
Intel Mac running OSX.  I'm working under 10.4, but 10.5 should be fine.
PPC and (*gasp*) Windows versions of the final game and perhaps some demos are likely to be available, and ought to have rather lower requirements, but to my knowledge there are no Intel Macs with retro specs, so the issue is moot for now.
Your mileage will vary with your graphics card memory and system RAM, and your CPU will dictate how long levels take to build, but not how fast they run once built.


Controls:

movement: up/down/left/right
dash: double-tap a direction

go down or up a level: z when on a stairway (may take time)

regenerate the current level: l (may take time)

quit: esc

F1: toggle FPS
F2: magic happy things (see Known Bugs)


Overview:
This is a very early build of the mystery dungeon algo I'm going to be wrapping into a classic-style RPG (if you're feeling echoes of Cave Story, don't worry, I am too- hopefully this won't take quite 5 years, but I'd like to see if Psych Software can give Studio Pixel a run for its money).
The only mechanic right now is to find a stairwell (up is currently drawn as a 0, down is currently drawn as a 1) and proceed to the next floor.  There is always one entrance and one exit to every floor (the top floor's entrance doesn't take you anywhere), and every open point on every floor can currently be reached from every other point, so there is ALWAYS a way forwards.  The end of the dev demo is currently whenever your graphics card cries uncle.  Mine (MBP 2.4GHz, 2GB RAM) gets unhappy in the 200-300 map dimension range (that's 40k-90k individual 'unique' procedurally generated tiles it has to juggle).


Known Bugs:
Mainly texture caching.  As just stated, this program generates a Royal Imperial Excrement Tonne of individual textures.  Now, in smart OpenGL implementations, unused textures will be flagged by OpenGL as 'purgable,' meaning the OS can freely ditch them to not-system-RAM as needed.  OpenGL under OSX, sadly, does not appear to be that smart, and if the app uses a texture once, it is kept in physical RAM until doomsday or explicit deletion.  Thus, as you wander around and see more and more of a level, the app's RAM footprint will grow, and in the 150+ tile square map range, eat up in excess of 2GB physical RAM even though all signs point to simply a 2GB pagefile.
This is where the F2 key comes in.  As of 0.0.3, F2 will enable or disable manual texture culling.  With culling on, a little (negligibly) more CPU will be consumed, and the app will make a bunch of GL deletion calls to get rid of unused textures, only regenerating them when the window gets close enough to the specified area of the map.  Side effects on very slow systems may include the occasional row/column of blank white map tiles if OpenGL doesn't have time to reload the texture.  Side effects on unlucky systems may include a massive memory leak (your RAM a'splode), as according to the interweb, some OpenGL implementations don't actually free their back-end memory allocation on a delete call, and always allocate more on a regenerate call.  
If you're on a Mac, I'd say tap F2 once either up front or as soon as you start experiencing multi-second hiccoughs in regular map navigation (indicating OpenGL and your graphics card are going into panic mode and trying to make the textures your graphics card can't fit disappear by moving them around repeatedly), and if the world doesn't end, don't touch F2 again.
If you ~disable~ culling after enabling it, you'll experience blank white map everywhere but where you were when you disabled culling until you change floors or regenerate the map.  This is because culling cleared out a lot of the map textures and simply turning off culling can't recreate them.



Trivia:
* The only pre-made assets in this demo are the character sprite, the text font, and a pseudorandom number array.  Everything else is procedural.

* Speedrunners will be interested to hear that currently, and by all plans for the final, the seeds for all random/procedural aspects are based on the running game time and other player-adjustible state data.  The random number system itself is written into the game, so it ~should~ produce identical results regardless of the machine running the game.

* There are currently 2 level carving algorithms- Rooms&Corridors and Caverns.  Caverns, a wildfire type algo, takes a good long time at high map sizes, so if you're waiting more than 30 seconds between floors, expect a cave.

* PMD is not the final title, but it's a working description until inspiration strikes.  It stands for "Procedural Mystery Dungeon."

* That said, I already have my main cast written up, and the beginning, endings, and major turning points / branches in the plot are either written or simply pending a brain dump, so this ~should~ get a tad more interesting than your average "Beat 50 levels, run a bunch of sidequests for 10 different people who don't want to go to the dungeon themselves, and fight the final boss thereby breaking the dungeon's curse" mystery dungeon.

* ... . . .  Okay, okay, I'll spill.  Her name's Martha, and in a society where everyone uses magic, she builds robots.  But don't expect to see much plot entering the dev demos until I can create proper dialog and text box classes, which are currently not on the agenda for the academic phase of the project, at least until I have procedural enemies and items working.
