US20100144444A1 - Real-time, video game playtesting - Google Patents

Abstract

A video game testing system facilitating real-time monitoring and modifying a video game during a playtesting session. The testing system includes video game platforms operating during a playtesting session to run a video game. A server is provided to run a communications hub module communicatively linked with the video game platforms. The testing system also includes a monitoring computer station with a statistics gathering tool receiving data related to play of the video game by a control group of players. The game play data is transmitted from the video game platforms via the communications hub module, and the statistics gathering tool processes the game play data and outputs aggregated statistics during the playtesting session. The testing system includes a development tool issuing authoring messages to the game platforms defining modifications to the game data during the playtesting sessions, whereby real-time feedback is provided on game play and modifications.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation-in-part of U.S. patent application Ser. No. 12/328,619, filed Dec. 4, 2008, and entitled “Communication Hub for Video Game Development Systems,” and is also related to U.S. patent application Ser. No. ______, filed with this application and entitled “Live Authoring Method for Real Time Development of Video Games,” and U.S. patent application Ser. No. ______, filed with this application and entitled “Collaborative Authoring Method for Video Game Development,” all of which are incorporated herein by reference in their entireties.
BACKGROUND OF THE INVENTION
• 1. Field of the Invention
• The present invention relates, in general, to video game development and communications between development tools and video game platforms, and, more particularly, to systems and methods for improving the efficiency and effectiveness provided during playtesting of video games.
• 2. Relevant Background
• The video game market has moved from a smaller niche market to a multi-billion dollar market. The demand for new video games is growing rapidly as the size and demographics of game players continues to expand. Also, video games used to be made for only one or two game platforms, but now there is a demand for video games that can be sold on numerous platforms including standalone game consoles, computers, handheld portable gaming devices, and other electronic devices such as cellphones, digital music players, and personal digital assistants (PDAs). As a result, there is significant competition among game developers to create video games to meet the growing demand in a timely and efficient manner and, often, for these games to be able to run as desired on differing platforms or devices.
• Large-scale, commercial video games are typically created by large development teams with the development process taking 1 to 3 years and costing millions of dollars. A typical development team may include producers to oversee production, game designers, artists, programmers, level designers, sound engineers, and testers with some team members handling more than one role. The development team works in a collaborative manner to create game content (or game assets) and game code, which together may be thought of as a game application, that can be run by a gaming engine on a particular game platform to provide the game to a player.
• For example, programmers may write new source code, artists may develop game assets such as characters or scene objects, coloring schemes, textures, 3D models of game elements, and the like, sound engineers may develop sound effects and music, writers may create character dialog, and level designers may create advanced and eye-catching levels. To support these team members, numerous game development tools, such as Microsoft XNA, Maya from Autodesk, Inc., and the like, are now available for use in designing and creating game content including creating and modeling characters and even for defining game logic (e.g., how high a character jumps, how much life does a character gain or lose based on a game event, how fast does a character or game element move, and so on). However, typically a complete engine has to be purchased, which causes most game developers to try to build their own tools. Additionally, each video game console or platform developer typically will make a software development kit (or SDK or devkit) available to game developers, and each SDK may include applications or tools that are useful in creating new video games. Each SDK may also include a communications library and/or interface (e.g., platform communications data) to facilitate communications with a game platform (e.g., the platform running a game under current development or running a built game for testing or use by a developer to see how a new character, asset, game parameter, or the like is working in the game).
• Currently, development tools used in the video game industry rarely communicate with each other and, if they do, the tools typically communicate and function using a one-to-one connection. Specifically, the tool communicates with a game running on a particular video game platform with a connection between the tool running on a developer's workstation and the game platform. For example, the development tool may generate a platform client on the workstation to provide an interface with the running game, and the tool may be required to manage a communication socket to support these communications. Each game platform typically utilizes differing interfacing and communication protocols (or at least have some differences), and each development tool is required to understand how to communicate with each game platform that may be used with the tool. Presently, a game developer may be working on a video game that needs to operate on more than one game platform, and the development for each platform often occurs along parallel paths as it is desirable (or required) for games to be released concurrently for each of the game platforms.
• Developing or “authoring” a video game is often time consuming for members of the development team, and computer processing time during the game creation and modification is often a large percentage of development time. For example, the present development process in the video game industry involves a designer, programmer, artist, or other team member using a development tool to change an existing, or to create a new, game asset such as a game object, a texture of an object or scenery element, an animation or character, or the like. The development team member then processes this data to create a new game build and then uploads it to a particular game platform or console. They can then see their changes or additions in the running game on the platform. If additional changes are required, the process is repeated with altering game assets through operation of a game development tool on their workstation and rebuilding and running the modified video game application with a game engine on the game platform.
• This iterative process is time consuming and also requires considerable amounts of processing time to create new builds or versions of the video game application, and the problem is amplified when there are numerous small changes that need to be made or many repetitive changes or additions that need to be made to a game level or scene as the developer quickly becomes frustrated with the tedious task of making minor changes and having to reprocess the game application to view the changes. Further, the process has to be repeated for each intended video game platform because a change or modification to a game asset that “works” or is effective on one platform may not be acceptable on another platform. For example, a coloring change or a lighting change to a video game may produce a desirable effect when the video game is run on one platform while the same change may produce a different and unacceptable effect on a second platform (e.g., a game development tool may allow setting lighting at 5 on a scale from 1 to 10 but each platform or game engine may translate this differently to produce differing effects). Another issue is that different game development tools may have to be run or used to alter differing portions or sets of the game assets, and, typically, this has required separate game builds or game asset processing to view the revised video game.
• Some companies have created products that designed to be used as the central hub of game content authoring, but this has not resolved all editing and modifying issues. Another attempt to address the time consuming editing or modifying problems of game development has been to try to build the tools into the game engine. However, this approach is generally undesirable as it increases the chances of work-stopping bugs in the tools as it ties operation of all of the tools together, and this approach has been resisted by game platform developers as it complicates the game engine and its operations. This only allows the content creator to view the created assets inside the tool, and while it is closer to a running game, it is not actually the same as the game running on a target platform, which can fool a game designer or developer.
• Another issue facing the video game industry is how to support collaborative efforts among the development team members working on a new video game. Typically, due to the large and complex nature of game content (e.g., game data and/or game assets), only one artist, designer, or other development team member can work on any given portion of a game at a time. For example, an artist working on a texture or materials for a given game level would force a designer who wants to adjust or tweak placement of some game objects or elements within that that level or location/position within that level to wait until the artist has completed their work or at least saved the new game data allowing a rebuild of the game. Such serial development efforts often extends the timeline for creating a new video game, and there are demands within the industry to shorten video game development times from many months down to a few months time (e.g., to respond to customer demand for games related to new movies or trends).
• Playtesting is often used to determine whether a video game is ready for market including working out bugs or problems and adjusting logic and game parameters/settings to make the game more enjoyable to play. Testing may begin as soon as there portions ready to play but often begins later in the development process so that there is a significant amount of the game to play for the testers. Playtesting generally involves people or testers playing the video game on one or more target platforms. In a typical closed or internal playtest, a group of testers are selected and asked to play through predetermined portions of the video game. After play is completed, their play experience is captured or documented through questionnaire and interviews or communications with development team members including those who worked to design the tested portions. In some cases, video recording is used to document the testers play experience. Also, some playtest labs include recording facilities to capture game information or statistics from each player's session, and this information is stored for later or offline evaluation by the development team. Hence, playtesting is generally a static process that captures for a snapshot of playtesting results for a tested portion of the game. The playtesting results are later analyzed and used to implement changes to the video game, but, to test these changes, another group of playtesters will be gathered to perform another playtesting of the modified video game.
• Hence, there remains a need for improved methods for playtesting video games. Preferably, such methods and systems support use of existing (and to be developed) video game development tools and would reduce the amount of time spent by developers in creating new game assets and in performing modifications to a previously built video game. Further, the inventors recognize that one of the largest discrepancies among the testers during playtesting is their video game skills, and, hence, the inventors believe it is desirable to provide a playtesting method and system in which the same testers are used to play a video game or portion of such game after game modifications are made such that skill discrepancies do not skew the playtesting results (e.g., one set of playtesters may have a high average skill level that encourages developers to make a game (or a particular move/task/function/operation) more difficult but a second, later set of playtesters may have a low average skill level that indicates the modified game is less fun because it is too difficult (or vice versa)).
SUMMARY OF TIE INVENTION
• The present invention addresses the above problems by providing methods and systems for facilitating and simplifying communications between video game development tools and video game platforms (or games running on such platforms). A central hub communications application is provided that abstracts the knowledge of the video game platforms as well as the existence of other video game development tools. The video game development tools can communicate with any game platform and with each other without requiring specific knowledge of the intended recipients and their communication rules or protocols. To this end, the central hub communications application or module has access to the data or knowledge of how to connect and communicate with each video game platform in a video game development system or network (e.g., has access to platform communication libraries (such as those provided with game platform SDKs or the like) that may be thought of as communication data sets or libraries). In contrast, the video game development tool only has a client-side communications library (e.g., access to such a library in memory of the development workstation or computer or as a library built-in to the tool) that allows the tool to communicate with the communications hub application. The hub application receives the tool-sent messages, processes these messages as necessary based on the video game platform communication data sets, and forwards the messages to the appropriate recipients/clients (e.g., video games running on one or more platforms, to another development tool, or other interested client).
• More particularly, a video game development tool is provided for facilitating communications with a first video game platform and a second video game platform (e.g., two or more platforms distributed by two or more companies), with the game platforms providing two different communication libraries defining messaging and other communications with the platforms or games running on such platforms. The system includes a communications hub module running in the system such as on a hub or communications server, and the hub server is communicatively linked with the first and second video game platforms to allow the communications hub module to forward messages to and receive messages from the game platforms. The system also includes memory or data storage that is accessible by the communications hub module and that stores the first and second communication data sets (e.g., first and second or differing code libraries that may be linked into the system). A video game development tool is provided in the system running on a computer system such as a developer workstation or other computing or electronic device. The development tool is communicatively linked with the communications hub module, and, in this regard, the development tool transmits messages configured or formatted based on a client-side communications library that provides information such as communication protocols for communicating with the communications hub module. In operation, the communications hub module receives the transmitted messages from the development tool, generates game platform messages from the received messages based on the appropriate first and second communication data sets, and then forwards the game platform messages to at least one of the first and second video game platforms.
• The messages from the video game development tool often will include game data for a video game running on both the first and second video game platforms, and, in these cases, the game platform messages are forwarded to both game platforms from the hub module. The hub module may process each of the messages from the tool to determine or identify a list of recipients for each of the game platform messages it creates. The list of recipients may be based on a set of addressees provided in the tool messages or may be based on the message content (e.g., to recipients interested in particular game data such as particular logic, game assets, game parameters/variable values, and the like). In many cases, the game development system will include additional game development tools linked to the hub module, and these tools may receive messages from the first or original game tool when they are identified in the set of addressees or when placed on the list of recipients by the communications hub module based on the message content (e.g., another tool may be interested when certain game data is modified by another tool). In this way, tool-to-tool communications are facilitated or provided within the development system via the hub module. The list of message recipients may be determined by the hub module from a list of clients that have been registered with the hub module to receive messages from video game tools, and the registered clients may include subsystems of a video game running on one or both of the game platforms. The development tool may use a single communication socket to send the transmitted message to both platforms via the hub module while the hub module may act to provide a communication interface with the game platforms in part by maintaining communication sockets or clients for these game platforms (e.g., to implement the protocols or communication rules/definitions provided in the first and second communication data sets).
• According to another aspect, a video game development system is provided with enhanced or “live” feedback to developers working with multiple game platforms or consoles. The system includes a communications hub module running on a hub server that is linked for digital communications with first and second video game platforms that use game engines to run video games (e.g., differently configured game engines such as those that may be provided by differing platform manufacturers). A video game development tool running on a computer system or workstation and that is also linked to the communications hub module. The development tool operates in response to user/developer input to perform modifications of video game data including game data or asset changes and additions. An authoring module is associated with the video game development tool and operates after the game data modifications to transmit an authoring message to the communications hub module. The authoring message typically includes content reflecting the game data modifications and is formatted based on a client-side communications library to be accepted/received by the hub module. The hub module generates game data update messages from the authoring messages and forwards these messages to the first and second video game platforms. The game engines on the platforms then operate to alter a running video game using the game data modifications to provide prompt visual/audio feedback to the developer on the changes they made with the development tool. The modifications may include changes to game logic for the video game and often may include multiple modifications (e.g., at least two) of the video game data such as a change to a game asset, e.g., a change to an object such as its location, size, texture, and so or a change to a game defining parameter such as a lighting level.
• According to another aspect, a video game development system is provided that is adapted for collaborative game authoring. The system includes a video game platform with a game engine running or providing video game instance based on a set of game data (e.g., defined game logic, game assets such as animations, objects, and game settings, and the like). A communications hub module is communicatively linked to the video game platform, and first and second game development tools are linked to the communications hub module. The tools are operated to modify the set of game data and to transmit authoring messages including content based on modifications to the set of game data to the communications hub module. The communications hub module generates game data update messages from these tool-generated authoring messages (with the update messages being in the form expected/required by the platform which typically differs from that required/expected by the hub module for the authoring messages) and forwards the update messages to the video game platform. In response, the game engine runs the video game using the set of game data including updates provided in the update messages. The first and second development tools may be operated concurrently by developers to transmit the authoring messages such that the live running instance of the game on the platform may include edits or changes (or additions) provide by both development tools to support collaborative design efforts.
• Regarding playtesting of video games, a video game testing system is provided that facilitates authoring or modifying the game during the playtesting session. The testing system includes a set of video game platforms that operate during a playtesting session to run (or provide an instance of) a video game, with the game running based on a set of game data such as game logic, game assets, and the like. A server or computer is provided in the testing system to run a communications hub module that is communicatively linked with the video game platforms (e.g., the running video games are communication clients of the hub module). The testing system also includes a monitoring system with a playtest statistics gathering tool that receives game play data related to a set of players playing the running video games. The game play data is transmitted from the video game platforms via the communications hub module, and the statistics gathering tool processes the game play data and outputs aggregated statistics during the playtesting session (e.g., provides real-time feedback on play results of a video game via a GUI on a display screen in the monitoring system). The testing system may also include a game development tool that issues authoring or game update messages to the game platforms via the hub module. The authoring messages include content defining modifications to the game data and are transmitted during the playtesting sessions such as to alter game logic in response to players in the control group finding a task too easy or too difficult. The authoring messages may be sent to all of the running video games or to some subset to allow selective modification of the playtested video games with the same control group of players.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a functional block diagram of a video game development system or network configured according to prior communication methods;
• FIG. 2 illustrates a functional block diagram in contrast to the system ofFIG. 1 shows a video game development system or network adapted according to an embodiment of the invention with a developer communications hub facilitating communications between game development tools and games running on differing video game platforms and, optionally between the tools themselves;
• FIG. 3 illustrates a functional block diagram of video game development system or network providing additional detail of an exemplary implementation or embodiment illustrating that games use a client-side communication library (that may be built into each tool) to create or use a single communication socket to transmit and receive game data or development messages from the central hub application;
• FIG. 4 illustrates a development system or network illustrating in more detail one exemplary computer system useful for implementing the communication methods, authoring methods, testing methods, and other functionality described herein;
• FIG. 5 is flow chart illustrating generally a game development or hub-based communication method of an embodiment of the invention;
• FIG. 6 is a functional block diagram of a game development system or network according to an embodiment of the invention showing use of a live authoring module along with a communications hub application to facilitate tool-to-game communications and to support live, real time authoring of video games;
• FIG. 7 is a flow chart of a live authoring process of an embodiment of the invention such as may be implemented by operation of the system ofFIG. 6;
• FIGS. 8A and 8B illustrate screenshots from display devices of two game platforms or consoles running the same video game being developed by authoring methods described herein;
• FIGS. 9A and 9B illustrates screens shots from display devices of two different game platforms running similar toFIGS. 8A and 8B after live authoring is used to update a set of game data or assets, which shows real time display of changes to a game by operation of one or more game tools and how such changes are implemented uniquely by two platforms;
• FIG. 10 illustrates a functional block diagram of a game development system (e.g., a simplified version of the systems ofFIGS. 2-4 and6 and components not shown inFIG. 10 may be included in the system ofFIG. 10) adapted for collaborative authoring of a video game;
• FIGS. 11A and 11B illustrate video game platform screenshots illustrating live authoring of a running game and also show authoring/development being performed in a collaborative way with two development tools (and/or with two authors/developers operating such tools in some examples while in others a single author may work two or more tools in a self-collaborative manner);
• FIG. 12 is a functional block diagram of a video game testing and development system (e.g., that may include at least some of the components fromFIGS. 2-4,6, and10) showing use of a communications hub application and playtesting statistics gathering tool to facilitate testing of a video game including obtaining real time feedback from a set of players or testers for modifications to the game data or tested portion of the video game;
• FIGS. 13 and 14 illustrate screenshots of test monitoring interfaces that may be provided by the playtesting statistics gathering tool or other devices of the system ofFIG. 12 to allow a user such as a game developer to access game test data in real time or “live” and also to view aggregated and/or processed data for the group of players or testers in a real time or live environment; and
• FIG. 15 is a flow chart showing the processes of an exemplary playtesting method providing real time feedback to developers or test monitors.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
• Briefly, embodiments of the present invention are directed toward methods and systems of enhancing playtesting of video games (or other software applications). The methods discussed below generally include providing a number of video games running on video game platforms (e.g., the same platform or platforms with varying configurations such consoles or devices from differing manufacturers/distributors). A group of players or testers are assigned to these platforms to playtest the game, and during the playtesting session, the method includes transmitting game play data from the video game platforms. A statistics gathering tool is in communication with the game platforms and functions to gather the transmitted game play data and then to process the game play data to generate a set of playtest statistics (e.g., number of players failing at a particular task, percentage of players defeating an opponent or level, and so on). During or concurrent with the playtesting session, the method includes displaying the playtest statistics on a monitor or display device such that a game developer is provided real-time feedback on playtesting results. The method may then include generating modifications to game data used by the game platforms to provide the video games, such as by operation of a game development tool, and transmitting the modifications to the video game platforms for use/implementation during the playtesting session to alter the running games (e.g., make a task easier or harder or otherwise alter game logic or game assets or otherwise modify the game as it is being tested). The playtest is continued after the changes such that the aggregated statistics and game play data can be collected by the statistics gathering tool and presented or displayed to the game developer (or test monitor).
• Other embodiments of the present invention are directed toward methods and systems of live authoring of video games to provide real time feedback to the authors or development team members. The live authoring methods and systems allow a development team member to create changes to a video game using one or more video game development tools and to cause these changes to be implemented on one, two, or more video game platforms with one broadcast authoring message (e.g., a message with game content or data that is implemented by running games on differing platforms). The authoring message or game update is broadcast through a game communication hub (e.g., a message with game content formatted for receipt by the hub or a hub application running on a hub server) to allow any listening client to listen and receive and react to the game update. The hub application acts to identify appropriate recipients for the message such as games (or subsystems of games) running on differing game platforms, game data storage for the game content, and/or other game development tools (e.g., a change made to a game asset or game data such as a texture property in one tool such as Adobe Photoshop is made/reflected in a game engine running the video game and also in a second tool such as Autodesk Maya) without the developer being forced to resend the message or to rebuild the game for each platform with the game asset or data changes/additions. The following description begins with a discussion of a video game development communication method and system with reference toFIGS. 1-5, and this description of use of a communications hub application to facilitate tool-to-platform communications is followed by a description of live authoring techniques with reference toFIG. 6-9B.
• Other embodiments of the present invention are directed to methods and systems for managing communications within a video game development system or network. Specifically, a game development system or network is described that lessens the processing overhead, usage complexity, and maintenance requirements for each game development tool used by a game developer by proving a central hub communication application in the development system or network that establishes a communication interface(s) between each tool and differing game platforms. The hub communication application (or the server running such an application) acts as a message passing hub that extracts (or determines) the recipients for a message issued by a development tool and transmits the content (e.g., game data such as modified game logic to be used by a game engine on a platform, a game asset such as a new character or object in 3D model or other form, and/or a game parameter such as lighting level, texturing, and the like) as-is or with reformatting to the recipients in the game development system or network.
• As background, the following description provides examples of particular computers, computing devices, workstations, video game platforms/consoles, communication networking and digital connections, memory devices, and other computing hardware and software resources used in video game development. However, it will be understood that these are only representative examples of useful implementations of the invention and not as limitations to its breadth. Further, embodiments of the invention may be thought of generally as a computer-based method for supporting communications, authoring, and testing during game development (e.g., while operating a developer terminal, node, PC, workstation, or the like and using one or more video game development tool), the particular software, firmware, and/or hardware used to implement the described methods and functions are also not limiting of the invention. In general, the algorithms, routines, and processes described herein may be implemented upon nearly any computer-readable medium that can cause a computer or computer system to perform a corresponding function. For example, the hub communication application may be provided as software or programming code for causing a computing device such as a developer's computing device or a central/networked server to perform particular functions as part of creating a game development computing and communication environment and may be stored on a memory device of nearly any node accessible via wired or wireless connections by video game development tools and run on a device that uses one or more processors or CPUs to run the software. The video game development workstations likely will include a number of input/output devices (I/O devices) such as a keyboard, a mouse or trackball or the like, a touchscreen or pad, a voice recognition mechanism, and the like. A monitor or monitors will also be provided to allow the user to view one or more user interface (such as windows created as part of the computing environment to view and/or access video game tool interfaces and view/modify game data such as game logic, game settings, game assets, game parameters, and the like). Such user interfaces may be nearly any combination of menus, screen designs, keyboard commands, command language, and the like (including in some cases mice, touch screens, and other input hardware such as voice recognition) to allow a user to interact with a computer and with video game digital assets and data stored in memory in a particular computing environment. The invention may also be implemented using one or more data servers that may communicate with the workstations over a digital communications network such as the Internet, a local area network, a wide area network, or the like using any of a number of well-known or later developed communications protocols (wired or wireless), and the browsers and related applications may be provided as web applications accessible in particular computing environments.
• To assist in understanding some of the benefits of such a hub-based communication system and method as part of the game development and testing process, it may be useful to discuss an existing or more conventionalgame development system100 as shown inFIG. 1. In a conventionalgame development system100, a number of developers may usedworkstations110,128 to present a computing or workingenvironment112,130 in which one or more development tools114,134 (such as the Maya Plugin, a Variable Tweaker tool, a logic update tool, and the like) are run so as to develop a video game. This game may be run on a number of differing video game platforms or consoles as shown as platform A and platform B with the running games shown asboxes160,170. Thecomputing environment112,130 of eachworkstation110,128, may include memory ordata storage117,137 that is used to store a communication/interface library orplatform communications data119,139. Such communications data may define all or some subset of the messaging formats and transmittal protocols expected by each video game platform, and, typically, each of the sets ofplatform communications data119,139 defines an at least partially different set of rules that must be followed for thetools114,134 to communicate properly with the runninggames160,170 on the platforms. If a developer were working with just one platform, this may not be too much of an issue, but more often eachdevelopment workstation110,128 and runningtools114,134 are used to develop agame160,170 for use on two, three, or more video game platforms. Hence, it is important for thetools114,134 to be able to communicate with each platform or game running160,170 on such varying platforms (such as those developed and distributed by Sony, Microsoft, Nintendo, and other gaming platform manufacturers).
• Presently,development tools114,134 used in the video game industry typically provide no communications or, if they do provide a form of communication, function as shown by using a one-to-one connection120,126,140,146 between thetool114,134 and the running games/platforms160,170. To establish communications, thetools114,134 may be thought of as creatingcommunication clients116,122,136,142 for eachgame160,170 that they wish to communicate with during development/operation ofsystem100. Further, such one-to-one communications may be thought of as requiring thetools114,134 to each create and managecommunication sockets118,124,138,144 to allowdirect messaging120,126,140,146 to and from the runninggames160,170. In thesystem100, each tool needs to understand how to communicate with eachplatform160,170 separately. For example, a communication link along with messages formatted as required by thecommunication data119 for aparticular platform160 likely cannot be used for sending a message with the same content to theother platform170. In a more concrete example, acertain tool114 or134 may use one set ofcommunication data119,139 (e.g., information/data provided in a video game platform developer's SDK or the like) to update objects or other game assets/data on a Sony PS3 platform (or first platform) but could not use these same communication techniques/methods to send messages updating the same objects or other game assets/data on a Microsoft Xbox 360 (or second platform). Further, the one-to-one communication technique has not been useful in allowing tools to communicate between each other or with other tools as thetools114,134 generally would need to have explicit knowledge of the other running tools in order to establish a connection.
• In contrast,FIG. 2 illustrates a game development system ornetwork200 that is adapted such that the individual games do not have to have knowledge of the particular platform communications data and/or rules or even what games and/or tools are “listening” or connected to thegame network200. The system200.again includes a pair ofdeveloper workstations210,250 that are running videogame development tools212,251, but only asingle connection214,252 is maintained/used by eachtool212,251 to communicate with bothgames230,240 running on two differing platforms and, optionally, with other tools (which is not typically done within thesystem100 ofFIG. 1).
• Thesystem200 simplifies game development communications by including a developer communications hub220 (e.g., a server or other computing device that may take the “server” role for messaging within system200). Thehub220 runs a central hub communications or message-passing application that abstracts the knowledge of platforms and existence of other tools from theindividual tools212,251, and such a centralization and abstraction of communications duties allows thetools212,251 to communicate with each other and with anygame platform230,240 without requiring specific knowledge of the intended recipient and potential interfacing, message formatting, and other communication requirements imposed by that recipient. Thesystem200 does this generally by centralizing the knowledge of how to connect withdifferent platforms230,240 into a central hub application and, in some cases, by building a client side communications library into each tool (not shown but used to allow thetools212,251 to communicate with the hub application with a relatively simple messaging protocol that can be used for all of its messaging and data transfer in system200). Such a library may also be used to allow theplatforms230,240 to connect with the hub220 (or hub communication application running thereon).
• As shown, thehub220 provides an interface to aclient222 fortools212,251 to communicate with games running on a first platform230 (shown as Platform A) as well ascommunication clients224,226 fortools212,251 to communicate with games running on a second platform240 (shown as Platform B inFIG. 2). Thehub220 includes memory ordata storage225 for storing communications data or libraries227 (such as those provided in video game SDKs and the like) for each of theplatforms230,240. The information is used by the hub application running onhub220 to provide the interfaces between thetools212,251 that send the hub-formatted messages overlinks214252 andgames230,240 running on differing platforms and linked tohub220 vialinks228,242. The communications may be managed, in part, by the hub application creatingcommunications clients222,224,226 based on theplatform communications data227 inmemory225. During operation ofsystem200, atool212 or251 transmits a message overlink214 or252 (such as a message to modify a lighting setting or a texturing of an object of the game or so on) that is formatted per the client-side hub library (not shown inFIG. 2). Thehub220 acts to determine which recipients should receive the message content such as one or both of the games on the twoplatforms230,240 andtool212 or251. Thehub220 then uses the appropriate communications data/libraries227 to reformat/translate the message for each recipient (and/or uses the createdclients222,224,226 to manage such communications and comply with communication rules). Thehub220 then forwards the message to the interested or determined set of recipients in thesystem200. As can be seen from the relatively general illustration ofsystem200, thetools212,251 andgames230,240 need only know how to talk or communicate with thehub220, and there is no need for specific knowledge of the communication rules of the intended recipient(s) to send game information or data out onto the network orsystem200 and to the recipient(s). In contrast to thesystem100 ofFIG. 1, thetools212,251 do not need to manage communication clients and/or sockets for each possible platform or store/access communications data/libraries for each game platform. Further, thesystem200 allows thetools212,251 to communicate with each other (as is explained in more detail below).
• FIG. 3 illustrates in more detail a videogame development system300 that may be used to implement the communication methods of an embodiment of the invention. In this embodiment, adeveloper computing system310 is shown that includes aCPU312 running two or more videogame development tools316,318 such as those used to create 3D models, to set or adjust game logic, to create objects, characters, or other game assets, and so on. I/O devices314 may be provided to allow a developer to interact with thetools316,318 and game data, and one ormore monitors320 are included to viewtool GUIs322 and otherwise view/interact withtools316,318 and game data. Thesystem310 further includesmemory324 that stores client-side hub communications data/library338, and this includes data to enable thetools316,318 to communicate with the communication hub application354 (and through thisapplication354 with games underdevelopment372,382 or other ones of thetools316,318 (or tools onother systems310 not shown). Thememory324 is also shown to include agame application320 such as a game being developed or a recent build of such a game (or this data may be stored on another memory device accessible bysystem310 and other developer systems). Thegame application330 includes game data such asgame assets332,game logic334, andgame settings336, and thegame application330 can be thought of as being defined by this game data; hence, game development includes using thetools316,318 to create and modify the game data inmemory324 and/or on arunning game372,382 on a number of video game platforms/consoles370,380.
• Thesystem300 also acommunications network340 that is used to connect thedeveloper system310 with ahub server350. Thehub server350 includes aCPU352 that runs acommunications hub application354. TheCPU352 also managesmemory356 that is shown to store a list of clients (e.g., platforms, tools, games or subsystems of games registered with the hub application, and the like) for receiving system communications. Thememory356 also stores platform communication data (e.g., SDK communication libraries for eachplatform370,380) for eachplatform370,380 in thesystem300 or expected to be added to/used withinsystem300. Thehub server350 runs thecommunication hub application354, and theapplication354 may function to provide acommunication interface362 between thetools316,318 and thegame platforms370,380 (and betweentools316,318 themselves). To this end, acommunication client364,366,368 may be created by thehub application354 using the platformcommunication data sets360 for eachplatform370,380 as well as rules/protocols for communicating with the workstation/system310.
• During operation of thesystem300, each of thegame development tools316,318 may use the client-side hub library338 as a built-in or runtime communication mechanism to create and manage a hub communication socket or link342,344 vianetwork340 to send messages to and from thehub application354 onserver350. These messages may include game data such as modifyinggame logic334 or anasset332 ongames372,382 (e.g., the same game running on two differing platforms). Thehub application354 processes these messages viainterface362 andclients364,366,368 and/orcommunication data360 to determine the recipients for the message, to place the message in the expected format for those recipients, and to transmit the message overlinks376,386,342,344 as appropriate. The list ofclients358 may include thevideo games372,382 or one of thetools318 and each message may be sent to one, a set of, or all of such recipients depending on the content (who is registered as being interested in that type of content/message) and/or on a recipient list/addressee in the message from thetool316,318 (such as to a particular game or game subsystem or to any tools interested in a particular game data).
• FIG. 4 generally illustrates a game development system ornetwork400 that may be used to implement the hub or centralize communication techniques and other functions/processes described herein. Thenetwork400 includes acomputer system402, which typically is used by a game developer (or member of a video game development team) and includes a processing unit or CPU203 and system memory205 with one or more game development tools that may be run by CPU203. As discussed above, each of the game development tools or programs may have a built-in client-side communications library that provides the information required for the program to communicate with a central communication hub application running on a remote computer250 (or on one of thedeveloper computer systems402 in a distributed system/network), and, in this manner, messages generated by the game development programs can be relatively simple and/or generic in form and be delivered via the central communication hub application to games running on first and second (or more)platforms451,453 that may have differing communication requirements (e.g., differing message configuration/content, differing transmission protocols, differing communication and/or client interfaces, and the like such as may be specified by each platform developer's SDK or a communication library in the SDK or otherwise specified).
• Asystem bus407 couples various system components includingsystem memory405 toprocessing unit403.System bus407 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.System memory405 includes read only memory (ROM) and random access memory (RAM). A basic input/output system (BIOS)456, containing the basic routines that help to transfer information between elements withincomputer system402, such as during start-up, is stored inROM456.Computer system402 further includes various drives and associated computer-readable media. Ahard disk drive409 reads from and writes to a (typically fixed) magnetichard disk411; amagnetic disk drive413 reads from and writes to a removable “floppy” or othermagnetic disk415; and anoptical disk drive417 reads from and, in some configurations, writes to a removableoptical disk419 such as a CD ROM or other optical media, and, of course, other removable memory devices may be inserted into and accessed (read and/or writing of data) via a port such as a USB or other communication port in a housing of thesystem402.Hard disk drive409,magnetic disk drive413, andoptical disk drive417 are connected tosystem bus407 by a harddisk drive interface421, a magneticdisk drive interface423, and anoptical drive interface425, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, programs, procedures, routines, data structures, program modules, and other data for computer system402 (such as initial installation of the client-side communications library and/or for backup storage/transfer of game application or game assets). In other configurations, other types of computer-readable media that can store data that is accessible by a computer (e.g., magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROMs) and the like) may also be used.
• A number of program modules such as game development tools, testing routines, and the like may be stored onhard disk411, removablemagnetic disk415,optical disk419 and/or ROM and/or RAM ofsystem memory405. Such program modules may include an operating system providing graphics and sound APIs, one or more application programs, other program modules, and program data such as game data. A user may enter commands and information intocomputer system402 through input devices such as akeyboard427 and a pointing device ormouse429. Other input devices may include a microphone, a joystick, a game controller, wireless communication devices, a scanner, or the like. These and other input devices are often connected toprocessing unit403 through aserial port interface431 that is coupled tosystem bus407, but may be connected by other interfaces, such as a parallel port interface or a universal serial bus (USB) or by wireless connections. A monitor(s)433 or other type of display device is also connected tosystem bus407 via an interface, such as avideo adapter435 such as for viewing game development and game testing GUIs or other game data.
• Computer system402 may also include amodem454 or other means for establishing communications overwide area network452, such as the Internet.Modem454, which may be internal or external, is connected tosystem bus407 via serial port interface431 (or some other interface). Anetwork interface456 may also be provided for allowingcomputer system402 to communicate (e.g., establish communication sockets and the like) with a remote computing device orserver450 via a local area network458 (or such communication may be viawide area network452 or other communications path such as dial-up or other communications means).Computer system402 typically includes other peripheral output devices, such as printers and other standard devices (not shown).Computer system402 is preferably equipped with an operating system supporting Internet communication protocols and/or other digital communications network protocols and communication interfaces (e.g., to support digital communications with the central communications hub oncomputer250 via messages generated and transmitted based on the definitions/requirements of the client-side communication library typically built into the game development programs). Other types of computer systems other than or in addition to the one shown are usable to practice the invention (e.g., a local area network of computers, an interactive television, a personal digital assistant, an interactive wireless communications device, electronic devices with adequate computing capabilities and memory, or the like).
• FIG. 5 illustrates a video gamedevelopment communications method500 such as may be implemented by thesystems200,300,400 ofFIGS. 2-4. At504, themethod500 starts such as by loading or providing a central hub application within a video game development system or network. The communications data or libraries for each game platform or console that is being used or may later be connected to the network may be made available to the central hub application. At510, themethod500 continues with providing client-side communications data or a hub library to each of the development tools (or to the workstations that run such tools). The client side library may be a runtime library stored in the workstation memory. The client-side libraries include the data or information (such as messaging configuration/format and/or other communications protocols) to allow the tools to communicate with central hub application. At520, themethod500 continues with registering development tools and/or video game(s) with the hub application to create a recipient list for the development network or system. Tools may register to be informed when particular game data is altered while the video games typically are registered in a subsystem manner to receiving communications/messages from tools including modified game data (e.g., a materials subsystem, an objects subsystem(s), a texturing subsystem, a lighting subsystem, and so on may each register with the hub application for a particular video game running upon a game platform linked to the development system or network). This aspect of the system allows tools to direct messages to a particular subsystem instead of relying on the game to determine the appropriate subsystem itself.
• Themethod500 then may include the hub application monitoring the communication network for a next message to be transmitted from a tool or game. When a message is received at the hub, themethod500 continues at540 with the hub application acting to identifymessage recipients540. For example, in some embodiments, the tools may transmit messages in a generic manner with no addressees specified, and in such cases the message may be sent to all recipients on the hub recipient list or a subset interested in a particular type of message or message content. In other cases, the message may be transmitted by the tool in a form that specifies one or more (a set) of recipients for the message, e.g., a message to a game running on one platform or another tool. At550, the hub application translates and/or reformats the message as appropriate based on the identified recipients and the communications data (rules, libraries, and the like) associated with each of these identified recipients. For example, a hub-formatted message from a tool may be reformatted or translated to comply with communications data/rules for a first game platform and also for a second game platform. Then at560, themethod500 continues with the hub application forwarding the message to all identified recipients or to clients requesting the game information in the message. In some cases, the hub application handles opening communication links or sockets for each platform (and/or for each recipient or the like). Themethod500 may continue at530 with waiting for additional game development or related messages or end at590. Generally, themethod500 may be used for one-to-one communications as a tool or other sender of the development network may specify the recipient or addressee, but themethod500 also supports a one-to-many connection or broadcasting communication methods as a tool can make a change to a particular game data (such as tweak a portion of the game logic) and transmit a generic hub-format message that will be sent by the hub application to all interested recipients (e.g., to all games or game subsystems affected by the change). As a result, a developer does not have to create and send a message for each platform to have the change implemented by running games.
• FIG. 6 illustrates agame development system600 adapted particularly for supporting live authoring of video games on two or more different game platforms or consoles (e.g., Microsoft's Xbox, Sony's Playstation consoles, Nintendo's Gamecube or Wii, and the like). Thesystem600 includes a number of components similar to those discussed in detail with thesystem300 ofFIG. 3 with like numbers being used for those components and the description ofFIG. 3 is applicable toFIG. 6. For example, thesystem600 includes ahub server350 running acommunications hub application354 that functions to receivemessages690,691 fromgame development tools316,318 running oncomputer610. Thesemessages690,691 are formatted according to ahub communication library615,617 shown as a built-in library fortools316,318, and thehub application354 acts to process the messages to determine a set recipients specified in the message or, more typically, from content of themessages690,691 and from comparison to aclient list358 of interested listening clients (e.g.,other tools316,318,games674,684, or storage management components for the centrally located/stored game data644). The receivedmessages690,691 are then reformatted/translated for each recipient based oncommunications data360 for that recipient (e.g., what format doesplatform670 expect/require? and so on) and forwarded to those recipients via the network340 (or via a direct connection (not shown)).
• Likewise, thedeveloper computer system610 is similar tosystem310 in that it includes aCPU312, I/O devices314, and amonitor320 for displaying information including game data intool GUIs322. Thesystem610 also uses theCPU312 to run one or moregame development tools316. In this case, eachtool316,318 is able to link to and communicate with thecommunications hub application354 using a built-in,client side library615,617 that defines how to interface and communicate with thehub application354 including how to formatauthoring messages690,691. In thesystem600, adata storage server640 is included that is accessible by thetools316,318 vianetwork340 and includesmemory642 storing the game application data644 (e.g., game assets such as created objects, character models and animation, game logic, parameter/variable settings, and other information used by a game engine in running a video game). Asgame tools316,318 access the data644 (e.g., display current values in a tool GUI or the like), a tool cache ormemory624 may be used byCPU312 to storegame data630 such asgame assets632,game logic634, and variable/parameter settings636 for efficient access bytools316,318.
• During operation of thedeveloper computer system610, a developer may call up or use a number ofgame development tools316,318. For example, alogic adjustment tool316 or318 may be used that provides aGUI322 that presents thepresent game logic634 orsettings636 and allows it to be readily adjusted or tweaked (e.g., how fast a character runs, how much high a character jumps, how many times an opponent has to be struck to fall, and so on) such as with pull down boxes with logic value choices, slide bars to adjust values, data entry boxes, and the like. Anothertool316,318 may be used to create a new animation or to modify an existing model or object such as by changing its texture, by moving its position within a screen, modifying its size, and so on via aGUI322 displayed onmonitor320.
• According to one important aspect of thesystem600, the developer is able to obtain instantaneous or real time feedback on these changes in previously built and running video games on two or more differing game platforms (e.g., on Sony's PS3 concurrently with Nintendo's Wii consoles and so on). As shown, thesystem600 includes at least twogame platforms670,680 that includegame engines672,682 to rungame applications674,684. The runningvideo games674,684 functionality is controlled in part by thegame assets676,686 such as 3D models of characters and other animations, level design, game play logic, lighting settings, textures, coloring, and so on. When thevideo game674,684 is run by theengines672,682 avideo display678,688 of the platform orgame system670,680 is used to display the game to players such as testers and, in this case, to the developers.
• To provide real time feedback, thedeveloper computer system610 includeslive authoring modules616,618 associated with or built in to eachdevelopment tool316,318. Thelive authoring module616,618 functions (as is discussed with reference toFIG. 7) to cause (or facilitate) changes or additions to thegame data630 for a video game to be broadcast as shown withauthoring messages690,691 from thetools316,318 through thehub application354 to a list of recipients orinterested clients358 of thehub server350. Theauthoring messages690,691 are formatted according to client-sidehub communications libraries615,617 for receipt by thehub application354 while thehub application354 uses platform/client communications data360 to translate each of the messages it sends out over network340 (or directly) to a list of recipients. The recipients for the reformatted (when necessary)authoring messages690,691 may be runninggame applications674,684 and other ones of thegame development tools316,318. This allows a developer to implement a change in the game assets such as to make a change to a character skin or clothing with one tool316 (such as Adobe Photoshop) and have that change broadcast viaauthoring message690 for distribution in proper platform/recipient form bycommunications hub application354, and the developer or use ofsystem610 will see the results of the change in both runninggames674,684 as thegame assets676,686 are updated based on received game data updatemessages694,696 transmitted by thehub application354. Additionally, the change may be broadcast to the other game development tool318 (such as Autodesk Maya) with another update message (not shown) fromhub application354. A gamedata update message692 may also be sent from thehub application354 to a data orcentral storage server640 to cause the game data for thenew game644 to be updated to reflect the changes made withtool316.
• In this manner, asingle authoring message690 or691 from atool316,318 may be used to cause multiple changes to be concurrently implemented within any number ofgame platforms670,680 as well asother tools316,318, and this can be achieved without the developer having to have knowledge of eachplatform670,680, without creating and sending multiple messages, and without having to reprocess or create new builds of the runninggame applications674,684 as the authoring is “live” or performed with real time feedback. Rebuilds of games, in contrast, are undesirable as they may take several minutes to complete.
• FIG. 7 illustrates a live videogame authoring method700 of an embodiment of the invention such as may be implemented by operation of thesystem600 ofFIG. 6. Themethod700 starts at706 such as by choosing a number of video game development tools for use in creating a new video game, loading such tools onto a workstation (or making the tools available from a server in a network or distributed computing environment). The video game may be designed for use on more than one video game platform, and at705 this set of video game platforms or consoles will be selected or defined. As discussed above, modifications to game logic, objects, textures, lighting, coloring, and other game assets/data may be processed by a game engine of each platform differently such that it is desirable for a developer to be able to view the results of changes to a running game in real time on the various platforms (e.g., with the displays of the platforms positioned side-by-side or nearby to allow ready comparisons of displayed games).
• At710, themethod700 continues with configuring the game development system for hub communications, e.g., for allowing a tool to send a single message in a format understood by the hub application that can then determine a recipient list, translate/reformat the message based on the communication requirements of each recipient, and broadcast/forward the authoring or game data update message to the set of recipients. To this end, client-side libraries may be provided on the game developer's computer or workstation such as modules built in or accessed by each game tool to allow the tools to communicate with properly formatted messages to the hub application, and hub application is provided in the system and communicatively linked to the tools (such as via a communication network). The hub application is provided access to communications libraries or data sets (e.g., communications libraries provided with a game platform SDK and the like to manage communications with clients associated with a potential recipient list within the developer system, which may include other development tools (e.g., a PC client may be utilized/supported by the hub application) as well as game data central storage.
• At720, themethod700 continues with providing and/or loading a live authoring module or modules on the developer computer system(s). For example, a single authoring module may be provided to support a set of development tools or an instance may be provided for each development tool to support communications with the hub application upon changes to the game data with a tool. At728, themethod700 continues with a developer using the game development tools (or other mechanisms) to create new game assets or to modify existing game data or assets (such as changing the logic to make a particular move or portion of a game easier or harder).
• At730, themethod700 includes determining whether automated messaging has been activated within the live authoring module. For example, it may be a default setting for the live authoring module for authoring messages to be broadcast automatically upon a game development tool linked to an authoring module being used to create or update a game asset or game data. In other embodiments, the game developer may be given the option of making such messaging automatic or to select an option in which they are prompted by the authoring module after making a change with a tool to send an authoring message to the running video games (and other interested clients/recipients) via the central communication hub. In this regard, if the messaging is not automated (e.g., handled by the authoring module without further action by the developer), themethod700 continues at740 with the live authoring tool prompting the user or developer to transmit a game update message such as by displaying a message in workstation monitor or tool GUI asking if the updated data should be sent in an authoring message or whether to remind the developer later (e.g., upon another asset addition or modification). At746, themethod700 includes determining whether the message transmittal is authorized. If not, themethod700 may continue at740 as shown or return to step728 (e.g., await a next change to a game asset). In other embodiments/implementations, the data is always sent if possible and typically always handled. In such cases, themethod700 is adapted to from prompting a user, especially when they may end up skipping one change and then allowing a second change, which is dependent upon the first, which may cause problems.
• If messaging is automated or has been authorized, themethod700 continues at750 with the live authoring module acting to transmit the authoring message to the communications hub application. The authoring message is in a format called for the by the hub application (e.g., in a client-side library), and the message content typically is the game data addition (e.g., a new object or character) or a change to an existing game asset such as to modify game logic, change a variable or parameter setting or position, and so on. At760, the hub application receives the message, determines a set of recipients or clients to receive the message, translates each based on a corresponding communications data set defining/controlling communications with that recipient, and transmits or forwards the messages with game data to each identified recipient.
• At770, the game data for the video game may be updated to reflect the game data in the authoring message (e.g., in centralized storage location accessible by one or more developers working on one or more workstations). At780, themethod700 continues with the game engine running the game application with the updated game data or assets as presented in the authoring message broadcast from the development tool. Themethod700 may end at790 or return to step728 to allow the developer(s) to make additional revisions or additions of the game data. In this manner, the developer can author a change or set of changes to a video game, broadcast a single authoring message with one, two, three, or more additions and/or changes to the game data or assets, and view the resulting effects these changes/additions have on the running game application within one, two, or more game platforms or consoles.
• FIGS. 8A and 8B illustratescreen shots810,820 of a video game that may be running upon two differing game platforms such as by two differing companies' game consoles. Often, it is preferable to create a single set of game data for a video game rather than creating a separate set for each game platform, and while a game application running on two differing platforms may appear nearly identical when displayed on the consoles' monitors there typically are at least minor differences in the display. In some cases, a change to a game asset such as a lighting level or texture of a scene element may have a desirable appearance on one platform while having an appearance or resulting effect that is undesirable on a second platform. Additionally, different pre-processing steps may be employed that take source data to engine ready. These steps can be run as part of the send to the hub or, in some cases, by another tool listening for updates going through the hub that would intercept, process, and re-send data.
• For example, the game data or assets used by a game application and/or game engine running the game application may be identical for thescreen shots810,820. As shown, agame character812 withclothing814 is shown to be jumping from the floor/ground818 toward the top of a game object (e.g., a column in this case)816. Thecharacter812 is shown to jump to a particular height, H_jump, while theobject816 has a particular height, H_object. In screen shot820 corresponding to a different game platform, thecharacter822 is shown to haveclothes824, and theclothes824 may have a different appearance thanclothes814. Similarly, the game shot820 shows the floor828 with a texture similar to that offloor818 but with some small differences. Yet further, anobject826 is included but its height, H_object, differs from that ofobject816 and/or the height of the jump, H_jump, may differ for thecharacter822. From this illustration, it can be seen that a set of game data may be processed differently or produce differing results for a game application run on two differing platforms. This makes it desirable for a developer to view a running game while (e.g., “live”) they make changes to the game data or assets and, preferably, to view the same game running on two or more platforms to allow a determination of whether the change or addition to the game assets is desirable or effective.
• FIGS. 9A and 9Bshow screen shots910,920 of the video game at the same location/position in the game and for the same two platforms but after several changes have been made to the game data. The change may be implemented with live authoring techniques described herein such as by changing several game assets and then issuing a live authoring messages with the changed content. In some embodiments, a single change or addition may be made with each message while other embodiments may have a developer performing several changes and sending all changes within a single authoring message. In the illustrated example, a developer has used game development tools to make several changes to the game data. The game logic has been modified such that the height of the jump, H_jump, of thecharacter912,922 in response to a player input is greater. Theobject916,926 has also been modified by reducing its height, H_object. Further, the texture of the flooring/ground918,928 has been modified.
• The modified game assets/data is used by the two game engines/platforms associated withscreen shots910,920 but, as is shown, the changes to the game data results in at least partially differing results or effects for the game display or game output. For example, the texturing of thefloor918,928 may appear somewhat different, the height the character jumps may be slightly different, and/or the height of theobject916,926 may differ for the two platforms with the same game data. Of course, not every game data change or addition will result in a different game effect for differing platforms, but it is very useful for a developer to be able to verify the effects of their editing or authoring in real time (or nearly instantaneously as the game display is modified based on changes) and for the effects to be verified/tested for all platforms for which the game is being designed. The live authoring tool with use of the communications hub application technology allows live authoring to be carried out in a game development system with efficient messaging and without requiring iterative steps of creating new builds of a game on every platform (e.g., a useful portion of the live authoring processes is that builds of multiple games running on differing platforms receive game data changes concurrently with the tool or developer workstation sending message(s) to the communications hub). Also, as discussed, multiple content/logic changes can be sent/made in real time, which significantly increases the efficiency of a developer making numerous edits/changes to a video game.
• In some game development environments, it is desirable for two or more game development tools to communicate with the same live instance of a video game on one or more video game platforms. For example, it may be useful for a developer to use two tools concurrently to work on a video game including changing differing portions of the game data (e.g., level design and game assets such as texturing, lighting settings, game logic, and so on). In other examples, two game developers may wish to work on the same portion or location within a video game concurrently with the same or differing game development tools. In some embodiments, a game development system configured as discussed above (e.g., seeFIGS. 2-4 and6 and the like) with a hub application may be used to allow content (or game data) changes performed or made by separate individuals (e.g., development team members) to be reflected in the same game simultaneously (or at least without requiring the game instance to be stopped, one set of changes made, rebuild the game, and then allow a next developer to work on the game). In some cases, the developers' respective tools may listen to communications (e.g., register as clients with the hub or the like) and update their game data on the client end (e.g., on the separate workstations) in real time or on an ongoing/live manner. As a more specific example, a texture artist using Adobe Photoshop (or another game development tool) may be working simultaneously or at least partially concurrently with a world designer using Autodesk Maya (or another game development tool), and as the texture artist tweaks or updates the texture, the change may be reflected in a running game instance on a set of video game platforms and also in the world designer's view or tool GUI of Maya. Additionally, the world designer may be changing or tweaking game data such as object positions and the changes they are making may reference the same texture being adjusted or authored by the other developer. Such collaborative authoring with real or near real time feedback on a running game instance and game tool GUI had previously been unavailable in the one-to-one (tool to game) connections used by game developers.
• FIG. 10 illustrates a videogame development system1000 adapted for supporting collaborative authoring methods and functions. Note, thesystem1000 is shown in a somewhat simplified manner to highlight portions that may be used in collaborative authoring but thesystem1000 may include any of the components and software devices discussed herein such as shown inFIGS. 2-4 and6. To support collaborative authoring of a video game, thesystem1000 includes a set ofdeveloper systems1010,1030 that may be operated by the same or, more typically, different authors or game developers. Amonitor1012,1032 is provided on eachsystem1010,1030 along with one or moregame development tools1020,1040. Thegame development tools1020,1040 are communicatively linked with ahub350, which runs acommunications hub application354 as described throughout this description, and thehub application354 uses platform and other client communication libraries or rule sets360 and registered client lists358 to support communications between thetools1020,1040 and a live, runningvideo game instance1074 as well as withother tools1020,1040 on the same or differing computers.
• During operation of thesystem1000, thegame development tools1020,1040 access centralized game data storage (not shown inFIG. 10) andstore game data1028,1046 in memory orcache1026,1044. Thetools1020,1024 use themonitors1012,1032 to display a tool GUI (or tool interface)1014,1034 that includes or is created based upongame data1028,1046. Concurrent with operation of thetools1020,1040, thesystem1000 includes one ormore game platforms1070 that use agame engine1072 to run aninstance1074 of the video game being worked on by thetools1020,1040, with theinstance1074 being run based on thepresent game data1076 including any updates orchanges1078 generated by use of thetools1020,1040. Thegame engine1072 may use or support use of one or more display and/oroutput devices1080 to provide the game output1084 (e.g., video images, sounds, music, dialog, and/or other audio output, controller tactile feedback, and the like defined or provided by the running game instance1074).
• In thisexemplary embodiment1000, a hub communications library ordata set1024,1042 is provided for eachtool1020,1040 and is used by thetools1020,1040 to transmit orbroadcast authoring messages1050,1052 to thehum350. Thecommunications hub application354 then determines recipients, translates themessages1050,1052 (which are in a format expected/required by the hub application354) to a form expected/required by each identified recipient, and then transmits a set of gamedata update messages1054,1056,1058. In the collaborative mode of operation, theclient list358 may include thetools1020,1040 (e.g., eachtool1020,1040 listens for changes to thegame data1028,1046 it uses/references). Theauthoring messages1050,1052 are transmitted generally after thetools1020,1040 are used to createupdates1029,1048 to thegame data1028,1046. These changes/content are included by thehub application354 in thedata update messages1054,1056,1058 such that thegame data1076 used by the live, runningvideo game instance1074 includes or is provided based on the game data updates1078. As a result, the game images/output1084 provided by theplatform output devices1080 is “live” or provides real time feedback after theauthoring messages1050 and/or1052 are transmitted.
• Significantly, themessages1050,1052 may be transmitted independently or in an overlapping manner to support collaborative authoring as a user ofdevelopment system1010 or1030 may continue work withtool1020 and1040 to author or modify thegame1074. In other words, “concurrent” and/or collaborative authoring is generally intended to mean that two ormore tools1020,1040 may work on a single game instance1074 (or instances running on two or more platforms1070) and communicate changes or updates with each other and/or with the running game (e.g., to have real time or live feedback regarding the changes provided by operation of thegame platform1070 and in theirtool GUIs1014,1034). Theupdates1029,1048 made by one or both of thetools1020,1040 are also reflected in the tool'sgame data1028,1046 such that work by each developer is provided in a timely manner to each developer, and thetool GUI1014,1034 may include theupdates1029,1048 such as shown with collaboratingauthor changes1015,1035 (e.g., changes made by the other one of the authors and not just with thetool1020 or1040 associated directly with thetool GUI1014,1034).
• FIGS. 11A and 11B illustratescreenshots1120,1140 that may be provided during operation of thesystem1000 ofFIG. 10. As shown inFIG. 11A, agame platform1070 may be running an instance of agame1074 and with a first set ofgame data1076 may create theoutput1084 shown inscreenshot1120 on theplatform monitor1080. In thescreenshot1120, acharacter1122 is shown jumping from scene element/object1128 (e.g., a floor, the ground, or the like) toward or onto another game object1126 (e.g., a platform, a column, or the like). As shown, the column orgame object1126 has a particular position in the game level or scene, and the floor orgame object1128 has a texture1130 (which is shown to be at a first stage of development/completion).
• As shown inFIG. 11B, thegame platform1070 may continue to run the instance of thegame1074 but with a set ofgame data1076 that has been updated with game data changes/modifications1078. In this example, theupdates1078 have been provided by twotools1020,1040 with one tool being used for texturing thefloor1128 while the other is being used to adjust object positions. Hence, as shown inFIG. 11B, thescreenshot1140 shows thefloor1128 at a later stage of development/completion for the texture1131 (or, in some cases, the texture/material1131 may be a newly created and applied texture/material). Also, thescreenshot1140 shows the column orgame object1126 being moved as shown witharrow1127 to a new position relative to the character1122 (e.g., to make a jump or other move easier or harder). Numerous other changes may be made by allowing two ormore tools1020,1040 to access a live instance of agame1074 and to provideupdates1078 to thegame data1076. Also, the changes1078 (such as the modification of thetexture1130 to1131) may be transmitted to theother tool1020,1040 and reflected (when appropriate) in thetool GUI1014,1034 such as when the tool interface includes a representation of a game object whose texture or other characteristics have changed as result of game updates performed by another tool.
• The hub communications applications and tool-to-game platform communication techniques described herein may also be utilized to provide unique and effective playtesting of video games. The playtesting described below may be thought of as “real-time” in that collected data from the game is transmitted via the communications hub to a playtesting monitoring system (or developers workstation/computer) and presented as the playtesting is occurring (e.g., with no or minor delays) on one or more monitors. Real-time playtesting turns what used to be a static game testing environment into a dynamic, interactive process. Interactivity is provided by the use of development tools or other devices to transmit game modifications (e.g., changing logic to make a function or process easier or harder or the like) via the communications hub to the game platforms (which may be differing types of platforms requiring differing communication protocols for messaging) where the game engine running the video game application uses the modified game data to nearly instantaneous provide a revised game to the game players (e.g., all of the games may be modified in a like manner or a subset may be modified to determine if the change has a desired or predicted effect).
• In some preferred embodiments, the video game testing system is adapted such that the game play data is monitored in real time rather than evaluating the results of a given testing session after the fact (e.g., days or weeks after the test group has left the test facility). Data is collected from each game player or individual tester and reported back to a centralized location such as a monitoring computer system or a developer's workstation adapted for playtest monitoring. From this central location or system, changes can be made by the developer such as by operating a video game development tool to transmit authoring messages with new game data/content to via the communications hub application to one or more of the running video games (e.g., a game mod recipient set). The results of this game modification or change can be determined nearly immediately because the game players or individual testers are still in the test facility and play the revised running game or instance of the game on one or more game platforms. For example, if a significant portion such as a majority of the game players are having difficulty completing a given jump (or other game task/function), the level designers or other development team members can “on the fly” or in near real time shorten the distance to see if this modification to the running game helps increase the success rate to a desired level (e.g., still some amount miss the jump if desirable to provide a challenge at this point in the game). A statistics gathering tool may be run to store the change to game data and when in the test that the change was made such that the game modification or “tweak” is tracked and stored along with other playtest tracking data.
• The game modification may be made on all game platforms or in all running game instances or for some smaller fraction or subset (e.g., 50 percent, 10 percent, 80 percent or the like), and the players may be grouped based on one or more criteria and the subset selected out of one or more of these groups (e.g., modify 30 percent of the running games for the highest skill level players, modify 70 percent of the running games for the players under 30 years old, modify 40 percent of the running games for the male players, or nearly any other combination of fraction of the games and grouping of players). The use of real-time monitoring of playtesting combined with modifying the game in a single play session ensures that the playtesters or test group of players is of a consistent skill level, which in the past had led to wide ranges of results as the skill of two groups of players often varied widely. The communications hub application allows any number of game clients to connect and send nearly any type of game play information or data through the hub to a statistics gathering and processing tool(s) for real-time processing/evaluation and display to monitoring individuals (e.g., members of the development team). One or more authoring or game development tools can connect to the same communications hub application and distribute tweaks or modifications to the game data to some or all of the playtesters during the playtest.
• FIG. 12 illustrates a videogame playtesting system1200 of an embodiment of the invention that is adapted for providing developers with real-time feedback of test results and also for allowing these developers to make changes to the running video games while the same control group is available to play the game. As shown, thesystem1200 includes aplaytesting facility1210 in which a plurality ofgame platforms1212 are provided, and, as discussed above, these may be the same platform or may vary to allow the same game to be tested on a variety of consoles/systems. Eachplatform1212 includes agame engine1214 to run a video game application1216 (or a portion that is ready for testing) based on a set ofgame data1218, which typically will be in an initial testing state and then will include test modifications or changes1220 as discussed below to tweak or change some game feature (such as amount of life or energy lost at being struck by an opponent or the like) after gathering and processing a quantity (e.g., a half hour, an hour, a number of attempts or repeats of a level or game portion, or the like) of test or play data. A display and/oroutput device1224 is provided as part of theplatform1212 and operates during game play or testing to provide game images and other output such as audio and tactile feedback output.
• As thegame1216 is played by a set of testers,game play data1230 is transmitted to thehub server350 that includes acommunications hub application354 that communicates (as discussed in detail above) usingclient communications libraries360 and client lists358 stored in memory with thegame platforms1212 and with aplaytest monitoring system1240. In particular, thehub application354 forwards thegame play data1230 to theplaytest monitoring system1240 in a form accepted/expected by the monitoring system1240 (or client applications running thereon such as thestatistics gathering tool1250 and game development tool(s)1254) astesting data messages1232.
• Themonitoring system1240 often will be operated by a game developer or development team member to tweak or fine tune aspects of avideo game1216 during or as part of performing playtesting at thefacility1210. To this end, thesystem1240 includes I/O devices1244 managed by aCPU1242 to allow an operator to input or select game changes ortest modifications1264 via interaction with agame development tool1254 and/or to view and manipulate results of game testing. Amonitor1244 is provided that may be used by a playtestingstatistics gathering tool1250 to display atest monitoring interface1246, e.g., to display aggregated playtest information to the developer. Themonitor1244 may also be used by thegame development tool1254 to display adevelopment tool GUI1245 to display thegame data1262 that is presently being used by the game (shown at1218) and is being tested and to allow the developer to make changes or tweaks to the game logic or other game assets/settings (e.g., shorten a jump, increase life/energy of a character upon reaching a check point, and so on). In other embodiments, a separate tool is utilized that is not necessarily part of themonitor1244.
• As discussed above, thedevelopment tool1254 may use a built in (or accessible)hub communications library1256 to communicate with thehub application354 withgame authoring messages1270 that typically will include testing mods or game data changes1264 made via thetool1254 andinterface1245. Thehub application354 determines the appropriate clients and sendstest modification messages1276 to the clients orgame applications1216 onvarious platforms1212 in the facility1212 (or to other development tools as discussed above). The clients receiving themodification messages1276 may then modify theirgame data1218 to include the modifications1220 and the runningvideo game1216 will reflect the changes to allow the testing by the same control group to continue to verify the effectiveness or usefulness of the changes. Thegames1216 receiving the changes1220 may be all of the runninggames1216 or some smaller subset selected by an operator of themonitoring system1240 such as a fraction of all games or a fraction of a subgroup of the games and so on.
• The playtestingstatistics gathering tool1250 may function to record all the receiveddata1266 inmemory1260, but, typically, thetool1250 also is configured to perform aggregation functions and to present processed/aggregateddata1247 within aninterface1246. For example, thegathering tool1250 may act to generate andstore1266 and then display aggregatedstatistics1247 such as numbers of players, average scoring/energy at various game checkpoints, number of players beating a level or challenge and how many attempts it requires, and so on. This aggregation of statistics bytool1250 is preferably done on an ongoing basis concurrently with the operation of theplaytesting facility1210 such that developers have real-time feedback on the results of the playtesting of thegame1216. Thestatistics gathering tool1250 may also display player statistics for each of the players as shown at1248 ininterface1246. Theindividual player stats1248 may include demographic information such as age and sex as well as other more gaming specific information such as number of years of gaming experience and skill ranking (if available, while thesystem1200 is useful in some aspects not because of knowledge of the skill levels but because the control group is the same before and after a test mod1220 is sent to and implemented in a running game1216).
• FIGS. 13 and 14 illustrate a pair ofscreenshots1310 and1410 that may be provided by the statistics gathering tool of thesystem1200. In thescreenshot1310, the monitor screen is divided into two areas with one displaying player statistics in player windows/boxes1320 and theother portion1350 being used to display aggregated playtest statistics. For example, aplayer window1320 may be provided for each member of the control group or each tester. In this embodiment, a thumbnail of the game playing status or game screen shot1322 is provided that shows where the player is in the game (e.g., with a still shot that is periodically updated or the like), but the game position/status may be provided also with text, symbols, and other displayed information. Theplayer window1320 also includes aplayer data section1330 that provides the developer or playtest monitor with information about the game player or tester. For example, but not as a limitation, theplayer data1330 may include aplayer ID1332 for each player along with a game/client address1336 such as would allow the test monitor to transmit test mod messages to specific ones of the testers to test a game change. Theplayer data1330 may also includedemographic information1334 such as age, sex, and the like and, if the players/testers are grouped as part of the testing (or by the statistics gathering tool), the demographics or player ID may include information indicating which group or subset of the game testers or control group the player has been assigned.Game status information1340 may also be provided in theplayer data1330 such as theircurrent score1342, the amount of life orenergy1344 their character has in the game, and other statistics such as position in the game.
• The testing described herein preferably includes some level of processing or aggregating of the game data from the testers to facilitate game development and decisions on how to improve the current game version. To this end, theaggregation section1350 includes atitle1352 indicating which game is described and includes a number of aggregated statistics or game test results determined by processing and/or aggregating the collected test data. For example, thestatistics1350 may include average scoring for a game or portion ofgame1354, may include percentage of players that lose or die at particular locations or tasks of thegame1356, may include average damage or loss of energy/life at various points of games1358 (e.g., how much energy does it require to reach a checkpoint or to perform a battle, and so on), and/or may include number of players passing/beating a level on a first (or other) attempt. Numerous other statistics or playtest results may be determined by the statistics gathering tool and displayed in an interface as shown withscreenshot1310. In some cases, the system is also used to capture spatial information that can be overlaid on top of an authoring environment to provide context (e.g., where do people die or fail often in a game or the like).
• In alternate oradditional screenshot1410, the statistics gathering tool may be used to group the game players or testers into groups based on various criteria and to display these various groups (or theplayer windows1320 and their aggregated statistics1350). For example, the criteria used to form threegroups1420,1430,1440 may be age or skill levels or these variable combined with gender of the players such as when the game may be more targeted to particular ages (such as tweens) or to particular genders. As shown, within each grouping on thescreen1410, a set ofplayer windows1424,1434,1444 are provided to allow a test monitor to quickly determine the status of the various players or testers in each group. Though not shown, a statistics/aggregated results window/box such as shown at1350 may be provided for eachgroup1420,1430,1440 to allow the test monitor to more rapidly compare the playing experience for each group (e.g., one group finds the game or a portion of the game easy or hard while another group may have a very different experience). The output or game test data displayed in thescreenshots1310,1410 may be utilized by a game developer to select test or game modifications (via operation of a game development tool) to implement within the entire control group or just on the machines/platforms of particular groups, fractions of groups, or even individual players.
• FIG. 15 illustrates aplaytesting method1500 that may be implemented by operation of thesystem1200. Themethod1500 starts at1505 such as with selection of a video game for playtesting, establishing a testing protocol, identification of a control group or set of testers, and gathering demographic data on the testers. At1510, themethod1500 includes configuring the testing system for hub communications such as by installing/loading a central hub application and communicatively linking this hub application with the game platforms in a test facility and game development tools to allow real-time game modifications during a test. At1520, themethod1500 includes linking or connecting one or more statistics gathering tools to the hub application, and the statistics gathering tool may run on any computer device within the test system such as on the hub server or a developer workstation. At1530, themethod1500 includes identifying a test group and storing player data in memory accessible by the statistics gathering tool.
• At1536, themethod1500 includes initiating game play in a test facility (or in platforms in a distributed test system which may even include online game testing as “facility” is not intended to be limiting to a particular physical location or room). Instep1536, a video game is run on a plurality of game platforms that may be the same configuration (e.g., all from one platform company) or may vary as the communications hub application allows the statistics gathering tool (and development tools) to communicate including receiving game play data from the various platforms and sending game data changes or authoring messages from the development tool to the running games. At1540, themethod1500 includes collecting game play data as the games are played by the control group of testers or game players and also using the statistics gathering tool to store this data, to aggregate and/or process the data, and to determine various statistics or test parameters or values based on the game data.
• At1550, the statistics gathering tool provides a test monitoring interface on a monitor of a developer workstation or monitoring system, and the interface includes at least portions of the gathered game data such as calculated statistics and/or player data and status information (e.g., seeFIGS. 13 and 14). At1560, the developer may act to make game changes or modifications based on the displayed game data/statistics, e.g., operate a game development tool to change game logic, to change game assets, and/or so on. Themethod1500 includes determining whether the modifications are made either automatically as discussed with an authoring tool or in response to an authoring message being sent by the development tool (e.g., manual message creation and transmission). At1570, when a modification is made, themethod1500 continues with using the communications hub application to identify clients (e.g., games running on platforms in a test facility based on content and/or based upon addressees in the messages such as a subset of the games in the control group). The messages are transmitted in proper format for the various platforms. At1580, the game engines are used to run video games with test modifications on all or a subset of the game platforms. Themethod1500 may continue at1540 to repeat gathering data after the game play data has been changed and tested by the control group. Additional changes may be made at1560 in an iterative process (e.g., real-time game testing and updating/development). At1590, themethod1500 ends such as at the end of the playtest session.
• It is understood that the present disclosure has been made only by way of example, and that numerous changes in the combination and arrangement of parts can be resorted to by those skilled in the art without departing from the spirit and scope of the invention, as hereinafter claimed. For example, the playtesting methods described herein may be used with testing and developing other forms of software and other products in which feedback may be provided by computer software through a communications hub application to a monitoring system. In such product development environments, the testing information is gathered, processed, and displayed at least with some overlap with the testing session (e.g., while the testers are still available to test product modifications). A software development or authoring tool is used to transmit product modifications to the testing facilities (e.g., a set of computers or electronic devices running a software application) such as by sending authoring messages with content including such changes via the communication hub module or application. The modified product is tested with the implemented modifications by the same or nearly the same control group, and the results/data are sent to the statistics gathering tool for processing and/or display on the monitoring station. This iterative, real-time process is effective for more quickly fixing usability issues with software products and also for fine tuning product features and design aspects in response to tester feedback or tester experiences (as measured by collection of test data).

Claims (20)

1. A video game testing system facilitating game authoring during testing, comprising:

a set of video game platforms operating during a playtesting session to provide a video game based on game data;

a server with a communications hub module communicatively linked with the video game platforms; and

a monitoring system with a playtest statistics gathering tool receiving game play data related to a set of players playing the video games, the game play data being transmitted from the video game platforms via the communications hub module, and wherein the playtest statistics gathering tool processes the game play data and outputs aggregated statistics based on the processing during the playtesting session.

2. The system ofclaim 1, further comprising a game development tool issuing authoring messages to the game platforms via the communications hub module, wherein the authoring messages comprise content including modifications to the game data and wherein the authoring messages are transmitted during the playtesting session to affect the video games provided by the game platforms.

3. The system ofclaim 2, wherein the authoring messages with the game data modifications are transmitted to a subset of the game platforms, whereby a fraction of the video games are modified during the playtesting session.

4. The system ofclaim 2, wherein the playtest statistics gathering tool repeats the receiving of the game play data, processing of the game play data, and outputting the aggregated statistics after transmittal of the authoring messages, whereby real-time feedback regarding game updates is provided by output of the monitoring system.

5. The system ofclaim 1, wherein the monitoring system comprises a monitor displaying an interface to the playtest statistics gathering tool including a display of at least a portion of the aggregated statistics.

6. The system ofclaim 5, wherein the interface further comprises a portion of the game play data linked to individuals within the set of players.

7. The system ofclaim 6, wherein the set of players are further divided into subgroups based on one or more parameters and wherein the aggregated statistics include information corresponding to game play be the players one or more of the subgroups.

8. The system ofclaim 1, wherein the authoring messages are transmitted to the game platforms after configuration by the communications hub module according to communications data sets associated with the game platforms.

9. The system ofclaim 8, wherein the game platforms comprises at least two configurations and wherein the communication data sets differ for the game platforms based upon the configurations of the game platforms receiving the authoring messages.

10. A playtesting method for video game development, comprising:

during a playtesting session, providing a plurality of instances of a video game running on video game platforms;

transmitting game play data from the video game platforms corresponding to a set of players playing the video game instances;

gathering the transmitted game play data with a statistics gathering tool running on a computer system;

with the statistics gathering tool, processing the gathered game play data to generate a set of playtest statistics; and

during the playtesting session, displaying the set of playtest statistics on a monitor, whereby a developer of the video game is provided with feedback on game play results during the playtesting session.

11. The method ofclaim 10, wherein the game platforms communicate with networked devices using two or more communications libraries defining messaging protocols and further comprising operating a communications hub application receiving the transmitted game data and forwarding the received game data to the statistics gathering tool in a single form.

12. The method ofclaim 10, further comprising collecting player data from the players in the set of players and wherein at least a portion of the collected player data is displayed on the monitor with the set of playtest statistics.

13. The method ofclaim 10, further including operating a game development tool to generate modifications to game data used by the video game platforms to provide the video game instances and transmitting the generated modifications to a set of the video game platforms during the playtesting session to alter the corresponding video game instances.

14. The method ofclaim 13, further comprising, after the transmitting of the generated modifications, repeating the transmitting of the game play data, the gathering, the processing, and the displaying of the set of playtest statistics.

15. A system for testing a software program, comprising:

a set of at least two computing platforms each running a software program based on a set of program data;

a server running a central hub application providing a communication interface to the computing platforms;

a statistics gathering module running on a computer linked to the central hub server, the statistics gathering module collecting data related to use of the software program by a set of operators, processing the collected data, and at least partially concurrently with the use of the software application by the operation displaying the processed data on a display screen.

16. The system ofclaim 15, further comprising a development tool generating an authoring message with modifications to the set of program data, wherein the central hub application forwards the authoring message to the computing platforms for use in running the software program and wherein the authoring message is generated concurrently with the use of the software program by the operators and with the collecting of data by the statistics gathering module.

17. The system ofclaim 16, wherein the computing platforms comprise video game platforms and wherein the software program comprises at least a portion of a video game application.

18. The system ofclaim 17, wherein the authoring message comprises game data affecting operation of the video games running on the video game platforms including modifications to game logic.

19. The system ofclaim 17, wherein the processed data displayed on the display screen includes game play status for the operators.

20. The system ofclaim 19, wherein the operators are grouped based on at least one demographic parameter and the processed data is displayed on the display screen at least partially based on the demographic grouping of the operators.

Images