Elixir Game Costume Design Three

The player process is modeled with Gen_server, I do not use genserver directly, but instead use the exactor, which removes the lock-locked interface definition.

Let's create a new Player_server_manager app and use the mix new Player_server_manager--sup to add sup to us. Then add the Exactor dependency in the Mix.exs as follows:

  defp    depsdo"~> 2.2"}]  end

Run Mix Deps.get, the success of the dependence on the ready.

Player_server_manager.ex generated by default

defmodule Playerservermanager do use Application#See http://elixir-lang.org/docs/stable/elixir/Application.html  #For more information on OTP applications  defStart (_type, _args) doImportSupervisor.spec, Warn:false children= [      #Define workers and supervisors to be supervised      #worker (Playerservermanager.worker, [Arg1, Arg2, Arg3]),    ]    #See http://elixir-lang.org/docs/stable/elixir/Supervisor.html    #For other strategies and supported optionsopts =[strategy:: One_for_one, Name:PlayerServerManager.Supervisor] Supervisor.start_link (children, opts) EndEnd

The player process is called Player_server Bar. Change it to what I need.

defmodule Playerservermanager do use Application#See http://elixir-lang.org/docs/stable/elixir/Application.html  #For more information on OTP applications  defStart (_type, _args) doImportSupervisor.spec, Warn:false children= [      #Define workers and supervisors to be supervisedworker (Playerserver, [], restart:: temporary),]#See http://elixir-lang.org/docs/stable/elixir/Supervisor.html    #For other strategies and supported optionsopts =[strategy:: Simple_one_for_one, Name:PlayerServerManager.Supervisor] Supervisor.start_link (children, opts) Ende nd

Because the player process is created dynamically, it uses simple_one_for_one, and I do not need to pass the default parameters, and I do not need to restart.

OK now let's write the Playerserver module (now it's simple, and I'm not yet aware of what needs to be adjusted, and then evolve with the server design).

Let's add a query to the Diamond interface first.

defmodule playerserver do use    exactor.genserver    defstart start_link (player), do:initial_state (% {player:player, socket:nil})    Defcall Gem, State:state, do:reply (state.player.base_info.gem) End

We add the boot interface to the Playerservermanager as follows

def start_player_server (%player{} = player) do    Supervisor.start_child ( Playerservermanager.supervisor, [player])  end

Add test code to Player_server_manager_test.exs

defmodule playerservermanagertest do and  exunit.case  doctest playerservermanager    setup    do Application.stop (:p layer_server_manager)    = Application.start (:p layer_server_manager)  End  Setup      do = player.new (0)      {: OK, player:player}  end  "start Player _server",%{    Player:player}doassert {: OK, pid} =  Playerservermanager.start_player_server (player)    assert  playerserver.gem (pid) = =  0  EndEnd

Test passed.

Written here before the player and Baseinfo @behavior should actually be @hehaviour, since the previous error, I removed it, the test still passed. The explanation may actually only need

Defdelegate.

Okay, here's the chapter. The legacy of the problem is that we usually need to give the player process a name, not through the PID, if it is a single node, local registration is enough, if it is cross-service access, we need a distributed registration mechanism (in fact, the distributed registration mechanism is prone to pit, if not necessary, do not). Like Gporc, like Syn. The former is more famous, I used to use Erlang before, have encountered strange strange problems. So let's try Syn in the next chapter.

Elixir Game Costume Design Three