[erlang-questions] Desing of MVC models
Fri Sep 13 09:36:27 CEST 2013
On 09/12/2013 11:59 PM, Ludovic Demblans wrote:
> I would like to ask a few questions about models (in an MVC sense) in
> 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
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
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.
More information about the erlang-questions