devlog # 9 // life updates + new systems (UI, character stats, turn-based system)
so, I’ve been away for what feels like a year - there are a million things I could share. first, let me update you on life things, then tell you a bit about what I’ve worked on in-game. as far as life things, I have been t i r e d. and with autumn (my favorite season) here, the desire to cuddle and sleep all day is strong.
part of what’s been keeping me so tired is also that I both started uni studies and have a new job. in the last blog, I mentioned I was thinking of going to university for further studies in computer science and all. well, thanks to a few people’s generosity (and many, many phone calls, emails, etc), I did get signed up in time! I have been absolutely in love with the things I’ve been learning in my first computer science class ever; even though it teaches Java, I have found that everything I’m learning is very easy to translate into C# and what I’m building in Unity. each day, I feel more confident in my coding, so much so that nearly everything I’ve done in the past month has been entirely from my mind, just free-coding, without any tutorial or other guidance. it is really amazing to feel like I can code up a system in my mind, even when I am away from a computer, and then sit down and type it out and it run exactly as I intended. while my studies and my new job (not especially difficult, but asks but for many hours each week; consider supporting me on Patreon so I don’t need to work as much?) keep me busy and often fatigued, I have been reclaiming time to code things I love and am really excited about - and I’d like to share with you a couple of things I’ve recently built. (edit: I just realised that a lot of the images are blurry :( will think on a fix for this)
where we left off with the last devlog, I was working a lot on the systems to build up the physical world: tile generation, interactables, biomes, and the like. I did actually work on some other parts of the world and visuals (will share that in a near future devlog!), but more and more lately, I’ve been feeling like what will really keep me excited and focused, to feel like I’ve reached a solid checkpoint in my development, is being able to actually *play* the game. even if it’s repetitive, only one area, or without animations, being able to press play and move characters around and interact is something I know will excite me. so, that’s what I’ve been working towards. there are a handful of pieces I can identify between where the game was last devlog and what it needs to be minimally playable: - a basic UI that shows character stats - a system to calculate and update the stats to be displayed - a system to keep track of turns automatically - for the UI or world to display player choices accurately - at least a couple interactive actions the player can take, besides moving (damaging health, defending, etc) I started with making a basic character stat UI and a behind-the-scenes calculator. note: since we’re working mainly on systems in this devlog, I’m going to be sharing a lot of code talk. but maybe you’re into that sort of thing. also remember that my focus in each of these pieces is not to make something gorgeous or especially well-organised; my focus is to make something that works (though I am always thinking about optimisation and other possible patterns along the way).
so, this is what the first UI for character stats looks like! I modeled this as a basic idea of how you might make a UI for creating a character and being able to preview their stats - both the base ones (like might and agility) and also a few of the compound ones (health, stamina, mana).
in this version, a player can choose an inheritance (what other games call “race”), a birth sign, and a primary class (though you won’t be able to choose it from the start like this in the game). each of these choices contributes modifiers which change the stats, which is calculated altogether when you press the left or right buttons. (again, these are not all the inheritances, signs, or classes in the game)
here’s a bit of the magick code that makes this happen:
as you can (hopefully?) see, I’m calling methods (CalculateClassValueMIT, etc) to get the relevant stat values and multiplying those against a magic number (eep!) and the character’s inheritance scaling. what you might you also notice here is that these calculations are hard-coded to a given attribute (might, dexterity, intellect, etc); along with MIT, each of the other five attributes has its own calculation method. I really hate this because I know there has to be another way to do it, but this is the way I know how to do so far - feel free to message me other patterns! (for example, I’ve seen people make a Stat class, but I don’t really get that yet?) then, while I was feeling a bit playful with UI and stats, I thought I would spend a day making a prototype of a “charisma interaction” system. by this, I mean that - in the game - characters will be able to use their interpersonal skills to be able to navigate certain quests, get more information, and the like. charisma pairs with each of the other attributes to give a certain way of interacting; for example, charisma and might could be interpreted as aggression, intimidation, using one’s size or boldness to gain favor. pairing charisma with will could render an interaction more focused on relating, understanding, and empathising. you can see some of might interaction here.
what’s shown in this is that Joseph, the unit kind enough to help with our testing, responds to your might interaction attempt with various phrases. behind the scenes, Joseph has their own inheritance, signs, and other traits, and when you click, these + a random roll are used to calculate *how* Joseph responds. in this case, Joseph has a primary sign of Aries, which inclines them to respond well to your might-based attempts (you’re in luck!). even when Joseph declines your attempts or chooses to stop talking about a subject (just wait some days for them to open up again), they will tell you that they mostly like how you’ve approached them, even if it didn’t work this time - a character with Virgo as a primary sign, however, might tell you off on your first attempt and refuse to interact further with you. rather than just a few pre-programmed dialogues, I am interested in the game having a more procedural, somewhat organic feel. also, in the actual game, Joseph will have slightly less patience; you won’t be able to keep clicking, only able to make an attempt twice in a day before the character closes that interaction. while the gif above shows many of the responses and reveal that there are just a handful of phrases this character will use, a player won’t see these in succession like this, so hopefully, the organic, personal feeling will be maintained. and again, in the future, I intend to make this more complex, not just button pressing. here’s some of the behind the scenes to how the aries sign is built. each sign is a scriptable object with these same parameters.
the basics of how a sentence is formed:
and what happens when you press the MIT button:
and the last thing to share today is about the turn-based system. I knew this was an important step in moving us closer to a playable version of the game.
take a look, and then I’ll explain.
feel free to rewatch a few times, since there’s a lot to notice.
first, I approached this system by defining exactly what makes up a turn. during a turn, the player will have four basic opportunities for choices: a first movement, an action, a secondary action (if the first was a half-action), and a second movement (if the character has any remaining movement). these are the phases that the character sees and directly interacts with. then, beyond/around that, each turn also needs to initialise a player and update any status effects (status phase), figure out who’s next and adjust each character’s place in the list (priority phase), and see if the battle conditions have been met or if a next turn is needed (check phase).
here’s a closer look at some of the phases in code:
the basic setup is that the player interacts by pressing buttons when their input is needed, then the code moves through the phases depending on numerous factors: if the player used up all their movement, if they have action remaining, if they have a status (sleep? paralysed?) that will skip their turn, which phase it is currently ..
I have seen other approaches to coding a state machine (which I guess is what this is?) that I didn’t understand very much at all, and I am excited about this code because I know it came from me and all the things I’ve learned over my short time coding. importantly, i am excited because it works.
whew.
so, what’s next?
well, I’ve built these systems solo (separate from the rest of the game systems) so that I could really polish them (as much as one polishes prototypes :p) before moving them into the fray. so, a next step is to integrate both the stat UI and the turn-based system into the rest. to make it so that a player can pull up a fuller UI with a key press. to show a constant UI indicating which units are involved in an interaction, maybe with some predictive stats (chance of hit). and to have the player’s “movement button press” actually be them choosing which tile to move to, calculating automatically if that is their full movement range, and a much prettier (radial?) UI for selecting actions .. let’s not get ahead of ourselves. one thing at a time. I will keep working at it, with my plan being to get a workable version running this weekend, so maybe check back soon. and if you’d like to support me or get some behind the scene insights or help with building your game, do check out my Patreon - I would love for you to join my party: patreon.com/ahnmakes ✨✨ otherwise, I’ll see you in the next devlog! with love and need for a long, long sleep, ahn






