Games Development 2 Text-based Game Data CO3301 Week 4

Contents Identifying “Hard-Coding” Types of Game Data Simple Example: INI files XML Overview XML for Games XML APIs Editing Tools

Hard-Coded Data Hard-coding describes the embedding of data in program code Seen early on in relation to program constants: char Name[256]; for (int c = 0; c < 256; c++) { … } The name length (256) is hard-coded – poor practice Solution: define a constant NAME_LENGTH Or: switch to a more flexible string representation Is the line below hard-coded? CMesh* tree = LoadMesh( “Tree1.x” );

Problems with Hard-Coding This is hard-coded CMesh* tree = LoadMesh( “Tree1.x” ); If we decide to use “tree2.x”, we need to change the code: Recompilation, can be slow for a large project Need to know where each LoadMesh call is to make changes Can’t be done at run-time (trying out different trees) How to improve on this - use data files

More Examples Hard-coding comes in other forms: This seems flexible: MessageBox( “Enter your name:” ); What if the application is released in another language? Or several… Effective localisation requires that no text strings are hard-coded. All should come from data files This seems flexible: bool enableWiggle = true; if (enableWiggle) { // Wiggle code } Programmer can toggle wiggle, but no-one else can If attached to UI, then OK. Otherwise enableWiggle should be a setting in a data file

What Can Be Stored as Data? Game data files can contain: Graphic settings (video card, res, AA, etc.) Game settings (difficulty, control setup, etc.) In-game level set-up: Entity templates needed per level Will drive resources to load (see last week) As well as provide some starting entity stats Level layout – entity positions Other required resources Localised text Hi-scores, network settings, menu layout…...

Text-based Data One positive point about hard-coded data is that it is stored in a text format (e.g. C++) Human read/writeable Use text-based data for equal convenience However, text-based data will often need to be parsed – at run-time Consider parsing performance and validation issues Can use binary data files, or compile text files to a binary form. Will not consider that here Can help for very large data sets

Issues with Text-based Data Parsing text-based files is slower than using hard-coding or binary data files However, most data is read at game or level set-up time, where performance is less critical Can be a issue regarding loading times Text files need more storage than binary data Data files are rarely significant in size, so only relevant with regards parsing time Text validation can be a headache True, good QA processes can help here Additional code development required (parsing) Reusable though

Rationale for Text Data Files Hard-coded data is inflexible: Requires recompilation for every change Requires programmer for every change Requires knowledge of code locations Text-based data files provide flexibility All settings in a few easily located files No recompilation required Can be even be coded to allow run-time changes to settings Changes can be made by anyone Including post-release

Simple Example: INI files The Microsoft “.ini” file is used in many applications to store simple settings: The format is long out-of-date, but still used for its simplicity A set of sections, each with keys and values: [Graphics] EnableWiggle=1 TreeType=“Tree1.x” [Input] MaxNameLength=256 Use functions such as GetPrivateProfileString & WritePrivateProfileSection

XML Overview XML (eXtensible Mark-up Language) is a general purpose mark-up language XML is used to store structured data Hence “mark up”: the data is marked with structure XML is not a programming or scripting language Not a sequence of operations, just structure XML has similar syntax to HTML Tags (<a> </a>) Attributes (<entity type=“Ship” />) XML is a text-based format But it isn’t really intended to be read

XML Overview XML is part of a family of technologies E.g. XSL – Style sheets for presenting XML XSLT – Transformations to convert XML data XML Schemas – To define constraints on XML data Etc. XML is platform independent and license-free Well supported, many implementations Lots of supporting tools too Plenty of free sources

XML Popularity XML was originally designed for transferring data across the internet But well suited to store structured data for general use XML is growing in popularity as the standard for data files For it’s portability and simplicity Microsoft, Apache, Mozilla etc. A number of games use XML too… Perhaps not for all their data needs, but certainly popular for configuration files and the like PC titles mainly

XML for Games XML stores data in a tree structure: <Level> <Entities> <Entity> <Type>Ship</Type> <Name>Luke</Name> <Position>0,10,0</Position> </Entity> <Name>Darth</Name> <Position>0,10,-100</Position> </Entities> </Level>

XML for Games Data can be stored between tags (previous example), but can be store as attributes instead: <Level> <Entities> <Entity template=“X-Wing” name=“Luke”> <Position X=“0” Y=“10” Z=“0” /> </Entity> <Entity template=“Tie-X1” name=“Darth”> <Position X=“0” Y=“10” Z=“-100” /> </Entities> </Level> In either case, the tree-based layout naturally matches many structures in games

XML for Games XML elements (tags) and attributes are customisable: <EntityTemplate Type="Ship" Name=“X-Wing" Mesh=“XWing1.x" HP="90" MaxSpeed="280" Acceleration="25" TurnSpeed="1.2"/> Suiting the wide variety of contexts in a game Values can be constrained with XML Schema: <xs:element name=“MaxSpeed"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="120"/> </xs:restriction> </xs:simpleType> </xs:element>

XML for Games XML is fairly easy to parse with its consistent tag structure Parsing speed can be reasonable Depending on the amount of validation Although XML data gets large quite easily which has an impact XML data is robust: Needs to be “well formed” But otherwise resilient to missing/duplicate data etc. So overall a good choice for game data More powerful than .ini files More data-centric than a scripted solution Will look at XML game data in the labs

XML APIs Two types of API for parsing: Stream-oriented – parses XML as a stream, uses callbacks as tags are opened and closed Potentially faster, especially on large documents Event / State based programming can be clumsy E.g. The expat parser (will see in the labs) Tree-traversal – reads entire document, passes back complete hierarchical structure Easier to work with Problems with large files E.g. TinyXML (good for projects)

XML APIs Popular APIs: Expat: Free, event driven, fast, used by Mozilla and others Libxml2: Free, event or document driven, powerful Xerces: Free, event / document driven, validates TinyXML: Free, simple document driven parser designed for simple integration into C++ programs Using Expat in the labs, though TinyXML may be a good choice for projects

XML Editors XML Notepad (Microsoft): Free, well supported XMLPad (WMHelp): Free powerful Many others Each allows editing in plain text or graphically Allow some measure of validation Can also create style sheets, schema etc. Visual Studio also has some support which is convenient for small files and simple changes