Last week, we reported that Square Enix wants to bring Final Fantasy VII to smartphones. Today, we’ve got an explanation for why that hasn’t happened yet: the game is too big, Square says.
“Unfortunately, it’s not that it’s not impossible for us to develop Final Fantasy VII for mobile,” Square Enix top man Takashi Tokita told the gaming website ShackNews. “It’s that currently, space will be an issue. Phones won’t be able to contain the space it takes. It’s over a gigabyte. People are probably going to have to wait a few years.”
Wait, what? I mean, yes, he’s right: On the PlayStation Network, the Final Fantasy VII download is 1352MB. But bigger games have made it to smart-phones without a problem: XCOM: Enemy Unknown, for example, is 1.88GB. Infinity Blade III? 1.49GB.
Hell, even some of Square Enix’s games are getting up there: Chaos Rings II is 823MB and Deus Ex: The Fall is 808 megabytes. So, uh, what’s with this excuse?
Comments
12 responses to “Final Fantasy VII Isn’t On Phones Yet Because It’s… Too Big?”
They clearly don’t have much interest in revisiting or porting FFVII. A shame the fans can’t move on from on of the most overrated games of all time.
Maybe Square is aware of the shitfit that some fans will have over making FFVII HD Remake instead of a crappy mobile port. So they simply say its too big.
Word of the day: Shitfit 😀
That is an interesting argument considering that consumer HDDs around the time the PC release for FF7 came out (1998) was no more than 20GBs. Of course, I do remember the mountain of CDs (I’m exaggerating of course but you know what I mean) that this game came with. Even so phones these days easily come with 32GBs or more. I think there is no excuse.
The game assets alone is 1.4GB. How big the rest of the game is depends on how big the supporting libraries needed to run the game are. The Steam version of FF7 is 1.5GB, for example, but it makes use of DirectX and the Windows API already on your system. The PSN version is similar, it uses the libraries built in to PS hardware.
Mobile operating systems generally only have very low level rendering APIs, so the developer has to supply their library of choice alongside their game. That means mobile ports of games (particularly 3D games) tend to be larger than their PC counterparts, often significantly so.
It seems perfectly reasonable to me that they’ve done the maths, and with the weight of the libraries they’d need to run the game on mobile, it would exceed the 2GB limit Apple puts on app sizes. They could release it exclusively on Android (which has a 4GB limit) but I suspect then Apple users would complain.
(edited to change ‘game data’ to ‘game assets’ for clarity in the first sentence)
I don’t think it is so much a case of “Apple users would complain” as it is a case of revenue. If Square thought they could make their money back on Android alone it would be a done deal.
I doubt the port would be particularly expensive, they’d make their money back whether it was released only on Android, only on iOS, or both. All the art, music and scripting assets are already done, it just needs code work.
Just for comparison sake, I looked up the sales stats. It’s hard to find stats for Apple’s store as they don’t show them publicly, but third party figures appear to show the following:
– Final Fantasy 1 and 2 sold more on iOS than Android.
– Final Fantasy 3 sold more on Android than iOS.
– Final Fantasy 4 and 5 sold evenly on both platforms.
Android, iOS and Blackberry use OpenGL ES as their 3D rendering API. This is the same API the PS3, Vita and 3DS (and probably others).
It is at roughly the same level as DirectX, so it isn’t clear that a mobile app would need to provide substantially more engine code than a desktop or console game.
OpenGL isn’t at the same level as DirectX, it’s
lowerhigher. I couldn’t list all the differences but a few that come to mind are that OpenGL doesn’t virtualise the graphics hardware so it requires a degree of app awareness of different hardware capabilities. In my personal experience, I find it to be much more complex codewise to produce the same output as modern DirectX platforms (9 is decent, but 10 and onwards are much improved).OpenGL ES is a cut down version of OpenGL and it’s missing some pretty useful features compared to the full version. GLSL processing is particularly inefficient, so much so that the PS3 ditched it in favour of an alternative solution. They’re supposed to be improving that in ES 3, but I don’t think that’s supported in any devices yet.
Probably the biggest point is that OpenGL doesn’t cover anywhere near the same scope as DirectX does. OpenGL is comparable to Direct3D, but the DirectX API (and the Windows API) are much larger, facilitating physics, networking, audio processing and other game pipeline tools that OpenGL doesn’t provide. Those need to be supplied by external libraries.
You’re right though that they could use OpenGL and cut out some of the library cruft, I admit it completely slipped my mind when I made my earlier post. But writing a full-featured game in OpenGL is still likely going to require additional libraries to be provided, and depending on what they are, the size can add up.
In my previous post, I was mainly comparing OpenGL with Direct3D, since those are the two APIs that are analogous. I realise that there are other related APIs that make up DirectX, but I disagree that there aren’t equivalents on mobile platforms. Phones seem to do a pretty good job of making sounds and connecting to networks.
What exactly do you mean by “OpenGL doesn’t virtualise the graphics hardware”? It provides a common API implemented by pretty much every graphic core manufacturer in the market. It is possible for vendors to provide extensions, but that will only affect the portability of your code if you use them. And the extension mechanism has worked fairly well as a way of testing out new features before standardising them.
And yes, OpenGL ES is a cut down version of OpenGL, but most of the removed features are related to the old fixed function pipeline that doesn’t really reflect the programmable nature of the modern GPUs. It might have started out as an API for limited capability devices, but today is more like “OpenGL without the legacy baggage”.
You are right that OpenGL ES 3.0 is not wide spread yet, but it is available in the flagship phones from Apple, Samsung, HTC and LG, and in Google’s current Nexus devices. It’s only going to grow from here.
I see I wrote that OpenGL is lower level in my earlier post, but I actually meant higher level there, meaning ‘further from the hardware’. I haven’t worked with either rendering API for years so apologies if the answer is a bit rusty.
DirectX is focused on fully virtualised hardware, The virtualisation provides a common interface to the hardware while still allowing it to be accessed at a low level, and the developer manages resources themselves. That access gives the developer a lot of flexibility and freedom to optimise the rendering pipeline to suit their needs. To compare with programming languages, DirectX is like C++. It’s powerful, simple by default but with the tools needed to burrow deep when needed.
OpenGL is more like Java. The API is completely detached from the hardware, such that it can run purely in software if you want, as long as you have an implementation for it. OpenGL doesn’t give access to the hardware at all, all the hardware management is done by the implementation, which is usually part of the graphics drivers. For the language analogy, the implementation is something like the JVM in Java: each vendor has a different implementation with different performance profiles, different quirks and sometimes different outright capabilities. The developer needs to query the implementation about its capabilities and avoid things that aren’t implemented, because the fallback is less graceful than with DirectX.
If you’re a programmer, the C++/Java analogy should be immediately understandable. Java provides a generally nice abstraction that can unfortunately be overcomplicated in areas, and walls off the implementation (the JVM) so it’s harder to fix performance problems or build for high efficiency. You’re at the mercy of the implementation, warts and all. Similarly, OpenGL is more about the API than what exists beneath it, the implementation is walled off and it’s similarly difficult to tweak for performance.
On the other hand, C++ (and DirectX) provides everything the developer needs. You can stay in the upper levels, working through the API interfaces (in my opinion, the DirectX interfaces are much simpler and better designed than the OpenGL interfaces), and when you need to you can dig deeper to tweak the implementation as you like.
So hopefully that was all consistent and understandable. The remark about virtualisation wasn’t integral to my point, it was more ‘one example of many’ where OpenGL operates at a different level to DirectX, often requiring more environment awareness in the application itself than the DirectX equivalent.
More to the point was your other comment on ‘making sounds’ and ‘connecting to networks’. What the OS provides in those areas is low level and basic. DirectSound provides a simple interface to the underlying hardware, simplifying various techniques that are used in every sufficiently advanced modern game – mixing, sample shifting, improved channel pooling, hardware acceleration where available, digital signal processing, 3D audio positioning, etc. As far as I know, there is no equivalent function in the Android API, and I’m not familiar with the iOS API to comment.
On PC, what used to be DirectPlay, which managed networking and other communication between processes, is now handled by third party libraries. Just as with DirectSound, Windows provides low level functionality, and libraries provide the more complex functionality needed by the software. These days that tends to come in the form of systems like Steam, Origin, UPlay, XBox Live (and the much-loathed Games for Windows Live) and so on. They’re all installed separately and in addition to the game itself on PC, while on mobile an equivalent library needs to be included in the distribution.
Returning to my original point, it all adds up. The size of what is needed to run a game is not limited to the size of the game folder. On PC you need to factor the size of DirectX, runtime libraries and in the case of multiplayer games, the platform library. The same applies to mobile, and the additional weight of supporting libraries is sometimes quite significant. It may well be enough to push FF7 past the 2GB Apple limit.
Lies. It’s because they haven’t figured out a way to monetise it yet with micro-transactions. My love/hate for Square is currently evenly balanced between the awesome Final Fantasy 14 team and the rest of the company.
Squeenix once again claiming a bullshit reason as to why FFVII won’t be re-released in a particular format….. what is new.
They seem to hate that game.
It’s going to be $100 anyway given their current behavioral problem with pricing,