There is a game, it implements a socket connection to the server.

Requests to the server are sent to me directly from the place where an event occurred. Requests are therefore scattered in different project files. After a partial review, I was told that it was not very good to send a request to the server directly from the "Player" file, but more correctly, probably from one place. Prompt, template, solution or a list of possible solutions for interacting with the server.

  • If you are given an exhaustive answer, mark it as correct (a daw opposite the selected answer). - Nicolas Chabanovsky ♦
  • I suspect that in your case Reactive Extensions will look good. - Pavel Hritonenko

2 answers 2

Unfortunately, what is recommended above is almost the same as what is already happening in your own implementation. This is just an abstract wrapper for accessing the server. An implementation through an architectural crutch is proposed. There should be no calls to the server through the Instance Singleton and Statics! The described path does not offer proper isolation. The normal solution would be:

  1. Create a class of model that can vary from online events and / or player input through public methods. In this class, access the network connection instance and listen for it to synchronize data. The connection can be stored in the same GameController, just not to make it open with a singleton or static, but to provide access by reference, through a normally built architecture.
  2. Dispatch events from monobekh to a mediator class, and from there change the state of the model. The model will synchronize these changes with the network and notify the mediators about the changes.
  3. Network events are applied to the model and send, internal events about changes (the same as in the case of changes from the input). The mediator will catch them and transfer them to monobech. I advise you to see how the separation of powers is solved in existing architectural frameworks, such as PureMVC.

    Em. In our games, for example, there is always a GameManager class that manages and redirects logic.

    Let's say for sending requests, we create RequestManager , which implements IRequestManager . In the simplest form:

     public interface IRequestManager{ void Send(string name, Object data); } public class RequestManager : IRequestManager{ [...] // отправка запроса public void Send(string name, Object data){ // здесь отправляем запрос } }

    And GameManager method to get a reference:

     public interface IGameManager{ IRequestManager GetRequestManager(); } public class GameManager : IGameManager{ // инициализируете где-нибудь IRequestManager mRequestManager; // например тут public void InitRequestManager(){ mRequestManager = new RequestManager(); } public IRequestManager GetRequestManager(){ return mRequestManager ; } }

    Now, if you need to send a request, then call the GetRequestManager method GetRequestManager the GameManager and send the request.

    GameManager can be done as a singleton, something like this:

     public class GameManager : IGameManager{ private statc IGameManager mSelf; // инициализируете где-нибудь private IRequestManager mRequestManager; // например тут public void InitRequestManager(){ mRequestManager = new RequestManager(); } public IRequestManager GetRequestManager(){ return mRequestManager ; } public statc IGameManager GetInstance(){ if(mSelf == null){ mSelf = new GameManager(); mSelf.InitRequestManager(); } return mSelf; } }

    Then from anywhere in the program you can send a request like this:

     GameManager.GetInstance().GetRequestManager().Send()