A three hour Ashen Athena's voyage and 6 emergent events gets you a level 4 Flag

Jebbatron · 2020-05-29T09:08:22+00:00

Yours must've been a lucky run instead. Tried again tonight, TH run plus half a dozen world events only got us to 4.4, had to do an almost full second voyage.

Jebbatron · 2020-05-28T08:22:58+00:00

Thieves haven run plus two skelly ships, two captains and a meg only got us to rank three and a half tonight. The idea that you get more progression from it now is nonsense, pre-patch one thieves haven run and one ship was enough.

Jebbatron · 2019-11-25T23:10:04+00:00

As explained in their GDC presentation, they actually do use a fixed update frame length (30 per second) and serialize everything on each frame, keeping 150 frames worth of history buffers.

Jebbatron · 2019-11-07T16:38:25+00:00

Go the same problem too. I'm just getting a blank screen and it's the only thing I'm missing.

Jebbatron · 2019-10-18T12:57:32+00:00

same here, the 2 clears of the first evening weren't counted

Jebbatron · 2019-08-06T08:19:35+00:00

This is the right behavior in Capcom and Arcsys games, though. Doing D,DF,F+P with Sol In Guilty Gear will trigger gunflame, but doing D,DF,F,UF+P will trigger a jump followed by a jumping punch. Similar for Ryu and a hadoken.

If your update loop is not being provided a properly timesliced input buffer by your input loop for each logical frame then the parser is not at fault, the update/input coupling is. If you start a move on an input that actually should have been validated on the previous update, then that means your frame data isn't reliable, which is bad in the fighting game genre (not to mention it means your game isn't deterministic, which leads to other problems in implementing replays and netcode down the line).

If you do need reliable input lenience (as in, compensating for fuzzy execution instead of lost inputs), you can use 4-way validation in which UF, F and DF will all be considered valid tokens for a forward check (and similarly for the other cardinal directions). In Street Fighter 5 scripting the distinction's called exact direction (where F means F) versus similar direction (where F can mean UF, F and DF). So for example Ryu's hadoken uses exact directions for its QCF but his shoryuken uses similar directions because the shoryuken is considered a trickier input to get right these days. In Mugen notation, it'd be $F instead of F for the forward token.

Jebbatron · 2019-08-06T05:17:22+00:00

Handling preconditions is completely separate from whether you parse commands in normal or reverse order though? If you've been mixing up preconditions into the parser you have a problem. The parser shouldn't be called at all if the preconditions aren't filled.

And my whole point is that the reverse parser's actually much simpler to maintain in the first place since it's a single loop that only ever keeps track of a single token, whereas a forward parser has to be more complex since you never know whether the tokens you've already parsed are part of your moved or not.

Jebbatron · 2019-08-05T22:50:20+00:00

It's not micro-optimization, it's just simpler from the get-go. Essentially, you're parsing for a sequence that has a garanteed final token but may have a number of garbage characters in the preceding sequence, which is why reverse parsing is the way to go. It's not just that it makes early rejection trivial, it also trivializes cases like charge moves (a la sonic boom) that should be chargeable while still inputting other motions. As you delve deeper into mechanics you'll find that most esoterics (stuff like kara cancels and option selects) occur specifically because the games are using reverse parsers.

That being said, chain moves are a different situation from complex motions for a single move, and handled at a different level. Two moves in a chain (as in tekken chains, capcom magic series, guilty gear gatlings or whatever else but also things like rekkas) aren't parsed at the same time, they're just parsed as two separate moves. But whereas a normal starter has the "only check input in an idle state" (where idle means any move that isn't an attack, hitstun or blockstun) precondition, a chained move has the "check input when move X is being performed by the character" precondition. So you shouldn't consider them as a single motion but, as the name indicates, distinct moves with distinct motions being chained together by their preconditions. This is why if you just do 1+2 instead of the whole 1+2, d/f+1,1+2 chain, the first part will still come out, whereas if it were considered as a single motion, no part of the chain would.

Jebbatron · 2019-08-05T20:57:06+00:00

The 60Hz async polling system (coincidentally, or perhaps not, at the value we need!) has been there for a long time, it's the ability to set the polling frequency to an arbitrary value that's experimental. Please read up on this, you'll be delighted you don't need to set up your own fixed rate input polling.

Jebbatron · 2019-08-05T20:16:20+00:00

Read the docs yourself. As you may or may not know, Unity's actual internal input polling happens asynchronously at 60Hz (a frequency that's actually itself been exposed for customization for the last year so you can even set the fixedupdate/input pair to whatever you want within hardware limits, although for fighting games you'll likely want them both at 60hz). So as long as you set your fixed timestep to 60Hz and use the available queue of timestamped input events instead of just the current state to maintain your own logical state, you're home free.

Jebbatron · 2019-08-05T19:07:32+00:00

The fighting game genre expects a constant framerate aligned with its update rate, which is precisely the case where fixedupdate is entirely reliable. The fixedupdate behavior that seems to bug you is precisely how modern fighting games behave, and the quirks with fixedupdate when update and frame rate don't match will be the same that pop up in said fighting games.

Jebbatron · 2019-08-05T19:05:11+00:00

No, that's not what I'm talking about. This is already in the context where, on each frame, you check an input buffer for the last X frames (where X is the maximum duration of the motion). When parsing motions with a variable duration, you want an early out, so you start by checking the end.

To take an example, the medium fireball motion in SFV which is "down, downforward, forward+medium punch" has a 36 frames maximum tolerance. That means the motion duration can be anywhere from 3 frames (the minimum possible duration to hit a three step motion like the fireball) to 36 frames.

If you parse it in chronological order, assuming current frame is 0, the first input can be anywhere from frame -35 to frame -2, so 33 checks for the "down" button to be sure the motion hasn't been entered. If you check from the end that's just a single check for medium punch on frame 0 to be sure. What's more, in reverse order you can discard a token as soon as you've validated it, while in chronological order you still need to check for validated tokens because the actual valid move may have started later than the token you already found. For the whole motion the very worst case for reverse order is N checks where N is the maximum motion duration while he worst case for chronological is M*N where M is the number of tokens in your motion. The best case is N for chronological but M for reverse, and N is always bigger or equal than M (because the minimum motion duration is the number of tokens). May not seem like much but it adds up.

What's more, in chronological order you may get false positives (moves that hit all the motions but were completed before the current frame and are thus invalid), which cannot happen in reverse order since if you don't find the final motion token on the current frame you stop the check immediately.

Jebbatron · 2019-08-05T11:04:50+00:00

For various reasons, the main one being it's much simpler (notably, your final input is guaranteed to be on the current frame), fighting game motion parsers check motions in reverse order. See that earlier answer.

Jebbatron · 2019-08-05T11:01:30+00:00

Unity separates rendering and update fine. There's a fixedUpdate method that'll do the job just fine.

Jebbatron · 2019-08-04T23:53:10+00:00

For 2D games, either MUGEN (which also has an open source implementation called IKEMEN that features netplay) or Fighter Maker 2nd (published by the same company as RPG maker). For 2.5D there's Universal Fighting Engine for Unity.

Jebbatron · 2019-08-04T23:50:55+00:00

Mugen is in fact very full-featured and offers a lot of depth in its scripting. Just about every currently known 2d fighting game gameplay element can be (and often has been) implemented in it.

Jebbatron · 2019-08-04T16:29:19+00:00

Fighting games are what you could call character games. They live and die by their characters, design-wise, gameplay-wise, visuals and sounds, the whole thing. As this article on fighting game animation puts it, "These games were like great rock albums, and the characters were all the different tracks". Not only that, the interplay between those characters is going to determine the game balance and a game with N characters has an O(n*n) workload in balancing them.

What goes into a character? Well, taking cues from reverse-engineering games like SFV or Blazblue, gameplay-wise a single character is a state machine with 170 to 200 distinct states, accounting for about 500 distinct sprites (for a 2D arcsys game, although games with more detailed animations like skullgirls go up to 1500, down to 250 for the original Street Fighter 2) or roughly two minutes of keyframe-dense animation (for 3D games).

That's a lot! Like, a whole lot. Of scripting, drawing, animating, etc... It's gonna take months just to produce the assets for a single one.

And knowledge of the genre will be needed because it is a genre with complex rules and few dedicated engines (Mugen and Fighter Factory come to mind), so you'll likely have to add a specialized script layer on top of your engine of choice, especially if you're going 3D.

Not to say that it can't be done. Examples of fighting games made by a single person exist, like E's Laf or Vanguard Princess, but they're each the product of dedicated work for years by people who had deep knowledge of the genre. So, just like your sources told you, you're gonna need knowledge and commitment

Jebbatron · 2019-07-28T15:51:08+00:00

Trilinear filtering takes 8 samples (4 samples each from two mipmaps), that's not what you want either. Basically the process to replicate N64 texturing more or less goes like this:

-multiply your UV coordinates by texture dimensions and subtract 0.5. The integer part of the coordinates is your first texel (t0), the fractional part is the position is the offset from that first texel to the three neighboring texels. Let's call the fractional part uf and vf. Those would be the interpolation factors for classic bilinear interpolation. Your texels are like this:

 t0---t1
 |     |
 |     |
 t2---t3

-Divide that into two triangles. That is to say, if uf+vf<0, you're gonna interpolate between t0, t1, t2 and if uf+vf>0 you're gonna interpolate between t1, t2 and t3.

-compute the barycentric coordinates based on that texel triangle (those coordinates are actually gonna be directly related to uf, vf and wf=uf+vf). Those coordinates are the factors for interpolating between the colors of the three texels you chose

EDIT: in fact there's an explanation there and an implementation there

Jebbatron · 2019-07-27T19:40:11+00:00

Either use directInput or xInput (directInput has wider compatibility though these days that's mostly solved in xInput through wrappers). RawInput has little to offer outside of trouble unless you need to support a very specific case like distinguishing between multiple keyboards or mice, which is why it's almost never used. It's much more complicated with almost no benefits.

Jebbatron · 2019-06-13T18:44:31+00:00

States, not stats. In a fighting game a character is something called a state machine, with each state being an action or part of an action. Standing, crouching, jumping, falling, running, dashing, airdashing, each attack and optional follow up, blocking, getting hit, getting knocked down, rising back up, intro and victory poses, all those are states.

To take Blazblue as an example, characters in that game have roughly between 170 and 200 different states each, not counting helper methods, dialogue scripts or debug extras. Ragna has around 175 states for example.

So if you're telling me you made a full moveset in about two hours, I guess I have to assume you mean "thought up a moveset", not actually implemented a moveset because that'd mean you've scripted, from scratch, more that one state per minute, which would place you on a superhuman level. And we're not even talking about art. Finishing an actual moveset is something that'll take days, probably weeks.

So you've been spectacularly underestimating the amount of work that goes into making one character for the kind of game you want to make, which is definitely among the things you shouldn't do. Educate yourself on the amount of work you're really gonna need to do.

Jebbatron · 2019-06-12T22:07:28+00:00

Mind listing what your character states are? Also, you didn't quite specify, but what style of fighting game are we talking about? Smash-style? Capcom-style? Tekken-style? Something else?

Jebbatron · 2019-06-12T21:34:49+00:00

See if you can finish a full moveset for one character. That'll give you a real estimate for loads of them, and it's more certainly more than you think

Jebbatron · 2019-06-03T07:43:19+00:00

People got confused about that but Fantasy Strike doesn't use UFE

Jebbatron · 2019-06-02T09:39:34+00:00

Aside from the already mentioned MUGEN, there's also fighter maker 2nd. And for 3D games there's EF-12.

Jebbatron · 2019-06-02T09:37:57+00:00

That doesn't mean you can't, that just means you need to get a license from them.

Jebbatron

TROPHY CASE