26
\$\begingroup\$

I'm writing a custom engine for a game. I started this game well before I understood why I should use middleware, instead, and it's too far along to rewrite.

The vast majority of my data comes from external files, and I don't just refer to assets; I define all of my game objects through .JSON. But, alas, I am human; occasionally my data files are invalid, or I change the format but forget to update the file, or the loader itself is flat-out buggy.

If, for whatever reason, an attempt to load some form of asset in a custom engine fails, what options do I have?

This is not a duplicate of How should I handle missing resources?, as that question is about user-facing assets like models or textures. Bad textures can be replaced with a checkerboard, bad sounds with silence, and bad text with "ERROR". My problem lies with data that's critical to the game even running, such as levels, game object definitions, and GUI layouts.

\$\endgroup\$
3
  • 7
    \$\begingroup\$ I use a similar approach for my game. I actually built a small utility app to generate my game data files to avoid human-error - this way I can just modify the files if I want to make changes wothout having to write 100,000 lines of JSON manually. \$\endgroup\$
    – Jax
    Apr 25, 2016 at 14:37
  • \$\begingroup\$ You could also run your data through a validator before loading it up. \$\endgroup\$
    – Jax
    Apr 25, 2016 at 14:44
  • \$\begingroup\$ My JSON is small enough that automatically generating it would be useless. Also, a validator won't help if the JSON is missing, or there's a bug in the thing that's supposed to read it. Thanks for the thought, though. \$\endgroup\$
    – JesseTG
    Apr 25, 2016 at 15:13

3 Answers 3

43
\$\begingroup\$

Log an error and gracefully exit.

Ideally, display a human readable error on screen as well. There should be a core pipeline of hard coded functionality that operates without these data files. It's the same pipeline that loads the data files in the first place. It should be capable of detecting when these core data files are corrupt or otherwise faulty and end the application. If users are intended to modify these files, there isn't much else that can be done. Otherwise, you need to implement a testing strategy to ensure these kind of corruptions don't happen. Then you can ensure you're only releasing valid data files.

\$\endgroup\$
12
\$\begingroup\$

Byte56 mentioned one option. There is at least one other:

Assume default values and display a Warning.

Depending on the nature of your data, it might be perfectly acceptable to assume some default values and warn the user that "since file xxx failed to load, we are using a generic yyy object."

\$\endgroup\$
6
\$\begingroup\$

It depends on whether this happens during development or release.

During development, you will have all kinds missing things, errors, and mess-ups, constantly, all the time, and you may even want to "hot" load assets on demand or replace an asset while the game is running. You might edit scripts with the game running to test an AI performs better, or anything the like.

It is most annoying if the program shows an error dialog and exits every time, and you must restart it which takes 2-3 minutes. The goal in development is to stall you (whose time is the most precious asset) as little as possible.
So, if for example, a texture is missing, you would want to see something like a red-white checkerboard, maybe with the word "missing" spelled on top of it as a replacement texture, so it is immediately obvious that something is odd. But you do not want the game to exit gracefully, nor even crash. Detailled information about what is missing in your logfile is immensely helpful.

On the other hand, in a release, the complete set of asset files should ideally[1] have gone through your automated asset pipeline. This needs to be not much more than a simple parser that reads in all your JSONs and then cross-checks that every module is consistent in itself, and verifies that every asset that you reference is actually there, and then zips the whole bunch of files up in some known (but not necessarily standard) way that is easy for your engine to read, optionally adding a few checksums.

You know that there can be no failure because your pipeline checked that everything was there before you released the package to the end user. So if a failure happens, either there has been a transmission error, or more likely the user is trying to cheat. In either case, the program should display a message saying that asset files are damaged, and exit.

Alternatively, you might offer the option to download a pristine copy of the assets from the internet (if you have a download server). But in order to avoid a customer support nightmare, be sure to ask prior to downloading gigabytes of data.


[1]Reality may look different, you may even find missing assets on AAA titles whose makers "should know", but they usually have unrealistic deadlines and large, changing teams, too. Ideally everything you ship has gone through the automated pipeline and is guaranteed to be complete.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .