Crikey,

Doesn’t time fly when you’re engrossed in things.

For all sorts of reasons, both personal and professional, I’ve been sidetracked from this project.  Thank heavens it’s a solo project and no-one was relying on me to hit deadlines.  Although, on the flip side, that would have made me pay more attention.  Six of one and half a dozen of the other I guess.

Anyway, I still have every intention of getting this thing running and now I’ve moved to a host which seems to give me a better deal, I’m not so worried about throwing lots of files and bandwidth around.

My intention now is to try and progress the project each week, and start to set myself measurable and achievable milestones.  All good intentions…

We’ll see how I manage I suppose.

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).

All projects need an achievable goal and some sort of road map to get there.  Without these, a project is going to descend into chaos with the feature list ever growing and the expectations and technology required constantly increasing.

As a silly analogy, imagine if someone said ‘paint me a picture’ and that was the only instruction you received.  What would you paint? how? in what style? how large? how detailed? and so on.  If instead, someone said, ‘paint me a picture of a red roofed house on a green hill with some clouds and a sun in the sky’.  You’d have a much better idea of what you were to paint and could start thinking about how to paint it.  Granted, it is still open to interpretation and there are many ways to paint such a picture ranging from a child-like version to something by one of the great masters.  You would probably go back to the person and ask some more detailed questions about what they wanted and you would make notes, forming the rest of the design document for your painting.

The amorphous project issue is bad enough in a badly organised group project, but it is even worse in a solo project.  When you work solo you only have yourself to report to, to direct you, to praise you, and to bring you back when you steer away from the plan on some sidetrack.

And yes, I’ve fallen foul of that recently, but I’ve only just realised the true impact it is having on my game project.  Projects that you do in your free time (and by yourself) are hard enough to plan time for, but with an amorphous state, you have no chance of ever completing it, let alone ‘on time’.

The thing is, I was trying to make the game as versatile as possible with plenty of customisation options.  This is okay and very achievable, but I failed to draw a line and decide where it should stop.  This meant that I was constantly reworking an interface and design that was perfectly fine but didn’t cater for a particular situation.

So I’m going back to the drawing board, without throwing anything away, and deciding which elements of the design are essential, which elements are desirable (not essential but would be nice), and which elements are really not worth the hassle (unnecessary).

The essential parts of the design will naturally stay in as otherwise they wouldn’t be essential.  This will include the core game mechanics and what input/output is needed to allow the player to actually play the game.  At its very raw state, a browser game should be playable in a text browser.  It may not be attractive, but it should work.  I’ve tested my game (a long time ago) in this state and it worked fine.  Only when I started to add complexity and ‘pretty’ it up, did the project slow to a crawl.

The desirable parts of the design come next but have to be further broken down.  For example, an attractive interface is not essential to the running of the game, but is desirable as it adds a cosmetic, appealing interface to the player.  This interface can range from very simple to very complex which means that each desirable feature needs to broken down into its own essential/desirable/unnecessary aspects.

The unnecessary parts of the design will be put to one side to trigger potential game updates in the future, but that’s where they should live, as part of an upgrade to an already functioning game.

Also remember that your aim should be to get a solid, working game ‘out there’.  This is why you should plan to have working versions of the game in its raw state (essentials only) so that you can test it and make sure it functions.  You can then plan which desirable features (and which versions of each) you really want in version 1.0 of your game and which ones can be added later.

If you decide that you really want every feature you have thought of in the game at the very start, you are setting yourself up for a very long development time where you still don’t know if the game will be received well.  Also, be wary of showing off everything at launch.  Players expect games to mature and change over time (to a point) and if you already have a series of upgrades planned (more desirable features), then you already have things to keep your players interested as the months go by.

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.

The online game is meant to translate directly to a table top board game, playable without lots of referrals to manuals and look up tables. With this in mind, the complexity that I was starting to throw at Dungeon Escape was aimed at the wrong project, it should have been thrown at the RPG.

It is inevitable that during the creation and coding of Dungeon Escape, changes and improvements will be made when working on the RPG. However, these improvements and added complexity do not need to be fully worked out yet, simply pencilled in and a large ‘to do’ list created. It should certainly not delay the implementation of Dungeon Escape which doesn’t need half of the features.

So I’ve halted further development on features that I don’t yet need and turned back to the design notes for Dungeon Escape. Dungeon Escape will still have a fully functioning scrolling map display as it is very useful. However, I don’t need a fog of war, or the need to accomodate huge maps, or even worry about filling corners in for the isometric or top down view as appropriate.

All dungeon maps in Dungeon Escape are the same size for quick and easy dungeon layout (on a table). And as the whole dungeon level is viewable on the table, it should also be viewable in the online version.

The heroes also don’t need the complexity of the RPG as they are intentionally simplistic. Although it goes against my preferred approach, there will be races and classes to keep hero selection simple (in the board game version you will select a card to represent your hero). This drastically reduces the graphic content I need to prepare for the game. Fully customisable avatars/heroes will be left for the RPG engine. Dungeon Escape simply needs a fixed set of images for each race/class/sex combination.

Ho hum

So all I need to do now is finalise the design, put some initial graphic sets together, and code up a playable prototype that is along the lines of the final version. That can then be open to testers to tear it apart and generally test. A few iterations of update/re-test, and it should be ready for open playing.

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 has been bugging me for a while is how I want to display the player and their surrounding area, giving as much control of the view as possible to the player.

The current test generates a 50×50 tile map and displays it in a flat rectangle (no isometric yet). The viewport is set to 400×400 pixels with a thumbnail of 100×100 beside it. The map can be scrolled by dragging on the viewport, or moving the highlighted area on the thumbnail.

The plan was always to allow the user to select the zoom level which would determine the size of the images used to draw the map. Currently the three variations are 25×25, 50×50, and 100×100.

Displaying the map and thumbnail in the first place, with accurate and smooth scrolling was a hard and annoying process even though looking back at the code now, it all seems so easy. This was mainly due to the method used to actually move the map around.

Initially, I followed the generally accepted approach of changing the style of the map container to move it around (element.style.left and element.style.top). This worked but I found that the map juddered and was just not responsive enough.

The eventual solution was to use element.scrollLeft and element.scrollTop which made a huge difference when you’re moving a couple of thousand DIVs around.

Misha3D and I came to the conclusion that this was because rather than just moving an element on the page, we were modifying a style which could have had implications on every child within that element, which caused the delay. We could be wrong, but it made sense at the time.

Once the map was being displayed and could be scrolled around, the next step was to allow the size of the images to be changed by the user. Diving straight in, I placed three buttons on the page and had each one run some code that would essentially destroy and recreate the map display by setting the innerHTML of the map DIV.

In hindsight it wasn’t a very clever plan. Sure enough it worked, but the time it took to rebuild the map was irritating and I was only messing around with a test. I dread to think how many potential players would run away screaming after trying to use it in a game.

I considered doing some tests with a more reasonable map size. Something smaller than 50×50 and more the sort of size that the game would actually use. Thankfully I stopped myself, realising that I was trying to avoid the problem by changing the test parameters rather than make the code work properly.

So I knuckled down and had another think. After a bit of messing around, I found a nice workable solution that only had a brief delay when changing the size of the images. The solution I’m currently uses modifies the style of the map tiles rather than rebuilding them.

After all, all we’re doing is changing the appearance of the tiles rather than the content, so why should be have to rebuild the structure.

Now that works to an acceptable standard, I still have more work to do on the map display routines. I need to give the option to view the map in isometric view at the push of a button and I need to plan and test some actual content on the map beyond a few people.

After that I can then tidy the routines up and throw a test together that allows the user to move around a map stored on the server, with some basic interaction.

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.