/agdg/ - Amateur Game Development General

Fighting games have a really big professional community, there should be tons of articles, hitbox viewers and stuff.

It's really a matter of messing with numbers and trial and error. play a lot of fighting games as well. Get good at them, too.

>>Making the actual fighting game engine yourself

You do realize there's a shit load of game engines out there for fighting games right?

Just base your game off of an existing engine. Don't re-invent the wheel that's already been re-invented so many many times.

>>22968

>shit load of engines

Mugen is garbage.

2D fighter maker is now a legacy software.

ED-12 (3D mugen) is for 3D shit.

That unity fighter engine is not for 2D.

So far there's no a single fighter engine that has all what I want (sprites + 3D backgrounds).

Also it would be easier to implement some shitty online.

>>22926

What libraries / frameworks are you using at the moment?

>>22979

libgdx

nothing that I've done is super hard to make tbh.

I have around 2 weeks of work here.

>>22968

MUGEN is proprietary non-commercial abandonware garbage, and that's pretty much about the extent of 2D fighting engines.

If you are suggesting using something like Unreal or Unity then fuck you. I know /agdg/ loves to spout the "UNITY IS THE BEST ENGINE EVER" bullshit around here whenever someone mentions doing some non-trivial programming job, but fighters are one of the easiest genres to produce engine-wise and libgdx offers all the tools you need to implement it. Using Unity wouldn't make it any easier, maybe quite the contrary since you would have to re-learn what libgdx can already do again in another language just to get absolutely no benefits.

>>23012

>>22989

>libgdx

What are you going to do performance wise when the JVM stops your game to collect garbage and reclaim memory?

>>23013

what the hell is going on in your fighting game that you're constantly allocating new memory

>>23029

I warned you about fireballs bro!!!!!

I told you dog!

>>23047

If you were at all a reasonable man, you would instantiate all the necessary objects at game loading.

Which would mean your 5 or so fireballs that could ever be in effect at a given frame

There's a reason loading is a fucking thing, it's specifically so you aren't pulling things in and out of memory when performance actually matters (which for games, would be while playing the game)

It's not just a timer you're being forced to sit through

and you'd be doing this is any language, with automated garbage collection or not, because it'd be fucking stupid not to. What the hell is your plan with C++? Destroying everything when you're making a jump? When you get hit? A random entity is picked for destruction every time you move left? When the hell are you going to blow cycles wiping things from memory?

Obviously when it doesn't fucking matter, building at game load and destroying at game end, and just recycling ephemeral entities during the match

>>22926

I think it mostly comes out of the aesthetics of the act. A forceful blow denoted by a pause before and after, the impact sending its target reeling some small distance, a slight skidding at he hits the ground

maybe slight rotation as his body contorts

its the motions of the body that really tell the story; I don't think there's much engine-side to be done

>>23056

Not to derail this shit any further. But generally under C++ making a game and engine you're going to use a custom memory allocator, so allocating in the middle of gameplay isn't as bad as without it.

>>23130

>a slight skidding at he hits the ground

This. It's all about the art in a 2D fighter. The art is what gives things weight etc. Look at Street Fighter, everyone weighs like 2 pounds.

Then look at Samurai Showdown. They have more weigh in the animation.

>>23138

Oh, Java is pretty fucking fast for allocations. The problem with Java is the garbage collector, but deallocating is also fairly slow in C++ so you just leave it for when you finish the match.

>>23138

I'm aware of that

my point in the last paragraph is that you're still blowing cycles deallocating memory

Even if it's custom-made faster, it's still costly, so now you have two options

find every hole where cycles are already being wasted (in between frames? during invul frames?) and fit your deallocations there with enough logic behind it to not overflow the time limit

OR

you do the smart and much simpler thing (architecture-wise), and don't have variable memory allocation while the game is running. Just load them, and recycle for the match.

With or without custom memory handling, trying to fit it within the game's execution rather than at load/end is just asking for trouble. Most likely involving lots of special-case logic.

When you have the freedom to do so, separate your concerns. It allows you to work in a much more abstracted and general manner.

When you don't, when time or space or both is absolutely critical or simply not being yet, then it's time to start thinking about merging your abstractions to cut out the impact of the glue holding it together.

Fighting games are not games that hit this wall memory-wise, and moving from nonvariable to variable memory during execution is likely not the route that best affects their memory usage (..it'll probably be in optimizing the background and character models that -must- be loaded at ~all~ times)