Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Ranzear
Jul 25, 2013

baby puzzle posted:

I thought that making a nice demo video to show off all of the game's new features would take a week or two but I'm realizing how much time this is going to take.

I'm starting to create a "modular" track system where different pieces of track model can be mixed and matched, and I can then apply different textures and colors to each instance as well. I think that will make it possible to have a nice variety of track types. I'm still very much stealing as many ideas from Redout as I possibly can.

Have you seen the postmortem video for Thumper?

Quick and dirty takes from your *first video:

  • Don't pan the music quite that much on turns. The effect is nice but it's quite jarring to shove it all the way over. (On good headphones here)
  • Needs measure markers, badly.
  • Tone down the major view changes. It's changing the position of upcoming elements too much or at very least killing the sense of speed when you go back to the close view. A little pan-up for the tube is fine, but even coming out of the tube was almost ideal to see the upcoming regular stuff.
  • Get upcoming elements closer to the center of the screen, maybe just by giving it that "Thumper stretch". It just feels a little unnatural to look at the top of the screen for upcoming elements. I might just be lost for lack of measure markers, but other games seem consistent on how the whole next measure fits, give or take.

I'm not a huge rhythm game player, but Thumper definitely taught me to read the chart instead of memorizing the chart, the latter I can maybe blame on Amplitude being not as good a game as I thought. It really changed how I look at these games. It also kinda looks like you're mixing up what input is playing which instrument but that seems more like a demonstration intent.

Edit: Second video went up while I was posting. Regarding the second video, aim the camera up a bit more for sure. The upward bends are eating way too much of the chart, and a full measure at least should always be visible. This one has edge markers on beat (which then disappear), but a distinct measure maker would be nice.

Double edit: Instead of hard-panning the track on turns, just pull down a lowpass on the outside channel of the turn. That should have about the same effect without a distracting major shift in volume.

Ranzear fucked around with this message at 02:17 on Feb 14, 2020

Adbot
ADBOT LOVES YOU

Ranzear
Jul 25, 2013

baby puzzle posted:

I've been playing Redout a lot, and often you literally cannot see the track ahead due to a turn or a hill, so there is no way to "sight read" the race track.

Gonna get straight to the point: This is, IMO, really poo poo design. It amounts to trial-and-error gameplay, the kind of stuff long purged from other genres. I'd rate it artificial difficulty akin to the Guy/Boshy games or just offscreen thwomps in SMM, but that really kind of depends on recovery. Do you fail the whole stage on those? Do you fail if enough of those gently caress you up? Is the charting basically designed to make you fail the first time, every time?

Definitely play Thumper. It has specific things that will kill you in just two hits, but a recovery system for both the first hit and you only restart the current section if you die. You still can't memorize everything the first few times through because all nine stages in a row is three hours long. The first level is nine and a half minutes alone. The whole game is still 'sight read or die', despite the faster cycle time after failure, and that's just way more engaging.

I couldn't figure out for years why rhythm games just didn't do much for me (except the multiplayer component of Amplitude). It had a lot to do with having to play the same junk over and over to memorize it, and this kinda ruined Guitar Hero for me too even though that game is set up to be sight-readable, because I approached it with that really bad idea to try to memorize the chart instead of playing the notes in front of me. Hell, I don't consider JasonParadise to be the best Guitar Hero player in the world because he memorized every chart and plays them flawlessly; he is, IMO, the best Guitar Hero player in the world because he will sight-read and likely full-combo literally any garbage meme chart or insane solo thrown at him.

I picked up Thumper because HBomberguy mentioned it, and it fixed rhythm games for me the same way he talked about Bloodborne 'fixed' Dark Souls games for some in the very same video. It forces you to learn to sight read, and then you'll look at other rhythm games differently afterward.

Here's a really basic litmus: Does the game get harder because you added more elements to play per measure, or because you added more turns to hide upcoming measures? Which way is better? Which way can a player better adapt to, if at all?

I've wanted to make a 'tiny mecha fights giant mecha' rhythm game for years, with tons of optional notes and branching paths and the goal isn't the end of the song but depleting a health bar while the music gets situationally more intense.

Ranzear fucked around with this message at 03:44 on Feb 14, 2020

Ranzear
Jul 25, 2013

Right, then: What is it really adding? If it isn't outright killing them, It's just a cheap tactic to steal some points from the player and you and your QA largely ignore it because y'all already know it's there. It should at least be possible to hit everything on the first time through, and fairer mechanics (like more elements per measure) should be working against that instead.

You'll end up instigating a mistake that the player can't do anything about, and that probably will just feel really bad except to the Stockholm-syndrome'd players of other games that feature that. A player should be able to own every mistake they make. Forced errors break trust and let players blame the game being bad instead of themselves being bad; what I'm pointing out is that the latter isn't entirely untrue.

There is a massive difference in player perception of "I didn't see that coming" and "I couldn't see that coming". It will fundamentally change how they approach your game in the first place. They'll dump effort into memorizing and perfecting all the boring parts just to brute-force the parts they can't do anything about until memorization kicks in.

Going back to my Guy/Boshy analogue, sometimes forced errors are a fun part of a game and I think you really could build a rhythm game around that, but it's gonna be all or nothing. There should be a consistent expectation that the game is either fair or unfair. There's actually a gimmick that keeps coming up in Clone Hero charts of hiding the real chart and playing against a video that shows a chart, but full of interface screwing and shenanigans, flipping it upside-down or rearranging and splitting the lanes and whatnot. They tend to be dogshit because not even JPara can read them the first time through and won't even bother to retry/replay it because they also trash all the hit/miss feedback mechanisms; they're turning a sight-reading game into a forced-error game and are visually interesting but seem tremendously un-fun to actually play, all you can do is memorize the gimmicks. They're cool, but definitely not fun.

I don't mean to rip into something your game probably doesn't focus on at all, it just jumped out at me as I was struggling with reading your elements in both videos. I really do think 'blind playable' is the holy grail of a rhythm game. Thumper still spends a few minutes in each of the first few levels teaching you each new mechanic that gets added; hell It even has a few bosses that do the thing you're talking about, but each of them has a soft 'lead-in' section to their gimmick and there's still the audio cues to rely on when things are visually too screwy, and it's also the entire theme of the boss and you only restart that boss section when you fail.

Seriously, play Thumper first chance you get. You'll see where I'm coming from.

Semi-unrelated: That controller is interesting, and I found it the site for it. Is it built for a particular game I can look into?

Edit: Oh man, trailing thought - A rhythm game constructed like SMM troll levels where the note you expect to play is almost always incorrect. Like a ... John Coltrane rhythm game? Yikes nevermind, settle down Satan.

Second trailing thought: A player's effort should be towards learning the game, not the chart.

Ranzear fucked around with this message at 05:12 on Feb 14, 2020

Ranzear
Jul 25, 2013

Rocko Bonaparte posted:

Little Rocko was terrified of aliens thanks to stuff like the movie rendition of Communion. I look at that now and crack up, but the wonkiness of the alien puppetry and the giant eyes absolutely messed with me. Somebody here might remember I was using the book over alien in an animated avatar for a few years. I guess there also was the notion it happened near where I lives and we think my grandfather did TV antenna work at Strieber's cabin. Anyways, If I was going to try to get other people to fall in on the same kind of terror I got as a kid, I'd be going for the uncanny valley. The alien's movements would have to be jagged and ... different ... in contrast to how everything else is moving.

I had a serious issue with grays for a long time just because of the X-Files intro.

Ranzear
Jul 25, 2013

Nah I'm cool with grays now. I think Adventure Time fixed it. Thanks Tree Trunks... I guess.

Now I just always have Don't Fear The Reaper pop into my head whenever there's an abduction beam.

Ranzear
Jul 25, 2013

Bert of the Forest posted:

For great examples of how much good texture work can imply without subdividing, look at the incredibly low poly but amazing environment assets of World of Warcraft classic. I’ve been playing it lately and find myself stopping constantly to admire the trickery of textures doing so much of the visual heavy lifting. Albeit their world us super stylized but I agree that too many rounded off corners tend to make something feel cheaper if the visuals imply a realistic look otherwise.

Another one is FFXI, which one has to remember was originally made for PS2. There were tools to extract, edit, and repack the models and textures and I got into all that before I even knew what a normal map was so I was super confused by all the sharp edges. Short version is some of the character parts have mere dozens of triangles and most characters stay well under 1000 total, which is pretty important for a console MMO. For comparison, I found a number for Fran in 12, which is basically the same engine, having over 4k triangles.

Textures do all the work, though the game does rely an awful lot on abstract lighting then. All of the animation is baked deformations too.

Ranzear
Jul 25, 2013

Gonna +1 on 'active group arcs' overlay, because it will also help when one switches to some new target in a wildly different direction and has to quickly determine what group is aimed that way. I think this leans into your center of screen guidance as well, because the 'correct' group will be pointing forward and more central.

I haven't played it yet though. I don't know how complex these groupings are, or whether all weapons of a group must overlap, or if that group is player-configured.

Ranzear
Jul 25, 2013

Not even pixel art is safe from crazy pipeline and lighting ideas.

https://www.youtube.com/watch?v=gUkY8ZoRfuQ
https://www.youtube.com/watch?v=EA_A8qhTh-8
https://www.youtube.com/watch?v=786nDr2pglg

Ranzear fucked around with this message at 01:43 on May 14, 2020

Ranzear
Jul 25, 2013

The White Dragon posted:

why even light pixels if you're gonna go old school go hard as a motherfucker and the only lighting changes should be fed directly to the rgb mix

Let's just bring back color vector monitors.

Ranzear
Jul 25, 2013

Shoehead posted:

And it almost always makes the pixels look muddy and desaturated, like babbies first photoshop pixelart that's all various shades of black with hints of colour.

Still some good takeaways from the first two videos. Unity actually has a depth-to-normalmap conversion built in, which could simplify art pipeline a lot, but those really cover why it doesn't work very well below a certain size threshold, and even still the Unity conversion has a very vague slider for how much it smooths the result. Cardinal shadows is just a way better method even above pixel art resolutions. I only linked the third video because that's the game he mentioned.

Also the mistake is not normal mapping pixel art, but trying to use smooth lighting. Threshold that poo poo for some hard shadows and get some fresnel edge lighting on it too to make stuff pop. It's not bad to light sprites, they're just too often lit badly.

Hell, normal-map lighting but then per-pixel clamp to a color palette. Would look fuckin' magical.

Ranzear fucked around with this message at 01:58 on May 17, 2020

Ranzear
Jul 25, 2013

New game design gripe: Randomly Optimal Enemies

You ever run into that one enemy in a game where you could tell if it just spammed that one single behavior you would lose 100% of the time? Like the only reason you stand a chance against it is because it keeps doing dumb or random things instead?

The Marauder in Doom Eternal is one of these. What a garbage loving enemy. He automatically blocks all shots until he tries to melee attack, but only melee attacks in a narrow window of distance. The problem is he can and does also dash out of that distance and decide to instant-hitscan-shotgun you or just generally gently caress about with ranged attacks and never give you the opportunity. He can be randomly optimal and basically unkillable, dealing free unavoidable damage and taking none. "Wait for the opening" enemies are always the worst, but usually they have the basic loving courtesy to not damage you in the meanwhile. You usually still take damage from the melee hit when you do manage to stun him out of it, too.

Slay the Spire almost does this. Enemies have a script they follow but pick from multiple scripts, so if you get the five slimes on the 'all five attack first turn' script instead of any other it can still gently caress your whole run. If enemies in Slay the Spire followed optimal tactics the game would be unwinnable.

Dead Space 2 had one of these as well, and I had a few other looser examples. There should be a sanity check on this poo poo: If a player took control, could they abuse the gently caress out of some behavior and always win? AI dumbness does not offset that!

Ranzear
Jul 25, 2013

Chev posted:

Remember the wisdom of Metal Slug: your giant gun can sit on a giant crab or shark.

Hammer Bro. posted:

Maybe after the boss takes enough damage the volcano opens up a mouth and starts barfing large horizontal beams of lava at you?

I'm pretty sure at least 40% of all volcanoes are actually just giant angry faces that look like mountains. I'm pretty sure they'd get more angry the more they got shot.
The answer is pretty clear now: Giant volcano-backed crab with the gun nestled in the volcano, which can submerge and reappear further away to charge and fire angry linear magma beams.

Hammer Bro. posted:

Oh, and if you could add the big flashing WARNING text during the boss reveal cinematics that'd be :allears:

Ranzear
Jul 25, 2013

Shoehead posted:

A huge mistake I mad starting out was thinking I should make enemies who are mirrors of a player character driven by ai trying to push buttons. It's bloody hard to do too.

My AI for Caliber is written with what amounts to a driving direction vector, but in the end they're just fake players using the standard-rear end input object, some batching of several into a single worker, and some loopback connections. The vector points the way and some dumb function just controls the steering and driving inputs to get it moving.

What generates that vector is the real 'AI'. Basically I get the position and type of thing and other properties and values my AI is aware of, create a unit vector in the direction of that object, and then feed the relevant other values (distance, health, energy, etc) into a somewhat bespoke funky curve to produce a positive or negative scalar to apply to the vector. Each vector generator handles a whole class of objects, so like 'enemy tank', 'capture point', 'enemy base', and most of the scaling is just some ratio of distance to relevant value. It boils down to a massive stack of curves which spit out a bunch of vectors that can be in all different directions and positive or negative meaning a whole lot of 'considerations' rather than any discrete decision making.

All those vectors get totaled up, and then it's just translated into the regular-rear end player input object - steer left, steer right, drive forward, drive backward, and there's even a bit of null zone so they'll sit still if there's no real impetus, all based on that one final vector. So no, you weren't too far off-base here, you just need the logic layer separate from the translation layer. I have a single function that handles translating that single vector into movement inputs, and then a target-keeping system for aiming/leading and firing inputs, and some other logical junk just for module handling.

With all that, I don't need to ever touch how it handles 'inputs' to be able to wildly change the logic behind them. I can throw a new vector generator in the massive pile, paying attention to some new object type or whatever, and as long as I scaled the output correctly it'll just mesh right in with everything else.

Also, mirroring player inputs for your AI is good because when something isn't working you can at least rule that part out.

Incidentally, I wrote this AI because I couldn't get goons to play my dumb tank game.

Ranzear
Jul 25, 2013

BoneMonkey posted:

Now I have 3 states, idle, moving and using an ability. Much smoother to have all the moving happening in one action.

You get lots of very interesting behaviour this way. Like my enemy units will naturally kite and surround player units. Because they move away from the player units if they are too close, move towards the player units if they are outside weapons range and move away from ally units if they are too close.

If I generalized and standardized my vector model, I could easily break it out into configurations instead of hard code. Caliber's is a really rough first pass at it, every node type is hard coded, but I think this model is fantastic for game AI. I think the most important thing I stick to is my bots have no behavior states at all.

What I also need to work on is generating meta nodes for more general use. Instead of just paying attention to game objects, there should be some nodes thrown in for stuff like quickly raytraced or just proximity wall detections, and still more complex behaviors off that like a meta node opposite the nearest wall from an enemy to use as cover. Even if I have grid-based randomly generated mazes, I'd generate a meta node on the center of each grid square and have a normal pathfinding algo just sort and weight them and then the vector stacking will lead them along the path while still also reacting to other vectors, and hell it'll even blend them around corners instead of looking like distinct waypointing.

Another reason that AI running on player structures is actually a good thing: I think the most important thing for writing good AI is to limit the dataset it's working on. This is also why my bots in Caliber are fake players, because it also gives them the same vision limitations as players. I hate when AI has total information anyway, but also believe it only makes AI even harder to get good behavior out of.

Ranzear
Jul 25, 2013

Kazinsal posted:

Unrelated to the main point, but that image makes me think that people need to stop entirely using green for "friendly" when paired up with red for "enemy". That second image is what happens for someone with red-green colourblindness (protanopia); literally can't tell what's friendly and what's not.

Blue makes a good substitute for green in that case, at least.

This is habitual for me even though I'm not even colorblind. Blue is better for healthbars too. I might just have a really strong dislike of green UI elements, especially bright green ones.

I watched BarbarousKing's playthrough of Hollow Knight over the last few days and he has deuteranopia. He had a hard time seeing the red spines on the green vines but could tell they were there once he was aware to look for them. Even weirder is he couldn't tell the orange infection blobs from the green acid pools he'd already encountered, so seemed to never even think the infection was a standout terrible thing when it appears in Crossroads and didn't recognize it had infected the snail dude and mosskin in that one place. More than once he pointed it out as green and it's interesting that an entire narrative concept got kinda dropped because it was color coded.

Ranzear fucked around with this message at 13:42 on May 29, 2020

Ranzear
Jul 25, 2013

Tunicate posted:

about how to avoid timewasting stuff in games

That's a bit more directly functional than I expected. One of my biggest gripes in my space of mobile game design is that menu fiddling to collect daily reward junk or clean out trash or even just close the news popup every single menu reload isn't gameplay and should be purged with maximum fervor.

I think in my case though it's more about skinner box bullshit overtaking the part that could actually be called gameplay in terms of time or effort invested by the player.

A lot of their examples are less about removing timewaste and more about removing friction. Sometimes friction is good. Death is a friction mechanic, which is why they mention tuning their checkpoint system so much because it needs some impact. I feel there's a confusion of timewaste and friction going on, but for the most part it's all good.

Ranzear
Jul 25, 2013

KillHour posted:

Note that this is the brightness of reflected light off a surface, not the brightness of the lights illuminating that surface.

Which would be apparent magnitude, not absolute magnitude :science:

Ranzear
Jul 25, 2013

Leveled logging in gamedev is a trap. It leads to 90% game object info spam and 10% ignored warnings relating to the development environment. The unseen error in all that mess is useless. The other trap is letting all logging be in one stream. Split it up by system (hell, even just a string tag like 'entity' or 'network') and write to independent files per system.

There shall only be two log levels:
Does something need to be fixed? Error.
Is it a temporary output for fixing something else? Log.

Wherever these logs get written should remain empty if nothing is wrong.

Ranzear
Jul 25, 2013

Log levels are somewhere between iffy and bad because they encourage giant monolithic logs that are a nightmare to actually sift through. That's why syslog is loving useless anymore and every piece of nix software worth a poo poo writes to its own directory in /var/log.

Like the latter, divide log messages into individual files by system or module, not imagined, predicted, or feigned importance. A separate log file for entities, level generation, network, etc and then one can see problems via the mere existence of a file instead of diving in with grep or regex.

Triarii posted:

The projects I'm on at work drive me nuts because launching the game instantly fills the unity console with thousands of messages and warnings, and even dozens of errors, and everyone new to the projects is just told "oh those are normal, you can ignore them."

Notification Fatigue is absolutely the worst thing any developer can succumb to and Unity specifically seems to encourage it by only having the single internal log. The hilarity ensues when everyone has their log so filtered that nobody can figure out why both the editor and the game are completely making GBS threads the bed. Spoiler, it's the 30MB/s being written by something logging serialized junk per frame.

Ignoring the trash and creating the trash are equal problems to solve.

Ranzear
Jul 25, 2013

Rust doesn't give warnings, only pain.

Ranzear
Jul 25, 2013

xzzy posted:

Unity's getting better! You just have to use a bunch of new features that have been in preview for over a year and can't yet interface with any other new features.

Some months ago I tried yet again to get a custom fragment in URP to load a secondary sprite as a normalmap for a shader, and even got some rudimentary support that boiled down to:

"It's just an extra map you create in the sprite!"
"Okay cool. How do I access it in my shader?"
"Why the gently caress would you want to do that? Are you a coder or something?"

It's fully tutorialized in the documentation, but apparently does or is used for absolutely nothing. A whole UI for secondary textures but no way to actually, y'know, access them in a loving sprite shader. Maybe it's been fixed but that's been the whole story of Unity over the past two years - new poo poo nobody can actually use.

Ranzear
Jul 25, 2013

Flannelette posted:

you aren't making a beautiful chair simulator.

I'm reminded that Chair loving Simulator exists. Thanks a lot...

Ranzear
Jul 25, 2013

gently caress wrong thread lol

Ranzear fucked around with this message at 05:25 on Aug 20, 2020

Ranzear
Jul 25, 2013

Probably a lot of slowdown in app development due to human malware. Just a way shorter queue now.

We learned to just always mark our approvals as 'urgent' or whatever, because there is literally no reason not to. Under 48 hours wasn't uncommon even last year if it got in before morning on the west coast.

Ranzear
Jul 25, 2013

SweetBro posted:

Obligatory reminder that using bitmap fonts makes Chinese localization a big pain in the dickus.

Even Japanese can run into character limits and having to keep a list of 'valid' kanji. It also breaks emoji support if you have some reason for those (in-game chat or whatever).

Adbot
ADBOT LOVES YOU

Ranzear
Jul 25, 2013


Unity can be set to have your window colors change while in play mode. Can make everything turn red so it's always obvious.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply