Pushing through


(In good times and bad, this song is a absolute f*cking banger. Where did music go?)

Had a great day of dev yesterday, 14 hours. To be fair 3 of those hours was getting the item system to insert an apostrophe into possessive words that are enum entries while my brain was utterly melted...

Gamedev is so weird, after all this time I thought I would be most happy about the mechanics of all the cool things in the game. Lifetaps, stuns, armor forumlas. NOPE! The thing i'm most happy for is I've almost sewn up the logic reference to upgrade values.

There's this maddening issue that plagues me through dev, "Is this value a multiplier or a scaler?". Like is this 10% or is it 110% percent? Should I add this or multiply this against something to get that 10% bonus? It sounds so simple, but it really isn't. And how do you display that value? If it's a single percent: .01, then you have to multiply it by 100 to get it to display as 1% and not .01%, and you have to be sure to round it or it's going to display as 1.0% and not 1%. This is for every single variable in your game that you have to manage that you want to show in the UI and to modify gameplay values.

This is the tricky thing about gamedev, it's rarely as simple as just getting something in and working, you need it in and working and displaying in the UI so the player can see what it does. You THINK that the hard part is going to be getting it in the game and doing the thing it's supposed to do, make the game more fun. So you get that in and you think, HUZZAH! ALL DOWNHILL FROM HERE! And then you start to try to display in in the UI and you realize, "Wait, this isn't showing the right value? Why is it showing 250% in the UI? It should be 150%!" and then you go in to try to fix it and you start messing with values and week goes by and you go back in to adjust something and you have all this  bloat, "Wait, which one of these is the functional value and which one ties into the UI?" I can't remember if this is already modified to be a multiplier or not...

After hours and hours of adjusting things and tweaking and tuning you go into your code and your brain is fried and you're prone to mistakes and the last thing you want to deal with is that NAGGING DAMNED MULTIPLIER DEBACLE THAT HAS PLAUGED YOUR PROJECT FOREVER.



I'm fast approaching the point all that nonsense will be a thing of the past. Just need to set up the preset for growth types and i'll never have to worry about this shit again. It will "just work"

I thought I was almost done a bit ago, but every time I had to go in and define if something was a multiplier (adds 1 so it can be multiplied against a value to bestow proper values, so if it's value is .1, you don't want to multply that flat value or you'll end up with a90% penalty not a 10% bonus. You can't simply make this value 1.1, because if you want to double this value to make it a 20% bonus, you would end up double it up to 220%. It's all so simple math in our heads, but in practice, it takes a bit of setup to make the pulling of these values behave in a natural fashion.

So i'm really excited that soon i'll just say, Oh this value is essentially an "approaches0divisor" which basically means an armor value, it will never reach 0 but it gets darned close. I don't need to tell it if it's displayed as a percentage, if the value needs to be rounded above zero, if it needs to be multiplied by 100 so that it can be displayed as a percentage in the UI. ALL of that will be taken care of internally, I will simply tell the variable what kind of upgrade it is, and then BOOM! It spits out the appropriate values depending on its level for the game logic, while communicating with UI elements the proper values.

That's the really nasty thing about game dev. We have to do everything so many damned times. First it has to work in the game, then it has to work with the UI, it has to work with the wacky edge cases, it has to work with the proper order of assets triggering in different orders and communicating with one another at different times, often erasing orders we wanted from other sources. Gamedev is one giant mess of half formed ideas and wonky short cuts all fighting with one another to exist and if a single solitary element misbehaves in the slightest way, the entire thing crashes and explodes.

Oh! I had this idea for a new blog I might try in the future if I burn out and can't get to work, I was thinking of calling it "just the tip" and it would be a very condensed very to the point Unity series on best practices that I think would resonate with a lot of people as there is just SO MUCH to know about gamedev and in all the chaos, we don't always learn very broad, important things and ways of thinking. We often fixate singular elements of our game like getting  a cool post process glow, or an animation, but less sexy things like scene organizations, naming conventions, and coding foundational setups are so so much more important and rewarding long term if you want to go the distance with your project.

Today is not going to be fun, but I'm going to be so relieved when this system works and I never have to deal with this sh*t again.

Speaking of, here's  a trick I learned from a kind soul on the Unity forums on how you can deal with enums in a way that is actually tolerable and allows for some small amount of wiggle room to adjust it:

instead of creating something like

None,

small,

medium,

large

make this:

None = 1,

small = 2,

medium = 3,

large =4

This way if in the future you want to get rid of medium and replace it with ULTRA BIG ASS SHIT and you want to reorder it a little you can do

None = 1,

large = 4,

ULTRA BIG ASS SHIT = 3,

small = 2

And all the existing content you have in the game won't have all their innards rearranged.

I need to find the right balance of tuning the internal logic, and setting up the actual upgrades because the two work together, neither side should fully dictate the pipeline, gotta bounce between code and design to find the optimal setups. Too much time in code it works perfectly but it doesn't do what you want, too much indulgence in design and you end up wanting to create a system with no form that's impossible to work with with infinite edge cases. I need to learn to take deep breathes and just try to enjoy the process of ping ponging as much as possible without stressing moving on to making the game too much.

It never ceases to amaze me how much I obsess about getting to adding the fish to the game, adding their abilities, setting up items, and thinking that's where the game is going to be made. But that's not gamedev. Gamedev is pulling your hair out at 3 in the morning after hours of failure wondering how to get apostrophes to be put into your possessive item names, it's rebuilding each and every force value after you made the heart wrenching decision to invalidate all force values by rescaling your project by a factor of 10 because the person who set the scale 6 years ago didn't know wtf they were doing. It's then redoing your force values again when you decided to improve the mechanics of abilities for the 5th time. It's fixing bug after bug that appear in a myriad of ways from the incalculable # of ways your systems interact with one another. The more ambitious your project is, the more you want to try to improve on the tried and true,  the more it's going to kick your ass, the more you're going to doubt yourself along the way, and the longer you're going to have to stew in the belly of the whale surrounded by failures and regret.

We're not out of the belly just yet, but there's a fire burning.

Get SeaCrit

Leave a comment

Log in with itch.io to leave a comment.