How about moving to UNREAL 4.X?

  • Thread starter Thread starter Ragna
  • Start date Start date
Status
Not open for further replies.
R

Ragna

Guest
What the title says. Now that it is completely free for non commercial creations...
Would it be too difficult to recreate the PSOne era FF engines on it? Is it worth the trouble?

I think such an advanced yet seemingly simple to use and well supported tool would benefit the advancement in Q-Gears.
 
What does Unreal 4 have to offer that the current engine doesn't that would actually be useful to Q-Gears? When you're cloning software from the '90s, using too advanced an engine would merely serve to raise system requirements with no real gain.
 
Well, it all depends on how you want it to be recreated, either 100% equal to the original -including data format limitations- or
adapting it to newer standards, surpass limitations, and make use of toolset and data integration. You'd want runtime game editing too probably.  :wink:
I think another benefit would reside in the great community around UNREAL, which could help too in submitting work to Q-Gears.  :roll:

I'm no expert on this matter yet I can clearly see some benefits.
Anyway it may depend too on the expertise of the development team, or the willingness to throw away some or much of the infrastructure already built to support Q-Gears if any.  :?
Now that I think about it, this all is applicable to UNITY too...  :-\
 
Unity 4 has infinitely better documentation and better support for a lot of standard game development stuff... reliable interoperability between a modeling/animating/texturing suites. Qgears is built around ogre3d which isn't technically a game engine, it is a renderer with some extras. Everything else is either coded or handled by another project, such as luabind. Switching over to unity would be a lot of work at this point, not to mention, ffvii wouldn't take advantage of a lot of unity's features
 
Help make QGears work at all, then feel free to port to UE :)

Right now we need people that know the FF7 formats etc. I have an issue with model sizes/rotations, no engine will solve this problem.

https://github.com/q-gears/q-gears/issues/115

Rendering g-shaded triangles really doesn't need UE.
 
Thanks, its now a problem of rotation :)
Click to expand...
The FF7 models always had some crazy rotation scheme I think the wiki has some details on it not positive. The issue is with the bone order I believe you MUST follow it in order to get the model right. Animations consist of delta compressed data (spiro cracked that). Anyhow I believe one of the first animations is actually just the rotation to pose the character normally based on the bone lengths. The issue with the bone lengths has something to do with the direction of rotation. I believe both the models in battle and field are about the same in how they work.
Did Akari have some of the animations working with the cloud field model?

Cyb
 
I already suggested using some game engine. And despite current issues in q-gears, the advantage would be to have the "engine" part done for free, eg interface, scripting, sound, controls, settings, etc.
For the original intent of having a drop in replacement you'd need source code to make loading of native data possible.
To get a real impression of the benefits of an engine you should face all implemented features and there quality of q-gears with the engine of choice and see what benefits and drawbacks there are.

As for Unreal 4 I See:
 + sound
 + editors (live preview, visual scripting, ...)
 + networking
 + interfaces
 + input controls (Keyboard, Gamepad, Oculus?, ...)
 + settings screens (not sure what is required to get them though, ogre has only the minimal rendering settings window)
 + platforms (win, mac, *nix, android, html5)
 + possible future updates / bugfixes
 + proven architecture & maybe good quality code at least I'd assume it to be

 - porting efforts
 - learning efforts
 - native format support may not be possible
 
QGears using Unreal is not going to happen....

Doesn’t combine the Unreal Engine code with “Copyleft” open source licenses. See the FAQ for more details.
Click to expand...
not usable with ANY of the Qgears code as its all under the GPL a  "Copyleft" license.
 
QGears using Unreal is not going to happen....

not usable with ANY of the Qgears code as its all under the GPL a  "Copyleft" license.
Click to expand...
That's for commercial purposes only.
And it would not matter if you port Q-Gears to UE4 since it wouldn't be the same code anymore with the same dependencies anymore, probably.

I already suggested using some game engine. And despite current issues in q-gears, the advantage would be to have the "engine" part done for free, eg interface, scripting, sound, controls, settings, etc.
For the original intent of having a drop in replacement you'd need source code to make loading of native data possible.
To get a real impression of the benefits of an engine you should face all implemented features and there quality of q-gears with the engine of choice and see what benefits and drawbacks there are.

As for Unreal 4 I See:
 + sound
 + editors (live preview, visual scripting, ...)
 + networking
 + interfaces
 + input controls (Keyboard, Gamepad, Oculus?, ...)
 + settings screens (not sure what is required to get them though, ogre has only the minimal rendering settings window)
 + platforms (win, mac, *nix, android, html5)
 + possible future updates / bugfixes
 + proven architecture & maybe good quality code at least I'd assume it to be

 - porting efforts
 - learning efforts
 - native format support may not be possible
Click to expand...
Not impossible at all.
You just need a data importer/exporter to reformat data at install time, like Q-Gears itself did: insert game disc and the game profile (for example FF7) installer will reformat all data and patch some of it after conversion, like field scripts, maybe.

That leaves it to the other two negative points. And as I said:
Anyway it may depend too on the expertise of the development team, or the willingness to throw away some or much of the infrastructure already built to support Q-Gears if any.  :?
Click to expand...
If that's the reason... well, it's up only to the project team. I'd say it is probably better to do it sooner than later.
But I agree: currently it seems most efforts should be made on reverse engineering. Maybe, using the current Q-Gears implementation as prototype, and then much later when more is discovered move to a better suited engine with more tools and features.

PS: If I had to choose the 5 most important benefits of using such engine...

  • Visual Editor:
    including the ability to test and edit at the same time.
  • Integration:
    with Visual Studio X, for example.
  • Multiplatform:
    more people can enjoy your work.
  • High quality architecture:
    and the ability to be extended or modified.
  • Support:
    by WhateverCompany Ltd. (like Epic), or the rest of the community.
Seems reasonable to you?

EDIT: I forgot to say it is free.
 
Last edited:
- native format support may not be possible
Click to expand...
As it happens, you CAN add native format support to Unreal 4, because they even make the engine's source available now.
+ editors (live preview, visual scripting, ...)
 + networking
 + input controls (Keyboard, Gamepad, Oculus?, ...)
Click to expand...
Networking support? Oculus Rift? Those aren't remotely relevant to this project. And visual scripting is not going to be very helpful since the engine will be running old scripts from 1998 anyway. Any new scripting at all is pretty much outside the scope of this project.

QGears using Unreal is not going to happen....

not usable with ANY of the Qgears code as its all under the GPL a  "Copyleft" license.
Click to expand...
This too. Not only would a switch to Unreal require literally the entire codebase to be rewritten from scratch for license compliance, it would require the new code to be licensed under something more likely to get it shut down. Normally I am adamantly against GPL, but the very things I dislike about it for most scenarios make it a great choice for something like this. Y'see, GPL makes it utterly useless commercially, a fact which Square Enix would have to be aware of. As such, they've got far less reason to shut it down than they would if it were licensed under any Unreal-compatible license, such as MIT. To switch to a license that allows for-profit sale would create a threat to Q-Gears' very existence.

That's for commercial purposes only.
Click to expand...
No. Unreal's EULA explicitly forbids distribution with "copyleft" licenses, any license that forcefully attaches itself to other parts of the same piece of software. This is not just for commercial use; any distribution of UE4-based projects with GPL components is a violation of both licenses at once.

Ultimately, even if licensing Q-Gears under MIT were an acceptable option, the amount of effort it would take to rewrite all of it would far exceed the benefits of the engine change. Honestly, aside from the license, if Q-Gears were just beginning I might almost be tempted to recommend it myself just for the portability and far more robust settings screen support. But at this point, the project is far enough in and deeply enough attached to Ogre3D that I really don't think it's worth the effort to port.
 
Last edited:
Getting the original data converted to 'workable' formats is still the primary challenge atm i.e. models and animations, field/battle/world scripts buried in the.exe(?) to LUA, backgrounds... this stuff needs reverse engineered before thinking about moving to a real engine methinks
 
As there source it not open it's understandable that they can't have you bundle it with any GPL code as that would require you to open the rest of the code as well which you are not allowed. But afaik GPL permits linking.

I initially committed my code under MIT and since I am the copyright holder of my code I can, at least with my parts, do as I please.  And one can always ask if the copyright holders would grant usage etc. But as already mentioned rewrite is needed anyway so that shouldn't be much of a problem.

Reversing is with current versions of IDA Pro easy as hell, at least for the pc data.

- native format support may not be possible
Click to expand...
I meant like in the original sense of a drop in replacement, so native format conversion on the fly, depending on the data structures that need to be filled it might just be hard, nothing is impossible :)

All in all I like the idea of learning Unreal :) but no matter the direction, time is of essence so don't count on me :/
Sharing code with current q-gears is unlikely in that approach though, sharing knowledge / reverse engineering  is more likely.
I can't quite imagine how collaboration works in case of U4 though.

Last but not least. It's you're time, enjoy, if that is with U4 great, if it is helping current q-gears fine, if you share knowledge nice :)
 
Spending 12 months (probably more) to get what we have now working in UE4 really is a waste of time IMO. No matter what we need the FF7 format info, algorithms etc. This is always the blocker, always step1, we don't even have this yet so what would be the point in moving to another engine?

Fields are driven by lua scripts that can be reloaded on the fly, a visual editor only brings a couple of extra bits for free such as positioning entities etc, but we can easily add that if need be.
 
There are two other things which why I think that the UE4 engine is a no go.
1. The engine is free for non-commercial use, but the game is commercial - which would make the project indirectly commercial. Except you re-built the entire game in the UE4 engine -> We have seen on the Chrono Trigger Project how this will end.
2. If there is no one who can make use of the extra power the engine brings with it, where would be the benefits?

A small visual upgrade and a graphical timeless look is all what we should seek for now .
 
The tools suggested would work against many of requirements of the game's content.
 
Last edited:
Status
Not open for further replies.
Back
Top