Development program, information processing system, information processing device, and information processing method

Abstract

To implement serialization and / or deserialization processing not affected by a change or the like of a type of a target object or the like.SOLUTION: A development program is provided for development of an application program with a programming language in which an object is generated on the basis of a type. The development program causes a computer of an information processing apparatus to function as: identifying means which identifies a type definition in a source code of the application program; and code addition means which generates a first code that generates an intermediate object for asset data corresponding to each of objects generated on the basis of the identified type definition and adds the generated first code to the source code of the application program. The intermediate object is stored as the asset data.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to a development environment for application programs, and more specifically, to serialization and deserialization of data.

Background Art

[0002] Conventionally, a process called serialization, in which data managed by an application program during execution is written out (persisted) to storage or the like, is known. The serialized (or to be serialized later) data is called asset data.

[0003] For example, Japanese Patent Application Laid-Open No. 2018-32154 (Patent Document 1) discloses a serialization data processing device or the like that can easily realize storage / retrieval of a plurality of versions of class instances.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] When serializing an object managed by an application program during execution, data having a data structure corresponding to the type of the object is written out. During the stage of developing an application program, the type of an object may be changed. When the type of an object is changed, it becomes difficult to reuse the previously written data in the application software.

[0006] One object of the present disclosure is to realize serialization and / or deserialization processing that is not affected by changes in the type of a target object or the like. [Means for solving the problem]

[0007] (Configuration 1) According to one embodiment, a development program is provided for developing an application program using a programming language that generates objects based on types. The development program causes the computer of the information processing device to function as a means for identifying type definitions in the source code of the application program, and a means for generating first code that generates intermediate objects for asset data corresponding to each of the objects generated based on the identified type definitions, and adds the generated first code to the source code of the application program. The intermediate objects are stored as asset data.

[0008] According to Configuration 1, the first code can be automatically generated to create intermediate objects corresponding to objects generated based on type definitions in the source code of the application program. These intermediate objects can be saved as asset data. In this way, since an intermediate object separate from the application program object can be used, serialization and / or deserialization can be achieved without being affected by changes in the type of the target object, etc.

[0009] (Configuration 2) In the development program described in Configuration 1, the code addition means may further add a second code, which is a type definition of an intermediate object, to the source code of the application program. An intermediate object may be generated according to the type definition of the second code. According to Configuration 2, since the type of the intermediate object can be defined using the second code, an intermediate object corresponding to the asset data to be output can be generated.

[0010] (Configuration 3) In the development program described in Configuration 1 or 2, the type of the intermediate object in the second code may be defined independently of the type definition in the corresponding source code. According to Configuration 3, the type of the intermediate object can be independent of the type of the object in the application program. Therefore, even if the type of the object in the application program is changed, the asset data will not be affected.

[0011] (Configuration 4) In the development program described in any of Configurations 1 to 3, the type of the intermediate object may be defined in the second code to inherit a common type definition. According to Configuration 4, the type definition of the intermediate object can be simplified by including the definition of common member functions, etc., in the common type definition.

[0012] (Configuration 5) In the development program described in any of Configurations 1 to 4, the second code may include code for calling a process to store values ​​obtained by a pre-specified function or pre-specified values ​​in an intermediate object. According to Configuration 5, not only can the data held by the application object be stored directly in the intermediate object, but values ​​obtained by a pre-specified function or pre-specified values ​​can also be stored in the intermediate object, thereby increasing the flexibility and convenience of program development.

[0013] (Configuration 6) In the development program described in any of Configurations 1 to 5, the second code may include code for calling a function that passes the value of a property held by an intermediate object to a pre-specified function. According to Configuration 6, the value of a property held by an intermediate object can be passed to a pre-specified function. For example, by specifying a function that sets data to an application object as the pre-specified function, it is possible to easily set data from an intermediate object to an application object.

[0014] (Configuration 7) In the development program described in any of Configurations 1 to 6, the second code may include code for calling a process that outputs the values ​​of the intermediate object's properties in a predetermined format for each type of intermediate object. According to Configuration 7, the process of outputting the values ​​of the properties held by the intermediate object in a predetermined format can be called from the intermediate object, so the process of writing out asset data can be easily implemented in application programs and the like.

[0015] (Configuration 8) In any of the development programs in Configurations 1 to 7, the specific means may extract a predetermined description from the source code of the application program, which includes a first description that specifies the name of a property and a second description that specifies a function or variable for obtaining the value. According to Configuration 8, first code can be generated based on the first and second descriptions.

[0016] (Configuration 9) In any of the development programs in Configurations 1 to 8, the code addition means may further add third code to the source code of the application program that performs processing to maintain the history of the intermediate object. According to Configuration 9, editing operations such as Undo and Redo can be performed on the values ​​of the properties held by the intermediate object.

[0017] (Configuration 10) According to another embodiment, an information processing system is provided for developing an application program using a programming language that generates objects based on types. The information processing system includes identification means for identifying type definitions in the source code of the application program, and code addition means for generating first code that generates intermediate objects for asset data corresponding to each of the objects generated based on the identified type definitions, and adding the generated first code to the source code of the application program. The intermediate objects are stored as asset data.

[0018] (Configuration 11) According to another embodiment, an information processing device is provided comprising one or more processors and memory for storing a program. The information processing device performs the following processes when one or more processors execute a program: identify type definitions in the source code of an application program written using a programming language that generates objects based on types; generate first code that generates intermediate objects for asset data corresponding to each of the objects generated based on the identified type definitions; and add the generated first code to the source code of the application program. The intermediate objects are stored as asset data.

[0019] (Configuration 12) According to another embodiment, a computer-operated information processing method is provided for developing an application program using a programming language that generates objects based on types. The information processing method includes the steps of: identifying type definitions in the source code of an application program written using a programming language that generates objects based on types; and generating first code that generates intermediate objects for asset data corresponding to each of the objects generated based on the identified type definitions, and adding the generated first code to the source code of the application program. The intermediate objects are stored as asset data. [Effects of the Invention]

[0020] According to this disclosure, serialization and / or deserialization processes can be implemented that are not affected by changes in the type of the target object, etc. [Brief explanation of the drawing]

[0021] [Figure 1] This is a schematic diagram showing an example of the hardware configuration of an information processing device according to this embodiment. [Figure 2] This figure shows an example of a type and the objects generated based on that type. [Figure 3]It is a diagram showing an example of asset data generated by serialization. [Figure 4] It is a diagram for explaining an example of the execution state of an application program generated by the information processing apparatus according to the present embodiment. [Figure 5] It is a schematic diagram showing a functional configuration example of the information processing apparatus according to the present embodiment. [Figure 6] It is a flowchart showing an example of the processing procedure of the build process of the information processing apparatus according to the present embodiment. [Figure 7] It is a flowchart showing an example of the processing procedure of the generation process (step S6) of the additional code shown in FIG. 6. [Figure 8] It is a diagram showing an example of the serialization definition description and the additional code generated based thereon. [Figure 9] It is a diagram schematically showing the software configuration implemented by the additional code shown in FIG. 8(B). [Figure 10] It is a diagram showing another example of the serialization definition description and the additional code generated based thereon. [Figure 11] It is a diagram showing yet another example of the serialization definition description and the additional code generated based thereon. [Figure 12] It is a diagram showing yet another example of the serialization definition description and the additional code generated based thereon. [Figure 13] It is a diagram showing an example of the editing of the automatically generated additional code. [Figure 14] An example of a serialization definition description explicitly including a type specification description is shown. [Figure 15] It is a diagram for explaining the handling of the serialization definition description at the time of build in the information processing apparatus according to the present embodiment. [Figure 16] It is a diagram for explaining the processing of the member functions of the intermediate object generated during the execution of the application program generated by the information processing apparatus according to the present embodiment. [Figure 17]This diagram illustrates the processing of member functions of intermediate objects generated during the execution of an application program produced by an information processing device according to this embodiment. [Figure 18] This figure shows an example of a schema file generated by an information processing device according to this embodiment. [Figure 19] This figure illustrates an example of how to use a schema file generated by an information processing device according to this embodiment. [Figure 20] This figure illustrates an example of how to use a schema file generated by an information processing device according to this embodiment. [Figure 21] This figure illustrates an example of how to use a schema file generated by an information processing device according to this embodiment. [Modes for carrying out the invention]

[0022] This embodiment will be described in detail with reference to the drawings. Note that identical or corresponding parts in the drawings are denoted by the same reference numerals, and their descriptions will not be repeated.

[0023] [A. Overview] In this embodiment, examples include a development program and an information processing device for developing application programs using a programming language that generates objects (instances) based on types (typically an object-oriented language). The source code of the application program is written using a programming language that generates objects based on types.

[0024] The information processing device according to this embodiment generates additional code to enable the output of asset data in a data structure independent of the type definition, rather than outputting the data held by an object (instance) generated by an application program (runtime program) using the object's type definition when serializing that data. Here, the application program being developed may be a game program, a practical application program, or a development tool program.

[0025] This configuration allows for the output of asset data of any data structure (type), independent of the type definition of the object being serialized, thereby increasing the flexibility and convenience of program development. For example, even if the type definition is changed during the development of an application program (such as adding or deleting members, changing property names, or changing the data type of properties), or if the type representation differs depending on the program environment, the output asset data can be used universally. Furthermore, the asset data can include data that does not exist in the type of the object being serialized, or data of a different data type than the object being serialized.

[0026] [B. Hardware Configuration Example] The information processing device according to this embodiment may employ any hardware configuration. The information processing device may consist of a single computer running one or more programs. The computer may be stationary or portable. The information processing device may also be implemented using multiple computers. When using multiple computers, computing resources provided by a cloud environment on a network may be used. Therefore, in this specification, the term "information processing device" encompasses an "information processing system" using multiple computers or computing resources.

[0027] In the following explanation, for the sake of simplicity, an example configuration for realizing an information processing device using a single computer will be described; however, the technical scope of this application is not limited to configurations realized using a single computer.

[0028] Figure 1 is a schematic diagram showing an example of the hardware configuration of an information processing device 100 according to this embodiment. Referring to Figure 1, the information processing device 100 includes, as its main hardware components, one or more processors 102, memory 104, display 106, input unit 108, storage 110, and communication module 122. These hardware components are communicated together via a bus 124.

[0029] The processor 102 is an arithmetic unit that executes instructions according to the machine code loaded into memory 104, and is composed of, for example, a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit).

[0030] Memory 104 is a non-volatile memory device that temporarily stores machine code and various work data for the processor 102 to execute instructions, and is composed of, for example, DRAM (Dynamic Random Access Memory) or SRAM (Static Random Access Memory).

[0031] The display 106 displays video information generated by the processing performed by the processor 102, and is composed of a display device such as an LCD (Liquid Crystal Display) or an organic EL (ElectroLuminescent) display.

[0032] The input unit 108 is comprised of, for example, an input device such as a mouse or keyboard that accepts user input.

[0033] The storage device 110 is a non-volatile storage device that non-volatilely stores data generated and used in the information processing device 100, and is composed of, for example, an SSD (Solid State Drive) or an HDD (Hard Disk Drive). Typically, the storage device 110 stores a system program 112 including an OS (Operating System) and drivers, a development program 114 for developing application programs, and a project 116 including source code. The storage device 110 may also store an application program 118 (executable file) generated from the project 116.

[0034] Development program 114 is a program for developing application program 118, and provides the functions necessary for developing application program 118, such as creating and editing the source code of application program 118, compiling the source code, and linking the objects generated by compilation. Furthermore, development program 114 provides the functions and processes described later.

[0035] The development program 114 may be stored in the storage 110 during the manufacturing stage of the information processing device 100, or it may be provided as a download from a distribution server (not shown). Furthermore, a computer-readable storage medium (e.g., a USB (Universal Serial Bus) memory or memory card) (not shown) containing the development program 114 may be attached to the information processing device 100, and the development program 114 may be read from the attached computer-readable storage medium and installed in the storage 110.

[0036] For the sake of explanation, a single development program 114 is shown, but it may consist of multiple programs. For example, a program that provides a basic development environment may have modules or libraries added (add-ons) to implement the functions and processes described later. Therefore, the technical scope of the present invention includes not only a single development program that implements all of the functions and processes described later, but also one or more modules or libraries that implement the functions and processes described later.

[0037] The communication module 122 is a module for wireless communication with external devices and is composed of modules such as Ethernet (registered trademark) and wireless LAN.

[0038] Figure 1 illustrates a configuration in which the processor 102 executes programs (system program 112 and development program 114) to realize various processes (i.e., software implementation). However, some or all of these processes may be realized using hardwired circuits. Specifically, some or all of the functions and processes that the information processing device 100 should provide may be realized using processing circuitry, including an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array). The processing circuitry may also include the processor 102 and the memory 104. Therefore, it can be said that the functions and processes that the information processing device 100 should provide are realized by the processor 102 and the memory 104, and / or by processing circuitry, including hardwired circuits such as an ASIC or FPGA.

[0039] [C. Serialization and Deserialization] Next, we will explain serialization and deserialization.

[0040] Serialization is the process of writing (persisting) data managed by a program (usually located in memory) to storage or another location. In the following explanation, persisted data and data intended to be persisted will be referred to as "asset data."

[0041] Deserialization is the process of reading data (asset data) that has been persistently stored on storage or other locations into memory so that it can be processed by a program. Note that asset data may be stored not only on storage, but also in ROM (Read Only Memory) or on a server on a network.

[0042] This section describes an example of data structures that a program generates and manages in relation to serialization and deserialization.

[0043] Figure 2 shows an example of types and objects generated based on those types. Figure 2 also shows an example of code following C++.

[0044] Figure 2(A) shows an example of type definition code. A type represents a data structure used in a program. Figure 2(A) shows an example of the MyData type defined as a structure (indicated by 10). In this example code, the MyData type is defined to include, as members, a property value1 (indicated by 11) that holds integer data and a property distance (indicated by 12) that holds floating-point data.

[0045] Thus, a type definition can include definitions of the data structures and behaviors (data types of properties) that the program handles.

[0046] Figure 2(B) shows an example of code that creates an object from the type defined in Figure 2(A). An object is a data entity that holds a specific value. The value (data) held by the object will be placed in memory.

[0047] Figure 2(B) shows an example of code that creates a MyData object, myData1 (sign 20), and assigns it a specific value. The object myData1 holds "10" as the value of property value1 (sign 21) and "10.f" as the property distance (sign 22). Note that ".f" is a representation of a floating-point number.

[0048] Figure 2(C) shows an example of how the values ​​(data) held by the object shown in Figure 2(B) are arranged in memory (binary representation) (reference numeral 25). As shown in Figure 2(C), the values ​​of property value1 and property distance are simply arranged contiguously in memory.

[0049] As shown in Figure 2(C), if the data of an object placed in memory is saved as is, problems may arise in subsequent data handling. For example, the data in memory consists only of values ​​arranged according to the order of the defined properties. Therefore, if, for example, a property is added, it becomes impossible to properly associate the changed type with the values ​​contained in the data.

[0050] Furthermore, even values ​​of the same data type may have different binary representations depending on the operating system, processor architecture, programming language, and version of the programming language. Therefore, even if a binary representation generated in a specific environment is saved as is, it may not be read correctly in a different environment.

[0051] To address the problems mentioned above, a method of serializing in a general-purpose format (for example, JSON format) is used.

[0052] Figure 3 shows an example of asset data 300 generated by serialization. As an example, Figure 3 shows asset data 300 in JSON format. In JSON format, key-value pairs are written separated by colons.

[0053] In the example shown in Figure 3, asset data 300 includes, as properties, a pair of name "value1" and a value, and a pair of name "distance" and a value. In the following description, "value1" and "distance" in asset data 300 will be referred to as property names, and their corresponding values ​​will be referred to as property values.

[0054] The asset data 300 generated by serialization may be in JSON format, or, for example, XML format using tags. Furthermore, any other arbitrary format may be used.

[0055] By generating asset data 300 consisting of name-value pairs as shown in Figure 3, the data can be handled in a general manner. Furthermore, by adopting general-purpose formats such as JSON or XML, it is possible to use generally available libraries. This means that the same asset data 300 can be read and used in programs regardless of the environment.

[0056] Furthermore, since processing can be done in units of name-value pairs, asset data 300 can be used. For example, if there is no property corresponding to the changed type, you can simply skip loading the data contained in asset data 300.

[0057] The information processing device 100 according to this embodiment provides a mechanism for more easily utilizing asset data 300 as shown in Figure 3.

[0058] [D. Support for serialization and deserialization] Next, the functions and processes of the information processing device 100 according to this embodiment for supporting serialization and deserialization will be described.

[0059] The information processing device 100 according to this embodiment supports the serialization and deserialization of programs written in a statically typed language (e.g., C++). In other words, the type of programming language is not limited as long as it is a statically typed language.

[0060] In statically typed languages, the types of objects generated by program execution are defined in the source code beforehand. Furthermore, functions are assumed to process only objects of predetermined types. Therefore, it is difficult to perform general-purpose serialization using functions. However, some dynamically typed languages ​​have features implemented to facilitate object serialization.

[0061] In this embodiment, by adding a predetermined description to the source code of the application program 118, code for realizing serialization and deserialization, which are characteristic of this embodiment, is automatically generated. For the sake of explanation, this predetermined description that is added will be referred to as the "serialization definition description," and the automatically generated code will be referred to as the "additional code." The user (the developer of the application program 118) creates the source code (source code 160 shown in Figure 5, etc., described later) by operating an editor or the like. For the sake of convenience, the source code created by this developer will be referred to as the "original source code" to distinguish it from the additional code.

[0062] The additional code is executed as a process (serialization) that holds the data of the target object in the application program 118. The additional code may also be executed as a process (deserialization) that holds the target value as the value of a member variable of the target object in the application program 118.

[0063] The serialization definition description defines the content of serialization (and deserialization). This description specifies the type (definition) of the objects in the application program 118 that are to be serialized. In this embodiment, by specifying the type to be serialized from the types defined in the source code of the application program 118, objects generated with the specified type become subject to serialization (in the following description, the type specified as subject to serialization is referred to as the "serialization target type"). In this embodiment, if there are multiple objects (instances) generated using the serialization target type, all of these objects become subject to serialization. The serialization definition description is written by the user (the developer of the application program 118) within the source code of the application program 118.

[0064] In one example, the serialization definition description includes the following (1) to (4): (1) A description that specifies the type to be serialized (hereinafter referred to as "type specification description"). A type specification specifies the type of object to be stored. You can specify the name of the object type to be serialized as the type specification, or you can specify that type to be serialized by placing a serialization definition inside (or nearby) the type definition to be serialized.

[0065] (2) Descriptions that specify functions for serialization and deserialization (hereinafter referred to as "function specification descriptions") As a function specification, you may specify a member function of the type to be serialized, or you may specify any other function. In this embodiment, you specify a function to be used for serialization (hereinafter, the description specifying this function will be referred to as the "serialization function specification") and a function to be used for deserialization (hereinafter, the description specifying this function will be referred to as the "deserialization function specification").

[0066] The serialization function specification specifies a function to retrieve a value, and / or an optional variable. The specified function is one that retrieves the value held in the asset data's properties. The specified function may, but is not limited to, a function that simply returns the property value of the object being serialized; any function is acceptable. It may also return a value resulting from some operation using the property value of the object being serialized, or it may not use the property value of the object being serialized at all (e.g., a constant value, a string, the property value of a member of another type, or the result of an operation using such a value).

[0067] Thus, the function specified in the serialization function specification may be a function that retrieves the value of the property of the object to be serialized (as is), or it may be a function that retrieves the result of a predetermined operation performed using the value of the property of the object to be serialized. Furthermore, the function specified in the serialization function specification may be a function that retrieves a predetermined constant.

[0068] The deserialization function specification also specifies a function. The function specified in the deserialization function specification is a function that sets the property values ​​of an object in application program 118 using the property values ​​of the asset data. This function may be a function that sets the property values ​​of the asset data directly as the object values ​​of application program 118, but is not limited to this, and any function is acceptable. It may also be a function that sets the value of an object in application program 118 as the result of some calculation using the property values ​​of the asset data, or it may not use the property values ​​of the asset data at all (constant values, strings, property values ​​of other asset data, or calculation results using them, etc.).

[0069] Thus, the function specified in the deserialization function specification may be a function that retrieves the value of the asset data's property (as is), or a function that retrieves the result of a predetermined operation performed using the asset data's property value. Furthermore, the function specified in the deserialization function specification may be a function that retrieves a predetermined constant.

[0070] (3) A description that specifies the property name in the asset data (hereinafter referred to as "name specification description") The naming specification specifies the data name, which is the property name. Note that the property name specified in the naming specification is also the property name in the intermediate object, as described later.

[0071] (4) A description that specifies the data type of a property in the asset data (hereinafter referred to as the "data type specification description"). Furthermore, the data type specified in the data type specification is also the data type of the property in the intermediate object, which will be discussed later.

[0072] In this embodiment, the data is stored as an intermediate object before being stored as asset data, and then this intermediate object is serialized and stored as asset data. In this case, the parts described as "asset data" above should be understood as "intermediate object." That is, the intermediate object may be saved as asset data.

[0073] When application program 118 is executed, the processing described in the additional code is executed, making it possible to separate the type definition of the object to be serialized in the original source code from the data structure in the asset data.

[0074] For example, in the serialization function specification, specify a function that outputs the value (the value itself) of a property (named "Property A") that is a member of an object in the application program 118, and in the name specification, specify a name different from the name of Property A (for example, "Property B"), then the value of the property of the object in the application program 118 (the value of "Property A") can be saved as asset data (or an intermediate object, hereafter the same) with a different name ("Property B").

[0075] Conversely, by specifying a function in the deserialization function specification that sets the value of the asset data's property directly to the value of "Property A" of the application program 118 object, and specifying "Property B" in the name specification, it is possible to deserialize the asset data with a different name from the asset data's property name when reading it.

[0076] Furthermore, by specifying a data type (e.g., string type) that is different from the data type of "Property A" (e.g., int type) in the data type specification description, the value of the object property of application program 118 can be saved to asset data in a different data type.

[0077] Furthermore, by specifying a function in the serialization function specification that outputs a value obtained by performing some calculation using the value of property A of the object of the application program 118, it is possible to save the calculated value, rather than the value of the property of the object of the application program 118 itself, to the asset data.

[0078] Furthermore, by specifying a function in the serialization function specification that outputs data unrelated to the members of the object of the application program 118, it is possible to save arbitrary data that does not exist in the object of the application program 118 as asset data.

[0079] In this embodiment, functions for serialization and deserialization are specified. Since arbitrary code can be written within these functions, the degree of freedom of the values ​​held by the asset data properties can be increased during serialization, and the degree of freedom of the values ​​held by the application program properties can be increased during deserialization.

[0080] However, for both serialization and deserialization, you may specify variables (or their names) or constants (or their names) instead of functions. In that case, the value held by the asset data's properties will be the value of that variable or constant (serialized), and the value held by the application program's properties will be the value of that variable or constant (deserialized). These variables and constants may be member variables of the object being serialized, or they may be external variables or external constants.

[0081] In this embodiment, when specifying the object to be serialized, the type of the original source code is specified. In this case, all objects generated with the specified type will be subject to serialization, but it is also possible to specify only some of the objects to be serialized.

[0082] Specific examples of serialization definition descriptions will be discussed later. In this specification, the term "procedure" means a description of how to perform a specific process in a program. A "procedure" includes, for example, functions, member functions, methods, directives, subroutines, and subprograms. In the following description, functions or member functions will be used primarily as examples of "procedures."

[0083] As described later, the source code of application program 118 (included in project 116) written by the developer of application program 118 is supplemented with additional code before application program 118 is generated (built). The addition of this code automatically generates intermediate objects (objects intended to be saved as asset data; details will be described later) for writing (serializing) and reading (deserializing) asset data 300 during the execution of application program 118.

[0084] Figure 4 is a diagram illustrating an example of the execution state of an application program 118 generated by an information processing device 100 according to this embodiment. Note that the application program 118 is generated from project 116, which includes additional code.

[0085] Referring to Figure 4, during the execution of the application program 118, in addition to any object 120 in the original source code (which may be referred to as the "original object" in the following description), an intermediate object 130 is generated by the execution of the processing described in the additional code. The intermediate object 130 can be called at any time to perform the processing necessary for serialization and deserialization.

[0086] The data structure (type) of the intermediate object 130 can be defined arbitrarily. The data held by the intermediate object 130 can also be edited arbitrarily.

[0087] More specifically, the additional code includes the following (1) to (5): (1) Type definition(s) of intermediate object 130 According to the code in (1), an intermediate object 130 is created. More specifically, (1) is the code that defines the type of the intermediate object 130 so that it has the following properties as members.

[0088] • Property name: The name specified in the naming specification of the serialization definition description. • Data type: The data type specified in the type specification of the serialization definition description. Thus, (1) is code that defines a type having member variables of the specified property names (data names) based on the property names (data names) specified in the naming specification. Also, (1) is code that defines a type having member variables of the data types specified in the type specification. In the code of (1), the type of the intermediate object 130 may be defined independently of the type definition in the corresponding source code 160.

[0089] If multiple serialization definition descriptions exist for a single type, the above members will be generated for each, resulting in the intermediate object 130 having a structure with multiple properties.

[0090] The type name of the intermediate object 130 is automatically set, for example, by adding an auxiliary name to the type to be serialized (the name is arbitrary, but for example, if the type name to be serialized is "MyData", the type name of the intermediate object 130 may be automatically determined to be "MyData_IntermediateObject").

[0091] Furthermore, the intermediate object 130 implements member functions such as the following: (A) LoadTo function: A function that calls the "deserialization code" described later. (B) ExtractFrom function: A function that calls the "serialization code" described later. (C)CreateDiff function: A function that generates a new intermediate object 130 that has only the difference between the properties of the specified intermediate object 130 and the properties of the object itself. (D) ApplyDiff function: A function that applies to the object itself an intermediate object 130 that has only the properties of the difference generated by the CreateDiff function shown in (C). (E)Clone function: A function that duplicates the object itself and creates a new intermediate object 130. (F) Exclude function: A function that excludes a specified property from the properties of the object itself. (G) ExcludeAll function: A function that excludes all properties of the object itself. (H)Include function: A function that sets a specified property from the properties of the object itself as the target of processing. (I) Sanitize function: A function that checks whether the value of the object's properties satisfies the constraints contained in the corresponding serialization definition description (for example, whether it is within the specified range). (J)GetPath function: A function that retrieves the path in the property tree of the current object. (K)GetTypeId function: A function that retrieves a hash value indicating the type of the data held by the object. (L)GetStringTypeId function: A function that retrieves the name (string) of the type corresponding to the data held by the object itself. (M)HasProperty function: A function that determines whether the object itself has the specified property. (N)GetProperty function: A function that retrieves the value of a specified property held by the object itself. (O)GetDataFormatVersion function: A function to retrieve the version of the data held by the object itself. The type of intermediate object 130 may also be defined to inherit a common type definition. In this case, the type definition of intermediate object 130 included in the additional code defines the type to inherit a common type that has at least one member function. For example, if the common type definition has a generic member function, then any intermediate object 130 can have that member function. All or some of the functions shown in (A) to (O) above may be member functions of the common type definition.

[0092] If there are multiple serialization target types, the type of intermediate object 130 is generated separately for each serialization target type.

[0093] In this way, the information processing device 100 generates type definitions for intermediate objects 130 from the source code 160 of the application program 118. The type definitions for intermediate objects 130 correspond to type definitions for saving data corresponding to objects generated based on serializable type definitions contained in the source code 160 as asset data.

[0094] Alternatively, the type definition of the intermediate object 130 may be extracted (as is) from the type definitions included in the source code 160 of the application program 118.

[0095] (2) Code describing a function to create (instantize) intermediate object 130 The code in (2) is code that executes the process of generating intermediate objects based on the types (type definitions) defined in the code in (1). In other words, the code in (2) is for generating intermediate objects 130 for asset data, corresponding to each of the objects of the application program 118 that are generated based on the type definitions in the source code 160 of the application program 118. The code in (2) also executes the process of creating an intermediate object when the process of storing the data of the target object (serialization) is performed.

[0096] If there are multiple objects (instances) created using the serialization target type, an intermediate object 130 will be created individually for each of them.

[0097] The intermediate object 130 is actually created when this code is executed. For example, when serializing an object for the first time, this code is executed and the corresponding intermediate object 130 is created. Alternatively, the code could be configured to create the corresponding intermediate object 130 when the object to be serialized is created.

[0098] (3) Code describing a function (hereinafter referred to as "serialization code"; a concrete example is shown as DEFINE_SERIALIZE_VALUE() in Figure 8(B)) (interface 131) that reads the output value of the function specified in the serialization function specification description into the property of the name specified in the name specification description. The serialization code included in the additional code is for the purpose of storing the value obtained by the function specified in the serialization function specification description or the value of the variable specified in the serialization function specification description as data corresponding to the target object, with the data name (property name) specified in the name specification description. In this case, the serialization code is the code that performs the process of storing the value obtained by the function or the value of the specified variable as the value of a member variable of the intermediate object 130 generated by the code in (2). Alternatively, the serialization code may also be for the purpose of storing the value obtained by a pre-specified function or a pre-specified value in the intermediate object 130.

[0099] The data corresponding to the target object may be asset data corresponding to the target object, or it may be data that is intended to be held as asset data (the value of the corresponding property of the intermediate object).

[0100] (4) Code describing a function that passes the value of the property of the name specified in the name specification description to the function specified in the deserialization function specification description (hereinafter referred to as "deserialization code"; a concrete example is shown as DEFINE_DESERIALIZE_VALUE() in Figure 8(B)) (Interface 132) The deserialization code included in the additional code is for the purpose of passing the values ​​of data names (property names) specified in the naming description held by the asset data to the function specified in the deserialization function description. For example, the function specified in the deserialization function description sets the value of the corresponding property of the object of the serialization target type using the value of the property specified in the (passed) naming description. Alternatively, the deserialization code may also be for the purpose of passing the values ​​of properties held by the intermediate object 130 to a pre-specified function.

[0101] (5) Code that executes the process of registering the pointer to the generated function. By automatically adding the additional code consisting of the above-mentioned code sets to the original source code, the type of intermediate object 130 is defined (as in (1) above), intermediate object 130 is created (as in (2) above), code is added to set the values ​​of the properties of intermediate object 130 using an arbitrary function (a function specified by the serialization function specification) (as in (3) above), and code is added to pass the values ​​of the properties of intermediate object 130 to an arbitrary function (a function specified by the deserialization function specification) (as in (4) above).

[0102] The additional code may also include the following (6) to (8). (6) Write the values ​​held by the intermediate object 130 to the asset data 300 (code describing the function (interface 133) for serialization) (7) Code describing a function (interface 134) for reading (deserializing) asset data 300 into intermediate object 130. Note that functions (6) and (7) may also be implemented as member functions of intermediate object 130.

[0103] As an example of (6), the GenerateJSON function may be implemented in the intermediate object 130. The GenerateJSON function may be called to generate pairs of property names (variable names) and their corresponding values ​​held by the intermediate object 130 as data in JSON format.

[0104] Alternatively, the GenerateXML function may be implemented in the intermediate object 130. When the GenerateXML function is called, pairs of property names (variable names) and their corresponding values ​​held by the intermediate object 130 may be generated as XML data.

[0105] The output format for the names and values ​​of the properties held by the intermediate object 130 may be a general-purpose format such as JSON or XML.

[0106] Thus, (6) is for executing a process that outputs the property values ​​of the intermediate object 130 in a predetermined format for each type of intermediate object 130. Note that the type definition of the intermediate object 130 (the code in (1) above) may also include code for calling such a process.

[0107] As an example of (7), the ExtractJSON function may be implemented in the intermediate object 130. In this case, an empty intermediate object 130 is created (instantized), and the ExtractJSON function is called with the asset data 300 to be read specified, so that the intermediate object 130 is loaded with pairs of property names (variable names) and their corresponding values ​​described in the asset data 300.

[0108] Alternatively, a Deserialize function may be provided to read data from asset data 300. The Deserialize function is called with the asset data 300 to be read and a type ID indicating the type of the intermediate object 130 that will read the asset data 300. The Deserialize function parses the specified asset data 300 to be read and reads pairs of property names (variable names) and their corresponding values ​​described in the asset data 300. Subsequently, an intermediate object 130 corresponding to the specified type ID is created (instantiated), and the data read from asset data 300 is set in the created intermediate object 130.

[0109] Furthermore, data exchange (serialization (export) and deserialization (reading)) between the intermediate object 130 and the asset data 300 can also be performed using any library.

[0110] If the code in (6) and (7) is not automatically generated as additional code, the developer of application program 118 will be responsible for writing this code.

[0111] Furthermore, depending on the application program 118, only serialization or deserialization may be required, or only a part of serialization or deserialization may be required.

[0112] Therefore, additional code may be generated to implement at least one of the interfaces 131 and 132 shown in Figure 4.

[0113] (8) Code that performs the process of maintaining the history of intermediate object 130 The intermediate object 130 may be able to hold not only the current value but also one or more past values ​​as property values ​​(data). For example, a function for performing Undo / Redo may be implemented as a member function of the intermediate object 130.

[0114] Furthermore, the information processing device 100 may be configured to automatically generate a schema file in addition to the additional code. The schema file describes the data structure of the type definition of the intermediate object 130 (or asset data 300). In other words, the schema file describes the data structure of the type definition for saving as asset data. Details of the schema file will be described later.

[0115] [E. Functional Configuration and Processing Procedures] Next, the functional configuration and processing procedure of the information processing device 100 according to this embodiment will be described.

[0116] Figure 5 is a schematic diagram showing an example of the functional configuration of an information processing device 100 according to this embodiment. Referring to Figure 5, the information processing device 100 includes an update module 140, a builder 142, and an additional code generation module 150. These functional modules may be realized by the processor 102 of the information processing device 100 executing a development program 114.

[0117] The user (developer of application program 118) uses an editor (not shown) or similar tool to create a project 116 that includes source code 160, a list of files 162 for the source code 160 to be built, and configuration information 164.

[0118] The additional code generation module 150 generates additional code 170 from project 116. In addition to additional code 170, the additional code generation module 150 may also generate a schema file 180. More specifically, the additional code generation module 150 includes the analysis module 152 and the additional module 154.

[0119] The analysis module 152 analyzes the source code 160 included in project 116 to discover the serialization definition description and constructs information for generating additional code 170 based on it. In this way, the analysis module 152 identifies the type definitions (type specification descriptions included in the serialization definition description) within the source code 160 of application program 118. More specifically, the analysis module 152 extracts from the source code 160 of application program 118 a serialization definition description (an example of a predetermined description) that includes a naming specification description (an example of a first description) that specifies the data name (property name) and a serialization function specification description (an example of a second description) that specifies a function or variable for obtaining the value. Then, the analysis module 152 generates the type definition of the intermediate object 130 based on the serialization definition description included in the source code 160.

[0120] The additional module 154 generates additional code 170 based on the extracted serialization definition description and adds the generated additional code 170 to the source code 160 of the application program 118.

[0121] Additionally, the additional module 154 generates a schema file 180. Configuration information 164 includes specifying the storage location for the additional code 170 and the storage location for the schema file 180 that is generated together with the additional code 170. The generated additional code 170 and schema file 180 are output to the specified storage locations.

[0122] The update module 140 adds the additional code 170 generated by the additional code generation module 150 to the source code 160 of project 116, and also adds the file name of the additional code 170 to the file list 162, updating the file list 162A.

[0123] Builder 142 compiles source code 160 and additional code 170 to generate application program 118. Builder 142 generates application program 118 (executable file) from project 116A updated by update module 140. More specifically, builder 142 includes analysis module 144, compiler 146, and linker 148.

[0124] The analysis module 144 analyzes the source code 160 and additional code 170 included in project 116A, which has been updated by the update module 140. At this time, the process of expanding macros written in source code 160 and additional code 170 is executed, but the macro definitions corresponding to the serialization definition descriptions in source code 160 are all set to be expanded to empty strings (null). As a result, the analysis module 144 replaces all serialization definition descriptions in source code 160 with empty strings.

[0125] The compiler 146 compiles the source code 160 and the additional code 170 based on the analysis results of the analysis module 152 to generate object code.

[0126] Linker 148 links the generated object code to produce application program 118 (executable file).

[0127] In the example above, the analysis module generated information for generating additional code 170, and then the additional module generated the additional code based on that information. However, the additional code could also be generated directly when analyzing the serialization definition description.

[0128] Figure 6 is a flowchart showing an example of the build process procedure for the information processing device 100 according to this embodiment.

[0129] Referring to Figure 6, when the information processing device 100 receives a build request for a library or application program 118 (YES in step S2), it first executes a process that is specified to be executed before the build as a pre-build. Here, it is assumed that the process to be executed as a pre-build is a process that generates additional code 170.

[0130] The information processing device 100 obtains the information necessary for generating the additional code 170 (for example, (1) a list of files of the source code 160 to be built, (2) the storage location of the additional code 170, and (3) the storage location of the schema file 180 that will be generated together with the additional code 170) (step S4), and executes the additional code 170 generation process as described later (step S6).

[0131] The information processing device 100 adds the generated additional code 170 to the source code to be built, generates a list of new source code files to be built (step S8), and compiles the target source code (step S10). Then, the information processing device 100 generates an executable file (application program 118) by linking the object code generated by the compilation (step S12). This completes the process.

[0132] Figure 7 is a flowchart showing an example of the processing procedure for generating the additional code 170 shown in Figure 6 (step S6). Referring to Figure 7, the information processing device 100 (analysis module 152 shown in Figure 5) analyzes (lexical analysis) the source code 160 to be built (step S60), and constructs information for generating additional code based on the information collected by the analysis (step S61).

[0133] More specifically, the information processing device 100 extracts a serialization definition description from the source code 160 during lexical analysis, which includes the names of properties included in the asset data 300 and the names of functions for obtaining the values ​​of those properties. Based on the results of this analysis of the source code 160, the information processing device 100 recognizes the serialization target types among the types defined in the original source code 160 and generates additional code to create the corresponding intermediate object 130. Details of the additional code are as described above.

[0134] Next, the information processing device 100 (additional module 154 shown in Figure 5) generates a string for generating additional code 170 based on the constructed additional code generation information (step S62), and also generates a string for generating schema file 180 (step S63).

[0135] More specifically, in step S62, the information processing device 100 extracts a serialization definition description (an example of a predetermined description) from the source code 160 of the application program 118, which includes a name specification description (an example of a first description) that specifies a data name (property name) and a serialization function specification description (an example of a second description) that specifies a function or variable for obtaining a value.

[0136] Finally, the information processing device 100 (additional module 154 shown in Figure 5) generates additional code 170 from a string for generating additional code 170, outputs it to a file (step S64), and outputs a list of the output files of additional code 170 (step S65). In this way, the information processing device 100 generates additional code 170 that is executed as a process (serialization) to hold the data of the target object of the application program 118 based on the serialization definition description, and adds it to the source code 160 of the application program 118.

[0137] In addition, the information processing device 100 outputs the schema file 180 from the string used to generate the schema file 180 (step S66). The schema file 180 contains information that identifies the data structure of the asset data 300, which includes one or more properties. The process then returns.

[0138] [F. Serialization Definition Description and Additional Code] Next, examples of serialization definition descriptions and additional code in the information processing device 100 according to this embodiment will be described. Note that the user (developer of the application program 118) can also edit the automatically generated additional code 170 as needed.

[0139] (f1: An example of storing data in asset data with the same property name as the property name in the application program's type definition) Figure 8 shows an example of a serialization definition description and the additional code 170 generated based on it.

[0140] Referring to Figure 8(A), source code 160 created by the developer includes type definition 40A for type MyData. Type definition 40A includes a definition description 401 for the integer type property value1, which follows the same syntax as usual.

[0141] A feature of this embodiment is that a serialization definition description 410 is added to the type definition 40A. In the example shown in Figure 8(A), the designation that a type is to be serialized is done by placing the serialization definition description 410 inside the type definition 40A of the type to be serialized. That is, by placing the serialization definition description 410 inside the type definition 40A of the MyData type, it is designated that the MyData type is to be serialized. Therefore, the serialization definition description 42 implicitly includes a type specification description.

[0142] For example, serialization definition description 410 includes the macro name 411 "BIND_VALUE". Macro name 411 is a string that indicates that it will be replaced by an object-like macro.

[0143] The serialization definition description 410 includes, as arguments, a property name 412 (an example of a "name specification description") that specifies the name of the property in the asset data 300, a data type definition 413 (an example of a "data type specification description") that specifies the data type of that property, a function name 414 (an example of a "serialization function specification description") that specifies the function used for serialization, and a function name 415 (an example of a "deserialization function specification description") that specifies the function used for deserialization.

[0144] Type definition 40A includes a function definition 404 that defines a function corresponding to the function name 414 specified as an argument to serialization definition description 410, and a function definition 405 that defines a function corresponding to the function name 415 specified as an argument to serialization definition description 42.

[0145] Figure 8(B) shows an example of additional code 170 that is automatically generated based on type definition 40A, which includes the serialization definition description 42 shown in Figure 8(A).

[0146] The additional code 170 shown in Figure 8(B) includes serialization code 50A which defines a function that reads the output value of a function specified by function name 414, which is an example of a serialization function specification description, into a property with the name specified by property name 412, which is an example of a name specification description.

[0147] The serialization code 50A includes, as arguments, a type name 416 that specifies the type to be serialized, a property name 412, and a data type definition 413.

[0148] Furthermore, the additional code 170 shown in Figure 8(B) includes deserialization code 52A that defines a function to be passed to the function specified by function name 415, which is an example of a deserialization function specification description.

[0149] The deserialization code 52A includes, as arguments, a type name 416 specifying the type to be serialized, a property name 412, and a data type definition 413.

[0150] When the application program 118, generated from project 116A which includes the original source code 160 and the additional code 170 shown in Figure 8(B), is executed, functions such as setting the property values ​​of the intermediate object 130 are implemented.

[0151] Figure 9 schematically shows the software configuration implemented by the additional code 170 shown in Figure 8(B). When the application program 118, which includes the additional code 170, is executed, an intermediate object 130 is created (instantized). The intermediate object 130 has the property of property name 412 included in the serialization definition description 42.

[0152] Intermediate object 130 implements a function used for serialization, specified by function name 414, and a function used for deserialization, specified by function name 415. Each function may be implemented in a way that makes them explicitly readable, or it may implement a separate procedure that encapsulates each function (for example, member functions as shown in Figures 16 and 17).

[0153] (f2: An example of storing data in asset data with a property name different from the property name in the application program's type definition) Figure 8 shows an example in which data is stored in asset data 300 with the same property names as the property names in the type definition of application program 118. However, in this embodiment, since the data structure of asset data 300 is independent of the type definition of application program 118, it is also possible to store data in asset data 300 with different property names.

[0154] Figure 10 shows another example of a serialization definition description and the additional code 170 generated based thereon. Figure 10 shows an example of code to implement the process of storing the value of the property m_Distance of an object in the application program 118 as the property Distance in the asset data 300.

[0155] Referring to Figure 10(A), the source code 160 created by the developer includes a type definition 40B for the MyData type. The type definition 40B includes a definition description 421 for the floating-point property m_Distance, which follows the same syntax as usual. The property m_Distance is a member of the object produced by the running application program 118.

[0156] In type definition 40B, serialization definition description 430 is added, specifying that the MyData type is a type to be serialized.

[0157] For example, serialization definition description 430 includes the macro name 431 "BIND_VALUE". Serialization definition description 430 also includes, as arguments, a property name 432, a data type definition 433, a function name 434 specifying the function used for serialization, and a function name 435 specifying the function used for deserialization.

[0158] In the example shown in Figure 10(A), "distance" is specified as the property name 432. As a result, asset data 300 with the property distance is generated. At this time, any name independent of the target property held by the running application program 118 can be specified.

[0159] Type definition 40B includes a function definition 424 that defines a function corresponding to the function name 434 specified as an argument to serialization definition description 430, and a function definition 425 that defines a function corresponding to the function name 435 specified as an argument to serialization definition description 430.

[0160] Function definition 424 defines a function that outputs the value of the m_Distance property of an object in application program 118. Function definition 425 defines a function that sets the value specified as an argument to the m_Distance property of an object in application program 118.

[0161] Figure 10(B) shows an example of additional code 170 that is automatically generated based on type definition 40B, which includes the serialization definition description 430 shown in Figure 10(A).

[0162] The additional code 170 shown in Figure 10(B) includes serialization code 50B which defines a function that reads the output value of the function specified by function name 434 into a property specified by property name 432. The serialization code 50B includes, as arguments, a type name 436 that specifies the type to be serialized, a property name 432, and a data type definition 433.

[0163] Furthermore, the additional code 170 shown in Figure 10(B) includes deserialization code 52B that defines a function to be passed to the function specified by function name 435. Deserialization code 52B includes, as arguments, a type name 436 that specifies the type to be serialized, a property name 432, and a data type definition 433.

[0164] The "propertyValue" in serialization code 50B and deserialization code 52B is a formal parameter name that refers to a "reference" to the type defined in data type definition 433 (in this example, the float type).

[0165] Thus, in this embodiment, data can be stored in the asset data 300 with an arbitrary property name independent of the property name of the object in the application program 118. This process offers the following advantages.

[0166] This solution addresses the need to use property names (variable names) with arbitrary prefixes (for example, "m_" to indicate a member variable) according to source code creation conventions, but to avoid adding prefixes like "m_" to the asset data 300 output by serialization.

[0167] This solution satisfies the need to maintain the original property names in the exported asset data 300, even though the meaning of a property changed during the development of application program 118, and therefore the property name (variable name) was changed in source code 160.

[0168] The member variable names of objects generated by the runtime program are assigned names that represent the data structure, but it is possible to satisfy the need to not expose (conceal) the names representing the data structure on the asset data 300 side. For example, the runtime program uses a member variable named "childElementLinkedList", but the property name output as asset data 300 can be set to "children".

[0169] Even if the specific data structure changes during the development of application program 118, the property names included in asset data 300 can be maintained as they are.

[0170] (f3: Example of storing asset data in a data type different from the data type of the application program) Figure 8 shows an example in which data is stored in asset data 300 using the same data type as the data type defined in application program 118. However, in this embodiment, since the data structure of asset data 300 is independent of the type definition of application program 118, it is also possible to store data in asset data 300 using different data types.

[0171] Figure 11 shows yet another example of a serialization definition description and the additional code 170 generated based thereon. Figure 11 shows an example of code that implements the process of storing the value of the property m_TagHash, which has a hash value (integer type) in an object of the application program 118, as a property Tag, which has a string (string type) in the asset data 300.

[0172] Referring to Figure 11(A), the source code 160 created by the developer includes a type definition 40C for the MyData type. The type definition 40C includes a definition description 441 for the property m_TagHash of a 32-bit unsigned integer type, which follows the usual syntax. The property m_TagHash is a member of the object produced by the running application program 118.

[0173] In type definition 40C, serialization definition description 450 is added, specifying that the MyData type is a type to be serialized.

[0174] For example, serialization definition description 450 includes the macro name 451 "BIND_VALUE". Serialization definition description 450 also includes, as arguments, a property name 452, a data type definition 453, a function name 454 specifying the function used for serialization, and a function name 455 specifying the function used for deserialization.

[0175] In the example shown in Figure 11(A), "Tag" is specified as the property name 452, and "string" (string type) is specified as the data type definition 453. As a result, asset data 300 with a string type property Tag is generated. In this way, any data type independent of the target property held by the running application program 118 can be specified.

[0176] Type definition 40C includes function definition 444, which defines a function corresponding to function name 454 specified as an argument to serialization definition description 450, and function definition 445, which defines a function corresponding to function name 455 specified as an argument to serialization definition description 450.

[0177] Function definition 444 defines a function that converts the hash value of the property m_TagHash of an object in application program 118 into a string and outputs it. The function GetTagString is defined in code that is not shown. Function definition 445 defines a function that converts a value (string) contained in the asset data specified as an argument into a hash value and sets it as the value of the property m_TagHash of an object in application program 118.

[0178] Figure 11(B) shows an example of additional code 170 that is automatically generated based on type definition 40C, which includes the serialization definition description 450 shown in Figure 11(A).

[0179] The additional code 170 shown in Figure 11(B) includes serialization code 50C which defines a function that reads the output value of the function specified by function name 454 into a property specified by property name 452. The serialization code 50C includes, as arguments, a type name 456 which specifies the type to be serialized, a property name 452, and a data type definition 453.

[0180] The serialization code 50C of the additional code 170 shown in Figure 11(B) is used to execute the process of storing the value obtained by the function specified in the serialization function specification description or the value of the variable specified in the serialization function specification description as data corresponding to the target object, in the data type specified in the type specification description.

[0181] Furthermore, the additional code 170 shown in Figure 11(B) includes deserialization code 52C that defines a function to be passed to the function specified by function name 455. Deserialization code 52C includes, as arguments, a type name 456 that specifies the type to be serialized, a property name 452, and a data type definition 453.

[0182] Thus, in this embodiment, data can be stored in the asset data 300 using any data type independent of the data type of the object properties of the application program 118. This process offers the following advantages.

[0183] For example, by pre-defining the correspondence between strings and hash values, the runtime program only stores the hash values ​​of the strings. By adopting this implementation, the information stored in the runtime program can be kept to a minimum, saving the amount of memory required. This is effective when the size of objects needs to be reduced due to hardware constraints, or when the string information itself is not necessary for processing.

[0184] Alternatively, in asset data 300, information can be stored as an encrypted binary sequence, while the runtime program stores the information as a decrypted string. By including the encrypted string in the asset data, the information held by the runtime program can be kept confidential. Furthermore, the data size can be reduced by converting long strings into binary data.

[0185] (f4: An example of storing data in asset data that is not held by the application program) In this embodiment, data not held by the application program 118 (runtime program) can also be stored in the asset data 300.

[0186] Figure 12 shows yet another example of a serialization definition description and the additional code 170 generated based on it. Figure 12 shows an example of code to implement the process of writing a hardcoded version (the value described in source code 160) to asset data 300.

[0187] Referring to Figure 12(A), the source code 160 created by the developer includes a type definition 40D for the MyData type. In type definition 40D, a serialization definition description 470 is added, specifying that the MyData type is a type to be serialized.

[0188] For example, serialization definition description 470 includes the macro name 471, "BIND_VALUE". Serialization definition description 470 also includes, as arguments, a property name 472, a data type definition 473, a function name 474 specifying the function used for serialization, and a function name 475 specifying the function used for deserialization.

[0189] In the example shown in Figure 12(A), the property name 472 is specified as "AssetDataVersion," and the data type definition 473 is specified as "int" (integer type).

[0190] Type definition 40D includes function definition 464, which defines a function corresponding to function name 474 specified as an argument to serialization definition description 470, and function definition 465, which defines a function corresponding to function name 475 specified as an argument to serialization definition description 470.

[0191] Function definition 464 defines a function that outputs "2", which is written in source code 160.

[0192] Function definition 445 defines a function that evaluates the value specified as an argument. More specifically, it defines that if the value read from asset data 300 (the value indicating the version) is "1" and not "2", the function EnableOldAssetBehavior is called. The function EnableOldAssetBehavior is defined in code that is not shown and typically performs processing to switch the behavior of the runtime program.

[0193] Figure 12(B) shows an example of additional code 170 that is automatically generated based on type definition 40D, which includes the serialization definition description 470 shown in Figure 12(A).

[0194] The additional code 170 shown in Figure 12(B) includes serialization code 50D which defines a function that reads the output value of the function specified by function name 474 into a property specified by property name 472. The serialization code 50D includes, as arguments, a type name 476 which specifies the type to be serialized, a property name 472, and a data type definition 473.

[0195] Furthermore, the additional code 170 shown in Figure 12(B) includes deserialization code 52D that defines a function to be passed to the function specified by function name 475. Deserialization code 52D includes, as arguments, a type name 476 that specifies the type to be serialized, a property name 472, and a data type definition 473.

[0196] Thus, in this embodiment, even data not held by the application program 118 can be held in the asset data 300. This process offers the following advantages.

[0197] For example, as shown in Figure 12(A), by hardcoding values ​​into the source code 160, information that identifies when the asset data 300 was output (e.g., asset version, date, program version, etc.) can be embedded. Using such information, it is possible to identify old asset data 300 that do not need to be used in the runtime program.

[0198] Furthermore, in cases where there are multiple independent values ​​in the application program 118, it is possible to implement a process that combines these multiple values ​​into a single matrix or vector and writes them to the asset data 300.

[0199] (f5: Edit automatically generated additional code) The user (the developer of application program 118) can also edit the automatically generated additional code 170 as they see fit. An example of editing additional code 170 is described below.

[0200] Figure 13 shows an example of editing the automatically generated additional code 170. Figure 13 shows an example of converting between the data held by the runtime program and the data held by the asset data 300.

[0201] Figure 13(A) shows additional code 170, similar to that in Figure 10(B). Users can edit additional code 170 as they wish. Figure 13(B) shows an example of code that implements the process of doubling the value of the serializable property obtained from the runtime program and writing it to asset data 300, and the process of multiplying the value read from asset data 300 by 0.5 and setting it in the runtime program.

[0202] Specifically, in serialization code 50B, "* 2.0f" (description 501 for doubling the value) has been added. In other words, a process is defined to return a value that is double the value obtained from the MyData object to be serialized.

[0203] The deserialization code now includes "* 0.5f" (code 502 for multiplying the value by 0.5). This defines a process that returns the value read from asset data 300 multiplied by 0.5.

[0204] In this embodiment, the user (developer of application program 118) can arbitrarily edit the automatically generated additional code 170, making it easy to serialize the results of arbitrary calculations performed on data held by an object of the serialization target type, and to deserialize the results of arbitrary calculations performed on the values ​​of asset data 300.

[0205] (f6: Example of a serialization definition that explicitly includes a type specification) Figure 14 shows an example of a serialization definition that explicitly includes type specifications. Figure 14(A) shows an example of code for a type definition of an external library specified as the type to be serialized. The type definition 60 shown in Figure 14(A) defines an ExternalLibraryData type that includes an integer property dataType (sign 61) and a floating-point property floatValue (sign 62).

[0206] In the example shown in Figure 14(B), source code 160 includes serialization definition descriptions 63 and 64 that specify the ExternalLibraryData type as the type to be serialized.

[0207] For example, serialization definition descriptions 63 and 64 each contain the macro name "BIND_VALUE_EXTERNAL" 631 and 641, respectively.

[0208] Each of the serialization definition descriptions 63 and 64 includes, as arguments, property names 632 and 642 (an example of a "name specification description"), data type definitions 633 and 643 (an example of a "data type specification description"), function names 634 and 644 (an example of a "serialization function specification description") that specify the function used for serialization, and function names 635 and 645 (an example of a "deserialization function specification description") that specify the function used for deserialization.

[0209] Furthermore, each of the serialization definition descriptions 63 and 64 includes a type name 636, 646 (an example of a "type specification description") that specifies the type to be serialized.

[0210] In the example shown in Figure 14(B), each of the serialization definition descriptions 63 and 64 explicitly includes a description (type specification description) that specifies the type to be serialized. That is, each of the serialization definition descriptions 63 and 64 (an example of a given description) further includes a type specification description that specifies the type of object to be held as data. In this case, the additional module 154 (see Figure 5) generates additional code 170 for objects generated by the type specified by the type specification description, based on the type specification descriptions (e.g., type names 636 and 646) included in the extracted serialization definition description.

[0211] In this embodiment, instead of attaching a serialization definition description to the defined type and property itself, a serialization definition description is attached that specifies the name of the property included in the asset data 300, the data type definition of the property's value, a function for obtaining the property's value, and a function for setting the property's value.

[0212] Therefore, even objects of types defined in external libraries can be freely serialized and deserialized. For example, the above explanation showed an example of adding the serialization definition description as part of the type definition, but it is also possible to place the serialization definition description outside of the type definition.

[0213] Thus, the description specifying the type of object to be serialized does not necessarily need to be placed within the type definition. As a result, any object type can be specified as the target for serialization.

[0214] (f7: Handling of source code with serialization definition descriptions attached) Next, we will explain how to handle source code to which serialization definition descriptions have been added. As described above, in this embodiment, the types to be serialized and deserialized are identified by adding serialization definition descriptions that include macro names such as "BIND_VALUE" (see Figure 8(A), etc.) and "BIND_VALUE_EXTERNAL" (see Figure 14(B), etc.) to the source code.

[0215] Such serialization definition descriptions are handled differently in the process of generating additional code 170 and the build process for generating application program 118.

[0216] Figure 15 is a diagram illustrating how the serialization definition description is handled during the build process in the information processing device 100 according to this embodiment.

[0217] The type definition 40A of the MyData type shown in Figure 15(A) includes a definition description 401 for the integer property value1 and a definition description 481 for the floating-point property distance. The type definition 40A further includes serialization definition descriptions 410 and 490.

[0218] Serialization definition description 410 includes the macro name 411, "BIND_VALUE", and serialization definition description 490 includes the macro name 491, "BIND_VALUE".

[0219] The serialization definition description 410 includes the property name 412, the data type definition 413, the function name 414, and the function name 415 as arguments. The serialization definition description 490 includes the property name 492, the data type definition 493, the function name 494, and the function name 495 as arguments.

[0220] Figure 15(B) shows the state in which information for generating additional code 170 has been constructed based on the information collected by lexical analysis during the generation process of additional code 170 (corresponding to step S61 in Figure 7).

[0221] The type definition 40F shown in Figure 15(B) is obtained by replacing the serialization definition descriptions 410 and 490 in the type definition 40E shown in Figure 15(A) with codes 410A and 490A, respectively, to generate the additional code 170. More specifically, the analysis module 152 of the information processing device 100 generates the type definition 40F by replacing the macro names contained in the serialization definition descriptions 410 and 490.

[0222] The first line of code 410A and 490A is written using the attribute syntax "__attribute__(())", specifying the contents of the arguments of serialization definition descriptions 410 and 490 as attributes. The second line of code 410A and 490A defines the union data structure and defines its members.

[0223] The information processing device 100 generates an additional code 170 based on the descriptions of codes 410A and 490A.

[0224] Figure 15(C) shows an example of type definition 40G after macro processing (corresponding to step S10 in Figure 6) during the build process for generating application program 118. During macro processing at build time, all macro definitions corresponding to serialization definition descriptions are set to empty strings (null). Therefore, serialization definition descriptions 410 and 490 included in type definition 40E shown in Figure 15(A) are both replaced with empty strings before compilation. Serialization definition descriptions added in addition to type definitions are handled similarly.

[0225] In this way, the builder 142 (additional module 154) of the information processing device 100 interprets the serialization definition description contained in the source code 160 as invalid and then generates the application program 118. More specifically, the builder 142 (additional module 154) of the information processing device 100 replaces macro names with empty strings.

[0226] As a result, the serialization definition description written in the source code has virtually no effect on the build process for generating the application program 118. In this way, by treating the same source code differently during the generation process and compilation of the additional code 170, the additional code 170 can be automatically generated without substantially affecting the original source code.

[0227] A common method for automatically generating source code for serialization is to attach attributes to the type or variable itself. However, with this method, types defined in source code that the builder cannot modify cannot have attributes attached and therefore cannot be included in the serialization target. In contrast, in this embodiment, additional code 170 can be generated simply by parsing the source code string (serialization definition description, etc.), so any type can be specified as a target for serialization and deserialization. In other words, any type can be included as a target for serialization and deserialization.

[0228] In this embodiment, the serialization definition description specifies a function (for serialization) for obtaining the value held as a property value of the asset data (or intermediate object), and a function (for deserialization) for passing the property value of the asset data (or intermediate object) (the passed value is used in this function and set as a property value in the original source code). Therefore, it is not necessary for the type of object 120 generated in the running application program 118 to match the data structure of the asset data 300, and they can be set independently of each other.

[0229] For example, during serialization, by appropriately defining a function to retrieve the values ​​held in the properties of the asset data (or intermediate object), it is possible to write values ​​that do not exist as properties of object 120 to asset data 300. Furthermore, during deserialization, by appropriately defining a function to pass the property values ​​of the asset data (or intermediate object), it is possible to change the type of object 120 without changing the data structure of asset data 300. In other words, the type of object 120 and the data structure of asset data 300 can be defined and modified independently of each other, without influencing one another.

[0230] [G. Intermediate Objects] Next, we will describe the intermediate object 130 that is generated during the execution of the application program 118 generated by the information processing device 100 according to this embodiment.

[0231] Figures 16 and 17 illustrate the processing of member functions of an intermediate object 130 generated during the execution of an application program 118 produced by an information processing device 100 according to this embodiment. Figure 16 shows the processing when the LoadTo function is called, and Figure 17 shows the processing when ExtractFrom is called.

[0232] Referring to Figure 16(A), when the LoadTo function with the property value1 specified is executed, the GetValue1 function, indicated by function definition 404 of type definition 40A added to the source code (see Figure 8(A)), is called. Similarly, referring to Figure 16(B), when the LoadTo function with the property distance specified is executed, the GetDistance function, indicated by function definition 424 of type definition 40B added to the source code (see Figure 10(A)), is called.

[0233] Referring to Figure 17(A), when the ExtractFrom function with the property value1 specified is executed, the SetMyValue1 function, indicated by function definition 405 of type definition 40A added to the source code (see Figure 8(A)), is called. Similarly, referring to Figure 17(B), when the ExtractFrom function with the property distance specified is executed, the SetDistance function, indicated by function definition 425 of type definition 40B added to the source code (see Figure 10(A)), is called.

[0234] For the sake of explanation, Figures 16 and 17 show examples of calling member functions by specifying a particular property (variable), but it is also possible to perform processing on all properties held by the intermediate object 130 at once.

[0235] In this way, when the member functions of the generated intermediate object 130 (such as the LoadTo and ExtractFrom functions) are executed, the functions specified in the serialization definition description added when generating the additional code 170 are called. Since the functions specified in the serialization definition description can be freely defined, highly flexible serialization and deserialization can be achieved.

[0236] To implement member functions as shown in Figure 16 in the intermediate object 130, the additional code 170 may include code to implement an interface (LoadTo function) in the intermediate object 130 for calling a predetermined procedure (such as the SetDistance function) to set the values ​​of properties held by the intermediate object 130 to a specified object.

[0237] Furthermore, in order to implement member functions as shown in Figure 17 in the intermediate object 130, the additional code 170 may include code to implement an interface (ExtractFrom function) in the intermediate object 130 for calling a predetermined procedure (such as the GetDistance function) to retrieve property values ​​and store them in the intermediate object 130.

[0238] In this embodiment, an intermediate object 130 is generated in association with the object 120 that is to be serialized and deserialized. Therefore, data can be read from and written to the object 120, and data can be read from and written to the asset data 300 independently, enabling more flexible serialization and deserialization.

[0239] [H. Schema File 180] Next, we will describe the schema file 180 generated by the information processing device 100 according to this embodiment.

[0240] The schema file 180 contains information that identifies the data structure of the asset data 300 to be serialized and deserialized. More specifically, the schema file 180 contains information that identifies the data structure of property names and values. By using the schema file 180, the asset data 300 can be generated and edited independently of the application program 118.

[0241] Figure 18 shows an example of a schema file 180 generated by an information processing device 100 according to this embodiment. Figure 18 shows an example of a schema file 180 corresponding to the type definition 30 shown in Figure 8(A).

[0242] Referring to Figure 18, the schema file 180 includes the name of the corresponding type 181, the type ID 182 indicating the corresponding type, property information 183,184 indicating detailed information about the properties included in the asset data, and the format version 185. Each of the property information entries 183,184 includes the name of the property included in the type definition of the intermediate object 130 (or asset data 300) and information indicating the data type of the property's value.

[0243] The information processing device 100 generates a schema file 180 for properties to which serialization definition descriptions have been added in the source code. More specifically, the information processing device 100 (analysis module 152) obtains the names and data types of one or more properties included in the asset data 300 based on the serialization definition description that specifies the data to be output as asset data 300 from the data held by the running application program 118.

[0244] The information processing device 100 (additional module 154) generates a schema file 180 containing information that identifies the data structure of asset data 300, which includes one or more properties, based on the results of the analysis of the source code 160. When using the intermediate object 130 as described above, the data held by the intermediate object 130 is output as asset data 300. Therefore, the information processing device 100 (additional module 154) may generate the schema file 180 based on the type of the intermediate object 130 that holds the data output as asset data 300, which is generated during the execution of the application program 118.

[0245] In this case, the information processing device 100 (additional module 154) generates the schema file 180 and additional code 170 to implement the intermediate object 130 that holds the data to be output as asset data 300.

[0246] Using schema file 180 facilitates the integration between the editing tool and the application program 118 (executable file). Schema file 180 may be output in a general-purpose format such as JSON or XML. Using a general-purpose schema file 180 allows it to be used with various editing tools.

[0247] For example, the editing tool creates asset data 300, edits asset data 300, and displays asset data 300 based on schema file 180.

[0248] The user can generate asset data 300 (e.g., test data) that can be read by the application program 118 corresponding to the schema file 180 by performing operations on the editing tool. The user can also edit the asset data 300 that can be read by the application program 118 corresponding to the schema file 180 by performing operations on the editing tool (e.g., changing values ​​for debugging). The editing tool also adds information from the schema file 180 corresponding to the asset data 300 output by the application program 118 corresponding to the schema file 180 and presents it to the user.

[0249] Figures 19 to 21 illustrate an example of using a schema file 180 generated by an information processing device 100 according to this embodiment. Referring to Figure 19, the running application program 118 is configured to write (serialize) and read (deserialize) asset data 300A and 300B.

[0250] Assume that schema files 180A and 180B, corresponding to asset data 300A and 300B, have been generated in advance.

[0251] The editing tool 400 allows for the generation and editing of asset data 300A and 300B by referencing schema files 180A and 180B. Users can freely generate and edit asset data 300A and 300B by operating the editing tool 400. For example, test data for debugging application program 118 can be easily prepared. Furthermore, by checking the asset data 300 written from application program 118, the cause of problems can be easily identified.

[0252] The editing tool 400 may be incorporated as part of the development program 114, or it may be a general-purpose application program independent of the development program 114. The editing tool 400 may utilize a set of libraries 480 for writing and reading asset data 300 according to the schema file 180.

[0253] Thus, the editing tool 400 may create or edit asset data 300 output from the running application program 118 in response to user operations.

[0254] Referring to Figure 20, the editing tool 400 can freely generate and edit asset data 300 even when the application program 118 is not present. For example, it can generate test data even when the application program 118 is offline and not running.

[0255] Thus, the editing tool 400 may create asset data 300 that can be used by the application program 118 in response to user operations.

[0256] Also, as shown in FIG. 21, data may be directly exchanged between the running application program 118 and the editing tool 400. By adopting such a configuration, the data held by the running application program 118 can be directly edited from the editing tool 400. That is, the user can edit the running application program 118 in real time.

[0257] Thus, the editing tool 400 may be able to receive the asset data 300 output from the running application program 118 and also be able to transmit the asset data 300 to the running application program 118.

[0258] By using the schema file 180 and the editing tool 400 as shown in FIGS. 19 to 21, the development of the application program 118 can be promoted.

[0259] In the present embodiment, the additional code 170 and the schema file 180 can be generated from the source code with the serialization definition description added. That is, a schema file 180 corresponding to the type defined by the source code for generating the application program 118 is generated. Therefore, based on the schema file 180, the application program 118 generated from the source code and the editing tool 400 can be easily coordinated.

[0260] Also, since the schema file 180 is automatically generated, there is no need for the user to create the schema file 180 from scratch.

[0261] [I. Modification Example] In the above description, an example of the process of adding a serialization definition description (and an exclusion specification description) indicating that it is a target of serialization and deserialization to the source code by using an object form macro which is a general-purpose function has been illustrated, but another method may be adopted.

[0262] For example, the serialization definition description (and the exclusion specification description) may be placed in the source code 160 as a comment. That is, the serialization definition description may be added as a comment in the source code (for example, in C++, a string starting with two slash symbols). For example, a comment containing a specific keyword such as " / / [BIND_VALUE]" may be added to the variables to be serialized and deserialized.

[0263] In the process of generating the additional code 170, comments containing specific keywords may be extracted by lexical analysis, and the variables described in the lines where the comments containing specific keywords are extracted may be specified as the targets for serialization and deserialization. On the other hand, in the compilation during the build, comments are ignored, so the application program can be generated without substantially affecting the original source code part.

[0264] Furthermore, the variables to be serialized and deserialized may be specified by any method other than macro names and comments.

[0265] The embodiments disclosed this time should be considered illustrative in all respects and not restrictive. The scope of the present invention is shown not by the above description but by the claims, and it is intended that all modifications within the meaning and scope equivalent to the claims are included.

Explanation of Signs

[0266] 30,40A,40B,40C,40D,40E,40F,40G,60 Type definitions, 42,63,64,410,430,450,470,490 Serialization definition descriptions, 50A,50B,50C,50D Serialization code, 52A,52B,52C,52D Deserialization code, 100 Information processing unit, 102 Processor, 104 Memory, 106 Display, 108 Input unit, 110 Storage, 112 System program, 114 Development program, 116,116A Project, 118 Application program, 120 Object, 122 Communication module, 124 Bus, 130 Intermediate object, 131,132,133,134 Interface, 140 Update module, 142 Builder, 144,152 Analysis module, 146 Compiler, 148 Linker, 150 Additional code generation module, 154 Additional module, 160 Source code, 162, 162A File list, 164 Configuration information, 170 Additional code, 180, 180A, 180B Schema file, 181 Name, 182 Type ID, 183, 184 Property information, 185 Format version, 300, 300A, 300B Asset data, 400 Editing tool, 401, 421, 441, 481 Definition description, 404, 405, 424, 425, 444, 445, 464, 465 Function definition, 410A, 490A Code, 411, 431, 451, 471, 491, 631, 641 Macro names: 412, 432, 452, 472, 492, 632, 642 Property names: 413, 433, 453, 473, 493, 633, 643 Data type definitions: 414, 415, 434, 435, 454, 455, 474, 475, 494, 495, 634, 635, 644, 645 Function names: 416, 436, 456, 476 Type names: 480 Library groups: 501, 502 Descriptions: 636, 646 Type names.

Claims

1. A development program for developing application programs using a programming language that generates objects based on types, wherein the computer of the information processing device A means for identifying type definitions in the source code of the application program, The system generates first code that generates intermediate objects for asset data corresponding to each of the objects generated based on the specified type definition, and the generated first code functions as a code addition means for adding it to the source code of the application program. A development program in which the aforementioned intermediate object is saved as asset data.

2. The code addition means further adds a second code, which is the type definition of the intermediate object, to the source code of the application program. The development program according to claim 1, wherein the intermediate object is generated according to the type definition of the second code.

3. The development program according to claim 2, wherein in the second code, the type of the intermediate object is defined independently of the corresponding type definition in the source code.

4. The development program according to claim 2, wherein in the second code, the type of the intermediate object is defined to inherit a common type definition.

5. The development program according to any one of claims 2 to 4, wherein the second code includes code for calling a process to store a value obtained by a pre-specified function or a pre-specified value in the intermediate object.

6. The development program according to any one of claims 2 to 4, wherein the second code includes code for calling a process that passes the value of a property held by the intermediate object to a pre-specified function.

7. The development program according to any one of claims 2 to 4, wherein the second code includes code for calling a process that outputs the values ​​of the properties of the intermediate object in a predetermined format for each type of the intermediate object.

8. The development program according to any one of claims 1 to 4, wherein the identifying means extracts a predetermined description from the source code of the application program, the description including a first description that specifies the name of a property and a second description that specifies a function or variable for obtaining a value.

9. The development program according to any one of claims 1 to 4, wherein the code addition means further adds a third code to the source code of the application program that performs a process for maintaining the history of the intermediate object.

10. An information processing system for developing application programs using a programming language that generates objects based on types, A means for identifying type definitions in the source code of the application program, The application program includes a code addition means that generates first code for generating intermediate objects for asset data corresponding to each of the objects generated based on the specified type definition, and adds the generated first code to the source code of the application program. An information processing system in which the aforementioned intermediate object is stored as asset data.

11. An information processing apparatus comprising one or more processors and a memory for storing a program, wherein the information processing apparatus operates by the one or more processors executing the program. The process of identifying type definitions in the source code of an application program written using a programming language that creates objects based on types, The process involves generating first code that generates intermediate objects for asset data corresponding to each of the objects generated based on the specified type definition, and then adding the generated first code to the source code of the application program. An information processing device in which the aforementioned intermediate object is stored as asset data.

12. A computer-based information processing method for developing application programs using a programming language that generates objects based on types, The steps include identifying type definitions in the source code of an application program written using a programming language that creates objects based on types, and The application program comprises the steps of generating first code that generates intermediate objects for asset data corresponding to each of the objects generated based on the specified type definition, and adding the generated first code to the source code of the application program. An information processing method in which the aforementioned intermediate object is saved as asset data.

Images