- Version belongs to 5.0
ECS？
- The real ECS belongs to entity-component-system
- There are only data and no methods in the component. In the system, there are methods for components. The system only needs to pay attention to the set of components it wants to pay attention to by searching.
- But the code of the ET framework is full of methods in the components. Components with data and methods can be disassembled at any time. What is it like? That's right
- It is Unity’s component mode
- Look at this resource component
- This kind of component is essentially equivalent to the singleton Manager we often use, except that it is a system-level service, so it is all mounted on the Game entity.
- So the ET framework itself is a hybrid thing. It mixes Unity's component model with ECS-style things.
- For the real ECS framework, you can see this ECS framework
- He uses ECS for the sake of using ECS, but in essence it is still OOP.
- In addition, in my opinion, ECS actually splits the Model business model in MVC, but for VC, it is still how to write it.
- Of course it's biased. I might have a deeper understanding by looking at some ECS demo source codes.
Message processing
-
In terms of message processing
-
Its logic is like this. After clicking the button to enter the map, it will send a message to the server, and the server will send back a player ID.
-
This player ID is the unique identifier of the client
-
When receiving the reply message from the server, send an internal message to create the Unit.
-
The handler of this internal message will create this Unit and broadcast it. I don’t understand why it needs to be broadcasted? Why is it strange to use internal information instead of events?
-
When the Unit was created, the pathfinding component and the mobile component were mounted on it.
-
There is an OperaComponent in the game scene. This component will monitor key clicks in real time and send the clicked position to the server, and the server will then send it back to the client.
-
[It’s also quite strange here,]
-
After receiving the ClickMapActor message, the client parses the position and calls the unit's Path component to move it. The general process is like this.
-
Send entry map to server
-
After receiving the message, the server sends the information to the Map server to create the unit.
-
The map server receives the message and starts creating the unit and adding a series of components, then broadcasts it to all clients.
-
After receiving the message, the client will check whether the unit exists locally and create a display
-
The opera component listens to mouse click events and sends click location messages to the server
-
Process the message in the server's processing function
-The UnitPathFind component will broadcast movement information to other clients. The map data is placed on the server. The server performs pathfinding and then broadcasts the pathfinding results to the client for movement.
-
You can see that the pathfinding component is on the server side
-
The client receives the message and finds the unit with the corresponding ID and starts moving.
-
But in fact, this is very inconsistent. When I send a message, I should await to get the message and then process it. This makes it very scattered and not focused enough.
event handling
- All the logic of ET is handled by events.
- A disadvantage of this is that it cannot be highly cohesive.
- The logic that originally belonged to one business model was dispersed into two or three scripts through events. Increased reading difficulty and coherence.
- For a simple example, the InitScenFinish event is sent after the game is initialized.
- The UI processing module receives the event, creates a UI object and displays it
- Compose UI logic and bind events in each separate UI component such as LoginCom and LobbyCom.
- He wrote all the code that belongs to the Model layer into the static class Helper to call it.
- In other words, the View layer directly calls the Model layer code. In fact, this is a strong coupling.
- Call MapHelper directly
- Call LoginHelper directly
- its UI processing is also very poor. The login interface belongs to LoginState. Generally speaking, this is all that is needed, and we only need to call the corresponding interface when switching to EnterMapState. This makes the context clear and coherent
class LoginState:State{
void OnEnter(){
UI.Show()
}
void OnLeave(){
UI.Hide()
}
}
- But in its code, after sending login complete message it is like this
- Because he wants to close the Login UI and then display the Lobby UI
- But in fact, it would be better to put the loading and unloading of Login in a script.
