sonc (Patreon)

it hasn't been the best week, but i'm eager to go forward.
on the other hand, engage is fun. i've been taking notes.
wow, the animations...
and the wolfies!!

but it's a little bit hard to look at this beautiful, ornate house that's just been opened for touring. there's so many rooms, all elegantly furnished... i don't always enjoy the choice of decor, but it's impossible to deny the grandeur of it.
i also want to add a sunroom someday, or perhaps we can make furniture like that too.
ah, i'd wanted to add a painting like the one they hung in the hall too, so that's a point of originality i've lost by speed.
after touring a finished house, it's challenging to go back and look at the one i'm building. they've got faux-diamant chandeliers and i'm still over here pouring concrete to replace bits of the foundation.

but i stand by what i said at the end of my last post. i have somewhere to put that energy, and that's really all i need. i'd like to do so for everyone who's been supportive all this time too.
in the end, there's nothing to do but lay another brick.

the last few days have been productive for me, but in a sprawling sort of way. i've been working on writing and eventing for the prologue battle. for much of this, i'm still dusting off the old tools and workarounds that i had set up for the demo, used exactly once, and then broke half of them through refactors two years later. it takes a bit of getting used to and sometimes some clean up, but the solutions usually exist.

they are not, however, usually good solutions. one thing i've evidently learned in the past two years since writing much of this code is how to prioritize readability and workflow. here's an example from yesterday:

we have in-combat dialogue, like when star talks to zaharald. but we need that dialogue to only play once. after all, it's not like the characters would have the same conversation again and again. but this dialogue is called on each new round of combat.

of course, i wrote some code to cover this in the demo. it looked like this:

...it goes off the side of the screen. annoying. but it worked!!!

however, it is not pleasant or readable, and if i'm in an eventing flow, i don't want to stop and have to worry about all the stuff that i need to copy paste and then fix something that's gone off the side.

we can make this a lot more friendly to work with with a few friendly functions:

this all does the same as the above, but then in the actual eventing breakdown it looks like this:

you don't need to know programming to see that that's much nicer. it doesn't take long to do, and it's likely to improve my workflow in the future.

another example from today. i'm trying to fix the transition between combat and a cutscene, but because the player's turn finished after the combat completed, the turn announcement interrupts the scene-- ENEMY'S TURN smack over the message box. awkward.

looking at the demo, i see how i got around this before:

someone who knows programming can probably see how desperate and shoddy the above is. someone who doesn't probably looks at these series of numbers at the end and thinks "????". both are correct. this is code to unwait/refresh each unit on the player's team just in case they had moved, because if it was the last unit to move, then we get interrupted. 

one might wonder why we don't just stop the interruption from happening mid-cutscene. I was exploring that today and haven't found a good solution.
one might also wonder why i don't just loop through the array like a normal person instead of manually checking to see if lynnoe is separated at the time. i don't have an answer for that one. let's go with drugs and/or satan.

anyway, it sucks.

so my play here was to fold the unwaiting (in a normal reasonable loop) into the prepScene command that's already there. simple. but then I look at the unwait handling and see that I don't actually have a good way to loop through just a single team-- i can either do a specific unit, or all teams, but not just one team...
weird, but okay, that's a quick enough refactor... 

...but the actual function is:

...messy.
again, you don't need to know code to know that that looks ugly.

a common theme in our refactors has been taking everything running through arrays (lists of properties detailing, A and then B and then C in a specific order) and converting it to objects (data which has properties attached to it in an inherent structure, which in practice means that we can set and call A B or C without worrying about the order it's presented in).

...why was everything in arrays in the first place?
i was still coding in the past.... ruby (for reborn) is an object-oriented language but i shied away from so much of it when i didn't understand essentials base structure. so many of my coding practices were still based off of php (for the website), which has much less friendly code tools. 

anyway, this is how trying to fix (1) issue turned into a refactor affecting the entire battle system.
there's a concern here about scope and spending too much time refactoring. if i thought it would take more than a couple hours i wouldn't have done it. but did you know that VScode has really good regex find and replace features? i didn't until today.

so let's now take a look at this same function after a bit of clean up

notice how it is now three lines long. we could make cass proud and make it one if we wanted. but even someone who doesn't program can probably read this and understand what's happening here.
i did add a bit of functionality on top of that so that we -can- call a specific team now as well, but the real benefit here is just in helping code be readable, because that's ultimately going to speed up the other programmer's work too.

i wish to acquire the nyoom.
i will Become sonic.
sonc the hej hong.
gotta eat chili docks.

but this is how things are going-- i try to do something simple to push the game forward, and it turns into three cats and a Project, but each time that happens the stability and/or workflow will improve a bit. so, maybe that's okay. 

gota go fas