TW202318221A - Platform to automate creation of serialised data objects for import into a game engine - Google Patents

Abstract

According to one aspect of the invention, there is provided a platform for creating serialised data objects from external data, the platform configured to generate code that analyses a table, comprising the external data organised in cells, to identify the type of data stored in each cell; determines if the identified data types are parsable; generates, in response to the identified data types being parsable, further code that when compiled outputs at least one serialised data object, wherein the data stored in each cell of the table is assigned to an attribute of the serialised data object; and retrieves an export format for the serialised data object, wherein the platform is further configured to compile the generated further code to output the serialised data object in the retrieved export format.

Description

Platform for automated creation of serialized data objects for import into a game engine

This disclosure relates to a platform that receives external data stored in tables and generates code to extract the external data for import into a game engine environment.

Although software game engines facilitate game development through access to game development tools, developers still have the tedious task of customizing these tools according to game requirements. Part of this customization provides data parameters for these tools that are used by the game being developed.

The direct way is to customize these development tools within the game development environment, where the developer manually changes all data values individually within the software game engine itself. The direct approach is tedious and time-consuming.

The second method is batch modification by importing a table containing data parameters for use by the game development tools. One or more spreadsheets (eg, in Excel® or Google Sheets® format) for editing and storing external data in a tabular format. In order to read external data in a game engine environment, the following procedure is generally followed: (1) write code specific to the data to read the external data for conversion into an in-game data object; (2) use tools to Convert external data into an easily readable data format (such as CSV), and then write code to read the data objects into the game engine environment. Programmers may need to rewrite the code for each new table.

The above process requires collaboration between designers and programmers, which results in time costs and inefficiencies in maintaining data structures for spreadsheets containing external data. Once the data structure changes, programmers need to adapt their written code accordingly, otherwise there will be errors when creating data objects that are read in-game.

An object of the present invention is to provide a solution to the above disadvantages.

According to a first aspect of the invention, there is provided a platform for creating serialized data objects from external data, the platform being configured to generate code that parses a table containing external data organized in cells to identifying the type of data stored in each cell; determining whether the identified data type is parsable; responsive to the identified data type being parsable, generating another code that when compiled outputs at least a serialized data object in which the data stored in each cell of the table is assigned to a property of the serialized data object; and an export format for retrieving the serialized data object in which the platform is further configured to compile another resulting Code to output serialized data objects in the extracted export format.

According to a second aspect of the present invention, there is provided a method for creating serialized data objects from external data, the method comprising the steps of: generating code to analyze a table containing external data organized in cells to identify the the type of data in the unit to determine whether the identified data type is parseable; in response to the identified data type being parseable, another code is generated that when compiled outputs at least one serialized A data object in which the data stored in each cell of the table is assigned to a property of the serialized data object; retrieves the export format of the serialized data object; and compiles another code generated to present the retrieved export format to output serialized data objects.

In the following description, various specific examples are described with reference to the drawings, wherein like reference numerals generally refer to like parts throughout the different views.

This application falls within the field of game development using game engines. A game engine provides a suite of reusable software components that game developers need to create games, such as graphics, sound, physics, and artificial-intelligence (AI) functions. This software suite allows game developers to create game objects, which are representations of elements designed for use in the game, such as characters, weapons, and environmental objects. Changing the properties of game objects allows each element to be customized to meet the needs of the game.

Data for these in-game objects (to modify their properties) can be stored in external files, such as spreadsheets created with diagramming software such as Excel® and Google Sheets®. Use a spreadsheet because it allows external data to be organized in a table. However, such spreadsheets cannot be imported directly into the game engine environment. Specific code must be written to parse this table to create data objects in a format recognized by the game engine, where each of the data objects contains relevant external data intended for the game object. The data objects can then be imported into the game engine, meeting the goal of importing external data into the game engine for conversion into game objects.

Rather than having to manually re-code to parse the tables used to store external data, this application attempts to implement a workflow that automates the process of importing data stored in external tables. This application achieves this implementation via a platform that hosts a program that, after detecting that external data imported into the game engine is contained in a table, then creates the code for the table recognized by the game engine.

In more detail, the program generates code that can access external data stored in tables in cells, organized as columns and rows. The generated code is configured to identify the type of data stored in each cell, and to output executable statements catering to that type of data. For example, if a cell is identified as containing an integer, the generated code will output executable statements to cater for integer-type data. In one implementation, the generated code identifies or learns the type of data stored in each of the cells of the table from an index accompanying the table that defines the type of data stored in each of the cells of the table by stating one or more properties of the stored data Data in each of the cells in the table. For example, an index may define that the data stored in a particular cell should be an integer and intended only at the client.

After determining that the identified data types that exist across external data are parseable, the platform generates another code to output executable statements catering to each of the identified data types to serialize the data stored in the cells of the table external information. This serialization creates one or more serialized data objects, which are data that each have a unique identifier and are used to combine different data types (eg, string, float, array) object. Each data type is identified by its name, and different data types are also called attributes of each data object. The generated further code outputs executable statements that map the data in the cells of the table to attributes of serialized data objects such that when the generated further code is compiled, the values stored in the table The data in each unit of is assigned to properties of the serialized data object such that the serialized data object has a collection of name and data pairs. The name of each property of a serialized data object is obtained from the field name of the unit providing data for that property. The generated code also exports one or more serialized data objects in a specified export format to accommodate the various acceptable input formats that different game engines have. The game engine can then load one or more serialized data objects for matching use with in-game data objects, whereby the data in the properties of each serialized data object is copied to the corresponding properties of the game object, where the serialized data object. In this way, the properties of data objects in the stylized game can be modified by external data in the spreadsheet.

Advantageously, all code generation and output of one or more serialized data objects is automatic without requiring code written by the game developer, thereby reducing the workload to manually create code that can Export external data stored in spreadsheet files during the game development phase.

The automatic code generator for outputting serialized data objects is described in more detail below with reference to FIGS. 1-8 .

FIG. 1 shows a workflow 100 for importing external data into a software game engine, such as but not limited to Unity®. Steps 102 and 104 are directed to the design of spreadsheets containing external data. According to an embodiment of the invention, steps 106, 108, 110, 112, and 114 are performed by a platform hosting an automated code generator to create serialized data objects from external data contained in the spreadsheets of steps 102 and 104 . Steps 116 and 118 are performed by a software game engine that imports the serialized data object created in step 114 .

In steps 102 and 104, a methodology is adopted in which the data structure of the spreadsheet is defined and the external data is configured to follow the data structure. Standardization of this methodology, such as predefining how external data is organized into rows for specific data types, will allow the creation of spreadsheets that platform-generated code works with spreadsheets.

Figure 2A shows a spreadsheet 200 (shown in two halves due to space constraints) of one possible implementation configuration according to this methodology. Spreadsheet 200 has a table 202 containing external data organized in cells 206 . Spreadsheet 200 also includes an index 204 accompanying the sheet 202 .

Index 204 defines the data stored in each of cells 206 in table 202 by stating one or more properties 208 of the stored data. The index 204 is referenced to determine which of the one or more properties 208 affect the code generation that occurs in steps 106, 108, 110, 112 to create the serialized data object. The one or more properties specify, but are not limited to, one or more of: the field names for each of the cells 206, the type of data stored in the cell 206, and the data in the cell 206 is for the user On the end or on the server. For example, the cell under the row "Example_Float" has four properties: the specification of the unique identifier ("ID") of the serialized data object to which the data in the cell belongs; the name of the data stored in the cell A specification ("Example_Float") that also provides the name of the property of the serialized data object to which the data in the cell is assigned (see 508 in Figure 5, 608 in Figure 6, and 708 in Figure 7); stored in the specification of the type of data in the cell ("float"), which in this case is a floating-point data type; and the specification of the range of data stored in the cell ("both"), which in this case indicates its For server or client. Similarly, all cells below the row "Example_Vector2" have five properties: the specification of the unique identifier ("ID") of the serialized data object to which the data in the cell belongs; the name of the data stored in the cell ("Example_Vector2") which also provides the name of the property of the serialized data object to which the data in the cell is assigned (see 510 in Figure 5, 610 in Figure 6); the type of the data stored in the cell the specification of ("Vector2"), which here is a two-dimensional array; the specification of the extent of the data stored in the cell ("client"), which in this case indicates that it is only for the client; and invalidation checks A specification that is executed to determine whether a cell needs to store data ("IsNullOrEmpty"), which in this case is executed for cells that fall below the column "Example_Vector2".

The external data in table 202 are considered valid configurations when the external data are organized according to the structure defined by index 204 . For the spreadsheet 200 of FIG. 2A, the structure is as follows. The first row specifies the field names for the data in the cell below it. The second column specifies the type of data stored in the cell below its row. The third column specifies the range of data stored in the cells below it, since some field names are used only by the client, while others are only used by the server for memory optimization purposes. The fourth column provides a means for specifying test conditions that can be applied to check that the data stored in the cell below it is configured effectively. The test condition described in the spreadsheet 200 is a null check ("IsNullOrEmpty"). However, other test conditions (not shown) may specify such as, but not limited to: whether there is a data type match in cell 206 with respect to the data type defined in cell 206 (e.g., if the second column specifies a data type of integer, then check cell 206 The data in it is actually an integer type, and not a floating point type or a string type), and whether there is consistency between the data in one or more of the related units 206, when these one or more related units need to define Applicable when attributes of game objects (e.g., if data in one cell 206 indicates that the gender of the player character is female, then test whether the data in one or more related cells 206 also contains data supporting gender indication, such as a female name ).

It should be appreciated that other structures are possible depending on the content of the index 204 . FIG. 2B shows another spreadsheet 250 (shown in two halves due to space constraints). As with spreadsheet 250 of FIG. 2A , spreadsheet 250 has a table 252 containing external data organized in cells 256 . Spreadsheet 250 also includes an index 254 of accompanying sheet 252 . Index 254 defines the data stored in each of cells 256 in table 252 by stating one or more properties 258 of the stored data. Index 254 thus defines the data structure of spreadsheet 250 whereby external data is configured to follow the data structure during configuration of spreadsheet 250 .

Index 254 of spreadsheet 250 shares similar definitions with index 250 of spreadsheet 250, such as defining the presence of script specific array (key enum Color), integer, string, Boolean, and floating point data types. However, index 254 of spreadsheet 250 also defines an array with multiple data sets (see 260A and 260B for the entry specifically identified as "2"). When the spreadsheet 250 is parsed in step 106, the code generated by the platform identifies each cell below the row "Example_Class_Array" via the reference index 254 as an array with multiple datasets 260A and 260B, and extracts all datasets. In contrast, existing methods extract only the first data set, but not both. The platform then marks each extracted data set 260A and 260B for assignment as an attribute of the final output serialized data object. In this way, each cell below the row "Example_Class_Array" can generate more than one attribute of the serialized data object.

Returning to Fig. 1, the platform for performing steps 106, 108, 110, 112 and 114 can be a single computer server or several computer servers, which have at least one memory to store instructions that affect the generation of program codes from The external data contained in the spreadsheet creates serialized data objects; and one or more processors having execution instructions.

In step 106 , the platform generates code 300 for parsing the spreadsheet 200 , as shown in FIG. 3 . Segment 302 is a C# indexer used to identify unit 206 using its respective field name. Segment 304 creates mappings at runtime to speed up recognition unit 206 . The generated code 300 analyzes tables 202 to identify the types of data stored in each of units 206 to determine whether the identified data types are parsable. The different data types present in table 202 are identified by referring to index 204 accompanying table 202 . The generated code 300 is configured to distinguish between an index 204 providing data definitions and a table 202 containing external data. For example, there may be an executable statement stating the location of index 204 and the location of table 202 in spreadsheet 200 . As previously mentioned, the index 204 defines the data stored in each of the cells 206 in the table 202 by stating one or more properties 208 of the stored data. Reference is made to the second column of index 204 as it specifies the different data types stored in cell 206 .

In the method shown in FIG. 2A , the generated code 300 supports basic data types such as integer (int), string (string), floating point (float) and Boolean (bool). Also supports custom data types commonly used in software game engines, such as "vector2" (two-dimensional array), "Vector3" (three-dimensional array), and script-specific arrays (for example, "enum Gender", "class User" and " repeated int"). The data type of the data stored in each of the cells is also reflected in the field names selected by each of the data cells during serialized data object creation (discussed later in step 106) Called, or by an in-game data object during external data import.

In addition to determining whether an identified data type in table 202 is parseable, another analysis performed on the contents of table 202 in conjunction with index 204 is as follows. The data in each cell 206 may be analyzed for validity relative to its respective property or properties 208 found in the index 204 . For example, if one of properties 208 specifies that the data in cell 206 is an array data type, then cells 206 storing a different data type (eg, integer) subsequently have invalid data. Invalidity checks may be performed on cells 206 required to store data for detecting blanks (ie, whether cells 206 actually store data). There may also be a check for duplicate field names. An error message may be output in response to any of these non-compliant results returned by the analysis, such as the detection of blank cells 206 during invalidity checking, or determination of unparseable by identified data types. In one implementation, the return of non-compliant results from any one or more of these analyzes may prevent spreadsheet 200 from being parsed in step 106 . Alternatively, these analyzes may be done at a later portion of workflow 100 , such as in step 118 .

If the spreadsheet 200 can be parsed in step 106 , the platform generates in step 108 another code 400 shown in FIG. 4 . Compiling another code 400 in step 110 causes data serialization in step 112 . These steps 108, 110 and 112 are described in more detail below. Another code 400 combines different data types 402 into a serialized data object, thereby providing the attributes of the serialized data object, and providing a unique identifier 404 of the serialized data object. Another code 400 combines different data types 402 by calling their respective field names 406 , 408 , 410 , 412 , 414 , 416 , 418 and 420 . It should be noted that although "string", "int", "bool", "float", "Vector2", "Vector3", "enum Gender", "class User" and "repeated int" are different data shown in Figure 2A type, another code 400 of FIG. 4 is used to create a serialized data object having a subset of these different data types, namely "string", "int", "float", "Vector2", "Vector3", "enum Gender ", "class User" and "repeated int". During the generation of another code 400, the index 204 is analyzed to determine combinations of different data types used as attributes of serialized data objects.

This further code 400, when compiled, then outputs at least one of such serialized data objects (see 522 and 524 in FIG. 5; see 622 and 624 in FIG. 6; and 722 and 724 in FIG. 7) or more, wherein the data stored in each cell 206 of the table 202 is assigned to an attribute of the serialized data object (522, 524; 622, 624; and 722, 724) (see 508, 510, 512 , 514, 515 and 518; 608, 610, 612, 614, 616 and 618 in Figure 6; and 708, 714, 716 and 718 in Figure 7). The name of each of the properties of the serialized data object is obtained from the field name of the unit 206 that provided the data for that property.

Compiling the further code 400 results in output of serialized data objects in an export format such as, but not limited to, JSON, scriptable objects, or CSV in step 114 . For example, extract the export format from the configuration file. In one implementation, the configuration file may be placed in the same folder where spreadsheet 200 is stored.

As an example, the configuration file has the following lines: SERVER_LANGUAGE=GO CLIENT_LANGUAGE=C# FORMAT=ScriptableObject SERVER_FORMAT=CSV CLIENT_FORMAT=ScriptableObject Self-read the configuration file, tell the platform that the GO code will be used for the server, and the C# code will be used for the client. In this way, the code generated by the platform can be adapted to output serialized data objects on the server or client side. This configuration file also tells the platform that serialized data objects will be exported in a scriptable object format. Other desired export formats, such as JSON or CSV, are obtained by changing the FORMAT line accordingly and reloading the spreadsheet 200 . One way to create serialized data objects in all desired export formats is to have multiple spreadsheet 200 and configuration file pairs, where each of the configuration files indicates one of the desired export formats for the FORMAT line. It should be appreciated that configuration files may have additional lines listing other possible programming language export formats.

After outputting the serialized data object in step 114 , one or more validity checks may be performed on the data in the serialized data object in step 116 . For example, a serialized data object may be inspected to determine whether one or more of its properties are null, for example, whether the "instance_string" field is empty; or whether there is mismatching data, such as "instance_string" Whether to correct the data type of the "Type" field. Additionally, one or more of the analyzes described earlier to be done in step 106 may alternatively be done in step 116 . These include invalid checks and duplicate field name checks. Performing these checks at step 116 advantageously allows bugs to be fixed before importing the serialized data objects into the software game engine at step 118 to reduce error handling.

In step 118, the serialized data objects from step 114 are imported into the software game engine. The software game engine deserializes these serialized data objects in the game with the generated code when running the game.

Figure 8 shows the code generated by the platform that manages the retrieval of spreadsheets. The generated code allows receiving a search string including the name of the table 202 for locating the table 202 from a plurality of tables stored in one or more folders. In this way, a game developer can easily locate the spreadsheet 200 containing the table 202 .

Returning to FIG. 1 , the platform executes the method for creating serialized data objects from external data via steps 106 , 108 , 110 , 112 and 114 . The method looks at the platform that generated the code 300 to analyze the table 202 containing external data organized in cells 206 to identify the types of data stored in each cell 206 to determine whether the identified data types are parseable. The platform then generates further code 400 in response to the identified data type being parseable, which when compiled outputs at least one serialized data object (522, 524; 622, 624; and 722, 724 ), wherein the data stored in each cell of the table is assigned to properties of the serialized data objects (522, 524; 622, 624; and 722, 724). Finally, the platform retrieves the export format of the serialized data objects (522, 524; 622, 624; and 722, 724) and compiles another generated code 400 to output the serialized data in the retrieved export format Objects (522, 524; 622, 624; and 722, 724).

Steps 102 and 104 may also be part of implementing a method of the platform to create serialized data objects from external data. That is, the method further comprises configuring the spreadsheet 200 by organizing the external data into cells 206 according to the index 204 of the accompanying table 202 stored in the table 202 by stating one or more property definitions of the stored data The data in each of the cells 206 in. One or more properties specify but are not limited to one or more of the following: field names for each of the cells 206, the type of data stored in the cell 206, and the data in the cell 206 is used for On the client or on the server. The generated code 300 is configured to distinguish between an index 204 providing data definitions and a table 202 containing external data.

Methods implemented by the platform to create serialized data objects from external data may also perform one or more of the following actions.

When generating the further code 400 for creating the serialized data object (522, 524; 622, 624; and 722, 724) the index 204 is analyzed to determine which of the different data types are used as attributes of the serialized data object a combination.

When analyzing table 202 to determine whether an identified data type is parsable, one or more of the following is performed: determining the data in each cell 206 relative to its respective index 204 defined in accompanying table 202 Validity of one or more properties; invalidation checks for elements 206 required to store data, and generation of error messages in response to detected blanks; and checks for duplicate field names. An error message may be generated in response to an identified data type being determined to be unparsable.

When processing a cell 206 in a table 202 containing multiple data sets, each of them is assigned to an attribute of the serialized data object (522, 524; 622, 624; and 722, 724).

When locating table 202 for analysis from multiple tables, a search string is received that includes the name of the table.

Adapted to output serialized data objects on the server or client side (522, 524; 622, 624; and 722, 724).

The name of each of the attributes of the serialized data object (522, 524; 622, 624; and 722, 724) is obtained from the field name of the unit 206 that provided the data for that attribute. Properties include a unique identifier for the serialized data object. The export format can be but not limited to one of JSON, scriptable object, and CSV.

The data types that the generated code 300 is designed to parse include basic data types and custom data types for use by software game engines. Basic data types include any one or more of integer, string, floating point, and boolean. Custom data types include any one or more of: 2D and 3D vectors and are script specific.

The above thus reveals a platform that advantageously automates the conversion of external data into in-game data objects, reducing human workload and errors, and improving work efficiency. Supports various external data formats, serialization methods for data objects used by software game engines, and language types of generated code.

In this application, unless otherwise specified, the terms "comprising," "comprise," and grammatical variants thereof are intended to mean "open" or "inclusive" language such that it includes the listed elements but also Permitted to include additional, not expressly listed elements.

While the invention has been described with reference to illustrative specific examples, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt the teachings of the invention to a particular situation without departing from the essential scope of the invention. Therefore, the present invention is not limited to the specific examples disclosed in this specification, but covers all the specific examples falling within the scope of the attached claims.

100: Workflow 102: Step 104: Step 106: Step 108: Step 110: Steps 112: Step 114: Step 116: Step 118: Step 200: Spreadsheet 202: table 204: index 206: unit 208: One or more properties 250: Spreadsheet 252: table 254: index 256: unit 258: One or more properties 260A: Data Set 260B: data set 300: code 302: Fragment 304: Fragment 400: code 402: data type 404: identifier 406: field name 408: field name 410: field name 412: field name 414: field name 416: field name 418: field name 420: field name 508: attribute 510: attribute 512: attribute 514: attribute 515: attribute 518: attribute 522:Serialized data object 524:Serialized data object 608: attribute 610: attribute 612: attribute 614: attribute 616: attribute 618: attribute 622:Serialize data object 624:Serialized data object 708: attribute 714: attribute 716: attribute 718: attribute 722:Serialize data object 724:Serialized data object

Representative embodiments of the invention are described herein, by way of example only, with reference to the accompanying drawings, in which:

[Figure 1] shows the workflow of importing external data into the software game engine.

[ FIG. 2A ] Shows the spreadsheet parsed during the workflow of FIG. 1 .

[FIG. 2B] Another spreadsheet showing that the workflow analysis of FIG. 1 can also be used.

[FIG. 3] Shows the code generated during the workflow of FIG. 1 to parse the spreadsheet of FIG. 2A.

[FIG. 4] Shows the code generated during the workflow of FIG. 1 to output serialized data objects.

[FIG. 5] shows serialized data objects in scriptable object format output by the generated code of FIG. 4.

[FIG. 6] shows serialized data objects in JSON format output by the generated code of FIG. 4.

[FIG. 7] shows serialized data objects in CSV format output by the generated code of FIG. 4.

[FIG. 8] Shows the code generated by the platform that manages the retrieval of spreadsheets containing external data.

100: Workflow

102: Step

104: Step

106: Step

108: Step

110: Steps

112: Step

114: Step

116: Step

118: Step

Claims (20)

A platform for creating serialized data objects from external data, the platform configured to generate code that: analyzing a table containing the external data organized in cells to identify the type of data stored in each cell; determine whether an identified data type is parseable; generating further code responsive to the identified data types being parseable, the further code outputting at least one serialized data object when compiled, wherein the data stored in each cell of the table is assigned to an attribute of the serialized data object; and Retrieves an export format for this serialized data object, Wherein the platform is further configured to compile the generated another code to output the serialized data object in an extracted export format. The platform of claim 1, wherein the data type is identified by reference to an index accompanying the table, which index is stored in each of the cells in the table by stating one or more property definitions of the stored data the data in the author. The platform of claim 2, wherein the index is analyzed when generating the further code to create the serialized data object to determine a combination of different data types for the attributes of the serialized data object. The platform of claim 2 or 3, wherein the one or more properties specify one or more of: a field name of each of the units, the type of data stored in the unit , and whether the data in the unit is for a client or a server. The platform of any one of claims 2 to 4, wherein the generated code is configured to distinguish between the index providing data definitions and the table containing the external data. The platform according to any one of claims 2 to 5, wherein the analysis of the table further comprises determining the validity of the data in each unit with respect to its respective one or more properties. The platform of any one of the preceding claims, wherein the analysis of the table further comprises performing invalidation checks on cells required to store data, and generating an error message in response to detecting blanks. The platform of any preceding claim, wherein the analysis of the table further comprises performing a check for duplicate field names. The platform of any one of the preceding claims, further configured to generate an error message in response to the identified data types being determined to be unparseable. The platform according to any one of the preceding claims, wherein the generated code is designed to analyze the data types including basic data types and custom data types used by a software game engine. The platform of claim 10, wherein the basic data types include any one or more of integers, character strings, floating points, and Bollinger; and the customized data types include any one or more of two-dimensional and three-dimensional vectors Many, and are script-specific. The platform of any one or more of the preceding claims, wherein the name of each of the attributes of the serialized data object is obtained from the name of a field of the unit that provided the data for that attribute. The platform of any one or more of the preceding claims, wherein the attributes include a unique identifier for the serialized data object. The platform of any one or more of the preceding claims, further configured to process a cell in the table containing multiple data sets to assign each of them to an attribute of the serialized data object. The platform of any preceding claim, further configured to locate the table for analysis from the plurality of tables by receiving a search string that includes the name of the table. The platform of any one or more of the preceding claims, further configured to accommodate output serialized data objects for a server or a client. The platform according to any one of the preceding claims, wherein the export format is one of JSON, scriptable object, and CSV. The platform according to any one of the preceding claims, wherein the export format is extracted from a configuration file. A method for creating a serialized data object from external data, the method includes the following steps: generating code to parse a table containing the external data organized in cells to identify the type of data stored in each cell to determine whether the identified data type is parsable; generating further code responsive to the identified data types being parseable, the further code outputting at least one serialized data object when compiled, wherein the data stored in each cell of the table is assigned to a property of the serialized data object; retrieve an export format for the serialized data object; and The generated further code is compiled to output the serialized data object in an extracted export format. The method as claimed in item 19, further comprising: The external data is organized into cells according to an index accompanying the table that defines the data stored in each of the cells in the table by stating one or more properties of the stored data. material.

Images