U.S. Pat. No. 9,035,947

DETAILED DESCRIPTION

The current development process for a video game application builds content for the video game application in a tool such as, but not limited to, a flash editor tool. Content may include, but is not necessarily limited to, buttons, labels, grids, toggles, and other common or uncommon user interface (UI) elements. The content may further be comprised of configurable properties. Examples of configurable properties within a screen include, but are not necessarily limited to, location of elements, size of elements, transparency/opacity of elements, data that elements are bound to, style properties such as font, size, color, sound effects based on events, and animations based on events. Elements may represent animated images or imagery such as, but not limited to, characters, structures, obstacles, etc., that comprise the scenery and action that occurs during a game session.

The development process may be characterized somewhat as a trial and error process in which content is created, implemented, tested, and evaluated as to whether it should be included in the video game application. Sometimes the proposed content is accepted and sometimes it is rejected necessitating additional content adjustments. Inserting the content adjustments into the video game application can be a time intensive and laborious process that generally requires the cooperation and collaboration of content creators and software engineers. The content creators may be responsible for creating content while the software engineers may be responsible for implementing the content into the application so that it may be evaluated during development. When the content is ready to be implemented into the video game application, it must go through a pipeline to the destination machine (e.g., a game console) and then be reloaded which can take between fifteen (15) seconds and three (3) minutes depending on at what point the content exists in the video game application. This process is repeated for every change regardless of the scope of the change. Since a content creator/developer may make large numbers of changes during the development process, the time inefficiency that is a part of the system may become magnified. This is especially true when the content change itself may only take a few seconds.

Various embodiments disclosed herein permit a user/developer to live link to one or more game console systems running the game application. The manipulation of elements of content using a live authoring tool (LAT) may result in instant feedback of content modifications in the game application. The instant feedback provided is a vast improvement over the delivery/reload scenario currently employed. In addition, one or more LATs may be connected to one or more game console platforms over a network. Such a configuration allows for easier collaboration for users/developers that may not be in the same location. In other words, multiple developers using multiple LATS may simultaneously collaborate to develop a video game application. Moreover, the LATs may be in communication with multiple game consoles running the video game application. Thus, content modifications may be evaluated for different game console platforms at the same time.

In general, a video game application is loaded onto a game application console and a LAT may be used to navigate to a screen to be modified. The LAT may be running on a separate computer that is remotely located from the game console. The LAT and the game console may be communicable over a direct point-to-point connection or over a network such as a local area network (LAN) intranet, wide area network (WAN) intranet, the Internet, or any combination thereof. Alternatively, if the game application console happens to be a computer, the LAT may be co-resident and executable on the same computer.

The video game application may push video game information to the LAT to sync the current state of the video game application and the LAT. Using a property editor the LAT may present, on a first display, a low fidelity version of the layout of a desired screen to be modified. One purpose of the low fidelity version of the layout is to generate assets that can be used in the video game application. The intent is to allow the LAT to hook up to different game console platforms. If the LAT also has to contain the same look as the video game application then two sets of assets need to be managed, or at least two systems using the same set of assets. For example, it is possible that a mobile implementation of a video game application may be different than a game console implementation, a video game application may change year over year, or different video game applications may use the LAT. The low fidelity version of the desired screen layout allows the LAT to be hooked up in any of the aforementioned scenarios and still work in the same manner.

The LAT may be used to modify content (e.g., user interface elements) in a screen. The content modifications may then be sent as a message from the LAT to the video game console executing the video game application. The messages containing the content modifications are sent immediately as they occur in the LAT and may be seen immediately in real-time in the executing video game application game console environment. The re-configured content/element properties may then be saved out as data for future use with the video game application or rejected/deleted.

The content modification process may be based on messages passed back and forth between the LAT to the video game application executing in a game console platform. In addition, multiple instances of the video game application executing on different video game console platforms may be coupled with a single LAT to see how the different platforms would render the modified content data. Content modification messages may be sent to all connected video game console platforms or can be selectively sent to specific video game console platforms for evaluation.

Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the novel embodiments can be practiced without these specific details. In other instances, well known structures and devices are shown in block diagram form in order to facilitate a description thereof. The intention is to cover all modifications, equivalents, and alternatives consistent with the claimed subject matter.

FIG. 1illustrates one embodiment of a system implementing a LAT for modifying content in a video game application during development. A LAT platform computer system100is generally directed to communicating and exchanging data with a game platform console160computer system. The communication may be direct115or over a network150such as a local area network (LAN), a wide area network (WAN), the Internet, or any combination thereof. In addition, multiple LAT platforms100may be coupled with multiple game platform consoles160in a many-to-one, a one-to-many, or a many-to-many implementation to further enhance the flexibility of embodiments described herein.

A LAT platform100generally comprises a computer110(e.g., a personal computer (PC)) under control of a processing component120. The processing component120may be responsible for executing a live authoring tool (LAT)130application or module. The LAT platform100may further include a memory component140. In addition the LAT platform100may be coupled with a computer display device145.

The LAT130may be responsible for receiving a high fidelity version of a desired screen image from a game console platform160. The LAT130may then convert the high fidelity version of the screen image to a low fidelity version to be displayed on the computer display device145. A user105(e.g., content creator or developer) may make modifications to the content represented by the low fidelity version of the screen image using the LAT130. The modified content may then be returned to the game console platform160for rendering.

In an alternative embodiment, the LAT130may not need to convert the high fidelity version of the screen to a low fidelity version of the screen. Some embodiments of the LAT130may make content modifications directly to the data representative of the high fidelity version of the screen which may be returned to a game platform console160for rendering and evaluation.

The memory component140may be included to store data as needed. The memory component140may include various types of computer-readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information. The memory component140may include non-volatile memory and/or volatile memory.

The computer display device145may provide visual feedback to a user105. The user105may interact with the computer110via a variety of well known input devices (not shown) and user interfaces (UIs) also not shown.

The game platform console160generally comprises a processing component170that may be responsible for managing the various functions of the game platform console160that include a runtime environment180for executing a video game application175. A data storage component185may be included to store data as needed by the video game application175. A video game display190may provide visual feedback pertaining to the video game application175.

The runtime environment180may include a game engine to execute the video game application175. For example, a video game application may be stored on a disk that may be loaded into the game platform console160via an external memory device such as a DVD drive. Alternatively, the video game application may be sent directly from a source computer and stored in data storage component185before being loaded into the runtime environment180to be executed by a game engine.

A LAT runtime interface165may facilitate communication with the LAT platform100. The LAT runtime interface165may capture screen images executing in the runtime environment180and push information to the LAT130to synchronize the current state of the video game application175with the LAT130. The LAT runtime interface165may also receive content modification messages from the LAT platform100and insert them into the runtime environment180on a real-time basis. The content modifications may be viewed on the video game display190and a determination made whether to save the content modifications in data storage component185.

Thus, the game platform consoles160used in the development process each include and use the LAT runtime interface165capable of exchanging messages with the LAT130such that the LAT130can provide data back to the various game platform consoles160in a format that can be understood by that game platform console160.

FIG. 2illustrates another embodiment of a system implementing a LAT for modifying content in a video game application during development. This embodiment allows a single machine labeled computer and game platform200to co-host a LAT platform module210and game platform module250. The computer and game platform200may be split functionally into the LAT platform module210and the game platform module250.

The LAT platform module210generally comprises a processing component220. The processing component120may be responsible for executing a live authoring tool (LAT)240application. In addition the LAT platform module210may be coupled with a LAT monitor215operative to display data from the LAT240. For example, the LAT monitor215may provide visual feedback to a user105. The user105may interact with the computer and game platform200via a variety of well known input devices (not shown) and user interfaces (UIs) also not shown.

The LAT240may be responsible for receiving a high fidelity version of a desired screen image from the game platform module250. The LAT240may then convert the high fidelity version of the screen image to a low fidelity version to be displayed on the LAT monitor215. A user105(e.g., content creator or developer) may make modifications to the content represented by the low fidelity version of the screen image using the LAT240. The modified content may then be returned to the game platform module250for rendering.

The game platform module250generally comprises a runtime environment270for executing a video game application280. A video game display255may provide visual feedback pertaining to the video game application280.

The runtime environment270may include a game engine to execute the video game application280. For example, a video game application may be stored on a disk that may be loaded into the game platform module250via an external memory device such as a DVD drive. Alternatively, the video game application may be sent directly from a source computer and stored in a data storage component290before being loaded into the runtime environment270to be executed by a game engine.

A LAT runtime interface260may facilitate communication with the LAT platform module210. The LAT runtime interface260may capture screen images executing in the runtime environment270and push information to the LAT240to synchronize the current state of the video game application280with the LAT240. The LAT runtime interface260may also receive content modification messages from the LAT platform module210and insert them into the runtime environment270on a real-time seamless basis. The content modifications may be viewed on the video game display255and a determination made whether to save the content modifications in data storage component290.

The LAT platform module210and the game platform module250may further be coupled with the data storage component290. The data storage component290may be included to store data as needed. The data storage component290may include various types of computer-readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information. The memory component140may include non-volatile memory and/or volatile memory.

In the embodiment ofFIG. 2, a single user can execute a video game application280and simultaneously make content modifications to the video game application280using LAT240. The content modifications may be passed over a bus245to the LAT runtime interface260and implemented in real-time by the runtime environment270executing the video game application280thereby providing instant feedback of what the content modifications look like when rendered on an actual game platform.

FIG. 3illustrates one embodiment of a messaging protocol between a LAT platform100and a game console platform160. The messaging protocol may describe the types of messages and data exchanged between components of the LAT platform100and components of the game console platform160. A precursor step may be to establish a connection between the LAT platform100and the game console platform160. The LAT platform100via the LAT130may navigate to a certain point in a video game application175being executed by the runtime environment180and request an introspect view of a desired screen image. An introspect view refers to a message sent from the LAT platform100to the game console platform160that requests the current view state information. The game platform160may then return data indicative of an introspected state representative of the requested introspect view.

The LAT platform100via LAT130may convert the data indicative of the introspected state representative of the requested introspect view to a low fidelity screen image. A user105executing the LAT130may make content modifications directly to the low fidelity version of the requested screen image. The content modifications may be organized as state changes that may be returned to the game console platform160via the LAT runtime interface165. The state changes may then be implemented in real-time within the runtime environment and evaluated using the video game display190. The process may be repeated as necessary to make further changes.

FIG. 4illustrates one embodiment of a corresponding widget representation to be exchanged between a LAT130and a game platform console160. In the LAT130view, a low (or high) fidelity representation of what is currently being displayed by the game console160on the video game display190may be seen on the computer display145. In addition, the properties of each object or element may be seen and modified. Such content modifications may be reflected back to the game platform via the messaging described inFIG. 3using the system ofFIG. 1orFIG. 2.

The messaging may include a widget manifest file. The widget manifest file may be indicative of the various UI elements that are included in a screen image. Each widget may represent a different UI element in a screen image. The widget manifest file may include, but is not limited to, one or more sets of global properties applicable to all widgets. Each widget may comprise widget data including, but not limited to, a technology independent common name identifier (e.g., Label), a technology dependent runtime name (e.g., ux::Flash::Label), which global property set(s) are to be inherited, a list of properties that are inspect-able and/or modifiable using the LAT130, and a list of defaults for any properties that require defaults for when a new widget is constructed. The widget data list of properties may include color, size, shape, and other low fidelity visual parameters for UI elements.

A user105, by way of LAT130, may relocate a widget, modify the properties of a widget, add a new widget, and delete a widget. The combination of one or more of the aforementioned LAT widget functions may modify the content of the screen image at issue. If a user105moves a widget, the LAT130creates and sends a message containing widget identifying data pertaining to each pixel to the game platform console160. The LAT runtime interface165receives the message and modifies a corresponding high fidelity version of the widget to match what was done by the LAT130. The content modifications contained in the widget are then rendered by the runtime environment180to present a real-time updated view of the screen containing the widget on the video game display190.

If a user105modifies properties of a widget, the LAT130creates and sends a message containing widget identifying data and the properties that were modified. The LAT runtime interface165receives the message and modifies a corresponding high fidelity version of the widget to match what was done by the LAT130. The content modifications contained in the widget are then rendered by the runtime environment180to present a real-time updated view of the screen containing the widget on the video game display190.

If a user105adds a new widget, the LAT130selects a widget from the memory component140of the LAT platform and creates and sends a message containing widget identifying data and the widget to construct. The LAT runtime interface165receives the message and constructs a corresponding high fidelity version of the widget. The new widget is then rendered by the runtime environment180to present a real-time updated view of the screen containing the new widget on the video game display190. Alternatively, the widget may be selected from a common repository that may be under the control of a separate widget server. In this manner, multiple LAT platforms100may create and store new widgets in a central location eliminating the need for each LAT platform100to create and maintain its own set of widgets.

If a user105deletes a widget, the LAT130creates and sends a message containing widget identifying data and the widget to delete. The LAT runtime interface165receives the message and deletes a corresponding high fidelity version of the widget. The runtime environment180renders the screen to present a real-time updated view of the screen with the widget deleted on the video game display190.

The user105may then save changes that have been made. The LAT130may send a message instructing the game platform console160to save to the runtime environment. The game platform console160via processor component170may then save the current state of the screen to a layout file that will be used to load this particular screen view in the future.

Included herein is a set of flow charts representative of exemplary methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, for example, in the form of a flow chart or flow diagram, are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.

FIG. 5illustrates one embodiment of a logic flow500in which a LAT130operating on a first machine may be used to modify the content of a video game application175operating on a second machine during development. In alternative embodiments the LAT and the video game application may operate on separate components of the same machine. The logic flow500may be representative of some or all of the operations executed by one or more embodiments described herein including those illustrated inFIGS. 1-4.

In the illustrated embodiment shown inFIG. 5, the logic flow500may open a video game application on a target game platform console160at block505. For example, a target game platform console160may be a modified version of a standard game platform console. Each target game platform console160may be associated with a runtime environment180including, but not limited to, a personal computer (PC), an Xbox™ platform, a Playstation™ platform, a Wii™ platform, mobile computing device (e.g., smartphone, tablet), etc. The combination of game console and runtime environment may comprise a game platform. In the embodiments herein, the target game platform console160may be a modified to include a LAT runtime interface165operative to exchange communications with a LAT130executing on a remote or co-hosted LAT platform100. The embodiments are not limited to this example.

In the illustrated embodiment shown inFIG. 5, the logic flow500may then launch a LAT130at block510. For example, the LAT130may be resident on a LAT platform100executing on a personal computer (PC) or other computer system110. The LAT platform100and the game platform console160may be communicable with one another via the LAT runtime interface165that has been incorporated into the game platform console160. The embodiments are not limited to this example.

In the illustrated embodiment shown inFIG. 5, the logic flow500may then connect and interface with a game platform console executing a video game application at block515. For example, the LAT130may send a message to a game platform console160by way of the LAT runtime interface165asking the game platform console160to provide information regarding its game platform. This information may include identifying the type of game platform (e.g., personal computer (PC), an Xbox™ platform, a Playstation™ platform, a Wii™ platform, mobile computing device, smartphone, tablet) as well as any configuration properties. Configuration properties may include, but are not limited to, items such as screen size, screen resolution, audio capabilities, processor capabilities, and the like. In addition, the LAT130may connect with multiple different game platform consoles160to evaluate content modifications across a variety of platforms at once. The embodiments are not limited to this example.

In the illustrated embodiment shown inFIG. 5, the logic flow500may receive data representative of a high fidelity version of a screen image on the video game console160at block520. For example, the LAT130may send a request message to the game platform console160by way of the LAT runtime interface165asking the game platform console160to forward the image data indicative of the current screen in the executing video game application175. The game platform console160may return the requested data to the LAT130in the form of a high fidelity version of the requested screen image. The embodiments are not limited to this example.

In the illustrated embodiment shown inFIG. 5, the logic flow500may render a low fidelity version of the received data representative of a high fidelity version of a screen image at block525. For example, the LAT130may convert the high fidelity version of the received screen image to a low fidelity version of the same screen image. The low fidelity version of the screen image may then be rendered on a display145coupled with the LAT platform100. The embodiments are not limited to this example.

In the illustrated embodiment shown inFIG. 5, the logic flow500may modify content within the low fidelity version at block530. For example, the LAT130may perform multiple content modifications to the low fidelity version of the screen image. The low and high fidelity versions of the screen image may be comprised of widgets. A widget may represent an element within the view of the screen image. An element may be a character, a structure, an object, etc. A collection of widgets may be organized into a widget manifest file. The widget manifest file may include additional global properties that pertain to the screen image, such as background color, etc. Thus, the data representative of a screen image may be fully described by the contents of the widget manifest file and its associated widgets. By amending or altering properties of the various widgets and global properties of the widget manifest file, a user may edit the screen image. As earlier described, some of these content modifications include relocating a widget, modifying the properties of a widget, adding a new widget, and deleting a widget. The embodiments are not limited to these examples.

In the illustrated embodiment shown inFIG. 5, the logic flow500may send content modifications to the game console platform160at block535. For example, the LAT130may send the widget modifications back to the game platform console160by way of the LAT runtime interface165. The widget modifications may then be forwarded to the runtime environment180. The embodiments are not limited to this example.

In the illustrated embodiment shown inFIG. 5, the logic flow500may render the content modifications in a high fidelity version of the video game application175on the game console platform160at block540. For example, the runtime environment180may enable the widget modifications in real-time for the high fidelity version of the screen image. As a result, the image presented on the video game display190may be refreshed to illustrate the content changes made to that screen image. The video game application175need not be re-loaded or re-booted thereby saving valuable time. The developer can see, in real-time, the net effect of the changes made by the LAT130. Since the development process often requires multiple changes regardless of how big or small, the cumulative time saved in making and evaluating the content changes is significant. This leads to a quicker development cycle. The embodiments are not limited to this example.

In the illustrated embodiment shown inFIG. 5, the logic flow500may decide whether to save or delete the content modifications at block545. For example, the user105may view in real-time the effect of the content modifications to the video game application175and make a determination whether to save the content modifications at block550or delete the content modifications at block555. The user may cause the LAT130to save the changes that have been made to the high fidelity version of the screen by sending a message to the target game platform console160to save the modifications made to the runtime environment180. The target game platform console160may then save the current state of that screen to a layout file that will then be used to load this view in the future. The embodiments are not limited to this example.

Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as “IP cores” may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a non-transitory machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as “IP cores” may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor.

Some embodiments may be described using the expression “one embodiment” or “an embodiment” along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. Further, some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

It is emphasized that the Abstract of the Disclosure is provided to allow a reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein,” respectively. Moreover, the terms “first,” “second,” “third,” and so forth, are used merely as labels, and are not intended to impose numerical requirements on their objects.

What has been described above includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and/or methodologies, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.