Posted by: Xalthorn | January 25, 2008

Mondestia Design Overview

Introduction

This is the first post in the Mondestia Design category where I’m going to document the design and implementation progress of the Mondestia website.

I’m expecting that there will be many occasions where I make a bad decision and have to reverse or back track and rethink it. However, rather than hide these mistakes I’ll just keep going and bring the project back on course. This way, people will be able to see my mistakes and hopefully learn from them.

It also means that if someone reads the posts and can see I’m heading for a huge problem, they might feel inclined to warn me before I go too far.

Feature Summary

Without going into too much detail at the moment, the following list shows the main features that I will be incorporating into the Mondestia site.

Environment Shell

The aim is to have a single website that is made up of a number of environments. These environments are self contained games but they all utilise the same central record for the player.

This means that a single login is needed to the site, which gives potential access to any of the environments within it. This removes the need to register a new account for each game. It also allows for achievements gained in each game to be recorded in a central location, allowing the possibility of one environment recognising achievements in others.

Privileges

Although there is a single login to the site, a user potentially has access to all environments within it. The privilege system gives a detailed level of access to environments or even parts of environments.

The privilege system also allows for guests to browse through the site.  Although they will not be able to play any games until they register (where would we save the scores and achievements?) , they are able to look at the help files, game guides, screenshots, and so on without being forced to register first.  This should not only remove the annoyance from potential players but also help to ensure that registered players actually intend to play.

Low Bandwidth

There are many little tricks and approaches that will be used to keep the bandwidth to a minimum.  This should result in cheaper hosting and also, much faster responses for the player.

Database driven content

There is little point in creating such a dynamic site if I’m then going to create static pages of content and uploading them.  Therefore, as much content as is practical will be driven from a database.

Environment States

Because the user is encouraged to use the shell to switch between environments as they see fit, their current position or state in each environment will be preserved as they use it.

This state will also be preserved if they close the browser down, meaning that they can play as much or as little as they like, close the browser (even in mid combat) and then when they return to the site, their position in that environment will be exactly as they left it.

There are special cases made for multiplayer environments where the other players cannot be expected to wait days for you to log on and have your turn, but the general approach stands.

Advertisements

Responses

  1. You’ve raised some good points there.

    Though I don’t see how you will be handling the situation when a player quits in the middle of a multiplayer combat right now. But I am anxious to learn more. Keep it coming…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: