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:

 

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:

 

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:

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

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.

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.