TFR Guidelines [READ]

[TheShyGuy]

Try not to plan the game out for only FM2K. Otherwise, you're excluding ideas that can be done by others in the future. I've been thinking about attempting programming tFR from scratch(sorta -using the MFGGTKO engine) sometime and it would suck if the game was designed around FM2K only.

[Kosheh]

Try not to plan the game out for only FM2K. Otherwise, you're excluding ideas that can be done by others in the future. I've been thinking about attempting programming tFR from scratch(sorta -using the MFGGTKO engine) sometime and it would suck if the game was designed around FM2K only.

Oh if that's in reference to my post, I phrased it like that because that's all we've got right now



what I mean though that on a PC you don't have pressure sensitive keys to begin with (imagine the GCN's L and R trigger buttons - and these are a thing on every input button on every console nowadays it seems - the Playstations have always had pressure-sensitive buttons) sooo it's kinda hard to plan an attack strength mechanic around that. We need something more...

not based on pressure sensitivity.

[TheShyGuy]

At first, I was going to do a large brainstorm dump, but that ended up too long. Instead, below are just bullet points about ideas that I feel need to be further discussed.

TL;DR I need input on the bullet/bolded points

Input Buffering

• -Single long input buffer string?
  
• -buffer keys + duration, include "spaces" (game steps when no key is pressed)
  
• -When to Clear Buffer
  
• -Consuming keys
  
• -Error Tolerence

Comboing/Chaining Attacks
-We can get some unique characters with this, but it seems like the guidelines have a fixed set of moves. What if the bare minimal moves required are just those that exclude combos. So combos would be something that's depends on the character. Yeah, it requires learning characters, but I think the potential is worth it. The basic moves would remain (Idle, Crouch , Jump, Attacks mapped to single Punch or Kick Key, etc).

Collision Interaction and Masks

• Collision Types
  • Attack (offensive)
    
  • Hurt (weak points)
    
  • Defensive (like shielding)
    
  • Special? (for projectiles - reflectable?)
    
  • Grab
    
• Collision Interaction
  • Are there collision priority?
    
  • Are we even doing the "High" attacks can only hit "High"/"Mid' tagged hurt]regions?
    
  • Or just normal collision mask detection? (preferred. It makes more sense to me)
    
• Knockback?
  • Variable or constant independent on player damage (I don't play many fighters)
    

Online

• -Should this be the first thing worked on or later down the dev? Personally, I've never done multiplayer networking.
  
• -Safety of executing other's scripts?

Animation Engine?

• -simple frame-based animation? (traditional sprite animation)
  
• -Or feature-filled animation engine? (longer dev time for making the tool. Unless someone has a reccomendation for an animation tool. Prefably free for accessibility.)

-Scripting/Customization for Stages and Characters (even the Character Selection Screen, Menus, Stage Selection Screen too??)
-Characters/Stages Creation Tools
-Frame Rate? 60fps or 30 fps? Who cares?

Edit:

To further explain things, I do plan on doing a tFR attempt within a few weeks. But I'd rather discuss a few things before jumping right in totally blind.

I really need to know what kind of animation engine is good for the game. I'm leaning towards a plain and simple animation engine. I've overengineered and poorly designed a bit of animation engines overtime. They all resulted in engines that I'm not happy about that all required me to make relatively complicated tools at the times. It's getting old and annoying to keep failing lol =p. A simple animation engine + tool sounds refreshing. Something that only includes what's necessary and nothing more. Until I get more feedback on this, I'll focus my attention on other things. I'll take a pre-existing free animation tool too. The goal is get animations in game. I can support converting GIF frames to an animation which will hopefully make things alot easier. Animate in Graphics gale, gimp, MS paint and turn it into an in-place animated GIF. Import into the animation tool and save. Done. It's useable in game (sorta). Err gotta stop editting this post.

From what I researched, Input Buffering/control can break a game. That's something that can be further refined during dev with playtesting. Really, Input Buffering + unique combos + free control of scripting moves sounds like it has lots of potential to be really fun to make and play. I've thought about how I'd handle input buffering and executing combos while compensating for error tolerance. I'll go into more detail in later posts because all these edits are making this post too large......again.

Scripting is going to be the center of content creation- for stages, characters and maybe even the menus. Later, I'll need good community feedback on scripting to make sure it's user-friendly and intuitive enough to use, especially for non-programmers and artists. What kind of scripting do you guys expect (What kind of customization do you guys expect?).

Online? Like I said, I never did online networking. For an online community, it sounds pretty important. It's likely that I'll put up public prototypes of networking alone instead of a tFR with networking. The reasoning behind this is due to having part of the game engine already done thanks to working on MFGGTKO for half a year. I didn't implement the engine with Online in mind. I think it'd be simpler to get a feel for networking and see how that might affect the existing engine than to blindy start throwing networking code into it.

Edit:

I guess I'll just work out the details solo instead of getting input about how things work from the community

[TheShyGuy]

I might make my own programming thread after I'm done with some of the animations I'm working on. I think there should be another one dedicated towards the actual in depth mechanics and design of the game too. These two posts don't feel right to be in the Guidelines thread or the References thread.

Anyways, thanks everyone for helping and working together to design the mechanics

I'm still doing research but here's what I'm thinking.

Input buffering:

There's going to be a single input buffer. The length of it will be the length of the longest move + some padding space. I'll only be buffering the game keys + empty moments when no key is down. The moment and duration a key was pressed will be buffered and whether or not the key is still down. This allows putting time limit on how long a move input needs to be executed within. The buffer will only be cleared: for the player who gets hit, both players if either parrys, for the player who gets grabbed or some status effect that stuns them. Consuming keys will be up to the coders for a characters. I don't want to hardcode force consuming keys when checking for them returns true. Oh yea, for move inputs that are a "sub input" for a longer move, I'm not entirely sure how to handle that. From research, it seems that you check them from longest to shortest (done by character scriptwriters). Then script to allow the small sub-input move to be able to cancel into the longer move a few frames into it. Error tolerance...hmmm. I think it would be okay to be strict with the attack button order and a bit lenient with the direction button order. So attack buttons MUST be pressed in the correct order, but directional keys will probably allow multiple different orientations. Maybe it should be as strict as the attack buttons? I'm not actually sure heh.


Combing/Chaining Attacks
Combos will be easy to do and code/script. A combo is really just "while doing A, allow the option to go to B" -- While punching, if up + punch button pressed, do jab-uppercut combo. The script will literally, most likely ,closely look like this:

Code:

...
subactions.jab = function()

    ...

    //stops following code from executing until frame 25
    events:asynchronous(25)
    
    //events.changeAction(Action,requirement condition)
    //if true at any point after this call, the action (move) will change
    events:changeAction(actions.upperCut, events:buttonsPressed(up,punch))
    
    ...
end

The player is able to combo into UpperCut anytime after 25 frames of animation if he pressed up+punch. Easy right? That's how combos will most likely be scripted. You can build long or even repeating combos if you wanted to. This also means that input tolerance for combos can be more strict since the input is only looking a small segment to be executed by the player at obvious moments in a combo.

Collision interaction/Responses

A single attack collision mask 'group' can hit multiple opponents at the same time, but only once. With an attack collider that hit opponent A at frame X, the same collider can hit opponent B (assist?) at frame X + Y (later). If an attack collision overlaps at all with a defensive collision, it will not try to collide with a hurtbox even if it overlaps the hurtbox. I'm unsure if there should be attack collider priority to handle what happens when two attack colliders overlap. For example, a "strong" collider should overpower(cancel out) a "light" hit collider- thus the opponent gets hit but the player doesn't. Two priorities of the same value will cancel eachother out...or should they trade hits? I need help on these decisions, especially since I don't player fighter games often. I'm guessing we're going with "height" priority (low,mid,high). I'm unsure how things go, but I think that you can only defend against the same "height" priority attack. However, I saw something about unblockable combos (hitting low block stuns the opponent, calling an assist to hit high or mid guarantees a hit). They recommended that ONLY while in in block stun, the blocker can also block low,mid and high. I'm unsure, I'll have to research that more. Am I getting to in-depth with this? I'm guessing knockback is constant.

Online
For online, I'm going to look into something called GGPO. It was used for skullgirls and other mainstream(?) fighters. The main idea about it is that you can control how much visual lag you feel. You can control how much you visually compensate for lag. When you get input from the opponent or something, the game does a rollback...I'm still looking into it. I'm unsure if I'll even have it at all. It's pointless if no one will play it right?

Animation Engine
I'm thinking about going with the more complicated one. The main features that need to be supported are sprite animation and root motion (allowing the animation to move the character in game). The first one is easy to do with the simple engine. The second isn't tough to add onto a simple engine, buuut no one said anything so I'm going with something more interesting (mua- ha .....ha). The more complicated engine will support palettes, subanimations, key framed animation, normal sprite animation, and hierarchy (parent/child relationships). How long will it take to make the tool? I dunno. I wouldn't mind going with a simpler engine, but seeing as how no one cares to input anything, I decided to go with the one that will help me more in the future..-I think heh

Scripting/Customization
Lua. Not much to say on this right now.

Content creation tools
I'm thinking about making a character and stage making tool. The tools are really just for visual aid. You will be able to create attack, defense, grab, and hurt box/circles. I'm still working out if I should have this data be saved and automatically handled by the game, or the result script event/function be copied to your clipboard or pasted directly into the script. There will be a tree view of animations, articles and actions-subactions (moves). Clicking on an action or subaction will show the script text and animation for the action/subaction only. I gotta put more thought into the tool as a whole and it's design. The main goal will be to make it easy and nearly automated to make characters. Seeing as how each character has the same exact moves input-wise, I can create a character script template. All people would have to do is add in the collision data.

I'm unsure how to go about the stage tool. Stages are very similar to characters in that they also have an action/subaction system and use the same animation system. They will be able to generate attack collisions too (Or not? I might be thinking too much of smash bros). If people would rather go for just cosmetic stages, I can support them to just be an animation + a ground collision mask.

Feedback appreciated but not expected. I'll regret whining later lol

[Chris2Balls [:B]]

Sub inputs seem a bit complicated, and I'm not sure I followed what that was about. :/ Why would there be a different error tolerance between the direction keys and the other keys? Wouldn't it be simpler to keep it all the same?
No qualms whatsoever with your explanation of the combo chaining.

What you said about collisions/hit boxes seems pretty good to me. Hits of the same strength that collide, in my experience, cancel out. Hits according to height makes sense.

I don't think online is high on the priority list. I'm all for you to do the more complicated animation engine, root motion seems good to me!

For the content creation tools, a character script template would be the way to go, yes. This will encourage people to finish their characters, hopefully.

I think the stages should be left cosmetic for now, but you could keep the possibility of the stage system having an action system, yeah!


I hope this gets more support, as it'd make the work started by Robo and TomGuycott easier to handle for everybody!

[TheShyGuy]

Sub Input:
For example, if the (P)unch and (K)ick keys are used for separate moves. And (P + K) is used for another, then the both the punch and kick moves should allow a few frames to cancel into the (P + K) move. This would be more useful if players didn't have the same general basic button input for moves though. So this idea could be unnecessary.

Error tolerence Difference:
I'm not entirely sure what I was thinking at the time. I think I was thinking that for the gamepad and keyboard, direction buttons would be tougher to get 100% accurate (especially on a gamepad) than normal attack buttons. Thus keeping a separate buffer or way of checking the buffer (one for attack buttons, one for directions) might be necessary.

[TheShyGuy]

I know this isn't my thread or anything, but since I haven't made one, I might as well update others on things a little. I haven't done much and am deciding whether or not these fancy tools are even worth the time. It's a decision between niceties (animation and character scripting tool) and requirements (animation engine is done + the old tool program, the character scripting tool isn't a requirement but would be nice. I can always manually script characters myself and figure out what is actually needed for a tool instead of what I think is needed. I can create tools later anyways, so having no tools isn't set in stone. What's needed right now is game progress more than niceties anyways.

The core of the game are the characters. That much is pretty solid. Like I said before, the moveset system is done and, now, I'll just use the old animation system temporarily. That means that all I really gotta do is collision interaction/response, input buffering, and stage implementation. I don't think that'll take a whole lotta time but I'm terrible at estimating my work speed. At this point, I just want to finish the game so thats gonna be my main focus.

Just in case, I got no internet where I live and can only get on every few days so expect some delay time between responses.