Context

There was a point several months ago when I was building the quest system for the game and I noticed that all of the objectives I was making were pretty bland (the quest scripting system is comprised of objectives and actions- things a player needs to do, and the actions that happen when they do them). Go there. Kill that. And so on. It brought me back to when I was looking at randomly generated quests in another game and I immediately dismissed it as silly, since they were reduced to “Bring me <x> of <y>”. Which cuts to the point: the objectives of quests in RPGs have ALWAYS been silly things that happen to fit into the game part. Even your most story heavy RPG out there still boils down to “clear this dungeon to hit the next plot beat”. What makes a quest interesting isn’t the objectives themselves, but the context that you’re doing them in.

It’s a pretty obvious statement, but apparently I had to remind myself of it. When I was in a rush to write the existing sample quest I made some pretty obvious mistakes. There’s several plot beats where the players have to go somewhere to get some information. The places end up not mattering to the main plot arc. Sometimes they were short stories in of themselves, but not always. It took me a little bit to realize why they felt so off: because they were irrelevant to the primary story. Many of the existing side quests had similar problems, of me slipping into a mode of being sarcastic and dead inside and making them simple chores with excuses instead of tiny little stories.

It’s an easy thing to forget. And it’s not always just from the context not being present. MMORPGs have suffered from this for years: partially because they’re multiplayer, partially because there’s too many quests to make them all interesting, partially because players have no power over the world, and partially from how¬†they deliver context. Take a look at the current standard for MMORPG quest dialogs, the World of Warcraft “here’s a bunch of text in a small scrolling window with an easy access button for accept so you can quickly and conveniently completely ignore it”. It makes no effort to simulate a conversation. It’s built so you can easily skip it. There is no need to read it because any required information has been folded into an automated system. It is only there to theoretically please the segment of the audience that demands it.

So I guess you want to know how the code is going. It’s going pretty good. You can walk around node style and such like now, but nuances like how traps and battles are triggered requires further work since the original system wasn’t made for how it works here.

Look Ahead

So generation is finally largely complete. There will undoubtedly be further changes to it to mesh with new art assets, thicker walls, and adding logic for new place types and all that. But fundamentally it’s done. You can see a sample of the results here:

generationRed/grey mist indicates higher difficulty. Volcanos/Castles/Towers are dungeons.

The logic behind placing dungeons (essentially boss encounter areas) was fairly simple and basically involves sets of contiguous zones being generated from the existing world data. The first set is special and is generated from the town and spreads about randomly, creating a safe haven with a certain number of zones for low level players. Additional sets are generated off of the first set or other sets and traverse through the map looking for passageways that introduce as few openings as possible, since a zone set will generate two dungeons to fill up entrances at most. If a zone set is completely blocked in by other sets, it simply generates its dungeon randomly somewhere within it- ideally blocking a zone or two (a process that still needs some tweaking when you’re only working with 4 zones total most of the time).

So I feel pretty good about this because it means there probably won’t be any more major systems that will need massive additions to them, other than an improved effects/animation system. But I also feel really bad because looking back at it, this entire zone system thing was not necessary for the node system and I just wasted over 2 months of work on it. It offers several advantages in terms of being able to visually display a single area containing many things, sure, but that is not such a vital feature as to dump all this time into it (especially when it’s going to increase the load on the art department). I’d say this whole working-without-the-entire-design thing has worked out pretty well considering the dangers inherent, but this entire generation chapter shows me getting a little too relaxed with it- I should have decided upon the design before coding an entirely new generation system for a problem that was going to change radically from the design shift. It’s a valuable lesson that will not be forgotten.

Mutually Assured Generation

This week ended up dedicated to the last phase of generation, placing places. And it really didn’t need to be.

You see my original plan to integrate zone generation was to simply place the single tile location inside the zone and then have roadway entrances lead to it. I figured in the future I could even place additional tiles around the zone to give visual indication of what the location contained. You can see an example of this here:

 

problemo3(ignore the caves, as they are debug markers of zone entrances)

From a player’s perspective, though, they don’t really see the zones. They see the roadways. And in cases like this, they get the misleading impression that the volcano leads directly to the swamp. But it doesn’t. So I wracked my head for viable solutions for most of the week (when I wasn’t fixing glitchy zone borders, anyway). And there aren’t any really:

  1. Make more expressive roadways (terrible visually, for artist, and for programmer).
  2. Don’t generate zones where the location cannot be the crossroads for every entrance (viable, but restrictive and slower).
  3. Just use the zones.

It’s the last one there that’s the final hope. It pretty much means we go all out and place the location objects throughout the entire zone, making it clear. This is an example of it using existing place objects:

example2

Naturally in practice this would mean having a variety of graves on each tile in a graveyard, or to place a variety of houses in a town zone, etc. Sew has gone on to suggest that we’d replace difficulty terrain types (lava, snow, grass, etc) with zone tile types (dead earth for a graveyard, etc) to make the connections stand out. But before we commit that far, we want to actually test out the node system and see if it’s worth using. So that’s where my goal is, marching onward to largely use the old stuff while altering the movement system to the node stuff. And terribly behind schedule.

There’s just one last task in generation. Dungeon placement. The original plan was to just place dungeons down in areas with a single connection and then mark them as high priority for future generation (hence creating areas that they blockade). This system, however, doesn’t work very well with the shape system in place since it can generate several zones at once for a single shape, eating up the zone budget dramatically. So now I’m pondering some sort of system that looks for choke points and places dungeons on them. I just want to be done with generation.

 

Final Zone Lap

I started looking at the remaining time this week, and drew up a schedule to follow. I then proceeded to immediately miss all of the excessively aggressive deadlines. The goal for this week was to wrap up generation- not necessarily the pretty stuff, but to complete it sufficiently to begin pursuing the rest of the new map stuff. It’s incredibly difficult to extract much of any topics of interest from this week. But in the order than they happened:

Fixing the previous bugs

stranded

You might recall this bug from last week, zones not getting their wall edges when part of their generation chain hit an error and got undone. Turns out the problem is that the remaining zones weren’t getting passed to the wall generator on account of the error, and they didn’t get undone from the error either. A simple fix of actually undoing failed generator chains.

Adding new generator constraints

The area generator for a single town basically needs to deal with two constraints: Don’t generate more than X zones, and don’t create a single zone chain longer than Y zones from town. I ended up handling these constraints by having the various generators take in the maximums relative to the current zone, and estimating how much their generator would take up- continually lowering the parameters until they’re either within the limits, or letting the master generator know that this is impossible. It also required adding the calculation of distance from town- not complex, but yet another pre-requisite to add to the work load.

Generating multiple towns

Required some heavy repurposing of the generator to basically iterate over 3 generators 3 times: Create town border, create town, create town area. Had to jump through some hoops to get it to let each town subzone know which town it belongs to to calculate distance, passing a different element to each zone generator, etc. This also revealed how completely inadequate the existing generator was at dealing with impossible generators when this many zones are present (generation could take several minutes). Optimization was quite simple since I hadn’t put any effort into it prior, mostly just making it recognize impossibilities much faster instead of having it hit its head against the wall. This phase also revealed a glitch in the zone shape generator which wasn’t validating that a new tile was actually adjacent to the existing zone.

You can see the fruits of the labor here:

multitown

 

Looks a bit like a random, garbled mess at the moment. But there IS logic behind it, and it’ll start to make a lot more sense with proper locations, roadways, and variation to show off the underlying layout logic.

Next week I hope to finish out generation by placing locations, roadways, and allowing for dungeon lock generation (Essentially, dungeons “claim” their own portion of zones, and their sub-zones shouldn’t connect to other zones without placing another dungeon or some other form of lock). From there I’ll move straight into implementing the new node based movement system.