Should a game engine support "general" file formats at runtime?

Use a binary format that is most efficient for the engine loading/rendering. Different platforms may need different data anyway (endianness, more data for platforms that support more features, etc.).

Use offline tools to do a conversion.

Portable model formats are designed to be as flexible as possible (and stuff like 3ds files can have custom data for specific plugins etc. you probably aren't interested in).

The only use I can think of for supporting generic formats is if your level editor is packaged with your engine and you need to import models etc. for placement. These should still be saved out in your own format on export (or after an import).

I'd say that you should implement what you need. Say, Unreal Engine and CryEngine support many formats because they're pretty much designed to be the end-all of any developer, adapting to their development environment. You work with Maya? No problem. Work with 3D Max? No problem. And so on.

So if you need to support a format, you see somebody (you or someone else) using that format, support it. If you don't, and only use, say, 3D Max files, there is no need to make your life harder isn't it?

On the other side, say that you have your own shiny format but you work in Blender. Maybe supporting uploading .obj files directly will make your work easier and you can convert such assets to your format once you have finished working with them.

I tend to aggree that the retail build of your game should use custom formats, rather than common formats for assets. This applies more to heavy-weight, production-pipeline-oriented formats (like PSD, 3DS, or Collada), than to common interchange formats (like BMP or JPG) though. The production oriented formats are designed to carry all the info needed to modify the asset, track authorship, and sometimes even history and other metadata that's useless to your game. Even if you can and do strip that out within the confines of the format (as you might to with TIFF or possibly Collada), the format still bares a lot of overhead and cruft that's no longer necessary. Common interchange formats are less of a concern on this front, as they are typically pretty simple and lightweight, and are either already compressed, or compress well.

But there are other benefits to custom formats too. The first is that it deters the average user from modifying the assets (at least until more experienced and determined individuals produce tools to do so), and the second is that you can go from disk to first-use with minimum CPU intervention. I/O will always be the bottleneck for loading that big 3D mesh, but still, every CPU cycle you have to spend transforming its vertices into the coordinate system your engine uses are CPU cycles not spent doing other useful work. Why not have just baked the right coordinate system into the file to begin with. In some cases and on some platforms you might even be able to hand off asset loading to other hardware (say, DMA engines) and not have the CPU interrupted at all.

Use a custom binary format for speed when loading complex assets such as 3d models. This allows you to do pre-processing of the data (such as calculation of normals or flipping of texture coordinates) so that it is in the best possible format for your engine. If you make the conversion part of your build process it is very easy to manage.

There's no need to reimplement bitmap formats, since they are pretty quick, and you should ideally be using something like .dds (or equivalent) as it has hardware support.

As for generic data, I'd advise against XML since it can be slow to parse. I haven't used JSON myself, so I can't really comment on it, but it seems lighter weight than XML.

Its also important that you only optimise what is actually causing performance issues. As an example, In my current project I have lots of 1-2 kilobyte data files that are in custom text format containing name/value pairs. Loading and parsing them all takes less than a second, so there's no benefit to switching over to using a binary format for them.

I like having support for complex formats, at least for the first stages of development. It's MUCH easier to prototype with when you don't have to worry about producing a toolchain that may itself be buggy. Eventually that'll all be stripped out in favor of custom formats and DDS images. But that doesn't have to be your starting point.

generic formats can be more convenient to work with, but not necessarily ideal.

for example, JPEG and PNG are widely supported, and are compressed fairly well (it takes a bit of work to really do all that much better regarding compression size/quality tradeoffs), ...


more custom formats though can have the advantage of faster load-times or providing features more directly relevant to the use case, at the cost of the possible loss of file interchange (requiring special tools or application plugins to use them).

tradeoffs can then be made regarding decode time vs compression vs complexity vs disk-IO time.

for example, a highly compressed format which lumps multiple texture images together may be faster to decode than a simpler bulky format, since the CPU time to decode the data may still be less than the disk-IO time needed to read it.

this is "within reason" though, as not all tradeoffs have equal weight.


binary vs ASCII is a more complex issue, as not only is size and speed an issue, but potentially whether or not the data is human-readable or editable.

within a binary format, there may be many possible tradeoffs (TLV vs fixed-format vs a loosely-structured image, ... fixed vs variable-width numeric codings vs entropy coding and VLC, ...).

a lot also depends on how the data will be used, like if it will be primarily read sequentially (such as being parsed and decoded), or subject to being kept in memory and pieces of it being accessed randomly, ...

The short answer is "yes". The long answer follows.

I think the major aspect of this issue is in deciding whether you want to ship with generic resource support or use it exclusively for development. The answer to that lies in how you plan to support any games you make with this engine and whether or not you intend to make the engine available for others to use. The advice to use generic formats in development and custom formats in the shipping product is sound advice when given in terms of resource loading performance. However, I disagree on principle that it should be used as a means to prevent players from modifying the assets. I think that if a player wants to modify assets for their own use, that's a perfectly legitimate thing to do. I'm not saying that a developer should go out of their way to provide access to tools for reading/writing the custom formats if supporting modding is not a goal, just that asset protection should not be a motivator for using custom formats.

If it were me, I would add support for generic formats via third-party libraries (FreeImage, AssImp, etc) for my own use during development at a minimum. Then I would ship with custom formats in the application's directory tree. If I wanted to support modding, I would enable generic format support for reading from the user's app data directory, allowing them to override the loading of default resources, for example by using the same file name. If I didn't mind the support headache, I'd go a step further and either provide a tool to convert the custom resources to another format or offer some or all of the resources as a separate download in more generic formats. Finally, if I wanted to offer up the engine to other developers I would definitely support a variety of formats so that users aren't locked into a specific toolchain if they don't want to be.

Absolutely not, but also yes/maybe. No as in: the engine shouldn't parse COLLADA files. But yes/maybe as in: that doesn't mean the engine can't load COLLADA files at runtime.

IMHO, data processing should be moved out of the engine runtime and into the toolchain. This greatly simplifies the engine runtime, which keeps it flexible/maintainable.

If you want to support some extra file format, it's of no concern to the engine runtime; you just add that file loader into the data processing part of the code-base, which is completely decoupled from the engine runtime.

Forgive the ASCII art -- the architecture I use separates the developer's PC from the game via the data toolchain:

________________     _________________     _____________________________
| Developer's  | --> | Data compiler | --> | Abstract game file system |
| Windows file |                              ||
| system       |     _________________     ___\/___
|              | --> | Code compiler | --> | Game |

During development, there's no reason that the game can't talk to the data toolchain. When loading a file, the game can send a message to the data toolchain saying "I want to load the file 'blah'", and if that file is some JSON config file, then the data compiler can load it, parse it, compile it, and then send the resulting bytes on to the runtime.

Every game engine that I've used in the past 4 years has implemented it's "development file system" (the one that's used in non-shipping builds) over a TCP/IP connection to the data processing tools, which makes this kind of configuration pretty straightforward.

Absolutely not, but also yes/maybe. No as in: the engine shouldn't parse COLLADA files. But yes/maybe as in: that doesn't mean the engine can't load COLLADA files at runtime.

IMHO, data processing should be moved out of the engine runtime and into the toolchain. This greatly simplifies the engine runtime, which keeps it flexible/maintainable.

If you want to support some extra file format, it's of no concern to the engine runtime; you just add that file loader into the data processing part of the code-base, which is completely decoupled from the engine runtime.

I think it more depends on whether there is a direct practical consequence of supporting or not supporting a given file format.

so, the question isn't so much about whether or not a person can or should be able to load COLLADA, but more what might be the tradeoffs made based on whether or not they decide to support COLLADA, or if they do, whether it is a good idea to load it at runtime, ...

for example, requiring an external library dependency, or being too much of a hassle to implement, would make a case for not supporting it;
whereas, it performing too badly to be worthwhile loading it, more makes a case for not using it (but whether or not the engine can load it, is not nearly so relevant: if it isn't used, it may not cost much either).



I guess it also depends some on how a person sees the role of their engine as well.

for example, a person who sees an engine more as a means of distributing self-contained finished games directly to end-users, may well see the role of their engine differently than someone who sees it more sort of like, say, the offspring of something like Quake and FireFox (say, pulling down contents from player-run online servers via URLs and with large chunks of the server-side game-logic written in a language like JavaScript, ...), and in turn, what choices would be more preferable regarding engine architecture and behavior.

in the latter case, how hard it is for end-users to run and administer servers, put up contents, ... may be a bit more of a concern.

but, for other kinds of uses, this may not make sense.
for example, you probably wouldn't want to do a big single-player RPG this way, ...

likewise, for something like an MMO, it may make sense for much more of the processing to be on the client end, mostly as running all the logic on the servers could require a lot more costs due to needing a larger number of beefier servers (granted, the server "could" probably just hand the clients a big glob of bytecode or similar for it to play with, and maybe add in some "tamper protection" features, or mechanisms to hinder client-side modding, ...).

Firstly, Hodgman is exactly correct.

Your examples are only related to 3D file formats, and for that the answer is a very clear and resounding ”NO”.

.ma, .3ds, .dae, .fbx, whatever. Those file formats were not made for the purpose of loading into a game engine. A format that gets loaded into an engine is a format that was made to be so. Since every game engine is different, every 3D format for every game engine is different. In other words you have to roll your own. No choice in this respect.


If we are talking about image formats, it depends on your goal.
Our company does not (yet) license out its engine so we can just say, “To use images in our engine, it has to be converted to our own format.”
But if your goal is to make a commercial game engine, it should be able to load all kinds of formats while at the same time having its own format which is designed for fastest loading.
The philosophy is that while the engine supports loading of .BMP as a convenience, all images should be converted to the custom format for best performance.


L. Spiro

A resounding no here as well.

The effort you put into supporting all the other non-game ready formats (be it textures or mesh data) could be directly sunk into a command line tool to convert the source data from the start.

You'll be doing no more 'real work' - infact you'll do less as you won't have to remove it later from the runtime.
You won't get tempted to leave it in 'for now' - because we all know it doesn't work that way in reality
You'll speed up your start up times - data is built rarely, but if you are transcoding on every start up your start up times can/will suffer, certainly in debug mode if you are doing any heavy lifting with containers etc and memory allocations.
You'll simplify your engine code - with 'one way' to get data in you won't have to deal with debugging multiple paths.

This isn't to say you can't have code at runtime to construct small assets, in our new renderer most of our 'test demos' use internally generated vertex data and texture data in lieu of disk based assets. Even the resource system testing demos do that (although they present the data as if it came from disk).

But everything is treated as if it is a 'game ready' format once it hits the engine.