[erlang-questions] Desing of MVC models

[Loïc Hoguin]

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