2d fighters n construct n stuff temp thread[removed]

New releases and general discussions.

Post » Fri Aug 14, 2009 6:55 am

what was expected was confirmed. new thread on subject can be anticipated on the bearings of appropriate contingency in accumulated interest arising.
B
2
S
2
G
4
Posts: 259
Reputation: 1,968

Post » Sat Aug 15, 2009 8:05 am

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.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426


Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 5 guests