This book is a work in progress, comments are welcome to: johno(at)johno(dot)se
Back to index...Here is a PDF version of some of this material which I made for a lecture.
Write about how data driven architectures can go wrong when object existence is tightly coupled to data existence and / or validity. Creation patterns (static Class* Class::create(datasource)).
Talk about sources of data, and how the existence of data structures don't NEED to to be bound to any specific datasource.
One interesting aspect of when a game isn't dependent on any given data (i.e. default values) coupled with auto-persistence is that you can tackle problems more incrementally.
For example world UV-mapping in Z-Fighter, required brainpower in order to figure out what UVs to use for each bitflag combination. Rather than sit down and work it all out on paper and then code it, implemented a simple in-app editor that let me amortize the cost of figuring this out over several application executions. When I was playtesting and saw a glitch, I would simply switch to the editor and fix that specific instance of the problem. Automatic persistence solved this for me, along with the editor, and there was no need to actually look directly at the bit patterns. Actually using the data for its intended run-time was very close to the editing, so there was minimal code. Also, IMGUI saved the day.
When creating a game, the need for editing data is everywhere.
Tradeoffs between runtime-optimization of data (i.e. in memory) and accesibility and editing. Text files are popular. SQL-databases.
Note that the big issue is often how to edit the data. Text editors are readily available and work well. Note that this often binds editing to how the data is persisted. To use regular text editors, you need to persist as text files with some arbitrary format/syntax.
When in comes to tools, talk about the importance (in this case, as opposed to the previous discussion of run time datastructures) of thinking about where the data is authored.
In the case of images, Photoshop, etc are good tools, and artists are trained to use them. Therefore, image file formats come into play, and the application needs to read them. Therefore, images/textures are candidates for being "traditional" data sources (i.e. application loads them from file).
Same thing goes for 3d models, and there are good tools available. Also for audio waveforms (.wav, .mp3, .ogg).
The main point is that when there are compelling third-party tools for creating assets / data, use them.
However, in most projects, there is also a huge amount of application specific data, ranging from configuration data of various sorts, gui systems, level data, etc. I argue that in all cases where the data comes from / is authored in some application specific way, editor functionality for these data should be built into the application. This includes data that comes from level editors, Juice, guis, units in an rts, etc, etc.
The main gain of this is iteration speed (the edit-play cycle).
Talk about a clear dilineation about what is called what:
Assets = data that comes from external files, at load time transformed into runtime data, part of View.
EVERYTHING else can use standardized persistence, i.e. core::Persistent.
Talk about the design of core::Persistent:
Talk about the design of core::persist::IContext, various tradeoffs with the various implementations