Skip to content

June 29th, 2014

June 29th, 2014 published on

Things continue to go smoothly. The event system has long been wrapped up, and scrolling is half done (which is actually the technical half, the other half is just interface details). So at this point all I need to do is to build sample widgets, convert existing systems over to the new one, and build a few more common ui layout builders. So quite literally just grunt work at this point. I need an intern for this stuff. The actual implementation of new UI will be a gradual process over time since it’s partially dependent on artistic design and partially dependent on more of the proper game design being nailed down.

That’s about all for this week. Not a lot to talk about. Maybe next week will be more interesting if I decide to work on proper game stuff on the side, but I wouldn’t count on it.

 

June 22nd, 2014

June 22nd, 2014 published on

This week has been pretty smooth. The event system is getting pretty close to done, despite me taking half the week off for design work. At this point I’m only really worried about getting scrolling functional, since it’s a complicated weave of several systems. Most everything else is just going to be grunt work. Takes time, but not much thought. Getting it done this month is still pretty bleak, though.

Design work was all over the place. A lot of stuff is still very much in the realm of, “I know how this needs to work, but don’t know how to fill in the details yet”. What I can talk about is the conclusion I made about battles. Right now it’s very hard for players to get much of a sense for their progression, any idea what a given tier of difficulty requires, or even feel very good about the rewards they get. All these problems have a central problem: players aren’t in battles long enough to get a sense for anything. They also aren’t required to be in battle that often for them to care about being more powerful in battle. No one really loves having to fight the same enemy over and over again in an RPG, but the fact of the matter is that it actually serves a vital purpose. The key is to not go overboard with it.

One of the more recent updates added more battle opportunities to the map by placing chances of encounters between every non-battle area on the map. It was an improvement. But it’s not enough, since the system still relied on luck so it was still possible for players to miss out on battles. The new system I’ve proposed flat-out requires every player to engage in combat if they want to move around the map. It works by placing a monster encounter on every tile. Once a player defeats that monster encounter, they’re free to move there without having to fight it again.

Whether an encounter is cleared is actually instanced for every player, so people can’t just follow someone else around to avoid battles. I was really hesitant to make it instanced since I think instancing things tends to make the multiplayer element a little more detached. But then I considered the fact that having random encounters is also instancing in a sense, since one player rolling a battle doesn’t influence the odds of another player rolling a battle. I began to get more comfortable with the idea of instancing after that.

A lot of fringe benefits start to fall out of this system, too. A major problem with the game was that players can very easily snipe rewards that other players found, diluting the joy of exploring the map. By requiring a battle and having it instanced, the player who beats the battle first will also get first dibs at the reward. This also creates moments of tension where the player who can kill the monster encounter faster will get the reward at the other end. Since these encounters are instanced between players it also means where each player can go on the map changes over time, creating some strategic movement choices.

I’m not completely confident that this particular system is going to be the right solution (and it definitely won’t erase all of our problems), but I feel like I’m probably headed in the right direction now.

June 15th, 2014

June 15th, 2014 published on

sheets

 

As you can see, the new character sheets are fully functional in-game. The active player’s sheet is made larger than the other player’s as well as fading out the inactive player sheets a little bit in order to emphasize the player who’s turn it is. The client playing the game is always first in the list, so it’s easy to keep track of who you are. The list is also arranged in the actual turn order so you can tell how far away your next turn is at a glance. Of course character sheets aren’t entirely done just yet, there’s many polishing touches that will have to be done later, but it’s a good foundation.

Stopping to make something functional with the display portion of the system was one of the few smart things I’ve done lately. A whole lot of things had to be changed to get it working properly that will affect future systems, so I saved myself some hassle of having to update them for the changes. Not only that, but being able to do something practical that is actually getting used in the game is a huge morale boost compared to spending months chugging away on code with no visible results.

Playing through the game with the new interface was interesting. Being able to easily see a comparison of player states made some things a lot more obvious than they were before (namely spotting exactly when and where another player starts falling behind). In general the game is more comfortable to play since there’s less in the way of missing information for players. It’s a valuable lesson to learn: for testing purpose having an ugly interface is fine, but just because it’s ugly doesn’t mean you shouldn’t make sure it’s displaying all the necessary information for players.

 

June 8th, 2014

June 8th, 2014 published on

Lots of minor problems this week. So player sheets aren’t entirely done yet. But I do have the basics drawing now:

Those images-representing-health/mp-percents are one of the reasons I went on this mad quest.

And as you might hope, it scales up to larger resolutions as needed:

1920

Here’s Sew‘s original mock up for this piece of interface (as you might notice, I haven’t gotten around to actually filling in the experience bar yet)

Concept

So I’m pretty sure I’m going to get this thing up and running in game next week (assuming I handle the too-boring-to-talk-about issues that continue to plague me). And then I’ll be moving on to finishing this thing off with event handling (so it can actually be interacted with), basic ui widgets, and functional scrolling. It’s looking more and more like the cost of this is going to be 4 months. Regrets weigh heavily, but it has been encouraging getting to work with something. And the system is legitimately a delight to work with.

June 1st, 2014

June 1st, 2014 published on

This is the week I begin regretting implementing this in C++. In short the display part is compiling just fine now, but still has a bit of remaining work to get it to start actually drawing stuff on the screen. Since most of this week was spent fixing rote (but painful) errors, there isn’t much of anything to talk about here. Looks like this UI overhaul is going to cost 3-4 months instead of 2. Really hoping for that 3.

I’m aching to get back to work on the game proper. I might even sneak in some work on it on the side? After being away from it for a couple months the biggest bang for buck that sticks out in my mind is cleaning up the main quest to make every portion of it potentially game winning. I’m starting to warm up to more player choices in quest lines to provide an initial sense of “wonder what happens if I do the other choice” to keep players coming back, though I worry that using it too much will result in players assuming each choice always results in the same thing. Something about side quests still seems off to me, but I can’t put my finger on it yet. Suspect that time management will start to fall out of the main quest changes and give me a better idea.

Right now the game is on the verge of a very big choice. We can either lean much heavier into multiplayer, or we can keep it at a distance in the hopes of also having an engaging single player mode. Leaning into multiplayer has a lot of benefits for the game proper: the more places we put players the more replayable the game as a whole becomes, having battles built around pvp makes the game better in multiplayer, and the more places we put other players the less boring the pacing of turn based becomes in multiplayer. Basically the more emphasis on multiplayer, the better the game becomes at multiplayer (duh) and as a whole. But putting out a multiplayer-focused indie game is basically playing with fire. If you successfully gain a long-term player base, you will warm your house for a very long time since that player base will naturally expand itself. If you don’t gain a long-term player base you will have burnt down your house because no one wants to buy a multiplayer-focused game when there’s no one else to play it with. Given all the niches this game hits (JRPGs, turn based, etc) that are traditionally single player games it’s really hard to tell if hitting these niches with a multiplayer focused game is brilliant or suicide. At the end of the day the choice is obvious: we started this game because we wanted to play a multiplayer version of these, so we should just make the best possible multiplayer version of one. Even if no one else agrees.