Pre-Alpha Progress Update 2: First Feedback and Huge Bugs
Updates first
Okay, so let’s start with what I actually did these last few days. First, I split the menus from one large task to smaller tasks, and then second I split the skill upgrades into implementation and UI. With that in mind, the new progress is:
[x] Pause Menu with Help Screen
[x] Passive Skills
[x] Skill Upgrades
[x] Skill Replacement (logic)
[ ] Skill Replacement (UI)
[x] Actual Dice models
[x] More enemies and bosses
[x] No sounds
[ ] No visual/particle effects
Passives ended up not being too complicated to implement. I just needed a way to find all the passives equipped on the player and then take them into account before dealing or receiving damage. The Skill
class already has an ApplyEffect()
function, so I pass any relevant passive skills into that, and the skill decides if the passive should have an effect. Simple.
With thatin place, I decided to give a release to some close friends and family to start hearing their feedback, and fortunately, it wasn’t as bad as I was expecting.
There where some interesting issues, though, and I want to discuss them here, hence making this a Tech Discussion post and not an Update or Design session.
The Bad
General Feedback
The first bit of feedback actually came from my wife, and that was confusion. I quickly realized that, unless you’ve been following my devlogs or are part of my brainstorming chats, since there is no Tutorial or Help screen, it’s kinda confusing to get started.
I suspected this might be an issue, but given that the people who I gave this early copy to kinda new what I was doing, I was somewhat surprised by how confusing it was. So I decided to add some instructions and some help screen items on the main and pause menus, and gave them a new release, and that seemed to help.
That was the biggest bit of negative feedback; no-one commented on the jank UI and free assets because they realize everything is still for prototyping, and fortunately the mechanics mostly worked as expected.
Mostly.
First Bug: Broken Skills
My buddy sent me a screenshot of the Heal skill not working, and then I was confused. The version I gave them worked for me, so I went and checked what’s going on, and it turns out, the second release I did with the help screens, I removed some stuff by accident.
Turns out, when working with Scriptable Objects, the FormerlySerializedAs
attribute is really important.
I was getting annoyed by having it in my code and just taking up space, so I removed it, thinking I made that change ages ago, shouldn’t be an issue. Turns out, the Heal Skill was the only one I never touched again, so it was actually still using the old field name.
Doh.
Easy fix though, so got another release out pretty quick.
Second Bug: The Doozy
Turns out, I didn’t understand Scriptable Objects or how they are supposed to be used. For some context, I created a public class Skill : ScriptableObject
so that I can use the CreateAssetMenu
Attribute and create new skills in the Editor. I also figured skills should be fairly static, so having something that is effectively a persistent data object should be fine.
And it was, until I wanted to be able to upgrade skills. I either needed to create a skill for each level, or I needed a field that had upgrade info and some state for tracking the level. I created a
[Serializable]
public class SkillInfo
{
public string damageAmount;
public float criticalMultiplier;
and then gave my Skill
a
[SerializeField] private SkillInfo[] infoPerLevel;
[NonSerialized] private int _currentLevel = 1;
which then let me increment the state without it being serialized, so between loads it would reset the state back to 1 and everything will be fine.
Except it wasn’t.
It was fine in the editor when I start a game and stop a game. It was fine in the release if I played then quit and played again. But what I didn’t realize is; Scriptable Objects are persisted between scenes.
So using my fancy new Pause menu with the “Return to Menu” button, I could fight some waves, level some skills, restart the game, and start with upgraded skills.
Obviously not intended. As my buddy said when I pointed it out:
Accidental heritage mechanic is accidental
This was a lot trickier to fix. I could just not use ScriptableObjects, but they are so nice, and being able to modify them in the editor is great. I don’t want them to be MonoBehaviours, and as pure C# classes I couldn’t find a way to edit them in the editor, only code.
I don’t want this post to go on forever, but I might do a follow up, because I managed to solve it by wrapping the ScriptableObject with a “Runtime” class. Basically, for my public class Skill : ScriptableObject
I have a companion class
public class RuntimeSkill
{
private Skill _skillData;
public RuntimeSkill(Skill skillData)
{
_skillData = skillData;
}
// methods moved from Skill to here...
}
I moved all the custom methods from Skill
to RuntimeSkill
, added a public RuntimeSkill AsRuntimeSkill()
method to it, and created getters for all the fields (so I can also have a RuntimeSkillInfo
companion for SkillInfo
and the getter can then do the conversion for me).
This way my code can use the runtime instance of the data without modifying the source; anything that isn’t a simple getter needs to happen on the Class, not the ScriptableObject.
And this fixed my issue. After modifying 43 source files. Oh well.
The Good
Overall, the three people I gave the game too seemed to enjoy it. Once they understood the mechanics, they enjoyed it, and turns out my fears about RNG being too brutal was unfounded.
The way the weighted dice mechanic works is that you have a 44% chance (4/9) of rolling your choice, as opposed to a 16.7% (1/6) chance, and for healing that chance is 50% (5/10). I can still tweak these, but so far this seems to give a nice balance between getting what you want and being reminded that rolling dice is a gamble.
Sounds like the win/loss ratio for rounds played was about 2:1, which is fine for a prototype I think.
So yeah, pretty happy with that feedback.
What’s next
Well, first up, a few days rest. I go back to my real job in a few days, since my PTO is almost up, and I still want to spend some time with my wife.
I may have become a little obsessed with this project. Just a little.
That said, my Trello has been updated, and I have a ton of things I want to do.
How many of these will make it into the the Feb release? No idea. I’m still focusing on mechanics and core gameplay loop first, before I start “making it pretty” using the Assets I purchased.
So yeah, that’s it for now. I’ll probably post again in a few days, maybe a week or so. I have another week in Feb coming up where I’ll have some time in the evenings to work on this again while my wife is on a trip, so hopfully I can make some good progress then
In the meantime, enjoy the video update of the current state of the game ^_^
Get So this is how I DIE
So this is how I DIE
Horde survival custom dice roller. Oh yes.
Status | Prototype |
Author | DuhblinnZA |
Genre | Role Playing |
Tags | 3D, Dice, Indie, Roguelite, Turn-Based Combat, Unity |
More posts
- You snooze you lose 😴51 days ago
- Time doesn't necessarily happen in chronological order.92 days ago
- Not dead yet...💀🎲Apr 20, 2024
- Thank you 🫶 (also, what's next)Mar 11, 2024
- We did it! 🥳Mar 01, 2024
- Small update on Alpha Demo releaseFeb 29, 2024
- Pre-Alpha Progress Update 7: Getting close...Feb 28, 2024
- Pre-Alpha Progress Update 6: End of Feb is when!?!Feb 26, 2024
- Pre-Alpha Progress Update 5: I have no idea what I'm doingFeb 18, 2024
- Pre-Alpha Progress Update 4: Scope CreepFeb 11, 2024
Leave a comment
Log in with itch.io to leave a comment.