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

This forum is currently in read-only mode.
From the Asset Store
Casino? money? who knows? but the target is the same!
  • what was expected was confirmed. new thread on subject can be anticipated on the bearings of appropriate contingency in accumulated interest arising.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)