TFR Guidelines [READ]

[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