WO2010037341A1 - 网络游戏资源分配的方法及设备 - Google Patents

网络游戏资源分配的方法及设备 Download PDF

Info

Publication number
WO2010037341A1
WO2010037341A1 PCT/CN2009/074195 CN2009074195W WO2010037341A1 WO 2010037341 A1 WO2010037341 A1 WO 2010037341A1 CN 2009074195 W CN2009074195 W CN 2009074195W WO 2010037341 A1 WO2010037341 A1 WO 2010037341A1
Authority
WO
WIPO (PCT)
Prior art keywords
game
request
client
configuration
resource allocation
Prior art date
Application number
PCT/CN2009/074195
Other languages
English (en)
French (fr)
Inventor
赵亮
Original Assignee
腾讯科技(深圳)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技(深圳)有限公司 filed Critical 腾讯科技(深圳)有限公司
Publication of WO2010037341A1 publication Critical patent/WO2010037341A1/zh

Links

Classifications

    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35Details of game servers
    • A63F13/358Adapting the game course according to the network or server load, e.g. for reducing latency due to different connection speeds between clients
    • A63F13/12
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/534Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing for network load management, e.g. bandwidth optimization, latency reduction

Definitions

  • the present invention relates to the field of network communications, and in particular, to a method and device for allocating network game resources. Background of the invention
  • the blackjack game on the network is similar to the traditional blackjack game rules, and the player is determined by the way the players take turns sitting. For example, there are currently 6 players in the order, as: A, B, C, D, E, F.
  • the server side randomly selects a player as the dealer, if you choose C.
  • the server side rotates the dealers in order: the dealer in the second game is D, the dealer in the third game is E, and the dealer in the fourth game is F, and so on.
  • One of the objectives of the present invention is to provide a method and apparatus for network game resource allocation, which enables a client to participate in game resource allocation.
  • the invention provides a method for network game resource allocation, comprising the steps of:
  • A receiving a resource allocation request sent from a game client
  • the invention also provides a device for allocating network game resources, comprising:
  • a receiving module receiving a resource allocation request sent by a game client
  • the allocation module allocates corresponding resources to the game client when the resource allocation request is currently required to be promised.
  • the method and device for allocating network game resources enable the client to actively participate in the distribution of game resources by increasing the interaction between the client and the server, thereby improving the interest of the game, and avoiding the fact that the client does not participate in the game resources in the prior art. Defects caused by the distribution. BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a schematic flowchart of a method for allocating network game resources according to a first embodiment of the present invention
  • FIG. 2 is a schematic flowchart of a method for allocating network game resources according to a second embodiment of the present invention
  • FIG. 3 is a schematic diagram of network game resource allocation according to a third embodiment of the present invention
  • FIG. 4 is a schematic structural diagram of a device for network game resource allocation according to a fourth embodiment of the present invention
  • FIG. 5 is a schematic structural diagram of a configuration module for network game resource allocation according to a fourth embodiment of the present invention
  • Figure 6 is a block diagram showing the structure of an allocation module for network game resource allocation according to a fourth embodiment of the present invention. Mode for carrying out the invention
  • the invention provides a method and a device for allocating network game resources. By improving the interaction between the server and the client of the game, the client of the game can obtain richer game resources and increase the interaction and interest of the game.
  • a method for allocating network game resources including the steps of:
  • the online game usually includes a game server side and a game client.
  • the user first applies for the game account to the game server through the game client; then, the game account is used to log in from the game client to the game server to play the game, so that the steps can be seen.
  • the operations in S10 and S11 can be performed by the game server side.
  • step S10 and step S11 in the embodiment of the present invention may also be performed by a third-party device for controlling a game, which is not specifically limited herein.
  • the following is an example of the execution of the game server.
  • the game server receives the resource allocation request for starting the game sent by the game client.
  • the resource allocation request includes specific request information, and also includes related data information of the client, such as account information of the user.
  • the account information includes an account name and an account level.
  • the server side of the game determines whether the resource allocation request needs to be promised according to the request content of the resource allocation request, and if yes, the game server end allows the request; then allocates the corresponding resource according to the requested content. Describe the client, and feed back the requested information to the client; otherwise, refuse to allocate resources to the client, and feed back the requested information to the client.
  • the client sends different resource allocation requests to communicate with the server, so that the client actively participates in the allocation of game resources and enhances the fun of the game.
  • a second embodiment of the present invention is based on a first embodiment, and a method for allocating network game resources, by configuring a server end and a client end of the game, may increase interaction between the client and the server, including step: 520, performing game initialization configuration;
  • the performing the game initial configuration includes: performing game type configuration, performing game area configuration, and/or performing dynamic file library configuration.
  • the game type configuration is configured separately for different games on the game server side, and different types of games are distinguished; for example, chess and blackjack belong to different types of games, and different configurations are needed to distinguish The client chooses one of Chess and Parker in one game and there is no confusion.
  • the playing area configuration is specifically an identifier of a different game rule configured for the same game, including performing an area name configuration and a configuration field corresponding to the area name (the field may be filled with the identifier of the game rule corresponding to the area name), and the like.
  • the identification of the game rules can be in various forms, taking the blackjack game as an example, the game rule is identified as a fixed identity, The logo of taking the seat, the logo of the winner, the logo of the winner in succession, the logo of the dealer according to the position of the table, etc. Since a game has many different rules of the game, it is necessary to distinguish the configuration so that different games are played. Different areas are carried out. In this way, the gameplay will be enriched, so that the game client can obtain richer game resources from the game server.
  • the fixed sitting is to designate the dealer in the game as a certain game player, and in this embodiment, the game player who fixes a certain game seat is the dealer;
  • the taking of the sitting is a commonly used rule, and the game maker is designated in turn according to the order of the game seat;
  • the actual shooting is to send a sitting request to the game server through the game client, and the game server specifies the game maker according to the sitting request, as described below.
  • the dynamic file configuration is a configuration of a specific rule for a certain type of game that executes a certain rule, that is, a content of a game rule identifier corresponding to a game type; for example, a fixed sitting game in blackjack needs to be configured with a specific Dynamic files (SO files), when you play a fixed game, you need to call the dynamic file.
  • SO files Dynamic files
  • the performing the dynamic file library configuration includes performing the confirmation of the configuration of the dealership document, etc., wherein the confirming the configuration of the dealership document may specifically include: setting the dealer information for the dealer seat or setting the auction information for the client to shoot the dealer.
  • the confirmation of the configuration of the dealer document is determined according to the rules of the game, and is determined for determining the dealer in the game.
  • the owner of the preset game seat is designated as the dealer, specifically: By setting the seat value of the game seat, the seat value of the dealer seat is set to be greater than 0. The seat value of other game seats is set to 0, which is convenient for the server to identify the dealer's seat and send the corresponding game resources.
  • the seat value of the game seat can be added to the seat value by the seat value of the game seat, for example, the seat value is incremented by one, Make the game dealer's seat value greater than 0, which is convenient for the server to identify the dealer's seat and send the corresponding game resources.
  • the game maker is specified according to the request value carried by the request sent from the client, and the seat value of the game seat of the game dealer is designated as a special value, for example, the game maker
  • the seat value is set to be greater than 0, and the seat value of other game seats is set to 0, which is convenient for the server to identify the dealer's seat and send the corresponding game resources.
  • the request value may be the number of coins, indicating that the value is sent.
  • the client requesting the request in order to obtain the number of coins that the game maker can pay; or, the request value may be a multiple of the game win or loss, indicating that the client that sends the request is sent, and the game maker can win or lose the game.
  • the actual shooting may be a time-limited shooting, or a limited number of shootings, or a combination of the two, that is, the client decides whether to send a sitting request within a limited time, and limits the number of times the request is sent.
  • the client initiated by the actual shooting is randomly designated by the server.
  • the winner in the game is confirmed as the dealer, that is, the winner can sit in a row, which is similar to the rules of the dealer's character in the mahjong game, and will not be described here.
  • the server end of the game receives a resource allocation request for starting the game sent by the client.
  • the resource allocation request may be at least one of a game type request, a game area request, a location request, or a sitting request.
  • the game type request is a request for the client to send a certain type of game to the server, and the content of the request includes a game type; for example, the client enters a blackjack game, and needs to send the game identification information including the blackjack game to the server.
  • the game type request after the server side permission, can enter the game and can control the number of players.
  • the game area request is a request by the client to send to a certain area of a certain game to the server side, and the content of the request includes the name of the area of the game; for example, the client enters the fixed sitting game area of the blackjack game, and needs to The server side sends a game area request including the fixed sitting game area identification information, and the server side permission is allowed to enter the game. You can control the number of players.
  • the location request is a request for the client to request to enter a specific location, and the request content includes identification information of the game seat; the server end can ensure that the other client is not allowed to enter when the specific location has been occupied by the client. Or, the game seat in the game, the client is not allowed to enter, that is, only when the specific location is idle.
  • the sitting request is a request sent by the client to obtain the dealer in the game, and the server may limit the time and/or the number of times the client sends the request.
  • the request content includes the request value.
  • the resource allocation request includes the specific request content, and also includes related data information of the client, such as the account information of the user, to confirm the identity of the client.
  • the account information includes an account name and an account level.
  • the server side of the game confirms the resource allocation request according to the request content of the resource allocation request, and determines whether the requested content can be implemented, so that the server-side confirmed balance includes Promise the request and reject the request; if the server can implement the client's request content, then the request is promised; otherwise, the request is rejected.
  • the server determines the promise request or rejects the request according to the number of people who have entered the game type; if the number of people who have entered the game type reaches the preset first threshold, the server rejects the request; The first threshold, then the request is promised.
  • the server determines the promise request or the rejection request according to the number of people who have entered the game area; if the number of people who have entered the game area reaches the preset second threshold, the server rejects the request; The second threshold, then the request is promised.
  • the second threshold is equal to the first threshold, or is not equal.
  • the server determines the promise request or rejects the request according to the requested game seat; if the requested game seat has been occupied by the client or is playing a game, the server will reject the request; otherwise, the request is promised.
  • the server specifies the game maker according to the content of the request; within a limited time and/or a limited number of times, the server sends a request, the server requests the request, and specifies the last client to be the game maker; otherwise , refused the request.
  • the server side of the game performs resource allocation according to the result of the confirmation; if the request is promised, the corresponding resource is allocated to the client according to the requested content, and the information of the promise request is fed back to the client; , refusing to allocate resources to the client, and feeding back the requested information to the client.
  • the server side promises the request, the client is allowed to enter the game and allocate the corresponding game resource; otherwise, the game is rejected and the information of the rejection request is fed back to the client.
  • the server side promises the request, the client is allowed to enter the request area to play the game, and the corresponding game resource is allocated; otherwise, the game is rejected and the information of the rejection request is rejected to the client.
  • the server For the location request, if the server requests the request, the client is allowed to enter the requesting game seat to play the game, and the corresponding game resource is allocated; otherwise, the game is rejected and the requested information is rejected to the client.
  • the client waits for the server to specify the game maker and allocates the corresponding game resource; otherwise, the client fails to shoot the game maker, and the server feeds back the requested information to the client, and Assign the appropriate game resources.
  • the method for allocating network game resources increases the interaction between the client and the server for the configuration of the server and the client of the game, so that the user of the client actively participates in the allocation of the game resources and enhances the interest of the game.
  • a device 20 for network game resource allocation according to a third embodiment of the present invention including:
  • the receiving module 21 receives different resource allocation requests of the game client;
  • the distribution module 22 allocates corresponding resources to the game client when it is currently required to approve the resource allocation request.
  • the receiving module 21 is connected to the client of the game through the network, and receives a resource allocation request for starting the game sent by the client.
  • the resource allocation request includes specific request content, and also includes related data information of the client, such as account information of the user. Among them, the account information includes the account name and the account level.
  • the distribution module 22 is connected to the receiving module 21, and confirms the resource allocation request according to the request content of the resource allocation request, and determines whether the requested content can be implemented, if the server can implement the requested content of the client. And agreeing to the request; allocating corresponding resources to the client according to the requested content, and feeding back the requested information to the client; otherwise, rejecting the allocation of resources to the client, and feeding back the requested information to the client.
  • the device 20 for network game resource allocation in this embodiment receives the different resource allocation requests and exchanges communication, so that the user of the client actively participates in the allocation of the game resources and enhances the interest of the game.
  • the fourth embodiment of the present invention is based on the third embodiment, and the device 20 for network game resource allocation can increase the interaction between the client and the server for the configuration of the server and the client of the game.
  • the device 20 for network game resource allocation includes a receiving module 21 and an allocating module 22, and a configuration module 24, which can perform game initial configuration.
  • the configuration module 24 includes a type configuration unit 241, a region configuration unit 242, and a file configuration unit 243.
  • the type configuration unit 241 performs a game type configuration to distinguish different types of games.
  • the area configuration unit 242, Performing a game area configuration, which is a configuration of an identification of a game rule used in different areas of the same type of game; the file configuration unit 243 performs dynamic file library configuration, and configures a dynamic file for different rule games, including game rules corresponding to the game type.
  • the content of the logo In this way, the allocating unit 22 allocates resources corresponding to the requested content carried by the resource allocation request to the game according to the game initial configuration. Client.
  • the file configuration unit 243 includes a confirmation store configurator 2431 for confirming the configuration of the dealer document.
  • the type configuration unit 241 is configured separately for different games on the server side, and different types of games are distinguished; for example, chess and blackjack belong to different types of games, and different configurations are needed to distinguish, so that the client Choosing one of Chess and Parker in a game is not confusing.
  • the area configuration unit 242 includes an identifier for performing the area name configuration and the game name for which the area name corresponding body is different for the same game configuration, so that the same game can be performed using different rules in different areas; wherein, the game
  • the identification of the rules can be in various forms. Take the blackjack game as an example.
  • the logo of the game rules is the logo of the fixed seat, the logo of the sitting, the logo of the dealer, the logo of the winner, and the table seat. The position determines the dealer's logo, etc. Since a game has a plurality of different game rules for playing the game, it is necessary to distinguish the configurations so that different gameplays are performed in different areas. At the same time, the game's gameplay has become richer, allowing the client to get richer game resources from the server side.
  • the file configuration unit 243 is a configuration of a specific rule for a certain type of game that executes a certain rule; for example, the fixed sitting game in blackjack needs to configure a specific dynamic file (SO file), and when the fixed game is played, , need to call the dynamic file.
  • SO file specific dynamic file
  • the configuration of the confirmation dealer configuration 2431 includes: setting the dealer information for the dealer seat or setting the auction information for the client to shoot the dealer.
  • the configuration of the confirmation dealer arranging 2431 is determined by the game rules, and the dealer in the game can be determined. For example, still In the case of blackjack, for example, in the rules of fixed sitting in the village, taking turns sitting in the village, and taking the seat in the village, it is necessary to confirm the banker configuration file 2431 to configure different determined bookmaker files for the game.
  • the seat value may be set for the game seat by confirming the dealer configurator 2431, the seat value setting of the dealer seat is greater than 0, and the seat value set by the other game seats is 0. It is convenient for the server to identify the dealer's seat and send the corresponding game resources.
  • the seat value of the game seat can be set to zero by confirming the dealer configurator 2431, and then the seat value of the game seat designated as the game maker is added, which is ⁇ , ⁇ ! Take the seat value and perform the force 1 calculation to make the game maker's seat value greater than 0, which is convenient for the server to identify the dealer's seat and send the corresponding game resources.
  • the confirmed dealer configuration 2431 may be configured with a limited time and/or a limited number of times of the auction on the server side; and the configuration is determined by the confirmation dealer configuration 2431 on the client.
  • the requesting value is included in the request, and the server end may specify the game maker according to the request value, and specify the seat value of the game seat of the game bookmaker as a special value by using the confirmation dealer configuration component 2431, for example
  • the game dealer's seat value is set to be greater than 0, and the seat value of other game seats is set to 0, which is convenient for the server to identify the dealer's seat and send the corresponding game resources.
  • the request value may be the number of the game coins, and indicates the number of coins that the game maker can send to obtain the game maker.
  • the request value may be a multiple of the game win or loss, indicating that the game is sent.
  • the client requesting, in order to obtain the game bookmaker can win or lose the game multiple wins, for example, a client wants to get the game bookmaker, first send a request to sit, then the game wins and loses multiples; another client actually Shoot, then send the request to sit, then the game wins and wins multiples is 2 times; another client actually shoots, the game wins and loses multiples will become 4 times, if no one is actually shooting, you can get the game bookmaker, get Server-side game maker Resources.
  • the client initiated by the actual shooting is randomly designated by the server.
  • the receiving module 21 connects to the client of the game through the network, and receives a resource allocation request for starting the game sent by the client.
  • the resource allocation request includes a game type request, a game area request, a location request, and/or a sitting request.
  • the game type request is a request for the client to send a certain type of game to the server, and the content of the request includes a game type; for example, the client enters a blackjack game, and needs to send the game identification information including the blackjack game to the server.
  • the game type request after the server side permission, can enter the game and can control the number of players.
  • the game area request is a request by the client to send to a certain area of a certain game to the server side, and the content of the request includes the name of the area of the game; for example, the client enters the fixed sitting game area of the blackjack game, and needs to
  • the server side sends a game area request including the fixed sitting game area identification information, and the server side permission is allowed to enter the game, and the number of players can be controlled.
  • the location request is a request for the client to request to enter a specific location, and the request content includes identification information of the game seat; the server end can ensure that the other client is not allowed to enter when the specific location has been occupied by the client. Or, the game seat in the game, the client is not allowed to enter.
  • the request for the sitting is a request sent by the client to obtain the dealer in the game, and the server may limit the time and/or the number of times the client sends the request, if the time exceeds the limited time or the number of times, the receiving module 21 will reject the request. Receiving the request for sitting.
  • the request content of the sitting request includes a request value.
  • the resource allocation request includes the specific request content, and also includes related data information of the client, such as the account information of the user, to confirm the identity of the client.
  • the account information includes an account name and an account level.
  • the distribution module 22 can be implemented in various structural realization manners, as shown in FIG. 6, Figure 6 is a structure of the embodiment of the present invention.
  • the allocation module includes: an acknowledgment unit 61, which determines a request content carried by the resource allocation request;
  • the determining unit 62 determines, according to the determined request content, whether the resource allocation request is currently required to be agreed;
  • the allocating unit 63 when the determination result of the determining unit 62 is YES, allocates a corresponding resource to the game client; when the judgment result of the determining unit 62 is negative, rejects the resource allocation request, and feeds back the information of the rejection request to The game client.
  • the determining unit 62 determines whether the request content can be implemented according to the content of the request of the resource allocation request. If the server side can implement the request content of the client, the current request needs to be promised; otherwise, the request is rejected.
  • the determining unit 62 determines the promise request or the rejection request according to the number of people who have entered the game type; if the number of people who have entered the game type reaches the preset first threshold, the server rejects the request. If the number of people does not reach the first threshold, the request is promised.
  • the determining unit 62 determines the promise request or the rejection request according to the number of people who have entered the game area; if the number of people who have entered the game area reaches the preset second threshold, the server rejects the request; If the number does not reach the second threshold, the request is promised.
  • the second threshold is equal to the first threshold, or is not equal.
  • the determining unit 62 determines a promise request or a rejection request according to the requested situation of the game seat; if the requested game seat has been occupied by the client or is playing a game, the determining unit 62 will reject Request; otherwise promised.
  • the determining unit 62 specifies the game book maker according to the requested content; within a limited time and/or a limited number of times, the client sends a request for sitting, the determining unit 62 will agree to the request, and specify the last shot by the server.
  • the client is the game bookmaker; otherwise, the request is rejected.
  • the allocating unit 63 performs resource allocation according to the determination result; if the determining unit 62 agrees to the request, the corresponding resource is allocated to the client according to the requested content, and the information of the promise request is fed back to the client; otherwise, the resource is refused to be allocated.
  • the client feeds back the requested information to the client.
  • the client is allowed to enter the game, and the allocating unit 63 allocates the corresponding game resource to the client according to the requested content, and feeds back the requested information to the client; otherwise, rejects the client.
  • the end enters the game and feeds back the requested information to the client.
  • the client For the game area request, if the determining unit 62 agrees to the request, the client is allowed to enter the request area to play the game, and the allocating unit 63 allocates the corresponding game resource to the client, and feeds back the information of the promise request to the client; otherwise, The client is denied access to the game and feedback is rejected to the client.
  • the client For the location request, if the determining unit 62 agrees to the request, the client is allowed to enter the requesting game seat to play the game, and the allocating unit 63 allocates the corresponding game resource to the client, and feeds back the requested information to the client; otherwise, rejects the client. The end enters the game and feeds back the requested information to the client.
  • the client waits for the server to specify the game maker, and the allocating unit 63 allocates the corresponding game resource to the client, and feeds back the requested information to the client; otherwise, the client actually The game maker failed, and the server side feedback rejected the requested information to the client.
  • the device 20 for network game resource allocation in this embodiment increases the interaction between the client and the server for the configuration of the server and the client of the game, so that the user of the client actively participates in the distribution of the game resources and enhances the interest of the game.
  • the configuration device of the network game resource allocation in the embodiment can increase the interaction between the client and the server, and enhance the interest of the game. Flavor.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

Description

网络游戏资源分配的方法及设备 技术领域
本发明涉及到网络通信领域, 特别涉及到一种网络游戏资源分配的 方法及设备。 发明背景
现在网络中的二十一点游戏, 与传统的二十一点游戏规则相似, 采 用玩家轮流坐庄的方式确定庄家。 比如, 支设当前有 6个玩家, 作为顺 序分别为: A、 B、 C、 D、 E、 F, 在游戏开始的第一局, 游戏的服务器 端随机选择一个玩家作为庄家, 假如选 C, 则之后从第二局开始, 服务 器端依次按顺序轮换庄家: 第二局的庄家为 D, 第三局庄家为 E, 第四局 庄家为 F等, 如此不断循环。
可以看出, 现有的玩家轮流坐庄的方式中, 庄家资源都是由服务器 端按照固定不变的、 且与客户端信息无关的原则分配的, 客户端没有任 何参与, 只是被动接受, 如此, 就会导致游戏的客户端与服务器端缺少 交互、 庄家确定的方法比较单一等问题。 因此, 一种使客户端参与游戏 资源分配的方法是当前亟待解决的技术问题。 发明内容
本发明的目的之一为提供一种网络游戏资源分配的方法及设备, 实 现客户端参与游戏资源分配。
本发明提供一种网络游戏资源分配的方法, 包括步骤:
A, 接收来自游戏客户端发送的资源分配请求;
B , 如果当前需要答应所述资源分配请求, 则分配相应资源给所述 游戏客户端。 本发明还提供一种网络游戏资源分配的设备, 包括:
接收模块, 接收游戏客户端发送的资源分配请求;
分配模块, 在当前需要答应所述资源分配请求时, 分配相应资源给 所述游戏客户端。
本发明所述网络游戏资源分配的方法及设备, 通过增加客户端与服 务器端的交互,使客户端主动参与游戏资源的分配,提升游戏的趣味性, 避免现有技术中由于客户端不参与游戏资源的分配所带来的缺陷。 附图简要说明
图 1 是本发明第一实施例网络游戏资源分配的方法流程示意图; 图 2 是本发明第二实施例网络游戏资源分配的方法流程示意图; 图 3 是本发明第三实施例网络游戏资源分配的设备结构示意图; 图 4 是本发明第四实施例网络游戏资源分配的设备结构示意图; 图 5 是本发明第四实施例网络游戏资源分配的配置模块结构示意 图;
图 6 是本发明第四实施例网络游戏资源分配的分配模块结构示意 图。 实施本发明的方式
本发明提供一种网络游戏资源分配的方法及设备, 通过改善游戏的 服务器端与客户端的交互, 使得游戏的客户端可以获得更丰富的游戏资 源, 增加游戏的互动性和趣味性。
参照图 1 , 提出本发明第一实施例的一种网络游戏资源分配的方法, 包括步驟:
S10, 接收来自游戏客户端发送的资源分配请求; Sll , 如果当前需要答应所述资源分配请求, 则分配相应的资源给 游戏客户端。
网络游戏中通常包括游戏服务器端和游戏客户端, 用户首先通过游 戏客户端向游戏服务器端申请游戏账号; 然后, 通过游戏账号从游戏客 户端登陆至游戏服务器端进行游戏, 如此, 可以看出步骤 S10和步骤 S11 中的操作可由游戏服务器端执行。 当然, 本发明实施例中步骤 S10和步 骤 S 11也可由用于控制游戏的第三方设备执行, 这里不进行具体限定。 为便于描述, 下述都以游戏服务端执行为例。
如步骤 S10所述, 在通过游戏账号登陆后, 所述游戏服务器端接收 游戏客户端发送的启动游戏的资源分配请求。 所述资源分配请求包含具 体请求内容外,还包含客户端的相关数据信息, 比如用户的账号信息等。 其中, 账号信息包括账号名称和账号等级等。
如步骤 S11所述, 所述游戏的服务器端, 根据所述资源分配请求的 请求内容, 判断当前是否需要答应资源分配请求, 如果是, 游戏服务器 端答应请求; 则根据请求内容分配相应资源给所述客户端, 并将答应请 求的信息反馈至客户端; 反之, 拒绝分配资源给所述客户端, 并将拒绝 请求的信息反馈至客户端。
本实施例所述网絡游戏资源分配的方法, 通过客户端发送不同的资 源分配请求,与服务器端交互通讯,使客户端主动参与游戏资源的分配, 提升游戏的趣味性。
上述对本发明实施例提供的方法进行了基本描述, 下面结合具体实 施例对本发明实施例提供的方法进行详细描述。
参照图 2, 本发明第二实施例基于第一实施例而提出, 一种网络游 戏资源分配的方法, 通过对游戏的服务器端及客户端的配置, 可以增加 客户端与服务器端的交互通讯, 其包括步骤: 520, 进行游戏初始化配置;
521 , 接收游戏客户端发送的资源分配请求; 这里, 不同的游戏客 户端可能发送不同的资源分配请求, 因此, 本步驟 S10中可能会接收到 多个不同的资源分配请求。
522, ^^据资源分配请求的请求内容, 对所述资源分配请求进行确 认;
523 , 根据确认结果分配相应的资源, 并反馈回客户端。
如步骤 S20所述, 所述进行游戏初始化配置包括: 进行游戏类型配 置、 进行游戏区域配置和 /或进行动态文件库配置等。
其中, 所述进行游戏类型配置是在游戏服务器端为不同的游戏分别 配置, 将不同类型的游戏进行区分; 比如, 象棋和二十一点属于不同类 型的游戏, 需要进行不同配置以区分, 使客户端在一次游戏中选择象棋 和朴克牌的其中之一进行, 不会产生混淆。
所述进行游戏区域配置具体是为同一种游戏配置不同的游戏规则 的标识, 包括进行区域名称配置和进行区域名称对应的配置字段(该字 段可填入与区域名称对应的游戏规则的标识)等, 以使同一种游戏可以 在不同的区域使用不同的规则进行; 其中, 游戏规则的标识具体可有多 种形式, 以二十一点游戏为例, 则游戏规则的标识为固定坐庄的标识、 轮流坐庄的标识、 竟拍坐庄的标识、 贏家连续坐庄的标识、 按照桌子座 位位置确定庄家的标识等, 由于一种游戏具有多种不同的游戏规则进行 游戏, 需要区分配置, 使不同的玩法在不同的区域进行。 如此, 就会使 得游戏的玩法也随之变得更丰富, 从而使游戏客户端可以从游戏服务器 端获取更丰富的游戏资源。
其中, 所述固定坐庄是将游戏中的庄家指定为某一游戏玩家, 本实 施例是固定某一游戏座位的游戏玩家为庄家; 所述轮流坐庄是现有常用的一种规则, 依照游戏座位次序轮流指定 游戏庄家;
所述竟拍坐庄是通过游戏客户端向游戏服务器端发送坐庄请求, 由 游戏服务器端根据坐庄请求指定游戏庄家, 具体下述。
所述动态文件配置是对执行某一规则的某一类型游戏的具体规则 的配置, 也即与游戏类型对应的游戏规则标识的内容; 比如, 二十一点 中的固定坐庄玩法需要配置特定的动态文件 (SO文件), 进行固定坐庄 玩法时, 需要调用所述动态文件。
这里, 所述进行动态文件库配置包括进行确认庄家文件的配置等; 其中, 所述确认庄家文件的配置具体可包括: 为庄家座位设置庄家信息 或者为客户端竟拍庄家设置竟拍信息等。 本实施例, 所述确认庄家文件 的配置是根据游戏规则而定, 为确定游戏中的庄家而设。
仍以二十一点为例, 如果游戏规则标识为固定坐庄的标识, 则指定 预设的游戏座位的主人为庄家,具体为: 通过将游戏座位设置座位数值, 庄家座位的座位数值设置大于 0, 其他游戏座位设置的座位数值为 0, 方 便服务器端辨识庄家座位, 发送相应游戏资源。
如果游戏规则标识为轮流坐庄的标识, 则可以通过将游戏座位的座 位数值设置为零, 再是将指定为游戏庄家的游戏座位的座位数值进行加 运算, 比如, 将座位数值进行加 1运算, 使游戏庄家的座位数值大于 0, 方便服务器端辨识庄家座位, 发送相应游戏资源。
如果游戏规则标识为竟拍坐庄的标识 , 则根据来自客户端发送的坐 庄请求携带的请求数值指定游戏庄家, 并将所述游戏庄家所坐游戏座位 的座位数值指定为特殊数值, 比如, 游戏庄家的座位数值设置为大于 0, 其他游戏座位的座位数值设置为 0 , 方便服务器端辨识庄家座位, 发送 相应游戏资源。 这里, 所述请求数值, 可以是游戏币的数量, 表示发送 坐庄请求的客户端, 为取得游戏庄家可以付出的游戏币数量; 或者, 所 述请求数值可以是游戏输贏的倍数, 表示发送坐庄请求的客户端, 为取 得游戏庄家可以将游戏输赢增大的倍数, 比如, 一客户端想取得游戏庄 家, 首先发送坐庄请求, 此时游戏输贏的倍数是 1倍; 另一客户端竟拍, 再发送坐庄请求, 此时游戏输贏的倍数是 2倍; 再一客户端竟拍, 游戏 的输赢倍数将变为 4倍, 如果无人再竟拍, 则可以取得游戏庄家, 获取 服务器端发送的游戏庄家资源。 所述竟拍可以是限制时间竟拍, 也可以 是限制次数竟拍, 还可以是二者结合, 即客户端在限定时间内决定是否 发送坐庄请求, 并限定发送请求的次数。 所述竟拍发起的客户端是服务 器端随机指定。
如果游戏规则标识为赢家连续坐庄的标识, 则将游戏中的贏家确认 为庄家, 即贏家可以连续坐庄, 这种方式类似于麻将类游戏中庄家角色 的规则, 这里不再赘述。
如步骤 S21所述, 在通过游戏账号登陆后, 所述游戏的服务器端接 收客户端发送的启动游戏的资源分配请求。 这里, 所述资源分配请求可 为为游戏类型请求、 游戏区域请求、 位置请求或坐庄请求等中的至少一 个。
所述游戏类型请求是客户端向服务器端发送进入某一类型游戏的 请求, 请求内容包括游戏类型; 比如, 客户端进入二十一点游戏, 需要 向服务器端发送包括二十一点游戏辨识信息的游戏类型请求, 经过服务 器端许可, 方可进入游戏, 可以控制游戏人数。
所述游戏区域请求是客户端向服务器端发送进入某一游戏的某一 特定区域的请求, 请求内容包括游戏的区域名称; 比如, 客户端进入二 十一点游戏的固定坐庄玩法区域, 需要向服务器端发送包括固定坐庄玩 法区域辨识信息的游戏区域请求, 经过服务器端许可, 方可进入游戏, 可以控制游戏人数。
所述位置请求是客户端请求进入某一具体位置的请求, 请求内容包 括对游戏座位的辨识信息; 服务器端可以确保在某一具体位置已经被客 户端占用的情况下, 另一客户端不得进入; 或者, 正在进行游戏的游戏 座位, 客户端不得进入, 即, 只有在该具体位置空闲时才可进入。
所述坐庄请求是竟拍坐庄玩法中客户端为取得庄家而发送的请求, 服务器端可以限制客户端发送坐庄请求的时间和 /或次数。请求内容中包 括请求数值。
所述资源分配请求包含具体请求内容外, 还包含客户端的相关数据 信息, 比如用户的账号信息等, 确认客户端的身份。 其中, 账号信息包 括账号名称和账号等级等。
如步骤 S22所述, 所述游戏的服务器端, 根据所述资源分配请求的 请求内容,对所述资源分配请求进行确认,判断所述请求内容可否实现, 使得所述服务器端确认的结杲包括答应请求和拒绝请求; 如果服务器端 可以实现客户端的请求内容, 则答应请求; 否则, 拒绝请求。
针对所述游戏类型请求, 服务器端根据已经进入游戏类型的人数, 判断答应请求或拒绝请求; 如果已进入所述游戏类型的人数达到预设的 第一阈值, 服务器端拒绝请求; 如果人数未达第一阈值, 则答应请求。
针对所述游戏区域请求, 服务器端根据已经进入游戏区域的人数, 判断答应请求或拒绝请求; 如果已进入所述游戏区域的人数达到预设的 第二阈值, 服务器端拒绝请求; 如果人数未达第二阈值, 则答应请求。 这里, 所述第二阈值与所述第一阈值相等, 或者不等。
针对所述位置请求, 服务器端根据请求的游戏座位的情况, 判断答 应请求或拒绝请求; 如果所述请求的游戏座位已经被客户端占用或者正 在进行游戏, 服务器端将拒绝请求; 否则答应请求。 针对所述坐庄请求, 服务器端根据请求内容指定游戏庄家; 在限定 时间和 /或限定次数内, 客户端发送的坐庄请求, 服务器端答应请求, 并 指定最后竟拍的客户端为游戏庄家; 否则, 拒绝请求。
如步骤 S23所述, 所述游戏的服务器端, 根据确认的结果进行资源 分配; 如果答应请求, 则根据请求内容分配相应资源给所述客户端, 并 将答应请求的信息反馈至客户端; 反之, 拒绝分配资源给所述客户端, 并将拒绝请求的信息反馈至客户端。
针对所述游戏类型请求, 如果服务器端答应请求, 则允许客户端进 入游戏, 并分配相应游戏资源; 否则, 拒绝进入游戏并反馈拒绝请求的 信息至客户端。
针对所述游戏区域请求, 如果服务器端答应请求, 则允许客户端进 入请求区域进行游戏, 并分配相应游戏资源; 否则, 拒绝进入游戏并反 馈拒绝请求的信息至客户端。
针对所述位置请求, 如杲服务器端答应请求, 则允许客户端进入请 求游戏座位进行游戏, 并分配相应游戏资源; 否则, 拒绝进入游戏并反 馈拒绝请求的信息至客户端。
针对所述坐庄请求, 如果服务器端答应请求, 则客户端等待服务器 端指定游戏庄家, 并分配相应游戏资源; 否则, 客户端竟拍游戏庄家失 败, 服务器端反馈拒绝请求的信息至客户端, 并分配相应游戏资源。
本实施例所述网络游戏资源分配的方法, 对游戏的服务器端及客户 端的配置, 增加客户端与服务器端的交互通讯, 使客户端的用户主动参 与游戏资源的分配, 提升游戏的趣味性。
参照图 3 , 提出本发明第三实施例的一种网络游戏资源分配的设备 20, 包括:
接收模块 21 , 接收游戏客户端不同的资源分配请求; 分配模块 22, 在当前需要答应所述资源分配请求时, 分配相应资源 给所述游戏客户端。
所述接收模块 21 , 通过网络与游戏的客户端连接, 接收客户端发送 的启动游戏的资源分配请求。 所述资源分配请求包含具体请求内容外, 还包含客户端的相关数据信息, 比如用户的账号信息等。 其中, 账号信 息包括账号名称和账号等级等。
所述分配模块 22, 与所述接收模块 21连接, 根据所述资源分配请求 的请求内容, 对所述资源分配请求进行确认, 判断所述请求内容可否实 现, 如果服务器端可以实现客户端的请求内容, 则答应请求; 根据请求 内容分配相应资源给所述客户端, 并将答应请求的信息反馈至客户端; 反之,拒绝分配资源给所述客户端,并将拒绝请求的信息反馈至客户端。
本实施例所述网络游戏资源分配的设备 20, 接收客户端发送不同的 资源分配请求,并交互通讯,使客户端的用户主动参与游戏资源的分配, 提升游戏的趣味性。
参照图 4, 本发明第四实施例基于第三实施例而提出, 一种网络游 戏资源分配的设备 20, 对游戏的服务器端及客户端的配置, 可以增加客 户端与服务器端的交互通讯, 所述网络游戏资源分配的设备 20包括接收 模块 21和分配模块 22, 还包括配置模块 24, 可以进行游戏初始化配置。
参照图 5,所述配置模块 24包括类型配置单元 241、 区域配置单元 242 和文件配置单元 243; 所述类型配置单元 241 , 进行游戏类型配置, 区分 不同类型的游戏; 所述区域配置单元 242 , 进行游戏区域配置, 为同一 类型游戏在不同区域所使用游戏规则的标识的配置; 所述文件配置单元 243 , 进行动态文件库配置, 为不同规则游戏配置动态文件, 包括与游 戏类型对应的游戏规则标识的内容。 如此 , 分配单元 22根据所述游戏初 始化配置分配与所述资源分配请求携带的请求内容对应的资源给游戏 客户端。
优选地, 所述文件配置单元 243包括确认庄家配置件 2431 , 进行确 认庄家文件的配置。
本实施例, 所述类型配置单元 241是为服务器端不同的游戏分别配 置, 将不同类型游戏区分进行; 比如, 象棋和二十一点属于不同类型游 戏, 需要进行不同配置以区分, 使客户端在一次游戏中选择象棋和朴克 牌的其中之一进行, 不会产生混淆。
所述区域配置单元 242包括进行区域名称配置和进行区域名称对应 体是为是为同一种游戏配置不同的游戏规则的标识, 使同一种游戏可以 在不同的区域使用不同的规则进行; 其中, 游戏规则的标识具体可有多 种形式, 以二十一点游戏为例, 则游戏规则的标识为固定坐庄的标识、 轮流坐庄的标识、 竟拍庄家的标识、 赢家连续坐庄的标识、 按照桌子座 位位置确定庄家的标识等, 由于一种游戏具有多种不同的游戏规则进行 游戏, 需要区分配置, 使不同的玩法在不同的区域进行。 同时, 游戏的 玩法也随之变得更丰富, 使客户端可以从服务器端获取更丰富的游戏资 源。 其中, 固定坐庄、 轮流坐庄、 竟拍坐庄、 贏家连续坐庄、 按照桌子 座位位置确定庄家等的具体描述可参见图 2所示的步骤 S100中的文字描 述。
所述文件配置单元 243是对执行某一规则的某一类型游戏的具体规 则的配置; 比如, 二十一点中的固定坐庄玩法需要配置特定的动态文件 ( SO文件), 进行固定坐庄玩法时, 需要调用所述动态文件。
所述确认庄家配置件 2431的配置包括: 为庄家座位设置庄家信息或 者为客户端竟拍庄家设置竟拍信息等。 本实施例, 所述确认庄家配置件 2431的配置是 #居游戏规则而定, 可以确定游戏中的庄家。 比如, 仍以 二十一点为例,二十一点中的固定坐庄、轮流坐庄和竟拍坐庄等规则中, 需要通过确认庄家配置件 2431分别配置不同的确定庄家文件进行游戏。
如果游戏规则标识为固定坐庄的标识, 在所述固定坐庄玩法中, 可 以通过确认庄家配置件 2431为游戏座位设置座位数值, 庄家座位的座位 数值设置大于 0, 其他游戏座位设置的座位数值为 0, 方便服务器端辨识 庄家座位, 发送相应游戏资源。
如果游戏规则标识为轮流坐庄的标识, 可以通过确认庄家配置件 2431 , 将游戏座位的座位数值设置为零, 再是将指定为游戏庄家的游戏 座位的座位数值进行加运算, 比 ^口, ^!夺座位数值进行力口 1运算, 使游戏 庄家的座位数值大于 0, 方便服务器端辨识庄家座位, 发送相应游戏资 源。
如果游戏规则标识为竟拍坐庄的标识, 可以通过所述确认庄家配置 件 2431在服务器端配置竟拍的限定时间和 /或限定次数等;并通过所述确 认庄家配置件 2431在客户端配置坐庄请求, 且坐庄请求中包含请求数 值; 所述服务器端可以根据所述请求数值指定游戏庄家, 并通过所述确 认庄家配置件 2431 , 将游戏庄家所坐游戏座位的座位数值指定为特殊数 值, 比如, 游戏庄家的座位数值设置为大于 0 , 其他游戏座位的座位数 值设置为 0, 方便服务器端辨识庄家座位, 发送相应游戏资源。 其中, 所述请求数值, 可以是游戏币的数量, 表示发送坐庄请求的客户端, 为 取得游戏庄家可以付出的游戏币数量; 或者, 所述请求数值可以是游戏 输贏的倍数, 表示发送坐庄请求的客户端, 为取得游戏庄家可以将游戏 输贏增大的倍数, 比如, 一客户端想取得游戏庄家, 首先发送坐庄请求, 此时游戏输贏的倍数是 1倍; 另一客户端竟拍, 再发送坐庄请求, 此时 游戏输贏的倍数是 2倍; 再一客户端竟拍, 游戏的输贏倍数将变为 4倍, 如果无人再竟拍, 则可以取得游戏庄家, 获取服务器端发送的游戏庄家 资源。 所述竟拍发起的客户端是服务器端随机指定。
如此, 所述接收模块 21, 通过网络与游戏的客户端连接, 接收客户 端发送的启动游戏的资源分配请求。 所述资源分配请求包括游戏类型请 求、 游戏区域请求、 位置请求和 /或坐庄请求等。
所述游戏类型请求是客户端向服务器端发送进入某一类型游戏的 请求, 请求内容包括游戏类型; 比如, 客户端进入二十一点游戏, 需要 向服务器端发送包括二十一点游戏辨识信息的游戏类型请求, 经过服务 器端许可, 方可进入游戏, 可以控制游戏人数。
所述游戏区域请求是客户端向服务器端发送进入某一游戏的某一 特定区域的请求, 请求内容包括游戏的区域名称; 比如, 客户端进入二 十一点游戏的固定坐庄玩法区域, 需要向服务器端发送包括固定坐庄玩 法区域辨识信息的游戏区域请求, 经过服务器端许可, 方可进入游戏, 可以控制游戏人数。
所述位置请求是客户端请求进入某一具体位置的请求, 请求内容包 括对游戏座位的辨识信息; 服务器端可以确保在某一具体位置已经被客 户端占用的情况下, 另一客户端不得进入; 或者, 正在进行游戏的游戏 座位, 客户端不得进入。
所述坐庄请求是竟拍坐庄玩法中客户端为取得庄家而发送的请求, 服务器端可以限制客户端发送坐庄请求的时间和 /或次数,超过限定时间 或限定次数, 所述接收模块 21将拒绝接收所述坐庄请求。 所述坐庄请求 的请求内容中包括请求数值。
所述资源分配请求包含具体请求内容外, 还包含客户端的相关数据 信息, 比如用户的账号信息等, 确认客户端的身份。 其中, 账号信息包 括账号名称和账号等级等。
其中, 分配模块 22具体实现时可有多种结构实现形式, 参见图 6, 图 6为本发明实施例提出的其中一种结构, 如图 6所示, 分配模块包括: 确认单元 61, 确定所述资源分配请求携带的请求内容;
判断单元 62, 根据确定的请求内容判断当前是否需要答应资源分配 请求;
分配单元 63, 在判断单元 62的判断结果为是时, 分配相应资源给所 述游戏客户端; 在判断单元 62的判断结果为否时, 拒绝所述资源分配请 求, 并反馈拒绝请求的信息给所述游戏客户端。
所述判断单元 62, 根据所述资源分配请求的请求内容, 判断所述请 求内容可否实现, 如果服务器端可以实现客户端的请求内容, 则当前需 要答应请求; 否则, 拒绝请求。
针对所述游戏类型请求, 所述判断单元 62才艮据已经进入游戏类型的 人数, 判断答应请求或拒绝请求; 如果已进入所述游戏类型的人数达到 预设的第一阈值, 服务器端拒绝请求; 如果人数未达第一阈值, 则答应 请求。
针对所述游戏区域请求, 所述判断单元 62根据已经进入游戏区域的 人数, 判断答应请求或拒绝请求; 如果已进入所述游戏区域的人数达到 预设的第二阈值, 服务器端拒绝请求; 如果人数未达第二阈值, 则答应 请求。 这里, 所述第二阈值与所述第一阈值相等, 或者不等。
针对所述位置请求, 所述判断单元 62根据请求的游戏座位的情况, 判断答应请求或拒绝请求; 如果所述请求的游戏座位已经被客户端占用 或者正在进行游戏, 所述判断单元 62将拒绝请求; 否则答应请求。
针对所述坐庄请求, 所述判断单元 62根据请求内容指定游戏庄家; 在限定时间和 /或限定次数内, 客户端发送的坐庄请求, 所述判断单元 62 将答应请求, 通过服务器指定最后竟拍的客户端为游戏庄家; 否则, 拒 绝请求。 所述分配单元 63 , 根据判断结果进行资源分配; 如果判断单元 62答 应请求, 则根据请求内容分配相应资源给所述客户端, 并将答应请求的 信息反馈至客户端; 反之, 拒绝分配资源给所述客户端, 并将拒绝请求 的信息反馈至客户端。
针对所述游戏类型请求, 如果判断单元 62答应请求, 则允许客户端 进入游戏, 分配单元 63根据请求内容分配相应游戏资源给客户端, 同时 将答应请求的信息反馈至客户端; 否则, 拒绝客户端进入游戏并反馈拒 绝请求的信息至客户端。
针对所述游戏区域请求, 如果所述判断单元 62答应请求, 则允许客 户端进入请求区域进行游戏, 分配单元 63分配相应游戏资源给客户端, 同时将答应请求的信息反馈至客户端; 否则, 拒绝客户端进入游戏并反 馈拒绝请求的信息至客户端。
针对所述位置请求, 如果判断单元 62答应请求, 则允许客户端进入 请求游戏座位进行游戏, 分配单元 63分配相应游戏资源给客户端, 同时 将答应请求的信息反馈至客户端; 否则, 拒绝客户端进入游戏并反馈拒 绝请求的信息至客户端。
针对所述坐庄请求, 如果判断单元 62答应请求, 则客户端等待服务 器端指定游戏庄家, 分配单元 63分配相应游戏资源给客户端, 同时将答 应请求的信息反馈至客户端; 否则, 客户端竟拍游戏庄家失败, 服务器 端反馈拒绝请求的信息至客户端。
本实施例所述网络游戏资源分配的设备 20 , 对游戏的服务器端及客 户端的配置, 增加客户端与服务器端的交互通讯, 使客户端的用户主动 参与游戏资源的分配, 提升游戏的趣味性。
本实施例所述网絡游戏资源分配的配置装置, 对游戏的服务器端及 客户端的配置, 可以增加客户端与服务器端的交互通讯, 提升游戏的趣 味性。
以上所述仅为本发明的优选实施例, 并非因此限制本发明的专利范 围, 凡是利用本发明说明书及附图内容所作的等效结构或等效流程变 换, 或直接或间接运用在其他相关的技术领域, 均同理包括在本发明的 专利保护范围内。

Claims

权利要求书
1、 一种网络游戏资源分配的方法, 其特征在于, 包括步骤:
A, 接收来自游戏客户端发送的资源分配请求;
B , 如果当前需要答应所述资源分配请求, 则分配相应资源给所述 游戏客户端。
2、 根据权利要求 1所述的网络游戏资源分配的方法, 所述步骤 B中, 所述当前需要答应资源分配请求包括:
B1 , 确定所述资源分配请求携带的请求内容, 根据确定的请求内容 判断当前是否需要答应资源分配请求, 如果是, 确定当前需要答应资源 分配请求;
所述 B1中的判断结果为否时, 则进一步包括: 拒绝所述资源分配请 求, 并反馈拒绝请求的信息给所述游戏客户端。
3、 根据权利要求 2所述的网络游戏资源分配的方法, 其特征在于, 所述步驟 B1中的判断包括:
如果所述请求内容为请求进入的游戏类型, 则判断已进入所述游戏 类型的人数是否达到预设的第一阈值;
如果所述请求内容为请求进入的游戏区域, 则判断已进入所述游戏 区域的人数是否达到预设的第二阈值, 所述第二阈值与所述第一阈值是 否相等;
如果所述请求内容为请求进入的游戏座位的标识信息, 则判断所述 标识信息对应的座位是否空闲, 所述空闲为所述座位未被其他游戏客户 端占用, 或者所述座位当前没有参与任何一种游戏;
如果所述请求内容为请求取得庄家的相关信息, 判断该相关信息是 否为指定的庄家的相关信息。
4、 根据权利要求 1至 3任一所述的网络游戏资源分配的方法, 其特 征在于, 在步骤 A之前, 进一步包括:
AO , 进行游戏初始化配置, 所述游戏初始化配置包括: 游戏类型配 置、 游戏区域配置和进行动态文件库配置, 所述游戏区域配置为同一类 型游戏在不同区域所使用游戏规则的标识的配置, 所述动态文件库配置 包括与游戏类型对应的游戏规则标识的内容;
所述步骤 B中的分配相应资源给游戏客户端包括:
根据所述游戏初始化配置分配与所述资源分配请求携带的请求内 容对应的资源给游戏客户端。
5、 根据权利要求 4所述的网络游戏资源分配的方法, 其特征在于, 所述游戏区域配置包括: 区域名称配置和与区域名称对应的游戏规则的 标识的配置; 所述游戏规则的标识为: 固定坐庄的标识、 竟拍庄家的标 识、 赢家连续坐庄的标识、 和按照桌子座位位置确定庄家的标识中的至 少 ■个;
所述动态文件库配置包括的与游戏类型对应的游戏规则标识的内 容为确认庄家的配置。
6、 根据权利要求 5所述的网络游戏资源分配的方法, 其特征在于, 所述确认庄家的配置为:
如果游戏规则标识为固定坐庄的标识, 则指定预设的游戏座位的主 人为庄家;
如果游戏规则标识为竟拍庄家的标识 , 则根据来自客户端发送的坐 庄请求携带的请求数值指定游戏庄家, 所述请求数值为游戏币的数量或 者游戏输赢增大的倍数;
如果游戏规则标识为贏家连续坐庄的标识, 则将游戏中的贏家确认 为庄家; 如果游戏规则标识为按照桌子座位位置确定庄家的标识, 则指定坐 在该桌子座位位置的^ L家为庄家。
7、 一种网络游戏资源分配的设备, 其特征在于, 包括:
接收模块, 接收游戏客户端发送的资源分配请求;
分配模块, 在当前需要答应所述资源分配请求时, 分配相应资源给 所述游戏客户端。
8、 根据权利要求 8所述的网络游戏资源分配的设备, 其特征在于, 所述分配模块包括:
确认单元, 确定所述资源分配请求携带的请求内容;
判断单元, 根据确定的请求内容判断当前是否需要答应资源分配请 求;
分配单元, 在所述判断单元的判断结果为是时, 分配相应资源给所 述游戏客户端; 在所述判断单元的判断结果为否时, 拒绝所述资源分配 请求, 并反馈拒绝请求的信息给所述游戏客户端。
9、 根据权利要求 8所述的网络游戏资源分配的设备, 其特征在于, 该设备还包括: 用于进行游戏初始化配置的配置模块, 其中, 所述配置 模块包括:
类型配置单元, 进行游戏类型配置;
区域配置单元, 进行游戏区域配置, 所述游戏区域配置为同一类型 游戏在不同区域所使用游戏规则的标识的配置;
文件配置单元, 进行动态文件库配置, 所述动态文件库配置包括与 游戏类型对应的游戏规则标识的内容;
所述分配单元根据所述游戏初始化配置分配与所述资源分配请求 携带的请求内容对应的资源给游戏客户端。
10、 根据权利要求 9所述的网络游戏资源分配的设备, 其特征在于, 所述文件配置单元包括:
确认庄家配置件, 进行确认庄家文件的配置。
PCT/CN2009/074195 2008-09-25 2009-09-24 网络游戏资源分配的方法及设备 WO2010037341A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNA2008101613816A CN101393584A (zh) 2008-09-25 2008-09-25 网络游戏资源分配的方法、系统及配置装置
CN200810161381.6 2008-09-25

Publications (1)

Publication Number Publication Date
WO2010037341A1 true WO2010037341A1 (zh) 2010-04-08

Family

ID=40493877

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/074195 WO2010037341A1 (zh) 2008-09-25 2009-09-24 网络游戏资源分配的方法及设备

Country Status (2)

Country Link
CN (1) CN101393584A (zh)
WO (1) WO2010037341A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112363839A (zh) * 2020-11-23 2021-02-12 腾讯科技(深圳)有限公司 一种资源请求处理方法、装置及服务器

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101393584A (zh) * 2008-09-25 2009-03-25 腾讯科技(深圳)有限公司 网络游戏资源分配的方法、系统及配置装置
CN102811209A (zh) * 2011-06-03 2012-12-05 南京中兴新软件有限责任公司 联网游戏处理方法、装置及系统
CN107308644B (zh) * 2017-07-12 2018-11-06 腾讯科技(深圳)有限公司 配置信息的获取方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1691597A (zh) * 2004-04-24 2005-11-02 华为技术有限公司 一种用于在通信网络中提供游戏业务的系统和方法
CN1721019A (zh) * 1999-01-28 2006-01-18 世嘉股份有限公司 网络游戏系统、使用该系统的游戏装置终端及存储介质
CN101126991A (zh) * 2006-08-18 2008-02-20 腾讯科技(深圳)有限公司 一种在网络游戏中为用户分配游戏资源的方法及系统
CN101393584A (zh) * 2008-09-25 2009-03-25 腾讯科技(深圳)有限公司 网络游戏资源分配的方法、系统及配置装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1721019A (zh) * 1999-01-28 2006-01-18 世嘉股份有限公司 网络游戏系统、使用该系统的游戏装置终端及存储介质
CN1691597A (zh) * 2004-04-24 2005-11-02 华为技术有限公司 一种用于在通信网络中提供游戏业务的系统和方法
CN101126991A (zh) * 2006-08-18 2008-02-20 腾讯科技(深圳)有限公司 一种在网络游戏中为用户分配游戏资源的方法及系统
CN101393584A (zh) * 2008-09-25 2009-03-25 腾讯科技(深圳)有限公司 网络游戏资源分配的方法、系统及配置装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112363839A (zh) * 2020-11-23 2021-02-12 腾讯科技(深圳)有限公司 一种资源请求处理方法、装置及服务器
CN112363839B (zh) * 2020-11-23 2024-03-15 腾讯科技(深圳)有限公司 一种资源请求处理方法、装置及服务器

Also Published As

Publication number Publication date
CN101393584A (zh) 2009-03-25

Similar Documents

Publication Publication Date Title
US10922918B2 (en) Player-entry assignment and ordering
JP6000377B2 (ja) ゲームリソースを割り振るための方法およびサーバ
JP6336132B2 (ja) 対戦ゲームの運営システムおよび方法
US8382566B2 (en) Network game anti-cheating device, method and system
US20100216534A1 (en) Computerized method and system for reassignment of unengaged players in an on-line gaming system
US11425204B2 (en) Method of system of assigning a seating position in instances of a game
EP1989673A2 (en) Quickly providing good matchups
US20090121438A1 (en) Method for Teams to Play Poker Tournaments
JP2009523541A5 (zh)
WO2011048908A1 (ja) ゲームシステム及びそのコンピュータプログラム
WO2010037341A1 (zh) 网络游戏资源分配的方法及设备
JP2012081154A (ja) ゲーム装置
JP2006149663A (ja) ゲーム装置、ゲームシステム及びゲーム方法
JP2014209970A (ja) ゲームシステム、そのサーバ装置、コンピュータプログラム及びマッチング制御方法
KR101072729B1 (ko) 가변적인 베팅이 적용된 온라인 포커 게임을 제공하는 시스템 및 방법
KR100638496B1 (ko) 온라인 확률 게임 운영 시스템 및 방법
TW202000282A (zh) 使用萬用牌的撲克牌遊戲方法、遊戲伺服裝置及電腦可讀取的記錄媒體
JP2016146930A (ja) ゲームサーバ及びプレイヤーがゲームをプレイするグループの決定方法
KR102234696B1 (ko) 온라인 포커 게임 제공 서버
KR102474540B1 (ko) 블록체인을 이용한 네트워크 게임 플레이 운용 방법 및 이를 이용하는 시스템
KR20130094567A (ko) 특정 장수의 카드로 진행하는 가위바위보 토너먼트 게임
US20140221100A1 (en) Game machine system and method for playing game
CN105771237A (zh) 棋牌游戏的换牌控制方法和装置
US20160379440A1 (en) Method for access control using a mobile device
KR100704539B1 (ko) 시드머니 자동 변경을 이용하는 온라인 게임 제어 방법 및시스템

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09817255

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 16.08.11)

122 Ep: pct application non-entry in european phase

Ref document number: 09817255

Country of ref document: EP

Kind code of ref document: A1