January 02015, on Witness to Unity

I haven't posted about Witness to Unity in a while. Given the amount of work and general back-and-forth a lot of code can be, I'll try to be a bit more general for this post, covering some design thoughts and some code thoughts.

Equipped for Battle

Designing equipment and the party's base stats has been interesting. I've been designing the database entries in a text file first to get them donw or compare them, before I then put them into the game itself. When working out how equipment influences elements, I would then put the number of items that weak/null/defend/etc. each element into a spreadsheet so I could total each element or affinity. This was a good idea, as I intially found equipment had a large number of weakness-causing traits, and less defences. Which for armour is, well, dumb.

Working like this has also allowed me to determine the equipment categories and character pseudo-classes, so I can design their stats around that, and give equipment items that enable classes to gain temporary skills to compensate for whatever shortcomings they have. My hope is that this allows the player to have a simplified form of custom builds for some challenges.

Element Understanding

Remember how I discussed intelligent enemies and mentioned that I was getting my trues and falses mixed up? Well they were still mixed up. With regards to the ability to check for element rates, I had written the code completely wrong. I fixed this so that an enemy can now actually break element immunity and target a character that now will take neutral damage.

Because element reflection is different to element weakness/immunity, this also had to be appended to the AI code, so both null and reflect states can be negated by a Break spell.

Meeting Your Target

Accuracy was imbalanced. The change of hitting your target is based off of comparing the agility of the attacker and the target, along with hit and evasion rates. The latter isn't so important here. The problem is that I code to the effect of (user.agi / target.agi) / 1.1, meaning that if two battlers with equal agility fought, their accuracy would be 90%.

This didn't feel balanced with how agility influences turn count - characters with even amounts of turns ought to be consistenly meeting each other's hits. Simple enough, the alteration is now an additional 30%, as opposed to a subtraction of 10%. (And not dividing it by a float, for some stupid reason.)

Quest Structure

Instead of a single quest to follow, the player is given the freedom to explore, recruit party members, complete their personal quests, and then fight the final boss after a certain amount of time before it causes the End of Everything. Time flows via sleeping and in-game days - it's a gameplay design rather influenced by modern Persona. The days influence the status of the game world, and time left to prepare for the end boss.

When I first thought on the concept, there were a number of holes and oversights on my part. Over time, I went over a few ideas on a way to exploit this system to deliver certain ideas, themes, or as a meta-fictional theme. Eventually I turned back on a few ideas for a number of reasons. At the moment I am the only person working on this game, so I really ought to be working at a level one person can feasibly handle. The second reason would be that if I can still deliver some theme or what-have-you using a simpler system, or that certain elements are not as important and could be dropped, then that is what I should do.

There then comes a question about this mechanic, though. Should the player be allowed to sleep whenever they want? In Persona, sleeping early in a day lets you, well, spend the whole day sleeping. In terms of mechanics this lets you improve your character's condition if you royally screwed up. In Witness to Unity my question is instead this - should I let the player easily corner themselves and have to start over?

Is there an advantage to punishing the player for sleeping too much? Or should I keep it that you can only sleep after a story element? Sleeping isn't the only way to recover the party's condition, of course. The player can go to eateries and pay money for food. ... or use items. Eateries would be essentially the classic RPG inn (no in-setting flow of time), so any downside to that mechanic would also apply to other RPGs doing similar.

It's question of if this mechanic serves a more narrative purpose, or a more gameplay/difficulty purpose. Mechanics don't have to be exclusively one or the other, but how I handle it could say different things. Giving the player the option for free recovery at the expense of time could deliver a message about focus and putting aside everything for a certain goal. Not giving the player that option would focus on anything delivered in the dialogue, or other mechanics.

Wow I went on a tangent there. But okay. I'm still rather early stages about this project, but I also want to be sure I'm getting things right in my plans. So long as there's a bit of freedom to this game, I don't want something do go wrong and create a snowball through the threads of gameplay, getting me thoroughly lost in how to rectify things.

That, or I just need to relax.

Tuesday, 20th January 02015

blog, games, witness to unity.