JP5207648B2 - Programs and computer systems - Google Patents

Description

  The present invention relates to a program for exchanging messages between avatars in a virtual society in which a plurality of avatars appear, and a computer system that executes the program.

  In recent years, network games in which a large number of people participate via the Internet, such as MMORPG (MMORPG: Massively Multiplayer Online Role-Playing Game), have become widespread (for example, Non-Patent Document 1).

  In this type of network game, a plurality of players can each operate a terminal device to cause their own avatar to appear in the virtual society and have a conversation with each other or play a game together.

“Han Game Guide”, [online], NHN Japan Co., Ltd. [Search February 9, 2007], Internet <URL: http://www.hangame.co.jp/guide/index.asp?Content=avatar >

  Conventionally, mail, chat, etc. are known as communication means using a personal computer and a network. These were intended for specific people, and there was no means of communication for unspecified limited people. Conventionally, a bulletin board is known as a function for sending a message to the public. However, this bulletin board sends a message to an unspecified number of publics, and all people who access the bulletin board can send it to the public. The message can be viewed, and the message cannot be sent to an unspecified limited person.

In the network game, there is no communication means that incorporates a game-like element that realizes message passing in an avatar activity that does not directly aim at message passing.
An object of the present invention is to provide a program that realizes message passing to an unspecified limited person through an avatar activity in a virtual society of a network game, and a computer that executes the program The purpose is to provide a system.

The game program provided by the first aspect of the present invention is a computer system in which a plurality of terminal devices are connected via a network, and a plurality of virtual characters (hereinafter referred to as avatars) respectively operated by the plurality of terminal devices. ) And a virtual object, a virtual society generation procedure for generating a virtual society, a display procedure for displaying the virtual society on a display unit of each terminal device, and a specific terminal device (for example, a virtual object purchased) When a message input operation associated with the virtual object is received, a message registration procedure for registering the message in association with the virtual object, and the virtual object in which the message is registered are included in the plurality of avatars. For an unspecified avatar acquisition operation (for example, fishing) Next, an acquisition procedure for acquiring and occupying the unspecified avatar, and a message output that enables the message to be output to a terminal device that operates the unspecified avatar when the virtual object is occupied by the unspecified avatar And a procedure for causing the unspecified avatar to use the virtual tool item to acquire the virtual object, and the performance of the tool item used by the unspecified avatar. And determining whether or not the virtual object can be acquired .

In the above invention, the computer system may further execute a moving procedure for moving a virtual object in which a message is registered in the virtual society .
In the above invention, by the operation from the terminal device that operates the unspecified avatar, it is possible to acquire another unspecified avatar by releasing the occupation of the virtual item occupied by the unspecified avatar according to the acquisition operation. The computer system may be caused to further execute a occupancy release procedure for returning to a certain state.

In the above invention, the virtual society generation procedure includes a procedure of generating an avatar to which an attribute is given, the message registration procedure includes a procedure of registering an attribute together with a message, and the acquisition procedure corresponds to the virtual object. A procedure for enabling acquisition of the virtual object only to an unspecified avatar to which an attribute matching the registered attribute is attached may be included.

In the above invention, the specific terminal device may be a terminal device on which a purchase operation of the virtual item is performed.

A computer system provided by the second aspect of the present invention includes a storage unit that stores the program and a computer that executes the program.

  According to this invention, when a virtual object with a registered message is acquired, a message can be output to an unspecified limited person by enabling the message to be output to the avatar that acquired the virtual object. It becomes possible to send. In addition, a message registered to a virtual building or virtual object is output in a form that is output from the virtual building or virtual object, so that a message is sent to an unspecified limited number of avatars present at that time. Can be communicated. This makes it possible to transmit a message to an unspecified limited person using chance, which is not found in the conventional mail, chat, and bulletin board.

  Since the present invention can deliver messages through activities (not direct communication) in a virtual society such as fishing and butterfly trapping, for example, it is possible to communicate with other players without impairing the preference of the network game. It becomes possible to take communication.

<< Overview of the game >>
First, an online game developed in a computer system to which the present invention is applied will be described.
This game is a multiplayer network game executed on a computer system in which a portal server and a personal computer as a terminal device are connected via a network such as the Internet. In a virtual society created virtually using functions (especially image processing functions), a player who is a user of each terminal device makes an avatar that is a virtual character operated through the terminal device appear. It is a game that allows avatars to live in a virtual society and perform various activities. In the description of this embodiment, the player's operation may be appropriately expressed as an avatar activity.

  The virtual society is composed of a plurality of stages, and the avatar can move within one stage and can move between the stages. Each stage is uniquely characterized by its nostalgic town, modern town, coast and fields.

  In this computer system, the portal server operates a portal site and displays a game image of the game on a terminal device logged into the portal site. As a result, a game image linked with the portal function can be displayed, and a highly interesting portal site can be provided. For example, if a link is set to a store or item in a virtual society of the game, and the player selects the store or item by clicking the mouse or the like, the portal server connects the terminal device of the player to the link destination. When the player performs a search on the portal site, the virtual society region corresponding to the search content is displayed as a search result on the terminal device. For example, when searching for “game”, a list of sites related to the game is displayed, and a game center or the like in the virtual society is displayed.

  In this network game, the avatar moves in the virtual society in response to the operation of the terminal device by the player. The avatar wears various items such as clothes and glasses. This item is also a virtual item worn by the avatar in the virtual society. The player can activate the avatar in the virtual society with his / her favorite appearance by causing the avatar to wear various items. The player can obtain these items for his / her avatar by purchasing them at a store installed in the virtual society, or receiving or exchanging them from other avatars. For purchasing items, virtual currency that is valid in this virtual society is used.

In this online game, an avatar can send a message using the following various methods.
(1) Message fish: The fish that wrote the message is released to the river or the sea, and other avatars who caught it can read the message. (2) Message butterfly: Release the butterfly that wrote the message and capture it. What other avatars can read the message (3) Message bottle: A bottle with a note on which a message is written is poured into a river or the sea (or placed on a street corner), and a bottle that is drifted or placed on a street corner (4) Donkey's ear well: Multiple messages are input to the well, and randomly selected messages are displayed in balloons from the well at the specified timing. These messages can be sent to specific avatars. It is not intended for the hand (avatar), but is a message transmission means with a chance that no one knows when to read. In addition, messages can be delivered through daily operations of avatars during online games (for example, fishing, insect trapping, etc.).

<< Detailed explanation of the game >>
Hereinafter, the game will be described in detail with reference to the drawings.
A virtual society created by the portal server and a plurality of terminal devices is composed of a plurality of stages. Each stage has a different aspect such as a town with a house and a store, a field where a river flows, and a coast.

  FIG. 1 is a diagram showing a bird's-eye view of the city layout. In this town, a train station 100, a store 101 selling various products, a park 102, and the like are laid out. In this embodiment, one stage is composed of 40000 cells of 200 cells × 200 cells.

  When a player logs in to the network game, the game starts when the player's avatar is standing at the train station 100. The player can move his / her avatar in the city to visit the store 101, the park 102, and the like. It is also possible to move his / her avatar to another stage on the train 103.

  2 is a diagram showing a monitor display example of the stage “town” shown in FIG. On the monitor 26 of each terminal device, a part of the city shown in FIG. 1 is displayed with a substantially horizontal line of sight. This figure shows the scenery in the vicinity of the store 101A (cigarette) in FIG. Here, a self avatar 110 and a plurality of other avatars 111 are displayed. The player can move (walk) his / her avatar 110 in the direction of the mouse click by clicking the mouse on the screen. Further, when the player clicks the store 101A with a mouse, his / her avatar 110 can enter the store 101A. Furthermore, when the player clicks on the train 103, his / her avatar 110 can be placed on the train 103 and moved to another stage.

  FIG. 3 is a diagram illustrating an example of an avatar that is a virtual character operated by a player. The avatar in the figure represents a male avatar. The avatar has a basic shape (element body) as shown in its own avatar 110 in FIG. 2, and various items are added to the element body 120 by the operation of the player as shown in FIG. An avatar with a simple appearance is constructed. In this figure, the body 120 has items such as a wig (hairstyle) 121, glasses 122, a T-shirt 123, a jacket 124, pants 125, and shoes 126, and is finished to the appearance shown in the figure. These various items are purchased from a store in the virtual society, like the message fish, message butterfly, and message bottle described above.

  In this online game, as described above, a message can be transmitted to other avatars through an avatar activity that is not an activity for directly transmitting a message. In the following embodiment, transmission of a message using a fish item (message fish) will be described.

  FIG. 4 is a flowchart showing a player operation procedure when a message is delivered using a message fish. FIG. 4A is a flowchart showing a procedure in which the first avatar writes a message to the fish and releases it. First, the first avatar purchases fish for writing a message at the store (S201). Then, a message and an attribute of an avatar to be read by this fish are written (S202). And it moves to a river and the sea with this fish (S203), and discharges this fish (S204). This allows the fish to freely move around water areas such as rivers and seas (by control of the server computer).

  FIG. 5B is a flowchart showing a procedure for reading a message written on the fish caught by the second avatar by fishing. The second avatar purchases a fishing rod, takes the fishing rod (S210), and goes to the river or the sea (S211). Then, the fishing line is lowered into the water (S212). Then, since the fish in the vicinity bites, when the pull is confirmed (S213), the fishing line is pulled up (S214). This lifts the fish. Then, the message written in this fish is displayed (S215). In addition, when a fish can be caught, a message may not be displayed immediately, but a message may be displayed when an avatar possesses a fish as a belonging and the player performs a display operation.

  Hereinafter, the operation of the computer system for realizing the progress of the game as described above will be described.

<< Description of system configuration >>
FIG. 5 is a diagram illustrating the configuration of a computer system that executes the network game. This computer system includes a portal server 1 and a plurality of terminal devices 2 connected via the Internet 3. The portal server 1 may be configured by a general server computer or workstation, and the terminal device 2 may be configured by a general personal computer, and thus detailed description of the hardware configuration is omitted.

  The portal server 1 includes a server database 11 (see FIGS. 6 and 7) that stores and stores data of a virtual society and a plurality of avatars, a game progress management unit 12 that controls and manages the overall progress of the network game, and items for avatars in stores. The item sales management unit 13 that controls and manages the sales and issue of affiliates, and the communication control unit 14 that controls communication with the terminal device 2 and the like. The game progress management unit 12 is a functional unit in which the game progress management process by the game progress management program is realized by hardware resources such as the CPU of the portal server 1. The item sales management unit 13 is a functional unit in which the item sales management process by the item sales management program is realized by hardware resources such as the CPU of the portal server 1. The communication control unit 14 is a functional unit in which communication control processing by the communication control program is realized by hardware resources such as the CPU of the portal server 1 and communication-related peripheral devices.

  The terminal device 2 is a local database 21 that stores data for advancing a network game on its own device, a display control unit 22 that displays a game screen on the monitor 26, and an operation that receives an operation of a player who is a user of the terminal device 2. A management control unit 24, a communication control unit 24 for controlling communication with the portal server 1 and the like, and a game progress management unit 25 for controlling the progress of the game in the own machine are provided. A monitor 26 is connected to the display control unit 22. The display control unit 22 is a functional unit in which display control processing by the display control program is realized by hardware resources such as the CPU of the terminal device 2. The operation management unit 23 is a functional unit in which operation management processing by the operation management program is realized by hardware resources such as peripheral devices such as a CPU of the terminal device 2 and a mouse / keyboard. The communication control unit 24 is a functional unit in which communication control processing by the communication control program is realized by hardware resources such as the CPU of the peripheral device 2 and communication-related peripheral devices. The game progress management unit 25 is a functional unit in which game progress control processing by a program for controlling game progress is realized by hardware resources such as the CPU of the terminal device 2.

  In the terminal device 2, this network game may be displayed by an Internet browser or may be executed by an independent application program. When displayed on an Internet browser, a game program (display control program, operation management program, communication control program, etc.) is provided as a plug-in for the Internet browser. These programs may be installed in advance in the terminal device 2 using a medium such as a CD-ROM. However, when the program is provided as a plug-in of an Internet browser, the terminal device 2 first loads the portal server 1. It may be automatically downloaded from the portal server 1 when logging in. The local database 21 may be constructed at the same time as the program. The local database 21 and each program are downloaded and updated from the portal server 1 every time the terminal device 2 logs into the portal server 1.

  The operation management unit 23 monitors the operation of the player, updates the data of the own avatar in the own device with the detected operation content, and transmits the operation information representing the operation content via the communication control unit 24 to the portal server 1. Send to. The portal server 1 (game progress management unit 12) manages the progress of the game so that each player's avatar is activated based on the operation information sent from each terminal device 2. Management of the progress of the game is performed by updating the contents of the server database 11 that stores all the states of the virtual society so as to match the state of the virtual society at that time. The game progress management unit 12 of the portal server 1 periodically transmits update information of the database 11 to each terminal device 2. Each terminal device 2 (each game progress management unit 25) updates the local database 21 based on the update information sent from the portal server 1, and advances the game by updating the screen display accordingly. .

  The item sales management unit 13 of the portal server 1 functions when an avatar operated by any player (terminal device 2) visits a store provided in a virtual society. When the item sales management unit 13 transmits the sales item information of the store to the terminal device 2 that operates the avatar that visited the store or the avatar (player) purchases the item, the item sales management unit 13 owns the item. Register in the item table and subtract the price of the item from the owned virtual currency.

  6 and 7 are diagrams showing the configuration of the server database 11. The server database 11 includes a virtual society data storage unit 30 that stores the configuration of the virtual society, an avatar data storage unit 40 that stores data about a plurality of avatars, and a plurality of items that are sold, owned, and worn in the virtual society. It has the item data storage part 50 which memorize | stores data, and the message data storage part 60 which memorize | stores the message which the avatar transmitted.

  The virtual social storage unit 30 includes a stage data storage unit 31 that stores the configuration of each of a plurality of stages, a building data storage unit 32 that stores data of a building such as a house, a station, or a park standing at each stage. The sales item data storage unit 33 manages items to be sold. The avatar data storage unit 40 includes a player data storage unit 41 that stores information for each avatar registered in the portal server 1 and an avatar element image data storage unit 42 that stores an element image of the avatar. .

  The stage data storage unit 31 stores stage data set for each stage for each stage. Each stage data includes stage name data indicating the name of the stage (for example, “nostalgic city”, etc.), map data in which the layout of the building or the like in the stage is written, and a building that designates a building arranged on the map data Includes specified data.

  The building data storage unit 31 stores building data set for each building for each building. Each building data includes building name data indicating the name of the building (for example, “XX department store”, etc.), building image data that is an external image of the building, and building type data (whether store, private house, room entry is possible or not) In the case of a building that can be entered, internal layout data is included, and in the case of a store that sells items, item specifying data that specifies sales items is included. The building data is set not only for structures but also for roadside street stalls.

  The sales item data storage unit 33 stores sales item data provided for each item sold at any store in the virtual society. Each sales item data includes item designation data for designating the item from items stored in the item data storage unit 50 and price data indicating the price of the item.

  The item data storage unit 50 stores item data set for each item. Each item data includes an item ID for identifying the item, item name data indicating the name of the item (such as “red umbrella”), item image data indicating the appearance of the item, and where the item is worn on the avatar. The item type data etc. which instruct | indicate such are included.

In addition, the item which an avatar wears in this game is not limited to clothing, For example, tools, such as a fishing rod and a bug net, are also included. Such tools are also sold at stores.
The message fish, message butterfly, and message bottle described above are also the types of items sold in the store. Each of these three types of items is composed of a plurality of types of items having different sizes and the like. For example, in the case of a message fish, there are items such as “human eagle eagle” and “Futakoto azi” that are different in size. These “Hitokotoi” and “Futakotoji” are item names.

  These message fish, message butterflies, and message bottles are similar to regular items when sold in stores, but an avatar purchases this item and writes a message to release (release, release, stream, put) Etc.), each becomes a communication item having the above-described characteristics, and is registered in a message data storage unit 60 (described later) of the server database.

  The player data storage unit 41 stores player data set for each avatar (player) registered in the portal server 1. Each player data includes avatar name data indicating the name of the avatar of the player, element selection data specifying an image of the avatar element selected by the player, attribute data indicating the attribute of the avatar, and which stage the avatar is in. Position data indicating where the item exists, operation data indicating the operation (posture) of this avatar, an item table in which items owned or worn by this avatar are registered, and used in a virtual society Possession amount data representing the possession amount of the virtual currency.

  The avatar element image data storage unit 42 stores a plurality of avatar element images selected by the element selection data of the player data. The avatar element image is, for example, an image such as the avatar 110 shown in FIG.

  The attribute data of the avatar is data indicating the attribute of the avatar or the player, and includes data of categories such as age group, sex, hobby, and region as shown in FIG. This attribute data is information that is input by the player when registering to participate in this network game. When the player's own attribute is input, the attribute to be assigned to the virtual avatar operated by the player is input. There is.

In FIG. 7A, one age group is selected from five options of teens, 20s, 30s, 40s, and 50s. Either sex is selected from male / female. One or more hobbies are selected from games, music, sports, movies, drive touring, and reading. One area is selected from 47 prefectures.
The data representing the player attributes is not limited to these. Moreover, the setting mode of options of age group, hobby, and region is not limited to the above.

  FIG. 7B is a diagram showing a fish data storage area in the message data storage unit 60. The fish data is data registered for the message fish released into the water, such as fish ID, size data, item ID, capture condition data, position information, capturing flag, message body, etc. for identifying this fish. Consists of content.

  The size data is data representing the size of the fish. The size data determines the size of the fish in appearance and the number of message characters that can be written (registered in association with each other). For example, “Hitokotoi” has a size of 5 cm and can register a message up to 20 characters. “Futakotoji” has a size of 10 cm and can register a message up to 40 characters. The item ID is an ID for specifying item data stored in the item data storage unit 50. By specifying item data with this item ID, it is possible to read the item image data included in the specified item data and create the appearance of this message fish. The capture condition data is data that specifies conditions (attributes) of an avatar that can catch this fish. This capture condition data sets the attribute of the player who writes a message to this fish in order to narrow down the avatar (player) that he / she wants to read this message. This capture condition data is set for all or a part of the plurality of categories shown in FIG. Message fish for which capture condition data is not set can be caught by all avatars.

  In addition, when the avatar attribute is not set in the player data, it is possible to catch only the message fish for which the catch condition is not set, that is, the message fish caught by all the avatars.

  The position information is data indicating where the fish is swimming, and includes information indicating the stage and coordinates within the stage. The fish migration is not controlled by the player, but the game progress management unit 12 of the portal server 1 determines a migration route using a unique algorithm. The game progress management unit 12 determines the migration route of each fish by the above algorithm and periodically updates the position information of each fish.

  Note that the game progress management unit 12 may update the position information of the fish instead of updating the position information of the fish as the position information of the fish. Further, the position information may not be included in the fish data. In this case, the fishing of the fish is determined regardless of the position of the fish. For example, the success or failure of the fishing of the fish is determined only by the match between the capture condition data, the attribute data of the avatar, and the fish size and the performance of the fishing rod.

  The catching flag is a flag indicating that the fish is hung on the fishing line in any of the terminal devices 2. When this flag is set, the other terminal device 2 cannot capture this fish. In the game progress in the terminal device 2, if there is a fish in the vicinity where the avatar hangs the fishing line, the fish is caught in the fishing line, and this is notified to the portal server 1. The portal server 1 sets a capturing flag in response to this notification. However, even if the fish is caught in the fishing line, if the catching is delayed or the above catching conditions are not satisfied, the fish will escape. When notified from the terminal device 2 that the fish has escaped, the portal server 1 resets the capturing flag. On the other hand, when it is notified from the terminal device 2 that the fish has been caught without escaping, the message body is transmitted to the terminal device 2 and the fish data is deleted from the message data storage unit 60.

  The message body consists of text data. The number of characters varies depending on the size of the fish, and is about 200 to 400 characters. In this embodiment, the message to be set (registered in association with) the message fish is text, but the message is not limited to text. For example, anything that can be output from a terminal device, such as audio, still images, and moving images, may be used.

  The portal server 1 always stores a data group shown in FIGS. 6 and 7B as the server database 11. The local database 21 of the terminal device 2 has almost the same configuration and contents as the server database. The difference between the server database 11 and the local database 21 is that the local database 21 does not have player data (41) of an avatar (another avatar) operated by another player. Of the local database 21, the fixed parts of the virtual social data (30) and the item data (50) are installed together with the program. And the part updated according to progress to a game is downloaded as update data, whenever the terminal device 2 logs in to the portal server 1 by operation of a player.

  In the above game, when the user's own avatar moves on the stage, the player data and the like of the other person's avatar located on the destination stage is downloaded. At this time, the player data of the other avatar that was located on the stage before the movement is discarded.

  In addition, the self avatar and the other person's avatar always move, the item to be worn and the item to be held may be changed, and the attribute data of the avatar may be changed. For this reason, the portal server 1 updates the player data in the server database 11 when receiving information indicating changes in the player data such as a change in the position of the avatar or a change in the attribute data from each terminal device 2. The transmitted data is periodically transmitted to each terminal device 2 as update information.

  When an avatar (player) purchases a message fish item and releases it to the river or the sea, fish data is created, and this fish data is uploaded from each terminal device 2 to the portal server 1. The portal server 1 registers the fish data in the message data storage unit 60 (registers the message in association with the virtual object), and downloads the fish data to each terminal device 2 when the data is periodically updated.

  This fish data is downloaded to each terminal device 2 in order to reduce traffic, only fish ID, capture condition data, size, appearance image designation data, and location information are logged in or periodically updated, etc. When there is a notification from a certain terminal device 2 that it has been picked up, the message text is downloaded only to that terminal device 2.

However, the following method may be adopted.
(1) Download all fish data (including message text) to all terminal devices 2 at the time of login or the like.
(2) Based on the position information of the fish data, it is determined which stage the fish is in, and the data is downloaded only to the terminal device 2 of the avatar in the same stage.

After the message text of the fish data is transmitted to the terminal device, the fish data is deleted from the message data storage unit 60, and the terminal device 2 is notified that the fish has been caught.
When each terminal device 2 receives the notification that the fish has been caught, the terminal device 2 deletes the already downloaded fish data of the fish.

≪Description of operation≫
The operation of the computer system shown in FIG. 4 will be described with reference to the flowcharts of FIGS.
FIG. 8A is a flowchart showing an operation during login. When the player performs a login operation such as inputting an ID and a password using the terminal device 2 (S1), the terminal device 2 transmits this login operation information to the portal server 1 (S2).

  When the portal server 1 receives the login operation information from the terminal device 2 (S3), the portal server 1 logs in and registers the player (assuming that the login operation information is correct), and performs processing to make the avatar appear in the virtual society. (S4). Then, the latest data is transmitted to the terminal device 2 operated by the player (S5).

  The terminal device 2 receives the data sent from the portal server 1, and updates the local database 21 of the own device with this data (S6). Then, the virtual society is displayed on the monitor 26 based on the data written in the local database 21 and the avatar (including its own avatar) appearing in the virtual society at this time is displayed. A game is started in the device 2 (S7).

  The progress of the game is managed by the game progress management unit 12 of the portal server 1 based on operation information transmitted from the plurality of terminal devices 2, and is transmitted from the portal server 1 in the terminal device 2 that has logged in. Based on the update data, the game progress management unit 25 manages the progress of the game.

  FIG. 8B is a flowchart showing a game progress process in the terminal device 2. This process is executed periodically. First, the game progress management unit 12 of the portal server 1 updates the position of the fish data registered in the message data storage unit 60 of the server database 11 (S9). Since the position of the fish data does not depend on the operation from the terminal device 2, it is determined on the portal server 1 side. Next, based on the updated contents of the server database 11, update data for updating the local database is periodically transmitted to each terminal device 2 (S10). This update data includes data for updating the position information of the fish data and the position and operation of each avatar. The terminal device 2 receives the update data sent from the portal server 1 (S11), updates the local database 21 (S12), and updates the screen display of the monitor 26 based on the update data (S12). S13) By this, the game is advanced.

FIG. 9 is a flowchart showing the operation of the computer system corresponding to the operation control operation of the avatar by the player.
FIG. 3A is a flowchart showing the operation of the terminal device 2. When the player causes the avatar to perform some action, the player instructs the avatar to perform the action by operating the mouse or keyboard of the terminal device 2. For example, when moving the avatar, an appropriate position in the direction to be moved on the screen of the monitor 26, or a store to be entered or a vehicle to be ridden is clicked with the mouse. If you want to hang a fishing line on the sea, right-click on the fishing rod item and select "Drop" from the pull-down menu. When the operation instruction is received by the player (S20), if this instruction is not an instruction to move the avatar to another stage (NO in S21), the terminal device 2 is operating the appearance of the avatar. While changing to a state (S22), this operation information is transmitted to the portal server 1 (S23). For example, when an appropriate position in the direction to be moved or a store to be entered is clicked, its own avatar is controlled to move within the same stage, and a vehicle such as the train 103 in FIG. 1 is clicked The self avatar is controlled to move to another stage. When the menu for hanging the fishing line is selected, the shape is changed so that the fishing rod, which is an item worn by the avatar, is lowered. When the menu for pulling up the fishing line is selected, the shape is changed so that the fishing rod, which is an item worn by the avatar, is pulled up.

  However, if the operation control operation in step S20 is an operation for moving the avatar to another stage (YES in S21), the terminal device 2 transmits this stage movement operation information to the portal server 1. (S25). Thereafter, the data of the new stage of the movement destination is received from the portal server 1 (S26), the local database 21 is updated with this data (S27), the image and avatar of this stage are displayed, and the game is played at this stage. It resumes (S28).

  FIG. 5B is a flowchart showing the operation of the portal server 1 when the operation information is received from the terminal device 2. The portal server 1 receives the operation information transmitted by the terminal device 2 in step S23 of FIG. Then, the player data (position data, motion data) corresponding to the terminal device 2 is updated based on the motion information (S32). The updated player data is transmitted to other terminal devices 2 at the time of periodic data update shown in FIG.

  FIG. 4C is a flowchart showing the operation of the portal server 1 when receiving operation information indicating that the stage is moved from the terminal device 2. The portal server 1 receives the stage movement information transmitted by the terminal device 2 in step S25 in FIG. 5A (S34), and stores the position data and operation data of the avatar data corresponding to the terminal device 2 in this stage. Update based on the movement information (S35). The position data is set to a default position when entering a new stage. Then, the new stage information is transmitted to the terminal device 2 (S36). The updated position data of the avatar is transmitted to each of the other terminal devices 2 at the time of periodic data update shown in FIG.

  As described above, the terminal device 2 transmits the operation information to the portal server 1 and updates the posture and position of its own avatar (without waiting for reception of update data from the portal server). Thereby, the update of the posture and position of the own avatar corresponding to the operation is prevented from being delayed. Note that the user's own avatar may also be moved after receiving the update data from the portal server 1.

  FIG. 10 is a flowchart showing a message registration operation performed by the terminal device 2. This process starts when the player purchases fish at the store. When the player purchases fish (S40), the terminal device 2 displays a message registration window for this fish (S41). This message registration window includes a capture condition input unit and a message text input unit.

  The terminal device 2 first receives an input of capture conditions (S42). The capture condition is data specifying all or part of the avatar attributes shown in FIG. In the input window displayed on the monitor 26, for example, a list of information shown in FIG. 7A is displayed, and the capture condition is input by the player performing an operation of selecting one option from one category of the list. .

  Next, the terminal device 2 receives an input of a message (S43). As described above, the number of characters in a message that accepts input varies depending on the size of the fish. When the message fish is released by the avatar (S44), the message fish data (message data) generated by the above operation is transmitted to the portal server 1 (S45), and the operation is terminated.

  Here, the message data transmitted from the terminal device 2 to the portal server 1 includes an item ID, a size, a capture condition, a message text, a discharge position, and the like. Of these data, the item ID and size are acquired from the item data and transmitted. The size is acquired from item type data (indicating the type of fish in the message fish) included in the item data.

  Note that the message registration window may not be displayed immediately after the player purchases the fish, and the message registration window may be displayed when the fish is possessed as an avatar's possession and the player's display operation is accepted.

  The portal server 1 receives the message data transmitted from the terminal device 2 (S47). Then, this message data is registered as fish data in the message data storage unit 60 of the server database (S48). That is, the portal server 1 generates fish data by attaching a fish ID to the received message data, and registers it in the message data storage unit 60. The registered fish data ID, position data, item ID, size data, capture conditions, and position information are transmitted to each of the other terminal devices 2 at the time of periodic data update shown in FIG. .

FIG. 11 is a flowchart showing a fish catching processing operation, that is, a fishing operation in the terminal device.
When the player hangs the fishing line possessed by his / her avatar on the river or the sea (S49), this operation starts. First, information on the position where the fishing line is hung (the position of the snow) is determined (S50). Based on this position information, it is searched whether there is a fish in the vicinity (S51). This search is determined based on the position information of the fish data downloaded from the portal server 1 to the local database 21. If there is no fish in the vicinity (NO in S52), the operations from S50 onward are repeated until the thread is pulled up (S53). Since the avatar may move the fishing line, the position information is determined every time (S50).

  On the other hand, if there is a fish in the vicinity, it is calculated whether or not this fish is caught (bite) this time based on the probability according to the distance between the fish and the fishing line (fish) (S54). If no fish is caught (NO in S55), the process returns to S50 and the operations after S50 are executed again. Therefore, if there is a fish in the vicinity, the probability calculation of S54 is executed every time until it catches unless the fish has moved far.

  Here, the probability of biting based on the distance between the fish and the fishing line (fish) is 100% when the fish and fish are in the same cell, and decreases by 30% every time one cell is shifted. For example, if the fish is in the cell next to the fish, the probability is 70%.

  On the other hand, if it is determined that a fish has been caught (YES in S55), the capturing information is transmitted to the portal server 1 (S56). The portal server 1 determines whether or not another avatar is already capturing this fish. If no other avatar is capturing, the portal server 1 returns the capture permission information. If the other avatar is already capturing, the portal server 1 does not capture the fish. The permission information is returned (see FIG. 12A). The terminal device receives the capture permission / non-permission information (S57). Next, the size of the fish data and the capture conditions are read out, and it is determined whether the performance of the fishing rod conforms to the size of the fish and whether the attribute of the avatar conforms to the capture conditions of the fish (S58). The reason for judging the suitability of the performance of the fishing rod and the size of the fish is that multiple ranks of the fishing rod function are set, and the limit value of the fish size that can be raised for each rank of the fishing rod is set, This is because there are some fish that are too big to catch depending on the rank of the fishing rod. The fishing rod (item) ID, the rank, and the limit value of the fish size are stored in the server database 11 and the local database 21 in association with each other. Thereafter, the screen is moved to display that the player is catching fish (pulling) (S59).

  Both the message fish item and the fishing rod item are items sold at the store, and there are a plurality of types with different prices. The higher the price, the larger the appearance of the message fish, and the larger the number of characters in the message that can be written. In addition, the fishing rod item has a performance capable of catching a thicker and larger fish as the price increases. In step S58, it is determined whether or not the thickness of the fishing rod is suitable for the size of the message fish to be picked up, that is, the thickness is such that a fish larger than this message fish can be picked up. Make a YES decision when you are.

  It should be noted that, in the determination of conformity / nonconformity of the capture conditions, even if it is not completely adapted, if it is approximated, it may be recognized as suitable with some probability. That is, in the category option list where the capture conditions and attributes do not match (see FIG. 7A), when the capture conditions and the attributes are close to each other, it may be determined to be suitable with a predetermined probability. The options shown in FIG. 7A are listed in order from the approximate one, for example, in order of age (10's, 20's, ...) or in order of region (Hokkaido, Aomori, Iwate, ...). Has been. Therefore, even when the capture condition and the attribute do not match, a process for determining a match when the distance in the option list of FIG. Is possible.

  In this case, the capture probability may be determined according to the distance between the capture condition and the attribute. For example, if the capture condition is 20's, if the attribute is 20's (distance 0), the capture probability is 100%, if the attribute is 10's, 30's (distance 1), the capture probability is 50%, and the attribute is For 40s (distance 2), the capture probability is 20 percent.

In addition, the determination method of whether a fish starts is not limited to the above. That is, in the above embodiment, the success or failure of the capture is determined based on the position information, the capture condition, and the fish size, but some of these conditions may be used, and for example, the fish data indicates the fish type When data is included and the avatar is fishing in the sea, one fish may be selected and drawn by lottery from the data of the sea fish stored in the message data storage unit 60.
I lowered it back)
In response to this pull, it is determined whether or not the player (avatar) has pulled the fishing line within a certain time (S60, S61). If it is not lifted within a certain time (NO in S60, YES in S61), a process to the effect that the fish has escaped is performed (S62), and the operation returns to S50.

  If the fishing line is pulled up within a certain time after the occurrence of pulling (YES in S60), whether the information received in S57 was capture permission information, and the fishing rod, size, and avatar attribute determined in S58 The catching condition is determined (S63). If this condition is satisfied (YES in S63), the fishing process (S64) is executed. On the other hand, if the information received in S57 is non-capture information or if the conditions in S58 are not met (NO in S63), the fishing line is pulled up, but the line breaks and the fish escapes. Processing to that effect is performed (S65), and the operation is terminated.

Here, the processing to the effect that the fish has escaped in step S <b> 62 is processing for stopping the pulling image of uki and transmitting capture failure information to the portal server 1. Further, the processing of the fact that the line is broken in step 65 is a process of erasing the fishing line image while pulling up and transmitting capture failure information to the portal server 1. Note that the rod of the fishing rod that has been cut will be automatically restored at the next use.
Thus, this process starts when the fishing line is hung in step S49 and ends when the fishing line is pulled up in step S53 or step S60.

  FIG. 12A is a flowchart showing the operation of the portal server 1 that has received the capturing information from the terminal device 2. When capturing information is received from the terminal device (S90: corresponding to S56 in FIG. 11), the server database 11 is searched based on the fish ID included in the capturing information, and the capturing flag of this fish data is set. It is determined whether it has been performed (S91). If the other terminal device is not capturing, the capturing flag is reset (NO in S91). After setting the capturing flag (S92), the terminal device that has transmitted the current capturing information is set. Capture permission information is transmitted (S93). On the other hand, if it is already being captured by another terminal device, the capturing flag is set (YES in S91), so the capture non-permission information is transmitted to the terminal device that has transmitted the currently capturing information. (S94).

  FIG. 5B is a flowchart showing the operation of the portal server 1 that has received the capture failure information from the terminal device 2. When the capture failure information is received from the terminal device (S95: corresponding to S62 and S65 in FIG. 11), the server database 11 is searched based on the fish ID included in the capturing information, and the capturing flag of the fish data is detected. Is reset (S96). This allows the fish to be captured again.

  FIG. 13 is a flowchart showing the fishing process in S64 of FIG. First, capture success information is transmitted to the portal server 1 (S70). Correspondingly, the message body written in the caught fish is received from the portal server 1 (S71). Next, in accordance with the avatar fishing operation, the fish image is displayed on the monitor 26 (S72), and this fish is registered in the item table as an owned item (S73). Next, corresponding to the message display device by the player (avatar) (S74), the message text is displayed (S75). The display continues until there is a display erasure operation by the player (avatar) (S76). When there is an erasure operation (YES in S76), the display is erased (S77) and the operation is terminated.

  The portal server 1 receives the capture success information transmitted from the terminal device 2 (S80), reads the message text of the fish data identified by the fish ID included in the capture success information (S81), and receives this message. The text is transmitted to the terminal device 2 (S82). Thereafter, the fish data is deleted (S83), and the operation is terminated. This deletion of fish data is notified to each terminal device 2 from the portal server 1 by S10 shown in FIG. 8, and the terminal device 2 that has received this notification deletes the corresponding fish data from the message data storage unit of the local database 21. To do.

  The fish caught by the above processing becomes an item owned by the avatar from the message managed by the portal server. The avatar can display the message any number of times after clicking this fish item. Also, this item can be bought, sold, exchanged, discarded, etc. like other items.

<< Other Embodiments >>
The message fish has been described above. Next, message butterflies and message bottles will be described. Message butterflies and message bottles are variations of message fish. Message butterflies and message bottles differ from message fish in the following ways.

The message fish swims in the water of the river or sea and can only be seen as a fish shadow until it is picked up, but the message butterflies can fly in the air of all stages and are always visible. Message fish can set avatar attributes that are captured as selection conditions, but message butterflies cannot set selection conditions. If the fish is close, it will hang on the fishing line regardless of the skill of the avatar. However, the message butterfly cannot catch the butterfly unless it operates the tool net, which is a tool item. However, the avatar can catch the message butterfly as long as the insect net can be operated well, and does not choose the attribute of the captured avatar.
In this embodiment, butterflies are used, but the insects flying in the air are not limited to butterflies, and other insects such as dragonflies can be used.

  In addition, since the avatar can pick up message bottles that are placed on the street corner or launched on the beach, no skill is required for acquisition (capture), but the message is read like a message fish. Avatar conditions that can be set. This condition is not a capture condition, but a condition that allows the message to be taken out by opening the lid of the bottle after capture.

  With reference to FIG. 14, the operation procedure of the player when delivering a message using message butterflies will be described.

  FIG. 5A is a flowchart showing a procedure in which the first avatar writes a message on the butterfly and releases it in the air. First, the butterfly for the first avatar to write a message at the store is purchased (S220). And a message is written in this butterfly (S221). Then, the butterfly is released into the air at an arbitrary place (S222). Thereby, this butterfly can freely fly around all stages (by control of the portal server 1).

  FIG. 5B is a flowchart showing a procedure in which the second avatar catches butterflies by reading insects with a bug catching net and reads a message written therein. The second avatar takes the insect net (or purchases the insect net: S225) and finds butterflies in the town or in the field (S226). Then, the insect trapping net is operated so that the butterfly is housed in the net, and the butterfly is captured (S227). The capture of the butterfly is successful when the avatar (player) shakes the insect net and catches the butterfly in the net, that is, when the butterfly is on the trace of the insect net swung by the avatar. If the butterfly is to be caught, the avatar (player) must swing the insect net at a good position at a good timing, and the success or failure of capturing the butterfly reflects the skill of the avatar (player). When the butterfly is captured, a message written on the butterfly is displayed (S228).

  Since the message butterfly is flying in the air and is always visible from the avatar (player), the terminal device 2 performs a process of displaying the butterfly based on the position information notified from the portal server 1.

  FIG. 6C is a flowchart showing an operation that is executed when the second avatar (player) captures the butterfly, that is, when the avatar swings the insect net at the place where the butterfly is located. . When the avatar performs the butterfly capturing operation, that is, when the capturing operation by the player is accepted (S140), the terminal device 2 transmits the capturing operation information to the portal server 1 to determine whether to permit capturing, that is, It is inquired whether other avatars (players) have already captured butterflies (before receiving the image update information from the portal server 1) (S141).

  The portal server 1 receives this capture operation information and executes the processes of S91 to S94 in FIG. That is, it is determined whether or not the butterfly has been captured first based on whether or not the capturing flag of this butterfly data is set (S91). After setting the capturing flag (S92), the capture permission information is transmitted to the terminal device (S93). On the other hand, if another terminal device has already been captured, capture non-permission information is transmitted to the terminal device (S94).

  The terminal device 2 receives information from the portal server 1 (S142). If the received information is capture permission information (YES in S143), the terminal device 2 executes a capture success process (S144). This successful capture process is substantially the same as the message fish fishing process of FIG. 13, and instead of the operation of displaying the fish image in S72, an image in which butterflies are captured in the insect net is displayed. On the other hand, if the information received from the portal server 1 is capture non-permission information (NO in S143), the terminal device 2 displays an image in which the avatar has failed to capture butterflies (an image of butterflies escaping from the net). Display (S145) and end the operation.

  Since no catch condition is set for the message butterfly, it is not determined whether the catch condition of the message fish matches the attribute of the avatar (S58 and S63 in FIG. 11). Further, when receiving the capture permission information, the terminal device 2 proceeds to the capture success process without exception (see S143), and the portal server 1 performs the process of FIG. Never run.

  FIG. 15 is a flowchart showing a player operation procedure when a message is delivered using a message bottle. FIG. 3A is a flowchart showing a procedure for discharging a bottle filled with a memo in which a first avatar has written a message or placing it on a street corner. First, the first avatar purchases a bottle and a memo for writing a message at the store (S230). Then, a message and an attribute of an avatar to be read are written in a memo and enclosed in a bottle (S231). And when this bottle is made to flow, it moves to the river or the sea with the bottle (S232), and the bottle is made to flow to the river or the sea (S233). This causes the bottle to drift (by control of the server computer) and to some shore. In addition, without performing the drift control of the bottle, one point may be selected from a predetermined drift point, and the bottle may be arranged at this point. Further, when the bottle is not poured, it can be placed at any place such as a street corner (S234). In this case, the bottle does not move and remains in the same position until someone picks it up, and the avatar who placed the bottle can see who picks it up.

  FIG. 5B is a flowchart showing an operation that is executed when the second avatar (player) performs an operation of picking up the bottle in the terminal device that operates the second avatar. When the second avatar is operated to pick up the bottle at the coast or on the street corner (S150), the terminal device 2 transmits the pick-up operation information to the portal server 1 to determine whether or not to permit the pick-up, that is, An inquiry is made as to whether another avatar (player) has already picked up the bottle (before receiving the image update information from the portal server 1) (S151).

  The portal server 1 receives this capture operation information and executes the processes of S91 to S94 in FIG. That is, it is determined whether or not the bottle has been picked up first based on whether or not the acquisition flag of this bottle is set (S91). If the acquisition is not being performed by another terminal device, the acquisition is performed. After setting the middle flag (S92), the acquisition permission information is transmitted to the terminal device (S93). On the other hand, if another terminal device has already been acquired, acquisition non-permission information is transmitted to the terminal device (S94).

  The terminal device 2 receives the information from the portal server 1 (S152), and when the received information is the acquisition permission information (YES in S153), the terminal device 2 executes the operation after step S155 (described later). On the other hand, when the information received from the portal server 1 is acquisition non-permission information (NO in S153), the terminal device 2 displays an image in which the avatar has failed to pick up the bottle (image in which the bottle has slipped off from the hand). Is displayed (S154), and the operation is terminated.

  The operations after step S155 are as follows. The terminal device 2 displays an image in which the avatar has successfully picked up the bottle (S155). After that, the avatar performs a lid opening operation of the bottle (S156) or waits until the bottle is placed on the coast or on the street corner again (S157).

When the bottle lid opening operation is performed (YES in S156), the determination is made based on whether or not the attribute of the picked up avatar matches the lid opening condition set in the message of the bottle. A match / mismatch between this attribute and the opening condition is determined in step S158. If this condition is met (YES in S159), a successful opening process is executed (S160). This lid opening success process is almost the same as the message fish fishing process of FIG. 13, and instead of the operation of displaying the fish image in S72, an image that displays the message written in the note inside the bottle lid is opened. Is displayed.
Further, when the avatar (player) performs the operation of placing the bottle on the coast or on the street corner again (YES in S157), the lid opening failure process is executed (S161), and the operation is terminated.

  The lid opening failure process in step S161 is a process of displaying the bottle image on the virtual society at the foot of the avatar and transmitting the lid opening failure information to the portal server 1. The portal server 1 that has received the lid opening failure information executes the process of FIG. 12B as in the case of the message fish.

  In this way, the message bottle can pick up any avatar without tools. Also, after picking up, the message can be read with the lid open only if the lid opening condition is met.

  In the case of a message bottle, processing differs depending on whether it is drifting or drifting on the shore, so the processing of FIG. 16 is executed instead of S9 of FIG. 8 which is processing in the case of a message fish that is always migrating. In FIG. 16, it is first determined whether the bottle is drifting (S100). Whether it is drifting or not is determined by the drift flag provided in the bottle data registered in the database. The drift flag is a flag that is set when the bottle has drifted to the shore or placed on a street corner or the like.

  When drifting, that is, when the drift flag is reset, position data representing the drift position of the bottle is updated (S101). This position data is distributed to each terminal device at the next data update time. Then, it is determined whether or not the shore has been stranded by this movement (S102). Whether or not the ship has drifted to the shore is determined by comparing the map data in the database with the position data updated this time. If it has drifted (YES in S102), the drift flag is set (S103) and the operation is terminated. The set of the drift flag is distributed to each terminal device at the next data update. On the other hand, if it has not yet drifted to the shore (NO in S102), the operation is finished as it is.

  In the embodiment and the modification described above, the items that are registered in association with the message are fish, butterflies, and bottles, but the type of the item is not limited to this, and any item that exists in the virtual society. Good.

≪Donkey ear well≫
Next, the donkey ear well will be described with reference to FIGS. 17 and 18. "Message fish", "message butterfly", and "message bottle", which are the means of communication through the avatar activities described above, each object (fish, butterfly, bottle) in which a message is written into one avatar. The message was only displayed to the avatar (player or terminal device) that was captured, but the donkey's ear well was blown out of the well like a geyser at the appropriate time, and then the surroundings of the well The avatar in can read.

  FIG. 17A is a flowchart showing a procedure for inputting and outputting a donkey ear well message in a network game. The avatar goes to the well end (S240) and inputs a message (S241). The message input to the well is a diversion (metaphor) of blowing a secret story (the king's ear is the donkey's ear) toward the well, but in this game the message is input by clicking on the well This is done by typing a message into the message input window displayed by. A message is input a plurality of times by many avatars, and a randomly selected message is output from the well (S242). The message is output by being displayed in a balloon window displayed in such a manner that a voice can be heard from the well. As a message input to the well, a microphone may be provided in the terminal device 2 so that voice data is actually injected instead of text data.

  Since the message input to the well is free, unlike the message fish, message butterfly, and message bottle described above, the same avatar may repeatedly input the message. Therefore, the recording time and the avatar ID may be added to the input message so that the same avatar cannot input the message many times (for example, about once a day).

  FIG. 17B is a diagram showing a configuration of well message data registered in the server database 11. The well message data includes a message ID that is information for identifying the moving message data, a well ID that is information for identifying the well in which the well message data is input, a recording time of the well message, and a displayable flag. And a message body. The displayable flag is a flag indicating that this message has been selected to be displayable (details will be described later).

  In the virtual society of this network game, there are a plurality of wells through which messages can be input, and the game progress management unit 12 outputs which message intermittently based on the recording time of the message and the well ID. To decide.

FIG. 18A is a flowchart showing the operation of the computer system when a well message is input. In the terminal device 2, when the well is clicked by the avatar, this operation is executed. When the avatar moves and clicks (S110), a message input window is displayed (S111). This input window is displayed in the shape of a balloon window from the well. When a message is input by the avatar (player) (S112), the balloon window is deleted so as to be sucked into the well (S113), and information such as the well ID and recording time is added to the portal server (S114). .
The portal server 1 receives the message transmitted from the terminal device 2 (S115), and registers it as well message data in the database (S116).

  FIG. 5B is a flowchart showing the operation of the computer system when a well message is output. The game progress management unit 12 of the portal server 1 regularly selects well message data (S120). This selection is performed at random, but may be selected with reference to the recording time so as to preferentially output old messages. When a message is selected, counting of the storage time is started, and the well message data is set to be displayable, that is, a displayable flag is set (S121). The message set to be displayable is transmitted to the terminal device of the avatar in the same stage as the well that outputs this message at the next periodic data update. In addition, you may select the avatar which exists in the predetermined area (area which can display a well on a display screen) around a well instead of the avatar in the same stage as a well. Then, the selected message waits until a certain storage time elapses from the selection (S122). When the storage time elapses (YES in S122), the well message data (the well in which the displayable flag is set) is set. Message data) is deleted (S123). The storage time is approximately 2 hours. If there is an avatar that has moved to this stage within the predetermined period, the well message is also transmitted to the terminal device of the avatar.

  FIG. 5C is a flowchart showing the operation of the terminal device 2 that has received the well message. When receiving the well message, the terminal device 2 starts measuring the storage time, and intermittently displays the well message at regular intervals until the storage time elapses. In the standby routines of steps S130 and S131, it is determined whether the display time has arrived (S130) or whether the storage time has elapsed (S131).

When the display time has arrived (YES in S130), the received well message is displayed in a balloon window that is ballooned from the well (reproduced when the message data is voice data) (S132). Since this display is displayed as an object on the well, even if it is the same stage, if the avatar is in a position where the well is not visible, it is not actually displayed on the monitor 26. When a certain display time (for example, 5 minutes) elapses (S133), this window display is deleted (S134), and the process returns to the standby routine.
On the other hand, if the storage time has elapsed (YES in S131), the received well message is deleted (S135), and the operation is terminated.

  Although multiple wells are arranged in the virtual society, the selected message may be displayed as a balloon from one of the wells (generally recorded wells). It may be displayed at the same time. The selection of well message data in S120 may be performed by selecting one or a plurality of well message data for all wells, and selecting one or a plurality of messages from messages input from each well. Also good. In addition, there may be an empty selection (zero selection) times in the regular selection. In addition, a message may be selected to be output from a well different from the input well. Only one well may be arranged in the virtual society.

  In this embodiment (the donkey's ear well), the well message is displayed every time a predetermined display time arrives, but the display timing of the well message is not limited to this. For example, when the avatar performs a specific operation on the well, that is, when the terminal device 2 receives a specific operation from the player, the well message may be displayed. For example, when the avatar looks into the well (when the player double-clicks the well), the well message may be displayed only by the terminal device 2 that has performed the operation. In this case, S130 in FIG. 18C may be a determination operation for determining the avatar peeping operation (specific operation by the player).

  In addition, although this embodiment (Ear well of donkey) is the structure by which a message is displayed from a well, the virtual building where a message is displayed may not be a well, for example, a toilet etc. may be sufficient. Further, it may be a virtual object such as a lake or a pond, or a telephone instead of a virtual building.

  In the embodiments (donkey ear well, message fish), the server constituting the computer system executes the portal function, and the game content is associated with the portal function, but is not limited to this configuration. . The game according to the present embodiment may be a role-playing game, another type of game such as an action game, or a game that can activate an avatar that allows an item to be displayed in a virtual society. That's fine.

  Note that the system configuration of the computer system is not limited to this, and the portal server may be configured by a plurality of devices, and also has a function as a product sales server, so that actual products can be sold by the portal server. Also good.

  The “avatar” generally does not include a game character, but in the present invention includes a game character that is operated by a player's operation.

The figure which shows an example of the virtual society used as the stage of the network game performed with the computer system to which this invention is applied The figure which shows the example of a screen display of the said virtual society Figure showing an example of an avatar Flow chart showing the procedure for writing and catching messages on message fish in the game The figure which shows the structure of the computer system which performs the said network game The figure which shows the server database which is established in the portal server The figure which shows the server database which is established in the portal server A flowchart showing the operation of the computer system at the time of login and periodic data update Flow chart showing avatar motion control processing Flow chart showing the operation when registering a message The flowchart which shows operation of the terminal device at the time of fish capture (fishing) operation The flowchart which shows the operation of the portal server at the time of fish capture (fishing) operation Flow chart showing the operation of the computer system when fishing is successful Flow chart showing the procedure for writing and capturing messages on message butterflies in the game Flow chart showing the procedure for writing and capturing messages in message bottles in the game Flowchart showing message bottle location information update procedure Flow chart showing the procedure for inputting and outputting messages to the donkey's ear well in the game The flowchart which shows the process sequence of the computer system for performing the message input / output to the ear well of a donkey

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Portal server 2 ... Terminal device 11 ... Server database 12 ... Game progress management part 21 ... Local database 25 ... Game progress management part 30 ... Virtual social storage part 60 ... Message storage part

Claims (6)

To a computer system in which multiple terminal devices are connected via a network,
A virtual society generation procedure for generating a virtual society including a plurality of virtual characters (hereinafter referred to as avatars) respectively operated by the plurality of terminal devices, and a virtual object;
A display procedure for displaying the virtual society on a display unit of each terminal device;
When a message input operation associated with the virtual object is accepted from a specific terminal device, a message registration procedure for registering the message in association with the virtual object;
An acquisition procedure for causing the unspecified avatar to acquire and occupy the virtual object in which the message is registered in accordance with an operation for acquiring the unspecified avatar that is one of the plurality of avatars
When the virtual object is occupied by the unspecified avatar, a message output permission procedure that enables the message to be output to a terminal device that operates the unspecified avatar;
A program to be executed by the,
The acquisition procedure is a procedure for causing the unspecified avatar to use a virtual tool item to acquire the virtual object, and the virtual object can be acquired according to the performance of the tool item used by the unspecified avatar. A program that includes procedures for determining whether or not A moving procedure for moving a virtual object in which a message is registered in the virtual society,
The program according to claim 1, further causing the computer system to execute.   By the operation from the terminal device that operates the unspecified avatar, the occupation of the virtual item occupied by the unspecified avatar is released according to the acquisition operation, and the state is returned to a state where other unspecified avatars can be acquired. The program according to claim 1 or 2, further causing the computer system to execute an exclusive release procedure. The virtual society generation procedure includes a procedure of generating an avatar to which an attribute is given,
The message registration procedure includes a procedure of registering an attribute with a message,
The acquisition procedure includes a procedure for enabling acquisition of the virtual object only to an unspecified avatar to which an attribute matching the attribute registered in association with the virtual object is given. The program according to any one. The program according to any one of claims 1 to 4 , wherein the specific terminal device is a terminal device on which a purchase operation of the virtual item is performed. A computer system comprising: a storage unit that stores the program according to any one of claims 1 to 5 ; and a computer that executes the program.

Images