<div dir="ltr">I think you have some more marble to cut away before the shape of the problem begins to reveal itself.<div><br></div><div>* do the players interact with each other directly? Â If so, what state do they share and how much? Â Is there a separation between 'state for everyone' (e.g. world of warcraft: the entire world geometry and all 3d models are gigabytes of static data that are stored on the local filesystem and not kept 'live' in memory) and 'player state'? Â What is the size and nature of each type of state?</div>
<div><br></div><div>* what are the constraints around latency -- does it look more like a real time game (e.g. street fighter, counterstrike, league of legends) where, e.g., 250 ms of latency is unacceptable to the experience, or more like a turn based game (e.g. chess, poker, backgammon) where latency of 3s is tolerable? Â This drives certain considerations; e.g., you may be able to use a slightly lower performance but more reliable database system for the latter case.<br>
<br></div><div>* what is the shape and nature of your cost envelope? Â If you are running server infrastructure for a game, then you may need to take special measures to ensure that your costs remain beneath your gross profit.</div>
<div><br></div><div>Since, as you say, managing game state is such a giant pain in the ass, my general best practice when I do exactly this thing as part of my day job is to first write down all of the different kinds of state, their approximate quantity in bytes per player/world/universe/shard/whatever, and then do some spreadsheet math to figure out what I can get away with.</div>
<div><br></div><div>Example: Game is Facebook-style web game like Farmville. Â State can be boiled down to a binary data structure that is 4 kilobytes in size per player. Â Expected profit per user is on the order of pennies. Â Tens of millions of users expected. Â Solution: save state in the user's own browser via encrypted cookie, use tiny database (sqlite, mysql, etc.) for leaderboards and sending seeds between players. Â </div>
<div><br></div><div>Example: Game is World of Warcraft style MMO but you're trying to do it in the browser so can't download gigabytes. Â So you must shard each zone into, say, a 50 megabyte downloadable size. Â Zone shards are static so can be files. Â Private player data (e.g. inventory, raid history, message log) is maybe 1 megabyte; public player data (e.g., x/y/z coordinates, avatar skin) is maybe 30K and shared across the entire world (but usually limited to a shard), needs fast access though as the world ticks at 30 frames per second and you need to do distance calculations, etc. Â Store the public player data in memory, dets (per shard) or redis depending on whether you want raw speed, resiliency, or tooling. Â Store the private data in memory, dets, redis, or mysql, depending on speed, resiliency, tooling, cost and analytics requirements.</div>
<div><br></div><div>Generally I use ets for fast-access random-lookup state that has to get shared between processes, redis for fast-enough (still plenty fast) random-lookup state that has to be able to get large and/or survive system crashes or writeoffs (via slave replication and aof, rather than clustering), mysql for mass market mediocre state storage where the client has pre-existing infrastructure and ad hoc querying is important, postgres for green fields state storage where ad hoc querying is important, and thankfully so far I have been able to avoid having to use inconsistent data stores in production. Â I wouldn't ever consider dets or mnesia because equivalently-functional tools exist that are radically more popular and have better tooling, capability, characteristics or safety guarantees.</div>
<div><br></div><div>F. Â </div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 15, 2014 at 10:03 AM, Lloyd R. Prentice <span dir="ltr"><<a href="mailto:lloyd@writersglen.com" target="_blank">lloyd@writersglen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I'm thinking through the design of a web-based multiple-player game. Each player maintains a private database--- most likely dets. Each player moves through nested finite state machines. Each player may be logging in or out at any state of play.<br>
<br>
At this point my grasp of Erlang architecture breaks down. I don't understand how best to:<br>
<br>
- parse game structure across players, processes, and directories<br>
- maintain player state between sessions<br>
<br>
At this point in my Erlang education I feel like I know the words but can't play the music.<br>
<br>
I'd much grateful for any and all ideas and suggestions.<br>
<br>
Many thanks,<br>
<br>
LRP<br>
<br>
Sent from my iPad<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div>