Program and system

Abstract

To improve a user's level of interest.SOLUTION: A program causing a computer to function as control means that, based on sound data obtained by a user, changes a display of an object on a portal screen.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present invention relates to a program and a system. [Background technology]

[0002] In recent years, it has become known to play sound data such as music when a predetermined application program is being executed on a user terminal.

[0003] However, such sound data has a strong auxiliary element, and it is desirable to use it to further enhance the user's interest. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-103729 Summary of the Invention [Problem to be solved by the invention]

[0005] SUMMARY OF THE INVENTION It is therefore an object of the present invention to provide a program and a system that can increase the interest of users. [Means for solving the problem]

[0006] According to one aspect of the present invention, there is provided a program that causes a computer to function as a control means that changes the display of an object on a portal screen based on sound data obtained by a user. [Effects of the Invention]

[0007] The present invention makes it possible to increase the interest of users. [Brief explanation of the drawings]

[0008] [Figure 1]FIG. 1 is a diagram showing an example of the configuration of a game system according to an embodiment. [Figure 2] FIG. 2 is a diagram showing an example of the hardware configuration of a user terminal. [Figure 3] FIG. 2 is a diagram illustrating an example of a hardware configuration of a server device. [Figure 4] FIG. 2 is a diagram showing an example of the functional configuration of a user terminal. [Figure 5] FIG. 2 is a diagram illustrating an example of the functional configuration of a server device. [Figure 6] 10 is a flowchart showing an example of a processing procedure of a game system. [Figure 7] FIG. 10 is a diagram showing an example of a first screen. [Figure 8] FIG. 10 is a diagram for explaining an example of an arrangement of characters displayed on the first screen. [Figure 9] FIG. 10 is a diagram showing an example of a second screen. [Figure 10] FIG. 10 is a diagram for explaining an example of an arrangement of characters displayed on the second screen. [Figure 11] FIG. 10 is a diagram showing an example of a third screen. [Figure 12] FIG. 10 is a diagram for explaining an example of an arrangement of characters displayed on the 3rd screen. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Fig. 1 shows an example of the configuration of a game system according to this embodiment. The game system 1 shown in Fig. 1 is configured to enable users to play games online, for example, and includes a user terminal 10 and a server device 20.

[0010] The user terminal 10 is, for example, an electronic device used by a user. In this embodiment, the user terminal 10 is assumed to be, for example, a smartphone, but the user terminal 10 may also be other electronic devices such as a tablet terminal, a personal computer, or a video game device.

[0011] The server device 20 is provided to enable users to play games using the user terminals 10, and is communicably connected to the user terminals 10 via a network 30 such as the Internet.

[0012] Although only one user terminal 10 is shown in FIG. 1, the game system 1 includes a plurality of user terminals used by a plurality of users who can play the game.

[0013] Fig. 2 shows an example of the hardware configuration of the user terminal 10 shown in Fig. 1. Here, with reference to Fig. 2, the hardware configuration when the user terminal 10 is a smartphone will be described.

[0014] As shown in FIG. 2, the user terminal 10 includes a nonvolatile memory 11, a CPU 12, a main memory 13, a wireless communication device 14, a display 15, a touch panel 16, and the like.

[0015] The nonvolatile memory 11 stores various programs. The various programs stored in the nonvolatile memory 11 include, for example, an operating system (OS) and various application programs that run on the user terminal 10.

[0016] The CPU 12 is a processor for controlling the operations of various components within the user terminal 10, and executes various programs stored in, for example, the non-volatile memory 11. The CPU 12 may be a single processor or may be configured with multiple processors.

[0017] The various programs stored in the non-volatile memory 11 are loaded from the non-volatile memory 11 into the main memory 13 and executed by the CPU 12, and the programs (application programs) executed by the CPU 12 include a game program 13A for operating as a user terminal in the game system 1.

[0018] The wireless communication device 14 is a device for performing wireless communication with an external device (for example, a server device 20, etc.).

[0019] The display 15 is a device for displaying, for example, various screens relating to the game played by the user.

[0020] The touch panel 16 is a device that detects the position where the user's fingertip or the like touches, and is disposed, for example, on the front surface of the display 15, overlapping it.

[0021] The display 15 and the touch panel 16 constitute a touch screen display, and the touch screen display can detect (accept) various operations performed by the user on the screen.

[0022] Fig. 3 shows an example of the hardware configuration of the server device 20 shown in Fig. 1. As shown in Fig. 3, the server device 20 includes a nonvolatile memory 21, a CPU 22, a main memory 23, a wireless communication device 24, and the like.

[0023] The nonvolatile memory 21 stores various programs. The various programs stored in the nonvolatile memory 21 include, for example, an operating system (OS) and various application programs that run on the server device 20.

[0024] The CPU 22 is a processor for controlling the operations of various components in the server device 20, and executes various programs stored in the nonvolatile memory 21, for example. The CPU 22 may be a single processor or may be configured with multiple processors.

[0025] The various programs stored in the non-volatile memory 21 are loaded from the non-volatile memory 21 into the main memory 23 and executed by the CPU 22, and the programs (application programs) executed by the CPU 22 include a game program 23A for operating as a server device in the game system 1.

[0026] The wireless communication device 24 is a device for performing wireless communication with an external device (for example, the user terminal 10, etc.).

[0027] The following describes the functional configuration of the game system 1 according to this embodiment. The game system 1 according to this embodiment has a function that enables users to play games by, for example, operating in cooperation with the user terminal 10 and the server device 20.

[0028] Here, an overview of the game that can be played by the user in this embodiment will be described. The game system 1 (user terminal 10 and server device 20) according to this embodiment provides a game play environment in which it is possible to play a game that has elements of an action game and elements of a role-playing game (hereinafter referred to as an action RPG game).

[0029] As an element of an action game included in an action RPG game, the user can move the user's character (hereinafter referred to as the player character) placed in a virtual space (game space) prepared in the game play environment and engage in battles between the player character and enemy characters by performing a predetermined operation on the user terminal 10. Also, as an element of a role-playing game included in an action RPG game, the user can grow (train) the player character as the game progresses.

[0030] 4 shows an example of the functional configuration of the user terminal 10. As shown in FIG. 4, the user terminal 10 includes an operation receiving unit 101, a control unit 102, a display processing unit 103, and a storage unit 104.

[0031] 4 are functional units realized by, for example, the CPU 12 (the computer of the user terminal 10) of the user terminal 10 executing the above-mentioned game program 13A (i.e., software). This game program 13A may be downloaded to the user terminal 10 via the network 30, or may be distributed by being stored in advance in a computer-readable storage medium.

[0032] 4 is realized by the nonvolatile memory 11 shown in FIG. 2 or another storage device (not shown).

[0033] The operation reception unit 101 receives user operations (instructions) for playing the action RPG game of this embodiment. When the user terminal 10 is a smartphone as described above, the operations received by the operation reception unit 101 include operations of touching a fingertip to a touch panel 16 (touch screen display) provided on the user terminal 10 (for example, a tap operation, a long tap operation, a swipe operation, etc.).

[0034] The control unit 102 executes control to progress the action RPG game based on the operation accepted by the operation accepting unit 101.

[0035] The display processing unit 103 displays various screens for playing the action RPG game under the control of the control unit 102.

[0036] The storage unit 104 stores, for example, game data and user data. In the game system 1, an account is issued for each user who can play the action RPG game. The game data is common data among the accounts and is referenced when the above-described game program 13A is executed. Specifically, the game data includes, for example, data for defining the game play environment and setting data related to the action RPG game. Meanwhile, the user data is data related to the user that is managed for each user account. Specifically, the user data stored in the storage unit 104 included in the user terminal 10 (i.e., user data related to the user who uses the user terminal 10) includes, for example, data for managing the user's game progress, the characters owned by the user, and the items acquired by the user.

[0037] 5 shows an example of the functional configuration of the server device 20. As shown in FIG. 5, the server device 20 includes a storage unit 201, a data management unit 202, and a control unit 203.

[0038] The storage unit 201 shown in FIG. 5 is realized by the nonvolatile memory 21 shown in FIG. 3 or another storage device (not shown).

[0039] 5 are functional units realized by, for example, a CPU 22 (a computer of the server device 20) provided in the server device 20 executing the above-described game program 23A (i.e., software). This game program 23A may be downloaded to the server device 20 via the network 30, or may be distributed by being stored in advance in a computer-readable storage medium.

[0040] The storage unit 201 stores game data similar to the game data stored in the storage unit 104 included in the above-described user terminal 10. The storage unit 201 also stores user data for each user registered in the game system 1 (server device 20) (i.e., a user to whom an account has been issued).

[0041] The data management unit 202 manages the game data and user data stored in the storage unit 201. Specifically, the data management unit 202 executes processes such as adding, updating, and deleting game data and user data.

[0042] The game data and user data managed by the data management unit 202 are transmitted from the data management unit 202 (server device 20) to the user terminal 10 and stored in the storage unit 104 included in the user terminal 10.

[0043] The control unit 203 executes various processes to provide a game play environment for playing the action RPG game (that is, to enable the user to play the action RPG game).

[0044] It should be noted that "provision of a game play environment" in this embodiment is realized by a game program that operates in the game system 1 (i.e., the game program 13A executed in the user terminal 10 and the game program 23A executed in the server device 20). However, the game program according to this embodiment may be a part of the game programs 13A and 23A.

[0045] Furthermore, in the game system 1 according to this embodiment, for example, the server device 20 may have at least some of the functions of the user terminal 10, or the user terminal 10 may have at least some of the functions of the server device 20. Furthermore, the game system 1 may include devices other than the user terminal 10 and the server device 20. That is, the game program according to this embodiment (game programs 13A and 23A) may be executed by the user terminal 10, the server device 20, or another device.

[0046] In the action RPG game of this embodiment, in-game music (music pieces) such as BGM (Background Music) and VGM (Video Game Music) are prepared as sound data. In this embodiment, a mechanism is adopted in which new sound data to be played in the action RPG game can be obtained by satisfying certain conditions while playing the action RPG game.

[0047] Specifically, when a quest (event) that a user can play (participate in) in an action RPG game begins, a virtual space in which a player character is placed is displayed on the screen (display 15) of the user terminal 10, and the player character battles an enemy character placed in the virtual space based on the user's operation on the user terminal 10. In an action RPG game, the user can develop their character by winning the battle against such an enemy character (i.e., clearing the quest). The above-mentioned sound data can be obtained, for example, by opening an object such as a treasure chest placed in the virtual space displayed on the screen of the user terminal 10 when playing a quest.

[0048] However, the path (method) for obtaining sound data is not limited to this. Sound data may be obtained, for example, by clearing a quest or accomplishing a mission provided in the quest. Furthermore, sound data may be obtained by the player character reaching a predetermined position in the virtual space or by the player character coming into contact with a predetermined character located in the virtual space. Furthermore, sound data may be obtained by winning a battle against a predetermined enemy character located in the virtual space. Furthermore, sound data may be obtained by playing a quest using a predetermined character. Furthermore, part of the predetermined condition for obtaining sound data may be playing the action RPG game with the mute mode of the user terminal 10 turned off (i.e., in a state where the user can hear the in-game music).

[0049] In this embodiment, "obtaining sound data" means that the sound data can be played as background music or visual music (VGM) when playing an action RPG game (e.g., a quest) (hereinafter referred to as quest background music). In other words, when the user obtains sound data, the sound data can be set as quest background music.

[0050] As described above, sound data that can be obtained by the user (sound data prepared in advance in an action RPG game) is managed, for example, as game data, and the sound data (identification information for identifying) obtained by the user is managed, for example, as user data. By referencing such game data and user data, it becomes possible to play, for example, sound data set (selected) by the user from a list of sound data obtained by the user as quest background music.

[0051] As mentioned above, users can obtain sound data by meeting certain conditions, but in action RPG games, the sound data is largely auxiliary and may not contribute sufficiently to increasing the interest of users playing the RPG game.

[0052] Therefore, in this embodiment, a function is provided for utilizing sound data prepared in an action RPG game to enhance the user's interest.

[0053] Specifically, in this embodiment, a configuration is adopted in which the display of an object on a specified screen of an action RPG game is changed based on sound data (i.e., the result of obtaining the sound data) obtained by the user by, for example, satisfying specified conditions.

[0054] An example of a processing procedure of the game system 1 according to this embodiment will be described below with reference to the flowchart of Fig. 6. Note that although the processing shown in Fig. 6 is assumed to be mainly executed by the user terminal 10, at least a part of the processing shown in Fig. 6 may be executed by the server device 20.

[0055] First, the control unit 102 included in the user terminal 10 determines whether or not to display a predetermined screen in the action RPG game in response to a user operation accepted by the operation accepting unit 101 (step S1).

[0056] An example of the predetermined screen is a portal screen in an action RPG game. The portal screen is also called a home screen or a top screen, and corresponds to a screen that serves as a starting point for transitioning to multiple other screens for using various functions provided in the action RPG game.

[0057] Specifically, the portal screen may be a screen that is displayed when the action RPG game is started (the game program 13A is launched), a screen that displays ongoing events, or a screen that displays a selection image that serves as an entrance to transition to a screen of ongoing events, or an announcement image of ongoing events or upcoming events. Other screens to which the portal screen transitions include various setting screens, a screen (character formation screen) for organizing a party for playing a quest (i.e., selecting characters to compose the party), a screen for acquiring characters or items that can be used in the action RPG game according to the results of a lottery, and a screen (quest selection screen) for selecting a quest to play.

[0058] If it is determined that the predetermined screen is not to be displayed (NO in step S1), the process of step S1 is repeatedly executed.

[0059] On the other hand, if it is determined that a predetermined screen is to be displayed (YES in step S1), the control unit 102 identifies the number of pieces of sound data that the user has already acquired (hereinafter referred to as acquired sound data) (step S2). Note that the number of pieces of acquired sound data can be identified by referring to the user data as described above.

[0060] Next, the control unit 102 determines whether the number of acquired sound data identified in step S2 satisfies a predetermined first condition (step S3). In step S3, for example, if the number of acquired sound data is less than a predetermined value (hereinafter referred to as a first threshold), it is determined that the number of acquired sound data satisfies the first condition.

[0061] If it is determined that the number of acquired sound data satisfies the first condition (YES in step S3), the display processing unit 103 displays the first screen as the above-mentioned predetermined screen (portal screen) (step S4) in accordance with the control of the control unit 102. Note that the first screen displays, for example, characters (objects) that appear in an action RPG game.

[0062] On the other hand, if it is determined that the number of acquired sound data does not satisfy the first condition (NO in step S3), the control unit 102 determines whether the number of acquired sound data satisfies a predetermined second condition (step S5). Note that in step S5, for example, if the number of acquired sound data is less than a predetermined value (hereinafter referred to as a second threshold), it is determined that the number of acquired sound data satisfies the second condition. Note that the second threshold is a value greater than the first threshold described above.

[0063] If it is determined that the number of acquired sound data satisfies the second condition (YES in step S5), the display processing unit 103 displays the second screen as the above-mentioned predetermined screen (portal screen) (step S6) in accordance with the control of the control unit 102. Note that the second screen is a screen in which the display of characters (objects) is different from that of the above-mentioned first screen.

[0064] If it is determined that the number of acquired sound data does not satisfy the second condition (NO in step S5), the display processing unit 103 displays the third screen as the above-mentioned predetermined screen (portal screen) (step S7) in accordance with the control by the control unit 102. Note that the third screen is a screen in which the display of characters (objects) is different from that of the above-mentioned first and second screens.

[0065] According to the process shown in FIG. 6, when a predetermined screen such as a portal screen is displayed, control is realized to change the display of the character based on the number of sound data already obtained.

[0066] Note that Figure 6 mainly describes the processing (control) when displaying the portal screen, and omits detailed explanations of other processing (e.g., control related to battles) that is executed in response to playing the action RPG game.

[0067] Here, specific examples of the first to third screens displayed as the portal screen in this embodiment will be described. Note that the portal screen in this embodiment is a 3D portal screen that displays characters appearing in an action RPG game in three dimensions. On this portal screen, for example, a video of a character playing a musical instrument on a live stage is displayed.

[0068] Fig. 7 shows an example of the first screen. As shown in Fig. 7, the first screen 300 is a screen that displays, for example, three characters 300a to 300c arranged on a live stage. Fig. 8 shows an example of the arrangement of the characters 300a to 300c from above the live stage. In the example shown in Fig. 8, character 300a is arranged near the center of the live stage when viewed from the side where the audience is positioned, character 300b is arranged to the left of character 300a when viewed from the side where the audience is positioned, and character 300c is arranged to the right of character 300a when viewed from the side where the audience is positioned.

[0069] Fig. 9 shows an example of the second screen. As shown in Fig. 8, second screen 400 is a screen in which a plurality of characters including characters 400a to 400c corresponding to audience members are further added to first screen 300. Fig. 10 shows an example of the arrangement of a plurality of characters including characters 400a to 400c from a position facing the live stage where characters 300a to 300c are arranged (i.e., behind the audience). In the example shown in Fig. 10, five characters including characters 400a to 400c are arranged in a position facing characters 300a to 300c below the live stage.

[0070] Fig. 11 shows an example of the third screen. As shown in Fig. 9, the third screen 500 is a screen in which a plurality of characters including characters 500a to 500c are further added to the second screen 400. Fig. 12 shows an example of the arrangement of a plurality of characters including characters 500a to 500c from above the live stage. In the example shown in Fig. 12, four characters including characters 500a to 500c are arranged behind characters 300a to 300c when viewed from the side where the audience is positioned (i.e., the lower side of the live stage).

[0071] Here, it is assumed that the total number of sound data that the user can obtain in the action RPG game in this embodiment is 10, and the first threshold value described in Figure 6 above is 4 and the second threshold value is 8.

[0072] In this case, the first screen 300 shown in Fig. 7 is displayed when the number of acquired sound data is less than 4. The second screen 400 shown in Fig. 8 is displayed when the number of acquired sound data is 4 or more but less than 8. Furthermore, the third screen 500 shown in Fig. 9 is displayed when the number of acquired sound data is 8 or more.

[0073] That is, in the above example, the number of characters displayed increases from the first screen 300 to the second screen 400 and the third screen 500, and in this embodiment, it can be said that it is possible to customize the portal screen so that the excitement of the live performance increases by obtaining sound data (that is, the excitement increases step by step by adding characters to be displayed). Therefore, in this embodiment, it is possible to increase the interest of users who play the action RPG game using the portal screen.

[0074] Furthermore, producers of sound data (in-game music) want users to take an interest in the sound data, but as mentioned above, the sound data is often a supplementary element of an action RPG game, and users are often not very interested in the sound data. However, in this embodiment, for example, since it is possible to customize the portal screen as the number of acquired sound data increases, it is expected that users will actively acquire sound data, and as a result, users will take an interest in the sound data (for example, users will listen to background music, etc.).

[0075] 7 to 12, the characters displayed on the portal screen may be predetermined characters (may be fixed) or may be characters designated (set) by the user. Furthermore, the characters displayed on the portal screen may be characters owned by the user (characters acquired by the user in an action RPG game) or characters not owned by the user.

[0076] 7 to 12 are merely examples, and the arrangements of the characters displayed on the portal screens may be changed. Specifically, for example, the positions of the characters 300a to 300c shown in FIGS. 7 and 8 may be changed, or the position of the character 300a may be swapped with the position of the character 300b or 300c. While the characters 300a to 300c have been described here, the same applies to the other characters displayed on the portal screens. Note that information such as the characters displayed on the portal screens and the positions at which the characters are positioned (i.e., information for displaying the characters on the portal screens) may be managed in game data or user data.

[0077] Furthermore, although it is assumed that the characters are displayed as three-dimensional moving images on the portal screen, the characters may be displayed so as to be observed from different viewpoints (i.e., the viewpoint changes sequentially). The characters may also be displayed so as to be observed from a fixed viewpoint. The viewpoint from which the characters are observed may also be specified in response to a user operation.

[0078] The portal screen may be a 2D portal screen that displays the character in two dimensions, rather than a 3D portal screen that displays the character in three dimensions. Furthermore, whether the character is displayed in three dimensions or two dimensions on the portal screen may be set (designated) by the user. In other words, the user may be able to select (switch) between the 3D portal screen and the 2D portal screen. Furthermore, since the appearance of the character differs between the 3D portal screen and the 2D portal screen as described above, the position of the character may be changed between the 3D portal screen and the 2D portal screen so that the character can be easily viewed.

[0079] Incidentally, the above-mentioned first screen 300, second screen 400, and third screen 500 are screens displayed as portal screens in an action RPG game (screens that function as portal screens), and the portal screens have multiple buttons arranged on them for transitioning to other screens.

[0080] Specifically, in the examples shown in FIGS. 7 to 9, buttons 601 to 610 are arranged on the portal screen. Button 601 labeled "Go Adventure" is a button for transitioning to the quest selection screen described above. Button 602 labeled "Party" is a button for transitioning to the character organization screen described above. Button 603 labeled "Facility" is a button for transitioning to a screen displaying the user's facility site. In an action RPG game, placing a predetermined facility in the user's facility site can have the effect of allowing the game to proceed more advantageously.

[0081] Also, for example, if the portal screen is the top screen of a specific event, button 604 labeled "progress" is a button for transitioning to a screen where the progress of the event can be confirmed. Button 605 labeled "event" is a button for transitioning to a screen that displays (a list of) other events currently being held. Button 606 labeled "lottery" is a button for transitioning to a screen where characters or items can be acquired by lottery.

[0082] Furthermore, button 607 labeled "Menu" is a button for transitioning to a screen where various settings can be made in the action RPG game. Button 608 labeled "Mission" is a button for transitioning to a screen where the contents of the missions prepared in the action RPG game and the progress of the missions can be confirmed. Button 609 labeled "Presents" is a button for transitioning to a screen where the user can confirm and acquire items (presents) that can be acquired.

[0083] Moreover, the button 610 labeled "VIEW" is a button for removing the above-mentioned buttons 601 to 610 from the portal screen and improving the visibility of the characters displayed on the portal screen.

[0084] In this embodiment, characters are added to the portal screen (the number of characters displayed on the portal screen changes) depending on the number of acquired sound data. However, sound data that the user can acquire may be associated with a specific character (i.e., in-game music may be prepared for each character). In this case, for example, each time sound data is acquired, a character associated with the acquired sound data may be added (newly displayed) on the portal screen. With this configuration, the portal screen is customized so that the number of acquired sound data and the number of characters displayed on the portal screen are the same. In the case where characters associated with acquired sound data are added to the portal screen as described above, the arrangement of the characters on the portal screen may be determined based on the order in which the sound data was acquired. The correspondence between sound data and characters may be managed, for example, in game data.

[0085] Furthermore, when sound data is obtained by the user as described above, the character associated with the sound data may be released, allowing the user to use (operate) the character to play a quest. In other words, the sound data may be used not only to display a character, but also to make a character available in an action RPG game appear.

[0086] Furthermore, for example, if sound data corresponding to a character already owned by the user is obtained (i.e., the character corresponding to the obtained sound data matches a character already obtained and owned in the action RPG game), a special effect may be generated for that character. This special effect may include, for example, the release of a new skill (special ability) for the character corresponding to the obtained sound data, or the application of a special effect to the character displayed on the portal screen.

[0087] Furthermore, in this embodiment, multiple characters are displayed on the portal screen, and when, for example, a character displayed on the portal screen is designated by the user (a tap operation is performed on the character), the portal screen may transition to a screen (details screen) that displays details of the sound data (in-game music) associated with the character. On the details screen, it is possible to, for example, check the title of the in-game music, listen to the in-game music, or set the in-game music (character-specific BGM) as quest BGM or default BGM. The information (sound data details) displayed on the details screen may be managed, for example, in game data or the like.

[0088] Furthermore, in this embodiment, it has been described that characters playing musical instruments are displayed on the live stage, but if, for example, an instrument (object) can be obtained by playing a quest, it may be possible to change the instrument played by a specific character by associating that instrument with that specific character.

[0089] In this embodiment, the number of characters displayed on the portal screen increases as the number of acquired sound data increases, but this embodiment is only required to change the number of characters displayed on the portal screen based on the number of acquired sound data, and it is not necessary to increase the number of characters as the number of sound data increases. Specifically, for example, when the number of acquired sound data is small, multiple characters with low rarity may be displayed on the portal screen, and when the number of acquired sound data is large, one character with high rarity may be displayed on the portal screen.

[0090] Furthermore, in this embodiment, instead of changing the number of characters based on the number of acquired sound data, the movements of the characters may be changed based on the number of acquired sound data. Specifically, for example, a character performing a first action (e.g., a relatively gentle movement) may be displayed on the first screen, a character performing a second action (e.g., a more intense movement than on the first screen) may be displayed on the second screen, and a character performing a third action (e.g., a more intense movement than on the second screen) may be displayed on the third screen. Also, a character performing a different action (e.g., a special dance) may be displayed depending on the number of acquired sound data.

[0091] Furthermore, in this embodiment, the display of the character displayed on the portal screen may be changed based on the result of obtaining the sound data (for example, the type or combination of the obtained sound data) rather than the number of obtained sound data. Specifically, for example, when sound data corresponding to a first character and sound data corresponding to a second character that has a high degree of intimacy with (or is related to) the first character are obtained, the first character and the second character may be displayed in association with each other on the portal screen. In this case, the first character and the second character may be displayed, for example, so as to perform a special action, or may be displayed in a state where they are positioned close to each other.

[0092] That is, in this embodiment, it is only necessary to realize that the display on the portal screen becomes more luxurious or decorated as sound data is acquired (that is, the user is prompted to acquire sound data).

[0093] As described above, acquired sound data can be set as quest background music, but the acquired sound data may be played randomly while the portal screen is displayed, or may be played in the order in which they were acquired. Furthermore, the acquired sound data played while the portal screen is displayed may be, for example, the most recently acquired sound data.

[0094] Furthermore, if a character displayed on the portal screen is associated with a musical instrument as described above, sound data may be reproduced in a tone based on that musical instrument. Specifically, if a violin is associated with a character displayed on the portal screen (i.e., the character is holding a violin), sound data may be reproduced in a violin tone. The same applies to other musical instruments.

[0095] Furthermore, when acquired sound data is set as quest background music as described above, an in-game effect corresponding to the acquired sound data may be applied when playing the quest. Specifically, the player character's parameters (attack power, HP, movement speed, etc.) may be improved according to the acquired sound data set as quest background music. Note that the in-game effect corresponding to the acquired sound data may be constantly exerted during play of the quest, or may be temporarily exerted according to the playback position of the acquired sound data (for example, when an exciting chorus melody is played).

[0096] As described above, in this embodiment, the display of characters (objects) on the portal screen changes based on the sound data acquired by the user, thereby increasing the interest of users playing the action RPG game. Furthermore, in this embodiment, as the number of acquired sound data increases, the portal screen appears more lively, which increases the motivation of users to collect sound data (i.e., encourages users to acquire sound data). As a result, this can increase users' interest in the sound data (in-game music) provided in the action RPG game.

[0097] As described above, the portal screen in this embodiment is described as a screen that serves as a starting point for transitioning to multiple other screens for using various functions provided in the action RPG game, but this portal screen is different from a dedicated screen (e.g., a soundtrack screen) for accepting at least the selection of background music to be played in the action RPG game. Furthermore, the portal screen in this embodiment may include a screen on which images for using multiple functions other than playing background music are arranged, and may also be a screen for transitioning to a soundtrack screen. In other words, in an action RPG game in which a user can obtain background music (sound data), this embodiment changes the display of objects on a portal screen (i.e., a screen that has relatively little to do with the obtained background music) that does not display a list of the obtained background music, based on the background music obtained by the user, and is therefore thought to be able to contribute to increasing the user's interest, unlike a typical soundtrack screen in which the number of playable background music (objects representing it) simply increases. In addition, in this embodiment, the display of objects on the screen during the game (for example, while playing a quest) may be changed based on the BGM that the user has acquired (collected). Specifically, the number or movement of characters on the stage displayed on the screen during the game may be changed based on the number of BGMs that the user has acquired. Furthermore, the number and difficulty (movement) of enemy characters that appear (spawn) in the quest may be changed based on the number of BGMs that the user has acquired. Furthermore, in this embodiment, it has been described that the user obtains sound data corresponding to in-game music, but the sound data may be any sound data that can be played in an action RPG game, and may be short sounds that are not musical pieces such as background music, sound effects, or lines (voice), etc. Furthermore, in this embodiment, the display of objects on the portal screen is described as being changed based on sound data (BGM) acquired by the user. However, the display of characters on the portal screen may be changed based on points that the user can collect (earn) by clearing or unlocking quests, for example. In this case, the display of characters on the portal screen may be changed automatically and gradually based on the points collected by the user. Furthermore, the display of characters on the portal screen may be changed by the user spending the points collected. Furthermore, points may be used for purposes other than changing the display of characters on the portal screen (e.g., purchasing items or leveling up characters). Note that the points that a user can collect by clearing a quest may be determined based on the content of the quest (e.g., the time required to clear the quest, the number of attacks or amount of damage received from enemy characters until the quest is cleared, etc.).

[0098] Furthermore, although this embodiment is based on the assumption that the user plays the game online, this embodiment may also be applied to the case where the user plays the game offline.

[0099] Although the present embodiment has been described with respect to a game program for allowing a user to play an action RPG game, the present embodiment may also be applied to game programs for playing other games. Furthermore, the present embodiment may also be applied to application programs that provide other services (such as health management applications or learning management applications) as long as sound data can be obtained by satisfying certain conditions.

[0100] The present invention is not limited to the above-described embodiments, and the components can be modified and embodied in practice without departing from the spirit and scope of the present invention. Furthermore, various inventions can be created by appropriately combining multiple components disclosed in the above-described embodiments. For example, some components may be omitted from all the components shown in the embodiments. Furthermore, components from different embodiments may be appropriately combined. "Addendum" Some of the features of the present invention are summarized below. "assignment" For example, the purpose is to increase the interest of the user. "Solution" (1) Computer, A control means for changing the display of an object on the portal screen based on the sound data obtained by the user. A program that functions as a (2) The program according to (1), wherein the portal screen is a screen that serves as a starting point for transitioning to a plurality of other screens. (3) The program according to (1), wherein the object includes a character. (4) The program according to any one of (1) to (3), wherein the control means changes the number of objects displayed on the portal screen based on the number of sound data obtained by the user. (5) The program described in any one of (1) to (3), wherein the control means changes the behavior of the object displayed on the portal screen based on the number of sound data obtained by the user. (6) The program according to any one of (1) to (3), wherein the control means adds an object associated with the sound data obtained by the user to the portal screen. (7) The program according to (1), wherein the control means displays details of sound data associated with the object when the object displayed on the portal screen is specified by the user. The solution constituted by the above program may be appropriately applied to the fields of devices, systems, methods, and media. "effect" The configurations (1) to (3) have the effect of increasing the interest of users who use the portal screen, for example. According to the configuration (4), for example, by changing the number of objects based on the number of sound data obtained by the user, it is possible to increase the interest of the user. According to the configuration (5), for example, the action of the object can be changed based on the number of pieces of sound data that the user has acquired, thereby increasing the interest of the user. According to the configuration (6), for example, an object associated with sound data obtained by the user can be added to the portal screen, thereby increasing the user's interest. According to the configuration (7), for example, the details of the sound data can be easily confirmed from the portal screen, which has the effect of increasing the user's interest in the sound data. [Explanation of symbols]

[0101] 1...game system, 10...user terminal, 11...non-volatile memory, 12...CPU, 13...main memory, 13A...game program, 14...wireless communication device, 15...display, 16...touch panel, 20...server device, 21...non-volatile memory, 22...CPU, 23...main memory, 23A...game program, 24...wireless communication device, 30...network, 101...operation reception unit, 102...control unit, 103...display processing unit, 104...storage unit, 201...storage unit, 202...data management unit, 203...control unit.

Claims

1. Computer, A control means for changing the display of an object on the portal screen based on the sound data obtained by the user. A program that functions as a

2. The program according to claim 1 , wherein the portal screen is a screen that serves as a starting point for transitioning to a plurality of other screens.

3. The program of claim 1 , wherein the object includes a character.

4. 4. The program according to claim 1, wherein the control means changes the number of the objects displayed on the portal screen based on the number of the sound data obtained by the user.

5. 4. The program according to claim 1, wherein the control means changes the behavior of the object displayed on the portal screen based on the number of pieces of sound data obtained by the user.

6. 4. The program according to claim 1, wherein the control means adds an object associated with the sound data obtained by the user to the portal screen.

7. 2. The program according to claim 1, wherein said control means displays details of sound data associated with an object when said object displayed on said portal screen is designated by a user.

8. A system comprising a control means for changing the display of an object on a portal screen based on sound data obtained by a user.

Images