A side-effect (not un-anticipated) of my design change--my switch away from such a pure Diablo-oriented gameplay--can be summed up with two questions. What makes the dungeons in a game similar to Legend of Zelda fun? How can such a dungeon be randomized?
With the original Golem, the emphasis was on monster slaying for loot, just like Diablo 2. There were quests and such, but they were almost tangential to the task at hand: slay as many enemy golems and minions as you can. The occasional key to unlock a door and such usually served only to unlock further areas to loot. Once the technical aspects involved in any random-dungeon-generation scheme are tackled, this sort of gameplay is sublimely suited to random generation.
But the new design steers away from the mindless garnering of loot and power, and seeks to blend some of the quirkier aspects of roguelikes with hack-and-slash, and an almost Zelda-ish style of gameplay and character setup. Fewer items, less variety in the way a character is structured, and more emphasis on puzzle pieces in level design. Puzzle-piece dungeons typically require forethought and design, something which is of course difficult when the forethought and design are completely in the hands of the Random Number God.
This is what I am struggling with right now, in addition to more mundane and easily solvable technical details related to the engine design.
In Golem 1, I made the decision to rely almost exclusively on the random generator for level content, and for those few places where a pre-determined level structure was required, I was forced to painstakingly construct the structure by hand within the generation script. Had I continued the game, I would have been forced to eventually construct a tool such as I am working on now, which can be used to assemble level pieces that can be loaded by the map generator as needed. I hate tool construction and find it to be one of the most boring and tedious aspects of game programming. Having to iron out all the hideously uninteresting details of widgets, windows, buttons and scrollbars is tantamount to standing in line at the DMV. I would just as soon get that shit done with.
But I bow to wisdom in this regard, and certainly a level editor will come in handy. After all, with the greater emphasis on story, there will need to be a more solid feeling of overall structure to the game.
But I wonder if I'm barking up the wrong tree in many respects on this, and I am trying to figure out how I can expand the capabilities of the editor to encompass varying levels of randomness in how level pieces are randomly assembled to make a coherent whole level. I'm thinking here of a recursive approach to random level generation, one in which the randomness can appear at any specified level of the design, and can be excluded from any specified level. Forgive me, but my thoughts are a little scrambled about this (long day at work, very tired), so if I ramble, just ignore me.
Envision a throne room. You might have a long, vaulted hall with a heavy, ornate, grand beast of a throne at one end set upon a raised dais. Gold filigree inlays decorate the floor, and crimson tapestries edged with gold hang in broad, rippled swoops along the length of the chamber. Tall doors open at the far end, polished mahogany carved with bas-relief depictions of ancient battles and long-dead glories. Statues alternating with suits of armor on stands line the walls, inset into shallow, arched niches--forgotten coats adorn gleaming shields clutched in empty mail gauntlets beside cracked and weathered marble figures.
Now, how can that throne room be described such that a large set of similar throne rooms can be generated randomly? The chamber can be viewed as a series of detail levels. At the first level, there is the chamber itself. Dimensions, shape, rough location of main elements--these are the areas where the randomization can occur at this level. I need to be able to essentially choose a main floorplan for the chamber, that locates the throne, the doors, any hidden doors or stairways, rows of columns, etc... The details are lacking here; all we have is the general arrangement.
Then, for each detail, we recurse. For the throne, we have a number of options. Alternatives for the actual chair to use, alternatives for the base or pedestal upon which it stands. We can further recurse into the chair or throne itself; is there a hidden compartment within the base? What does it contain? Gold? A switch to open a hidden stairway? Is it trapped? Each level presents us with choices and the opportunity for randomization of those choices.
How about the statues in each niche? What should their appearance be? Is the armor they wear useful, or is it merely for show? Can a particular statue be moved to reveal a secret passage?
And so it goes. I need to be able to specify any given room in terms of a recursive ruleset, while reserving the option at any given level to have only 1 alternative for any given detail or selection. If there must be a secret door behind the throne and there must be a switch inside the compartment beneath the throne to open it, then these features need to be generated regardless of the selection of the other details in the generation tree.
I was on my way to painfully hammering out a system for this sort of thing with Golem 1, until I derailed myself. It was for this exact level of flexibility that I initially opted to not build a custom level-piece editing tool. I really had no idea how to build such a tool, and I still don't. A simple level editor is easy--you lay out the landscape and add details. But in a recursively defined random feature, you can't just throw down some tiles and start stacking in walls, since you can't limit even the shape of the room. Such an editor, then, wouldn't work with tile placement as such, but rather as a ruleset editor, and if all I'm going to do is work with sets and tables of rules, then why build a tool? Why not just do it as I have been doing, and build the rule tables into the level generation script? I like the free-form, typeless tables of Lua or other dynamic languages for work such as this. For each level of detail in such a room, I can construct a table object that maintains the rules for selection at that level of detail, and can store state that is solidified as choices are selected.
I don't know, I'll have to think about it some more. At any rate, I am constructing at least a simple level editor, for it is likely that there will be some levels that are always the same, and have no randomly generated aspects.
Dug through some dusty old backup CDs from many years ago, and found one of my very early attempts at creating an isometric animated character. I drew this guy by hand when I was 15 or so. I thought it might be good for a laugh.
Pretty awful, huh?
