Bonus update: Skill screen.

So, it looks like I got more done today than I expected.

The skill learning screen is way better now.  Here's a before and after shot:

Before

After

First, I removed the skill costs from the section where you select the skills, because the costs took up a lot of horizontal space and didn't provide much value. The numbers and colored circles and stuff were just visually noisy and contributed to a feeling of overwhelmedness. (Just so you know, in the first screenshot, the 1/1 indicates the skill is usable once per day, and the 10MP means it costs 10 MP to use. The colored circles are icons signalling uses per battle and MP cost, respectively. This is not always important for the player to know, and if it were, it could be communicated through the help text above, which, as you can see, it is.)

Second, I nuked the gold part of the window and replaced it with something showing you how much skill powder and other skill items you have. (In Yanfly's original script, this was a place to purchase skills using gold, but in this game, you don't use gold to buy skills, you use skill powder and similar items.)

Third, I received some feedback that the way the needed number of items in the first screen was presented was confusing. Green text notwithstanding, when somebody saw they needed 24/10 skill powder to learn a skill, they thought that they needed 24 and only had 10. In fact, if the players saw two numbers separated by a slash, and one was higher than the other, they just sort of assumed, regardless of the placement, that they didn't have enough of the needed item. So, I made the first number "cap out" at the number needed. In the second screenshot, you'll see that the player has 10/10 of the skill powder needed to learn the skill. The player actually has 24 skill powder, as seen in the little box below the cost screen, but 10/10 makes it very obvious that you can learn the skill.

Gonna send this entry into my thesis advisor for some feedback.

Large parties, belts, item pricing.

Work has been slow, this time because family on my wife's side was over for vacation.

But I have done some stuff since last Friday.

First off, the quest system now supports of to five party members:

This poor slime does not stand a chance.

Also, I added belts to the stock of the store and made a new store:

Now displaying belts.

Also, I did a lot of tweaking to the item prices. I wanted the item cost to scale linearly as you went up through the game, so I figured out what level I wanted the player to get each item at (let's call that number "L" ) and then make the cost of an item = C * L, where L is a constant. Looks like a lienar scaling, right?

On the contrary, you gain levels more slowly as you advance through the game, making your level over the course of time look kind of like a square-root curve. The cost of items is linear with respect to level, but *not* with respect to game time! To solve this issue, I had to change the item formula to something that looked like cost = C + (B * L^2), and that straightened it right out. Now, items scale quadratically with respect to level, but linearly with respect to game time. This has the end effect of making items cheaper near the beginning and more expensive later on.


In the end, this should remove player frustration, make it so I need to give less gold in chests near the beginning, and make the item formula scale better into late game.

Stoneacre Fields: Now with 81% less player death!

The past two days were spent playing the first dungeon (Stoneacre fields) over and over again, and trying to balance it.

My goal is to make it so that a party of two people can complete Stoneacre fields four days from the time they start playing. The problem is, Stoneacre fields was horribly balanced when the thesis was first approved.

My wife and I have a lot of patience. We figured that if this game was hard, that was okay, because it would just extend the playtime, right? That, plus a lassez-faire attitude towards balance (it was only for my wife and I, after all) combined to make the first dungeon a huge difficulty spike compared to the tutorial. It took a week of diligent chores for us to beat the giant bat, the weakest monster in the dungeon. It took three weeks of diligent chores to beat the boss.

That's not going to work for something released to other people. I'm already working at a disadvantage because gamers are used to instant gratification. It would be ideal if they could do a new dungeon (or two) every day, but that would require a plethora of dungeons I just don't have time to create. Four days per new dungeon is about the most I can ask for; Three weeks is completely out of the question.

And so I had to nerf the monsters. And nerf them more. And nerf them more.

For reference, the easiest monster in the dungeon was roughly equal to a level 3 character, and the strongest was equal to a level 7 character. After the nerfs, the easiest monster was about level 1.5 and the hardest was level 4.

And it still wasn't enough.

I had to invent new low-level skills to give the players more strategic options. (For example, a spell that affects all enemies; useful against groups but cost-inefficient against single targets) I had to provide them some level of sustain (healing spells usable once per combat, etc.) I had to give them extra equipment. I had to provide chests with gold in them. Finally I got to the point where two characters that had only been playing four days each could beat the dungeon. Barely. If they were smart about it.

My mind reeled as I tried to figure out why on earth it was so hard to make that dungeon function. My math suggested that there was no way the characters should be having that much of a problem.

Then, I found out there was a bug. Turns out that any guests you recruit to your party revert to being level one at the end of the first battle they participate in. I wasn't running around with two characters that had played four days each, I was playing with one four day character and one complete noob in fancy gear.

Argh argh.

The fabled Stoneacre Fields

Anyway, things are good. I'm to the point where I have four days of playable content. The party system works (in fact, it works better than last time I claimed it worked.) I've got items, monsters, a half-dozen skills, a skill learning system, shops, tutorials, character training, a training regime editor, and all sorts of stuff. I had my thesis adviser play it all the way through once; he seemed pretty impressed. I think we're getting to the point where it's time to roll out an alpha soon.

So what's left to do before the first alpha test?

• Larger parties. Right now, only two people can party up. I need to increase that to five.
• Fix a memory leak when people leave the party that causes bloated saved games.
• Make it so you can only enter dungeons once per day. Add an "explore" mode that lets you enter dungeons after that, but in a way that prevents them from getting items and stuff. This is important because we want the players to be able to play, but we don't want them to be able to grind.
• Fix up the "learn skills" screen. It's the most confusing interface problem right now.
• More positive feedback when gaining levels. Right now, it's really easy to miss the "You leveled up!" notification.

My goal is to have this done by this coming Wednesday, in time for my research meeting. I'm super excited. If this works, then I'm on the right track, and perhaps a month from now, I can have a beta with several weeks worth of content.

...right now, I just need to avoid the temptation to work on the next dungeon, the Poacher's Forest.

Guests have items!

It might not look like much, but let me explain this image:

This is a guest character imported from a different save file. She brought all her equipment with her. Important to note: Because of the planned crafting/enchanting system in this game, this is way more hard than it was in the original RPGMaker MV.

RPGMaker uses a design pattern called "Flyweights," meaning that items in RPGMaker are just pointers to a "prototype" item that represents all items of that class. For example, because all "shortswords" are identical, whenever anybody buys a shortsword, rather than creating anew shortsword and giving it to the player, it just gives the player a  pointer to the original swortsword.

This causes problems when you want to enchant things or otherwise edit how items work. If I don't actually have my own shortsword, but just a pointer to some "base" shortsword, then if I make my shortsword a fiery shortsword, all other shortswords in the world change to match.

To fix this problem, Yanfly wrote some code she called "independent items" that makes it so whenever you get a new item, it actually creates a new item that can be modified independently of the original. The problem is, in order to maintain compatibility with other RPGMaker plugins, she had to do it in sort of a hacky way. The new item is also a flyweight, and is stored with all the other flyweight classes in the same database!

This made it a real pain to copy equipment from one save to another. I couldn't just copy it, I needed to dig in the original save's database, copy it into the new database, and then re-align all the pointers to match up. It took way too long to do this; at this rate, the game isn't going to be done in time. I hope either I start solving these problems faster or the problems get smaller as I progress, or I'm going to have to cut some features to make the deadline.

But the good news is that you can now play with guests, and they keep their items when they arrive. This means I can test the dungeons in the conditions I intend: a party of 2-3 characters working together. That means I can balance the first dungeon or two and get the system out to my alpha testers before too much longer.

Thank goodness.

Finally! Regime Changer

I have now created an external utility to create training regimes for Heroes Life.

It is ugly as sin because basically I hate Java Swing. Swing makes a lot of sense from a data structure standpoint, and it also (in theory) supports responsive design (meaning if you change the size of the window, the components resize or re-arrange themselves to fit the new window.)  In practice, though, it's hard to make anything look aesthetically pleasing. I greatly prefer visual basic's GUI editors.

This interface allows you to edit both training, repeatable, and epic tasks. It lets you load regimes and save regimes.

This was a pain to make, but it represents the first step in going from a program that my wife and I enjoy using to something that can be distributed to more people to enjoy as well.

I'm going to work a little more on trying to make this user friendly and take another pass at beautifying it.

EDIT: That's better. Now it looks somewhat respectable, and help text has been added as well.

Next step is to figure out how on earth to load this from RPGMaker. I mean, RPGMaker does file IO already, but only in a really weird way that emulates the way that a PS1 memory card used to work. Also, RPGMaker has no keyboard support. There's some UI stuff that'll need to be solved to get this to work...

A second party member, more control over help text.

Done. You can now recruit another save file's character into your game.



Sadly, right now, it only works for a single other protagonist. No parties of more than two right now. I need to think about the best way to handle party management. How will you remove party members? How will you "Update" party members if you want to use the most recent version of your friend's character? There are still some logistical challenges to solve.



Also, I ended up learning a lot about the CommandWindow source code and the debugging tools bundled with RPGMaker MV as I solved a different problem. It was important that you could not swap out the equipment on "guest" characters, because otherwise, you could recruit a friends character, take all his stuff, dismiss him, then have your friend "update" his save file (refreshing his stuff) and you could rob him again for essentially infinite items. To prevent this, I made it so you could not alter the equipment of guest characters. Problem is, it was hard for the player to realize this; there was just an annoying "Buzz" sound when they tried with no other feedback. To solve this, I dove into the code and figured out how to replace the "updateHelpWindow" function on the equip command window to give each command a sentence of help text. And if you are in the equip screen of a non-party member...



...It'll let you know in nice shiny text why precisely you get a buzzing sound every time you try to mess with the guest's equipment.

Recruiting other Saves!

Sorry for the week delay. My parents were in town for a week, so we took a "Stay at home vacation".

At any rate, Today's progress (and Mondays) was to work on the algorithm that lets you recruit the main characters from other save files.

I wanted the Gamification framework to have a social element; I pictures families or groups of children playing this game together, motivating each other to do homework or chores. The problem was, whenever my wife and I played this during testing, we'd end up having a hard time with it. The game needed to "live" on either my computer or hers, and so if she did chores but I was using my computer, I'd have to get off for long enough for her to start the game, get in, and record her work. Likewise, we'd have the same problem if the game was on her computer. Also, if we wanted to do a dungeon run, it felt bad to do it alone, but sometimes our schedules wouldn't line up so we could do the dungeon together.

The end solution to this, I feel, would be for each player's game to be separate, but for players to be able to "recruit" their friends on the same network. So, I have a character that I run and my wife has one that she runs, but my character can (with her permission) make a "guest appearance" in her game and vice versa.

Later, I'll want to do it over the network, but for now, I'm just making it so you can recruit the main characters from other save games.

I don't quite have it adding the other protagonists to your party yet, but here's a picture of the loaded protagonists in the tavern waiting for recruitment, all wearing their gray newbie robes.