MFGG TKO DevLog - TSG Left

[MC Jimmy]

This looks really amazing. I'm assuming the gifs are actual ingame material coded. The engine looks really tight and cool.

[TheShyGuy]

Thanks, I appreciate the support. The gifs are actually made with this : http://www.cockos.com/licecap/


Edit:

Playing with premultiplied alpha blending + stencil buffer:
GIFS

Spoiler

(This kind of blending won't be in the game, I'm just messing around)


Edit2:

Done messing with blending. Additive blending supported:

GIFS

Spoiler

[Mit]

here's some other stuff-


a character select portrait! it's one out of about 10.


some concept art of one of the enemy types: the smiley. it's facial expression (and palette) determines it's actions.

[Mit]

woops double post but here are some more animations


beb


also, going fast

[TheShyGuy]

Devlog? 7? -Back in the Loop?-...(title)

I'm sorry for this just being a straight copy/paste. But this is just to get you guys back in the loop in some way. Kami and I are basically talking about the fighting system atm and I decided to write a story about where I am with it.

-from skype-

[6:02:59 PM] Kamtaku(Zachary Baumhoff): for that clash cancel thing, would projectiles get canceled if an attack hits them

[6:03:48 PM] TheShyGuy: thats what I'm asking. How in depth are we gonna make the attack/defending system

[6:04:24 PM] Kamtaku(Zachary Baumhoff): well personally this game has simplist combat in a way so I'd say not super in depth

[6:05:19 PM | Edited 6:05:26 PM] Kamtaku(Zachary Baumhoff): it's obviously not going to play like a streetfighter game orz

[6:05:54 PM | Edited 6:06:20 PM] TheShyGuy: perhaps there could be a flag that allows a hitbox to not be cancellable. Like for explosive missile projectiles, I'd expect the target to still get hit if they try to 'cancel' it out.

[6:06:49 PM] Kamtaku(Zachary Baumhoff): if it was an explosive missile though wouldn't it explode if it was canceled or not?

[6:08:38 PM | Edited 6:09:08 PM] TheShyGuy: yea it would explode on anykind of contact, but I meant that if we allowed all hitboxes to be cancellable with another, then the target could cancel out the incoming missile + the post explosion if they generate 2 hitboxes fast enough

[6:09:27 PM] Kamtaku(Zachary Baumhoff): ah
[6:09:29 PM] Kamtaku(Zachary Baumhoff): yeah
[6:09:57 PM] Kamtaku(Zachary Baumhoff): the explosion itself shouldn't be canceled unless a shield is used and even then it could probably only do half dmg or something

[6:11:27 PM] TheShyGuy: yeah thats pretty much coded for I think
[6:11:34 PM] TheShyGuy: -defensive collisions
[6:12:22 PM | Edited 6:12:30 PM] TheShyGuy: I just haven't really tested defensive collision bubbles yet though so I can't say its solid atm

[6:12:46 PM] Kamtaku(Zachary Baumhoff): something is better than nothing atm at least, it's not like we're in a rush
[6:15:32 PM] Kamtaku(Zachary Baumhoff): how're the core things coming along in general on that sidenote

[6:23:50 PM] TheShyGuy: I've been focused on the Brawler system for about a week or so. I'm gotta remove some dependencies from the "Moveset API" so that normal objects can take advantage of the system (since it really is just a state machine, but gives good control of scripting states on a per animation frame level + per game step). I already know how to do this, but it's just repetitive type of code that only requires time....and patience lol.

I gotta rethink the way "Actions" are designed. Atm, its just a glorified single function with quite a bit of conditionals/ifs (which sound so ugly, but its not that bad imo if you look at it....but I might just be used to it). I've got an idea of how I'm going to go about it. Oh yea, the point.. Actions and subactions can be thought of as "Action + Animation" (..from Smash bros). Actions control a state at a per game step level, while subactions control the state at a per animation frame level. This is why I've gotta separate Actions so that this can be done correctly (-I didn't think it was necessary back then, but for "special" attacks, it would most likely be needed)

[6:27:18 PM] TheShyGuy: The Brawler system used to be a single file that was going to handle everything about the fighting system. Recently, I split it up into separate files, one for binding collision bubbles correctly to the owner, one for applying physics correctly to the bubbles, and one for parsing and caching colliison pairs. The parser caches all collision pairs and waits till the end of the step to check and categorize all colliisions. Instead of also handling the resolution (applying damage, knockback, etc), I'm still thinking of how to delegate the output groups to an external system so that the Brawler collision system only cares about the input (collision bubbles) and outputs the pair groups (off vs off, off vs def, off vs hurtbox, etc).

[6:36:08 PM | Edited 6:36:27 PM] TheShyGuy: I was going to go in deep with the collision pair categorizing/filtering based on whether the opponent is grounded or not, the offencisve collision priority, etc but its nice to know I don't gotta go there.

I also still gotta think about hwo to do Catch/Throwing characters, but once I separate Actions, that should be easier since I can set the target's Action state directly with Catch collision bubbles (to something like "Grabbed"). Something like this along with the flinch and launched actions will probably be injected into brawlers because it'll never differ.
[6:37:36 PM] TheShyGuy: And I need a gfx for the shielding graphic bubble. Unless we're using the shield sprite, then I just gotta use it.
[6:39:58 PM] TheShyGuy: and thats all I'm aware of that I have to do for the Brawler system... Once thats done, I'll be pretty confident in working on the scripting part of the Character editor because the fighting system will be solid. Which means everyone can start making atleast character content..................


I'm done lol. Didn't mean to write a story. Might as well put this in the devlog so people are in the loop in some way.

[TheShyGuy]

Short devlog #8

Actions have been separated and redesigned. They're no longer 'just a single function'. They are just like subactions, except they run per game step instead of per animation frame. Actions and subactions run parallel to eachother sorta (I probably mentioned that already), which gives me the best control of both worlds.

The Moveset dependency thing is gone. Yeahp.

I did other things, but I gotta check my commits to see exactly what. It's been a while but I know I had to have done something else too hehe.

Gif in spoiler of wall jumping with new Action system thingy.
(Spoiler because I can see how annoying it is to wait for everything to load at once)
GIFS

Spoiler

It's nothing really interesting from your view I guess hehe. But, I dunno, it "just felt better". -Ofc, this is just me playing around and doesn't reflect Mit's moveset at all (besides the animations). None of these GIFS do.

[TheShyGuy]

Devlog #9

I've emboldened and titled paragraphs for easy skimming. Feel free to skip whatever you want ofc.

Over the past two months here are most of my commits for those interested. They don't go into detail.

Spoiler

2014-02-20

--additive blending supported
--ParticlePrototype
--C# ScriptHandler
-abstracted input handler out to an interface

2014-03-11

-Added Emitters:
-->Particle Emitter data + component
-->Sound Emitter data + component

2014-04-01

-Working on separating Actions so that a "state/move" = Action + Subaction
->Action + Animation
->Action updates per step
->Subaction/Animation updates per animation frame

2014-04-04

-ActionState class now supports 'And' and 'Or' type of requirement grouping.
-A newly set action will update the same step it was set.

2014-04-09

-Added Graphing Tool for use with making curves for Utility AI

2014-04-11

-Separated Actions work good so far, no obvious bugs
-MovesetDataInterface fully removed

4 days ago

-Subaction Manager loops subactions correctly now

__

Reason for Inactivity
The devlog wasn't active because, as you can see by the commit dates, I wasn't programming a whole lot. That and because it seems like only a few are interested in the devlog hehe. Despite that, I'm gonna try to keep this going.

Overall Info

I am currently working towards a new build for the team to see. I'm going to implement a few more things before I do so though, like articles(weapon props, like FLUDD for Mario or Bowser's Flame breath), hurt/flinch/launched hardcoded actions + bouncing off the level, defensive bubble shield, and the Brawling collision resolver thing (applies collision bubbles -> offensive,defensive, hurtboxes).

Articles

Articles are basically normal objects with "Moveset" data (Actions, Subactions + arbritrary data) but with a parent/child relationship between another object. The parent has access to all the properties of the article and vice versa right now. The parent can set Actions (change/force action) for the articles which is key. I'll try to show some GIF examples on this in a later devlog.

Attaching Articles

Articles sometimes have to be attached to the character. I just started working on this. The aim is for an article root bone to be binded to an arbitrary bone of the parent. This should be pretty easy and fast to do so expect to see an example soon.

Getting Hurt, Flinching, Launched

I've never coded any of the three above so at first I was unsure how to go about it. That's why it's taken so long to get to them. They're going to be hardcoded actions and subactions. We're aiming for a smash bros type of hurt response. More info on this later.

Collision Resolver

In order for me to work on correctly implement hut/flinch/launch states, I need a way of getting to that state. At first, offensive collision resolution was simple because the engine wasn't far enough in development. The only thing it did was tell the victim he was hit and the attacker that he hit something. I was going to leave all that code in the system and single class. However, that means, I have to also encode cases for when the target is even hittable, launchable (large bosses shouldn't be), and all collision pair cases (catch, throw, offensive->defensive, offensive->hurtbox). That didn't sound good to me at all. So, as it is right now, at the core, the brawler engine just handles adding, checking and parsing collisions (this might be delegated to a higher level, or just abstracted in a way that is less game specific but it's not required so w/e). It then delegates resolution to another system. The new system can be created at a higher level to be more game specific. Bosses will be added to a system that may just apply damage. Brawlers would be added to a system that applies damage, knockback and collision effects. Normal objects, like blocks that only need to respond to the fact that it got hit don't really need to be in a system. They can listen to that specific event through the necessary data.

Programming Misc

I try to keep things separated enough without much redundancy. Throughout this project, delegating things out for higher levels to figure out has seems to be powerful. At the lower level, some info is unknown and cannot be implicitly implied. At the higher levels, things are more known, arbitrarily implied and self-imposed so that shortcuts can be made. With that mindset, making the game has been relatively easier than anything I've done before. It's still hardwork, but there hasn't been a problem I couldn't figure out yet. That issue with passframing walking + shooting for mit is easily resolved through the use of articles. Mit can be split into a lower body walking animation and the upper body shooting animation. The upper body will be represented as an article which I can control. That simple and no need for passframing at all- which was a terrible misuse anyways.

Misc 2

It's taken me about 6 months to make this fighting engine. I don't think anything else will be as complicated and long-term. After implementing the above, I feel that the Fighting system will be solid and I can finally move on to other things. Hopefully, that means that more interesting stuff can be shown and done soon. I can start to work on actually game content and tools too. The only other thing I think would take a long time on the coding side is networking, which I've never done. But that's pretty much the last thing on the list so that game should be nearly done by the time I start working on that. If networking fails, then hehe I dunno.

TL;DR Read Overall Info to get a quick summary.

[TheShyGuy]

Devlog #End

Welp, I apologize, but I no longer want to continue programming for this game. I'm going to relax a bit, learn and most likely move onto Unity. Goodluck guys, and again, sorry for leaving.

[Kelvin]

If TheShyGuy isn't gonna program for this anymore, mind if I have a look at the code? Maybe I can help with it.

[TheShyGuy]

I didn't give them the source code. I have no problem giving it out though (I used to though). However, if Mit would give the OK, I'll post pm it...or I'll just give it to him to put it in the DB if he asks. Are you familiar with Xna + C# (+ Lua) ? It's not well commented, but I can comment it before handing it out as well as document things a bit. I also don't mind helping you out getting familiar with the code as I tried to stick to a consistent pattern when coding so it's easier to understand how and why things are set up the way they are.

[Kelvin]

I normally use C++ but I have a friend who's real good with C# who's helping me learn. It's really not hard, just a few differences to get used to.

[TheShyGuy]

Ok, then it's just up to Mit now. I told him already, I'm just waiting for a reply.

____

Ok, he's fine with it. I'll give it to you sometime during the week. I gotta clean things up and document the code for others/you. I might also add an alternative simpler animation system. The one that's used is overkill + the tool I made for it isn't all to friendly (it was meant for RidgeTroopa and Phaze initially). I may try to simplify the new system down to a normal frame-based animation system. Don't worry, I'll give you the original code first and maybe add in the alternative system afterwards if you want.

_____

Some concepts you might wanna get familiar with while I ready things.

-Matrices (concept wise)
-->Parent-Child relationships
-Entity-Component system (concept-wise)
---> The idea of representing the same object different ways (it will more sense when you see the code)
-Lua (it's easy to get the hang of)
-The way Actions/Subactions work (you can find out from skimming this thread.)

Uhh If I think of any more, I'll edit this or make a new post.

_______

If you have any questions, just ask.

[Kelvin]

i'm well familiar with matricies and parent/child, and the rest I can easily look up. Send me both versions; it'll be good for me to see both versions.