U.S. patent application number 12/164024 was filed with the patent office on 2009-12-31 for player character matchmaking with distributed peer-to-peer functionality.
This patent application is currently assigned to MICROSOFT CORPORATION. Invention is credited to Timothy E. Rance.
Application Number | 20090325712 12/164024 |
Document ID | / |
Family ID | 41448134 |
Filed Date | 2009-12-31 |
United States Patent
Application |
20090325712 |
Kind Code |
A1 |
Rance; Timothy E. |
December 31, 2009 |
PLAYER CHARACTER MATCHMAKING WITH DISTRIBUTED PEER-TO-PEER
FUNCTIONALITY
Abstract
Video game players may become matched with other players for the
purposes of communication and/or playing together for the mutual
benefit of each in an arrangement that uses a distributed network
for implementing peer-to-peer connectivity in combination with a
matchmaking server. When a player enters a new level in the video
game, identifying information such as a level ID (identification)
is registered with the matchmaking server which may be provided as
part of a larger game service. Other players on the same level, for
example, are located using a matchmaking query. A direct
peer-to-peer connection is initiated between players, and position
updates pertaining to the players are communicated in a
peer-to-peer fashion. In an illustrative example, friends of
players are given to friends who are ensured to be seen by
reserving a predetermined number of connection slots for players or
player characters on a friends list.
Inventors: |
Rance; Timothy E.; (London,
GB) |
Correspondence
Address: |
MICROSOFT CORPORATION
ONE MICROSOFT WAY
REDMOND
WA
98052
US
|
Assignee: |
MICROSOFT CORPORATION
Redmond
WA
|
Family ID: |
41448134 |
Appl. No.: |
12/164024 |
Filed: |
June 28, 2008 |
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
A63F 13/12 20130101;
A63F 13/34 20140902; A63F 2300/408 20130101; A63F 13/795 20140902;
A63F 2300/5566 20130101; A63F 2300/556 20130101 |
Class at
Publication: |
463/42 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A system for implementing peer-to-peer matchmaking in a game
environment, comprising: a game console configured for executing
programming to implement gameplay in a game environment; a
matchmaking server accessible by the game console over a network,
the matchmaking server comprising a plurality of profiles
associated with a set of game consoles and respective player
characters, each of the plurality of profiles including an IP
address assigned to the game console and level information
associated with the player characters; memory in communication with
the matchmaking server bearing computer-readable instructions
capable of causing the matchmaking server to determine a playgroup
and to send information about the playgroup to the game console,
the playgroup a subset of the plurality of profiles; memory in
communication with the game console bearing computer-readable
instructions capable of setting up a peer-to-peer connection with
at least a portion of the playgroup; and memory in communication
with the game console bearing computer-readable instructions
capable of rendering virtual avatars of at least a portion of the
playgroup on a user interface of the game console.
2. The system of claim 1 further comprising memory in communication
with the game console bearing computer-readable instructions
capable of inviting a member of the playgroup to a group, and
memory in communication with the game console bearing
computer-readable instructions capable of receiving an acceptance
of the member of the playgroup to the invitation so that if the
member of the playgroup accepts the invitation, the memory in
communication with the game console bearing computer-readable
instructions is further capable of merging an instance of the game
console with an instance of a game console associated with the
member of the playgroup.
3. The system of claim 1 in which the memory in communication with
the game console bearing computer-readable instructions is further
capable of setting a high-water mark flag if a population of the
playgroup increases to a predetermined high-water mark.
4. The system of claim 3 in which the memory in communication with
the game console bearing computer-readable instructions is further
capable of clearing the high-water mark flag if a population of the
playgroup decreases to a predetermined low-water mark.
5. The system of claim 4 in which the memory in communication with
the game console bearing computer-readable instructions is further
capable of accessing the matchmaking server if a population of the
playgroup decreases to a predetermined very-low-water mark, the
accessing to request from the matchmaking server information about
a playgroup.
6. The system of claim 1 in which the memory in communication with
the matchmaking server further comprises memory bearing
computer-readable instructions capable of causing the matchmaking
server to perform a query of the plurality of profiles.
7. The system of claim 6 in which the query returns profiles that
are on a friends list associated with a profile of the game console
and further returns profiles that have an affinity with the profile
of the game console.
8. The system of claim 7 in which the affinity is based on at least
one of a common language, a common level of a respective plurality
of player characters, a common geographic locale of the game
consoles, a common style of play, or a common playing history.
9. The system of claim 1 in which a population of the playgroup is
predetermined, and in which a subset of the population of the
playgroup is reserved for members of a friends list.
10. The system of claim 1 in which the peer-to-peer connection is a
Winsock connection.
11. A method for matching players in a video game, the method
comprising the steps of: initiating gameplay in a first instance of
the video game for a first player; retrieving from a matchmaking
server information about a plurality of other players in a
plurality of other instances of the video game, respectively, the
plurality of other players forming a playgroup, at least a subset
of the playgroup members of a friends list of the first player, and
a remainder of the playgroup determined by an affinity to the first
player; establishing a peer-to-peer connection between the first
player and each of the playgroup; receiving position information
indicating the position of avatars associated with the plurality of
other player characters forming the playgroup in the respective
plurality of other instances of the video game; creating a virtual
avatar for each of the other player characters in the first
instance of the video game; and rendering a graphic representation
of the virtual avatars in a three-dimensional space in the first
instance of the video game at a position that is based on the
position information for the avatar associated with the other
player characters in the other instances of the video game to
enable the players to be found.
12. The method of claim 11 including the further steps of receiving
an indication from the first player that one of the plurality of
other player characters is to be invited to play in the first
instance of the game, receiving an indication that the one of the
plurality of other players has accepted the invitation, and
updating game state information for the first instance of the video
game to include the avatar for the one of the plurality of other
players.
13. The method of claim 11 including the further steps of
establishing a high water mark for the playgroup, in which if a
number of members of the playgroup reaches the high water mark,
then setting a high water mark flag and not establishing any
additional peer-to-peer connections.
14. The method of claim 13 including the further steps of
establishing a low water mark for the playgroup, in which if the
high water mark flag is set, and if a number of members of the
playgroup decreases to the low water mark, then clearing the high
water mark flag and allowing the establishing of additional
peer-to-peer connections.
15. The method of claim 14 including a further step of establishing
a very low water mark for the playgroup, in which if the number of
members of the playgroup decreases to the very low water mark, then
repeating the retrieving step.
16. The method of claim 11 in which each peer-to-peer connection is
a Winsock connection.
17. The method of claim 11 in which the affinity is one of a common
geographic locale, a common language, a common level, a common
playing history, a common style of play, or a common region of
play.
18. The method of claim 11 in which a population of the playgroup
is predetermined, and in which a subset of the population of the
playgroup is reserved for friends.
19. A computer-readable medium containing instructions which, when
executed by one or more processors disposed in an electronic
device, perform a method for operating a video game including
player characters controlled by players, the method comprising the
steps of: initiating gameplay in a first instance of a game for a
first player; retrieving from a matchmaking server information
about a playgroup formed by other player characters in a plurality
of other instances of the game, the playgroup determined by players
or player characters being on a friends list of the first player or
player character or by having an affinity with the first player or
with a player character controlled by the first player;
establishing a peer-to-peer connection between the first player and
each of the playgroup; receiving position information indicating
the position of player characters associated with respective
members of the playgroup in the respective plurality of other
instances of the game; creating a virtual avatar for each of the
other player characters in the first instance of the game; and
rendering a graphic representation of each of the virtual avatars
in a three-dimensional space in the first instance of the game at
positions that are based on the position information for the player
characters in the other instances of the game.
20. The computer-readable medium of claim 19 in which the affinity
is based on one of a common geographic locale, a common language, a
common level, a common playing history, a common style of play, or
a common region of play.
Description
BACKGROUND
[0001] Computer and video games have matured from the likes of
"Pong" into epic adventures having rich storylines, photorealistic
graphics, and complex interaction systems, thereby allowing players
to immerse themselves in the alternative reality that is emulated
by the video game. As used herein, video games may include, but are
not limited to, any game played on a data processing device.
Examples of video games may include computer games, game console
games (e.g., playable on the Microsoft Xbox.RTM., Sony
PlayStation.RTM., and/or Nintendo.RTM. 64 and Wii brand game
consoles), coin-operated or token-operated arcade games, portable
gaming device games (e.g., playable on the PlayStation Portable
("PSP".RTM.), Nintendo Game Boy and DS.TM., mobile phones,
smartphones, personal digital assistants, etc.), or other
software-driven games that are played on personal computers.
[0002] Video games come in many genres, such as first-person
shooters ("FPS"), role-playing games ("RPG"), simulation, sports,
strategy, and driving, to name a few. Each video game is not
necessarily limited to a single genre, and may indeed encompass
multiple genres. An RPG generally refers to a game in which each
participant assumes the role of a character in the game (such as an
adventurer, monster, or other game character) that can interact
within the game's virtual world. A character controlled by a
player/user is commonly referred to as a game character or player
character.
[0003] In the FPS genre, the display screen typically provides a
first person point of view, e.g., as if the player is viewing the
video game's virtual world through the eyes of the character the
player is controlling. Popular FPS games include the HALO.RTM.,
DOOM.RTM., QUAKE.RTM., and Half-Life.RTM. franchises. FPS games are
very popular, in part because they are particularly well-suited to
multiplayer gameplay.
[0004] In multiplayer play, each participant controls a player
character within the virtual environment, and the participants
either work alone or in teams to complete their objective(s) for a
particular game. The wide availability of Internet connectivity has
fueled the popularity of multiplayer video gaming as players can
use their on-line connection to locate other players and then
participate in a common game. In the multiplayer video game,
players can typically see and interact with player characters
controlled by other players, even if the other players are
physically located in another state or country. Multiplayer FPS
games may provide different objectives in various game modes, thus
providing a variety of gameplay types to participants.
[0005] For example, in one type of multiplayer play, massively
multi-player online ("MMO") games, thousands of players share the
same instance of a game world that is being played on a server. New
players are added to the instance of the game world by logging into
the server. This creates open access to the instance of the game
world and allows players to interact with every player logged into
the server.
[0006] In another type, massive open online role-playing games
("MMORPGs"), players log into a server in the same manner as they
would in a massive multi-player online game. However, instead of
placing all players in the same instance of the game, the server
creates multiple parallel instances of the game. For each instance,
the server automatically identifies a small group of players that
are to be assigned to that instance. For example, the server may
identify eight players that are playing within a single instance.
In most cases, the groups are formed based on the position of the
player characters, also termed "avatars", in the game world. An
avatar is the representation of the player in the game and can take
the form of a character or even an object, such as a car. If an
avatar moves too far away from the other avatars in the game world,
the server will transfer the avatar to another group, and thus to
another instance of the game. This transfer happens automatically
without any input from the players.
[0007] In a third type of multi-player game, a player acts as a
host and sends invitations to other players to join in an instance
of the game. To send such invitations, the player typically
interrupts a game they are currently playing to access a list of
friends or available players and to initiate a command that sends
the invitation to each of the players. If the host logs off of the
game, the instance stops. This undesirable consequence is often
termed "host migration".
[0008] In general, such grouping is important because, while in
many MMORPGs it is enough to coexist with other players since much
of the gameplay centers on one-to-one interaction, other games
require teamwork to successfully meet a goal, whether the goal is
to defeat a high-level "boss," retrieve a rare artifact, or defeat
an opposing army. In this case, players must organize themselves
together in groups or teams.
[0009] Prior attempts at such organization include lobby systems as
well as in-game systems that essentially amount to "pick up"
groups. While these attempts have met with some success, they
require considerable user motivation; consequently, they do not
generally provide a way for all players to become matched into a
group.
[0010] This Background is provided to introduce a brief context for
the Summary and Detailed Description that follow. This Background
is not intended to be an aid in determining the scope of the
claimed subject matter nor be viewed as limiting the claimed
subject matter to implementations that solve any or all of the
disadvantages or problems presented above.
SUMMARY
[0011] Video game players may become matched with other players for
the purposes of communication and/or playing together for the
mutual benefit of each in an arrangement that uses a distributed
network for implementing peer-to-peer connectivity in combination
with a matchmaking server. The matchmaking server is typically only
accessed at limited and discrete times. When a player enters a new
level in the video game, identifying information such as a level ID
(identification) is registered with the matchmaking server which
may be provided as part of a larger game service. Other players on
the same level, or having a similar identifier of affinity, are
located using a matchmaking query. A direct peer-to-peer connection
is initiated between players, and position updates pertaining to
the players are communicated in a peer-to-peer fashion. In an
illustrative example, friends of players are given to friends who
are ensured to be seen by reserving a predetermined number of
connection slots for players or player characters on a friends
list.
[0012] The present arrangement for player character matchmaking
further includes the display of simple representations of other
players, in one example glowing orbs (here termed "virtual
avatars"), that appear in one player's single-player instance of a
game. The other players are generally playing in their own
instances of the game (though some of these other players may
already be combined into one or more instances), and their
associated virtual avatars in the first instance may appear at the
same position and level as in their own instances. The virtual
avatar appearance may update in real-time so that the avatars may
appear to move around in the level.
[0013] Advantageously, bandwidth requirements for positional
updates are minimal using the distributed peer-to-peer network.
Moreover, the CPU requirements are lessened as each client need
only track a relatively small number of external players. In this
way, the implementation is highly scalable, and little if any
additional server software or hardware support will typically be
required. The present arrangement further enables a reliable way to
locate and track players on a friends list, as well as to provide
players with additional ways to meet new friends. A solution to the
issue of "host migration" is also facilitated as the present
arrangement provides a peer-to-peer solution that needs no
centralized host.
[0014] This Summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This Summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used as an aid in determining the scope of
the claimed subject matter.
DESCRIPTION OF THE DRAWINGS
[0015] FIG. 1 shows an illustrative gaming system that may be used
to implement one or more of the features of the arrangement
described herein;
[0016] FIG. 2 shows a functional block diagram of the gaming system
shown in FIG. 1;
[0017] FIG. 3 shows a functional block diagram of an illustrative
networked gaming system;
[0018] FIG. 4 shows a functional block diagram of an illustrative
online gaming environment;
[0019] FIG. 5 is a flowchart showing operation of an illustrative
gaming arrangement in which a first player character may view (and
be viewed by) other player characters in a playgroup, and in so
doing may choose to group with other player characters by inviting
the player characters to a group;
[0020] FIG. 6 shows an illustrative gaming arrangement in which a
first player character views various player characters in "ghost"
or virtual avatar form; and
[0021] FIG. 7 shows an illustrative gaming arrangement in which
players A-E are each connected to a matchmaking server.
[0022] Like reference numerals indicate like elements in the
drawings. Elements are not drawn to scale unless otherwise
indicated.
DETAILED DESCRIPTION
[0023] A server-based solution is described in U.S. patent
application Ser. No. 11/766,466, filed Jun. 21, 2007, entitled
"Live Game Lobby" owned by the assignee of the present application
and hereby incorporated by reference in its entirety which uses an
avatar-tracking server to which every player maintains a
connection. A central server uses various parameters to determine
which players to connect together, maintains all positional data,
handles disconnects, and the like. This system is sufficient for
smaller massively multiplayer online game populations but certain
difficulties may be presented at larger populations with regard to
the servers employed. Large populations tend to tax the server's
bandwidth and CPU excessively. The system is less easily scalable
overall, and the server is a separate application requiring its own
hardware and support for deployment. In addition, if an attempt is
made to ameliorate these above difficulties by distributing server
functionality, then player generally encounter difficulty locating
their friends. By comparison, the present arrangement for player
character matching utilizes a highly scalable peer-to-peer
networking arrangement that give priority to friends of a given
player.
[0024] Turning now to the drawings, FIG. 1 illustrates an example
of a gaming system 100 on which computer games, video games, and/or
other electronic games (collectively referred to herein as video
games) may be played. The gaming system 100 is only one example of
a suitable gaming system and is not intended to suggest any
limitation as to the scope of use or functionality of the features
described herein. Neither should the gaming system 100 be
interpreted as having any dependency or requirement relating to any
one or combination of components illustrated in the illustrative
operating gaming system 100.
[0025] Aspects described herein are operational with numerous other
general purpose or special purpose computing system environments or
configurations. Examples of well-known computing systems,
environments, and/or configurations that may be suitable for use
include, but are not limited to, PCs, server computers, portable
and handheld devices such as personal digital assistants ("PDAs"),
mobile phones, smart phones, handheld game devices, tablet PCs or
laptop PCs, media centers, multiprocessor systems,
microprocessor-based systems, set-top boxes, programmable consumer
electronics, network PCs, minicomputers, mainframe computers,
electronic game consoles, distributed computing environments that
include any of the above systems or devices, and the like.
[0026] Aspects herein may be described in the general context of
computer-executable instructions, such as program modules, being
executed by a computer. Generally, program modules include
routines, programs, objects, components, data structures, etc.,
that perform particular tasks or implement particular abstract data
types. The features described herein may also be practiced in
distributed computing environments where tasks are performed by
remote processing devices that are linked through a communications
network. In a distributed computing environment, program modules
may be located in both local and remote computer storage media
including memory storage devices.
[0027] The gaming system 100 may include a game console 102 and
multiple controllers, as represented by controllers 104.sub.1 and
104.sub.2. The game console 102 is equipped with a removably
attachable hard disk drive 105 and a portable media drive 106 that
supports various forms of portable storage media as represented by
optical storage disc 108. Examples of suitable portable storage
media include DVD (digital versatile disc), CD-ROM (compact
disc-read only memory), game discs, and so forth.
[0028] Game console 102 has slots 110 on its front face to support
up to two controllers, although the number and arrangement of slots
may be modified. A power button 112 and an eject button 114 are
also positioned on the front face of the game console 102. The
power button 112 switches power to the game console and the eject
button 114 alternately opens and closes a tray of the portable
media drive 106 to allow insertion and extraction of the storage
disc 108.
[0029] Game console 102 may connect to a television 118 or other
display via A/V interfacing cables 120. A power cable 122 provides
power to the game console. Game console 102 may further be
configured with broadband network capabilities, as represented by
the cable or modem connector 124 to facilitate access to a network,
such as the Internet.
[0030] Each controller 104 may be coupled to the game console 102
via a wired or wireless interface. In the illustrated
implementation, the controllers are USB (Universal Serial Bus)
compatible and are connected to the console 102 via respective USB
cables 130.sub.1 and 130.sub.2. The controllers 104 may be equipped
with any of a wide variety of user interaction mechanisms. In this
example, each controller 104 is equipped with two thumbsticks
132.sub.1 and 132.sub.2, a D-pad (directional pad) 134, buttons 136
(e.g., `A`, `B`, `X`, `Y`), and two triggers 138 (although only one
trigger is shown in the drawing). These mechanisms are merely
representative, and other known gaming mechanisms may be
substituted for or added to those shown in FIG. 1.
[0031] A memory unit 140 may be inserted into a memory unit reader
141 in the game console 102 to provide additional and portable
storage. In this example, up to two memory units may be supported
by the game console 102. Portable memory units enable users to
store game parameters and user accounts, and port them for play on
other consoles. A headset 142 may be connected to the controller
104 or game console 102 to provide audio communication
capabilities. Headset 142 may include a microphone for audio input
and one or more speakers for audio output.
[0032] Gaming system 100 is capable of playing, for example, games,
music, and videos. With the different storage offerings, titles can
be played from the hard disk drive or the portable media 108 in
drive 106, from an online source, or from a memory unit 140. For
security, in some embodiments executable code can only be run from
the portable media 108. A sample of what gaming system 100 is
capable of playing includes game titles played from CD and DVD
discs, from the hard disk drive, or from an online source, digital
music played from a CD in the portable media drive 106, from a file
on the hard disk drive (e.g., Windows Media Audio ("WMA") format),
or from online streaming sources, and digital audio/video played
from a DVD disc in the portable media drive 106, from a file on the
hard disk drive (e.g., Active Streaming Format), or from online
streaming sources.
[0033] FIG. 2 shows functional components of the gaming system 100
in more detail. The game console 102 has a central processing unit
("CPU") 200 and a memory controller 202 that facilitates processor
access to various types of memory, including a flash ROM (Read Only
Memory) 204, a RAM (Random Access Memory) 206, the hard disk drive
105, the memory unit reader 141, and the portable media drive 106.
The CPU 200 is equipped with a level 1 cache 210 and a level 2
cache 212 to temporarily store data and hence reduce the number of
memory access cycles, thereby improving processing speed and
throughput.
[0034] The CPU 200, memory controller 202, and various memory
devices are interconnected via one or more buses, including serial
and parallel buses, a memory bus, a peripheral bus, and a processor
or local bus using any of a variety of bus architectures. By way of
example, such architectures can include an Industry Standard
Architecture ("ISA") bus, a Micro Channel Architecture ("MCA") bus,
an Enhanced ISA ("EISA") bus, a Video Electronics Standards
Association ("VESA") local bus, and a Peripheral Component
Interconnects ("PCI") bus also known as a Mezzanine bus.
[0035] As one suitable implementation, the CPU 200, memory
controller 202, ROM 204, and RAM 206 are integrated onto a common
module 214. In this implementation, ROM 204 is configured as a
flash ROM that is connected to the memory controller 202 and a ROM
bus (not shown). RAM 206 is configured as multiple DDR SDRAM
(Double Data Rate Synchronous Dynamic RAM) that is independently
controlled by the memory controller 202 via separate buses (not
shown). The hard disk drive 105 and portable media drive 106 are
connected to the memory controller via the PCI bus and an ATA
(Advanced Technology Attachment) bus 216.
[0036] A 3D graphics processing unit 220 and a video encoder 222
form a video processing pipeline for high speed and high resolution
graphics processing. Data is carried from the graphics processing
unit 220 to the video encoder 222 via a digital video bus (not
shown). An audio processing unit 224 and an audio codec
(coder/decoder) 226 form a corresponding audio processing pipeline
with high fidelity and stereo processing. Audio data is carried
between the audio processing unit 224 and the audio codec 226 via a
communication link (not shown). The video and audio processing
pipelines output data to an A/V (audio/video) port 228 for
transmission to the television or other display. In the illustrated
implementation, the video and audio processing components 220-228
are mounted on the module 214.
[0037] Also implemented on the module 214 are a USB host controller
230 and a network interface 232. The USB host controller 230 is
coupled to the CPU 200 and the memory controller 202 via a bus
(e.g., PCI bus) and serves as host for the peripheral controllers
104.sub.1 and 104.sub.2. The network interface 232 provides access
to a network (e.g., Internet, home network, etc.) and may be any of
a wide variety of various wired or wireless interface components
including an Ethernet card, a modem, a Bluetooth module, a cable
modem, and the like.
[0038] The game console 102 has a dual controller port subassembly
240 which supports the game controllers 104.sub.1 and 104.sub.2. A
front panel I/O subassembly 242 supports the functionality of the
power button 112 and the eject button 114, as well as any LEDs
(light emitting diodes) or other indicators exposed on the outer
surface of the game console. The subassemblies 240 and 242 are
coupled to the module 214 via one or more cable assemblies 244.
[0039] A system power supply module 250 provides power to the
components of the gaming system 100. A fan 252 cools the circuitry
within the game console 102.
[0040] The game console 102 implements a uniform media portal model
that provides a consistent user interface and navigation hierarchy
to move users through various entertainment areas. The portal model
offers a convenient way to access content from multiple different
media types--game data, audio data, and video data--regardless of
the media type inserted into the portable media drive 106.
[0041] To implement the uniform media portal model, a console user
interface ("UI") application 260 is stored on the hard disk drive
105. When the game console is powered on, various portions of the
console application 260 are loaded into RAM 206 and/or caches 210
and 212 and executed on the CPU 200. The console application 260
presents a graphical user interface that provides a consistent user
experience when navigating to different media types available on
the game console.
[0042] The gaming system 100 may be operated as a standalone system
by simply connecting the system to a television or other display.
In this standalone mode, the gaming system 100 allows one or more
players to play games, watch movies, or listen to music. However,
with the integration of broadband connectivity made available
through the network interface 232, the gaming system 100 may
further be operated as a participant in a larger network gaming
community. This network gaming environment is described next.
[0043] FIG. 3 shows an exemplary network gaming environment 300
that interconnects multiple gaming systems 100.sub.1 . . . N via a
network 302. The network 302 represents any of a wide variety of
data communications networks. It may include public portions (e.g.,
the Internet) as well as private portions (e.g., a residential
Local Area Network ("LAN")), as well as combinations of public and
private portions. Network 302 may be implemented using any one or
more of a wide variety of conventional communications media
including both wired and wireless media. Any of a wide variety of
communications protocols can be used to communicate data via
network 302, including both public and proprietary protocols.
Examples of such protocols include TCP/IP (Transport Control
Protocol/Internet Protocol), IPX/SPX (Internetwork Packet
Exchange/Sequenced Packet Exchange), NetBEUI (NetBIOS Extended User
Interface where BIOS stands for Basic Input/Output System),
etc.
[0044] In addition to gaming systems 100, one or more online
services 304.sub.1 . . . N may be accessible via the network 302 to
provide various services for the participants, such as hosting
online games, serving downloadable music or video files, hosting
gaming competitions, serving streaming audio/video files, and the
like. The network gaming environment 300 may further involve a key
distribution center 306 that plays a role in authenticating
individual players and/or gaming systems 100 to one another as well
as online services 304. The distribution center 306 distributes
keys and service tickets to valid participants that may then be
used to form games amongst multiple players or to purchase services
from the online services 304.
[0045] The network gaming environment 300 introduces another memory
source available to individual gaming systems 100, namely online
storage. In addition to the portable media 108, the hard disk drive
105, and the memory unit(s) 140, the gaming systems 100 can also
access data files available at remote storage locations via the
network 302, as exemplified by remote storage 308 at online service
304.sub.N.
[0046] FIG. 4 is a block diagram of another illustrative online
gaming environment 400, e.g. Xbox.RTM. 360 by Microsoft
Corporation. Multiple game consoles 402.sub.1, 2 . . . N are
coupled to a security gateway 404 via a network 406. Each game
console 402 can be configured in a similar manner as game console
102 of FIG. 1 or FIG. 2, for example. Network 406 represents any
one or more of a variety of conventional data communications
networks. Network 406 will typically include packet switched
networks, but may also include circuit switched networks. Network
406 can include wired and/or wireless portions. In one exemplary
implementation, network 406 includes the Internet and may
optionally include one or more local area networks and/or wide area
networks ("WANs"). At least a part of network 406 is a public
network, which refers to a network that is publicly-accessible.
[0047] In some situations, network 406 includes a LAN (e.g., a home
network), with a routing device situated between game console 402
and security gateway 404. This routing device may perform network
address translation ("NAT"), allowing the multiple devices on the
LAN to share the same IP address on the Internet, and to operate as
a firewall to protect the device(s) on the LAN from access by
malicious or mischievous users via the Internet.
[0048] Security gateway 404 operates as a gateway between public
network 406 and a private network 408. Private network 408 can be
any of a wide variety of conventional networks, such as a local
area network. Private network 408, as well as other devices
discussed in more detail below, is within a data center 410 that
operates as a secure zone. Data center 410 is made up of trusted
devices that communicate using trusted communications. Thus,
encryption and authentication within secure zone 410 is not
necessary. The private nature of network 408 refers to the
restricted accessibility of network 408 such that access to network
408 is limited to only certain individuals (e.g., restricted by the
owner or operator of data center 410).
[0049] Security gateway 404 is a cluster of one or more security
gateway computing devices. These security gateway computing devices
collectively implement security gateway 404. Security gateway 404
may optionally include one or more conventional load balancing
devices that operate to direct requests to be handled by the
security gateway computing devices to appropriate ones of those
computing devices. This directing or load balancing is performed in
a manner that attempts to balance the load on the various security
gateway computing devices approximately equally (or alternatively
in accordance with some other criteria).
[0050] Also within data center 410 are: one or more monitoring
servers 412, one or more presence and notification front doors 414,
one or more presence servers 416, one or more notification servers
418, and a profile store 428 (collectively implementing a presence
and notification service or system 430), one or more match front
doors 420 and one or more match servers 422 (collectively
implementing a match service), and one or more statistics front
doors 424 and one or more statistics servers 426 (collectively
implementing a statistics service). The servers 416, 418, 422, and
426 provide services to game consoles 402, and thus can be referred
to as service devices. Other service devices may also be included
in addition to, and/or in place of, one or more of the servers 416,
418, 422, and 426. Additionally, although only one data center is
shown in FIG. 4, alternatively, multiple data centers may exist
with which game consoles 402 can communicate. These data centers
may operate independently, or alternatively may operate
collectively (e.g., to make one large data center available to the
game consoles 102 and 402).
[0051] Game consoles 402 are situated remotely from data center
410, and may access data center 410 via network 406. A game console
402 desiring to communicate with one or more devices in the data
center logs in to the data center and establishes a secure
communication channel between the game console 402 and security
gateway 404. Game console 402 and security gateway 404 encrypt and
authenticate data packets being passed back and forth, thereby
allowing the data packets to be securely transmitted between them
without being understood by any other device that may capture or
copy the data packets without breaking the encryption. Each data
packet communicated from game console 402 to security gateway 404,
or from security gateway 404 to game console 402, can have data
embedded therein. This embedded data is referred to as the content
or data content of the packet. Additional information may also be
inherently included in the packet based on the packet type (e.g., a
heartbeat packet).
[0052] The secure communication channel between a game console 402
and security gateway 404 is based on a security ticket. Game
console 402 authenticates itself and the current user(s) of console
402 to a key distribution center 450 and obtains, from key
distribution center 450, a security ticket. Game console 402 then
uses this security ticket to establish the secure communication
channel with security gateway 404. In establishing the secure
communication channel with security gateway 404, the game console
402 and security gateway 404 authenticate themselves to one another
and establish a session security key that is known only to that
particular game console 402 and the security gateway 404. This
session security key is used to encrypt data transferred between
the game console 402 and the security gateway 404, so no other
devices (including other game consoles 402) can read the data. The
session security key is also used to authenticate a data packet as
being from the security gateway 404 or game console 402 that the
data packet alleges to be from. Thus, using such session security
keys, secure communication channels can be established between the
security gateway 404 and the various game consoles 402.
[0053] Once the secure communication channel is established between
a game console 402 and the security gateway 404, encrypted data
packets can be securely transmitted between the two. When the game
console 402 desires to send data to a particular service device in
data center 410, the game console 402 encrypts the data and sends
it to security gateway 404 requesting that it be forwarded to the
particular service device(s) targeted by the data packet. Security
gateway 404 receives the data packet and, after authenticating and
decrypting the data packet, encapsulates the data content of the
packet into another message to be sent to the appropriate service
via private network 408. Security gateway 404 determines the
appropriate service for the message based on the requested
service(s) targeted by the data packet.
[0054] Similarly, when a service device in data center 410 desires
to communicate data to a game console 402, the data center sends a
message to security gateway 404, via private network 408, including
the data content to be sent to the game console 402 as well as an
indication of the particular game console 402 to which the data
content is to be sent. Security gateway 404 embeds the data content
into a data packet, and then encrypts the data packet so it can
only be decrypted by the particular game console 402 and also
authenticates the data packet as being from the security gateway
404.
[0055] Although discussed herein as primarily communicating
encrypted data packets between security gateway 404 and a game
console 402, alternatively some data packets may be partially
encrypted (some portions of the data packets are encrypted while
other portions are not encrypted). Which portions of the data
packets are encrypted and which are not can vary based on the
desires of the designers of data center 410 and/or game consoles
402. For example, the designers may choose to allow voice data to
be communicated among consoles 402 so that users of the consoles
402 can talk to one another--the designers may further choose to
allow the voice data to be unencrypted while any other data in the
packets is encrypted. Additionally, in another alternative, some
data packets may have no portions that are encrypted (that is, the
entire data packet is unencrypted). It is also noted that, even if
a data packet is unencrypted or only partially encrypted, all of
the data packet can still be authenticated.
[0056] Each security gateway device in security gateway 404 is
responsible for the secure communication channel with typically one
or more game consoles 402, and thus each security gateway device
can be viewed as being responsible for managing or handling one or
more game consoles. The various security gateway devices may be in
communication with each other and communicate messages to one
another. For example, a security gateway device that needs to send
a data packet to a game console that it is not responsible for
managing or handling may send a message to all the other security
gateway devices with the data to be sent to that game console. This
message is received by the security gateway device that is
responsible for managing that game console and sends the
appropriate data to that game console. Alternatively, the security
gateway devices may be aware of which game consoles are being
handled by which security gateway devices--this awareness may be
explicit, such as each security gateway device maintaining a table
of game consoles handled by the other security gateway devices, or
alternatively, implicit, such as determining which security gateway
device is responsible for a particular game console based on an
identifier of the game console.
[0057] Monitoring server(s) 412 operate to inform devices in data
center 410 of an unavailable game console 402 or an unavailable
security gateway device of security gateway 404. Game consoles 402
can become unavailable for a variety of different reasons, such as
a hardware or software failure, the console being powered-down
without logging out of data center 410, the network connection
cable to console 402 being disconnected from console 402, other
network problems (e.g., the LAN that the console 402 is on
malfunctioning), etc. Similarly, a security gateway device of
security gateway 404 can become unavailable for a variety of
different reasons, such as hardware or software failure, the device
being powered-down, the network connection cable to the device
being disconnected from the device, other network problems,
etc.
[0058] Each of the security gateway devices in security gateway 404
is monitored by one or more monitoring servers 412, which detect
when one of the security gateway devices becomes unavailable. In
the event a security gateway device becomes unavailable, monitoring
server 412 sends a message to each of the other devices in data
center 410 (servers, front doors, etc.) that the security gateway
device is no longer available. Each of the other devices can
operate based on this information as it sees fit (e.g., it may
assume that particular game consoles being managed by the security
gateway device are no longer in communication with data center 410
and perform various clean-up operations accordingly).
Alternatively, only certain devices may receive such a message from
the monitoring server 412 (e.g., only those devices that are
concerned with whether security gateway devices are available).
[0059] Security gateway 404 monitors the individual game consoles
402 and detects when one of the game consoles 402 becomes
unavailable. When security gateway 404 detects that a game console
is no longer available, security gateway 404 sends a message to
monitoring server 412 identifying the unavailable game console. In
response, monitoring server 412 sends a message to each of the
other devices in data center 410 (or alternatively only selected
devices) that the game console is no longer available. Each of the
other devices can then operate based on this information as it sees
fit.
[0060] Presence server(s) 416 holds and processes data concerning
the status or presence of a given user logged in to data center 410
for online gaming. Notification server(s) 418 maintains multiple
notification queues of outgoing messages destined for a player
logged in to data center 410. Presence and notification front door
414 is one or more server devices that operate as an intermediary
between security gateway 404 and servers 416 and 418. One or more
load balancing devices (not shown) may be included in presence and
notification front door 414 to balance the load among the multiple
server devices operating as front door 414.
[0061] Security gateway 404 communicates messages for servers 416
and 418 to the front door 414, and the front door 414 identifies to
which particular presence server 416 or particular notification
server 418 the message is to be communicated. By using front door
414, the actual implementation of servers 416 and 418, such as
which servers are responsible for managing data regarding which
users, is abstracted from security gateway 404. Security gateway
404 can simply forward messages that target the presence and
notification service to presence and notification front door 414
and rely on front door 414 to route the messages to the appropriate
one of server(s) 416 and server(s) 418.
[0062] Match server(s) 422 holds and processes data concerning the
matching of online players to one another. An online user is able
to advertise a game available for play along with various
characteristics of the game (e.g., the location where a football
game will be played, whether a game is to be played during the day
or at night, the user's skill level, etc.). These various
characteristics can then be used as a basis to match up different
online users to play games together. Match front door 420 includes
one or more server devices (and optionally a load balancing
device(s)) and operates to abstract match server(s) 422 from
security gateway 404 in a manner analogous to front door 414
abstracting server(s) 416 and server(s) 418. Other matchmaking
aspects are discussed below in connection with matchmaking server
432.
[0063] Statistics server(s) 426 holds and processes data concerning
various statistics for online games. The specific statistics used
can vary based on the game designer's desires (e.g., the top ten
scores or times, a world ranking for all online players of the
game, a list of users who have found the most items or spent the
most time playing, etc.). Statistics front door 424 includes one or
more server devices (and optionally a load balancing device(s)) and
operates to abstract statistics server(s) 426 from security gateway
404 in a manner analogous to front door 414 abstracting server(s)
416 and server(s) 418.
[0064] Thus, it can be seen that security gateway 404 operates to
shield devices in the secure zone of data center 410 from the
untrusted public network 406. Communications within the secure zone
of data center 410 need not be encrypted, as all devices within
data center 410 are trusted. However, any information to be
communicated from a device within data center 410 to a game console
402 passes through security gateway cluster 404, where it is
encrypted in such a manner that it can be decrypted by only the
game console 402 targeted by the information.
[0065] One or more features described herein may be embodied in
computer-executable instructions (i.e., software) stored in RAM
206, non-volatile memory 108, 105, 308, or any other resident
memory on game console 102. Generally, software modules include
routines, programs, objects, components, data structures, etc. that
perform particular tasks or implement particular abstract data
types when executed by a processor in a computer or other device.
The computer executable instructions may be stored on a computer
readable medium such as one or more hard disks 105, portable
storage media 108 (e.g., CD-ROM, DVD, disk, etc.), solid state
memory, RAM 206, etc. As will be appreciated by one of skill in the
art, the functionality of the software modules may be combined or
distributed as desired in various embodiments. In addition, the
functionality may be embodied in whole or in part in firmware or
hardware equivalents such as application specific integrated
circuits ("ASIC"), field programmable gate arrays ("FPGA"), and the
like.
[0066] Much of FIG. 4 shows an arrangement by which a game service
such as an MMORPG may be played. FIG. 4 also shows a matchmaking
server 432, as well as two peer-to-peer connections, which may form
a portion of the game service.
[0067] Peer-to-peer connection AB 403 is shown connecting consoles
A and B, i.e., 402.sub.1 and 402.sub.2, and peer-to-peer connection
BN 405 is shown connecting consoles B and N, i.e., 402.sub.2 and
402.sub.N. In such connections, it is noted that player A (also
called user A) is playing game instance A on gaming machine A
402.sub.1. Game instance A includes a game state A that describes
the position and status of every object and avatar, including
virtual avatars, in a three-dimensional gaming environment of game
instance A. Player B and player N are playing respective separate
game instances on respective gaming machines 402.sub.2 and
402.sub.N. Game instance B has game state B and game instance N has
game state N. Game state A, game state B, and game state N are all
different since game instance A, game instance B, and game instance
N are separate instances of the game.
[0068] Note that game instance A, game instance B, and game
instance N are all for the same game but are different instances of
that same game. As a result, the separate instances may contain
similar objects and environments but the status of at least one
object or avatar will be different in any two of the game
instances. Furthermore, the avatar for each player in a particular
instance cannot affect objects in other game instances. Thus, the
avatar for player A in game instance A cannot affect objects in
game instance B or objects in game instance N. As described herein,
players A, B, and N are said to be remote from each other because
they are using separate gaming machines. It will be appreciated
that although the players are said to be remote from each other,
they may be located in the same building or room as long as they
are using a separate gaming machine.
[0069] Turning now to FIG. 5, a flowchart is shown illustrating a
method for matchmaking players. The method begins when a first user
starts a game on the game service (step 502); in so doing the user
also establishes a session with a matchmaking server. This
matchmaking session is only for the purpose of matchmaking and in
general no one else need join the session.
[0070] Typically, the first user may have to perform an action in
order to log on to the game service. For example, during login, the
game service may obtain a gamer tag (a unique identifier associated
with the user) and a password from the user, as well as a console
ID that uniquely identifies the gaming machine that the user is
using and a network path to the gaming machine. The gamer tag and
password are authenticated by comparing them to information stored
in user records, which may be located on the same server as the
game service or may be distributed on a different server or a
collection of different servers. Once authenticated, the game
service stores the console ID and the network path in user records
so that messages and downloadable content may be sent to the
appropriate gaming machines.
[0071] In some implementations, demographic information may then be
passed to the game service (step 504). In combination or in a
separate step (as shown), a level ID is then submitted to the
matchmaking server (step 506), which may include a game identifier
as well as other information such as level, region, language used,
and the like. Additional details about such data are described
below.
[0072] A query is then performed to identify the region, for
example by a query module 510. The query may include a search to
determine which of the user's friends are online (step 508). This
query may be performed by comparing the online population with a
friends list entered or otherwise compiled by the user. A remainder
of the playgroup may then be determined (step 512).
[0073] In particular, the remainder of the playgroup may constitute
any other players that are deemed as potential group members with
the first player. These are in many cases strangers to the first
player, in the sense of not being on any sort of friends list
associated with the first player. Several factors, termed
"affinity" factors, may play a role in the determination of the
remainder of the playgroup. For example, players in the same
geographic vicinity (in the game environment or in the physical
environment, such as the same state or country) as the first player
may be chosen.
[0074] Players who share a common language with the first player
may be chosen, or those of similar skill levels or those who engage
in similar in-game activities such as fighting or exploring.
Players who are not on a "banned" list associated with the first
player may be chosen. Players who have a common playing history,
for example, that have previously played with the first player, may
be chosen. Numerous variations may be implemented to meet the needs
of a particular implementation. In addition, steps 508 and 512 may
be combined into a single playgroup determination step.
[0075] In some cases, for each player B virtual avatar seen in the
instance of player A, player B will see a virtual avatar of player
A in the instance of player B. This may be configured to be always
the case when player A and player B are on each other's respective
friends lists.
[0076] A next step is the creation of peer-to-peer connections
between the first player and other players (step 514) of the
playgroup. Following the determination of the playgroup, the
matchmaking server retrieves and provides the requisite network
pathways, e.g., IP addresses, such that a peer-to-peer connection
may be established between the first player and each other player
of the playgroup.
[0077] In an alternative implementation, following the
determination of the playgroup, a peer-to-peer connection may be
established between the first player and each other player of the
portion of the playgroup constituting friends (found in step 508),
and the remainder of the playgroup (found in step 512) may have
connections formed following the friends. In this way, friends
connections, often deemed more valuable to players, are always
reserved (and not used for strangers) and seen immediately. Other
implementations will likewise be seen. The type of connection made
may vary. However, one suitable type of connection is a Winsock
connection. Other varieties will also be understood to be
employable to create the peer-to-peer connection.
[0078] Once the peer-to-peer connections are established, the
connections are generally maintained for the duration of the game
or until a termination occurs. Terminations may occur when the
first player traverses from one level to another, when one of the
playgroup stops playing the game, or at various other times as
dictated by the system, some of which are described below.
[0079] A next step is that the first user's instance is populated
with virtual avatars of each member of the playgroup (step 516).
That is, once the peer-to-peer connections are established in the
foregoing step, the first user may receive data, in a peer-to-peer
fashion, from each member of the playgroup, and this data may be
represented as virtual avatars in the first user's instance. Each
peer in the peer-to-peer network sends the current position (step
516a) of an associated avatar in the three-dimensional gaming world
to the instances to which it is connected. A virtual avatar is then
created (step 516b) and rendered (step 516c) on a user interface of
the first user.
[0080] The avatars are virtual since they do not interact with
items in the first user's instance. The avatars are simply present
to indicate to the first user that friends, and players to whom
they have an affinity, are present and may potentially be joined in
a group. In the case that they are joined in a group, the instances
may be merged in any fashion, and gameplay may be synchronized
between the players. Additional details of the virtual avatars, the
way in which an avatar may replace a virtual avatar, conflict
resolution, and synchronization techniques, may be seen from the
patent application incorporated by reference above.
[0081] In some embodiments, each game instance may also send
attributes of the player's avatar including level, region, indoors,
outdoors, health, weapons, and awards. As the player moves the
avatar within the three-dimensional game world of the game
instance, the game instance provides position and attributes
updates to its peers. Based on this information, the new position
and attributes of the virtual avatar in the first user's instance
are updated.
[0082] The peer-to-peer network structure is used to distribute
information about the position of avatars so that an instance of a
game knows the location of player characters in other instances of
the game within a playgroup. The game instance then uses this
position information to create a position object that can be
rendered in the three-dimensional graphical environment of the
gaming instance. For example, through these embodiments, player A
is able to see a graphical representation of the position of player
B's player character in a position corresponding to the position of
player B's player character in game instance B.
[0083] The virtual avatars shown in a game instance are not able to
interact with other objects in the game instance until such time as
a group is established, in which case one or the other instance is
played by both players. Prior to that time, each position object or
virtual avatar may be displayed as a "ghost" object. Further, even
though a player's avatar may be represented by a position object in
another game instance, the player does not see the objects in that
other game instance. Instead, the player only sees the objects in
their own game instance. For example, if player B's avatar is
represented by a position object in game instance A, player B would
only see objects in game instance B and would not see the objects
or game world of game instance A, although player B may be able to
see a virtual avatar of player A's player character if player A is
in player B's playgroup.
[0084] Following the population of the first player's instance with
virtual avatars (step 516), gameplay may commence (step 520).
[0085] A feature of the present arrangement is to allow players to
find other players with whom to group, e.g., for purposes of
performing tasks, quests, raids, or the like, that they may not
otherwise be able to achieve. For this reason, a group invitation
module 530 is shown, having an initial step of one user inviting
another to a group (step 518). If the invited player accepts the
invitation (step 519), a group is established (step 522). These
steps are shown in dotted lines as the steps are optional and are
not required, generally, for performance of the arrangement.
[0086] One difficulty that may occur in certain implementations of
the arrangement is that the same players may be returned by the
matchmaking server time after time. To address this difficulty, a
connection management module 540 may be employed to prevent the
same group of players from being returned each time a query is made
by the query module 510. This ensures that a given game is
reasonably populated with orbs.
[0087] A first step performed by the connection management module
540 is to determine if the current population is below a
predetermined high water mark (HWM) (step 524). For example, a high
water mark may be set at 200 virtual avatars, which represents the
entire playgroup, friends and non-friends. If the high water mark
is reached in the initial query, then the high water mark flag may
be set at once. If the population is below the high water mark,
e.g., 200 virtual avatars are not immediately populated in the
first user's instance in the initial query, then the connection
management module 540 continues to populate the playgroup (step
528) as "external" players continue to join and be accessible by
the matchmaking server. Once the population reaches the high water
mark, then the connection management module 540 stops populating
the playgroup, and sets the high water mark flag (step 526).
Gameplay may then continue (step 520).
[0088] It is noted in this context that gameplay may generally be
allowed during any of the above population steps. There is
generally no need to cease or pause gameplay during the performance
of the arrangement.
[0089] Once the high water mark flag is set for the first user,
then no additional users will be added to the playgroup and
displayed as virtual avatars in the first user's instance until the
high water mark flag is cleared. In some implementations, players
with set high water mark flags are consequently not returned in
queries of other players. For example, as players log on and access
the matchmaking server, players with set high water mark flags will
not be displayed to those users. Of course, generally in such
circumstances, a set number of friend slots, e.g., 50 slots for
members of a friends list, will be maintained in the playgroup, so
appearances of friends will not in general be blocked by the action
of step 526.
[0090] So long as the high water mark flag is set, no additional
players or users will be added to the first user's playgroup.
However, external player connections will gradually be reduced as
players change levels, stop playing, or the like. If the total
number of connections drops to a low water mark (LWM) (step 534),
then the high water mark flag may be cleared (step 536) to indicate
the session is again open for incoming connections. Like the high
water mark, the value for the low water mark may vary, but one
exemplary value is 150 players. Once the high water mark flag is
cleared, then the instance may continue populating (step 528) until
such time as the high water mark flag is set again. If the total
number of connections drops to a very low water mark (VLWM) (step
532), then the flow may proceed to the query module 510 to re-run
the query step to attempt to bring the population up to a higher
value. Like the high water mark and low water mark, the value for
the very low water mark may vary, but one exemplary value is 100
players.
[0091] FIG. 5 shows how the matchmaking server becomes involved in
the arrangement, following the initial query, once a very low water
mark is attained. The matchmaking server also performs a new query
whenever the first user's player character moves from one level to
another, as in this case the prior virtual avatar population is
less relevant, and a new virtual avatar population may be desired.
The fact that a player moves to a new level will be registered with
the matchmaking server.
[0092] FIG. 6 shows one exemplary depiction of a small number of
virtual avatars in the region of a first user's player character
600. The player character 600 is shown in the center for clarity,
but may generally be located anywhere. A number of avatars are
disposed around the player character 600. Avatars for players with
which the player character 600 is already grouped into a single
instance, are shown in solid lines. Such avatars are not virtual
avatars but rather represent other player characters in the same
instance as the player character of the first user. Avatars 602 and
604 are indicated in this way.
[0093] Avatars 606, 608, and 610 are shown in dotted lines, and
represent virtual avatars, and generally represent player
characters in other instances of the game. The presence of avatars
606, 608, and 610 is based on information from the matchmaking
server 432, but the location, update information, appearance, and
the like, are based on information communicated in the peer-to-peer
network. As such, the information need not pass through a central
server, which could possibly create a bottleneck and reduce
performance.
[0094] FIG. 7 shows one exemplary depiction of peer-to-peer
connections between users as well as connections to a matchmaking
server 432. In this example, arrows indicate exchange of position
data. Dotted lines are matchmaking queries. The matchmaking server
432 includes a plurality of profiles 750, each including at least
an affinity factor such as a level identifier, as well as an IP
address for the game console. The profile may also include
demographic information such as preferred language.
[0095] A game console may instigate a query of the profiles 750.
The results of the query, sent back to the game console, may
include a playgroup 710. The playgroup 710 may include a number of
slots 720 reserved for members of a friends list, and the remaining
slots 730 are used for others with whom the first user has an
affinity.
[0096] The following events may then take place in such an
arrangement. Player A 702 enters the level, e.g., level 3, on his
own. Player B 704 then joins level 3, finds player A, who is listed
as a friend, and connects to player A (connection I). Player D 708
joins level 3, finds players A and B, with both of whom player D is
friends, and connects to both (connections IIa and IIb). Player C
706 joins level 3, finds player D, to which player C is a friend,
and connects to player D (connection III). Player C also finds two
strangers, players A and B, and connects to them as well
(connections IVa and IVb) based on affinity, in this case level, as
determined by the matchmaking server 432. For example, players A
and B may have been displayed in a playgroup for player C. Player E
then joins, but player E joins level 5, and thus does not connect
to any of the level 3 players (players A-D) due to lack of
affinity. Any of the peer-to-peer connections may be formed, e.g.,
by a Winsock connection 703, or by any other type of peer-to-peer
connection.
[0097] Variations of the above may also be utilized. For example,
the use of a matchmaking server need not be mandatory by all
players. While the present arrangement may be of particular use
where player characters are moving over multiple levels and/or
locales, it may be employed in any game and game system. The code
for a given arrangement may be downloaded or may be implemented as
stand-alone code that may be placed into any game. While any type
of code may be used, conventional peer-to-peer connections may be
established employing the standard Microsoft.RTM. Windows .RTM.
SDK.RTM.. The term "level" used here should be understood to mean
any locality or unity of circumstance that may give rise to one
player finding a grouping with another player potentially
beneficial. In many cases, a level may mean a mission, a quest, a
locality, or a stage.
[0098] While the present arrangement has been described in the
context of a video game, it may also be implemented in an
educational context, such as to allow students working online on
common assignments or in the same grade to work together. Other
applications will also be apparent. For example, variations in the
rendering of virtual avatars in a user interface may include only
rendering virtual avatars within an angle of vision of the first
user's player character, rendering virtual avatars on a map
display, and so on. In addition, while the context of inviting one
other player and player character within a playgroup to form a
group has been described, multiple players and player characters
may also be invited at one time or sequentially.
[0099] While the arrangement has been described with respect to a
game console, it is to be understood that the arrangement may be
implemented in any number of computing systems, including laptop
computers, desktop computers, tablet computers, handheld computers,
mobile phones, smart phones, game consoles, and the like.
[0100] And although the subject matter has been described in
language specific to structural features and/or methodological
acts, it is to be understood that the subject matter defined in the
appended claims is not necessarily limited to the specific features
or acts described above. Rather, the specific features and acts
described above are disclosed as example forms of implementing the
claims.
* * * * *