Design summary of Erlang game suit

This is mainly for more than a year, individuals engaged in the development of Erlang game clothing for some things to think about.

There is no hierarchy to think of.

Welcome to the discussion.

Usually the design of the Erlang game service involves the following:

• Mission system
• Active system
• Guild System
• Gameplay system
• Buddy system
• Chat system
• Mall
• Turntable
• and other

I've had a few projects, only 2. In these 2 projects, I have seen that system modeling takes the following Yiguoduan:

• That is, the player process loads all player data and processes all possible systems;
• The entire game suit is usually only the player process, guild process, gameplay process, and some public processes.
• All you see in the entire game is the process and the app is not visible.
• Often there are few gameplay processes, and many logically differentiated gameplay are simply brutally crammed into a gameplay process.

I'm curious, is this the Erlang game suit? In my opinion, this is all a mess, not to say that the ERLANG/OTP system is used as a building block?

Why can't I see task apps, active apps, guild apps, play apps, friends apps, and more? Is it not clearer to use the application to partition the system? Maybe it can be loaded on demand.

data, rather than loading the entire player data? Can it be easier to reuse code by applying modeling?

Moreover, all things melted together, the system test is almost impossible, and no test means a bug.

In particular, the gameplay process is mixed with a variety of gameplay logic, using the case if pattern match to invoke different code.

Usually do a good game, but also inadvertently lead to other play a bug. (I have encountered this problem in 2 projects).

I hope the game suit design should be this:

• The system is built as a building block, you will have mission apps, Buddy Apps, Marketplace apps, guild apps, and more
• With the application division, the player process does not need to load all the data, the required data in the relevant applications to solve, and even for non-hotspot data, the application may be loaded to release memory after processing.
• Applications can be tested independently, without relying on other stuff.
• Different gameplay is built with different processes, a way to play well, and you don't have to worry about it.

Perhaps the application to modeling, the task of building a process seems too overqualified. It is even more convenient to process data in the player process, avoiding unnecessary inter-process communication consumption.

Then I think it's good to model the library application.

Design summary of Erlang game suit