I follow Megan Fox of Glassbottom Games on Twitter. She has done multiple games in Unity and has tweeted a bunch about learning Unreal. Apparently there are a bunch of things that are sort of complicated or messy to do in Unity that are much simpler in Unreal.
I feel a tiny bit called out with the bit about text rendering. In my defense, the text rendering I was using previously was kind of bad.
In the middle of it, a lot of it resonates.
Development:
-Not going to lie, when you go from prototype (wow this engine is handy) to end result (all I want is one more setting!) you'll be hand-rolling.
-The alternative is to really just accept engine limitations and focus on your implementation- with the danger of continuous iterations to get it just right.
-Switching engines will just get you a lot of easy prototype wins, after which, you guessed it... you'll be hand-rolling.
-Either hand-rolling or continuous iteration can be fixed by forcing yourself to ship. I guess shipping unfinished prototypes is another pitfall?
Marketing:
-It seems the current best value for money social media is either Reddit or TikTok.
-Reddit requires a solid mapping of audiences in subreddits and their rulesets.
-Advise for TikTok is to be a mensch.
-Twitter apparently works as a Linked-in for gamedevs, i.e. you have to network, network, network- and in the end you may get some shout-outs?
-Steam digital festivals is where it's at for getting your demo out/game seen. The festival should be a featured one, and select one where the topic ties into your game.
-Discord, I don't know. Once you have players, I suppose? I have a dayjob and a family, so it feels like the input needed matches that of Reddit.
-YouTube and Twitch are more accessible than you think if you have a good game. Just... ask.
-If you're going to buy ads anywhere spend on professional marketing as well as buying views. Mind you, I gleaned this from marketing professionals so as the Dutch say 'Wij van wc-eend'.
Since my games are heavy on visuals and I'm light on time, I'm going to try to market on TikTok. Surprise: that means rewriting my controller tools.
extra: In general, social media is fickle. You know what isn't fickle? Emailing lists. They might not work for every potential user out there, but those who do read their emails will keep reading emails forever and ever even if Musk buys Twitter or TikTok enrolls all teens in the PLA.
Publishing:
-I don't have my notes on this handy, but basically a publisher will want to talk to your alternate accountant self. If you don't log your hours, pay yourself a wage, have all your spending in the books, and most of all have a roadmap on how to find and grow your audience, no publisher you want to talk to you will talk to you. Lots of scammers will.
-I took a business class ages ago, but to be honest I'm far too early in this game to start applying it. That said, I'm slowly building my repertory of assets (scripts) and so I should be accounting it. If your game is 'I prototyped this idea I had and now it goes on .io' you might get away with not knowing busineseese.
-Your elevator pitch should probably be on point, too. But you know what? It should have been the seed of your game. Don't make a game because 'now I can animate sprites'. Make a game because 'It's genre x but I fixed mechanic y and now it's double awesome!'.
Yeah I'm just trying to get to the point where I can just publish a quick and fun game on itch.io. Marketing and making money on my game are distant distant thoughts.
On the same token, maybe that's the secret to Josh Wardle's success? He just made a dumb game for his girlfriend and then it went viral and got bought by a major publisher. Easy-peasy.
"Simple, real stupidity beats artificial intelligence every time." -Mustrum Ridcully in Terry Pratchett's Hogfather p. 142 (HarperPrism 1996)
This week's report is late in the day. Does this mean that I've been putting the finishing touches on some epic feature that's going to take an entire essay to describe? No! I've been playing Sekiro all week. Nevertheless, a few things to document.
On the Nimsters front, I revised the Paralysis status effect again. Now, rather than an instant turn-loss with geometric back-off on how much status damage it takes to inflict the status, Paralysis is now essentially the inverse of Sleep. With the Sleep status effect, you're trying to land on one of the numbers you've already landed on in order to wake up; with Paralysis, every number you land on on the timeline will cancel your move if you land on it again for as many turns as you have stacks of Paralysis. This places Paralysis back among the status effects that progressively get worse the more stacks you have, since the more stacks of Paralysis you have, the more active land-mines you leave on the timeline for yourself.
Behind the scenes, I changed status damage to be tracked as an objective amount (that is, % of the status inflicted) rather than storing it in terms of your Vitality stat. The practical upshot of this is that you can't level up, gain a few points of Vitality, and suddenly not be poisoned / paralyzed / whatever else.
I also penned the Poison and Light-type moves, which just leaves Fighting Force, Psychic, and Dark left, plus random additions to the types I've already completed as I come up with them.
Finally, I implemented the "timeline influence" move effect. Basically, a move can now change the character of the values generated on the timeline by adding a min, max, or averaging function to two rolls, such that the timeline persistently has either lower numbers, higher numbers, numbers closer to the center, more stars, or more Xes.
I am still putting more mental effort than necessary into the idea of fast serialization to a binary format for my primary / action game engine, because the thing about having a day job is it produces long swatches of boredom where designing such a thing is actually the most interesting available option.
This week, ehhh... I'll set a goal of getting those last three types' moves written.
My favorite musical instrument is the air-raid siren.
It turns out that I goofed on the current status of which types had their moves written as of my last post. I hadn't actually committed the Light-type moves yet; I just sketched them out in a notebook. So, though I did hit my goal of getting three types' worth of moves written, those three types were Fighting Force, Psychic, and Light. I would have gone ahead and pushed through to get the Dark moves written as well, but I also goofed in that there was a whole type whose moves I'd forgotten about: Normal Physical. And that type, being everyone's backup type, is closer to a type and a half in terms of how many moves it's going to wind up containing. So, this week's target is about two and a half types' worth of move definitions, at which point I'll be done...ish with that portion of the content phase (I may want to return and do a balance pass / apply some lessons I learned toward the end of the first pass) and can move on to writing Nimster definitions.
... yeah, that's it. Slow week. Blame Aegis Rim.
My favorite musical instrument is the air-raid siren.
Last week I hit my target for velocity while discovering that my starting point was behind expectations; this time my location and target stayed in place while I didn't get as much work done as planned. Call that the Heisenberg Uncertainty Principle of project planning, I guess.
This week I did all the data entry for Dark-type moves. In keeping with the trend of folding multiple Pokemon types into one Nimster type where appropriate, the Dark type in Nimsters strongly resembles the Ghost type on its physical-attack side, with a bunch of jump-out-and-yell-boo attacks and various bite, claw, and horn attacks with diabolically-themed names. The special-attack side is a bunch of more traditional dark magic, with a suite of various combination status effect attacks. One family of moves involves sacrificing HP for gain; "Spite" is an attack that's much stronger than a normal entry-level attack moves, but has a full 50% recoil damage-- which you can either offset with the recovery from "Life Drain", or use to empower "Wrath", which increases in power the fewer HP the user has. The Dark type's defensive moves have a unique character where they refresh for a turn when activated and stack with themselves, thereby becoming more and more dangerous the more often you trigger them. Stare into the abyss, and the abyss stares into you. One last unique aspect of the Dark type is that unlike all other types, the moves that you can use on the X (which otherwise renders all other moves unusable) have no drawbacks. Normally X moves have some kind of painful downside to them (which is still better than just losing your turn entirely), but the Dark type thrives in the conditions that everyone else suffers under.
This week's goal is get the Physical-type moves entered. From there I might proceed to the balance analyzer, just to have some fun with coding before going back into another big data entry phase (writing up stats for the Nimsters I already have concepts for).
My favorite musical instrument is the air-raid siren.
The only item on my docket this week was to write up the basic Physical moves; I completed it. I therefore conclude that the key to hitting your expectations is to lower your expectations.
The Physical type, like the Normal type in Pokemon, is "everyone's secondary type"; it doesn't do anything particularly out of the ordinary mechanically. On the physical(stat)-attack side, the direct attacks come in sets themed around body parts-- claws, teeth, hands, feet, whatever various long appendages the user may have-- and a few sets around gestures like running and jumping. On the special-attack side, Physical owns the concept of sound and the voice, with a few damaging attacks that scream or use sonic waves, and status moves powered by the voice in some way, like lullabies, confounding gibberish, growling, howling, and roaring. On the defensive side, the Physical type has very few Claim-type moves, which generally theme around some kind of effect on the battlefield; I don't think there are many cases where something you do with your body extends to the world around you. Physical's Guard-type moves are similarly basic but stamina-efficient; for instance, "Fly" causes the user to evade "close targeting" attacks (contact and energy blast, but not projectile) for several turns. The one unique aspect of the Physical type is its self-buffing moves; instead of buffing subsequent moves of its own type, it buffs moves according to their targeting-- so, for instance, "Take Aim" boosts the power of subsequent Projectile attacks regardless of type.
In all honesty I probably should have just built out the move list while I was building out everything else, but I'm a sucker for giant data-entry projects. The next step is to start building out the game proper-- adding a map, deciding which of my current Nimster concepts you should be able to find there, and entering stats for those Nimsters, rinse and repeat until the player is the Nimster Battle League Champion. I suspect it will take me several weeks before I'll have something I want to present-- and it'll still be a text-based game in the console whenever it's done. I also have the creeping sensation that there's something I'm forgetting-- Nimster accessory effects or Abilities, most likely, that's going to take more work than it feels like. But we'll cross that bridge when we get to it.
My favorite musical instrument is the air-raid siren.
Haven't posted lately here - I spent about two months working on a procedural sex system, which had a lot going on and I'm sure would be very interesting, but isn't exactly forum friendly, and spent the first half of this month working on fairly basic game functionality - save games, options screens, and so on. I've now gotten enough art assets in from my freelancers though that I can start getting things ready for the visual side of my character creation system. I'm currently going for a somewhat Star Trek-themed uniform system, so the clothing pieces are all broken up so that certain parts of it can be dynamically colored in the game for each ship division. I've also of course ordered up a number of different body tones and pieces to create characters with, especially for the Humans as I imagine people will notice humans who look the same a lot quicker than aliens. I'm keeping things pretty flexible - while most species will have a 'masculine' and a 'feminine' body frame (depending on the nature of the given species), gender markers can be applied on either frame.
This week's report is going to be a whole bunch of cheap starchy filler, because the amount of actual work I got done doesn't even register on the micro-scale. Just felt like spending my evenings (and weekend) playing Okami instead of being productive.
On the Nimsters front, I made a last-ditch effort to have absolutely anything to report on Thursday and typed up the stats for exactly one Nimster-- Squarrel, the game's token Route 1 Trash Mammal. "Fiercely territorial, it will attack anyone who enters its area. However, because it is so weak, it usually loses." Squarrel's unique Ability Attribute is "Pugnacious", which renders it immune to the Fear status effect, but also prevents it from switching out until it is defeated. This complicates the way its evolution branches-- a Squarrel must gain the majority of its experience before the level at which it transforms through direct victories in order to turn into Champmunk. If it gained the majority of its experience points through consolation-prize EXP or watching others fight, it becomes Sourrel, the "left out" Nimster.
I briefly revisited my ECS game architecture this week when I thought I had a way of improving the way components are initialized on creation. As it turns out, my engine may not be well engineered, but it's certainly maximally engineered at this point; the ideas I had to improve it immediately slammed into the same conditions that rendered what I was thinking of impossible as I had to account for the first time. I really cannot do anything with that code any more besides actually make games with it.
On that subject, a half-hearted whim: my parents recently dug up a bunch of my old stuff out of the storage closets, and since I've got a house of my own now they wanted it out of theirs. Which is to say that I've come into possession of several of those rorshach-print notebooks from back when I was like eight years old, and doodled a bunch of absolutely unoriginal game designs (as in, a character who is essentially just Rick the Hamster from Kirby's Dream Land with the fire power, because I thought a fire-breathing hamster was awesome). If I can manage to read through those things without cringing out of my skin, I might find something that could be fun to use as a throwaway project-- avenging the dead dreams of my younger self.
Similar but perpendicular brainwave: instead of creating just one pixel-art retro throwback, make five small ones and sell them as a package under the conceit that it's a collection from some dead 90s-era company that never actually existed.
My favorite musical instrument is the air-raid siren.
My ten year old made a Scratch game featuring hamsters with swords... What I'm saying is you should dump your stupid finished engine, and recode it in scratch. It'll be easy!
Still battling distraction and disinclination, with little success, but some success nonetheless. This week I typed up the stats for those evolved forms of Squarrel-- Champmunk and Sourrel-- and the Route 1 Trash Bird line, Canairy, Cairdinal, and Robairn. I then realized that I'd basically left the starters in their nascent, "get the game off the ground for debugging purposes" forms, and went back and gave the water starter line-- Bubby, Sogidogi, and Pouddle-- more final stats.
- Champmunk gains the Fighting Force type, and the special Attribute "Ambusher", which increases the power of attacks made on the first turn it's out. Almost like showing up and sucker-punching foes who were already weakened were how it got its winning record in the first place...
- Sourrel has the Attribute "Sore Loser", which grants it a weak physical attack when it's forced to retreat. It has a unique Claim-style move called "Cache In" that attacks enemies that land on the space and heals allies that land on it, but only one time each. Sourrel also learns Wildfire, a Claim-type move that causes fire damage to anyone that lands on the claimed space, ally or enemy. Sourrel fights under the assumption that it's going to lose and makes sure that nobody else has any fun either.
- Canairy's Attribute, "Sickly", makes it weaker to the Poison status effect. After evolving, this is replaced with "Wary", which evades any attack made against Cairdinal or Robairn the first turn they're out.
- The Bubby line's Attribute, "Damp", cuts incoming damage from Fire attacks in half (in addition to its natural type resistance). Can't set a wet dog on fire; that's just science. (Not to mention it would be immoral.)
But then, having just typed up these Attributes, I have to admit that I'm having second thoughts about giving Nimsters Attributes at all. I'm not fond of passive effects in RPGs generally speaking, and there's a certain amount of creative load to having to come up with one (even if not necessarily unique) for each Nimster. It's a design element I borrowed from Pokemon essentially by reflex, which for a simple project may be more cognitive load than required. So this week I'm probably going to go ahead and revert the code changes I made to support Attributes, and see how well the game holds up without them. I will probably keep the idea of "Accessories" (that is to say, held items) just to give the player something else to spend their money on and another party-customization option.
Entirely unrelated, I was playing around with concepts for a roguelite character progression system, with the idea of building power by acquiring perks that you could stack multiple copies of to improve their power, with a system of diminishing returns so the player is encouraged to spread the investment in their abilities around (think using Poms of Power to level up Boons in Hades). But then you have to come up with a mathematical function to drive the diminishing returns. Ultimately, here's what I came up with: choose a constant denominator D. The strength of a given perk's effect at level N is (N * D) / (N + D - 1). This always works out so that the perk's power is 100% of its base value at level 1, always increases as you increase N, but increases by less with each level. The choice of D is important-- the lower a value of D you choose, the faster the gain per level drops off. I leave it to you to throw that into Excel and play with the curves if you're actually interested in that sort of thing.
Kupi on
My favorite musical instrument is the air-raid siren.
I've now more or less fully completed my character creator/portrait generator system - I'm still waiting for art assets for one of the playable races, but the functionality is complete, and I've got things set up to create dynamic portraits for both full-body and facial images. I also went through and did some math on how many character variants I have for the various races (not their actual names):
Overall a pretty healthy set of options, although clearly I need to add more color to future races to keep there from being more cases like the all-black insectoids.
That's the last main coding task I have for the initial playable version of the game, but now the time's come for me to actually create a GUI design rather than using the default Unity components. I've never really done GUI design before, but some early experiments with some fonts and buttons are looking promising - at the very least it's an immediate improvement over the defaults.
Still battling distraction and disinclination, with little success, but some success nonetheless. This week I typed up the stats for those evolved forms of Squarrel-- Champmunk and Sourrel-- and the Route 1 Trash Bird line, Canairy, Cairdinal, and Robairn. I then realized that I'd basically left the starters in their nascent, "get the game off the ground for debugging purposes" forms, and went back and gave the water starter line-- Bubby, Sogidogi, and Pouddle-- more final stats.
- Champmunk gains the Fighting Force type, and the special Attribute "Ambusher", which increases the power of attacks made on the first turn it's out. Almost like showing up and sucker-punching foes who were already weakened were how it got its winning record in the first place...
- Sourrel has the Attribute "Sore Loser", which grants it a weak physical attack when it's forced to retreat. It has a unique Claim-style move called "Cache In" that attacks enemies that land on the space and heals allies that land on it, but only one time each. Sourrel also learns Wildfire, a Claim-type move that causes fire damage to anyone that lands on the claimed space, ally or enemy. Sourrel fights under the assumption that it's going to lose and makes sure that nobody else has any fun either.
- Canairy's Attribute, "Sickly", makes it weaker to the Poison status effect. After evolving, this is replaced with "Wary", which evades any attack made against Cairdinal or Robairn the first turn they're out.
- The Bubby line's Attribute, "Damp", cuts incoming damage from Fire attacks in half (in addition to its natural type resistance). Can't set a wet dog on fire; that's just science. (Not to mention it would be immoral.)
But then, having just typed up these Attributes, I have to admit that I'm having second thoughts about giving Nimsters Attributes at all. I'm not fond of passive effects in RPGs generally speaking, and there's a certain amount of creative load to having to come up with one (even if not necessarily unique) for each Nimster. It's a design element I borrowed from Pokemon essentially by reflex, which for a simple project may be more cognitive load than required. So this week I'm probably going to go ahead and revert the code changes I made to support Attributes, and see how well the game holds up without them. I will probably keep the idea of "Accessories" (that is to say, held items) just to give the player something else to spend their money on and another party-customization option.
Entirely unrelated, I was playing around with concepts for a roguelite character progression system, with the idea of building power by acquiring perks that you could stack multiple copies of to improve their power, with a system of diminishing returns so the player is encouraged to spread the investment in their abilities around (think using Poms of Power to level up Boons in Hades). But then you have to come up with a mathematical function to drive the diminishing returns. Ultimately, here's what I came up with: choose a constant denominator D. The strength of a given perk's effect at level N is (N * D) / (N + D - 1). This always works out so that the perk's power is 100% of its base value at level 1, always increases as you increase N, but increases by less with each level. The choice of D is important-- the lower a value of D you choose, the faster the gain per level drops off. I leave it to you to throw that into Excel and play with the curves if you're actually interested in that sort of thing.
Like, what you need here is some sort of visual editor for these. I'm watching you balance this in your head and I'm thinking about my upcoming not yet started fantasy game with loads of species and roles. I'm thinking three weeks dayjob crunch will basically put me back on square one.
Whereas if I had a nice visual interface, probably in another project folder, where I could drag and drop attributes and immediately see repercussions in a matrix of encounters, that would really help me balance it all out. I'll need one for the trade part of it, too.
Still battling distraction and disinclination, with little success, but some success nonetheless. This week I typed up the stats for those evolved forms of Squarrel-- Champmunk and Sourrel-- and the Route 1 Trash Bird line, Canairy, Cairdinal, and Robairn. I then realized that I'd basically left the starters in their nascent, "get the game off the ground for debugging purposes" forms, and went back and gave the water starter line-- Bubby, Sogidogi, and Pouddle-- more final stats.
- Champmunk gains the Fighting Force type, and the special Attribute "Ambusher", which increases the power of attacks made on the first turn it's out. Almost like showing up and sucker-punching foes who were already weakened were how it got its winning record in the first place...
- Sourrel has the Attribute "Sore Loser", which grants it a weak physical attack when it's forced to retreat. It has a unique Claim-style move called "Cache In" that attacks enemies that land on the space and heals allies that land on it, but only one time each. Sourrel also learns Wildfire, a Claim-type move that causes fire damage to anyone that lands on the claimed space, ally or enemy. Sourrel fights under the assumption that it's going to lose and makes sure that nobody else has any fun either.
- Canairy's Attribute, "Sickly", makes it weaker to the Poison status effect. After evolving, this is replaced with "Wary", which evades any attack made against Cairdinal or Robairn the first turn they're out.
- The Bubby line's Attribute, "Damp", cuts incoming damage from Fire attacks in half (in addition to its natural type resistance). Can't set a wet dog on fire; that's just science. (Not to mention it would be immoral.)
But then, having just typed up these Attributes, I have to admit that I'm having second thoughts about giving Nimsters Attributes at all. I'm not fond of passive effects in RPGs generally speaking, and there's a certain amount of creative load to having to come up with one (even if not necessarily unique) for each Nimster. It's a design element I borrowed from Pokemon essentially by reflex, which for a simple project may be more cognitive load than required. So this week I'm probably going to go ahead and revert the code changes I made to support Attributes, and see how well the game holds up without them. I will probably keep the idea of "Accessories" (that is to say, held items) just to give the player something else to spend their money on and another party-customization option.
Entirely unrelated, I was playing around with concepts for a roguelite character progression system, with the idea of building power by acquiring perks that you could stack multiple copies of to improve their power, with a system of diminishing returns so the player is encouraged to spread the investment in their abilities around (think using Poms of Power to level up Boons in Hades). But then you have to come up with a mathematical function to drive the diminishing returns. Ultimately, here's what I came up with: choose a constant denominator D. The strength of a given perk's effect at level N is (N * D) / (N + D - 1). This always works out so that the perk's power is 100% of its base value at level 1, always increases as you increase N, but increases by less with each level. The choice of D is important-- the lower a value of D you choose, the faster the gain per level drops off. I leave it to you to throw that into Excel and play with the curves if you're actually interested in that sort of thing.
Like, what you need here is some sort of visual editor for these. I'm watching you balance this in your head and I'm thinking about my upcoming not yet started fantasy game with loads of species and roles. I'm thinking three weeks dayjob crunch will basically put me back on square one.
Whereas if I had a nice visual interface, probably in another project folder, where I could drag and drop attributes and immediately see repercussions in a matrix of encounters, that would really help me balance it all out. I'll need one for the trade part of it, too.
Heh... the irony with that suggestion being that the whole reason I've been doing everything in typed JSON was because Nimsters was supposed to be a project that wasn't as heavyweight as my Monogame-based engine. That, and since I started building it on a Mac, I didn't have ready access to a built-in C# UI editor that I knew how to use. But a simple editor would probably be for the best in the long run, especially since maps pretty much have to be drawn rather than described. I'll make that a priority for next week.
My favorite musical instrument is the air-raid siren.
A few examples of my early GUI design work (pause menu, save menu, ship info frame):
My design goal is to basically use Star Trek's LCARS as an inspiration, though upgrading to the superior sci-fi shape of octagons to avoid being sued keep things unique.
I continue to advance at a weak plod. I've been applying some new time-management techniques during the day job, which I think is keeping me sufficiently focused on work during the daylight hours that I hit the evening with little will to do anything but relax and play games. That tells me that I need to focus my game work on the weekends.
I rounded out the evolutionary line of the starter Nimsters by speccing out the Grass Plant-type starter's evolution chain. Bunja, described in-game as looking like a small green chew-toy with angry eyes, has almost nothing but physical attack power. On transforming into Ronibble, it gains a bipedal gait and a large novelty carrot it wields like a sword. This gives it access to the unique move Carrotana, which, unlike most attacks that can be used between a minimum and maximum value on the timeline, is usable on two separate numbers, 0 and 9. After levelling up further and transforming into Samurabbit, it gains another unique move, Bunshido, which is simultaneously an evade and a block with a counter-attack. (Meaning, it will negate incoming attacks used on numbers higher than it (the evade) and attacks used on numbers lower than it (the block).) What keeps this in check (other than the opponent having a self-targeted move and refusing to attack on the guard turn) is that it can only be activated on the numbers 4 and 5.
My plan for the coming week is to take Cornucopiist's advice and create a visual builder for these data files, which will hopefully bait me into actually presenting some enthusiasm for the work.
My favorite musical instrument is the air-raid siren.
Can someone point me in the right direction to get started on fluid simulation in Unity? I want to make a 2D thing that is like a planet with a large body of water, I can remove a chunk of that water and then it will slowly fill in the gap. I'm having trouble getting started partly because gravity goes to the middle of the planet, not just down. I also need to be able to edit viscosity easily, if that matters. Any help would be appreciated, I'm not asking you to make it for me, just point at a useful tutorial or something would be great.
I think you need a radius rather than a gravity simulator? I haven't done it myself, but looks like another way to go would be a shader (bear with me) acting on the vertices of a disk.
I think Cornucopiist's solution would also result in much less processing time too. So depending on the scale of your planet you might want to consider it.
"Simple, real stupidity beats artificial intelligence every time." -Mustrum Ridcully in Terry Pratchett's Hogfather p. 142 (HarperPrism 1996)
In the process of reflecting on how I spend my time (generally, not with exact measurements), I've found that the Penny-Arcade boards consume a lot of my personal hours, and predominantly in a lurking mode rather than posting. As an escalation in getting myself out of that mode, I gave the Penny-Arcade domain a failing redirect in my tower PC's hosts file, which I find is a harder mechanism to revert than most of the other productivity / content-control software I've used. I normally wouldn't mention that, but this week's topics are things I would normally use visual aids, screenshots, and videos to help explain, which I don't have access to from my laptop (physically only available around lunchtime). All this to say: I'm forced to used words to describe things that are better described with pictures, and a picture is worth a thousand words...
Anyway, two projects this week. On the platform-game side, I added elasticity to platforming physics interactions. I don't know if that's exactly the right term, but it's the one I'm using. The problem I was facing is that velocity was perfectly preserved when deflecting across a surface; if you bounce off of a wall, you continue upward with the same velocity as you had when you struck the wall. This lead to an odd situation where you could fall into a half-pipe, strike a non-walkable section of the floor, deflect across the surface normal, fly with enough speed to strike the opposite side of the half-pipe on a non-walkable section, deflect across that, and wind up traveling upward with exactly as much speed (or more) as you had when you were falling. It made poor Sonic feel completely out of control. So I added a component called "Elasticity" that supplies the ratio of velocity that is preserved after impact.
My initial implementation was just to multiply the velocity vector by elasticity (if present) after deflection, which almost had the intended effect. The problem was that if you, say, slammed into a wall while airborne, it would also reduce the vertical component of the character's velocity. If you held the direction button into the wall, you'd skip off the wall repeatedly in a way that felt chunky and sort of.. entry-level-game-physics-y. Like if you were going to have a wall-slide move, it should look more deliberate. So I added some logic to the character's state machine to change how it responds to non-walkable surfaces based on its total velocity-- under the threshold it would use the "Projection" interaction type, where it would just negate any movement contrary to the surface normal. This sort-of produced the intended effect, but you still had the repeated impacts until you hit the cutoff. So I looked at the problem again, and realized that I could fix it by just adjusting the vector math a bit. Really what I wanted was not a change in the magnitude of the vector, but to negate an amount of velocity in the direction of the surface normal.
Defining some variables...
v is the original velocity at the time of impact.
v' is the altered velocity.
p is the component of v on the plane of the surface normal (the vector projected onto the surface normal).
o is the component of v orthogonal to the surface normal (along the surface)
e is the scalar value of elasticity for the moving physics body.
v' = o + -p * e
When e = 1.0, this produces a simple deflection; the new velocity points away from the surface at the same angle that the old velocity pointed into it. That's sufficient to get the intended result; however, I realized that the act of getting the orthogonal vector involved the definition of the projected vector (which, I think, actually also involves the orthogonal vector) and sensed some redundant calculation going on, so I applied some algebra to the equation:
o = v - p
v' = v - p - p * e
v' = v - (1 + e) * p
So the deflection is now handled by projecting the velocity onto the surface normal, multiplying it by 1 + e (the "1" negates all motion into the surface; "e" is any velocity on that axis retained), and subtracting it from the original velocity. And the result is that if you continue to push the character into the wall, they bounce off once or twice, but maintain all the velocity they accumulate due to gravity. And no special handling is required from the character's state machine.
---
On the Nimsters end of things, I broke ground on a content file editor. Originally I had planned to use this sub-project as a learning opportunity to study WPF, but one of the first things I learned is that WPF has fewer features and worse support than WinForms, a far older and more venerable technology. I did, however, use some of the things I've learned about WPF to drive the creation of my forms, such as looking up the TableLayoutPanel control and the Docking property child controls, which has made the Move editor I created look much more organized than my usual spray of controls with hard-coded positions. I also experimented with the notion of data-binding, which, to nobody's surprise, I couldn't get to work in the advertised way and eventually just decided to code my own version of. Everything "just works" until it doesn't, and then refuses to tell you why what you gave it is incorrect. Please, y'all. Fail fast and fail loud.
As always seems to happen, a mechanism I'd originally created to save myself time wound up creating extra work for me. JSON doesn't handle polymorphism well (at least in the context of strongly-typed languages), and since I had always planned to be typing these content files by hand rather than using an editor, I created some JSON converters that turn strings of tokens into result objects for certain types like move effects. For instance, if you have a move that provides a guard effect that blocks contact attacks for three turns, in the data files that looks something like...
"Guard Block Targeting Contact Turns 3"
... and then there's an entire token-parsing subsystem designed to traverse those strings and return the appropriate result. Well, that format was created with the assumption that they were read-only. I had to add a new method to every parseable object to spit out a string that would then parse back to the same object. And then, because I'd so deeply embedded these parsers in the notion of "convert a string in a JSON object into a C# object", I wound up having to do some pretzel twists in my code to go from what you put into the text boxes on the form to object instances that could be assigned to the actual data objects you're editing. But, it all got done this week, and I felt content knowing that all the tools I'd made for the Move editor could be trivially applied to the Nimster data.
... and then I looked at the Nimster data, which is all full of entirely different data types that are going to need their own custom handlers since half of them are Dictionaries. Ah well, that's a project for the coming week.
Kupi on
My favorite musical instrument is the air-raid siren.
There's not much to add from this week over what I talked about last week; I just put the finishing touches on the Nimster editor for my Nimsters content file editor project. So, I put in the effort to get some files onto the machine I post from these days so I can show them off:
The move list controls were somewhat of a pain in the ass to arrange; it turns out that the TableLayoutControl really doesn't like it when you alter the contents of a particular column or row. It adapts well to being expanded and adding new controls, but moving controls around in it is bad news. I also, at one point, considered using nested table layouts, and the documentation on the control gives you the verbal equivalent of a deeply worried look and an eventual, stammering utterance that you really should consider not actually doing that. So, I cheated a bit by swapping the data in the controls around, rather than the controls themselves.
In any event, the move list is set up such that when you choose a new move to add to the list, it assigns it a level one higher than the current highest move. You can then use the "up" and "down" buttons to swap the positions of the two adjacent moves, retaining the levels they're learned at. The X button deletes the move from the list entirely (and in saying that I realize that I need to make sure that plays nicely with the concept of "the table does not like to contract".) On the right side of the move table you can see that button labeled "Smear"; what it does it take every move not learned at level 0 (that is, intrinsically known) and spread them equally across the range indicated, plus or minus 2 levels on a very rough normal distribution. So the actual move entry process in most cases will just involve appending a bunch of moves to the list, sorting them into the proper order, and then using the Smear function to set the levels they're learned at to the appropriate range.
I also brought a short video demonstrating the new elasticity physics that cut the platforming character's speed in the direction of the surface normal on impact. You can see how Sonic bonks lightly against the ceiling and walls instead of pinballing all over the place now. There's still a bit of jankiness when sliding down the wall because he's trying to rotate to match his movement, but at least he doesn't bounce or stall.
My plan for the coming week is to make sure that the edited Nimsters content files are saved back after being edited (whether deliberately or by autosaving), and then go back into data-entry mode.
My favorite musical instrument is the air-raid siren.
When I wrote the code for my ball bouncing I thought I had been really clever and gotten it working consistently at varying framerates.
Turns out I wasn't quite right. In the test I set up 60FPS and 165FPS diverge after around 20 bounces. And if I set Monogame to not use a fixed timestep, balls that are following the same path start diverging from each other at that point.
My best guess is that this is a floating point precision issue, so I guess it's time to go through everything and replace floats with doubles and see if that makes things better.
Switching ball bounce calculations to use doubles was a success! The ball bounces now stay consistent across framerates.
Unfortunately it turns out I have another bug and my attempts at fixing it have not been successful so far. When the ball bounce they do another movement in the new direction, ensuring that balls always move the same distance each frame. Except as part of implementing the ball squish/wall splat I save this until after the splat is done. And now balls that are on the same path, some distance apart, end up bunching up.
The problem goes away if I disable the wall splat, but I haven't quite figured out where exactly I've screwed up.
EDIT: Turns out I was wrong. Using doubles did not outright fix the diverging paths, it merely made it take longer before happening and I hadn't let it sit long enough to see it.
Not a whole lot new as far as game dev, still churning through all my various GUIs and replacing default assets with my new designs (may post some more screens later). Got the last set of portrait art delivered for the playable species, which also means I now have all of the artwork for the game's introduction sequence/initial release, though not all actually in the game yet.
But mostly just wanted to proclaim that I've finally passed 1,000 Steam sales, after accounting for returns and such. \o/
It's still nothing I can live off of, but as far as I'm aware I've actually done a fair bit better than the majority of games on Steam, so I'll take it.
I've been in a dark headspace all week and it ain't getting any better, so this week's report will be terse.
As an organizational aid, I added a new "Category" property to Nimster moves. This is mostly because attack moves tend to be organized into "families" consisting of one "entry-level" move and three advanced moves that all put their own spin on the original theme. But I found that just displaying the list of moves as it exists in the definition file was very messy and hard to navigate, and most sort orders I came up with tended to leave move families smeared all over the place, which is bad because most of the time when you give a Nimster one move in a family, you want to give it several others and it helps if they're all in the same place.
Naturally, after creating the concept of a move category, I had to go back and apply categories to all the moves that needed them. And then I created the standard move sort that puts them all in the expected order, which at this point is a ten-link long chain of .ThenBy()s.
For entering a Nimster's move list, moves of the Physical type and the Nimster's own types are moved to the top of the selection list.
This week's plan to is to bring a few of the earliest types I entered moves for into compliance with the patterns I established of later types. It's SGDQ week, though, so if I'm being honest I'm probably not going to get much done. But we'll see.
My favorite musical instrument is the air-raid siren.
Yep, SGDQ slowed the hell out of my pace this week. Just two tidbits to report:
- I added a few new Nimster moves to types that previously had been more scattershot. The hobgoblin of my mind as a designer of RPGs is creating symmetries where they don't need to exist; for whatever reason, unless I create families of moves with one initial move and three advanced moves, it just feels wrong.
- I discovered that my editor's save-back function obliterated a few of the more obscure data members, like conditional power modifiers on moves (such as "does more damage if used on a higher number than the opponent's last number"). And then as I started reading through all of the existing moves to try to find the ones with descriptions that indicated said conditions, I realized that this would be an ideal opportunity to write the balance analysis tools that I've alluded to previously. I'm somewhere in the middle of writing all the necessary functions for moves to submit a rough power-balance score, which I'll eventually wire up to the editor so a move can tell you if it's above or below the power curve in real-time.
My favorite musical instrument is the air-raid siren.
Of course, the thing about SGDQ week is that it's followed by the week after SGDQ week, when I can watch all the runs back to back without pauses, which turns out to leave my attention strained even more than SGDQ week proper. Nevertheless, I've been chipping away at what I've been talking about for the past two weeks, adding a few new Nimster moves here and there and shoving my balance analysis functions back into their lane when they judge something wildly incorrectly. (It turns out that game balance isn't something that's easily quantified by a series of a multiplications. Who knew?)
Sort of having second thoughts about Nimsters in general. I'm feeling like I've made the same over-scoping mistake I've made a couple times now and that it's served its intended purpose of keeping my programming-brain sharp while I was between jobs. The core timeline mechanic might be better suited to a much thinner roguelite structure, but that would also entail starting over from zero. If I'm going to break off from Nimsters, it'll be to resume work on my action games... specifically Ike Ika, which was my designated "get something finished" project before Nimsters became my "practice new languages and get hired" project and then took over the "get something finished" slot.
I'll let you know what I've decided next week.
My favorite musical instrument is the air-raid siren.
I have started to dig into Game Coding Complete. The book is getting a little crusty. The copyright is 2013.
I got the source code to work in VS 2022 Community Edition. Had to link a bunch of libraries. Of course no one pointed that out.
I also had to use a version that someone got to work with VS 2017 on the forums.
I was also going to try learning a game engine. Still deciding on that. Godot looks appealing because it is free. Still Unity and Unreal have more mass appeal.
Oh yeah. I forgot about Monogame. Was there any popular games made with that? I think Super Giant Games uses it for their stuff.
Quite a few actually. Celeste, Stardew Valley and Axiom Verge just to name a few.
You just usually don't see it advertised the way you do with Unity or Unreal.
It is also worth noting that it is not a game engine, but a game development framework. There are many many features that any of the major engines provide that one will have to make for oneself if using Monogame.
Posts
I feel a tiny bit called out with the bit about text rendering. In my defense, the text rendering I was using previously was kind of bad.
Twitch | Blizzard: Ianator#1479 | 3DS: Ianator - 1779 2336 5317 | FFXIV: Iana Ateliere (NA Sarg)
Backlog Challenge List
In the middle of it, a lot of it resonates.
Development:
-Not going to lie, when you go from prototype (wow this engine is handy) to end result (all I want is one more setting!) you'll be hand-rolling.
-The alternative is to really just accept engine limitations and focus on your implementation- with the danger of continuous iterations to get it just right.
-Switching engines will just get you a lot of easy prototype wins, after which, you guessed it... you'll be hand-rolling.
-Either hand-rolling or continuous iteration can be fixed by forcing yourself to ship. I guess shipping unfinished prototypes is another pitfall?
Marketing:
-It seems the current best value for money social media is either Reddit or TikTok.
-Reddit requires a solid mapping of audiences in subreddits and their rulesets.
-Advise for TikTok is to be a mensch.
-Twitter apparently works as a Linked-in for gamedevs, i.e. you have to network, network, network- and in the end you may get some shout-outs?
-Steam digital festivals is where it's at for getting your demo out/game seen. The festival should be a featured one, and select one where the topic ties into your game.
-Discord, I don't know. Once you have players, I suppose? I have a dayjob and a family, so it feels like the input needed matches that of Reddit.
-YouTube and Twitch are more accessible than you think if you have a good game. Just... ask.
-If you're going to buy ads anywhere spend on professional marketing as well as buying views. Mind you, I gleaned this from marketing professionals so as the Dutch say 'Wij van wc-eend'.
Since my games are heavy on visuals and I'm light on time, I'm going to try to market on TikTok. Surprise: that means rewriting my controller tools.
extra: In general, social media is fickle. You know what isn't fickle? Emailing lists. They might not work for every potential user out there, but those who do read their emails will keep reading emails forever and ever even if Musk buys Twitter or TikTok enrolls all teens in the PLA.
Publishing:
-I don't have my notes on this handy, but basically a publisher will want to talk to your alternate accountant self. If you don't log your hours, pay yourself a wage, have all your spending in the books, and most of all have a roadmap on how to find and grow your audience, no publisher you want to talk to you will talk to you. Lots of scammers will.
-I took a business class ages ago, but to be honest I'm far too early in this game to start applying it. That said, I'm slowly building my repertory of assets (scripts) and so I should be accounting it. If your game is 'I prototyped this idea I had and now it goes on .io' you might get away with not knowing busineseese.
-Your elevator pitch should probably be on point, too. But you know what? It should have been the seed of your game. Don't make a game because 'now I can animate sprites'. Make a game because 'It's genre x but I fixed mechanic y and now it's double awesome!'.
On the same token, maybe that's the secret to Josh Wardle's success? He just made a dumb game for his girlfriend and then it went viral and got bought by a major publisher. Easy-peasy.
This week's report is late in the day. Does this mean that I've been putting the finishing touches on some epic feature that's going to take an entire essay to describe? No! I've been playing Sekiro all week. Nevertheless, a few things to document.
On the Nimsters front, I revised the Paralysis status effect again. Now, rather than an instant turn-loss with geometric back-off on how much status damage it takes to inflict the status, Paralysis is now essentially the inverse of Sleep. With the Sleep status effect, you're trying to land on one of the numbers you've already landed on in order to wake up; with Paralysis, every number you land on on the timeline will cancel your move if you land on it again for as many turns as you have stacks of Paralysis. This places Paralysis back among the status effects that progressively get worse the more stacks you have, since the more stacks of Paralysis you have, the more active land-mines you leave on the timeline for yourself.
Behind the scenes, I changed status damage to be tracked as an objective amount (that is, % of the status inflicted) rather than storing it in terms of your Vitality stat. The practical upshot of this is that you can't level up, gain a few points of Vitality, and suddenly not be poisoned / paralyzed / whatever else.
I also penned the Poison and Light-type moves, which just leaves Fighting Force, Psychic, and Dark left, plus random additions to the types I've already completed as I come up with them.
Finally, I implemented the "timeline influence" move effect. Basically, a move can now change the character of the values generated on the timeline by adding a min, max, or averaging function to two rolls, such that the timeline persistently has either lower numbers, higher numbers, numbers closer to the center, more stars, or more Xes.
I am still putting more mental effort than necessary into the idea of fast serialization to a binary format for my primary / action game engine, because the thing about having a day job is it produces long swatches of boredom where designing such a thing is actually the most interesting available option.
This week, ehhh... I'll set a goal of getting those last three types' moves written.
The ability to put icons in text! Along with some less visible code changes and minor additions.
I don't know if anyone here uses MonoGame, besides myself and Kupi, but if anyone is interested the whole thing is available on my Github.
It turns out that I goofed on the current status of which types had their moves written as of my last post. I hadn't actually committed the Light-type moves yet; I just sketched them out in a notebook. So, though I did hit my goal of getting three types' worth of moves written, those three types were Fighting Force, Psychic, and Light. I would have gone ahead and pushed through to get the Dark moves written as well, but I also goofed in that there was a whole type whose moves I'd forgotten about: Normal Physical. And that type, being everyone's backup type, is closer to a type and a half in terms of how many moves it's going to wind up containing. So, this week's target is about two and a half types' worth of move definitions, at which point I'll be done...ish with that portion of the content phase (I may want to return and do a balance pass / apply some lessons I learned toward the end of the first pass) and can move on to writing Nimster definitions.
... yeah, that's it. Slow week. Blame Aegis Rim.
Last week I hit my target for velocity while discovering that my starting point was behind expectations; this time my location and target stayed in place while I didn't get as much work done as planned. Call that the Heisenberg Uncertainty Principle of project planning, I guess.
This week I did all the data entry for Dark-type moves. In keeping with the trend of folding multiple Pokemon types into one Nimster type where appropriate, the Dark type in Nimsters strongly resembles the Ghost type on its physical-attack side, with a bunch of jump-out-and-yell-boo attacks and various bite, claw, and horn attacks with diabolically-themed names. The special-attack side is a bunch of more traditional dark magic, with a suite of various combination status effect attacks. One family of moves involves sacrificing HP for gain; "Spite" is an attack that's much stronger than a normal entry-level attack moves, but has a full 50% recoil damage-- which you can either offset with the recovery from "Life Drain", or use to empower "Wrath", which increases in power the fewer HP the user has. The Dark type's defensive moves have a unique character where they refresh for a turn when activated and stack with themselves, thereby becoming more and more dangerous the more often you trigger them. Stare into the abyss, and the abyss stares into you. One last unique aspect of the Dark type is that unlike all other types, the moves that you can use on the X (which otherwise renders all other moves unusable) have no drawbacks. Normally X moves have some kind of painful downside to them (which is still better than just losing your turn entirely), but the Dark type thrives in the conditions that everyone else suffers under.
This week's goal is get the Physical-type moves entered. From there I might proceed to the balance analyzer, just to have some fun with coding before going back into another big data entry phase (writing up stats for the Nimsters I already have concepts for).
It's not for any actual game, it's just a demo for a shape drawing library I'm making, but I think it looks alright.
The only item on my docket this week was to write up the basic Physical moves; I completed it. I therefore conclude that the key to hitting your expectations is to lower your expectations.
The Physical type, like the Normal type in Pokemon, is "everyone's secondary type"; it doesn't do anything particularly out of the ordinary mechanically. On the physical(stat)-attack side, the direct attacks come in sets themed around body parts-- claws, teeth, hands, feet, whatever various long appendages the user may have-- and a few sets around gestures like running and jumping. On the special-attack side, Physical owns the concept of sound and the voice, with a few damaging attacks that scream or use sonic waves, and status moves powered by the voice in some way, like lullabies, confounding gibberish, growling, howling, and roaring. On the defensive side, the Physical type has very few Claim-type moves, which generally theme around some kind of effect on the battlefield; I don't think there are many cases where something you do with your body extends to the world around you. Physical's Guard-type moves are similarly basic but stamina-efficient; for instance, "Fly" causes the user to evade "close targeting" attacks (contact and energy blast, but not projectile) for several turns. The one unique aspect of the Physical type is its self-buffing moves; instead of buffing subsequent moves of its own type, it buffs moves according to their targeting-- so, for instance, "Take Aim" boosts the power of subsequent Projectile attacks regardless of type.
In all honesty I probably should have just built out the move list while I was building out everything else, but I'm a sucker for giant data-entry projects. The next step is to start building out the game proper-- adding a map, deciding which of my current Nimster concepts you should be able to find there, and entering stats for those Nimsters, rinse and repeat until the player is the Nimster Battle League Champion. I suspect it will take me several weeks before I'll have something I want to present-- and it'll still be a text-based game in the console whenever it's done. I also have the creeping sensation that there's something I'm forgetting-- Nimster accessory effects or Abilities, most likely, that's going to take more work than it feels like. But we'll cross that bridge when we get to it.
This week's report is going to be a whole bunch of cheap starchy filler, because the amount of actual work I got done doesn't even register on the micro-scale. Just felt like spending my evenings (and weekend) playing Okami instead of being productive.
On the Nimsters front, I made a last-ditch effort to have absolutely anything to report on Thursday and typed up the stats for exactly one Nimster-- Squarrel, the game's token Route 1 Trash Mammal. "Fiercely territorial, it will attack anyone who enters its area. However, because it is so weak, it usually loses." Squarrel's unique Ability Attribute is "Pugnacious", which renders it immune to the Fear status effect, but also prevents it from switching out until it is defeated. This complicates the way its evolution branches-- a Squarrel must gain the majority of its experience before the level at which it transforms through direct victories in order to turn into Champmunk. If it gained the majority of its experience points through consolation-prize EXP or watching others fight, it becomes Sourrel, the "left out" Nimster.
I briefly revisited my ECS game architecture this week when I thought I had a way of improving the way components are initialized on creation. As it turns out, my engine may not be well engineered, but it's certainly maximally engineered at this point; the ideas I had to improve it immediately slammed into the same conditions that rendered what I was thinking of impossible as I had to account for the first time. I really cannot do anything with that code any more besides actually make games with it.
On that subject, a half-hearted whim: my parents recently dug up a bunch of my old stuff out of the storage closets, and since I've got a house of my own now they wanted it out of theirs. Which is to say that I've come into possession of several of those rorshach-print notebooks from back when I was like eight years old, and doodled a bunch of absolutely unoriginal game designs (as in, a character who is essentially just Rick the Hamster from Kirby's Dream Land with the fire power, because I thought a fire-breathing hamster was awesome). If I can manage to read through those things without cringing out of my skin, I might find something that could be fun to use as a throwaway project-- avenging the dead dreams of my younger self.
Similar but perpendicular brainwave: instead of creating just one pixel-art retro throwback, make five small ones and sell them as a package under the conceit that it's a collection from some dead 90s-era company that never actually existed.
Still battling distraction and disinclination, with little success, but some success nonetheless. This week I typed up the stats for those evolved forms of Squarrel-- Champmunk and Sourrel-- and the Route 1 Trash Bird line, Canairy, Cairdinal, and Robairn. I then realized that I'd basically left the starters in their nascent, "get the game off the ground for debugging purposes" forms, and went back and gave the water starter line-- Bubby, Sogidogi, and Pouddle-- more final stats.
- Champmunk gains the Fighting Force type, and the special Attribute "Ambusher", which increases the power of attacks made on the first turn it's out. Almost like showing up and sucker-punching foes who were already weakened were how it got its winning record in the first place...
- Sourrel has the Attribute "Sore Loser", which grants it a weak physical attack when it's forced to retreat. It has a unique Claim-style move called "Cache In" that attacks enemies that land on the space and heals allies that land on it, but only one time each. Sourrel also learns Wildfire, a Claim-type move that causes fire damage to anyone that lands on the claimed space, ally or enemy. Sourrel fights under the assumption that it's going to lose and makes sure that nobody else has any fun either.
- Canairy's Attribute, "Sickly", makes it weaker to the Poison status effect. After evolving, this is replaced with "Wary", which evades any attack made against Cairdinal or Robairn the first turn they're out.
- The Bubby line's Attribute, "Damp", cuts incoming damage from Fire attacks in half (in addition to its natural type resistance). Can't set a wet dog on fire; that's just science. (Not to mention it would be immoral.)
But then, having just typed up these Attributes, I have to admit that I'm having second thoughts about giving Nimsters Attributes at all. I'm not fond of passive effects in RPGs generally speaking, and there's a certain amount of creative load to having to come up with one (even if not necessarily unique) for each Nimster. It's a design element I borrowed from Pokemon essentially by reflex, which for a simple project may be more cognitive load than required. So this week I'm probably going to go ahead and revert the code changes I made to support Attributes, and see how well the game holds up without them. I will probably keep the idea of "Accessories" (that is to say, held items) just to give the player something else to spend their money on and another party-customization option.
Entirely unrelated, I was playing around with concepts for a roguelite character progression system, with the idea of building power by acquiring perks that you could stack multiple copies of to improve their power, with a system of diminishing returns so the player is encouraged to spread the investment in their abilities around (think using Poms of Power to level up Boons in Hades). But then you have to come up with a mathematical function to drive the diminishing returns. Ultimately, here's what I came up with: choose a constant denominator D. The strength of a given perk's effect at level N is (N * D) / (N + D - 1). This always works out so that the perk's power is 100% of its base value at level 1, always increases as you increase N, but increases by less with each level. The choice of D is important-- the lower a value of D you choose, the faster the gain per level drops off. I leave it to you to throw that into Excel and play with the curves if you're actually interested in that sort of thing.
Insectoids: 27
Shapeshifting Reptilians: 216
Sexy Kaminoans: 900
Scaley Reptilians: 3780
Humans: 8640
Overall a pretty healthy set of options, although clearly I need to add more color to future races to keep there from being more cases like the all-black insectoids.
That's the last main coding task I have for the initial playable version of the game, but now the time's come for me to actually create a GUI design rather than using the default Unity components. I've never really done GUI design before, but some early experiments with some fonts and buttons are looking promising - at the very least it's an immediate improvement over the defaults.
Like, what you need here is some sort of visual editor for these. I'm watching you balance this in your head and I'm thinking about my upcoming not yet started fantasy game with loads of species and roles. I'm thinking three weeks dayjob crunch will basically put me back on square one.
Whereas if I had a nice visual interface, probably in another project folder, where I could drag and drop attributes and immediately see repercussions in a matrix of encounters, that would really help me balance it all out. I'll need one for the trade part of it, too.
Heh... the irony with that suggestion being that the whole reason I've been doing everything in typed JSON was because Nimsters was supposed to be a project that wasn't as heavyweight as my Monogame-based engine. That, and since I started building it on a Mac, I didn't have ready access to a built-in C# UI editor that I knew how to use. But a simple editor would probably be for the best in the long run, especially since maps pretty much have to be drawn rather than described. I'll make that a priority for next week.
My design goal is to basically use Star Trek's LCARS as an inspiration, though upgrading to the superior sci-fi shape of octagons to avoid being sued keep things unique.
I continue to advance at a weak plod. I've been applying some new time-management techniques during the day job, which I think is keeping me sufficiently focused on work during the daylight hours that I hit the evening with little will to do anything but relax and play games. That tells me that I need to focus my game work on the weekends.
I rounded out the evolutionary line of the starter Nimsters by speccing out the Grass Plant-type starter's evolution chain. Bunja, described in-game as looking like a small green chew-toy with angry eyes, has almost nothing but physical attack power. On transforming into Ronibble, it gains a bipedal gait and a large novelty carrot it wields like a sword. This gives it access to the unique move Carrotana, which, unlike most attacks that can be used between a minimum and maximum value on the timeline, is usable on two separate numbers, 0 and 9. After levelling up further and transforming into Samurabbit, it gains another unique move, Bunshido, which is simultaneously an evade and a block with a counter-attack. (Meaning, it will negate incoming attacks used on numbers higher than it (the evade) and attacks used on numbers lower than it (the block).) What keeps this in check (other than the opponent having a self-targeted move and refusing to attack on the guard turn) is that it can only be activated on the numbers 4 and 5.
My plan for the coming week is to take Cornucopiist's advice and create a visual builder for these data files, which will hopefully bait me into actually presenting some enthusiasm for the work.
Shitty paint of what I'm trying to do:
http://www.jgallant.com/2d-liquid-simulator-with-cellular-automaton-in-unity/
In the process of reflecting on how I spend my time (generally, not with exact measurements), I've found that the Penny-Arcade boards consume a lot of my personal hours, and predominantly in a lurking mode rather than posting. As an escalation in getting myself out of that mode, I gave the Penny-Arcade domain a failing redirect in my tower PC's hosts file, which I find is a harder mechanism to revert than most of the other productivity / content-control software I've used. I normally wouldn't mention that, but this week's topics are things I would normally use visual aids, screenshots, and videos to help explain, which I don't have access to from my laptop (physically only available around lunchtime). All this to say: I'm forced to used words to describe things that are better described with pictures, and a picture is worth a thousand words...
Anyway, two projects this week. On the platform-game side, I added elasticity to platforming physics interactions. I don't know if that's exactly the right term, but it's the one I'm using. The problem I was facing is that velocity was perfectly preserved when deflecting across a surface; if you bounce off of a wall, you continue upward with the same velocity as you had when you struck the wall. This lead to an odd situation where you could fall into a half-pipe, strike a non-walkable section of the floor, deflect across the surface normal, fly with enough speed to strike the opposite side of the half-pipe on a non-walkable section, deflect across that, and wind up traveling upward with exactly as much speed (or more) as you had when you were falling. It made poor Sonic feel completely out of control. So I added a component called "Elasticity" that supplies the ratio of velocity that is preserved after impact.
My initial implementation was just to multiply the velocity vector by elasticity (if present) after deflection, which almost had the intended effect. The problem was that if you, say, slammed into a wall while airborne, it would also reduce the vertical component of the character's velocity. If you held the direction button into the wall, you'd skip off the wall repeatedly in a way that felt chunky and sort of.. entry-level-game-physics-y. Like if you were going to have a wall-slide move, it should look more deliberate. So I added some logic to the character's state machine to change how it responds to non-walkable surfaces based on its total velocity-- under the threshold it would use the "Projection" interaction type, where it would just negate any movement contrary to the surface normal. This sort-of produced the intended effect, but you still had the repeated impacts until you hit the cutoff. So I looked at the problem again, and realized that I could fix it by just adjusting the vector math a bit. Really what I wanted was not a change in the magnitude of the vector, but to negate an amount of velocity in the direction of the surface normal.
Defining some variables...
v is the original velocity at the time of impact.
v' is the altered velocity.
p is the component of v on the plane of the surface normal (the vector projected onto the surface normal).
o is the component of v orthogonal to the surface normal (along the surface)
e is the scalar value of elasticity for the moving physics body.
v' = o + -p * e
When e = 1.0, this produces a simple deflection; the new velocity points away from the surface at the same angle that the old velocity pointed into it. That's sufficient to get the intended result; however, I realized that the act of getting the orthogonal vector involved the definition of the projected vector (which, I think, actually also involves the orthogonal vector) and sensed some redundant calculation going on, so I applied some algebra to the equation:
o = v - p
v' = v - p - p * e
v' = v - (1 + e) * p
So the deflection is now handled by projecting the velocity onto the surface normal, multiplying it by 1 + e (the "1" negates all motion into the surface; "e" is any velocity on that axis retained), and subtracting it from the original velocity. And the result is that if you continue to push the character into the wall, they bounce off once or twice, but maintain all the velocity they accumulate due to gravity. And no special handling is required from the character's state machine.
---
On the Nimsters end of things, I broke ground on a content file editor. Originally I had planned to use this sub-project as a learning opportunity to study WPF, but one of the first things I learned is that WPF has fewer features and worse support than WinForms, a far older and more venerable technology. I did, however, use some of the things I've learned about WPF to drive the creation of my forms, such as looking up the TableLayoutPanel control and the Docking property child controls, which has made the Move editor I created look much more organized than my usual spray of controls with hard-coded positions. I also experimented with the notion of data-binding, which, to nobody's surprise, I couldn't get to work in the advertised way and eventually just decided to code my own version of. Everything "just works" until it doesn't, and then refuses to tell you why what you gave it is incorrect. Please, y'all. Fail fast and fail loud.
As always seems to happen, a mechanism I'd originally created to save myself time wound up creating extra work for me. JSON doesn't handle polymorphism well (at least in the context of strongly-typed languages), and since I had always planned to be typing these content files by hand rather than using an editor, I created some JSON converters that turn strings of tokens into result objects for certain types like move effects. For instance, if you have a move that provides a guard effect that blocks contact attacks for three turns, in the data files that looks something like...
... and then there's an entire token-parsing subsystem designed to traverse those strings and return the appropriate result. Well, that format was created with the assumption that they were read-only. I had to add a new method to every parseable object to spit out a string that would then parse back to the same object. And then, because I'd so deeply embedded these parsers in the notion of "convert a string in a JSON object into a C# object", I wound up having to do some pretzel twists in my code to go from what you put into the text boxes on the form to object instances that could be assigned to the actual data objects you're editing. But, it all got done this week, and I felt content knowing that all the tools I'd made for the Move editor could be trivially applied to the Nimster data.
... and then I looked at the Nimster data, which is all full of entirely different data types that are going to need their own custom handlers since half of them are Dictionaries. Ah well, that's a project for the coming week.
I made the balls squish a bit when they hit a wall.
There's not much to add from this week over what I talked about last week; I just put the finishing touches on the Nimster editor for my Nimsters content file editor project. So, I put in the effort to get some files onto the machine I post from these days so I can show them off:
The move list controls were somewhat of a pain in the ass to arrange; it turns out that the TableLayoutControl really doesn't like it when you alter the contents of a particular column or row. It adapts well to being expanded and adding new controls, but moving controls around in it is bad news. I also, at one point, considered using nested table layouts, and the documentation on the control gives you the verbal equivalent of a deeply worried look and an eventual, stammering utterance that you really should consider not actually doing that. So, I cheated a bit by swapping the data in the controls around, rather than the controls themselves.
In any event, the move list is set up such that when you choose a new move to add to the list, it assigns it a level one higher than the current highest move. You can then use the "up" and "down" buttons to swap the positions of the two adjacent moves, retaining the levels they're learned at. The X button deletes the move from the list entirely (and in saying that I realize that I need to make sure that plays nicely with the concept of "the table does not like to contract".) On the right side of the move table you can see that button labeled "Smear"; what it does it take every move not learned at level 0 (that is, intrinsically known) and spread them equally across the range indicated, plus or minus 2 levels on a very rough normal distribution. So the actual move entry process in most cases will just involve appending a bunch of moves to the list, sorting them into the proper order, and then using the Smear function to set the levels they're learned at to the appropriate range.
I also brought a short video demonstrating the new elasticity physics that cut the platforming character's speed in the direction of the surface normal on impact. You can see how Sonic bonks lightly against the ceiling and walls instead of pinballing all over the place now. There's still a bit of jankiness when sliding down the wall because he's trying to rotate to match his movement, but at least he doesn't bounce or stall.
My plan for the coming week is to make sure that the edited Nimsters content files are saved back after being edited (whether deliberately or by autosaving), and then go back into data-entry mode.
Turns out I wasn't quite right. In the test I set up 60FPS and 165FPS diverge after around 20 bounces. And if I set Monogame to not use a fixed timestep, balls that are following the same path start diverging from each other at that point.
My best guess is that this is a floating point precision issue, so I guess it's time to go through everything and replace floats with doubles and see if that makes things better.
Unfortunately it turns out I have another bug and my attempts at fixing it have not been successful so far. When the ball bounce they do another movement in the new direction, ensuring that balls always move the same distance each frame. Except as part of implementing the ball squish/wall splat I save this until after the splat is done. And now balls that are on the same path, some distance apart, end up bunching up.
The problem goes away if I disable the wall splat, but I haven't quite figured out where exactly I've screwed up.
EDIT: Turns out I was wrong. Using doubles did not outright fix the diverging paths, it merely made it take longer before happening and I hadn't let it sit long enough to see it.
But mostly just wanted to proclaim that I've finally passed 1,000 Steam sales, after accounting for returns and such. \o/
It's still nothing I can live off of, but as far as I'm aware I've actually done a fair bit better than the majority of games on Steam, so I'll take it.
I've been in a dark headspace all week and it ain't getting any better, so this week's report will be terse.
As an organizational aid, I added a new "Category" property to Nimster moves. This is mostly because attack moves tend to be organized into "families" consisting of one "entry-level" move and three advanced moves that all put their own spin on the original theme. But I found that just displaying the list of moves as it exists in the definition file was very messy and hard to navigate, and most sort orders I came up with tended to leave move families smeared all over the place, which is bad because most of the time when you give a Nimster one move in a family, you want to give it several others and it helps if they're all in the same place.
Naturally, after creating the concept of a move category, I had to go back and apply categories to all the moves that needed them. And then I created the standard move sort that puts them all in the expected order, which at this point is a ten-link long chain of .ThenBy()s.
For entering a Nimster's move list, moves of the Physical type and the Nimster's own types are moved to the top of the selection list.
This week's plan to is to bring a few of the earliest types I entered moves for into compliance with the patterns I established of later types. It's SGDQ week, though, so if I'm being honest I'm probably not going to get much done. But we'll see.
Yep, SGDQ slowed the hell out of my pace this week. Just two tidbits to report:
- I added a few new Nimster moves to types that previously had been more scattershot. The hobgoblin of my mind as a designer of RPGs is creating symmetries where they don't need to exist; for whatever reason, unless I create families of moves with one initial move and three advanced moves, it just feels wrong.
- I discovered that my editor's save-back function obliterated a few of the more obscure data members, like conditional power modifiers on moves (such as "does more damage if used on a higher number than the opponent's last number"). And then as I started reading through all of the existing moves to try to find the ones with descriptions that indicated said conditions, I realized that this would be an ideal opportunity to write the balance analysis tools that I've alluded to previously. I'm somewhere in the middle of writing all the necessary functions for moves to submit a rough power-balance score, which I'll eventually wire up to the editor so a move can tell you if it's above or below the power curve in real-time.
Of course, the thing about SGDQ week is that it's followed by the week after SGDQ week, when I can watch all the runs back to back without pauses, which turns out to leave my attention strained even more than SGDQ week proper. Nevertheless, I've been chipping away at what I've been talking about for the past two weeks, adding a few new Nimster moves here and there and shoving my balance analysis functions back into their lane when they judge something wildly incorrectly. (It turns out that game balance isn't something that's easily quantified by a series of a multiplications. Who knew?)
Sort of having second thoughts about Nimsters in general. I'm feeling like I've made the same over-scoping mistake I've made a couple times now and that it's served its intended purpose of keeping my programming-brain sharp while I was between jobs. The core timeline mechanic might be better suited to a much thinner roguelite structure, but that would also entail starting over from zero. If I'm going to break off from Nimsters, it'll be to resume work on my action games... specifically Ike Ika, which was my designated "get something finished" project before Nimsters became my "practice new languages and get hired" project and then took over the "get something finished" slot.
I'll let you know what I've decided next week.
I got the source code to work in VS 2022 Community Edition. Had to link a bunch of libraries. Of course no one pointed that out.
I also had to use a version that someone got to work with VS 2017 on the forums.
I was also going to try learning a game engine. Still deciding on that. Godot looks appealing because it is free. Still Unity and Unreal have more mass appeal.
GameMaker still seems best for 2D.
Yeah. I think I will go with Monogame. It is an actual game framework.
Quite a few actually. Celeste, Stardew Valley and Axiom Verge just to name a few.
You just usually don't see it advertised the way you do with Unity or Unreal.
It is also worth noting that it is not a game engine, but a game development framework. There are many many features that any of the major engines provide that one will have to make for oneself if using Monogame.