Draft Interview Responses
13 Dec 2007

JMM = J. Michael Moshell, UCF
MG = Michael Gourlay, FIEA, EA
TG = Thomas Gorence, I.D.E.A.S.
BA = Bill Albing
SS = Sherry Steward, DEI

Q1: Briefly describe your job, your day to day duties, and your role within your organization.


JMM: I work as a professor of Digital Media. In this capacity I design and teach courses, conduct research projects, write grant proposals, develop new curricula and serve on University committees.

MG: I have two jobs: I am a research associate at University of Central Florida in a graduate program called the Florida Interactive Entertainment Academy where I create curriculum for and teach graduate students learning how to make interactive media (such as video games and military simulations) and also do research. I am also a senior software engineer at Electronic Arts where I write software for video games including Madden NFL, NASCAR and several other games. Among many other things, I wrote the visual effects system used by many EA Sports titles including Madden, NCAA, NASCAR, NFL Tour, Fight Night Big (a.k.a. Pummel), Euro Cup and FIFA Street. I also wrote the network application layer architecture used by Madden and NASCAR.

TG: I am the lead developer / programmer in the graphics department for i.d.e.a.s. / integrity arts. I am involved with creating technical specifications, project maintenance, documentation, testing and deployment. My day to day duties usually involve Flash development (ActionScript programming), PHP / mySQL development, and graphic design.

BA:

SS:

Q2: Please describe a project in which you have used the eXtensible Markup Language. What was the purpose of this project, and who was the audience? Were there multiple authors? What was your design process like? Did you use any brainstorming tools or audience analysis techniques to help structure your XML hierarchy or did you "code from scratch"? Did the structure of your XML document (e.g. elements and attributes and relationships between them) remain the same throughout the duration of the project, or were revisions necessary?

JMM: The Cast Member Performance Management Project (CMPM) is developing a theory and practice for managing the behavior of actors in learning-oriented multi-player online role playing games (MORPG). A central tool of CMPM is the Cast Performance Management System (CPMS), a distributed Java and PHP application that coordinates the activities of online actors. The purpose is to provide new ways of using computer game technology for learning in K-12 and university education. Its ultimate audience will be the students in schools and universities around the world, we hope. My graduate student Alpesh Makwana and I are authoring these materials, with help from "seasonal labor" (semester-long student projects.) We coded from scratch, but the structure is based on a formal model that we call the Scenario Segment Guide. The structure of our documents (there are several) are constantly evolving as we implement the Java and PHP code and test the resulting system.

MG: At FIEA and EA we use XML in nearly all games to describe many forms of data including visual effects. The purpose of the projects is to entertain, and the audience includes anybody who plays or develops video games. Video game software (e.g. the "engine" and asset conditioning software) effectively has 4 sets of users, each with different requirements: End users who play the games or potentially modify them, artists who supply artistic content ("assets") used in the game, producers and level designers who supply various other kinds of content such as layout and high-level descriptions of autonomous behavior, and other programmers who author everything else. Typically a modern video game for a current console has a team of anywhere from 30 to 150 people. The design process is somewhat formal and includes several phases, starting with the game pitch. After the pitch is approved then preproduction starts, which includes research, design and prototyping. We have employed various tactics including traditional and more recent methods. We used to spend about 6 to 8 weeks writing design documents, then spent the rest of the year writing software. More recently we have started to adopt techniques resembling "SCRUM" where we alternate between design and production. For other parts of the project we have used brainstorming tools such as MindMap, but the XML formats usually derive from higher level requirements of the software design. Often the XML layout has a direct analogy to the classes used to implement the software. More recently we have had a push toward designing the XML separately from the implementation so that we could in principle have file formats that outlive and span across any given implementation so that even if we have multiple competing engine implementations then at least they could share their file formats. In practice we have not adopted that practice yet. We regularly extend the XML format with an eye toward having the new parser continue to accept older files. Most of the time, we add to the existing XML format and rarely change something so drastically that old files fail to work with the new parser.

TG: A recent example project involving XML would be a trivia application. Basically, a list of multiple-choice questions, and feedback depending on whether the person got the question right or wrong. The purpose of the project was to create an interactive educational exhibit, that could randomly select a question from an external file, which could easily be updated by someone without knowledge of programming. The design process usually starts with planning, followed by design of the XML file structure itself. A common tool I use for almost all XML applications is known as ECMAScript for XML, or for short, E4X. It makes parsing and searching the information within an XML file much easier. For most trivia projects, the format stays the same. The main element tags are TRIVIA (the main “wrapper” tag), QUESTION (to “wrap” each question) and ANSWER (child nodes of QUESTION tag). For each set of ANSWER tags inside a QUESTION tag, one of those elements has a “CORRECT” attribute. This format is extremely simple, and rarely needs any revisions. If a revision is needed, it would only be for a special case, such as adding time limits to certain questions.

BA:

SS:

Q3: Why did you choose to use XML rather than another technology (such as a relational database?)

JMM: First - XML is uniquely low-cost. The concept can be explained in minutes, and you can immediately begin to build documents with an ordinary word processor. Second - Tools exist in Java, in PHP, and indeed in most major programming environments that make it easy to transform XML into data structures that are used within the telecommunication and graphical display elements of our programs.

MG: We also use relational databases for other kinds of information, especially where we need to execute sophisticated relational queries on the data. XML works well when we need some text format which describes some asset, usually in some static way. We like XML because parsers for it are readily available; the format is familiar to most programmers and some non-technical people so humans can modify the file format in the absence of a specialized authoring tool.

TG: XML tends to be more of a “standard” format, in that an XML has a definitive structure, and a definitive set of data, no matter what is accessing the XML file (whether it be a website, flash animation, software, notepad, etc.) Using the aforementioned E4X function library can also bring many of the benefits of a relational database to XML (specifically, search queries and linking multiple entries to each other). While XML will not replace relational databases, it can emulate their function, so in most cases, I choose to go with XML, unless there are performance issues.

BA:

SS:

Q4: What process did you use to author your XML content? Did you use any tools or software programs (including software that auto-generates XML code)?

JMM: There are three principal XML documents in our system: The Scenario Model, multiple Session Records and Session Logs. A Scenario Model is constructed manually. Currently, we use word processing, but we could use a syntax-directed tool to automatically build well-formed valid code. We just haven't done so yet. Session Records are automatically constructed from the Scenario Model by the Java application. The Session Record contains the particulars of a particular "run" of the game: who played what roles, which goals and learning objectives have been met, what reconfigurations of the user interface have been made (e. g. boxes dragged around the screen, etc.). Session Logs are also automatically generated by the Java application. They record all changes to the system's state, as well as all dialog that occurred through the built-in text chat system.

MG: We use multiple methods to author the XML: Initially the systems had their data described procedurally, at which point we made the decision to read the descriptions from a file. Instead of authoring the files from scratch we wrote serialization methods to output the existing descriptions in XML form. Subsequently people modified the XML files using regular text editors. Later, people developed several specialized authoring tools to modify and author XML files either directly or indirectly. It is common for games to have in-game "tweakers" which update the data structures directly after which the classes containing the data can serialize the data out to XML.

TG: All of my XML is coded with a regular text editor, such as notepad. There are many tools to make coding easier via color-coded syntax and auto-completing phrases, however I haven't found anything that works much better than the traditional copy and paste workflow.

BA:

SS:

Q5: What type of parser (SAX, DOM, etc.) did you use for your project? Was this parser commercially available, or did you build it? Why did you choose this parser, and were there any particular advantages or disadvantages to it?

JMM: I wrote my own ad hoc XML processor in Java, based on DOM4J. It is open source. I chose it because it easily integrates with Java in the Eclipse IDE.

MG: Usually SAX (for in-game use) but sometimes DOM (usually for tools used internally). At EA we use a parser written internally. At FIEA we use an open source parser called Expat. At EA we have to use software developed internally or for which we have obtained licenses. The process of obtaining a license is cumbersome and we generally need to modify source code so that we can control the memory footprint since most games ship on fixed memory systems. At FIEA we have more limited resources and Expat serves our needs adequately.

TG: Being a flash project, there are a few ways to parse the data. Flash 8 and earlier (ActionScript 2.0) has an awkward way of parsing XML information, so I normally rely on a custom class called XMLConstruct made for ActionScript 2.0, however Flash 9 (ActionScript 3.0) has built in functions to parse XML, including the E4X library. The aforementioned XMLConstruct class was created by a group of developers at indivision.net. The ActionScript 3.0 parser is built in to the new Flash CS3 commercial software

Using the XMLConstruct parser is extremely advantageous in that it allows you to refer to a specific XML element (also known a “node”) by name, as opposed to by number. For example, without the XMLConstruct class, to refer to an element, it would look something like this:

myNode = myXML.childNode[0].childNode[1].nextSibling;

using the XMLConstruct class, the same result could be attained thusly:

myNode = myXML.trivia[0].question[1].answer;

BA:

SS:

Q6: Did you use stylesheets or transformations with your XML documents? If so, which types?

JMM: Not yet. We are evolving the DTD for our CMPM dialect (we call it cpXML) but as yet the parsing is 'ad hoc', driven by the architecture of our Java application.

MG: Not usually.

TG: Typically, I do not use stylesheets or transformations with my XML documents. Any formatting or manipulation is done after the information has been parsed by the parent application (in most cases, this is Flash).

BA:

SS:

Q7: How did you validate your XML documents, if at all? Did you use DTDs, Schema, or another method?

JMM: Again, we handle this by producing error messages within our Java code if the DOM4j system objects to any well-formedness issues; and reporting any validation issues when our internal scanner fails to understand a structure.

MG: At EA the tools teams sometimes employ validation facilities built into the DOM parser.

TG: When using flash, the only validation needed is standard error checking. If the application works, and is bug-free, the XML is considered valid. When dealing with XML for websites (for example, RSS feeds), then many different tools are used or validation, my favorite being the W3C online validator.

BA:

SS:

Q8: In your mind, what are the primary strengths and weaknesses of XML as a communications technology?

JMM: Strengths: broad acceptance, simplicity. Weaknesses: no systematic way to find relevant namespaces. It sometimes seems like luck and accident when one finds good ontologies.

MG: Primary strength is that customizing a parser for XML is extremely easy especially when using a SAX-based parser which mostly entails writing callbacks and a simple push-down automata. Usually we can get away with finite-state automata and occasionally employ a stack to handle recursive elements, which are rare. Primary weakness is that it is verbose so although editing by hand is straightforward, it takes a much larger number of keystrokes. Also, reading XML is slightly harder than reading other declarative languages. Writing procedural phrases in XML is especially cumbersome.

TG: The strengths of XML would be its open text format, ability to be edited using standard text editors, and the ease of reading / editing the information. The weaknesses are directly related to its strengths: being a physical file format, it can create issues with performance, especially if many different applications are trying to read from the same file at once. This is where a standard database would be ideal.

BA:

SS:

Q9: What skills and competencies are important to technical professionals wishing to learn more about XML and XML-related technologies?
Aside from learning the subject matter itself, would you recommend any additional fields of study or particular coursework?


JMM: In our case, computer science has been very useful. We haven't tried to use tools that might be appropriate for non-programmers, since our principal objective has been to build our own software. For many or most XML users, programming should not be a requirement. The tools appropriate to these audiences are not yet part of our repertoire.

MG: I teach (or review with) my students the basics of formal language theory and the Chomsky hierarchy, which applies to parsing in general. I also teach my students how to use a SAX-based parser and they are required to implement a parser that they use in a game engine that they write. People dealing with any parser should understand the fundamentals of automata, specifically finite state and push-down.

TG: A good understanding of the concepts of database redundancy and database design are essential in being efficient with XML, or any database at all. A working knowledge of HTML would also be extremely helpful, since XML could be easily considered a regular HTML page, with custom tags as opposed to predefined ones. XML has so many uses, that additional fields of study are too numerous to count, however I will emphasize some of the particulars aforementioned. ECMAScript for XML (E4X) is one of the most powerful tools for dealing with XML data, and learning how to use it should be a top priority for anyone involved with XML. XML also allows you to emulate any number of database designs, including single-linked-lists, double-linked-lists (also known as graphs) and many others. Understanding the differences between various database structures is the best recommendation I could give. Sometimes database design (or in this case, XML file structure) is such a blank sheet of paper, it's hard to know where to start.

BA:

SS:

Q10: Are there any other comments or thoughts about your project you would like to share?

JMM: XML has proven to be much easier to work with than I anticipated. The tools such as DOM4j and PHP's SimpleXML just seem to work, reliably and first-try. This makes projects move much faster than some other technologies.

MG: In games it is useful to have compact file formats that parse very quickly. Since XML is a text format, it is fundamentally slow to parse. Some XML parsers have subsystems that partially pre-parse and generate a binary file format that has a direct analogy to XML. It is important for interactive applications to have access to tools such as that.

BA:

SS: