TFR: Scratch Edition [Program] - TheShyGuy - 12-14-2014
For the newest build (7/31/16), check this post http://www.vg-resource.com/thread-26351-post-620742.html#pid620742
News May 19, 2015:
- Required character animation count has been reduced to ~20 animations instead of the ~40 animations.
- Input Buffering, Online, AI, Story/Arcade Mode, Community Customization, Main Menu, and Options Menu are scrapped due to non existent community interest and lack of content. Each take a lot of time and hard work and the benefits are non existent, thus they will no longer be supported.
- Only Player Vs Player battles will be supported
The bare minimal required animations for characters are:
- Idle
- Walk Forward
- Walk Backward
- Duck
- Jump
- Fall
- Punch 1
- Kick 1
- Duck Punch
- Duck Kick
- Jump Punch
- Jump Kick
- Special 1 (can be offensive, defensive, healing ,etc)
- Grab
- Grab Attack
- Throw
- Standing Defend
- Duck Defend
- Air Defend
- Hit
- Knock Down (Face plant)
- Get Back Up
The forward and back attacks can be replaced with the neutral attacks (normal punch or kicks). There only really needs to be one special for consistency between characters. Status effects (burnt, electrocuted, etc) and the variations of getting hit can all be replaced with the normal Hit animation. Although, due to game mechanics, Knocked Down (Face plant) and getting back up are still required.
As a result of the scrapped features, only the bare minimal of the game is needed to be coded. Which means that I only have to finish the fighting system and add content. As of today, I've finally supported working grabs and throws. Fighting-wise, I just have to support defending and cancelling out equivalent attacks that connect. After I'm sure the fighting system is done and stable, I will work on the menus and content. At that point, I'll probably restart a frequently updated devlog.
*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.
Try out the newest build! (2/9/15)
Download
https://www.dropbox.com/s/lx1qyvaaov6co4o/Build%5B2-8-15%5D.zip?dl=0
Make sure you have XNA redistributable installed:
http://www.microsoft.com/en-us/download/details.aspx?id=20914
There aren't really any obvious changes though. I'd say it's not worth the 60mb download, but I want to keep with the consistent updates.
Some things may not work, or break~
Additional controls:
"r" to create Chaoxy's grab assist.. which I forgot the name of...I wanna say glub glub but I'm almost sure that's not it.
"[home]" to open the editor. -You can't do much with it at the moment except select the character, set an action, pause, play or step the game, and set the subaction tick.
Try out the newest build! (1/1/15)
Download
https://www.dropbox.com/s/ut609y1f6zc8abp/Build%5B1-1-15%5D.zip?dl=0
Make sure you have XNA redistributable installed:
http://www.microsoft.com/en-us/download/details.aspx?id=20914
Please note that this isn't any sort of "alpha", "beta", or even "demo". It's a build. I'll do my best to have a monthly build, despite the current state of the game. Also note, characters are not in development, nor are stages. The current build includes debug content that I use for testing. I'm currently still working on the game engine.[/color]
The build currently only shows the debug characters, Gors and C2B, along with Machobot's spritality form. They were developed for testing purposes and do not reflect any of the member's characters accurately.
Debug Controls:
'Q' to create Gors
'W' to create C2B
'E' to create Machobot's spritality form.
'[Backspace]' to delete all the characters
'3' to show debug collision masks
'9' to play a random song
--
Gors and C2B Controls:
Left Shift: Jump
Arrow Keys: Move
Z : punch
X : kick
MachoBot:
Z : Spritality
Note: Again, not all moves are coded. They're debug characters.
Oh yeah. If you want to change the stage to Icicle's stage, open the file "Content\\Debug\\debug_stageToLoad.txt". Change the letter to I. If you want to go back to Chaoxy's stage, change the letter to 'C'.
Characters, Articles/Props, Stages, and Assists
Characters and articles have the exact same capabilities. I haven't made any assists yet, but i figured they'd operate similarly. I don't think assists require any "AI". They show up, do a fixed attack or get hit, and leave. The only difference between the three (and stages) may just be scripting.
At the moment, stages only support music, a single animation and collision masks. However, that limit is completely arbitrary. I've been thinking about just giving stages the same amount of capabilities as characters. That means they could have their own scripting/moveset to make them interactive (stage hazards?). For those of you who make stages, what kind of support would you like?
Customization (Chars, stages, assists)(Scrapped) [Low Priority?]
Update May 2015: Community customization has been scrapped due to non existent community interest. Supporting customizations for others takes time and work. Due to circumstances, the disadvantages greatly overcome the advantages.
I might scrap the idea of supporting community customization, at least for now. I'd have to actually teach people how to use all the non-user friendly tools and scripting stuff that's required to know. In the end, I think it would be a better idea if I just coded everyone's character and stage. To be blunt, it's not like there are many finished characters or stages right now. The advantage is that I can create them better, quicker, and they'll be less prone to bugs. However, I'd need in-depth information, gotta code every character, stage and assist, and there is bound to be misunderstandings in communication and thus require a bit of back and forth. During school, I have no daily internet connection, so I won't be available that much.
That said, please organize your spritesheet in a way that's easy for me to use the frames. Make it obvious which animation is which. Please align animations. I'd rather have extra white-space than have to manually align frames by hand. I can make use of GIFS too, so if that'd be easier for you to do, then please do so instead. GIFS are the easiest way for me to import an animation since all I gotta do is load them. GIFs should have the animation be in-place. However, I'd really appreciate if you also made additional gifs of the movement along with other information, like attack bubbles or an example of the move against an opponent.
I would also need good in-depth information about the actions themselves. How fast does he/she move on the ground? For attacks, how much damage and knockback do they do, literally? What about the direction of knockback? Where are the attack masks located (its a circle, so a position and radius). Is it a strong hit, or a normal one. The same goes for specials. Give as much info as possible, even if you feel it's redundant.
---
Hmmm. Maybe I'm not giving you guys enough credit. I'm all for community customization. It relieves work off me and distributes it in an effective way. However, I feel that there would only be a few people capable enough to be able to work through the issues of my tools and learn how to code. You won't have to really learn much about the coding API, err coding interfaces (rules, syntax, etc), as I've already made a veery basic scripting tool with intellisense. For scripting actions and subactions, at most, you'd have to only know how to create basic conditionals (If/else), loops and the premade events (functions) , which I'm confident non-coders can grasp easily and quickly. Not to mention, there's intellisense for all of those to ease having to memorize much. The tool hides most of the other things, even creating custom events and character-specific variables. More info later.
Scripting
Scripting is entirely done in Lua, mainly using coroutines. Lua is the core of movesets. There are events, requirements, actions, and subactions, If you want a scripted stage, then that means it'll make use of the moveset system. It's no problem, though.
An action is just a coroutine that's called once every game step. When an action is changed, the next action will execute immediately to allow for chained actions that visually don't do anything without costing a game step. There is only ever one action playing at a time per moveset. Actions usually set a subaction at its start.
A subaction is similar to an action. Except, it's called once per animation tick. It defines the animation to play, and there can be multiple subaction ... sub functions executing at the same time. I still have to work out some things that should happen when a subaction ends, like resetting the character to a consistent state. More info later, if needed.
--
I'm also in the process of creating tools to ease scripting. I've created a basic moveset scripting tool with basic intellisense. This intellisense helps you code by showing you names of existing valid identifiers (events, functions, etc) and also shows a comment or description as-well. This removes the need to look anything up, memorize code, and decreases the chance of typo related bugs. The tool also hides some of the syntax that one would other-wise need to know about. I'm in the process of planning a basic character debugging tool that allows you to "step" through moves on a per frame basis. I'm not aiming for a perfectly working tool, it just need to ease development. It's more of a one-off thing. More info later.
Animation
I've created an animation tool and engine but the the tool isn't user friendly. I'm only naming the main features for those of you who want to be creative. Otherwise, ignore the list.
The engine supports:
- Traditional Frame by frame animation
- Skeletal Animation
- Key framed animation
- Linear and Jump/Step Interpolation
- Root Motion Translation only (moving object by animation)
- SubAnimations (it just means using another animation within the current animation - a sub animation. Look at Chaoxy's stage. The cogs and floor are a great example.)
- Importing GIfs as an animation into the tool
- Exporting animations as a sprite sheet or GIF
- Opaque, Translucent, and completely Transparent sprites. (Fully transparency can happen if the sprite tint is animated)
- Palettes and Palette animation.
If there are any questions about what you can do, animation-wise, just ask.
Palettes
Palettes are supported by the animation engine, but not by the game engine, yet. I imagine that it would only require me to load a different palette file, which sounds pretty simple. Palettes would be unique on a per-character level.
Note: In the animation engine, a palette file is more of a collection of separate grouped pixel palettes in a single file. Why? This is to allow fading and switching between palettes in animation - animateable palettes. However, alternate "costumes/colors" in the game sense are separate palette files atltogether. Er, more info later. If anyone wants to be creative and has questions, ask. I'll provide visual examples if needed.
Collisions [High priority, need info]
In the fighting system, collision masks are restricted to circles. I usually refer to them as "bubbles". Honestly, I have no good reason for such a restriction. The collision detection system is, ofc, done and working. It's the same system as the normal collision system for the stage.
However, I still need to program in the actual responses, like hitlag and going into the hurt state. Although, I'm not entirely show how it should be done game-wise. I'm not familiar with the "rules" of getting hit, or atleast how it's supposed to work in tFR. I've played Soul Calibur, so I might build off that, unless that's an issue.
Oh yeah, I recently thought up how to go about directional defending. I really wanna use Robo9's super beam thing as a test so I might make a GIF of it later. There will also be support for sweet spots.
Menus [Medium priority, Content needed]
This will probably be easy to do. I already have an idea about how to go about it. The main thing keeping me from implementing it is that I'm unsure how the menu is supposed to look, content-wise. I've seen this, but I don't see any backgrounds. Also, I still gotta make the menu creating tool which will be easy.
For anyone who wants to make the menu sprites, I'm able to support intro, idle, and outro animations. You can also do a few other subtle things, but I'll give more info later, if needed.
Menus:
- Title screen
- Main Menu (Scrapped, unnecessary)
- Character Selection Screen
- Stage Selection Screen
- Other? (options, control configuration, etc?) (Scrapped, unnecessary)
Effects (GFX, SFX) [Content needed]
We're really lacking in the effects department. There are no sound effects or GFX at all. There should be common effects, that are shared between all character and character specific effects. Why separate them? In case the game ever gets to the point where people can make their own content, it'd be easier to add character effects without affecting shared effects.
AI (Scrapped) [Low Priority]
Update May 2015: AI has been scrapped from the game. There will not be any PlayerVsCPU matches since this kind of AI takes time. Since community interest is non existent, it seems that AI wouldn't be worth the trouble. Of course, PlayerVsPlayer will remain.
I haven't given much thought about how AI is going to work. I'll have to do research on how it's usually done since I have zero experience with this kind of AI.
Online (Scrapped) [Low Priority]
Update May 2015: Online has been scrapped from the game. Since community interest is non existent, it seems that Online wouldn't be worth the trouble and time. Of course, PlayerVsPlayer will remain.
Hmmm...Zero progress here. I'm thinking about using Lidgren for the networking. From what I researched, only inputs should be sent over the connection. This means that the game has to be deterministic, so I'll have to do a little bit more researching. It also requires that both player's have the exact same content.
Sound warning. This is smaller than I thought it'd be. Just go to the youtube page instead.
Dec.20, 2014:
- Added more info about possibility of customization. (See General Info -> Customization)
- Added more info about scripting tools. (See General Info -> Scripting)
- Added more info: Palette section (See General Info -> Palette)
- Added FAQs and Interesting posts section.
- http://www.vg-resource.com/thread-26351-post-576062.html#pid576062 - Fighter collision detection system plan
May, 2015:
- Input Buffering, Online, AI, Story/Arcade Mode, Community Customization, Main Menu, and Options Menu are scrapped due to non existent community interest and lack of content. Each take a lot of time and hard work and the benefits are non existent, thus they will no longer be supported.
- Only Player Vs Player battles will be supported
Todo:
-revise this post and make sure it includes only whats necessary
-looking into nLua (actively updated Lua 5.2+ wrapper for C#) instead of LuaInterface(uses older Lua 5.1, which seems like it can cause an issue).
-Collision Response:
- Grabbing and being grabbed [May 2015]
- Defending
- HitLag [May2015]
- Hurt state [May2015]
- Assist test[May 2015]
-directional defending test
-collision priority test (I'm not referring to height-based attacks)
Below are the current lists of characters, assists and stages that will be added due being finished content, with a few exceptions (i.e. not having status effects, Win or lose animaiton, or a Spritality/Gognio aren't issues)
Characters:
Assists:
Stages:
My Questions:
How does the collision response in tFR actually work?
Are attack responses fixed? For example, some attacks always launch or just cause hitstun.
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-post-549030.html#pid549030)
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?
Is defending directional, like Gors, or radial, like C2B?
For those of you who make stages, what kind of capabilities would you like? I can allow them to have as much support as characters, if needed. It'll be very easy to do. I haven't done so yet because it doesn't seem like it's really needed by anyone.
Since I'll be coding the content for now, I'm only doing those that are finished. I'll need in depth information about how the character, stage, or assist works.
(potentially)FAQ
How frequent will you post updates?
-I'm hoping to retry what I did with my MFGGTKO devlog. I'll try to post updates frequently. As for demos, hmmm. I can try for a monthly demo, regardless of its state. How that will go, I dunno.
What are the extents of projectiles?
-Projectiles will have as much capability as characters. I call them articles.
What are the extents of stages?
-If needed, I can allow them to have a custom script (moveset, really). Then, they can have as many animations as they want. You can even add little scripted "NPCs" by adding them as articles. They can interactive too, given they will have their own moveset.(Note: I'm talking about potential atm. No development has been done yet the solidifies the idea. But, I don't see any potential issues.)
Do sprites affect the character in any way or form? For example, would it affect the collision masks in any way?
-No. All your sprites do is look pretty. Otherwise, they don't add any functionality automatically in any way or form.
Are palettes supported?
Yes and no. My idea is to allow each character to have their own custom palettes. Yes: Palettes are implemented. No: There is no current system of setting a palette. Don't worry though, it should only require me changing a file to make it work correctly.
Zabaden: would you be able to implement a fighter who operates like the Pokemon Trainer in Smash Bros. and shifts between three characters directed by a third?
-I can imagine a way to do so in the engine's current state, along with some issues and lack of current support. If you want more info, ask.
What are the limitations of the engine?
-Uh, it'd be easier if you ask me the question of whether somethings are possible. The engine is still in development, so nothing is set in stone.
If you have any questions, please ask.
RE: [Program] TFR: Scratch Edition - TheShyGuy - 12-18-2014
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.
RE: [Program] TFR: Scratch Edition - [robo9] - 12-18-2014
I'm digging the sfx
RE: [Program] TFR: Scratch Edition - TheShyGuy - 12-20-2014
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.
RE: [Program] TFR: Scratch Edition - Chris2Balls [:B] - 12-20-2014
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!
RE: [Program] TFR: Scratch Edition - TheShyGuy - 12-20-2014
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
RE: [Program] TFR: Scratch Edition - Chris2Balls [:B] - 12-20-2014
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
RE: [Program] TFR: Scratch Edition - TheShyGuy - 12-20-2014
Hmm. Well, we can figure out what does and doesn't work later on when we can test things out.
RE: [Program] TFR: Scratch Edition - [robo9] - 12-21-2014
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-post-549030.html#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
RE: [Program] TFR: Scratch Edition - TheShyGuy - 12-28-2014
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.
RE: [Program] TFR: Scratch Edition - Kosheh - 12-30-2014
(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?
RE: [Program] TFR: Scratch Edition - TheShyGuy - 12-30-2014
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...
RE: [Program] TFR: Scratch Edition - [robo9] - 12-30-2014
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
RE: [Program] TFR: Scratch Edition - TheShyGuy - 12-30-2014
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.
RE: [Program] TFR: Scratch Edition - [robo9] - 12-30-2014
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.
|