Skip to content

November 10th, 2013

November 10th, 2013 published on

Ah! Have we hit this point already? Yes, only 2 things done this week. But still on schedule since I was ahead last week. We’re entering into the rough patch here. Almost every thing left on the list involves significant UI work, significant changes to multiple existing systems, or large amounts of content to be both designed and implemented. If I were betting money on it, I’d say next week is when things will truly get off schedule.

Some of the work this week was about revising how rewards were dolled out. Previously enemy experience and gold were manually specified by hand to the specific amounts. What this led to was looking up a chart of appropriate values for different levels and tweaking based on how hard the enemy was relative to its intended area. One of the changes was switching to a reward level system- ie a level 5 gold reward results in 50 gold. Selections are still made relative to how difficult I feel an enemy is by setting its level, but the exact value comes from elsewhere. Now it will be much easier to tweak the reward pacing. Rank is still taken into account (each rank of the world is intended to be a big jump in costs to prevent players from gaining much value from grinding previous areas), so a rank 1 level 8 reward is still less than a rank 2 level 5 reward.

Something very similar is happening to equipment. Previously every single piece of equipment’s stats were manually specified. Naturally this led to a whole lot of looking up a chart for appropriate levels, which then led to clerical balance errors since equipment was in the format of “this style of equipment has versions 1, 2, 3 which are just straight upgrades”.  The new system will simply define an entire family of equipment’s growth across levels- with some options for additional flavor at certain levels if desired. Balance will now be much easier to tweak to perfection, though I suspect more will have to be done to equipment later to make it more interesting.

I was a little loathe to implement stuff like this because this kind of pass-the-balancing-off-to-the-computer stuff can easily go too far. For instance take this once popular (heck, maybe it’s still popular judging from most games these days) perception of how a difficulty curve should look:

boring_curve

The idea was that you constantly want to be challenging the player just a little bit so that they feel like they’re overcoming things, but not so much that they get frustrated and quit. This concept is, in fact, complete bullshit. The end result is that players feel bored and pandered to because the game never gets in their face and tells them that they suck, nor does it ever reward the player for getting significantly better. The game becomes forgettable because no part of it stays around long enough for the player to reflect on it. It gets even worse when you apply it to a game with even the slightest bit of non-linearity because it reduces player options to being meaningless- the cave or the castle? doesn’t matter, they’re both the same! Wouldn’t want you to get stressed and quit because we think you’re too dumb to try the other one if the first one you choose is too hard.

Moderation is key.

 

October 20th, 2013

October 20th, 2013 published on

This was a strong week for design. I wouldn’t describe the first draft of design as done but… the foundation for it certainly is. I would describe the current draft as a big glob of thought processes that need to be extracted into a simpler format. It feels really good to start on what looks like the very first step towards genuine completion of the game. Up until now the project has been dogged by, “will probably change this later” which created a crushing feeling of creating an endless stack of work. Being able to sit down and say, “THIS is going to be how it is” is relieving, even knowing that much of it could end up changing later (but probably won’t!).

The design process has been a little lower level than how I usually work at this stage (but is honestly how any designer probably should work at every stage). I sat down and isolated a primary chunk of the game (in this case, the map and objects on it). I then asked: how does each object affect a player’s thought process in deciding what to do in a turn? The goal being to create interesting decisions each turn where the player’s selection would have ramifications on future turns, allowing for both long-term and immediate consequences. This lead to some interesting discoveries falling out of the process, such as it being more interesting if you make the rewards for an action more explicit (as then the player gets to weigh risk vs. reward, rather than simply picking which risk he’s more comfortable with based on the current situation).

From there it was all about going down the list of game elements, listing out the various ideas for them that we’ve come up with over the years, and weighing the effects of each on player decision making and balance. In many cases it hinged on one style of system invalidating another style of system for a different game element, making the ideal choice fairly obvious in the context of the complete game.

Of course the best thing to come out of this process is that I’ve finally settled on what needs to be changed for the battle system. It’s sort of amusing to consider the evolution of the idea. Early this year it all started with an idea of “to make a minimal turn battle interesting, then each single action needs to have multiple consequences). This started out with an incredibly complicated system that could probably be spun out into its own entire game, which basically made every action have 4-5+ consequences associated with it. It was a cool system, but it had many flaws, including that making a quality AI for it would be too much work and it wouldn’t be as fun to fight as a player (even beyond that, it was simply too big of a game to fit within the rest of the game). Then towards the middle of the year I came up with a system that only had 2-3 consequences associated with it. This remained the leading system for a long time, but I still wasn’t sold on it. Only this week did I finally reduce it to a system where every action has 1 additional consequence to it. And it’s almost certainly perfect. It achieves exactly what we need: adding mind games to player vs player battles, and rewarding pattern recognition in monster battles. The funny thing is that I didn’t really realize what each iteration of the system was actually tweaking until after the fact.

October 6th, 2013

October 6th, 2013 published on

Node generation was smoothly wrapped up this week. There might be performance issues at a later date or something, but I’m not too worried. With that out of the way this week looks to be about adding some new system stuff to handle desired node features. Since they involve delving into some code that I haven’t looked at for over a year, things could get gnarly. After that I get to build some sample objects and begin testing to see how the node system has turned out. After that the “map revision” stage will be drawing to a close with the addition of the trap system. I’m happy with how things are turning out (the generation system I discussed last week in particular), but my anticipation to see how this is going to come together is sky high.

Of course that means the battle revisions are the next big thing on the horizon. After how the zone generation system turned into a waste of 2-3 months of development time, I’m going to be a whole lot more careful about not rushing straight to implementation. If code hours need to be spent somewhere, there’s plenty of work to be done on things unrelated to the core game. Truth be told, I still don’t have a completely solid plan for the battle changes. I do have a text file with pages and pages of different ideas for it, but nothing that feels right yet. Sadly most of the ideas I have gravitate towards character build customization rather than the battles themselves.

But let’s be real for a second. I’m not building two different games and mashing them together here. The two modes have to work together to form one sensible whole. That means one mode might have to be simpler than it otherwise could be in order to give the other mode the room it needs to breathe. The chaotic way we’ve ended up building this game just happens to have landed on me building up more of the map mode than I have the battle mode.

The deeper I get into finalizing the design of the map stuff, the clearer it’s going to be as to what the battle mode needs to bring to the table. Despite already having built most of the map system, I still don’t know where I’m going with it exactly. I know the fundamentals: players get to choose something different to do based on where they are on the map. That unlocks a whole world of possibilities from the number of options it presents to players. Lots of movement order planning, flavor to exploration, resource contesting, and so on. But I still need to nail down the specifics of it all: are players contesting resources for how they get to build their battle character, or are they merely contesting resources that expand their battle options? Stuff like that. It’s going to be much easier to figure out what battles are as I begin to finalize it. Battles will then start to inform the map stuff. Having parts of the system available to experiment and test with will make finding the game much easier than pure theory, as crazy as it may sound to build major parts of a game while having no idea how they all connect.

Big Bosses

Big Bosses published on

Progress is moving fairly smoothly on the node action system. Slowly. But smoothly. Sometimes you get so wrapped up in a thing that you forget where you are. Barring further major re-designs, this node action system is basically the last major piece of functionality that will need to be added. Lots of additional minor systems, stability, refactoring, etc will still remain, for sure, but this is possibly the last major thing! That’s exciting. But there’s not that much to discuss there. So let’s talk about battles.

Random battles are a tricky subject in every RPG. The best that they’ve been done is as an optimization problem- the player seeks out a way to end the battle as quickly as possible using as few resources as possible. Once the optimal battle solution is found the player will stick to the routine except (in a particularly well made game) when circumstances require them to do otherwise- expend more of one type of resource (MP/Items) to get out of it faster to spare a more precious resource (HP). If a game has an exceptional amount of luck added to it, the player is still optimizing as best they can within the luck- doing their best to understand the potential costs associated with a given battle. This is inevitable to any game revolving around throwing the same scenario at the player again and again in a system that is determined entirely by rigid digital choices. Things start to go sour in such a system when a battle is thrown at the player too frequently relative to the number of times it takes to fully optimize it. Repeating the same optimal attack pattern can get tiring very quickly.

The problem I’ve been facing with battles stems primarily from one thing: non-boss battles need to be done in 2 turns to keep up the game speed fluid, which means I need to find a way to make a 2 turn battle interesting. An endeavor which has been largely hopeless unless you vastly expand or otherwise mess with the pool of available options per turn (ie, shuffling them like a deck of cards or something).

Which I guess leads to an inevitable conclusion: Why not drop the regular battles entirely and just use the saved time for more boss battles where the turn count is high enough to allow for strategy? Hitting the resource consumption part of regular battles has always been shaky in this game since even regular battles can’t occur often enough to really drain the player all that much. It’s even worse in terms of stopping players from entering areas too high for them- at the moment I’ve been using a clumsy hack that dramatically increases the encounter rate in areas that are too high for a player to create a “are you even strong enough for this place?” check. Instead it may be better to abstract the resource drain of random battles entirely to just happening. I don’t know the exact form of this abstraction- a simple HP drain + exp gain per tile walked might be ok, but there’s probably something more interesting to do it with. It’s a good line of inquiry to start walking down.

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!

Context

Context published on

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.

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.

The Continuing Adventures of Maps

The Continuing Adventures of Maps published on

So I’m sitting here with a fresh finalized version of the map design. Let’s take a look at some of the harder decisions of the week.

 

Movement

By the end of last week’s entry, it had become apparent that our current system of grid based movement just wasn’t going to work out if we wanted to hit our goal of 1 hour long games. It allows for too many empty turns, and lets players get too far away from each other. Some tighter map design would fix this to a degree, but more drastic measures were needed.

movement

This was probably my biggest mental block on designing this game. When simplifying things down for the sake of time, it’s very hard to find the right balance of not destroying the original feel by going too far. I was resistant to admitting the change was necessary, last week wasn’t the first time I made a rough turn time calculation. Once I finally started to flesh out the available alternatives, I finally felt comfortable about this project for the first time in a long time. I’m pretty sure I’ve finally found what we were looking for.

nodesEach dot represents a node, each line a pathway between them.

The new method is that players move solely between points of interest “nodes” (towns, dungeons, wilderness,etc), rather than individual tiles. I then started at pretty much the opposite extreme of the previous system: players could move to any known node on the map in a single turn. This was a bit much since it basically destroyed any semblance of danger on the map and allowed players to attack each other from anywhere. But going down to a single node hop in a single turn really wouldn’t be a significant improvement from the old system, either.

What I’ve settled on as a solution is the stamina system. Players have a stamina meter with a cap on it. Each point of stamina allows them to do a single node move, and they gain 2 stamina each turn. This adds a certain layer of strategy to the proceedings since players can decide whether they want to use every drop of stamina as they get it, or to save up for a single massive movement when the situation calls for it. With this in place players have significantly more mobility than before, while still allowing some importance to how deep they decide to tread. The exact numbers will probably call for a lot of tweaking, but I think the fundamental system strikes the right notes.

Endurance

The old system used empty tiles for random battles and traps, creating endurance costs for moving around. Since there are no more empty tiles, something else had to exist to create danger in the world. The obvious substitute was made, with every node hop increasing a battle gauge which triggers a random battle once filled. Traps exist as an explicit percent chance on node paths. Perhaps the most notable thing is that random battles don’t necessarily damage mobility since players still gain stamina during them, which makes them more of a battle capacity check than a dead stop. Overall these are pretty limp wristed endurance dangers (by necessity), but they may still work out in the end.

Player vs Player

Player vs player has continually been the feature most likely to get cut. There are a lot of factors for this: online players are jerks and will exploit any fragile system to annoy other players even at the cost of winning the game, the nature of RPGs requires a battle system with enough room for strategy to give significant edge over numerical brute force, and being free-for-all requires some means of balancing unbalanced scenarios such as 3 versus 1.

The solution to these issues was surprisingly simple: it costs gold to attack players, the base cost goes up after each attack, and there is a multiplier to the cost when it’s imbalanced. PVP becomes another resource to use only when advantageous. Pure trolls will be wasting so many resources that they quickly become harmless, and eventually incapable of even initiating an attack.

Actions

Previously when players landed on an object, a random event would trigger. If they had a quest objective there, that would trigger instead. A simple and elegant system for moving turns along quickly. So I’m not entirely confident in this new system as being a good thing.

Under the new system, when ending their turn on an object players get a choice of what action they want to do there. Common actions include hunting for a battle, gathering an item native to the object type, and so on. This interface also extends to allowing players to opt-in to more random events placed on the object, selecting which quest objectives to complete (players often got confused when two quest objectives ended up on the same object in the old system, or locked into multiple unrelated battles, etc), and allow a generic object to contain more esoteric repeat functionality (ie, allow for repeat trading of one item for another).

It’s a great system for being able to expand upon the game easily, to allow a wider range of object functions with a smaller number of objects, and to make global quests more explicit. But it could also turn into a big ol’ mess of player indecision, reduction of uniqueness for individual objects, and a whole bunch of other varying effects. The primary goal of this system was to give players reason to form an ideal node route in their head. And it achieves that, but it could just as easily harm it with nodes having too much. It may end up being better to give each node type a very specific purpose instead, but even so making quests more explicit will still have some gains so it’s worth pursuing regardless of how it ends up.

 

This week I need to write up some plans for how to generate maps under this system, and then break up the whole thing down into a more digestible todo list and get to work on proper implementation. The whole thing basically amounts to a ton of small changes, so it’s hard to estimate how long it’ll take.

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.