This week inadvertently became almost entirely about rebalancing the stat system. It just plain took longer than expected to adjust all the monsters/equipment, and a lot of related stuff got tweaked in the process. The primary purpose of the overhaul was to make stats more readable. 1 strength directly responds to 1 more damage now, 1 defense is exactly 1 less damage, etc. Stat growth has become largely flat so numbers don’t really get out of control. I don’t know that I gained all that much from these changes, but it has been a needed clean up for awhile now so at least it’s out of the way.

One of the subtler changes to fall out of this is that I’ve made defense exclusive to enemies now. After running some calculations it seemed like the main purpose of defense, aside from keeping the size of numbers down, is that it has a much bigger impact on low level characters trying to fight high level characters rather than the other way around. So it’s an effective level gating mechanic. In terms of player vs player it’s actually ideal to make it so lower level characters stand a chance against higher level characters, but in terms of player vs monsters it’s more ideal to make stat growth meaningful to create a sense of progression. Hence, no defense in play when fighting players to keep PVP close while keeping defense in play for monsters as an effective way to keep players out of areas they shouldn’t be in and to make stats more relevant. The one major downside to this is that players won’t notice as much numerical growth in their damage numbers against enemies as they will in numerical growth against themselves. There are more convoluted ways to have a similar effect while letting damage numbers grow over time (ie, strictly in PVE have the gap in level determine a damage reduction), but I feel like making it based on a stat makes it easier for players to understand exactly what’s going on. It also allows me to have classes that make fighting monsters easier by reducing defense, but being totally worthless against other players which creates specialization (doubly so in co-op where a role could be dedicated to reducing defenses so the rest of the team can deal damage).

Another big change is the move to reduce all monster encounters to just 1 enemy. We pretty much all agreed that the multiple monster encounters are basically miserable to play. Which makes a lot of sense since they aren’t really interesting to solo. Sew proposed the idea of scaling enemy encounters against party size. So a 1 person gets 1 monster, 2 people get 2 monsters, etc. Multi-monster fights are more interesting with a party in play, and it helps reign back the extreme advantage that parties currently have in the game. So I’m heavily considering going with this route. The bigger problems are the extended issues: what happens when someone joins an existing battle, does a second monster spawn in? If so that’s a gigantic opportunity for griefing. If not then players are heavily rewarded to only join battles instead of being a party. It also opens up the opportunity for one player to get locked into a battle he can’t win when his party members die or leave the battle. A third problem is focus fire: with damage rates the way they are it would be totally trivial for monsters to focus fire a single party member to death in a single turn. The same goes for players. Something has to be done to make target selection more interesting than piling on to the same target. So there’s a lot of hard problems to be solved here first, but I’m hoping to move in this direction.

Meanwhile we’ve been working on designing the new battle UI. There’s some exciting stuff in there. In particular I’m looking forward to exposing passive abilities better, because it will allow me to have more gimmick-driven enemies without them being quite so confusing. Other cool stuff includes making the type system a whole lot less confusing to new players, faster to read ability selection, and really just less confusion for everyone involved across the board.

All throughout this my decision to stick to the current battle system continued to haunt me, since I had to test it quite a bit while rebalancing the stats. It’s probably fine? This is basically one of the biggest make or break decisions I’ll have made for this entire game. As it is, the game will be fairly easy for newcomers to pick up on. There will be a reasonable amount of RPG depth and trying out different combinations of builds. But it probably won’t be quite deep enough for an extremely dedicated competitive community or anything. Is this the better direction to go for in terms of being profitable? I have no idea. But it probably suits the game as a whole better. I want people to enjoy seeing the goofy story branch out in all kinds of surprising ways while casually backstabbing/cooperating their friends, and the lower barrier of entry is the best way to hit that mark. There’s still just enough depth here to keep the game interesting throughout.

This week consisted of doing a bunch of minor tweaks, performing more tests, and making a decision on whether to do a major change to the battle system. The long and short of it is that as-is the battle system doesn’t allow for much in the way of creative combinations. Which is pretty much inevitable when players can only do a single action in a battle turn and whatever passives they have. There’s a lot of ways we could try adding multiple actions per turn to give players more opportunities for combination (and hence customization). Doing a card deck shuffle system has been pretty appealing to me (because it still minimizes the number of options players have per turn, thus minimizing turn time). On a less drastic note having players choose two actions in a turn was also interesting. But eventually I settled on leaving it where it’s at.

There’s quite a few factors behind this. The system is at a reasonably good place right now- PVP is viable against players with differing levels, battles never take too long, PVE has a decent (but not great) element of following patterns, people can pick up the system quickly, etc. The only major flaw is the lack of combo depth, and I think I can actually improve that through smart ability design and map system interaction rather than pouring another layer of complexity on it. There’s also the big factor that I only have 3 months left to overhaul the design of this thing and adding this stuff on to combat would take up a significant amount of time. So I’m leaving it alone for now, changing it is more likely to make a bigger mess than it is to elevate it.

So with that out of the way I’ve started taking a spread shot approach to improving the game from here. There’s basically 5 points that I want to improve on, 3 of those I had numerous ideas for (and mostly pertain to improving the newest additions) and just picked some of my favorite improvements and put ’em on the schedule for update 5. Let’s take a look at the currently focused elements:

1. Refine The Battle System

There’s no single major problem with the battle system at this point. Just lots and lots of minor things. Some of it is just usability, like stats being unreadable nonsense to players. Some of it is broken monsters. Classes and their abilities need a fair amount of rethinking to see if I can add more combo opportunities. The attack type system is overemphasized and needs toned down slightly.Equipment needs to be a more interesting choice. There are experiments I want to perform like having 4 types instead of 3. Just lots of little things to punch it up and make it more immediately readable.

2. Improve Racing

The new main quest basically turns the game into a race to a goal between the players. Which is actually a big step up from the directionless mess it was before. But the actual racing itself needs improvement since once a person takes a lead, there’s very few options to catch up to them. I Have a bunch of ideas for making this more interesting.

3. Improve Victory Resolution

Right now if two players make it to the game ending battle at the same time, it all comes down to turn luck to determine who wins. This isn’t satisfying at all. We had some convoluted ideas for how to fix this like letting players fight each other in a battle against a monster. But we eventually went with the much simpler idea of ending the game with a climatic PVP showdown between players. This will probably fix it just fine, and there’s plenty of ideas for variations in this method of resolution.

4. Improve Progression 

While requiring battles has made a world of difference for players in appreciating their progression as being useful, the actual acquisition of power is still pretty straight forward: kill monsters. I want to give players stronger reasons for going off the primary objective, which will make the race itself more interesting: try to take it on slightly underlevelled, or be slow and cautious about it? On top of that I want to give players more options in actually customizing the build of their character to adapt to the game situation. The current leading proposal for this is to have 5 or so resources that players have to turn in varying combinations of to unlock different parts of their progression. This is starting to become an optional point to work on (might slow down pacing too much and makes the learning curve harsher), but I still want to give it a shot before dropping it.

5. Add Chain Reactions

I’ve talked about this a billion times on this blog. I want systems to bounce off of each other in a natural way to create unexpected situations for players. Right now the leading idea for this is to allow the map tiles to have effects on them that affect the battles taking place in them in various ways (ie, double damage from a particular attack type, everyone takes damage each turn, etc). This is one of the optional points that I’m willing to drop if nothing works.

————-

Once I’m satisfied with these points, the main goal is going to be to implement prototype versions of each of the scenarios. From there it’ll be about balancing and coming up with the final classes, items, equipment, monsters, and so on. Ideally the entire final versions of the scenario quests will also be done by the end of the year, but I’d settle with the prototypes since the rest of the game will have been finalized. There’s plenty of other work to be done with polishing, finalizing the menus, etc as well which will happen in who knows what order (ideally we should start on the menus once I finalize the systems rather than waiting on content completion). I can almost see the light at the end of the tunnel, but it’s very far away.

 

At long last the game is basically how it used to be. Probably a few crashes still lurking in there that I need to sort out. But the conversion is done. There’s a looming technical issue that I’ll need to sort out at a later date, but for the time being I’m switching my gears entirely back to working on the game itself. If I get lucky, enough time will have passed for one of my libraries to fix the issue for me. If I’m not lucky, I’ll have to do something time consuming. But I’ll worry about that when there’s a game worth investing into.

I’m taking a more literal prototype approach to adjusting the game this go around. Instead of planning out and scripting a large chunk of the branching plot, I’m just building a simple prototype that only branches in a few specific ways that represent the different ways the plot can affect the gameplay. It’s much faster to build, and gives a solid idea of how the changes will work out before applying all the detail to it. Doesn’t give much sense of the flavor of the game, but I’m ignoring that for now.

Likewise I’m temporarily going to start making the map layouts by hand instead of with the random generator. For now this is a measure that lets me easily radically alter the structure of the map without rewiring the generator. But it also lets me get a sense of what matters in a map layout and what doesn’t, which will feed back into the generator once I know what to target. It may also turn out that there’s only a handful of set layouts worth having around, so map generation might get dropped entirely.

It’s all about saving time to try things out faster. Hopefully these changes will work out. But if not, it won’t have cost as much as it could have.

 

The conversion to the new system came close to completion this week, but was thwarted by one last issue in the new system itself which slowed it down by requiring minor design work. Otherwise, it’s pretty close to running again. Still a few extended issues in terms of adding font outlining and tooltips to the new system in order to fully restore previous functionality. But odds are I’ll get to jump back into working on the game proper this week.

The amount of time sunk into this overhaul matched my worst fear estimate, and the amount of remaining work will probably take it far past that. I suppose it had to be done, but right now the amount of system and game design work required feels like it’s threatening to swallow me whole.

Much has been said about comments in programming. I feel like when I was first learning “comment everything!!” was popular advice to newcomers which eventually shifted over to “your code should be self-documenting!”, though I suspect the latter advice has been around for about as long. I’ve never been a huge comment user since I wrote most of my code during short term contests, making it disposable. Mostly documenting things that might need to be adjusted later, possible problems/deficiencies, and often using them to separate unrelated chunks of code (which is likely a bad practice that generally indicates the code should just be split apart). I should do a better job of documenting the API, particularly considering how often I use dynamic languages.

But after working on such a long term project for so long, the realest purpose of comments is starting to dawn on me. Comments are band-aids for when things aren’t ideal. If you’ve analyzed a situation and decided to go with a compromise to get something done just “good enough”, you can use a comment to explain the particulars of an odd line of code instead of wasting the reader’s time figuring out the chain of reasons for it. I’ve probably used them for such a purpose countless times without realizing it. But there are just as many times where I’ve done something convoluted without bothering to explain it, and then had to understand it again later. I need to make a more proactive effort to notice these situations and then explain them for the future. It’s not as good as just having obvious behavior, but it’s better than nothing.

This isn’t a mind blowing revelation so much as reminding myself by writing about it. Most people writing about “self-documenting code” will say something very similar. Though they mostly refer to it as using comments strictly for non-obvious or complicated sections of code, as opposed to just admitting it’s to alleviate bad code. I don’t think I fully absorbed the idea when it was about “non-obvious” code. But bad code. That I understand.

We’re through most of the “oh man everything is depending on a different API that we need to update” phase of conversion and into the “we need to actually change these things to work better with the new stuff” phase of conversion. At this point I almost regret not just leaving the existing systems as they were and limiting the new system to the UI. There ARE benefits to converting the entire game to the new system, but 3 weeks is a much worse price than I anticipated. Though I wouldn’t say this has been 3 weeks of pure work, things have been a little messy lately.

In general I’m starting to get more into a mindset of “get it done”. Been spending less time over thinking minor issues to be perfect. Converting older code to the new scene system has made me brush with some of the worst remaining parts of the codebase, and I’m starting to accept the fact that I just won’t have time to improve those parts any time soon. We’ll see what happens when we get down to polishing, but the things I need to do are holding up other aspects of production so they need to get done first. You can either build the perfect engine or you can build your game, but you can’t do both.

Well it finally happened this week. Sew came up to me and told me that he couldn’t really start on that much final art until there’s a finalized plan for the game. This was inevitable. Several months ago or so when I decided whether to do the UI/Display overhaul first or prioritize finalizing the game design I chose the UI, despite my gut feeling otherwise. I suppose that’s this year’s big mistake.

It’s a better mistake than last year, though. It taught me the valuable lesson that while development UI doesn’t need to be pretty, it does to be functional and expose needed information properly to players. Putting it off alongside prettiness can lead to false results. The changes will also make it easier to do certain design changes that I would have avoided before due to development costs. So it’s not a total loss.

Regardless, I immediately put the remaining UI work on the back burner (though I may try to work on it once a week so I don’t lose my place) and set to converting the existing game to use the new display system. The work needed to convert the existing map engine has been worse than expected. While I fully expected updating all the systems that depended on it to be a pain, I didn’t expect this much resistance from the engine itself. So it seems like it’s going to be a 2-3 week job instead of 1 week. It’s quite frustrating when all I really want to do is get back to work on the game itself.

So the game itself. Why is the basic game not finalized after nearly 3 years of work? Basically, it’s costly to iterate on a complex game.

The initial goal here was to build a system that could support the basic idea of the game we wanted to make and to then tweak it to make it better. Along the way I deliberately overbuilt portions of it to be able to handle common RPG mechanics that we might or might not need. At the same time I underbuilt other portions of it since time was at a premium. This system probably took about 1.5-2 years of production to become stable enough to really build sample content for and to test thoroughly.

Under the lofty ideals of iteration as king we should have then proceeded to rapidly tweak the game into a better state. But even with a solid foundation in place, I found the larger changes I wanted to make taking months to add because the original system was in no way built for them. In a game with a small central concept you can with rebuild the central mechanic again and again with relative ease. Say you wanted to make the perfect player movement in a platformer. Player movement isn’t an expensive thing to build over and over again, especially if what it interacts with doesn’t exist yet. This, as it turns out, isn’t so much the case when you’re already hauling around the rest of the game on your back. This is largely on me for building the entire game before iterating, but it’s also on our genre for relying on interactions between many things for the “game” to really start to exist.

I think I adapted to this fairly well. After the first changes being very high cost, I built newer versions of the map system in a direction where I could experiment with lots of things for a fairly low cost. It’s very unlikely that I’m going to shift from that fundamental system now, but I also haven’t completely figured out what really works with it yet. The battle system meanwhile was overbuilt to begin with and has been cheaper to iterate on.

There’s something Sew has asked me again and again the last year or so: “what is the game any more?”. The more I’ve tweaked the game in an increasingly complicated and mangled direction, the more I’ve lost him. There’s a method to the madness, and for every failure along the way I’m getting closer to what I’m looking for. You’ll just have to trust me on that.

I’ve done two approaches to making games in my life. The first one is creating a design doc and then building just that and fixing it in post. Very efficient for simultaneous team work, though it can lead you right off a cliff if you were wrong. The second one is building a core idea that you’re happy with and then continuing to build more and more around it until you run out of ideas. Not a technique I’ve had the opportunity to use much since it’s hard for teams, but it was probably the funnest to work with and led to the most reliable results. I had hoped to use the second technique for this game, but finding that first step has been a doozy.

 

This week was a matter of closing the last flaw in the design of the new scene system. In short I originally designed it around every parent node having its own set size, rather than having them expand to fill their children. This was workable but had various drawbacks once I started actually working with it. So the big change was the capacity to set parent node sizes based upon the size of their child layout. Since the system wasn’t designed for this there were numerous problems.

It’s all in now and working fine, if a little sketchy from not being designed for it. Most the week was spent on it. Implementing it wasn’t so bad, it was just a long series of new problems needing solutions cropping up the further I went into it. I don’t feel great about this time allocation. Next up is deciding whether to finish the remaining UI widgets or to convert the rest of the game to the new system. I’d personally prefer doing the conversion first so I can take a break on the UI and start testing out the new gameplay ideas. But it’s a risky choice if UI widgets end up requiring changing something fundamental. I’ll probably do it anyway since I’m sick to death of UI at this point, and anything requiring massive changes seems unlikely.

Meanwhile recent AMD drivers broke part of the game’s visuals and I am currently in a waiting game of deciding whether AMD, the library we use for rendering, or myself will end up fixing it. I’m guessing it won’t be AMD, but the game is far enough away that I can afford to wait and see.

Scrolling is done, it took longer than expected (largely due to being the first real production test on the event system and other such things), so on and so forth. Nothing to talk about this week! Probably not next week either.