<div dir="ltr">The MVC pattern is prominent in other languages due to a few facts:<div><br></div><div>* 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.</div>

<div>* Safety - If you want your data to survive a crash it *must* be put on stable storage all the time</div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>As Loic suggests, writing the game server should be possible without DB access, nor with HTTP access.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 13, 2013 at 9:36 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 09/12/2013 11:59 PM, Ludovic Demblans wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I would like to ask a few questions about models (in an MVC sense) in<br>
Erlang.<br>
<br>
I come from a web software development background (PHP/js) and try to<br>
adapt myself to Erlang philosophy but it's not always easy.<br>
<br>
So, I'm building a game server for a browser game. I choose to stick<br>
with MVC as it is what I know best.<br>
</blockquote>
<br></div>
Sorry for not answering your question, I'd just like to give you an alternative instead.<br>
<br>
You most likely don't need to store all of this in a database.<br>
<br>
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.<br>


<br>
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).<br>


<br>
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.<br>
<br>
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.<br>


<br>
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.<br>


<br>
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).<br>


<br>
I hope that despite me not answering your question I could be useful to you.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a></font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>