I'm still sitting on this performance killing bug that prevents me from working on anything big. Might be a function of looped engines or something -- I have no idea. Sadly this all came up when the construct team started losing steam and it's gone unfixed for several months.

Not that I can blame a free effort, but I am slightly skeptical over the SAFETY of working on such a game in construct. Though honestly that is the only thing thats ever outright crippled me.

Well, my usual 'see new release and hope my game killing bug has been fixed on accident" routine as again ended with sadness. Still nice to see some activity though. Cool stuff, but I gotta go cry now.

I had an idea for construct 2 that sort of covers this. Multiple layered object. So you could do all your detectors on one object, or have, for example, armor that breaks off, or do fighting game style hitboxes. It'd be more flexible and obviously useful than just multiple collision masks.

What I do right now (as a practical, but annoying solution) is have an object. I copy the animation I want to add hitboxes to and paste it on this object. I think Go over the sprite with boxes and trim out what doesn't fit right. Then I set animation speed to 0, and give it the same animation name.

Then every frame it's position is set to that of the player, it's animation is set to that of the player and it's frame of animation is changed to that of the player.

Then you modify the original animation and do this ALL OVER AGAIN, but hey, what can you do?

You COULD store all attack data in a 3d array and then make a mini app for creating hitbox data. Then they're made each frame! But thats a lot of work! But thats also the 'pro' way to do anything fighting game related.

Only if you had a nice convenient place for us to put information! someplace on-site and official, but not difficult to change! Something where you wouldnt have to get involved! Something like a wiki! Such a shame we don't have one of those!

:3

Hahah, thanks. You are the man, lucid.

This doesn't work either. While it doesn't write to all positions at once, this time it won't write to any position outside 0.

Even if I hardcode in a slot number. I ever cut down everything to a single number array in an attempt to write to a particular index. It was a failure. This really seems like something is broken.

Hey lucid, the code I posted for you yesterday didn't work So I rigged the same situation in a cap as an example so hopefully you or someone can notice what I did wrong!

http://kayin.pyoko.org/saveexample.cap

This is sort of a proto example of a save file format for my next game. Save stores all info and then there are superarrays within save, such as general. General keeps track of a few number arrays like x and y position, game time and deaths. General would have an index between 1 and 4 for each saved game.so {"save", "general", 1, "x"} would give the x value in generals saved game 1 slot.

In this example, I keep save and general and only work with x.

1 saves, 2 restores. Q and W add and subtract from the save slot. Text on the right tells you what save slot it's on, text on the left gives the x value in general 0 through 3.

When you press to save, ALL VALUES get set to your position, which is clearly wrong. Lucid said my code looked fine when I gave him a screenshot of it, but clearly something is up!

Any help will be appreciated, I've tried a million different things and 999,000 of them crash S.

Heres my suggestion for a rewrite

* Defining fonts. The ability for Spritefont to use multiple sprite fonts and define them each seperately.

*Being able to spawn text locations, because trying to use multiple Spritefont objects seemed to not work too well. "spawn text at xy" (and associating some sort of variable with it so you could modify or remove it) would be very nice.

*Line breaks. Might already exist?

This really should be a feature (even if its not till 2.0 comes around). I mean, with how pngs work, the functionality is sort of a natural possibility. Constructs current implementation might not set it's self up well for thast though, so oh well. Still I would absolutely love to be able to load up different color tables at any time, even if it were just for special effects or as an easier way to update a sprite set.

I'd think this would be doable in a different way due to the fact all images are pngs. I'd really love being able to just be able to edit and load up different pal files for sprites. That would be hella super lovely.

Loki, I am filled with BILE on your behalf. I would love to publically slander this man for his transgressions.

FYi, HD Remix has bigger sprites then Blazblue. HDR meant for 1080p. Blazblue runs at 720p and scales the sprites. That said, Blazblue's giant sprites at least don't look like ass, so who cares.

I've actually worked on a fighting game engine for a side scroll platformer so I have some experience here. It all depends on how complex you want things to be, but if you're doing a true 3D fighter, the first thing I'd say is to work with arrays to store data. There is a lot of actual databits for each individual move. I wouldn't even use the construct built in animation system (it's keyed for time delta and you need moves to be super consistent, animation wise). Anyways.

So you'd need a ton of enteries per move. Just for a normal you'd need the command, the damage done, the hit stun caused, the block stun caused, the recovery time for an anti air hit, the velocity changes for the opponent for an AA hit (probably two variables if not more for time/velocity), jump cancalability, gatlingability, proration, special traits, hitboxes(both attacking and vulnerability based) and animation. You can do hit boxes several ways. One is just the basic animation overlay (good enough for me), where you have two objects that animate in sync with the player. But if you want to get awesome, you can define hitbox points in an array relative to the center of the player and then use string functions to split them out and form various boxes. Of course this makes it a pain to properly align hitboxes. If I were doing a serious fighting game, I would probably make an editor to handle all this and then compile the information as data. Granted, this is involving.

You can do the same with animation. Frame name, wait time, frame name, wait time, blahblahblah.

A command reader is something I've had a hard time with. I have a solution that works sufficiently well, but for a serious fighting project, thats something you'd have to work on. Maybe we can convince one of the better programmers to tackle this. I'd like to see a system implementation that allows for various input rules and nuances found in other fighting games.

As for how to program events and stuff, I don't think thats too hard.

Check Commands

Advance Movement

Render hitboxes

Check for collision

Set Final animations and positions

Resolve frame

I have a pretty basic gatling system already worked out for my game that could be possibly shared, but I think it needs a lot of improvment. I think the important thing for anything like this it to work things out on paper first! An engine as complex as a fighting game engine needs to have a defined structure, or else you are going to waste a LOT of work.