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.