My project is an IO game similar to the gameplay of "Snake", that is, several players can eat food in the game interface, and they can also eat each other. After eating food or each other will become bigger. I started to connect to Matchvs after finishing the front-end development part with cocos creator. In fact, before I contacted Matchvs, I also learned about some foreign products, such as photon, proudNet, but network problems and charges are a real problem, after all, technology and funds are relatively limited for a single developer, everyone. should all understand.
Although Matchvs officially calls the services they provide "one-stop service", in fact, in my opinion, there are mainly two, one is to access their SDK, which can realize networking functions. The second is gameServer. The gameServer command-line tool is used for local debugging of back-end code. The back-end code is submitted to the git repository provided by Matchvs and runs directly on the server it provides us.
In Matchvs, there are some very common functions like registering, logging in, joining rooms, and sending events, which can be basically mastered without taking too much time. Second, for me, the biggest advantage is that there is almost no need to understand server-related knowledge, and you only need to focus on the logic writing of the front-end and back-end to complete the development of a game.
At first, I thought that these APIs can meet most of my needs, but later in the process of using it, I found some room for improvement in its design.
The following is a summary of some of my usage in the process of accessing Matchvs:
Let's talk about the advantages first.
1. The api is concise and covers a wide range.
Regarding data transmission and reception, the sdk's apis include sendEvent, sendEventNotify, and sendEventEx; the gameServer's apis include pushHander and pushEvent. The data interaction of the game only needs to call these interfaces. My project is an IO project, similar to Snake. One player calls sendEvent for food, and the other player binds sendEventNofity, and the data is passed from these two simple apis.
It supports multiple platforms and can also be used with other game engines.
For example: On the windows platform, I use cocos creator+matchvs to develop, and package it into Web Mobile, Web Desktop, Wechat Game, Android, Windows and other platforms according to the following configuration.
// The following is pseudo code, calling sdk without environment
var engine
var response = {}
if (isNative) {
engine = Matchvs.MatchvsEngine.getInstance()
} else if (isWeb) {
var jsMatchvs = require("matchvs.all ")
engine = new jsMatchvs.MatchvsEngine()
response = new jsMatchvs.MatchvsResponse()
} else ...
2, gameServer is more practical.
If the game logic is simple enough to only require the client to run all the logic code, we can skip the gameServer. If the game logic is complex, you can use gameServer to manage all clients at the same time.
gameServer+node(gs), so that people who know js can write back-end code, and the development speed is faster.
For example, in my project, since the homeowner will change, in the client, it is very cumbersome to use the homeowner to determine whether the game is about to start. It is very convenient to let the big housekeeper gs make the judgment. The client does not need to pay too much attention to the change of the homeowner, but only needs to care whether the game is to be started, which reduces the if-else logic of the client.
Matchvs provides the function of disconnection and reconnection.
In some cases where the network is poor (subway, elevator) and has been abnormally disconnected from the server, matchvs will help players connect automatically. The developer can set the number and frequency of connections, but it can only meet some basic scenarios.
For example: If the connection is disconnected and reconnected, the loginResponse will return a roomId parameter, indicating that the connection is disconnected and reconnected. At this time, the client can choose to reconnect or ignore it.
Multi-node server deployment and frame synchronization technology
For example: My project is an IO game. During the process of the player moving, the data of the current position is continuously transmitted. The picture still looks very smooth, and the game delay feels quite good. Developers can complete a game without worrying about data synchronization and without knowing much about the server. It still feels great.
shortcoming.
Currently, Matchvs mainly revolves around the concept of 'room'. Create, join, and acquire rooms, and send and receive data of each member in the room. Therefore, it is currently not suitable for scenarios in which data is sent and received outside the room.
For example: In the client, the user name needs to be modified, and this operation cannot be easily implemented.
At present, GS does not support database, but uses hashSet and hashGet, which is too troublesome to use. If there is a need for data access, developers need to buy a database service by themselves.
I hope there will be database support in the future, or support the use of the official database and the database purchased by myself.
The command line tool part of GS is not very easy to use, and there are some small problems. The password is not hidden when
logging in, and the error message is confusing.
To exit is to type quit, not the customary ctrl+c.
Turn off debug, the disconnection time is too long, and sometimes it is even unresponsive. Sometimes you have to force close.
The gs+node service uses hot update, which will cause some minor problems such as disconnection of the gs service.
On the official website, the corresponding documents are more difficult to find, and the guidance is not strong. It takes a lot of time to find a document. After feedback to the Matchvs team, it is said that the document will continue to be optimized, and the structure of the document center will be revised in the near future.
Some interfaces and methods are not explained in the official, you can only understand the usage method by viewing the source code or asking the official.
For example: When researching Demo-GS-JS, I thought of a question, what does the client use to monitor when gameServer pushes messages to the client. Later, it was known that it was received by sendEventNotify.
I found that the documentation doesn't have this description. The official website stated that it will make up for all the missing descriptions as soon as possible to explain that
the writing method of callback is unscientific.
For example: mvs. response. sendEventResponse = callback(msg){} mvs. engine. The writing method of sendEvent(data) is very unscientific. If there is also sendEventResponse in the subsequent code, the previous sendEventResponse will be overwritten.
Suggestion: Change the callback method to sendEvent(data, callback(err, msg) { }),
especially to remind that
random join and specified join rooms are independent of each other.
For example: a room joined by 'random join', if the user wants to join by 'specified join', he cannot join this room.
The official explanation is the same. However, the official documentation doesn't say so, hopefully the officials will notice this.
When the joinRoomNotify notification is just received, the user and other users may not be notified by messages.
For example: At this time, other people (clients) send messages to the joiner, and the joiner is likely not to receive it.
Officials gave an explanation: 'The user is already in the room at this time, but has not established a communication channel with other players. At present, the js-SDK is not perfect enough. It should be confirmed that the channel establishment is completed before sending the joinRoomNotify notification', and said that this bug will be corrected in subsequent versions.
My solution: When the above joiner joinsRoomResponse, send an isEnter message to inform others that I really came in.
The questions and suggestions are about the same, but there is one point to explain. Although there are some problems encountered in the subsequent use process, I would like to thank the official customer service for patiently answering and optimizing in the Q group (you can feel This is a team that is working hard on the product, and now I think of that customer service 80% is a product of Matchvs), so that the game can be launched smoothly and maintain stable operation.
PS: I heard that Matchvs is going to update a large version of optimization soon, I look forward to it, I hope it will get better and better.