Skip to content

February 15th, 2015

February 15th, 2015 published on

As it turns out the solution to the new generation was to simply expand the existing system further. Much like how node tags have rules describing how they should be generated to create more interesting patterns, I added two new pieces of data to represent interesting patterns in the world shape as a whole. The first one is that of Area. Area basically describes the entirety of one difficulty rank (for reference there are currently 3 ranks in a single game). Doing it on a per rank basis makes it easy to set it up so that further ranks can have longer or more difficult patterns. It’s also important because certain world shapes are more interesting than what would tend to happen naturally (for instance I like the pattern where the map starts with several branches, then has a section with no branches, then returns to several branches- the middle section having no choice serves as an interesting melting pot of gathering the players together at the mid point)

2015_generation

Then comes segments. Segments represent the entirety of a single map branch. In a lot of ways segments are secretly just probability charts for the players to consider. Having partial control over the patterns allows for stuff like “make all of this section’s positive tiles gold gain”, and “front load all of the negative tiles at the beginning” etc. Segments rely on node tag categorization to make broad generalizations such as “positive tile” or “major negative tile”, rather than specifying exact nodes themselves. Naturally the final phase is the same as it was in the previous generation system (essentially just picking a random node within a tag set whose constraints are valid), just applied to a smaller space.

It’s all really simple now that I put it out here, but much of the week was spent dealing with thorny issues. One such issue was how to apply gradual difficulty transitions across the map. Doing a transition mid-segment would result in imbalances of how a segment was designed (ie the negative tiles might end up as lower difficulty than positive tiles, making that segment too good). Eventually I settled on making the length of segments directly correspond to the length of difficulties. Consequently any extra long segments have to be built with the knowledge of when their difficulty will transition, so they won’t be designed in ways that promote imbalance.

There’s a lot more complicated additions the new generation system will need for stuff like lock/key nodes, but right now I’m just trying to get a basic version up and running so we can tell if this style of map is even worth generating in the first place. I kind of have a bad feeling about writing a generator before being certain of what map structures play well, but in theory the system should be able to adapt to any changes (of course that’s also what I said about the single worst waste of time of this project that was one of the previous generators).

Dependency

Dependency published on

This week’s big issue revolved around zone pathways. Last week I showed off this theoretical image of how to place zones in a grid, but offset the position of the node to create an illusion of breaking up the grid:

newzone

 

 

 

(it’s worth noting that the top middle witch hut isn’t actually a valid position in this image)

 

As it turns out, actually competently generating this is something of a chore.

choices

 

 

 

 

 

Red lines represent the different points that roads can come from.

 

 

 

 

 

 

 

In this system locations are composed of 3×3 tile squares, with a single tile buffer between them  (4×4 and up aren’t really viable due to tile size relative to screen size). Being a grid, there can be one roadway coming in on each side. Our road system isn’t sophisticated: the presence of a two road tiles next to each automatically connects them- no independent roads that are adjacent but going in different directions. The ultimate goal is to place the node (a town, a dungeon, etc) in a location such that every roadway uses it as the crossroads so that the pathways between zones are visually clear to the player: therefore each roadway must not touch another or it will create a second crossroads. With only one or two roadways, the position of the node can be anywhere within the grid. Once you hit 3 roadways, certain node positions are impossible relative to the roadway positions. At 4, every roadway needs to directly intersect.

choices2

 

 

 

 

 

 

 

 

The problem this creates is interdependence between every zone. A zone with only 2 connections, one of which has 4 connections, must place one of its roadways based on what the 4 connection wants. With enough 3/4 connection zones present, it ends up with a fairly uniform placement despite the effort to do otherwise. It’s also a pain to process when altering one zone can have ramifications on all of the others.

So I dropped it. Because it’s not that important relative to the amount of work it was going to take. And went for total uniformity:

newzone2

 

 

 

 

 

It looks alright. It’s also slightly more readable than the version with offsets. There may come a time to improve the look of it. That time isn’t now.

Map Readability

Map Readability published on

So this week we got to do a play test for the first time in several months. Play tests are probably one of the few morale boosts this team has, one of the big advantages of making a multiplayer game. I also noted that my productivity went up like crazy the day before the test because I wanted to fix up various things before hand. It’s always hard to artificially make dead lines for yourself that feel real, but scheduled weekly tests are surprisingly effective at it. The core focus of this test was to see how the new zone movement felt in action. I was a little worried about doing it before the new quest systems were added since the old system is pretty incongruent with the new zone movement. Nonetheless I think we got some important feedback on the movement itself.

Sew was confused about zone movement throughout the test (actually, pretty much everyone was, including myself). So much so that he actually created metaphor of country borders for zones so that he could understand them more easily (which is actually a pretty great way to explain concept):

sews-node-question-map

 

And really, who wouldn’t be just look at this mess:

generation

For awhile we assumed that it was largely an art issue- a big ol’ jumble of objects not intended for this purpose. Sew had even mocked up an example of a better way to display them:

 

speed-zoning

But Sew found that even with a simple mock up of color coded zones the layouts were still a jumbled mess to interpret. Even besides being messy he also had a feeling of exploration not being as satisfying as it was in the old system (even though the discovery system of not revealing a zone’s connections should have improved it over all). The only thing he could point to on the feeling was that maybe the zone walls made it feel claustrophobic. I suspected that the readability was actually the problem- it’s hardly satisfying to grope around a space that you don’t really understand the physicality of. He then suggested perhaps moving to a node/road system:

this-is-what-i-cant-say-with-words

 

Back during the zone planning I had considered switching to such a system. In fact, the zone system was even  going to be retrofit to adopt it. But that turned out to be unfeasible due to the nature of 4 directional roads contradicting zones supporting many more connections than just 4. The zone system would either have to be awkwardly forced to stick to certain connection limits, or (for better results) scrapped entirely with a new style of generator. So I went with the existing zone system, figuring that adjacent blobs would be more readable than having to trace complicated roadways anyway.

I told Sew that I thought such a system still had readability problems from the complicated roads with multiple crossroads with a cost of 1. He then inquired about how I felt about board game style movement, which the node/road system is very similar to. My thought that such games might look complicated to read, but are actually very simple to navigate since there’s only a hand full of points where the player make an actual movement choice, and most of the time they’re forced down a specific route. It was at that point when I realized where the actual problem was at: most board games either use very limited choose-a-branch movement or a direct grid. And the reason for that is readability: in either case players can take a quick look at the map and infer the distance between points without ever having to trace pathways- with a pure grid it’s as simple as the distance between points.

So it has become clear that I’ve been trying too hard with the idea of naturalistic map generation (that largely looks the same in execution anyway- a big mess). The solution I’ve come up to address the problem is to effectively snap zones to a grid of squares. So while in essence the game map is just a tile based grid (with zones acting as very big “jumbo” tiles), the tiles within the zone allow for some internal variety to create an illusion that it isn’t as much of a grid as it looks. Here’s an example of a map operating off of a 3×3 grid:

newzone

 

 

 

 

 

 

The graveyard is at the center of the grid, even though it may not look like it is since it’s placed at a far right offset within its zone. With this set up we hopefully combine the readability of a grid with the visual allure of a landscape. Sew’s happy that it doesn’t rely on walls or biome tiles. I’m happy that it’s the simplest thing to convert the existing generator into. We’ll find out whether it actually works next week!

Look Ahead

Look Ahead published on

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

Mutually Assured Generation published on

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

Final Zone Lap published on

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.

 

Bugs & Battles

Bugs & Battles published on

So the 3 basic shapes- loops, planes, and linear branching paths have been successfully implemented. Despite their simplicity, the zone generator really wasn’t built for their rigid generation (after all, it was designed for big chunky zones and not so much the smaller ones the node system revolves around). Over the course of implementing all 3 the system got built around the idea of rigidness more and more- the loops started out as a giant hack, but as the plane got completed the necessary infrastructure sort of naturally fell into place. You can see here the updated loop system that allows for post processing generation and variable segment sizes:

loop

 

I had hoped to then continue on to actually placing locations and connecting them with roads, but two bugs cropped up that prevented it. The first one is our good friend the ocean hole:

impossible

 

The test cases only involved 3 zones total so a 4+ zone hole didn’t really crop up. It’s basically impossible to fill this hole without fundamentally changing the zone links. The fix is mercifully simple, we’ll just fill the hole with another mountain (or whatever is being used as a zone edge in the area). Decorative and shouldn’t cause any problems.

The next set of problems stem from undoing zones. Sometimes a zone being generated just doesn’t work out- there isn’t enough space, it can’t connect to what it’s supposed to, etc so it needs to be erased- including all of its zone edges and links. Support for this has always been flakey and it finally began to surface with the more complicated terrain. The first glitch was just visual edges being placed where they didn’t belong- a simple problem with the edge display being tacked on debug stuff that I didn’t think through and was easily remedied with placing it the same time as the walls get generated. The second problem was with stranded non-zones:

stranded

The problem seems to stem from an adjacent zone getting undone near them, which ends up deleting their edge connection data as well in the process. Probably won’t be too hard to fix, but I didn’t have time to complete the process before this blog post.

Battle System Blues

battles

Since before starting this blog we have been in the second phase of this project. The first was to get the fundamental stuff playable if unrefined, this second phase is to make it fun, and the final phase will be to make it feel and look right. The game has two big fundamental components of the map system and battle system. So far we’ve been focusing on the map system revisions, but with its new theory in place and just tech remaining I’ve shifted my design attention to the battle system component. The battles are traditional console RPG turn based, not tactical movement or whatnot. A decision that keeps me awake at night since turn based games aren’t terribly popular at the moment, and king of the unpopularity totem is the turn based non-tactical RPG. So clearly making a multiplayer version of a traditionally single player genre that is incredibly unpopular at the moment is a great idea to bet all of your horses on. Popularity as it may be, it’s pretty much the best possible battle system for a game that’s trying to recreate the feel of an entire RPG in a single hour because it has the capacity for taking a minimal amount of time, and allows for a greater abstraction of world scale than an action RPG would.

The two topics I’ve been worrying about lately are player progression, and actual battle execution. While I’m quite confident in the basic turn based you-hit-them,they-hit-you structure, I’ve spent a lot of time thinking about what commands the player actually gets to choose in such a battle should be. The traditional mashing the attack command structure won’t really hold up here. Typical tricks such as elemental weaknesses and gimmick battles also falter in a game that is built around being replayed again and again. It also needs to have enough strategy to not have player vs player battles be determined entirely by who has the best stats. I had formulated an incredibly complicated system that succeeded at a lot of these factors, but ended up being poor for fighting against AI even on paper, and in general not being as pick-up-and-play as I’d like.

Right now the idea I’m toying with is trying to employ some of the strategy that a tactical RPG gets from positioning into the system without actually having positioning. Something like having using a particularly strong attack makes you more susceptible to damage in the next turn, to re-create the sense of positionally diving into enemy lines. I haven’t fleshed out the concept yet.

Presently most character building in the game stems from players individually purchasing skills (with a limited total per player), and equipment to build a sort of custom character. It sounded nice on paper, but skills don’t really have enough interaction between themselves on the same character to make purchase choices very interesting (it also suffered from skills being too expensive and potentially weak to bother purchasing).

So now I’m experimenting with the idea of “class packs”. Essentially at every milestone level (starting at 1, with a total of 3), players would get to choose between different class packs. Class packs would include various skills and stat gains they’d get at certain intervals. This is much more interesting since not every skill/stat boost in the pack would necessarily be beneficial- players would have to start making trade offs for certain advantages. It also isolates player build thinking time down to just 3 points in the game instead of throughout the entire game, hopefully trimming down turn time. As a final bonus, it makes level ups more exciting since players might be waiting for a certain level up to finally get a skill that they’ve been wanting. It still allows for some customization on the player’s parts since they can mix and match 3 class packs, and the available skill packs can still be randomized each session for some variety. So far I’m digging it.

 

Next week: Fixing all these bugs! And then placing locations down finally.

Loopers

Loopers published on

With the new map systems designed, I started doodling sketches of possible maps to decide how to generate maps with the new style. Since everything is node based I could have mapped out the sketches to allow for 5+ node connections something like this:

doodle1 Roads represent node connections. (does not actually contain 5+ node connections)

But pretty quickly settled on 4 node connections max for the sake of clarity in-game. I was actually heavily considering a tile-based representation of the nodes like this to be used internally:

doodle2Not represented in these doodles is that not every node need be connected.

With a system like this the number of nodes a node is connected to can be discerned at a glance just by how many roads are coming out of it in each of the 4 directions. It wasn’t until later that I decided to just use the existing zone generator, simply because the tile-based style would take more time.

Under the tile based system I basically decided upon 3 common map patterns that seemed most useful to generate off of:

Linear Branches

branches

 

A very simple system. Primary, long paths are generated. Off of them smaller, also linear branches are generated. Creates a sense of peck and hunt. Most player traffic gets focused on the long path, while going down the shorter paths creates a sense of searching.

 

Planes

planes

A whole bunch of 4-way connection nodes clustered into one area. Players end up relatively close together most of the time, and it’s a bit of a slog to get to the extremities.

Loops

loops

 

A classic board game layout. You’re either going one way or the other most of the time.

 

There’s not a whole lot of deliberate map design with just these 3 patterns. When’s the right time to use a loop? a plane? I don’t know yet. Just slap ’em down randomly and make sure there aren’t too many node jumps from the town. The placement of specific nodes has a little bit of thought in it: dungeons should block out further areas, healing fountains shouldn’t be too close to town, etc. For the time being this will have to be sufficient. My main goal is to get a basic generator up and going in order to have sample data for the rest of the new systems to work with. Maybe it’ll be good enough, maybe it won’t. I can build upon it later.

So I moved on to adding these patterns to the existing zone generator. And immediately ran into a terrible wall: the zone generator was never really meant for patterns as exacting as the loop, which requires zones to placed in a very exact way such that the final zone in the chain will connect with the origin zone. All the zone generator every really cared about was creating a zone off of the side of another zone, and allowed for a tremendous amount of random drifting. For the time being the fix is to place down guiding zone lines for each zone in the chain and disallow the random portion of the zone from spreading beyond the line:

loop_reality

 

This makes for way stiffer zones. There are various ways to diminish the effect- make it so the line lengths are distributed differently between lines (ie, for a total line of 6, the individual zones lengths could be 1,3,2). But right now I don’t really care, it makes it more readable anyway. The other problem is that it only really supports loops that start and end on the same node. Creating a double loop isn’t really available yet in this system. The short comings of the zone generator have come home to roost. The code changes required to make this work were incredibly nasty as well, and I am at a loss for a better way to do them.

Next week I will probably deliberately ignore the shortcomings of loops and implement the other two (much simpler) patterns and start generating the actual nodes and their paths and maybe rebuild the movement system for node movement I don’t know we’ll see.

A Tour of RPG Level Design

A Tour of RPG Level Design published on

Being that the end goal of the project is to create a multiplayer RPG that evokes feelings of single player RPGs, it seems prudent to look at level design applied across the genre to see how they evoke the feelings they do through mechanics. It should be noted that I’m largely describing the stereotypes of the design types, and that any given actual game probably breaks these convention in one way or another.

Dungeons

Dungeons are the key obstacles in an RPG. They present a space the player must conquer in order to progress in the game, either for character progression or for plot progression.

Designer Maze

The type of dungeon you think of when someone says first person dungeon crawler, possibly popularized by the novelty of 3d on early computers. There’s usually multiple pathways through the critical path in this style of dungeon. This creates a certain pattern of exploring simply to find the critical path and to understand the layout of the dungeon. Due to the size of the dungeon there’s also an expectation to backtrack to a safe point for recovery since the dungeon is almost certainly larger than the player’s total endurance. Backtracking can take the form of checkpoints (in the case of one continuous dungeon), returning to the beginning (in the case of multiple dungeons), or opening shortcuts at critical points. Traps and puzzles adding unpredictable resource consumption are also hallmarks of the style.

Open Maze

The style typically seen in roguelikes, both traditional and action RPG variants. In this style there’s only a single critical point of down stairs to the next level. As such, many of the rooms are technically unnecessary to progress in the dungeon. Most players will explore all of the rooms thoroughly for the sake of additional experience and treasure. Safety points often don’t exist at all beyond an option to rest after clearing a floor or room, making the focus on a constant plunge forward rather than a careful back and forth.

Linear

Evolved from a greater emphasis on story telling in jRPGs since it allows for a finer control over pacing, but now not uncommon in western RPGs as well (and really, most story focused games today). Characterized by a straight line to the end of the dungeon with various optional off branches. While functionally a straight line, a well designed dungeon will mask it with twists and turns in layout as well as shifts in scenery. Often designed as a straight shot for the player, but earlier instances were still designed for backtracking for resource replenishment.

Overworlds

Overworlds are the connective tissue between the other areas in an RPG. In some cases they exist mostly for context, but are quite capable of offering their own spin on exploration. It’s also possible for the overworld to merely be a set of menus instead of a physical space to move around in, but the differing styles can just as easily be mapped to the menu (although directed is the most common use).

Open

Pretty much what it says. In this form the player is dropped somewhere in the world, probably next to a town, and told to figure it out. Direction might come from NPCs, or it might not come at all. In the elder form this basically turns the game into the player fishing around for new areas and deciding whether they can take it on yet or not through experimentation. In later years it became more popular to scale areas to the player’s current level, draining any importance of discovery out of the game for the sake of freedom.

Range

Similar to the open model, but in this case the player merely unlocks a chunk of the world at a time as the plot progresses. The player has a smaller range of places to discover, but still has to contend with figuring out which ones are viable for their level.

Directed

Range scaled down even further to make it so that the player typically only has one or two places to go next. This makes it easy for the player to progress in the game while lending geographical context to the world. A common practice is to unlock access to several areas at once when a key part of the plot is met (ie, getting a vehicle). These areas are typically optional, or have a flat level requirement in order to make it safe for the player to pick and choose.

Towns

Towns might be one of the most varied components of the genre. In a lot of cases the mechanical exploratory element isn’t really present, creating to-scale areas where the player must simply wade through to the correct vendor or quest giver- either through a map, pointed to them directly, or even reduced to a menu. NPCs might have unique text boxes for themselves, entire dialogue trees, respond only to keywords based on type, or be largely non-interactive. I’m not going to cover all of them in detail since they’re not especially relevant to our game.

The one form I’d like to highlight for its exploratory elements is that of the hint NPC town. This is a town where the player isn’t strictly required to talk to any given NPC, but doing so will uncover directions to the next area, hints as to what enemies it contains and how to deal with them, and reveal what’s going on in the town. As such, talking to all of the NPCs becomes a sort of investigative research game. Once the idea of key NPCs came around, NPCs required to push the plot and who generally gave exposition dumps to the player about the new area, the hint NPC form started to erode. With the key NPC telling the player what’s going on anyway, dungeons becoming safer, and overworlds simpler the key functions of the hint NPC were quickly forgotten and they devolved into vestigial flavor text that no one wants to read.

—————————————

Throughout most of them there’s a common theme of endurance and discovery. Endurance because travelling typically incurs resource expenses on the player, some times requiring them to make judgment calls of when to walk back to safety. This lends weight and importance to travelling. Discovery because exploring the space is often required to know how to most efficiently use resources. This fleshes out the locations and lends them a sense of place beyond the flavor text and artistry. Most comfortingly, it shows that there’s a wide variety of ways to invoke similar feelings in players. My job is to figure out how to compress it all down into an hour, and allow multiple players to partake in it. Not the easiest task in a genre often defined by its length.

So here are a few different problems I’ve been tackling this week:

The nature of multiplayer exploration

 If you want to be reductionist, exploration in games pretty much amounts to picking a random direction and seeing what’s over there. This is perfectly fine for a single player game or even a co-op multiplayer game since the player can eventually get around to everything. If they pick a direction that’s too hard for them or has no reward in it, it doesn’t really matter. Finding that out was still entertaining, and they can pick another direction at their leisure until they find something useful. This pretty much falls apart in a competitive multiplayer environment immediately. Discovery opportunities are finite, another player finding something cool while the others don’t sucks the joy out of the process and it becomes more like advantages from luck. Even if you don’t care about balance, it still damages the joy of the process when players are focused on what someone else found.

The simplest solution is to make sure every corner has something of equal value. This also basically destroys any of the interest. You can mask the balance by delaying the reward- ie, one spot gives a key to get something even better from another spot. This distracts from the sameness, but doesn’t really improve it. You can apply the philosophy that every reward requires an equivalent challenge to gain, but this still requires a certain amount of sameness so that one player doesn’t find a challenge too hard for them while another finds several at their level. A little more direct application of that philosophy is to make it costly to uncover new land, and consequently unearned rewards are acceptable. These are all workarounds, the fundamental idea of exploration simply seems incompatible with fair competition. But they might be enough to create the illusion.

 The Tyranny of Turns

Let’s assume that the average length of a turn is 30 seconds (attempting to take into account short simple turns and long thinky turns). Now let’s assume the target time for a game is an hour. That gives an entire game about 120 turns, or 30 turns per player in a 4 player game. That’s not a lot of turns, and it gets even worse when you account for the number of turns probably spent inside a battle. It pretty much puts backtracking out of the question, and makes even the choice for 4-directional movement questionable. This is pretty much where I’m sitting, trying to figure out how to make each turn significant enough to give scale to the game within the limits.

For the next week I’ll continue to mull these and other design mysteries while perhaps working on some refinements to the game proper such as, I dunno, an options menu. The design phases of this project are incredibly stressful on me since you can’t really force progress and we’re working under a tight time limit, which is probably why I keep putting them off.

 

 

World Generation: Edges Complete

World Generation: Edges Complete published on

yay_oceans

 

As you can see here single edges with proper ocean hole detection was successfully implemented, pretty much finishing up the basic building blocks of the new world generation. You might be asking, “what is ocean hole detection”. Since the map generator fills in land by moving a cursor tile about randomly, there’s a chance for unclaimed ocean tiles to end up residing inside land masses. This isn’t really desirable since beach edge tiles take up a lot of space, so at the end of generation they’re searched for and filled in with land.

This was pretty simple when the map was composed of just ocean tiles and land tiles (find isolated ocean tiles), but the addition zones and edges made things a little more complicated since edges are neither ocean nor land until they’re next to another zone. It also added a secondary purpose for ocean hole filling since redundant edges were possible during generation:

redundantGreen is zones, yellow is edges.

While it was perfectly reasonable to leave the far right edge during generation, in reality it’s not a practical edge of anything- it’s surrounded by its own zone. As such, it’s the same thing as an ocean hole. Detecting redundant edges is exactly what you think it is: if you’re surrounded by other edges and are only adjacent to one zone, then you’re unnecessary and thus considered an ocean hole. A special exception was made for edges bordering the ocean, to prevent ocean rivers leaking into zones excessively.

Originally the ocean filling was run on a per-zone basis but this lead to a tricky edge case:

hard holesMountains denote zone borders, white mountains/caves/graveyards represent different zone’s edges.

If you ignore the bottom and left zones and consider the top right zone’s existence it made perfect sense for that edge to be where it is- it was just ocean there after all. But when the bottom zone was generated and it created an ocean hole, it was impossible for it to claim that tile- it was surrounded by the first zone’s edges. The first zone could fill it, but it had already been processed. The fix was to simply process all ocean holes for all zones at the end of generation, letting whatever logical adjacent zone fill them in.

So then I finally moved on to some proper level generation. This is a very early sample of generating a central town zone and then creating 3 linear paths off of it. At the end of one of the paths the next central town zone would be generated (not pictured) which will then create its own linear paths, and so on.

yay_paths

The generator basically consists of pre-made things called zone generators. These things create zones in specific patterns. In this example there’s the Linear Path zone generator which continually creates a certain number of small new zones in a given direction. The other is the Town generator which simply creates a single small zone.

In order to make more complicated patterns out of these, each zone can be given a deferred zone generator. So the real crux of this town generator is that it contains a populator component. The populator component is told to place a single town object within the zone, making it a proper town zone. Not only that, but the populator component can also place down a few Linear Path deferred generators on the town zone, so on the next pass of generation the linear paths will be created off of it.

In layman terms this level generator is ran by a magic gnome that can make land. After making some land, the gnome can plop down work orders for the next set of gnomes with instructions for what he wants built next to that piece of land. The next set of gnomes can do the same thing, and the process goes on until the gnomes are satisfied with the world.

This is all well and good, but now that it’s time to legit produce some level designs I realized I never really put down proper plans for the new world. I had a lot of scribbled ideas for what can be done and how it should be done, but not a concise plan. So get ready for an exciting adventure in game level design this Sunday.