The VG Resource

For the newest build (7/31/16), check this post http://www.vg-resource.com/thread-26351-...#pid620742
 

---

*Skim the headers.  If there are any questions or confusion, please ask.

Any discussion in this topic should be about the game engine, not content.  Of course, discussion of whether the engine is capable of, or potentially capable of, certain content is allowed.

Hello, everyone.  The game is being programmed in C# using XNA along with Lua for scripting.  My main focus has been on stages and characters.  Right now, scripting-wise, I think they are both nearly done.  I just have to move focus to the other important aspects, like collision response (getting hurt, grabbed, defending, etc), then "fighting" would be done.  By that point, there should be enough support for finished stages, characters and assists, unless I'm forgetting something.  The next things to do would be minor game-wise. They would be the actual menus, menu tool, battle HUD, character debug tool, etc.  The character debugging tool is just to ease placement of fighting collision bubbles and stepping through subactions.

---

---

If you have any questions, please ask.

Using Machobot's spritality to test defending soon.  It was really fun to do.  Although, it could use some additional GFX.

Sound warning. This is smaller than I thought it'd be. Just go to the youtube page instead.

I'm digging the sfx

Thanks.

I should be clear, though. I'm not working on any characters at the moment. The Gors, C2B and Machobot videos are more for testing.

I'd also like to point out that I do have questions that I'd like answered. The collision response questions would help clarify details. Although, I'm aware that the project was mostly focused on sprites so no one may actually have an "official" answer.

Edit:
Here's my plan for the fighting collision detection/parser. Fighting collisions are prioritized by ID. The lowest connecting, or overlapping, bubble ID (lowest being 0) will only be considered for influencing the opponent's collision bubbles. If a collision bubble is cancelled, proceeding ID's will be cancelled out in the further stages of parsing the detection. The stages of collision detection are in the same order shown below. If a collision bubble is cancelled in a previous stage, then it and proceeding collision IDs of the same type will be cancelled in the further stages. '--' denotes that the section of collision types is completely independent of the other sections. Below are all possible types of fighter collision overlaps given offensive, defensive, grab, and hurt collision bubbles. Here's my thoughts about fighting collision detection:

• <collision pair, self vs opponent > | <possible result>
  
• Off vs Off | cancelled by opponent
  
• Off vs Def | opponent defended, damage reduction, break through? (defense ignored)
  
• Off vs Hurt | damage opponent
  
• ---
  
• Grab vs Grab | grab cancelled?
  
• Grab vs Hurt | opponent grabbed.
  
• --
  
• Off vs Grab | n/a no meaning
  
• Grab vs Def | n/a grab cancelled? (dependant on if particular defense defends against grabs)
  
• Def vs Def | n/a no meaning
  
• Def vs Hurt | n/a no meaning
  

Off -> offensive/attack collision bubble
Def -> defensive collision bubble
Hurt -> ...Weak, hittabled collision bubbles
Grab -> Grab collision bubble

As a result, this system supports trading hits if both players hit the other's hurt bubbles, attacks can cancel eachother out or "overpower" another, grabs can be cancelled if both players make an attempt at the same time, grabs can be defended against (may just be n/a?. I can't think of good example), grabs can..grab if not cancelled.

Off vs Grab has no meaning. "What happens if you punch someone trying to grab you?" - the overlap has no meaning. Note, you can still hit the opponent and he can still grab you. Def vs Def has no meaning, atleast I can't think of a good example where it is meaningful - atleast in this game. Def vs Hurt is meaningless.

This should be solid enough for the detection system.

IMO movement should be fixed, and blocking directional. I'm for stun times, too.

As for collision responses:
-grabbing and being grabbed: I think the grab should have more or less reach according to each character, and being grabbed can be blocked if timed correctly? I wouldn't go for a Smash Bros. style grab, but more like a SF throw, I guess.
-defending: chip damage? maybe the specials could break the guard? recoil against strong attacks?
-not quite sure what you mean by hit lag
-hurt state: avoid a vicious cirle of being stunned and being open to hits, leading to a fast KO? in that case create a system in which the player is protected from hits for a small amount of time etc. it could be fun if being hurt led to being pushed back or something.

Thanks for this thread and your work, it's great that you've undertaken this project! I think once people can get their hands on a build they will be able to say what should be improved or not.

Keep going, man!

The collision bubble info (damage, knockback + angle, recovery frames, hitlag, etc) are defined in the moveset scripts. So, they'll all be open to balancing later.  From now on, I'll just refer to hitlag as the number of frames both parties are frozen for and hitstun as "recovery frames", the number of additional  frames the opponent is frozen for.

Reading through some things, there will probably be damage scaling where the amount of damage and duration of recovery decreases based on the amount of combos executed.  I could also do the temporary invincibility after being hit.  

Yeah, knockback is going to be implemented.  I'm guessing the amount of knockback is fixed.  Otherwise, it'd turn into smash bros.



~Appreciated

Okay, got it!

That would make sense for the combos, yeah. However, one exploit could be to keep starting combos, inflicting more damage than say a consecutive series of combos, so maybe you could add recovery time for both players?

I think fixed knockback would be better suited :p

Hmm. Well, we can figure out what does and doesn't work later on when we can test things out.

I guess I should answer some of the questions you had. Keep in mind that whenever Gors and I started this, we didn't have a design document in mind and while he set out some guidelines with the sprites, I was given free reign over the game. While my original idea was a momentum based fighter to where the higher combo you had the more options available, Gors sprited for a more traditional game.

Quote:How does the collision response in tFR actually work?

I'm not sure on what you mean on this. DO you mean the detection? Because that was handled by using multiple small boxes that resembled the shape of the sprite.
Are attack responses fixed? For example, some attacks always launch or just cause hitstun.

Quote:Are stun times (recovery times) a thing? Like, if the opponent is hit by attack mask 'A', he'll be stunned for 'X' frames, always? (http://www.vg-resource.com/thread-20507-...#pid549030)

Yes, that was the plan. Each attack had a specific amount of hitstun, and it depended on the attack. It didn't scale like Smash though

Quote:How does jumping work. Is movement fixed or can you move back and forth in the air, like smash bros? Right now, Gors has fixed jumping, but C2B has more of a smash bro jump. Which is correct for tFR?

I planned on using what would be mixture of both. There was some movement, but it was minimal.

Quote:Is defending directional, like Gors, or radial, like C2B?

I used directional

Although for all intents and purposes, this is your code. It doesn't really matter what I was doing, or what TomG did, or what the guy who showed up for a day and said he would do it did. Make it your own. Incorporate whatever, and remember it's a game for the community

I'm still working on the fighter collision response system.  I had an issue, but I solved it as I was writing this update.  Fighters will have some additional, non-moveset functions - template functions.  There will be 2 for hit stun, "ApplyHitstun" and "RemoveHitstun", and 2 for the context of grabbing (well being binding/attached), "ApplyBindState" and "RemoveBindState".  I can attempt to hardcode support this stuff, but it wouldn't be the best idea.  So implementing the functions correctly is up to the scripter.  However, it shouldn't be too complicated to implement them correctly.


Anyways, this isn't new, but here's some GIFs showing off root motion in action:

http://i.imgur.com/hODgBpl.gif
http://i.imgur.com/qx56M2p.gif
http://i.imgur.com/j4MVqUr.gif

Root motion is just animated movement.


I'd also like to note that tFR needs some graphic effects in general.   I assume sound effects aren't custom and are just used from other games.  Also, for anyone with content (characters, stages, assists), it'd would help if you made an explanatory description of how they work.  I don't need any of this right now, but I just wanted to give a heads up.

(12-21-2014, 12:06 AM)Sportoise Wrote: [ -> ]

Quote:How does jumping work.  Is movement fixed or can you move back and forth in the air, like smash bros?  Right now, Gors has fixed jumping, but C2B has more of a smash bro jump.  Which is correct for tFR?

I planned on using what would be mixture of both. There was some movement, but it was minimal.

If we're going for a Street Fighter-feeling game, I'd suggest fixed jumping movement. Mindgame jumping, with characters like Wario and Jigglypuff, would be a bit of an overload and would be extremely hard to fight against (and also pretty easy to abuse the hitstun making crossup combos way too easy)

If we have double jumping in the game, if you have fixed directions but can then change your direction in which you're jumping (i.e. jump forward, then double jump backwards) that would work and be...interesting, honestly.

The animated gifs above though: um, wow. I like the speed of this engine.
Would it be possible to create "turbo" modes too, for more pixel fighting mayhem?

Characters don't share the same moveset. Well, they do share a template, but whether they follow the "guidelines" of the game is up to the scripter. For now, that's just me. Later, nothing is stopping people from adding double jumping or Wario/Jiggly mindgame jumping. They can do so if they like or not. That's the point of customization. For the "official" tFR game(s), we can agree on some standard for the sake of consistency though.
__

By turbo, did you mean changing the speed of the game? I had trouble recording the gifs, so they might be choppy. I can't tell if its my computer or the gifs are just bad.

http://i.imgur.com/3D7if6H.gif 1/2x speed?
http://i.imgur.com/1BDSXmn.gif 2x speed?
http://i.imgur.com/44ZUYE7.gif 5x speed? (with game lag)

All I did was change the amount of game updates per step. I wouldn't be surprised if doing so causes some bugs lol.

__

I took the GIFs out of IMG tags because I'm starting to understand the pain of slow loading pages...

I think he's talking about a SF turbo styled game. Or maybe a PM styled one, idunno. I could actually handle something like that in my spare time if you wouldn't be interested in doing it

I've haven't played a variety of fighting games, including any Street Fighters. I'll have to look into what turbo mode actually is unless someone wants to give me a brief explanation.

...Sportoise, I also don't know what you mean by PM, haha. I may be programming this, but don't assume I know a whole lot about the genre heh.

Also, could you elaborate on the last sentence? Are you referring to helping me with coding or something else?

~time to do more googling.

To be honest, I confused SF Turbo with SF Rainbow. SF Turbo was essentially a faster, more competetive version of SF. I guess what he was suggesting was a version of TFR that would've been quicker and more with a higher skill ceiling.

By PM I meant Project M, which is a mod of Brawl that tries replicate the Melee engine. It has a mode called Turbo that allows you to cancel any move into another one

I was suggesting that if you didn't want to do a Turbo edition, I'd be happy to do it.