Skip to content

February 1st, 2015

February 1st, 2015 published on

Starting to make progress on actually putting the new map system together. Still very early. A fair amount of the time consumed was due to building a feature more thoroughly than initially expected. Technically this feature was problematic in the last iteration, instead of properly integrating item drop offs in the new system I was just using the same system as several iterations ago. This meant item drop offs worked in a way that was very confusing for testers, but was close enough that it was an easy thing to delay doing properly. With the advent of the new system being so dependent on pass-by actions, it became necessary to integrate them correctly. Had to pull out the old code, make it capable of working in multiple places, etc. End result is we can finally have node actions that demand gold or items to use them, and quest drop offs can be done as a pass by.

The other big thing of the week is a bit more technical. Around 7 months ago after a driver update, lines between tiles in the game started appearing for me. There was no logical reason in the code for these lines to be appearing, and I figured maybe it was just a problem with the new drivers. Months past, and the issue persisted in every new driver update. Looking for answers online didn’t lead to much since I had assumed it was an issue tied specifically to the newer drivers. This week I finally set my foot down and decided I was going to get this thing fixed. After a whole lot of fiddling it became clear that the issue behaved differently depending on two factors: when you change the resolution of the window from its starting resolution, and when you use decimals in sprite positions. After I boiled it down to symptoms it finally became possible to look up solutions online. Apparently when dealing with floating point positions video cards can blur the edges of things to create a smoother movement effect. This is useful for moving objects, but terrible when triggered on static things like my map tiles. Even removing decimal positions for these static objects isn’t enough to fix it since it can also be triggered by things like having the screen size coordinates not match the texture coordinates (which occurs by resizing the display window). Different cards deal with the rounding in different ways, too, presumably the driver update made my AMD card start to deal with it in a slightly different way. The solution in the end is to add exactly .375 to these static object’s positions to force the rounding to occur in a specific way between all cards. Programming, huh.

January 25th, 2015

January 25th, 2015 published on

Remember last week when I said we were pretty close to restoring original functionality? Turns out that ate up this entire week. Technically not all the original functionality is there yet in a couple places, but only in the places where there is also the need to add new functionality. Not a ton to talk about, it’s pretty much just put your head down and keep at it work. Getting closer to more interesting stuff. Right now my goal is to get a rough draft of the new map system playable and decide what’s needed to improve it. Have plenty of planned changes for it, but it’s nice to get a feel for it before going through with them.

January 18th, 2015

January 18th, 2015 published on

We’re getting pretty close to restoring functionality back to what it was, while also using the new style of map movement. But that’s actually just the beginning. I have to adjust everything to compensate for the new system. Most of the old system relied on players being on an exact tile to engage with stuff, but now that movement is random “pass-by” will become more prominent for quests and the like. Attacking other players or joining their battles will instead become range based instead of requiring the same tile (which will be pretty interesting when PVP becomes a more legitimate option to catch up to players who are ahead). Lots of adjustments like that.

Putting the new system together has been very promising so far. It’s still too early to be certain, but I can picture everything in my head now and that’s tremendously relieving compared to when there were several blind spots in the design. At this point the game just seems more like a ton of work that needs to be done, rather than groping around in the dark hoping to get lucky. I’m just anxious to see the theory applied at this point, and the closer I get the better it seems.

 

January 11th, 2015

January 11th, 2015 published on

The work has commenced on converting over to the new map style. While it was entirely possible to rewire the existing systems to support the new stuff, I went ahead and took this opportunity to clean up the code a bit. The map stuff was certainly the worst thing in the game, I had two different generations of system hot wired to work together. One of those systems had been mangled to work in ways it was never designed for. The numerous changes to maps over the years have taken their toll, especially considering it was rushed to completion so it wasn’t in a great state to start with. I’m not so much throwing away the old code so much as completely restructuring it. It feels great. Like lifting an albatross off my neck. While I’m adding a whole lot of extra work if we ever decide to revert back to the old system, I don’t really care because if this new system doesn’t work out there won’t be enough time to try anything else anyway.

As a result, the process of building the new map style is a little slower than it might otherwise have been. But I think it’ll be playable this month pretty easily. The rework will probably make it much faster to add new things to the map as well.

December 28th, 2014

December 28th, 2014 published on

Designing the new map system could possibly be described as an emotional roller coaster of a process. One might describe the new map as the biggest compromise I’ve had to commit to for this project. It took some time to accept it even after admitting that it’s the most logical course of action.

The map itself wasn’t the only major change I had to cope with. I also had to start to inject some luck into the game. It’d be lovely to do without, but a lot of RPG feel depends on it. It took this long for me to finally admit to it, though. I don’t actually like focusing my design process on something like “feel of an RPG, but multiplayer”. It’s very snake eating its own tail, focusing it on some vague hodge podge of other games. A genre piece like that is inherently weaker when it draws from its own medium. It’s where I’m going with it though. I’m trying my best not to blindly copy, but to understand the underlying purpose of things and use them for my own needs.

How to handle parties remains up in the air at this point, but otherwise the design is finished and all that remains is putting it all together. There’s a lot to do, but most of it is pretty low cost (the highest cost unfortunately being the first step). It took time, but I have a pretty good feeling about these changes now. I can see the game as a whole pretty clearly now. It’s a weird feeling, but I can get used to it.

December 21st, 2014

December 21st, 2014 published on

When I first started working on this game I was pretty adamant that the one thing I wanted most was free movement for players. That is, having players choose where they want to move on the map each turn (limited by some stat) as opposed to the more traditional board game format where players roll dice and move the designated number of spaces, only choosing where to move when the path branches.

When we were looking at competing games in the illustrious “jRPG mixed with board game” genre (yes that’s an actual genre) most of them went with traditional board game movement, but the one that used free movement appealed the most to me. It felt like actually exploring a world in an RPG instead of being hurled down a path based entirely on luck. And that is what I wanted the most: a multiplayer jRPG that works in the multiplayer by using board games as a metaphor, rather than a board game with jRPG flavor.

We’ve went through a lot of iterations of the free movement style. The first had very direct tilebased movement (resembling the movement of a tactics RPG in a lot of ways). That mostly created a lot of empty space, so we moved on to roads defining the path between points of interest. That still made the connections between places rather hard to read, so soon points of interest turned into strict squares. That empty space allowed for putting multiple things into a single point of interest, and so arbitrary verb lists for each area become possible. Some of them player activated, some of them not.

I love the idea of being able to put multiple unique actions on each point of interest. There’s so much you can do with that type of thing. In the back of my mind I secretly wanted to put in a sort of life sim scenario into the game that would have players chopping down trees or picking apples or buying low selling high etc. There’s a great game in there somewhere. But when you consider that we’re trying to make a fast paced multiplayer game here, it doesn’t jive all that well. Each and every one of those actions has to be parsed and remembered by every player. It becomes more overwhelming to figure it all out more than anything. There’s probably a really great slow paced game in it somewhere, but it’s a different game than the one we’re making.

What actually made this clearer more than anything else were the recent adjustments to the main quest. Sprawling multi-part quests where each individual part could branch out even further turned into straight forward singular objectives. Instead of letting players take as long as they want, extremely tight turn timers were added each step of the way. And all of this improved the game dramatically. The length of games dropped down closer to the golden one hour we were seeking. People started to pay attention to the main objectives and compete for them. The game wasn’t aimless anymore, there was a goal. And that goal started to look a whole lot like a racing game.

Do you know what a race looks like when you put it into a turn based format? It starts to look a whole lot like those traditional board games. You can see very clearly the standings of every player: who’s in front, who’s behind the pack, etc. And that isn’t the only thing a traditional board game looks a lot like. It also looks a whole lot like a jRPG’s dungeon: a linear line to the end, getting harder the nearer you are to the end of it (albeit with the addition of a few branching dead ends).

Another way to look at it is: what does free movement get us? Not a lot. Individual tiles basically get discarded after players use them, so the map becomes more irrelevant over time. This is particularly bad because it makes player created traps largely irrelevant outside of the plot critical path, which is exceptionally short so they easily become too powerful. The map is so small (by pacing necessity) that it doesn’t contribute much towards interesting player chase sequences (ie for stealing a quest item from someone). Free movement ultimately boils down to letting players choose how much of a risk they want to take each turn, which isn’t a bad mechanic but is trivial to replicate in linear movement. There are some cases where free movement can add a whole lot to the game, such as when adding a tower defense element to it (so the shape of the map stays relevant even after players have explored a tile), but none of these cases seem particularly relevant to us anymore.

Meanwhile linear movement gets us a whole lot. Having player rankings explicit on the map makes it very easy to reduce kingmaking from PVP: you can only attack players near to you. The entire map remains relevant longer, particularly useful for player traps. Map turns become simpler, so players can burn through them faster (which means each player doesn’t need to wait as long for everyone else to do their turn which means we have better pacing and turn flow). The sense of getting deeper and deeper into danger is easy to create. This is just scratching the surface of advantages.

It’s pretty simple: the game has changed, and the map systems need to change to match it. There’s some pain in admitting it when so much time has been invested in current systems. I worry slightly that it’s going to make the game seem simpler to players and will turn them off to it. The actual programming cost isn’t that high since most of the systems in place for free movement are just as relevant for linear movement.

It feels a little foolish to have resisted the linear movement for so long only to be forced to use it in the end. I don’t feel great about it considering how much of the second year was wasted on things I’m about to throw out. I’m too tired to mind it too much, though. The entire point of this development process was to find something that worked by constantly changing and then testing things. We’ve found something that works, and now it is time to support it. It’s an inherently costly process because much of it is spent creating things that you won’t actually use. The advantage of copying other people is that you don’t have to pay this invisible cost.

December 7th, 2014

December 7th, 2014 published on

This week was mostly spent recovering from the last update and on the initial design work for the next draft of the map systems.

I’m basically taking a layered approach to it. Basically solving one problem at a time, adding one missing element as needed. This has actually been in progress for awhile now. The first big step was introducing the monster den system which basically established how map progression should work and how to integrate battles into the game. The second big step was overhauling the way the main quest is structured into 3 big primary goals with strict time limits, each capable of winning the game (as opposed to the previous meandering objectives with little completion incentive until the end).

The next thing I’m focusing on is tension. It’s not the most fashionable RPG element with Western RPGs throwing it away in favor of quick save convenience while Japanese RPGs simply designed easier one-shot dungeons, though it lives on in various dungeon crawlers today. What I mean is giving players incentive to stretch their resources as far as possible. In more traditional RPGs this just meant trying to avoid backtracking to town in favor of completing the dungeon (accounting for the risk of pressing on vs. going back to town). In roguelikes it just means surviving as long as possible. What I’m talking about is resource management. I’m talking about the danger of a dungeon.

The traditional means of accomplishing this has just been making players backtrack to town if they decide the risk is too great. But this isn’t a viable solution to the problem due to the tight pacing we’re looking. Doubly so when you factor in that backtracking creates “empty” turns where players don’t get to do much (which then makes it far worse to sit through other player’s turns and makes losing far more irritating. You generally want to target every player having as similar of turn time as possible throughout the game). So that is the problem I’m facing right now: How do you create tension without backtracking?

I don’t have an answer yet. I’m also kind of really excited about finding one. The tension of delving into a dungeon is probably my favorite RPG element, but even I can admit that handling it with backtracking (or inevitable death in the case of roguelikes) isn’t necessarily the most engaging way of doing it. So I’m really enjoying trying to find a better way to do it.

Update 5 Test Report

Update 5 Test Report published on

Changes

  • Added a co-op mode, including a new main quest for it.
  • Implemented new Lane battle system to keep damage output steady between 1v1 and 4v4 battles as well as updated monsters to cope with it.
  • Created all new co-op classes designed around playing specific roles.
  • Switched to new class system where players choose only one class that progresses across the entire game, instead of mixing 3 classes.
  • Limited party movement to be roughly comparable to a single player, randomized turn order for each round.
  • A multitude of functionality improvements (Sharing shop access with party members, expanded battle ability lists, displaying possible enemy attack types, monster encounters scale to party size, monster transformation/spawning, controlling more than one character on a single computer, etc)

Test Results

Early results seem to indicate testers being largely positive about the changes so far. In particular engagement seems to be higher in co-op due to the fact that every player gets to participate in every battle most of the time, and every map turn is directly related to them (so there are few opportunities to wander off and lose focus while waiting for your turn). Some small issues with the rock-paper-scissors system being harder to follow with 8 characters being involved (and not so important that you will die by ignoring it), and potential power issues with debuffs given the current battle speed. Nothing to act on until further testing, though.

On my part I’m worried that the game length is possibly way longer than an hour in co-op and may need to be trimmed down further (Either by reducing the number of battles or the progression length). But this, too, requires further testing to be sure.

Next

At this point combat is about as good as it’s going to get. To help out PVP I’ll probably add a limited number of quest objectives that force cooperation (as well as PVP), to make sure it doesn’t stagnate with just 1v1. I have a number of 1v1 enhancing features for the lane system (slot traps/effects etc) I’d like to implement, but they won’t be a priority for the time being since there are bigger issues. Likewise allowing players to control monsters may add a degree of “always playing the game” to PVP as well, but just isn’t high enough priority to add any time soon.

The remaining Big Problem is simply getting the map game up to snuff. The new monster den system sets up a reasonable foundation, but I need to put meat on those bones already. My long-established guideline for it has been “the map should play like a dungeon” and that’s basically the angle I intend on build on though I don’t have any solid plans for it yet. In addition to the map itself, I want to finally implement player abilities that interact with the map (place down healing stations, put up traps for other players, warp themselves around the map, etc allows for interesting classes and more interesting map play).

I still want to get the fiddly RPG bits (more interesting equipment choices, more customization class progression, etc) to be more satisfying as well, but the map comes first. It may also turn out that these fiddly bits end up being part of the map as well.

Aside from that I also need to get PVP operating again since the co-op changes pretty much broke it. I mostly just need to rebuild the PVP classes to work in a single class system, but there are a few other improvements to the basic PVP formula that I want to add (mostly just killing other players to clear monster dens). Getting PVP up and running again will likely be the background task I work on while designing how the new map needs to work.

As you can tell by this laundry list, finalization certainly isn’t happening by year’s end. But I also don’t think it’s unattainable by February or March, as long as improving the map doesn’t require too drastic of changes. At any rate, I’m just glad that the game is visibly improving with each update.

November 23rd, 2014

November 23rd, 2014 published on

This week saw the completion of implementing new monsters and the wrap up of planning the prototype version of the co-op quest. So we will almost certainly test it out this week. That’s about 2 months from start to finish to implement co-op mode. At this point it’s blatantly obvious that I probably won’t be able to hit finalization this year, most likely I’ll go well into March with it. Not ideal, but not much I can do about it.

On the bright side I am pretty excited about testing this update with other people. I don’t like to say too much about my personal feelings about an update to the testers since it likely influences their opinion, but so far the lane system is on par with the monster den system in terms of “this was a good idea that is turning this project around”. My initial personal testing was basically the first time it felt like I was actually playing an RPG with this game. It’s also incredibly confusing to test by playing as all 4 players yourself since there’s no visual indication of what each class everyone is in-battle yet (and names are just numbered). That won’t be as big of a deal in multiplayer since everyone will be familiar with their own class and will associate the other players as needed (though even then we’re going to need to add some visual indication).

If this test works it will then be a matter of fixing up PVP to use the new systems from co-op (mostly just new classes), and then doing my best to improve the map aspect of the game. I feel rather silly spending 2 months mostly just fixing up the battle system when the world map is the most in need of attention, but it had to be done.

November 16th, 2014

November 16th, 2014 published on

Implementation of the sample co-op classes was wrapped up this week. It was a bit slower than expected because I actually managed to produce quite a few old battle system bugs thanks to the more intricate class abilities, so I had to stop and fix them. I’m starting to notice that any time I have to rebuild content is basically the biggest time sink in the project at this point. The big content hogs at this point are now building the new monsters and the new co-op quest. There’s a few tweaks I want to do before the next test as well, but they’re easy enough to do in between.

My big worry at this point is basically players exploiting battle scaling in co-op (in PVP it’s not as big of a deal). It’s like this basically: If the 3rd monster in a certain random battle formation is the one that gives the players trouble, then it might be in their best interest to split up into 2 parties of 2 players in order to avoid having that particular monster spawn. I don’t think this is too big of an issue since co-op classes are designed to work best in larger groups, and there’s still a battle speed advantage in that big parties get more battle turns before causing a new round to happen. But it’s certainly something I have to be careful with because I really don’t want to provide incentive for obtuse player behavior .