Yunfeng-Development Notes (1)

After a long time, we can finally start the formal project development.

In the past few days, we fell into the issue of the company's equity distribution, entangled in the fact that a few people need to be in place to start the game. We also repeatedly discussed what kind of game should we do. Lin Zong, finally, in the hands of several students who have already been in place, Dangdang decided to become handsome and start to do it.

There are less than 10 people in an empty office, which is different from what we imagined at first. In particular, the main planning has not yet been finalized. I said, dingdang, you are also a senior game player. After so many years of experience in the Game Department, with so many successful projects, you have never eaten pork and have never seen pig run, I don't believe you will be worse than others. If it wasn't for me that I had to stare at the program to implement it, I wanted to make my own plan. But you can do it with me.

The location of the main planning, we can leave it empty first, and the preliminary work cannot be extended. A product manager is required by a startup company to act as a game owner. Just like the cto I listed here, besides being responsible for the system architecture, I have to have a programmer to implement it.

After two days of discussion on the project schedule, we started the project today.

What is the game? Semi-confidential. I don't want to write more here, so I'm afraid everyone will scold me. Besides, what does this thing mean now? It will certainly change in a year or two. It is useless to say more, and it is useless to explain more. Simply put, a combat system is similar to World of Warcraft, but the core gameplay of the system is very different, easier, and more PVP-oriented MMORPG. Why is this? I don't want to explain it. It's not just a head shot.

Since it is a development note, I will write what I am doing and what I plan to do.

We first played World of Warcraft collectively for a week. Although most of the players are already wow old players, there are still two of them playing less. Let's get familiar with it. I am familiar with the Combat System and the artistic style. Cultivate some interest. Everyone will feel a little bit of love at least on the surface of what we will do in the future.

The art and planning plan is not discussed, but mainly the program plan.

Before closed beta, there were eight historical milestones. By the end of the first phase, there were internal running versions. This time, we have completely abandoned any finished products that we have accumulated in NetEase, all starting from scratch. However, for programmers, everything is in their minds, but the workload is not heavy. I am afraid it is the opportunity that most programmers dream.

Of course, we purchased a set of 3D engines (not introduced, not explained), with a higher starting point. The server also tries its best to use some mature open-source libraries.

Phase I intends to implement basic user login and scenario roaming, including running, jumping, walking, and riding in the scene.

Phase I programmers:

• Cloud wind: responsible for overall planning, overall protocol design, and implementation of some server modules.

• Monster company: responsible for the design and implementation of the client.

• Snail GUARD: Responsible for the detailed design and implementation of servers.

Quarrel is our tradition. It has started since today. By convention, I was unable to convince the project team of all my design and technical options. However, the compromise is that we should first follow my ideas. The first phase will be completed by the next weekend. Based on the problems encountered in the implementation process, we are revising or even restructuring the current design. The cost of a week and a half is what we can afford now.

PS. Programmers are such a strange creature. Good programmers have their own ideas. There is love for self-implemented or the code to be implemented. Implementing it according to others' ideas is very painful and will feel like they are wasting their own lives. Therefore, most of the dynamic projects were initially built by one person. In large companies, many old programmers like to recruit new people with potential. They think they have a blank sheet of paper to shape them. In the end, it is obedient. However, the fact is generally that either a mediocre person can be trained and cannot be assumed, or the technical choice can finally be separated. I always say to them, do you want to listen to others' opinions? If you do not want to, do not direct others to others. Don't let others help you with what you don't want to do.

My design draft is as follows:

The entire game system (required for Phase I projects) consists of the following components:

• The client runs on the player's terminal and uses a TCP connection to communicate with the system. It is connected to the game Server Gateway.

• Gateway is responsible for summarizing all clients. It is basically the same as what I thought many years ago. Although there are some small changes in implementation, there is no fundamental change in thinking.

• The customer agent runs on the backend of the Gateway. Logically, each client has an agent responsible for translating and forwarding client requests and responding. Many agents can be implemented in the same process or in multiple different processes. It can be run in the form of a script virtual machine or in other forms, which are not very important. This time, we are most likely to use an independent Lua State to implement a single agent.

• Data Service: stores gamer Data and Scenario Data. The front end uses its own code and protocol to communicate with other parts of the system. The back end wants to use redis for storage this time.

• Scenario manager for managing static scenarios and dynamic copies.

• A number of scenario servers are used for players to roam inside.

Services after the gateway are mutually trusted, and a virtual network can communicate with each other. Zeromq is currently used at the underlying communication layer, and Google protobuf is used for communication protocols.

The communication protocol between the client and the agent is isolated from that between the gateway and the logic nodes. It is not even guaranteed to adopt consistent technical implementation solutions and protocol design styles.

The key to the design here is the agent design. Most of the work is centered on it.

The workflow of a single agent represents what is displayed in the Project Phase I. The general logical process is as follows:

1. Waiting for User Authentication

2. The authentication system is handed over to the authentication server for authentication. If the authentication fails, 1 Retry is returned.

3. Obtain user data from the database (phase I data is very small, only the Default User Name, user image), and send it to the client.

4. Obtain the user's scenario number, obtain the location of the scenario service from the scenario manager, and apply to join the scenario.

5. Slave Scenario Server and synchronization environment.

6. Forward users' roaming requests in the scenario and synchronize real-time data in the scenario.

7. If an exception occurs on the client or a message is sent, the scene server is notified to exit.

This is a small difference from our game server design in history. In my opinion, the position, action status, and even subsequent combat numeric status of a user's role in a scenario are part of the scenario data, rather than part of the user data.

In user data, scenarios only include the current scenarios. You can use the scenario to save the role status data in the scenario. In simple and specific terms, similar to the series of Western games in the history of Netease, the player coordinates are one of the players' attributes and will be stored in the player data during persistence. After two years of thinking, I think this design method is problematic.

Intuitively, the attributes of a virtual role should not include the geographical location information of the role. It is the external constraint of the role. The scenario should have the location and various statuses of PCs and NPCs in it. When a PC is deprecated, it is considered that the PC is in a special State (not visible or affected by the surrounding PC/NPC) and is not isolated from this scenario. Therefore, I prefer to define a PC offline as a detach, while a launch is an attach operation. At this point, a scenario, as an entity, has its own data logic.

The agent-related protocols are roughly designed as follows:

• Auth login Authentication
  • User/pass get userid, return success or various failures
• Userdb
  • Obtain Avatar list with userid
  • Use avatar to obtain Avatar data (including the scenario name)
• Scene Manager
  • Obtain the scene ID using the scenario name
  • Use scene ID to obtain the scenario status, and return the permitted entry or various congestion statuses.
• Scene
  • Attach avatar to a scenario
  • Obtain Avatar scenario Context
  • View Avatar detach
  • Avatar sets coordinates, speed, behavior (run, walk, stand), direction
  • Avatar riding status changes
  • Avatar performs specific actions

Well, this will be the task of the next week. We need to refine the configuration tomorrow. Then, it is implemented.