I am beginning the development of a broser based game in which players take certain actions at any point in time.
Big parts of gameplay will be happening in real life and just have to be entered into the system.
I believe a good kind of comparison might be a platform for managing fantasy football, although I have virtually no experience playing that, so please correct me if I am mistaken here.
The point is that some events happen in the program (i.e. on the server, out of reach for the players) like pulling new results from some datasource, starting of a new round by a game master and such.
Other events happen in real life (two players closing a deal on the transfer of some team member or whatnot – again: have never played fantasy football) and have to be entered into the system.
The first part is pretty easy since the game masters will be "staff" and thus can be trusted to a certain degree to not mess with the system. But the second part bothers me quite a lot, especially since the actions may involve multiple steps and interactions with different players, like registering a deal with the system that then has to be approved by the other party or denied and passed on to a game master to decide.
I would of course like to separate the game logic as far as possible from the presentation and basic form validation but am unsure how to do this in a clean fashion.
Of course I could (and will) put some effort into making my own architectural decisions and prototype different ideas. But I am bound to make some stupid mistakes at some point, so I would like to avoid some of that by getting a little "book smart" beforehand.
So the question is:
Is there any kind of architectural works that I can read up on?
Papers, blogs, maybe design documents or even source code?
Writing this down this seems more like a business application with business rules, workflows and such… Any good entry points for that?
EDIT:
After reading the first answers I am under the impression of having made a mistake when including the "MMO" part into the title.
The game will not be all fancy (i.e. 3D or such) on the client side and the logic will completely exist on the server. That is, apart from basic form validation for the user which will also be mirrored on the server side.
So the target toolset will be HTML5, JavaScript, probably JQuery(UI).
My question is more related to the software architecture/design of a system that enforces certain rules.
Separation of ruleset and presentation
One problem I am having is that I want to separate the game rules from the presentation.
The first step would be to make an own module for the game "engine" that only exposes an interface that allows all actions to be taken in a clean way.
If an action fails with regard to some pre/post condition, the engine throws an exception which is then presented to the user like "you cannot sell something you do not own" or "after that you would end up in a situation which is not a valid game state."
The problem here is that I would like to be able to not even present invalid action in the first place or grey out the corresponding UI elements.
Changing and tweaking the ruleset
Another big thing is the ruleset.
It will probably evolve over time and most definitely must be tweaked.
What's more, it should be possible (to a certain extent) to build a ruleset that fits a specific game round, i.e. choosing different kinds of behaviours in different aspects of the game. This would do something like "we play it with extension A today but we throw out extension B."
For me, this screams "Architectural/Design pattern" but I have no idea on who might have published on something like this, not even what to google for.
Best Answer
EDIT: Your update to the question clarifies a lot of things, and changes the direction of the question quite a bit (at least from my perspective).
The problem seems to be that not only would you like to achieve this, but you'd like to achieve it in some completely generic way, which allows you to vary the rule engine behind the scenes dynamically. The latter is the really difficult part, and I'm not sure you're going to find a complete solution readily available for your exact needs.
If we take a step back, the "traditional" way of doing this would be something along the lines of the following (let's use a Model-View-Controller architecture, it's probably a good fit for your game):
The model represents the logic of your game, and is responsible for creating a structure which contains all the information that your presentation layer (the view) needs to do its job (preferably without any additional logic in the view). In practical terms, this means it will figure out exactly what actions are available to the player, which items are "sellable", etc.
The view would be in charge of how this information is presented to the user. Typically, the view is either a server-side template (which results in actual HTML being generated), or a client-side template or other javascript code which results some HTML being updated on the client side (in the latter case, the model is typically sent to the browser as AJAX).
The controller's job is simply to take incoming requests and to route the request to the relevant model, and send this result to the relevant view.
So essentially, if you've designed everything cleverly, the basic MVC pattern already gives a nice separation of the presentation from the logic. What you need to really figure out how to structure your model so that the view can remain relatively void of logic, and generic. Some things are easy (e.g. this list of items can be sold by the player) and some things are hard (here's a list of generic actions - if the player chooses action A, they need to select an item worth X to trade, and a player from their friends list). By carefully considering the axes along which you wish to remain flexible, you can come up with the correct architecture, however.
Assuming that the different rule-sets still fit into the same presentation strategy, varying the rule-set will be "relatively easy" to do. It's difficult to say more without knowing your exact game ideas, but you could have hooks in your core game rules for various modifications to apply their changes, etc. If you are looking for something more generic than that, consider reading up on rule engines, or even building your own domain specific language, which you can then translate into rules at runtime.
Original bit about MMOs:
Yannis' links go into some detail regarding MMO architectures. It might not be referring to browser-based games, but much of it is still applicable. A few things I would like to point out:
You seem to be alluding to having much of the game run purely on the client-side. Here's the problem with that: the client cannot be trusted. It's an old rule of thumb for any kind of development, and it applies to games too. It is trivial to mess with javascript code, and there are no purely client-side defenses for that. If this is a concern for you (say, your players' enjoyment or money is at stake), you have to do some work on the server side. Here's an example discussion over at gamedev (coincidentally, that site might be better suited to this question), where the advice is "Client-side movement handled immediately and then verified by the server is a great method when combined with server proxies with interpolated moves". Essentially, you want the server to know quite a lot about what's going on in the client, enough to be able to call foul if someone is tampering with the client. This is the approach used by most realtime multiplayer games (Battlefield, etc) - obviously you can't just trust the client to say "hey, I shot that guy, no, really", you need the server to be able to check that it's at least plausible. We're basically talking about mirroring the client logic and data on the server side.
This is obviously not the easiest thing to achieve, and will probably slow down your development. My advice would be to figure out exactly why you'd like this game to be heavily client-side (cost, user experience, etc), and to consider moving most of the functionality into the server-side. If you do this, your game becomes very similar to a tradition web application, where you just validate all user inputs and run the logic on the server-side. Many current browser "MMOs" actually use this approach, the good ones just happen to do it slick enough that you don't notice.
Note: I put MMO in quotes at the end, because if games like Evony are MMOs, then Gmail is one, too.