Once More, with Feeling
Dastardly playtesters have foiled my attempt to call it quits, and gave me a large list of improvements I'll do my best to make, by September 1st.
Since writing devlogs turned out to be fun, and also a way for me to get my errant thoughts into order, I've decided to make this log. If nothing else, as a reminder of what to do. I found that development is a lot more efficient if you have a thinking & designing phase, and then a producing & implementing phase, followed by a testing phase. In my early days having made the design document, helped me immensely. Although part of why I made the design document, was that I wasn't expecting to make a game. Just wanted the thoughts constantly hounding me out, and on paper. Enough reminiscing, here are the next list of features,
Lessons from my lovely playtesters:
Trimming the Script
Everyone knows games are meant to be played first and foremost, and it takes selective cinematic addition on top of that to tolerate longer periods of inactivity. Yakuza is good enough to do that, we are not. I knew that already since the beginning, it is not news to me. I have turned the dense tutorial into a series of story events, inspired by my half a dozenth playthrough of VtMB. Jack doesn't just tell you the controls and mechanics, but also gives you just enough insight into the setting to know what is going on, and be intrigued by it.
My big misstep was after the immediate combat tutorial ended. The player has nothing to do, while I attempt to get the story going, and unleash upon them 84 line of text for 10 minute reading. I feel like I can get across things better by trimming some fat, or re-positioning some scenes.
The area intros especially have been complained about. The narrative goal is that Leon is showing you the city, the practical one is that you know key locations when you enter a district. Still they can be shorter, and more matter-of-fact.
Less is More when it comes to options
Cut down on the amount of combat moves available from the get go. Let players unlock some later instead. My original thought was, that at a basic level everyone knows how to throw a Jab, Left Hook, Right Hook, Uppercut, Cross Punch. To not make the UI look weird, or put kickers at a disadvantage, there should be an even amount of kick options as well. All of this however translates into an overload of options when the player sees the combat screen for the first time. They don't need that confusion, the mechanics are enough. Three punches and three kicks should do, once for each height. Customizing the character with additional moves, comes later.
Frontload More Information
It was suggested that in the menu, the attack names should take on the color corresponding to their height. So you don't have to wonder about if a roundhouse kick is a Mid or a High. Coming form the Tekken school of thought, I took memorizing and practicing for granted, but that is a real-time fighting game, and this is a turn-based RPG! Well that means we have to redo the system, because that is a 2D array built from the available techniques in the beginning of the fight. So better change it back so it has access to every attribute of every technique. It all sounds a lot more complicated than it actually is. (I say that now, I might rue the statement when I try my hand at it.)
Another facet of this, and a super obvious one in hindsight, to have enemies display their health constantly. Back in the bright-eyed design phase, I dreamed that enemies will have their own sprites, showing how damaged they are, but that is simply a budget sink.
A QoL feature I have nowhere else to put: Add a variable that will remember the last selected attack, otherwise cancelling will bring back the player to the first attack (Jab at the moment) all the time, taking them away from their old pick. That is just frustration.
Technique Card Revision
The most obvious in hindsight feedback I got, was to make the technique card a toggle, instead of having to hold down the button for it. Also the cards inside of combat, should display the values that are adjusted by the Combo Counter, not the raw value of the technique.
Time is of the essence - Everyone got confused by day-night phases, but at least nobody thought this time around that they were just bugs. So new feature time: Adding a clock. From the beginning I knew I didn't want to bother with exact hours and minutes, that just breaks immersion, and gives this stressful feeling of hurry to everything, hence the lack of time-measurement, but that is not really a solution. This will be an analogue clock, with different sections of it having different colors, and denoting the phase of the day, and a slowly moving arm. The phases are the same as now: Morning, Noon, Afternoon, Evening, Night.
I'll also add dialogue to the transitions that would progress time, asking the player before doing so. Better to have the player press ENTER twice as they are trekking through areas, than be cheated out of their time by surprise transitions.
Some addendum on my end,
that weren't explicitly said by testers, but they helped me get to the conclusions:
- Review code to use Time Source instead of alarms where appliccable. Counting things in seconds instead of frames.
- While at coloring the different combat options, also grey out the ones that the player don't have enough Fatigue (have too much fatigue? maybe I should reconsider either the display or the naming convenience) are greyed out. So players know they won't be able to pick them in advance.
- Speaking of frontloading information, add another layer to your Fatigue Meter, where the amount of fatigue it takes to use a move will be shown, so players have to consult less with the technique card mid-combat.
- Give more HP to tutorial enemies, and less damage. It is better if new players have extra rounds to wail on them to get the feeling on things, rather than kill them too early, and miss early stages of the tutorial that were meant to build on.
- Have the last attack indicator on an enemy show "Didn't attack yet". Being empty just looks bad, and players might not even figure out what that is for long after now.
- I should add a defeat dialogue to losing on the Playground. It was never meant to be a gameover event, but players shouldn't find out they are out of health when they get into their next fight.
- I have to restore the Random NPC generation. Apparently the idea was feasable, it is the execution that needed an estra step. Using a surface to collect the NPC parts together.
- Controller support I guess. Keyboard controls are not obvious, and I already designed the whole system with a controller in mind, I just never added the.
Wretched bugs to crush:
- The painkiller dispenser in the Playground doesn't tell you when you don't have money, and didn't heal you. Also, Doctor Lazarus won't heal, as a side-effect of me cutting out his incomplete quest for the demo.
- Locking away areas by not opening them on the first day, was a mistake. Players may just wander around until a day passes, then breaking things, as locations get unlocked prematurely
- For some reason, fatigue isn't regained between fights. That is not intended. Unlike health and condition, fatigue shouldn't have to be managed outside of a combat situation.
- Something's wrong with the final dayphase, breaking the whole game.
- Player collision is too big, should be the size of the sprite's shadow
Files
Bainok: City of Fighters
Martial Art RPG
Status | In development |
Author | ManusC |
Genre | Role Playing |
Tags | 16x16, 2D, Pixel Art, Solo RPG |
Leave a comment
Log in with itch.io to leave a comment.