[erlang-questions] Desing of MVC models

[Jesper Louis Andersen]

The MVC pattern is prominent in other languages due to a few facts:

* Shared Nothing - The only way to persist data over multiple independent
connections is to push it down to a DB layer so you can communicate data
from A to B.
* Safety - If you want your data to survive a crash it *must* be put on
stable storage all the time

It is quite shocking how much of our typical infrastructure relies on
massive databases and big caches in order to be able to run individual
processes on a UNIX system.

In Erlang, you have options. Safety is had due to isolation, so you don't
have to push data onto stable storage as often. And you can quickly
communicate in the same memory space between processes, so you don't need a
mediating DB layer.

Many game servers written in Erlang just keeps most of the game state in a
process concurrent to the incoming HTTP requests. And then they use
something like gproc to find the game and update its internal state logic.

As Loic suggests, writing the game server should be possible without DB
access, nor with HTTP access.



On Fri, Sep 13, 2013 at 9:36 AM, Loïc Hoguin <essen@REDACTED> wrote:

> On 09/12/2013 11:59 PM, Ludovic Demblans wrote:
>
>> Hi,
>>
>> I would like to ask a few questions about models (in an MVC sense) in
>> Erlang.
>>
>> I come from a web software development background (PHP/js) and try to
>> adapt myself to Erlang philosophy but it's not always easy.
>>
>> So, I'm building a game server for a browser game. I choose to stick
>> with MVC as it is what I know best.
>>
>
> Sorry for not answering your question, I'd just like to give you an
> alternative instead.
>
> You most likely don't need to store all of this in a database.
>
> Why? Because a lot of this information is only useful while the player is
> active. I do not know the exact rules of the game you're building, but
> common things that generally do not need to be stored in the DB include for
> example position or current health, that is, what I call "live data". This
> live data is the data you would reset when loading up a new map/area, when
> the player starts playing or any similar situations. Don't put these in the
> DB.
>
> Where should you put them then? You create processes that contains these
> live data in their state. You create functions to perform operations on
> these processes, having the logic not in the "controller" but in these
> processes, the "controller" only needing to tell the process that something
> happened and what. This can be done using gen_server or gen_fsm (the latter
> is harder to learn but probably more adequate for many things).
>
> The process will also save to the DB the data that needs to be stored
> permanently, but it doesn't have to store it every time something happens,
> it can do it at regular intervals and on process termination.
>
> These processes are essentially what you call a model in MVC. You can
> simply have one process per "object" in the game. The cool thing however is
> that by doing the above your model is completely separate from your web
> layer, which means it's easy to plug a different layer (for mobile gaming
> for example) and more importantly that it's easy to test.
>
> It's also generally worth separating your game into its own OTP app
> separate from the web layer because it's now entirely independent, and
> there's no point in shutting everything down immediately if the web layer
> goes down and back up a second later.
>
> I often recommend people to write their game logic first without any
> graphics or database component, as it makes it easier to forget the bad
> habbits they had from other languages, and then, when the game works in
> tests (first manual, and then common_test automated testing), to add the DB
> (only for what you really need to store) and the graphics layer (in a
> separate OTP app).
>
> I hope that despite me not answering your question I could be useful to
> you.
>
> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
>
> ______________________________**_________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130913/2d4a57d5/attachment.htm>