One of the worst problem facing anyone working on a project is that of the amorphous project (amorphous basically means without a definite form, or lacking coherent organisation, it constantly changes).

I’m in the process of making a working version of the Mondestia website to include the prototype code for the Dungeon game.  Whilst I’m at it, I’m coding in the environment systems and so on.

I always intended the web page to be viewable at a screen resolution of 800×600 without the need for a horizontal scrollbar and to achieve this, I’m designing a fixed width web page of 750 pixels.  This allows me to have the main content with a little bit of side padding on an 800×600.

Usually with web page design, you don’t really have to worry too much about the page height.  You ensure that the main attention content is at the top of the page and then leave the rest to the vertical scrollbar.

Certainly with the majority of the website, where it is presenting information, we’re all accustomed to vertical scrolling and this isn’t an issue.

However, with the game environments where you will be using the page repeatedly to play the game, you really don’t want to be scrolling down each time to access parts of the interface.  It would get really tedious really quickly.

As I had used a 400×400 map viewport in my tests, I’m not really keen to shrink that any more.  However, because it’s so big, it meant I had to do some fiddling with the interface and general page layout to get it to fit in without any scrolling.

I’ve done it, but I’ve had to sacrifice some of the header height which makes the website look a little cramped.  I haven’t lost any content in the header, but I have lost valuable ‘white space’.

I considered having a different page layout for when you were in a game environment, effectively giving the game more ‘control’ of the screen estate, but opted against that as it would ruin one of the driving features of the website which is to allow the user to navigate through the site and games as they want, using a consistent interface and layout to switch between sections as they need.

Having spent quite some time working with the practicalities and implementation of a game engine that will be suitable for both Dungeon Escape and Mondestia RPG, I came to the realisation that again, I’m not seeing the wood for the trees.

Although the Mondestia RPG will be the larger, more detailed project, Dungeon Escape is meant to be simple. Really simple.

Sometimes, playing with a concept and coding things to prove it will work can take a heck of a long time and prove to be a major distraction, bringing progress on the main project to a grinding halt.

I’ve hit one of those.

One thing that I am going to do with the Mondestia site is to ensure that (as far as is practical) the content of the site is separated from the structure and presentation.

A session searching the internet for such topics will yield a huge amount of documents talking about this, most of which cover the topic in a really vague manner which only serves to reinforce that the approach is the right way to do things, but don’t give any details about how to actually do it.

Very frustrating.

To add to the frustration, there seems to be a difference of opinion as to what the terms Content, Structure, and Presentation refer to. So I figured I’d take these words and come up with my own definitions and way to approach the problem.

Content

Content is actual information that will be displayed in some way. The content is also identified as to what sort or type of content it is, whether that be a heading, an image, a body of text, and so on.

Without a definition of what sort of content it is, the information is meaningless. You simply cannot expect a system to ‘guess’ what type of content is being looked at.

This is why the content definitions need to be worked out right at the start of the project. Without any expectations of what sort of content will be presented, the code that structures and presents the content will be doomed before it starts.

Structure

Structure is rightfully moved away from the content and is where the interface is starting to be, well, structured.

It is this part which determines how and in what order the content is output. To achieve this, a template system will be used which has templates of pre-formatted HTML with specific locations for the content to be inserted.

It is important though, not to confuse structure and layout.  This part of the process takes the content and wraps it up in appropriate DIVs that the stylesheet will then stylise and position in the presentation stage.

Presentation

Once the web page has been built with the content and the templates, the actual look and feel of it needs to be added onto it. This will be done with stylesheets.

As far as is practical, the stylesheets should have complete control of where and how the parts of the page are to be displayed.  I appreciate that the templates go some way to control this as they do the initial ‘wrapping up’ of the content, but the stylesheet should have the final word.

Practicalities

It really does take a little thinking to move to this system of web design.  We’re so used to simply churning out the HTML, it’s hard to stop putting this in the content.

One of the difficulties is when you’re not quite sure what you will want to output or even, how you will want to change it in the future.

A classic example is image galleries.  You may decide initially that you want to display a grid of 12 thumbnails in three rows of four images.  So, you write your PHP to pull the images out of the database 12 at a time, with a page selector to let the user move through the library.  You follow this with a template that has spaces for 12 image variables, and finally the stylesheet makes it all pretty.

If we decided that we wanted to output fewer images, we’d have to go back to the PHP code and change that, then change the template, and finally change the stylesheet.  So much for a dynamic website.

What we should have done was have a variable in a database table that determined how many images should be displayed which would allow the PHP code to adapt itself to suit.  The next issue is the template which is still expecting 12 image variables, which the PHP script is meant to be providing.

The link between the PHP script and the templates it uses is strong.  The PHP scripts need to know what the templates are called and what they are expecting to receive.  This is why the content types and groups need to be defined well in advance, as well as understanding what may change in the future.

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.

Having scoured the web for quite some time looking for ideas on how to lay out a web based game, I find that there isn’t much out there unless you look at existing games.

There are plenty of tutorials and attractive templates for informational websites, but whilst these are nice, they’re not always appropriate for a website that by its very nature needs to be hugely interactive and dynamic.

I’m no designer and although I know I like a website when I see it, creating something that both looks nice and is functional is hard.

I’m also finding that I’m falling into the trap of designing a website and then shoe-horning the content into the resulting design. This is both a big mistake and a huge time waster as you have to constantly refine or re-design your website to accomodate your project.  But it’s an easy trap to fall into if you start browsing template sites.

After realising I have wasted so much time on this, and to hopefully help people from falling into the same trap, I’m going to start documenting and designing the website in this blog, creating a tutorial or series of guidance notes along the way. With any luck I’ll achieve two goals.

1. Get my project complete and live
2. Help others to do the same

At least that is the cunning plan…

With any luck, I’ll end up with a fully documented case study which will show the whole process warts and all.  I’m expecting, like with any project, that there will be changes and decisions made later on that will impact upon earlier decisions.  Rather than hide my ineptitude and lack of forward thinking by completing the project and then publishing edited notes, I’ll simply keep documenting how I overcome these obstacles.

When you have a map that can be displayed in either top down or isometric view, one of the views is going to show more data than the other. Whether this is acceptable or not is a decision that needs to be made.

I’ve done a few images to demonstrate what I mean. In each image, the map data available is shown by the numbered squares.

The first image shows the map data available. The red square shows the main portion of the map that we want to display.

The next image shows how the main content would be displayed in a top down view.

All nice and tidy, showing the content that we want and nothing more.

The next image, representing the isometric view, still has the red square to show the direct translation of the top down view to isometric. However, unless the display is intended to be a diamond shape, we need the additional map data to fill in the corners.

This means that the isometric view shows more map data than the top down view, but unless you display in a diamond shaped view, this is always going to be the way if you are going to display the same amount of main content (the bit of the map that reaches the edges of the display).

If you decide to allow the user to have a top down view that shows more data, you would need to provide map data to fill in the empty corners of the first image, which then means that the isometric view is missing data.

If you are only ever going to use one view, it isn’t an issue at all. But if like me, you want to give the player the choice of which view to use, they are going to be penalised in some way, based on their choice of view.

I guess it all depends on how much of a perceived advantage these extra spaces give a player.

What with one thing and another, I’ve not progressed the assorted projects at all recently.  Well that’s not strictly true, I’ve made notes and experimented with a few things, but I have nothing to show for it.

I’ve gone back to the drawing board with the map display issue and I think I have a working solution to the ‘fairness’ problem.  I just need to code a mock-up version and see if it functions adequately.

As to the website ’shell’, I’m working on categorising the different types of content I will need to display so that I can plan out the variables, content and structure templates, and general stylesheet requirements.

It’s the standard doing a huge amount of work to display ‘hello’ or something equally unfair, but unfortunately it’s required and to not do it will cause me huge problems down the line.

What was the quote? Failing to plan is planning to fail, or something like that.  I know that too much planning is counter productive, but I’m implementing so many non standard things this time around I’m beginning to wonder why I never pick small and simple projects.  At least I’d get a few obvious achievements in a smaller timescale.

One thing that I will be doing with the Mondestia site is allowing a great deal of variety for displaying the characters in the game.  This will include the player avatar, the heroes for Dungeon Escape, and the NPCs found in the various games.

Rather than having to select from a range of pre determined graphical images, all characters will be drawn like the various ‘dress up’ dolls and avatars found on the web.  This means that there will be a base image, and then clothes and equipment are layered on top of that image.

The whole process is very straightforward, but planning ahead is essential.  For example, if I was to offer a single pose (and facing) and body type for male and female, then the layered clothing is easily done.  Create a single image for each piece of clothing for each sex (two if it wraps behind the character) and we’re done.

The complexity and planning comes in when you offer more poses, more facing directions, and more body types.  The body types having the greatest impact.

Now, for each item you want, you need the following number of images:

race * sex * bodytype * pose * facing

So if we had the following options:

• Race : Human
• Sex: Male, Female
• Body Type: Standard, Thin, Heavy
• Pose: Standing, Sitting, Combat
• Facing: Forwards, Left, Right, Backwards

This would mean for each piece of clothing that could be worn by both sexes, I would need 72 images.  If I added another race that could also wear the same clothing, that would be another 72 images, and so on.

If I took the easy route and only allowed characters to stand up, and had just one body type, that would drop to  8 images per race (16 if I had a fighting stance as well). Certainy more manageable, but is it varied enough?

Top down RPGs usually have simple graphics for characters.  A walk cycle of three frames, the centre one doubling up as the ’standing still’ frame, a total of 12 images per character with animation.  The combat system usually has a completely different, static image of the character which is usually larger and much more detailed.

Characters are rarely shown sitting down, the only other pose being a dead, or prone pose (rarely for heroes, usually random townsfolk or guards).

Taking this view, and incorporating the combat stance in the same system, I could limit the poses for each race to:

• Sex: Male, Female
• Body Type: Standard
• Pose: Standing, Combat
• Facing: Forwards, Left, Right, Backwards

This would give me 16 poses for each item for each race.  Not too bad, definitely manageable, but is it enough?  The last thing I want to do is decide later on that I want a sitting pose and have to go back and do new graphics for every item already designed, meaning that the new pose cannot be used until the graphics are complete.  On the other hand, I don’t want to spend time creating a whole bunch of images that I’ll never use.

As an aside, the standard body type works really well for anime style graphics where all people are pretty much the same, however it doesn’t allow for the huge brutish warriors.  Also, although they are unlikely to try to wear the same clothes as smaller body type characters, they may well want to equip the same weapons.

At the end of the day, it will come down to making a decision on the poses that will be available in the games, and sticking to it.  A little time spent roughing out the design for the other games I have in mind (the RPG being the main one) and what poses I think will be needed.