Register or Login To Download This Patent As A PDF
United States Patent Application |
20100144444
|
Kind Code
|
A1
|
GRAHAM; FRASER
|
June 10, 2010
|
REAL-TIME, VIDEO GAME PLAYTESTING
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.
Inventors: |
GRAHAM; FRASER; (SALT LAKE CITY, UT)
|
Correspondence Address:
|
DISNEY ENTERPRISES, INC.;c/o Marsh Fischmann & Breyfogle LLP
8055 East Tufts Avenue, Suite 450
Denver
CO
80237
US
|
Assignee: |
DISNEY ENTERPRISES, INC.
Burbank
CA
|
Serial No.:
|
349622 |
Series Code:
|
12
|
Filed:
|
January 7, 2009 |
Current U.S. Class: |
463/42 |
Class at Publication: |
463/42 |
International Class: |
A63F 9/24 20060101 A63F009/24 |
Claims
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; anda 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 5, wherein the interface further comprises a
portion of the game play data linked to individuals within the set of
players.
7. The system of claim 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 of claim 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 of claim 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; andduring 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 17, wherein the processed data displayed on the
display screen includes game play status for the operators.
20. The system of claim 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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001]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
[0002]1. Field of the Invention
[0003]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.
[0004]2. Relevant Background
[0005]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.
[0006]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.
[0007]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).
[0008]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.
[0009]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.
[0010]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.
[0011]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.
[0012]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).
[0013]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.
[0014]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
[0015]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).
[0016]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.
[0017]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).
[0018]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.
[0019]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.
[0020]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
[0021]FIG. 1 is a functional block diagram of a video game development
system or network configured according to prior communication methods;
[0022]FIG. 2 illustrates a functional block diagram in contrast to the
system of FIG. 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;
[0023]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;
[0024]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;
[0025]FIG. 5 is flow chart illustrating generally a game development or
hub-based communication method of an embodiment of the invention;
[0026]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;
[0027]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 of
FIG. 6;
[0028]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;
[0029]FIGS. 9A and 9B illustrates screens shots from display devices of
two different game platforms running similar to FIGS. 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;
[0030]FIG. 10 illustrates a functional block diagram of a game development
system (e.g., a simplified version of the systems of FIGS. 2-4 and 6 and
components not shown in FIG. 10 may be included in the system of FIG. 10)
adapted for collaborative authoring of a video game;
[0031]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);
[0032]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 from FIGS. 2-4, 6, and 10) 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;
[0033]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 of FIG. 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
[0034]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
[0035]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).
[0036]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 to FIGS. 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 to FIG. 6-9B.
[0037]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.
[0038]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.
[0039]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
conventional game development system 100 as shown in FIG. 1. In a
conventional game development system 100, a number of developers may used
workstations 110, 128 to present a computing or working environment 112,
130 in which one or more development tools 114, 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 as boxes 160, 170. The computing
environment 112, 130 of each workstation 110, 128, may include memory or
data storage 117, 137 that is used to store a communication/interface
library or platform communications data 119, 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 of platform communications data 119, 139
defines an at least partially different set of rules that must be
followed for the tools 114, 134 to communicate properly with the running
games 160, 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 each
development workstation 110, 128 and running tools 114, 134 are used to
develop a game 160, 170 for use on two, three, or more video game
platforms. Hence, it is important for the tools 114, 134 to be able to
communicate with each platform or game running 160, 170 on such varying
platforms (such as those developed and distributed by Sony, Microsoft,
Nintendo, and other gaming platform manufacturers).
[0040]Presently, development tools 114, 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 connection
120, 126, 140, 146 between the tool 114, 134 and the running
games/platforms 160, 170. To establish communications, the tools 114, 134
may be thought of as creating communication clients 116, 122, 136, 142
for each game 160, 170 that they wish to communicate with during
development/operation of system 100. Further, such one-to-one
communications may be thought of as requiring the tools 114, 134 to each
create and manage communication sockets 118, 124, 138, 144 to allow
direct messaging 120, 126, 140, 146 to and from the running games 160,
170. In the system 100, each tool needs to understand how to communicate
with each platform 160, 170 separately. For example, a communication link
along with messages formatted as required by the communication data 119
for a particular platform 160 likely cannot be used for sending a message
with the same content to the other platform 170. In a more concrete
example, a certain tool 114 or 134 may use one set of communication data
119, 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 the tools 114, 134 generally would need to have explicit
knowledge of the other running tools in order to establish a connection.
[0041]In contrast, FIG. 2 illustrates a game development system or network
200 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 the game
network 200. The system 200.again includes a pair of developer
workstations 210, 250 that are running video game development tools 212,
251, but only a single connection 214, 252 is maintained/used by each
tool 212, 251 to communicate with both games 230, 240 running on two
differing platforms and, optionally, with other tools (which is not
typically done within the system 100 of FIG. 1).
[0042]The system 200 simplifies game development communications by
including a developer communications hub 220 (e.g., a server or other
computing device that may take the "server" role for messaging within
system 200). The hub 220 runs a central hub communications or
message-passing application that abstracts the knowledge of platforms and
existence of other tools from the individual tools 212, 251, and such a
centralization and abstraction of communications duties allows the tools
212, 251 to communicate with each other and with any game platform 230,
240 without requiring specific knowledge of the intended recipient and
potential interfacing, message formatting, and other communication
requirements imposed by that recipient. The system 200 does this
generally by centralizing the knowledge of how to connect with different
platforms 230, 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 the tools 212, 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 system 200). Such a library
may also be used to allow the platforms 230, 240 to connect with the hub
220 (or hub communication application running thereon).
[0043]As shown, the hub 220 provides an interface to a client 222 for
tools 212, 251 to communicate with games running on a first platform 230
(shown as Platform A) as well as communication clients 224, 226 for tools
212, 251 to communicate with games running on a second platform 240
(shown as Platform B in FIG. 2). The hub 220 includes memory or data
storage 225 for storing communications data or libraries 227 (such as
those provided in video game SDKs and the like) for each of the platforms
230, 240. The information is used by the hub application running on hub
220 to provide the interfaces between the tools 212, 251 that send the
hub-formatted messages over links 214 252 and games 230, 240 running on
differing platforms and linked to hub 220 via links 228, 242. The
communications may be managed, in part, by the hub application creating
communications clients 222, 224, 226 based on the platform communications
data 227 in memory 225. During operation of system 200, a tool 212 or 251
transmits a message over link 214 or 252 (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 in FIG. 2). The
hub 220 acts to determine which recipients should receive the message
content such as one or both of the games on the two platforms 230, 240
and tool 212 or 251. The hub 220 then uses the appropriate communications
data/libraries 227 to reformat/translate the message for each recipient
(and/or uses the created clients 222, 224, 226 to manage such
communications and comply with communication rules). The hub 220 then
forwards the message to the interested or determined set of recipients in
the system 200. As can be seen from the relatively general illustration
of system 200, the tools 212, 251 and games 230, 240 need only know how
to talk or communicate with the hub 220, 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 or
system 200 and to the recipient(s). In contrast to the system 100 of FIG.
1, the tools 212, 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, the system 200 allows the
tools 212, 251 to communicate with each other (as is explained in more
detail below).
[0044]FIG. 3 illustrates in more detail a video game development system
300 that may be used to implement the communication methods of an
embodiment of the invention. In this embodiment, a developer computing
system 310 is shown that includes a CPU 312 running two or more video
game development tools 316, 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 devices 314 may be provided to allow a developer
to interact with the tools 316, 318 and game data, and one or more
monitors 320 are included to view tool GUIs 322 and otherwise
view/interact with tools 316, 318 and game data. The system 310 further
includes memory 324 that stores client-side hub communications
data/library 338, and this includes data to enable the tools 316, 318 to
communicate with the communication hub application 354 (and through this
application 354 with games under development 372, 382 or other ones of
the tools 316, 318 (or tools on other systems 310 not shown). The memory
324 is also shown to include a game application 320 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 by system 310 and other developer
systems). The game application 330 includes game data such as game assets
332, game logic 334, and game settings 336, and the game application 330
can be thought of as being defined by this game data; hence, game
development includes using the tools 316, 318 to create and modify the
game data in memory 324 and/or on a running game 372, 382 on a number of
video game platforms/consoles 370, 380.
[0045]The system 300 also a communications network 340 that is used to
connect the developer system 310 with a hub server 350. The hub server
350 includes a CPU 352 that runs a communications hub application 354.
The CPU 352 also manages memory 356 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. The memory 356 also stores platform communication data
(e.g., SDK communication libraries for each platform 370, 380) for each
platform 370, 380 in the system 300 or expected to be added to/used
within system 300. The hub server 350 runs the communication hub
application 354, and the application 354 may function to provide a
communication interface 362 between the tools 316, 318 and the game
platforms 370, 380 (and between tools 316, 318 themselves). To this end,
a communication client 364, 366, 368 may be created by the hub
application 354 using the platform communication data sets 360 for each
platform 370, 380 as well as rules/protocols for communicating with the
workstation/system 310.
[0046]During operation of the system 300, each of the game development
tools 316, 318 may use the client-side hub library 338 as a built-in or
runtime communication mechanism to create and manage a hub communication
socket or link 342, 344 via network 340 to send messages to and from the
hub application 354 on server 350. These messages may include game data
such as modifying game logic 334 or an asset 332 on games 372, 382 (e.g.,
the same game running on two differing platforms). The hub application
354 processes these messages via interface 362 and clients 364, 366, 368
and/or communication data 360 to determine the recipients for the
message, to place the message in the expected format for those
recipients, and to transmit the message over links 376, 386, 342, 344 as
appropriate. The list of clients 358 may include the video games 372, 382
or one of the tools 318 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 the tool 316, 318 (such as to a
particular game or game subsystem or to any tools interested in a
particular game data).
[0047]FIG. 4 generally illustrates a game development system or network
400 that may be used to implement the hub or centralize communication
techniques and other functions/processes described herein. The network
400 includes a computer system 402, which typically is used by a game
developer (or member of a video game development team) and includes a
processing unit or CPU 203 and system memory 205 with one or more game
development tools that may be run by CPU 203. 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 computer 250 (or on one of the developer computer
systems 402 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) platforms 451, 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).
[0048]A system bus 407 couples various system components including system
memory 405 to processing unit 403. System bus 407 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 memory 405 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 within computer system 402, such as during start-up, is stored
in ROM 456. Computer system 402 further includes various drives and
associated computer-readable media. A hard disk drive 409 reads from and
writes to a (typically fixed) magnetic hard disk 411; a magnetic disk
drive 413 reads from and writes to a removable "floppy" or other magnetic
disk 415; and an optical disk drive 417 reads from and, in some
configurations, writes to a removable optical disk 419 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 the system
402. Hard disk drive 409, magnetic disk drive 413, and optical disk drive
417 are connected to system bus 407 by a hard disk drive interface 421, a
magnetic disk drive interface 423, and an optical drive interface 425,
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 system 402 (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.
[0049]A number of program modules such as game development tools, testing
routines, and the like may be stored on hard disk 411, removable magnetic
disk 415, optical disk 419 and/or ROM and/or RAM of system memory 405.
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 into computer system 402 through input devices such as a
keyboard 427 and a pointing device or mouse 429. 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 to processing unit 403 through a serial port
interface 431 that is coupled to system bus 407, 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 to system bus 407 via an interface, such
as a video adapter 435 such as for viewing game development and game
testing GUIs or other game data.
[0050]Computer system 402 may also include a modem 454 or other means for
establishing communications over wide area network 452, such as the
Internet. Modem 454, which may be internal or external, is connected to
system bus 407 via serial port interface 431 (or some other interface). A
network interface 456 may also be provided for allowing computer system
402 to communicate (e.g., establish communication sockets and the like)
with a remote computing device or server 450 via a local area network 458
(or such communication may be via wide area network 452 or other
communications path such as dial-up or other communications means).
Computer system 402 typically includes other peripheral output devices,
such as printers and other standard devices (not shown). Computer system
402 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 on computer 250 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).
[0051]FIG. 5 illustrates a video game development communications method
500 such as may be implemented by the systems 200, 300, 400 of FIGS. 2-4.
At 504, the method 500 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. At 510, the method 500
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. At 520, the method 500 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.
[0052]The method 500 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, the method 500 continues at
540 with the hub application acting to identify message recipients 540.
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. At 550, 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 at 560, the
method 500 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). The method 500 may continue at 530 with waiting
for additional game development or related messages or end at 590.
Generally, the method 500 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 the method 500 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.
[0053]FIG. 6 illustrates a game development system 600 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). The
system 600 includes a number of components similar to those discussed in
detail with the system 300 of FIG. 3 with like numbers being used for
those components and the description of FIG. 3 is applicable to FIG. 6.
For example, the system 600 includes a hub server 350 running a
communications hub application 354 that functions to receive messages
690, 691 from game development tools 316, 318 running on computer 610.
These messages 690, 691 are formatted according to a hub communication
library 615, 617 shown as a built-in library for tools 316, 318, and the
hub application 354 acts to process the messages to determine a set
recipients specified in the message or, more typically, from content of
the messages 690, 691 and from comparison to a client list 358 of
interested listening clients (e.g., other tools 316, 318, games 674, 684,
or storage management components for the centrally located/stored game
data 644). The received messages 690, 691 are then reformatted/translated
for each recipient based on communications data 360 for that recipient
(e.g., what format does platform 670 expect/require? and so on) and
forwarded to those recipients via the network 340 (or via a direct
connection (not shown)).
[0054]Likewise, the developer computer system 610 is similar to system 310
in that it includes a CPU 312, I/O devices 314, and a monitor 320 for
displaying information including game data in tool GUIs 322. The system
610 also uses the CPU 312 to run one or more game development tools 316.
In this case, each tool 316, 318 is able to link to and communicate with
the communications hub application 354 using a built-in, client side
library 615, 617 that defines how to interface and communicate with the
hub application 354 including how to format authoring messages 690, 691.
In the system 600, a data storage server 640 is included that is
accessible by the tools 316, 318 via network 340 and includes memory 642
storing the game application data 644 (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). As game tools 316, 318 access the data 644 (e.g., display current
values in a tool GUI or the like), a tool cache or memory 624 may be used
by CPU 312 to store game data 630 such as game assets 632, game logic
634, and variable/parameter settings 636 for efficient access by tools
316, 318.
[0055]During operation of the developer computer system 610, a developer
may call up or use a number of game development tools 316, 318. For
example, a logic adjustment tool 316 or 318 may be used that provides a
GUI 322 that presents the present game logic 634 or settings 636 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. Another tool 316, 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 a
GUI 322 displayed on monitor 320.
[0056]According to one important aspect of the system 600, 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, the system 600 includes at least two game platforms
670, 680 that include game engines 672, 682 to run game applications 674,
684. The running video games 674, 684 functionality is controlled in part
by the game assets 676, 686 such as 3D models of characters and other
animations, level design, game play logic, lighting settings, textures,
coloring, and so on. When the video game 674, 684 is run by the engines
672, 682 a video display 678, 688 of the platform or game system 670, 680
is used to display the game to players such as testers and, in this case,
to the developers.
[0057]To provide real time feedback, the developer computer system 610
includes live authoring modules 616, 618 associated with or built in to
each development tool 316, 318. The live authoring module 616, 618
functions (as is discussed with reference to FIG. 7) to cause (or
facilitate) changes or additions to the game data 630 for a video game to
be broadcast as shown with authoring messages 690, 691 from the tools
316, 318 through the hub application 354 to a list of recipients or
interested clients 358 of the hub server 350. The authoring messages 690,
691 are formatted according to client-side hub communications libraries
615, 617 for receipt by the hub application 354 while the hub application
354 uses platform/client communications data 360 to translate each of the
messages it sends out over network 340 (or directly) to a list of
recipients. The recipients for the reformatted (when necessary) authoring
messages 690, 691 may be running game applications 674, 684 and other
ones of the game development tools 316, 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 tool 316 (such as Adobe Photoshop)
and have that change broadcast via authoring message 690 for distribution
in proper platform/recipient form by communications hub application 354,
and the developer or use of system 610 will see the results of the change
in both running games 674, 684 as the game assets 676, 686 are updated
based on received game data update messages 694, 696 transmitted by the
hub application 354. Additionally, the change may be broadcast to the
other game development tool 318 (such as Autodesk Maya) with another
update message (not shown) from hub application 354. A game data update
message 692 may also be sent from the hub application 354 to a data or
central storage server 640 to cause the game data for the new game 644 to
be updated to reflect the changes made with tool 316.
[0058]In this manner, a single authoring message 690 or 691 from a tool
316, 318 may be used to cause multiple changes to be concurrently
implemented within any number of game platforms 670, 680 as well as other
tools 316, 318, and this can be achieved without the developer having to
have knowledge of each platform 670, 680, without creating and sending
multiple messages, and without having to reprocess or create new builds
of the running game applications 674, 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.
[0059]FIG. 7 illustrates a live video game authoring method 700 of an
embodiment of the invention such as may be implemented by operation of
the system 600 of FIG. 6. The method 700 starts at 706 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 at 705 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).
[0060]At 710, the method 700 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.
[0061]At 720, the method 700 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. At 728, the method 700 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).
[0062]At 730, the method 700 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), the method 700
continues at 740 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). At 746, the
method 700 includes determining whether the message transmittal is
authorized. If not, the method 700 may continue at 740 as shown or return
to step 728 (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, the method 700 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.
[0063]If messaging is automated or has been authorized, the method 700
continues at 750 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. At 760, 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.
[0064]At 770, 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). At 780, the method 700 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.
The method 700 may end at 790 or return to step 728 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.
[0065]FIGS. 8A and 8B illustrate screen shots 810, 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.
[0066]For example, the game data or assets used by a game application
and/or game engine running the game application may be identical for the
screen shots 810, 820. As shown, a game character 812 with clothing 814
is shown to be jumping from the floor/ground 818 toward the top of a game
object (e.g., a column in this case) 816. The character 812 is shown to
jump to a particular height, H.sub.jump, while the object 816 has a
particular height, H.sub.object. In screen shot 820 corresponding to a
different game platform, the character 822 is shown to have clothes 824,
and the clothes 824 may have a different appearance than clothes 814.
Similarly, the game shot 820 shows the floor 828 with a texture similar
to that of floor 818 but with some small differences. Yet further, an
object 826 is included but its height, H.sub.object, differs from that of
object 816 and/or the height of the jump, H.sub.jump, may differ for the
character 822. 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.
[0067]FIGS. 9A and 9B show screen shots 910, 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.sub.jump, of the character 912, 922 in response to a player input is
greater. The object 916, 926 has also been modified by reducing its
height, H.sub.object. Further, the texture of the flooring/ground 918,
928 has been modified.
[0068]The modified game assets/data is used by the two game
engines/platforms associated with screen shots 910, 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 the floor 918, 928 may appear somewhat different, the height
the character jumps may be slightly different, and/or the height of the
object 916, 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.
[0069]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., see FIGS. 2-4 and
6 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.
[0070]FIG. 10 illustrates a video game development system 1000 adapted for
supporting collaborative authoring methods and functions. Note, the
system 1000 is shown in a somewhat simplified manner to highlight
portions that may be used in collaborative authoring but the system 1000
may include any of the components and software devices discussed herein
such as shown in FIGS. 2-4 and 6. To support collaborative authoring of a
video game, the system 1000 includes a set of developer systems 1010,
1030 that may be operated by the same or, more typically, different
authors or game developers. A monitor 1012, 1032 is provided on each
system 1010, 1030 along with one or more game development tools 1020,
1040. The game development tools 1020, 1040 are communicatively linked
with a hub 350, which runs a communications hub application 354 as
described throughout this description, and the hub application 354 uses
platform and other client communication libraries or rule sets 360 and
registered client lists 358 to support communications between the tools
1020, 1040 and a live, running video game instance 1074 as well as with
other tools 1020, 1040 on the same or differing computers.
[0071]During operation of the system 1000, the game development tools
1020, 1040 access centralized game data storage (not shown in FIG. 10)
and store game data 1028, 1046 in memory or cache 1026, 1044. The tools
1020, 1024 use the monitors 1012, 1032 to display a tool GUI (or tool
interface) 1014, 1034 that includes or is created based upon game data
1028, 1046. Concurrent with operation of the tools 1020, 1040, the system
1000 includes one or more game platforms 1070 that use a game engine 1072
to run an instance 1074 of the video game being worked on by the tools
1020, 1040, with the instance 1074 being run based on the present game
data 1076 including any updates or changes 1078 generated by use of the
tools 1020, 1040. The game engine 1072 may use or support use of one or
more display and/or output devices 1080 to provide the game output 1084
(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 instance 1074).
[0072]In this exemplary embodiment 1000, a hub communications library or
data set 1024, 1042 is provided for each tool 1020, 1040 and is used by
the tools 1020, 1040 to transmit or broadcast authoring messages 1050,
1052 to the hum 350. The communications hub application 354 then
determines recipients, translates the messages 1050, 1052 (which are in a
format expected/required by the hub application 354) to a form
expected/required by each identified recipient, and then transmits a set
of game data update messages 1054, 1056, 1058. In the collaborative mode
of operation, the client list 358 may include the tools 1020, 1040 (e.g.,
each tool 1020, 1040 listens for changes to the game data 1028, 1046 it
uses/references). The authoring messages 1050, 1052 are transmitted
generally after the tools 1020, 1040 are used to create updates 1029,
1048 to the game data 1028, 1046. These changes/content are included by
the hub application 354 in the data update messages 1054, 1056, 1058 such
that the game data 1076 used by the live, running video game instance
1074 includes or is provided based on the game data updates 1078. As a
result, the game images/output 1084 provided by the platform output
devices 1080 is "live" or provides real time feedback after the authoring
messages 1050 and/or 1052 are transmitted.
[0073]Significantly, the messages 1050, 1052 may be transmitted
independently or in an overlapping manner to support collaborative
authoring as a user of development system 1010 or 1030 may continue work
with tool 1020 and 1040 to author or modify the game 1074. In other
words, "concurrent" and/or collaborative authoring is generally intended
to mean that two or more tools 1020, 1040 may work on a single game
instance 1074 (or instances running on two or more platforms 1070) 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 the game platform 1070 and in their tool GUIs
1014, 1034). The updates 1029, 1048 made by one or both of the tools
1020, 1040 are also reflected in the tool's game data 1028, 1046 such
that work by each developer is provided in a timely manner to each
developer, and the tool GUI 1014, 1034 may include the updates 1029, 1048
such as shown with collaborating author changes 1015, 1035 (e.g., changes
made by the other one of the authors and not just with the tool 1020 or
1040 associated directly with the tool GUI 1014, 1034).
[0074]FIGS. 11A and 11B illustrate screenshots 1120, 1140 that may be
provided during operation of the system 1000 of FIG. 10. As shown in FIG.
11A, a game platform 1070 may be running an instance of a game 1074 and
with a first set of game data 1076 may create the output 1084 shown in
screenshot 1120 on the platform monitor 1080. In the screenshot 1120, a
character 1122 is shown jumping from scene element/object 1128 (e.g., a
floor, the ground, or the like) toward or onto another game object 1126
(e.g., a platform, a column, or the like). As shown, the column or game
object 1126 has a particular position in the game level or scene, and the
floor or game object 1128 has a texture 1130 (which is shown to be at a
first stage of development/completion).
[0075]As shown in FIG. 11B, the game platform 1070 may continue to run the
instance of the game 1074 but with a set of game data 1076 that has been
updated with game data changes/modifications 1078. In this example, the
updates 1078 have been provided by two tools 1020, 1040 with one tool
being used for texturing the floor 1128 while the other is being used to
adjust object positions. Hence, as shown in FIG. 11B, the screenshot 1140
shows the floor 1128 at a later stage of development/completion for the
texture 1131 (or, in some cases, the texture/material 1131 may be a newly
created and applied texture/material). Also, the screenshot 1140 shows
the column or game object 1126 being moved as shown with arrow 1127 to a
new position relative to the character 1122 (e.g., to make a jump or
other move easier or harder). Numerous other changes may be made by
allowing two or more tools 1020, 1040 to access a live instance of a game
1074 and to provide updates 1078 to the game data 1076. Also, the changes
1078 (such as the modification of the texture 1130 to 1131) may be
transmitted to the other tool 1020, 1040 and reflected (when appropriate)
in the tool GUI 1014, 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.
[0076]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).
[0077]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.
[0078]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.
[0079]FIG. 12 illustrates a video game playtesting system 1200 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, the system 1200 includes a
playtesting facility 1210 in which a plurality of game platforms 1212 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. Each platform 1212 includes a game engine 1214 to run a
video game application 1216 (or a portion that is ready for testing)
based on a set of game data 1218, which typically will be in an initial
testing state and then will include test modifications or changes 1220 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/or output device 1224 is provided as part of
the platform 1212 and operates during game play or testing to provide
game images and other output such as audio and tactile feedback output.
[0080]As the game 1216 is played by a set of testers, game play data 1230
is transmitted to the hub server 350 that includes a communications hub
application 354 that communicates (as discussed in detail above) using
client communications libraries 360 and client lists 358 stored in memory
with the game platforms 1212 and with a playtest monitoring system 1240.
In particular, the hub application 354 forwards the game play data 1230
to the playtest monitoring system 1240 in a form accepted/expected by the
monitoring system 1240 (or client applications running thereon such as
the statistics gathering tool 1250 and game development tool(s) 1254) as
testing data messages 1232.
[0081]The monitoring system 1240 often will be operated by a game
developer or development team member to tweak or fine tune aspects of a
video game 1216 during or as part of performing playtesting at the
facility 1210. To this end, the system 1240 includes I/O devices 1244
managed by a CPU 1242 to allow an operator to input or select game
changes or test modifications 1264 via interaction with a game
development tool 1254 and/or to view and manipulate results of game
testing. A monitor 1244 is provided that may be used by a playtesting
statistics gathering tool 1250 to display a test monitoring interface
1246, e.g., to display aggregated playtest information to the developer.
The monitor 1244 may also be used by the game development tool 1254 to
display a development tool GUI 1245 to display the game data 1262 that is
presently being used by the game (shown at 1218) 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
the monitor 1244.
[0082]As discussed above, the development tool 1254 may use a built in (or
accessible) hub communications library 1256 to communicate with the hub
application 354 with game authoring messages 1270 that typically will
include testing mods or game data changes 1264 made via the tool 1254 and
interface 1245. The hub application 354 determines the appropriate
clients and sends test modification messages 1276 to the clients or game
applications 1216 on various platforms 1212 in the facility 1212 (or to
other development tools as discussed above). The clients receiving the
modification messages 1276 may then modify their game data 1218 to
include the modifications 1220 and the running video game 1216 will
reflect the changes to allow the testing by the same control group to
continue to verify the effectiveness or usefulness of the changes. The
games 1216 receiving the changes 1220 may be all of the running games
1216 or some smaller subset selected by an operator of the monitoring
system 1240 such as a fraction of all games or a fraction of a subgroup
of the games and so on.
[0083]The playtesting statistics gathering tool 1250 may function to
record all the received data 1266 in memory 1260, but, typically, the
tool 1250 also is configured to perform aggregation functions and to
present processed/aggregated data 1247 within an interface 1246. For
example, the gathering tool 1250 may act to generate and store 1266 and
then display aggregated statistics 1247 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 by tool 1250 is preferably done on an
ongoing basis concurrently with the operation of the playtesting facility
1210 such that developers have real-time feedback on the results of the
playtesting of the game 1216. The statistics gathering tool 1250 may also
display player statistics for each of the players as shown at 1248 in
interface 1246. The individual player stats 1248 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 the system 1200 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 mod 1220 is sent to and
implemented in a running game 1216).
[0084]FIGS. 13 and 14 illustrate a pair of screenshots 1310 and 1410 that
may be provided by the statistics gathering tool of the system 1200. In
the screenshot 1310, the monitor screen is divided into two areas with
one displaying player statistics in player windows/boxes 1320 and the
other portion 1350 being used to display aggregated playtest statistics.
For example, a player window 1320 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 shot 1322 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. The player window
1320 also includes a player data section 1330 that provides the developer
or playtest monitor with information about the game player or tester. For
example, but not as a limitation, the player data 1330 may include a
player ID 1332 for each player along with a game/client address 1336 such
as would allow the test monitor to transmit test mod messages to specific
ones of the testers to test a game change. The player data 1330 may also
include demographic information 1334 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 information 1340
may also be provided in the player data 1330 such as their current score
1342, the amount of life or energy 1344 their character has in the game,
and other statistics such as position in the game.
[0085]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, the aggregation section 1350 includes a title 1352
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, the statistics 1350 may
include average scoring for a game or portion of game 1354, may include
percentage of players that lose or die at particular locations or tasks
of the game 1356, may include average damage or loss of energy/life at
various points of games 1358 (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 with
screenshot 1310. 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).
[0086]In alternate or additional screenshot 1410, 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 the player
windows 1320 and their aggregated statistics 1350). For example, the
criteria used to form three groups 1420, 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 the screen 1410, a
set of player windows 1424, 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 at 1350 may be provided for each group 1420,
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 the screenshots
1310, 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.
[0087]FIG. 15 illustrates a playtesting method 1500 that may be
implemented by operation of the system 1200. The method 1500 starts at
1505 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. At 1510, the method 1500
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. At
1520, the method 1500 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. At 1530, the method 1500
includes identifying a test group and storing player data in memory
accessible by the statistics gathering tool.
[0088]At 1536, the method 1500 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). In step 1536, 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. At 1540, the method 1500 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.
[0089]At 1550, 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., see FIGS. 13 and 14). At 1560, 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. The method 1500 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). At
1570, when a modification is made, the method 1500 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. At 1580, the game engines are used to run video games
with test modifications on all or a subset of the game platforms. The
method 1500 may continue at 1540 to repeat gathering data after the game
play data has been changed and tested by the control group. Additional
changes may be made at 1560 in an iterative process (e.g., real-time game
testing and updating/development). At 1590, the method 1500 ends such as
at the end of the playtest session.
[0090]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).
* * * * *