The invention is directed to a computer/console implemented virtual strategy game comprising a field of play, and preferably played in real-time and within an on-line environment such as the Internet. For purposes of this patent, the term "virtual" references any manifestation of visual information on a display device associated with the computer or console; the term "real" references any visually perceptible object or objects existing in what is generally considered reality (the three dimensional time-space in which the earth resides).

Invention embodiments comprise three virtual "layers" of perceptible information for any location on an active field of play: the first or base layer comprises a virtual representation of one or more real objects (or any part thereof); the second or intermediate layer establishes virtual boundaries that define closed geometric forms (hereinafter "cells") that are not materially derived from the intrinsic information present in the first or base layer; the third or upper layer comprises at least one datum associated with that portion of a virtual representation of the first or base layer that is within the boundary of a given cell ("endogenous information") and/or associated with the state of the . cell itself, independent of any information relating to the cell bounded portion of the virtual representation ("exogenous information"). While it is not necessary that each cell comprise information, it is preferable; additionally, it is preferable that the endogenous information correlates with some perceptible attribute associated with the virtual representation within the cell boundary, examples of which are described below, but such correlation is not necessary, i.e., the information can attribute new attributes to the information presented by the perceptible attribute associated with the virtual representation within the cell boundary.

The virtual representations of one or more real objects of the first or base layer may be of any type, e.g., digitized visible light images, computer generated millimeter wavelength images, radar images, etc.; computer or machine assisted or derived images, designs, art, impressions or other creative expressions based upon human input; any other form of visual expressions that illicit a cognitive association between an object and a virtual representation thereof, regardless of origin. However for the purpose of game play, it is preferable to use virtual representations of real objects that are familiar to the game players insofar as the information of the third or upper layer correlates with some associated attribute(s) of a portion of the first layer. In the context of invention embodiment game play, geographical areas in the form of two- or three-dimensional maps or similar representations (hereinafter collectively "maps") are the preferred subject matter of the virtual representation.

The second or intermediate layer of cells is presented to provide limits to and for the third or upper layer. As noted above, the cells may be of any geometric form, size, spacing, pattern and sequence. Preferably, all material elements or features of the virtual representation in the first or base layer are encompassed by the cells of this second or intermediate layer, but such coverage is not necessary. Moreover, it is preferable to have the cells visually perceptible as well as uniformly dimensioned and distributed, e.g., a regular grid, during game play for reasons set forth in more detail below.

As referenced above, the data associated with the third or upper layer is endogenous or associated in some way with that portion of the virtual representation constrained by a cell boundary, or exogenous or not associated in some way with that portion of the virtual representation constrained by a cell boundary. It is in this third or upper layer that a cell can be made rich with information that can be used and exploited by players of a game according to the invention embodiments.

Examples of intrinsic endogenous data for geographic virtual representations or maps comprise one or more of the following non-exclusive list of intrinsic data: coordinates, elevation, geologic/topologic attributes and geographic features (sand, rock, water, ice, plains, mountains, forests, deserts, etc.), political/population areas and centers (towns, cities, states, parks, reserves, military, etc.), transportation corridors (paths, trails, roads, streets, highways, interstates, etc.), etc. Extrinsic data (data not derived from information present on or in the geographic virtual representations or map) includes one or more of the following, which may be obtained from other information sources that correlate to a specific area: population demographics, industry demographics, weather, resources, etc. By identifying at least one such property and incorporating information comprising that property into the game play, additional realism resulting from the selection of the map can be introduced into the game. Intrinsic and/or extrinsic endogenous data for any given cell may be static (coded) or dynamic (e.g., hyperlinked). All such intrinsic and/or extrinsic endogenous data are collectively referred to herein as "cell meta data", and are distinct from other data directly pertaining to cell attributes or assigned exogenous data, e.g., a player's occupation or potential occupation of a cell, as will be described below.

Because many invention embodiments are operated on hardware having operative connectivity to the Internet, dynamically acquired and/or updated cell meta data has particular appeal and currency. Additional realism and the possible introduction of variables outside the realm of reasonable programming can be obtained by introducing current event or even real-time data into the game play. For example, current/real-time data regarding weather in a particular group of cells may affect the ability for a player to engage in certain actions, e.g., typhoon conditions in a body of water through which a transport ship will pass may introduce casualties and/or increase transit time. This level of dynamic variable creation provides exceptional opportunities to increase realism, difficulty and a certain perceived level of randomness into the game play. Moreover, a player's awareness of current data that is not yet "presented" during game play may increase his/her success potential when such data is presented during game play. As a consequence, even when a player is not actively engaging in online game play, the player may still engage in actions or opportunities that provide value to or enhance the experience of the game when the player returns.

In certain embodiments of the invention, an Application Programming Interface ("API") is provided to enable players and/or other developers to create data transformation routines that harvest game exploitable data from Internet- based sources and allow the transformed data to be used by a cell data populator program. A recently introduced information delivery technology, RSS, is particularly attractive as a source of pre-transformation data as the "feeds" are pushed to the recipient as opposed to the recipient having to poll or otherwise acquire the data, and the feeds are rather topic specific, which reduces the amount of "clutter" that must be parsed for information. As these new applications harvest data of interest (and preferably within parameters established by a system administrator), the data is then integrated into the game, usually into the third or upper layer.

While the previous paragraphs concerned integration of current/realtime data into various invention embodiments, another aspect of certain invention embodiments relates to the related communication of audio and/or visual media to the players. Whether initiated by a game administrator or software embodiments of the invention (such as through the referenced API), media content relating to the introduction of new cell meta data can be delivered to game players. The media content may be secured from third parties or may be internally generated. Moreover, the modes of media content delivery are not limited to the game play medium - the Internet, which enables, for example, instant messaging, broadcast audio/video, VoIP - but comprise any valid mode of communication including, but not limited to, transmission of SMS/mobile texting or media clips, transmission of synthesized vocal broadcasts over telecommunication land lines, transmission of electronic mail, etc.

In addition to providing a ready means for acquiring and integrating real-time or temporally current information and/or media content into the game play, using the Internet or other wide area network also permits embodiments of the invention to provide a readily available communication means between players, be it text, voice, image(s) or any combination thereof. Beyond the benefits associated with such fingertip communication means (instant messaging, video conferencing, VoIP and other computer-based communications) such as the ability to consult and confer with aligned players or engage in cell trading opportunities, embodiments of the invention establish a communications portal as a primary element wherein the gaming experience is but one aspect of the portal. An extension of such player interaction is the distribution of communication opportunities beyond the game play medium, e.g., transmission of SMS/mobile texting or media clips, transmission of synthesized vocal broadcasts over telecommunication land lines, transmission of electronic mail, etc.

Given that the invention embodiments are preferably optimized for a large number of players, that the medium of game play is a wide area network such as the Internet, and that collaboration between players may constitute a valuable asset when attempting to achieve game objectives, the invention embodiments lends itself to social network communication models. Thus, in social network portal embodiments of the invention, user/player profiles can be created and interactions among members fostered with or without inclusion of invention embodiments as the core element of discussion. Thus, information exchanges between members of the network can take place outside of the gaming experience; it is not even necessary to be a player of the game in order to be a member of the network. However, for members that are also players, the inclusion of profile data and the ability to communicate with such persons provides additional realism and information to the game play experience.

Embodiments of the invention may also exploit an Application Service Provider-like on-line model due to the ubiquity of the Internet. While rendering (audio and visual) are handled by the player's computer, most other aspects of the game are addressed in a central (physical and/or logical) environment, thereby allowing for better and more uniform delivery of the gaming experience (see above and below) and bug fixes. As referenced herein, an "administrator" or "system operator", or equivalents thereof, is responsible for central activities.

Returning then to exogenous cell data, examples of this information include cell ownership; cell value; cell asset status and trends, identification, production status, quantity and/or quality; pending actions; executed actions; and similar game play information. Because of the base importance of certain exogenous information such as ownership, cells may also be modified to display select exogenous information. For example, ownership of a cell in certain invention embodiments may be presented by establishing a translucent color to the cell, thus retaining the perceptible information present in the first or base layer while also adding additional information not associated with or derived from the first or base layer. By extension, a "dashboard" can be established within the cell boundaries wherein several elements of information can be displayed simultaneously in conjunction with the first or base layer.

While the foregoing description of layers identifies three layers and their associated attributes, the skilled practitioner will appreciate that a referenced layer may comprise multiple (sub)layers, and that a given layer may be incorporated into another, e.g., the first or base layer includes a graphic depiction of the cells, but such depiction is not representative of the normal state of the object subject to the virtual representation. Thus, the labels used herein are for convention and convenience unless otherwise stated or clear from the context in which the term is used, and should not be construed as limiting the implementation of the various invention embodiments.

GAME PLAY AND ENVIRONMENT

New Players:

1. Each new player gets 1 cell; each cell comprises 5 soldiers and no credits (game money).

2. The new player is given a choice of which cell s/he wishes to "occupy".

3. In certain embodiments, the player is not guaranteed occupation of the selected cell. Where possible, BC tries to assign the player a cell close to the intended cell but also in vicinity of where other players are located to enhance game play. Purposely, the random assignment ensures that existing players do not game the system by creating multiple new accounts for the purpose of placing cells at specific coordinates to "surround" other players in order to gain a tactical advantage.

4. If the player pays default world currency (e.g., $1.00 USD), s/he has the option of specifying exactly which cell is to be occupied, provided, of course that the cell is unassigned. Exogenous Information:

Displayed cell colors depend on each player's circumstances:

^■ green : player's own cell(s)

^■ red : identified enemy cell(s)

^■ yellow : occupied ally/friend cell(s)

^■ blue : occupied neutral cell(s)

^■ grey : unoccupied cell(s), available for occupation

Each cell comprises certain characteristics in addition to its occupation status:

• Each occupied cell generates 1 credit every 4 hours.

• Each occupied cell can have up to a maximum of 20 credits.

• The occupier of a cell can purchase another gray cell for 10 credits.

• Each occupied cell can support up to 20 soldiers.

• A cell can have more than 20 soldiers, but will lose one soldier every 2 hours until there are just 20 soldiers.

• Each soldier costs 2 credits to acquire, and can be acquired at any time.

• Acquired soldiers are placed in the same cell where the credits originated.

• A player can temporarily assign attributes to other occupied cells, e.g., a player can assign the color pink to a blue cell that is occupied by another player, and BC will show any other cells (that the player has the ability to see) for that player as pink.

• Depending upon the play level, additional "resources" and/or "units" can be permitted and acquired for any occupied cell, e.g., artillery.

• Cell meta data can be displayed as a sub-screen in the overall display when a cell of interest is activated such as by a mouse click or mouse over, or can be presented in a balloon or similar temporary display when a cell is clicked or moused over.

Asset Movement Between Cells:

A player may move one or more available soldiers in one cell in order to occupy another cell(s) and/or a player may move one or more available soldiers in one cell in order to attack (and then occupy) another cell. An exemplary move routine would involve the following steps:

• The player identifies the cell that contains the soldiers to be moved.

• Once identified, a list of available soldiers (text or graphic) and optionally their "condition" for movement is displayed, from which the player identifies the soldiers to be moved.

• The player invokes a "move to" command, and navigates to and identifies an intended destination cell.

• BC may, prior to carrying out the command, provide the player with information relevant to the proposed move, such as, graphically illustrating the path of proposed movement and the virtual time necessary to accomplish the move (generally 1 cell per 0.5 hours). Additional information can also be provided such as likelihood of soldier attrition overall or per cell traversed, consumption of resources associated with the movement, and similar factors intended to better emulate reality.

• While moving, soldiers are identified on the cell in which they are currently located with a graphic that also communicates how many soldiers are in the moving group.

• Depending upon implementation, soldiers in transit temporarily within a cell may or may not be considered when determining the total soldier count for that cell.

• Other players may see the moving soldiers as static soldiers on the cell they currently occupy or may not see the moving soldiers at all.

• While moving through a cell, soldiers may defend that cell, if it is attacked, but cannot attack another cell unless "reordered" to do so (see below).

Asset Attack Movement Between Cells:

Attack scenarios involve considerations in addition to basic soldier movement referenced above, and contemplate the following considerations. Any cell that has attributed to it one or more soldiers can attack an adjacent cell occupied by another player.

When an occupied cell is attacked, the attacker is automatically identified as an enemy and all cells occupied by the attacker are displayed in red.

When an occupied cell is attacked, the occupier of the attacked cell is automatically identified as an enemy of the attacker, and all occupier affiliated cells are displayed in red.

During each attack operation, the success of the attack and soldier attrition within a cell are preferably determined as follows: o Attacking soldiers are paired with defending soldiers, preferably one to one, but may be allocated differently if other factors such as soldier strength, equipment and similar variables are taken into account. o A random number between 1 and 100 is generated; if the number is <= 40, the attacking soldier survives and the defending soldier dies, and if the number is > 40, the attacking soldier dies and the defending soldier survives (i.e., an attacking soldier has a 40% chance of killing the defending soldier and a defending soldier has a 60% change of repulsing the attack). o If the attacking cell had more soldiers than the defending cell, then the extra attacking soldiers who could not be paired up with defending soldiers are paired up with remaining soldiers that survived the first pairing and they fight those soldiers with either the same odds as before or new adjusted odds.

If the attacking soldiers eliminate all defending soldiers, the attacking soldiers must still conquer the cell, in preferred embodiments ~ the cell itself counts as a single soldier that must be eliminated. The attacking soldiers engage the defending cell by (taking turns, if more than one, and) pairing up with the cell and fighting with it with the same 40/60 odds as before or new adjusted odds. If the attack is successful, the attacking player is asked how many solider to move from the originating cell to the newly conquered cell (or any other cell occupied by the attacking player).

In certain embodiments, soldiers can only travel on cells that the attacking party occupies, i.e., soldiers cannot travel on red, yellow, blue, or grey cells.

New orders can be issued to moving soldiers, to send them to a new cell, or halt them at their current cell.

Endogenous Information:

In addition to the more cell independent considerations referenced above, BC embodiments also include constraints to movement and attack considerations that are variable and dependent upon the endogenous information of the cell with respect to the virtual map layer. While the number and nature of such attributes is nearly limitless (see discussion above regarding intrinsic and extrinsic sources of meta data), the following examples should illustrate a consequence of attributing a geographic dependent property to certain cells:

• Shoreline cells that connect to oceans can produce troop ships at a cost of 10 credits per ship; ships may be built instantly or over a period of time.

• Each ship can hold 10 soldiers.

• Ships move at a relative speed of 55kph.

• Ships can be used to ferry soldiers or deliver soldiers to attack other cells that touch ocean-connected water.

• While traveling, ships cannot be contacted; during the early stages of the game, ship location cannot be viewed.

• Ship destinations must be other shoreline cells; destinations cannot be water cells.

• Each shoreline cell can dock at most 2 ships.

• Docked ships can indefinitely house up to 10 soldiers each, without any losses.

• Soldiers on a docked ship cannot defend the shoreline cell if it is attacked.

• If a cell with docked ships is conquered, the attacking player gets ownership of me ship(s) and any soidiers they may contain.

• Soldiers that are on docked ships are not visible by other players on neighboring cells.

Organic (Wild) Cell Attribute Detection and Correction: If a cell is characterized, for example BC shows it as a land cell when it is in fact a water-only cell, players have the ability to flag the cell with a flag tool and mark it as water-only. The flag tool notifies the system administrator and players are compensated for every cell that they accurately correct. Accuracy can be determined by the system administrator or by other players. As to the latter, a revision list or revision history can be accessible by the users. If the alleged correction is, in fact, incorrect, then such a vetting process by the community reduces system operator resources

This community based or wiki approach to cell accuracy verification becomes very desirable in embodiments wherein cells are rich with cell meta data. Much of the cell meta data is comparatively dynamic (when compared to cell geographic or geologic attributes). In embodiments wherein each cell is approximately 1 minute latitude by 1 minute longitude, there are very many cells. Therefore, it is very beneficial to have the first pass accuracy vetting performed by many as opposed to few. A wiki approach meets this objective, and provides additional means for a player to acquire wealth/assets.

User Interface f "UI"):

Embodiments of the invention provide a UI intended to emulate that of a live strategic game console environment. Taking into account the various aspects of robustly implemented embodiments of the invention, the following disclosure elaborates on certain features and functions associated with such a UI.

1. Map

2. Cell Details

3. Location Search

4. Layer View Control

5. Player Communications

6. Game/Player Statistics

7. Web Site Navigation Map:

The map section is the primary mechanism for interacting with the game. As it uses the Google Maps API, the map section can be panned, zoomed in and zoomed out using the same techniques as the web based maps on the Google web site itself.

Additionally, individual cells can be selected by single-clicking on them. A selected cell is highlighted on the map section, and its details are displayed in the details section.

If possible, the following functions also have key bindings for quick access:

1. zoom in/out

2. map views: hybrid/terrain/map

3. default zoom level: 11 or otherwise specified in the users preferences

4. copy URL for current map view to clipboard

Where not explicitly present on the default Google Map view, functions such as the default zoom level and the copy URL for current map function may also be displayed in the UI for mouse access.

Cell Details:

The cell details section provides detailed information about a currently selected cell. The order in which this information is provided may be determined during the interface graphical layout design.

1. cell bank status - shows how many credits are currently available for spending in that cell.

2. production schedule — show the date/time when the next credit will be produced.

3. troop count - show the number of soldiers in the cell, identifying static soldiers and soldiers that are in transit.

4. death rate - if more than 20 soldiers on the cell, show estimate for when next soldier loss is expected to occur due to over population.

5. altitude - show ground altitude in feet and in meters.

6. coordinates - show cell coordinates in degrees and minutes. 7. attacks - show the number of attacks that the cell has sustained under the current owner.

8. booby trap status - show if cell contains a (nuclear) booby trap.

9. radioactive status - show if cell is currently radioactive, along with estimated time until radioactivity dissipates.

10. shoreline - identify cell as a shoreline cell, if it is on the edge of a body of water.

11. ships — identify the number of troop transport ships currently docked at the cell.

12. production index - numeric index for production rate. An index can be: +1 +2 +3 -1 -2 -3, depending on real world events. Links to real world news events that shift the index up or down may also be provided.

13. military index - numeric index for military odds, typically depends on altitude, but can also depend on other factors as determined by real world events.

Actions:

1. attack another cell - cell to attack must be adjacent to current cell.

2. buy more soldiers - can only use credits from current cell.

3. soldier instructions - select at least one soldier to travel to another cell or instruct soldiers moving through current cell to hold their position in current cell.

4. (if shoreline cell) build one or two ships -

5. (if shoreline cell) load/unload soldier(s) into/from docked ships.

6. (if shoreline cell) instruct any docked ships to move to and/or attack another cell.

7. purchase a nuclear booby trap for current cell.

8. set alert triggers - send an email or IM alert if one of the following monitored conditions is met:

~ v^^i i io uiiαcivυu.

• cell is conquered.

• cell credit levels reach a predetermined amount.

• stationary soldier numbers reach a predetermined amount. Location Search:

The location search feature is intended to allow players to quickly find specific areas on the map that meet desired criteria. Such criterions might be:

• city, state/province, county name

• player/empire name

• location bookmarks (unique to each player)

• latitude/longitude coordinates

• location of historical event (in-game or real-world)

The location search is integrated into the map section, above the main map, as best shown in Illustration 1.

Layer View Control:

The layer view control section plays a pivotal role in helping players to understand the strategic surroundings of their playing environment. In the simplest sense, the layer view control section provides a list of possible cell views to be superimposed over the Google Map. The following list options provide an example of the type of information that this section helps players to visualize:

1. Political - sets cell color to display status of map cells with respect to the player's status. green : player's own cell(s) red : identified enemy cell(s) yellow : occupied ally/friend cell(s) blue : occupied neutral cell(s) grey : unoccupied cell(s), available for occupation

2. Geographic — cell colors are from a color spectrum, and are determined by the cell altitude. Cell altitude is relevant to the game, as higher altitude cells have a military advantage of lower cells. Higher altitude cells, however, may produce credits at a slower rate than lower altitude cells.

3. Economic - cell colors are from a color spectrum, and are determined by the number of credits that are immediately available for use in each cell. 4. Military - cell colors are from a color spectrum, and are determined by the number of soldiers located on each cell.

5. Troop Movement - show troop movements by identifying all troops that are traveling by placing an icon in the cell where they are currently located. For each moving troop group, identify their point of origin, and their destination. Connect their point of origin to their current location with a line. Also, connect their current location with their destination using a line. A graphical mechanism can communicate the direction of movement along the two lines associated with each troop group. This view can be toggled on and off independently for all of the various cell views. This view also identifies all cells that are destinations for any ships currently in transit.

6. Empire Logistics - cell colors are assigned to differentiate geographic areas managed by different generals (sub-accounts) operating under the umbrella of a large and successful account that has grown large enough to be classified as an empire.

7. Player Demographics - there are several examples: a. Assign a color to each country/continent/etc. Track the origin/physical location of each player who has an account in the BC game. This view then allows gamers to easily determine if their country is being invaded by a group of players representing another country or continent. If, for example, US players notice that there is an invasion of Chinese players taking over cells in the US region, they have a chance to respond as a group based on motives originating from national motives. b. Assign color from a spectrum that identifies age. c. Assign color from a spectrum that identifies real-world money spent on the game. d. Identify player sex by color.

Fiάy ^' ci ^' v_.ύiϊiiϊiUiiiCai,ιύiiS:

In-game player communications are intended to emulate the typical instant messaging (chat) applications commonly used by known networks such as Google Talk, AOL/AIM, Yahoo Chat and MSN Messenger. In the general sense, the communications window is ideally a translucent overlay, similar to that of the battlefield cells.

The player communications section preferably informs each player whether the remote party they are sending a message to is currently online (logged into the game). If the remote party is not online, then the message will be delivered the next time that the remote party becomes available.

All communications between players is preferably, but not necessarily, logged. In such cases, each player has the able to search and access past communication sessions that s/he has had with other players. The communication history window ideally has similar functionality to the Chat Transcript Viewer in Adium, as is best shown in Illustration 2.

Notable Game Mechanics:

The social nature of BC is further aided by specific mechanisms that enable players to interact in ways that are symbiotically beneficial. For example, players have the option to invite their friends to join BC by sending them a personalized hypertext link ("URL"). New players who create new accounts on BC after clicking such personalized URLs are automatically linked to the player who send the URL in the following ways:

1. When logging in for the first time, the new player is shown a map region in the vicinity of the player who invited them.

2. The personalized URL is linked to a cell or cell region that belongs to the player who generated the URL.

3. The cell or cell region is automatically linked to the empire(s) of new player(s) who joined by clicking on the personalized URL.

4. When linked, a cell's or cell region's credit production rate is determined by the number of cells in the linked empire.

In this manner, players who invite friends to play BC are rewarded with increased credit production rates on existing cells. Likewise, players are motivated to mentor new invited players in order to increase credit production of their own cells.

Game/Player Statistics:

The game/player statistics section provides relevant information about the game and generally comprises at least some of the following statistics, which are intended to be exemplary and not exhaustive:

1. number of players in the game.

2. number of players currently logged in and active in the game.

3. cumulative time that the current game has been running.

4. cumulative time that the player has been in the game.

5. number of cells that the player owns.

6. number of soldiers that player has.

7. total credits that the player has.

8. player's rank in cells.

9. player's rank in credits.

10. player's rank in soldiers.

11. production capacity of all of the player's cells.

12. cells lost, since last login.

13. successful cells defended, since last login.

14. messages waiting to be read/received.

15. number of allies.

16. number of enemies.

In addition to the foregoing, game/player statistics may be presented through environmental and/or ambiance cues. For example, macro level audio and/or visual cues can be integrated into the UI whereby the player will be presented with crowd "cheers" at login if s/he is comparatively successful in the campaign, with volume an duration providing "degree" information. Similarly, browser border color could be dynamic to reflect statistical information regarding the game or the player's position therein.

Web Site Navigation: The BC game is located at BATTLECELL.COM and is preferably an AJAX enabled web page that is part of a larger website. The main index page is the game page itself. It contains the Google Map interface along with the other sections described in this document.

However, BATTLECELL.COM is still a web site, and as such, has other pages that deal with other aspects of the BattleCell experience:

1. legal disclaimer and privacy page.

2. game rules and strategies.

3. player blog pages.

4. community forum pages.

5. game related news/podcasts.

IN-GAME COMMUNICATIONS INFRASTRUCTURE

While the preceding disclosure concerned gaming infrastructure such as battlefield and map layers, UI and related architecture, invention embodiments also comprise various communication means by which interactions between players can be enhanced. By providing for such interactions, players can better establish alliances, trade resources and manage virtual personnel. The following disclosure is intended to exemplify three primary modes of player to player interaction.

The communications portion of the BC web site is preferably enabled to address the needs of three (3) specific kinds of communications.

• Direct Communications: players need to be able to communicate directly and instantaneously with each other through some form of Instant Messaging that is built directly into the BC game interface.

• Player Blogs: As in real life, some players are going to be more influential than others. All players are offered their own BC game blog where they can make announcements, discuss their experiences and solicit comments from other players and/or the public.

• Topic Boards: Users can have conversations centered around specific topics such as feature requests, bug reports, the impact of real world events, and other similar topics.

Recognizing the global user base of the BC game, embodiments of the invention exploit Internet-based resources relating to real-time and near real-time translation services, such as the Google Translation API.

1. Direct Communications translations are performed in real time between players, as the players send IM messages back and fourth.

2. Each user sees the Player Blogs in their own native language, regardless of the language in which any particular blog is written.

3. Each user sees Topic Boards discussions in their own language. In each topic, every entry is translated into the user's native language, regardless of its language origin.

Communication Type Details;

Direct Communications between players is accomplished via an in-game Instant Messaging service, presented in the same fashion as the preference and whole world map view 'window' as shown in Illustration 3:

In certain embodiments, the in-game IM feature allows players to communicate only with other players. Messages sent to players who are not online are stored until the next time those players access their BC account. A blinking notice, similar to the blinking light on an old fashioned answering machine, informs the player that there are communications waiting to be read, if the player received messages when not logged in.

If a player receives a message while logged in, the same blinking notice may be activated on the game interface. Optionally, this blinking notice may indicate the number of messages waiting to be read. When the player clicks the blinking notice, a popup window is displayed with the messages. Other players who have sent messages to the recipient are preferably presented in their own tabs, identified by their name or BattleCell ID.

As with conventional IM applications, the message recipient has the ability to respond to messages by typing in the text field at the bottom of the window. This window may offer additional features, such as an indicator that tells whether the remote player who the message is being sent to is currently online. As well, another option offers an archive of all prior conversations the player has had with the other person. The message archive view may also provide a search function to find prior messages using key words and/or dates.

Robust embodiments provide suitable means for integrating third party IM solutions such as Yahoo Chat, Google Talk, MSN Messenger and/or AOL/AIM. This feature enables other players (or even non-players) to contact an individual player, even if that player is not currently logged into the BC game interface.

When someone inside the BC game wishes to contact a player who is not currently logged into the game itself, the message is automatically forwarded to the player's respective IM application, provided that the person is available via an IM network that is configured in his or her BC settings. Nevertheless, player conversations are logged to their communication archives, even if the conversation is routed through one of the existing IM networks instead of through the BC game interface.

Player Blogs are automatically created for each player when they first sign up. By default, each player's BC blog site is also their profile page. This page is preferably separate from the BC game interface and may open as an additional web browser window.

Default information provided on the profile page may include:

Player name

Player picture (if provided)

Player location: city/state-province/country

Player language (as set by default in preferences)

Date player joined Player cell count

Player cell coordinates (region)

Number of allies

Player enemies (only available when viewed by allies)

As with conventional blogs, any blog entry preferably has a title, a date, and the article itself. Beneath the article are comments that other players can leave. In addition, the page may also contain an index of all prior blog entries, by date. Preferably, a few words of the title are shown on each entry, to help identify it. An optional search feature offers the ability to search for specific players, or specific blogs of the current player.

Player blogs may also be configured to provide an RSS stream for each player's blog page.

The blogs portion of the BC website is preferably configured to have an index page that allows player blogs to be listed in order of blog activity for each geographic region. In particular, a Google Map on the page allows users to select what region interests them. Upon selection, the page updates to show a list of players in that region who have active blogs, ranked by blog activity. Each entry in the list may contain at least some of the following information:

Player Name/BattleCell ID

Player Picture (if provided)

Abridged Player Stats: date joined, number of cells, number of allies, number of enemies Number of blog entries

Average number of comments per blog

An alternate way to access a particular individual's blog is to click on one of their cells in the standard BC game interface. In the cell details portion, an owner profile link m X ⁾ \ n\rof page.

Topic Boards are for general game conversations that are not part of the game process itself. One of the most important aspects of the Topic Boards is the player feedback, suggestions, and bugs sections. However, any active player can create additional topic boards that are appropriate and relevant to BattleCell.

Each Topic Board can have multiple conversations for that topic, where each conversation starts as a top level entry in that Topic Board. For example, the bugs topic board may start out with a single top level entry, "there are land cells in the middle of the Dead Sea" posted by a player. Another player may respond to this post, starting a thread. In this thread, yet other players can respond to the original post, or to any other responses in the thread. If someone finds a new bug, they post a new entry in the bugs topic board top level, "I can't communicate with other players via the in-game IM system".

As with Direct Communications and Player Blogs, a search function helps players find specific entries, globally in all Topic Boards, or within a specific topic board, or even within a specific thread.

Pushing Instant Changes to Player UI

As previously mentioned, the Ul is preferably browser based and uses AJAX to respond to player commands without reloading the entire browser page.

During regular game play, it becomes desirable to push commands to the UI for instantaneous execution. One example might be to rapidly shake the entire UI screen in order to simulate a missile strike. Another example might be to deactivate certain features in the UI by hiding them or otherwise marking them as unavailable, or to proactively alter cell colors to denote an immediate change in relationship between players.

These "push" commands may be transmitted to the AJAX driven UI via Bidirectional- streams Over Synchronous HTTP ("BOSH"). The UI may rely on a Javascript BOSH client that maintains an open connection to the BC web servers in order to receive such immediate commands.

The UI AJAX architecture may be simplified by integrating the BOSH client responsible for receiving UI commands into the Direct Communications interface as it also implements the XMPP over BOSH standard to provide instantaneous message delivery.

The preferred solution implemented by the BC AJAX interface utilizes a modified Direct Communications interface that utilizes XMPP over BOSH. Specialized UI push commands are encapsulated inside standard XMPP messages and pushed by the BC servers through the XMPP server to the Direct Communications interface on the UI. The Direct Communications interface recognizes the UI push commands and reroutes them to the relevant UI window and layer for execution.

Integrating UI push commands into the XMPP over BOSH functionality offers the additional benefit of lowering the TCP connection burden on the BC servers by not requiring an additional open TCP socket above and beyond what is already used by the Direct Communications functionality.