Considering they have him as a consultant, why don’t they just use Mike Z’s Z Engine. Mike’s already shown that you can do more than just fighters on his engine and even demonstrated a build with platforms.
The issue is more that the framerate in Unity affects the inputs and something causing the game to not run 100% will cause input lag or straight out input drops, and while I’m not afraid of that on my computer, I’d hate to see that online and from other computers, as well as other issues in Unity that just make me want to never touch the engine ever. It could be an amazing game, but will always be directly hindered by Unity and I really couldn’t justify playing a game on the engine no matter how good it is. They’d be better off making the game on almost any other engine ever.
Mobile/Web is largely where Unity3D got it’s start. The engine however has been making major inroads in the PC space lately. Lots of crowdfunded games like Kentucky Route Zero, Obsidian’s Project Eternity, and InExile’s Wasteland 2 use it. From what I’ve seen first hand in the industry, a large amount of other console game studios are migrating to it as well. It helps that Sony and especially Nintendo, have been playing a large part in pushing Unity.
What makes Unity3D so attractive is a combination of it’s licencing terms and how the engine is structured. Everything is logically ordered, well planned out, and nicely integrated for both artists and programmers.
That certainly is true, however if it’s any consolation, we are not the only fighting game on this forum to use it. What engine is used means far less than what the programmers can do with it.
Sounds like you’ve had a bad experience with a Unity game that probably was poorly optimized, and/or had other response issues. Also very important to note, if your point of reference here is mobile games, that would explain a ton. Optimizing for mobile is a job in itself and something not overtly obvious from the start. Lots of Unity ipad/iphone/andriod games suffer from it as a result, some even as bad as locking up occasionally for a for a fraction of a second.
It was several bad experiences and I have a hard time believing they were all poorly optimized. You have Mike Z as a consultant, ask him what he thinks of Unity.
I think what John is talking about us less about the optimization and more about the fact that inputs are tied to the framerate unlike what I believe is the norm with other engines. You can optimize all you want, but in a PC environment, someone somewhere is bound to find something that can slow it down and cause input delay.
Also, doesn’t GGPO style rollback netcode work better when the inputs aren’t tied to the framerate?
Technically, inputs are tied to the framerate in the emulated games on GGPO too of course.
Anyway, it’d be cool to see some more smash-like fighters. But the artwork isn’t my cup of tea. But it’s whatever, if a game is fun to play I’ll easily overlook it looking stupid. And well the quality of the artwork is good.
Spent some time researching this. Keep in mind, I am an artist, and outside of writting shaders, not programmer on the project. It appears that yes, Unity3d does indeed capture inputs with respect to the framerate. I imagine most dedicated fighting game engines handle this differently due to the muscle memory precision requirements for move execution. For other games types however, it does make sense sense for the two to be tied together and not run independently. I would imagine this is not an issue specific to Unity (yeah). Certainly understand the concern, but it’s hard to say what the impact will be on a slower machines until I test it. I do have one lead I plan to follow on this subject.
Even Ocarina of Time on N64 makes sure to seperate the framerate and inputs. The game renders the video at 30 FPS and accepts inputs at 60 FPS so you get buttery smooth controls all the time even if the game can’t keep up. If nothing else, your game should have smooth consistent inputs, and if your inputs are tied to the framerate, I don’t believe you can have that. It might work well enough to demo gameplay, but what happens if the framerate dips from 60 to 59 and you just so happen to press an input on that frame? You could potentially have the MK random input drop bug on your hands.
There are plenty of games where this wouldn’t matter. An RPG, a puzzle game, visual novel, any of these and I wouldn’t give half a damn. But something with the speed and execution of a Smash/Melee type game? I can’t agree to that, bro.
Back after a quick test. Cranked up the quality settings to the point where I was getting 12fps. Tested how many times Unity could register a button press in a small period of time. Update is the known, fighting game problematic framerate dependent loop. InvokeRepeat is an alternative method in the engine I decided to test it against. Here are my results:
Again, I am not a programmer by trade, but it does appear to be possible in Unity to gather inputs independent of the display framerate. Thanks for pointing out this concern and to everyone else sorry for all the technical talk.
Don’t apologize. Technical talk is pretty interesting in and of itself (then again, I’m a Computer Engineering student). Plus it gives us something to discuss when gameplay systems aren’t even close to finalized.
Makes me happy to hear that, especially when I have no short supply of my own technical responsibilities to talk about and demonstrate. More on that in one of the future stream sessions I have been trying to do while I work.