Fighting Game in TGB?
by David Sirlin · in Torque Developer Network · 03/26/2007 (2:24 pm) · 4 replies
Hello, I'm new to TGB and I'm a designer, not a programmer. I'm also ridiculously knowledgeable about fighting games. Here's my quick resume on that:
*Multiple time national tournament champion
*Co-organizer of Evolution Fighting Game Series, www.evo2k.com, largest fighting game tournament in the US
*Represented the US at Japan's international "Super Battle Opera" tournament (yes, that's real lol)
*Wrote the book "Playing to Win" about bettering yourself through competition: www.lulu.com/sirlin
*Produced a series of tutorial videos for Super Street Fighter 2 Turbo, which appear on the Capcom Classics Collection 2 game disc: http://www.sirlin.net/archive/my-street-fighter-tutorial-videos-from-ccc2/
Enough about me. In looking at TGB, I first thought it would be a pretty good framework for a 2D fighting game. After all, it handles collision, animation, and layers. But now there's a bunch of things that I'm not sure you can really do in TGB unless you edit the C code. Again, I'm no programmer so I have no intention to do that.
First, take a look at this image by my friend NKI: http://nki.combovideos.com/ST/tenshyoukyaku.jpg
1) Different sets of collision boxes. In the link above, you can see the red boxes (this is where the character can deal damage) and the blue boxes (this is where the character can receive damage). There is also a third set of rectangles not shown: the "yellow" ones that determine the character's position. These are used to keep the characters from walking through each other and can also be used for range checks on throws.
Can you set up multiple types of collision like this in TGB somehow?
Note that I don't care about convex polygons and I don't care about pixel perfect collision either. In some rare cases though, it is nice to be able to attach two disparate attack rectangles, and trigger a different reaction based on which one hit.
2) Per-frame collision. Each frame of an animation needs its own set of these rectangles, so it's no good to be limited to a single collision poly for an entire anim.
3) Storing anim frames. I see from the PlatformDemo that you can take a bunch of still frames and put them together into an anim inside TGB, and play through the anim to see what it looks like and adjust the playback speed. Great. In a 2D fighting game though, a character might have, say, 200 frames of animation. Imagine that they are numbered from 1 to 200. Here are some sample moves and the frames they would use:
Weak kick: 1,2,3,2,1
Medium kick: 1,2,4,4,4,4,2,1
Each anim used particular frames more than once. Also, some frames are shared between the two different animations. Note that you'd want the collision rectangles to be tied to the move, not to the art, so frame 2 might have different collision when it appears in weak kick than when it appears in medium kick.
Can TGB deal with the storage/memory issues here? It would be better to store just the 200 unique frames (plus a bunch of collision polygons) rather than duplicating all the frames out for each move and storing, in some cases, dozens of copies of the same frame. I suppose you could write a script for "medium kick" that plays each frame in succession, but then you wouldn't have the nice anim viewer.
(cont...)
*Multiple time national tournament champion
*Co-organizer of Evolution Fighting Game Series, www.evo2k.com, largest fighting game tournament in the US
*Represented the US at Japan's international "Super Battle Opera" tournament (yes, that's real lol)
*Wrote the book "Playing to Win" about bettering yourself through competition: www.lulu.com/sirlin
*Produced a series of tutorial videos for Super Street Fighter 2 Turbo, which appear on the Capcom Classics Collection 2 game disc: http://www.sirlin.net/archive/my-street-fighter-tutorial-videos-from-ccc2/
Enough about me. In looking at TGB, I first thought it would be a pretty good framework for a 2D fighting game. After all, it handles collision, animation, and layers. But now there's a bunch of things that I'm not sure you can really do in TGB unless you edit the C code. Again, I'm no programmer so I have no intention to do that.
First, take a look at this image by my friend NKI: http://nki.combovideos.com/ST/tenshyoukyaku.jpg
1) Different sets of collision boxes. In the link above, you can see the red boxes (this is where the character can deal damage) and the blue boxes (this is where the character can receive damage). There is also a third set of rectangles not shown: the "yellow" ones that determine the character's position. These are used to keep the characters from walking through each other and can also be used for range checks on throws.
Can you set up multiple types of collision like this in TGB somehow?
Note that I don't care about convex polygons and I don't care about pixel perfect collision either. In some rare cases though, it is nice to be able to attach two disparate attack rectangles, and trigger a different reaction based on which one hit.
2) Per-frame collision. Each frame of an animation needs its own set of these rectangles, so it's no good to be limited to a single collision poly for an entire anim.
3) Storing anim frames. I see from the PlatformDemo that you can take a bunch of still frames and put them together into an anim inside TGB, and play through the anim to see what it looks like and adjust the playback speed. Great. In a 2D fighting game though, a character might have, say, 200 frames of animation. Imagine that they are numbered from 1 to 200. Here are some sample moves and the frames they would use:
Weak kick: 1,2,3,2,1
Medium kick: 1,2,4,4,4,4,2,1
Each anim used particular frames more than once. Also, some frames are shared between the two different animations. Note that you'd want the collision rectangles to be tied to the move, not to the art, so frame 2 might have different collision when it appears in weak kick than when it appears in medium kick.
Can TGB deal with the storage/memory issues here? It would be better to store just the 200 unique frames (plus a bunch of collision polygons) rather than duplicating all the frames out for each move and storing, in some cases, dozens of copies of the same frame. I suppose you could write a script for "medium kick" that plays each frame in succession, but then you wouldn't have the nice anim viewer.
(cont...)
#2
1) Yes, you can create t2dSceneObjects in script, and give them collision detection -- creating the Red, Blue and Yellow box's in your screenshot ... you could assign all your 'collision boxes' a dynamic field like "colType" that determines whether its Red, Blue or Yellow and handle the collision appropriately.
2) If your working with a small set of on-screen graphics, such as just having 2 players and a background ... you could create 'per character on frame changed' callbacks, that rotate, move or flip your invisible collision boxes -- this would require coding, but not C++ (just TorqueScript) ... you could simplify the coding by just placing all the frames, one by one, in a scene... then create the necessary scene objects and what not ... then copy/paste some of the data from the level file into the 'per character on frame change' code ... fairly simply to do, extremely tedious
3) The TGB Animation Builder has the ability for you to place duplicate copies of frames in an animation, so you could have an animation that uses frames 1,2,1,2,1,1,2,3,2,1 for example ... so if your character has a total of 200 frames that make up the 50 different types of animations that are possible ... TGB can handle that. And if you can create animations out of frames used in previous animations, then do it ... you'll save memory, disk space and a number of other resources in the process --- if you have 200 frames, and you can only fit 20 of them in an image map ... create a Linked ImageMap and use the linked Image Map for the animations --- so you'd have 10 PNG files, for example, 10 ImageMap's created from those 10 files, 20 frames in each file ... and a single LinkedImageMap that consists of the first ten imagemaps ... then use the 200 Frame Linked Image Map in the Animation Builder
4) TGB is accurate to up to somewhere like 50ms ... theres 1000ms in a second ... so, thats like 1/20th (or 1/200th ... my math sucks) -- but that accuracy is only relevant to schedules, as far as I know -- collision checks are performed on each iteration of the 'game loop', which effectively means, at the rate of the current FPS -- however, TGB has the ability to restricti FPS (it does this through frame skipping, I believe) ... 1/60th of a second accuracy may or may not be possible with TGB, in this case ... without C++ code
5) Collision detection in TGB is performed at collision -- in the event of moving an object inside of another object, and then enabling collision detection, you would have to do some serious math to determine "how deep" it was ... for example, if box A is at 1,1 and box B is at 0,1 ... both boxes are the same size, and are 1,1 ... then the depth is .5,1 ... which means they are parallel but box B is only overlapping with Box A by one-half the width of box A ... you'd have to know whether or not .5/Y was 'deep' or not ... again, math math math ...
Now, my turn ... my personal opinion is that ... Yes, TGB can handle remaking something like Street Fighter ... is it suggested? Probably not, especially without a really good understanding of how to code ...
What would i suggest? ... TGE comes to mind, with a set camera view to give the '2D' feel ... you'd get a higher quality of graphics, better performance, and more accurate collision detection as you could build multiple collision boxes around the model ...
Another suggestion ... would be a game engine designed specifically for making games of this nature, although, I'm not aware of any ...
03/26/2007 (3:27 pm)
Let's tackle this one by one, eh? :)1) Yes, you can create t2dSceneObjects in script, and give them collision detection -- creating the Red, Blue and Yellow box's in your screenshot ... you could assign all your 'collision boxes' a dynamic field like "colType" that determines whether its Red, Blue or Yellow and handle the collision appropriately.
2) If your working with a small set of on-screen graphics, such as just having 2 players and a background ... you could create 'per character on frame changed' callbacks, that rotate, move or flip your invisible collision boxes -- this would require coding, but not C++ (just TorqueScript) ... you could simplify the coding by just placing all the frames, one by one, in a scene... then create the necessary scene objects and what not ... then copy/paste some of the data from the level file into the 'per character on frame change' code ... fairly simply to do, extremely tedious
3) The TGB Animation Builder has the ability for you to place duplicate copies of frames in an animation, so you could have an animation that uses frames 1,2,1,2,1,1,2,3,2,1 for example ... so if your character has a total of 200 frames that make up the 50 different types of animations that are possible ... TGB can handle that. And if you can create animations out of frames used in previous animations, then do it ... you'll save memory, disk space and a number of other resources in the process --- if you have 200 frames, and you can only fit 20 of them in an image map ... create a Linked ImageMap and use the linked Image Map for the animations --- so you'd have 10 PNG files, for example, 10 ImageMap's created from those 10 files, 20 frames in each file ... and a single LinkedImageMap that consists of the first ten imagemaps ... then use the 200 Frame Linked Image Map in the Animation Builder
4) TGB is accurate to up to somewhere like 50ms ... theres 1000ms in a second ... so, thats like 1/20th (or 1/200th ... my math sucks) -- but that accuracy is only relevant to schedules, as far as I know -- collision checks are performed on each iteration of the 'game loop', which effectively means, at the rate of the current FPS -- however, TGB has the ability to restricti FPS (it does this through frame skipping, I believe) ... 1/60th of a second accuracy may or may not be possible with TGB, in this case ... without C++ code
5) Collision detection in TGB is performed at collision -- in the event of moving an object inside of another object, and then enabling collision detection, you would have to do some serious math to determine "how deep" it was ... for example, if box A is at 1,1 and box B is at 0,1 ... both boxes are the same size, and are 1,1 ... then the depth is .5,1 ... which means they are parallel but box B is only overlapping with Box A by one-half the width of box A ... you'd have to know whether or not .5/Y was 'deep' or not ... again, math math math ...
Now, my turn ... my personal opinion is that ... Yes, TGB can handle remaking something like Street Fighter ... is it suggested? Probably not, especially without a really good understanding of how to code ...
What would i suggest? ... TGE comes to mind, with a set camera view to give the '2D' feel ... you'd get a higher quality of graphics, better performance, and more accurate collision detection as you could build multiple collision boxes around the model ...
Another suggestion ... would be a game engine designed specifically for making games of this nature, although, I'm not aware of any ...
#3
There is the MUGEN engine that's used for homemade fighting games, and even the game Melty Blood which eventually got a PS2 release. I have no experience with that engine, and it seems to have some legal issues: http://en.wikipedia.org/wiki/M.U.G.E.N
Besides, TGB is cross platform, has the potential for an xbox live port, and is a close cousin to TGE, so it's just got way more going for it overall.
Regarding your TGE suggestion, can't really agree that a 3D game inherently has "better graphics," or "more accurate collision." And going to 3D greatly increases the complexity of making anything. Even the best 3D fighting game teams in the world have yet to create the deformations of characters (stretching arms, changing body proportions) that are used routinely in 2D games. A game like Capcom's 2D Darkstalkers (and all its weird, stretchy/morphing characters) is nearly unfathomable in 3D for anything under $20 mil, lol. 2D's main problem is being stuck in a low res world of 224 pixel tall native resolution, while 3D is now 1080p.
Anyway, all that aside, TGB is just easier to wrap my mind around than 3D stuff, so I figured it would be a better place to start learning.
Regarding the answer to #2, I think I get it, but I guess you'd have to keep around all 200 frames in the level editor so that you'd be able to tweak the rectangles, look up the data in the level file, then make the changes to the script. Sounds painful.
Maybe whole undertaking is too painful, even, but I'll probably play around with it for learning's sake.
--David
03/26/2007 (4:04 pm)
Thanks for the answers Mr. Higgins.There is the MUGEN engine that's used for homemade fighting games, and even the game Melty Blood which eventually got a PS2 release. I have no experience with that engine, and it seems to have some legal issues: http://en.wikipedia.org/wiki/M.U.G.E.N
Besides, TGB is cross platform, has the potential for an xbox live port, and is a close cousin to TGE, so it's just got way more going for it overall.
Regarding your TGE suggestion, can't really agree that a 3D game inherently has "better graphics," or "more accurate collision." And going to 3D greatly increases the complexity of making anything. Even the best 3D fighting game teams in the world have yet to create the deformations of characters (stretching arms, changing body proportions) that are used routinely in 2D games. A game like Capcom's 2D Darkstalkers (and all its weird, stretchy/morphing characters) is nearly unfathomable in 3D for anything under $20 mil, lol. 2D's main problem is being stuck in a low res world of 224 pixel tall native resolution, while 3D is now 1080p.
Anyway, all that aside, TGB is just easier to wrap my mind around than 3D stuff, so I figured it would be a better place to start learning.
Regarding the answer to #2, I think I get it, but I guess you'd have to keep around all 200 frames in the level editor so that you'd be able to tweak the rectangles, look up the data in the level file, then make the changes to the script. Sounds painful.
Maybe whole undertaking is too painful, even, but I'll probably play around with it for learning's sake.
--David
#4
as for better collisions, I simply meant that you wouldn't have to do as much work in TGE as you would in TGB to create your bounding box collisions ...
As for your response to #2 ... depending on how your working with things, yes ... you would most likely want to keep all the frames in the level editor -- HOWEVER, I've found that when working with large amounts of art assets, that it's actually more beneficial for me to chunk everything out into seperate projects... then use the 'datablocks.cs' from the projects 'managed' folder to build my level in the actual game project ... to allow for 'on need loading' of assets specific to a level ...
All in all, if your not a programmer, I would probably give up on the fighter concept ... or find a programmer capable of doing most of the stuff required ... also, there are engines out there that perform much better collision detection (such as pixel collisions)
03/26/2007 (4:48 pm)
@David, by better graphics, I mean ... you can have much nicer looking graphics, and gain performance ... where as, with TGB, to keep the framerates high, you've got to use low-sized graphics, which inherently reduce the overall quality of the image ... also, with TGE, you can play with lighting ... good DSQ's (animation sequences) would compensate for most of your concerns ... take a look at "gish" -- it was made with TGE and is a 2D Side-Scroller ... with unbelievable deformations ... it's a blob ... acts like a blob, looks like a blob, and "feels" like a blob ... of course, GISH most likely required quite a bit of C++ as for better collisions, I simply meant that you wouldn't have to do as much work in TGE as you would in TGB to create your bounding box collisions ...
As for your response to #2 ... depending on how your working with things, yes ... you would most likely want to keep all the frames in the level editor -- HOWEVER, I've found that when working with large amounts of art assets, that it's actually more beneficial for me to chunk everything out into seperate projects... then use the 'datablocks.cs' from the projects 'managed' folder to build my level in the actual game project ... to allow for 'on need loading' of assets specific to a level ...
All in all, if your not a programmer, I would probably give up on the fighter concept ... or find a programmer capable of doing most of the stuff required ... also, there are engines out there that perform much better collision detection (such as pixel collisions)
Torque Owner David Sirlin
4) 1/60th of a second accuracy. Fighting games gather input and update gamestate every 1/60th of a second. If the game slows down or something, it still needs to gather input at that rate, because it's really bad if inputs are missed. Ideally, graphics rendering slowdowns don't affect input or gamestate loops.
Also, let's say a move has 5 frames (5 60ths of a second) where the red attack rectangle is active. The opponent is knocked down (invulnerable) and stands up just in time to get hit by the tail end of that 5 frames (the last of the 5). Is TGB accurate enough to reliably register a collision that was valid, in this case, for only 1/60th of a second (1 frame)? Ignore networking issues for now; I just mean local play.
5) Collision "depth." It's useful to be able to script the reaction to a hit based on how "deep" the hit is. For example, in Street Fighter, the opponent jumps at you and you do a dragon punch (aka uppercut, aka shoryuken). If you do the dragon punch really early, then at the moment the opponent collides with it, the overlap of his collision with yours will be really small (only the distance he could travel in one frame, because one frame into the overlap, he gets hit).
But if you wait until very last moment possible before the enemy gets to you, THEN you do the dragon punch, your collision rectangle will suddenly turn on and have a huge overlap with the opponent's blue rectangles. In Street Fighter, the deep dragon punch gives 200 points instead of 100 points (who cares about points?) and it also does more damage (which feels great!).
Can TGB tell whether a collision is "deep" or just "glancing?"
Maybe TGB can easily do all this stuff, or maybe it can't easily do any of it. I honestly don't know, that's why I'm asking!
Thanks,
--David
David Sirlin
www.sirlin.net