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.

Having made a decision about the content I want in the game interface, I have now hit the next stumbling block.  How to lay the site out.

The first question is of course, what resolution to support.  Having a website that is generally too wide for most people is a cardinal sin.  We’re all happy to scroll down a web page, but having to scroll sideways is just not on.

640×480 is generally not used by people who play web games nowadays, but 800×600 is, with some people moving to much higher resolutions.  Having looked at a fair amount of website tutorials, and the widths used there, I’ll be building the default web interface to be 760 pixels wide to allow for scrollbars and a little dead space around the page.

The next issue is the height of a header and other fixed content that pushes the actual game content down the page.  If most games require the player to click on a display area, each click causing a refresh, then having to scroll down the page to find that area would get annoying very quickly.

A header that is there simply to show the name of the site, often with a big graphic, seems to be a bit of a waste.  By the time the player has reached your site, logged in, and wants to play the game, they already know the name of the site.  Do they really need to be reminded by a large header?

To deal with this, the front page, and general site pages will have a fairly decorative header.  However, once you are in the game interface, this header will be tucked away in a small login status bar at the top of the page.  I’m not expecting this to be deeper than 20 or 30 pixels and it will have the name of the site (which itself is a link to the homepage), who you are logged in as, new mail/message/forum alerts, and so on.

Once you get past that small header, the content that you need to actually pay attention to will be displayed.  The more important (frequently used) stuff at the top of the page, the less important or occasional use stuff lower down.

Although it is tempting to have a horizontal menu bar underneath the header, this will again push the content down the page.  In the default layout I will probably have a sidebar menu with a quick link section in the header (if it fits).  Unless I have the game specific menu at the top of the sidebar, with less frequently used options beneath those.

Of course, the only way to find out what works is to try it in a browser and see what is easily accessed.  Time for a bunch of layout tests I think.

Because this is going around in circles with the decision of whether to go for top down or isometric, I’m tempted to go for both versions and let the individual player choose the one they prefer, switching between them if they want.

As usual, there is an ‘ah but…’ involved.

It was always my intention (and it remains so) that the player will be able to zoom in and out of the view to see either more detail, or more of an overview of the area. This is why all of the graphical tests have had three versions.

The difficulty now is that with an isometric display, there will always be more of the map shown unless you have a ridiculously narrow display. My concern is that players who opt for the isometric view will see more of the area than those who have opted for the top down and whether this is fair or not.

I’ve put another graphical test on the site (www.mondestia.com) which limits the vertical display of the isometric version, but this would then mean having two sizes of viewport depending on whether you are using isometric or top down.

Comments and opinions very much appreciated…

Having played around with the graphic styles, and had a disappointingly low number of responses from the community, I’ve decided on the style I’m going to use.  I’m going to use the top down view, and I figured I’d share my thoughts and reasons for this decision.

Isometric

Although technically more impressive than the top down view, it requires edge clipping to make it look halfway decent unless you go for the diamond view which in itself needs to be incorporated into the centre of a layout to stop wasting screen real estate.

With a scrolling map that is bound to have large structures such as buildings, and given that I can’t draw ‘off screen’ to automatically clip to a viewport, I would have to cut up each large graphic into isometric building blocks, including drawing the cross section of the building unless I was to resort to paper thin walls between tiles.

I could have drawn the whole thing with PHP into a single graphic and sent that down to the browser, but that is very wasteful of both server processing and bandwidth to send such a large and unique graphic each page refresh.

I had also considered using Flash to create the image as that would also solve the clipping issue, but that would be giving temptation to create a fully animated interface which would not only move the goalposts of the project further away, but also move away from the overall aim of the site.

Top Down

There is a good reason why this view is favoured by many web based games, and it isn’t just because of its simplicity compared to isometric.

It’s because it just ‘fits’.  The graphics are easily split into rectangles, and tile together smoothly.  Having a rectangular display also allows for an interface to be easily built around it with no risk of overhangs on the left or right edges.  The top overhang is also predictable and can be allowed for in the view.

Large structures are easily done by cutting the image up into tile sized chunks and drawing them as appropriate, the only concern being the drawing of a tall object or character that is just off the bottom of the display but the top of which would be visible.  Although this issue also exists with the isometric view of course.

Whilst I was doing some graphic tests for one of my game projects, I wanted to test the feasibility of either an Isometric or angled top down view (Zelda like).

Because I just needed some placeholder graphics, I found the following graphic set extremely useful for prototyping the angled top down view:

http://lostgarden.com/2006/07/more-free-game-graphics.html

This meant that the angled view looked gorgeous, but my isometric view, with way too vibrant colours, made the aesthetic comparison difficult as I found myself looking at the quality of the image rather than the general view type.

So I decided that it would make sense to used the same graphics for both versions, which meant I would need to turn the angled view graphics, which were square, into an isometric version.

I tried the obvious method of rotating the image 45 degrees and then halving the height, finally scaling the image to the size of my original isometric images.

Photoshop did the job wonderfully, except it anti aliased the image when it was rotated, and even though I tried manually scaling it, there was a horrible white edge around the tiles.

I tried an alternative method of having a new layer on top of my image, filling it with black, and then rotating and scaling that (meaning there was no anti-aliasing of the layer underneath), removing the black layer once it was done, but I still had issues with getting it to fit properly.

The final solution I found that worked nicely is detailed below. My original square tiles were 100 x 100, and my target isometric tile is 101 x 51 (a tile fitting on a 100 x 50 grid with an overhang to clean up the edges).

I started by opening my 101 x 51 tile gif (with transparency), changing the Image->Mode to RGB colour so I could do some processing on it.

I then used CTRL+Click on the thumbnail in the layers window to select everything that wasn’t transparent.

With that prepared, I could open up my 100 x 100 tile jpg, do Image->Rotate Canvas->Arbitrary with an angle of 45 degrees clockwise. This gave me a diamond version of the tile.

I then did Image->Image Size, and changed it to 104 x 52 (remembering to uncheck the Constrain Proportions). This gave me my Isometric version of the tile.

I then selected everything (CTRL+A), copied it (CTRL+C) and then switched back to my original isometric image.

A quick Edit->Paste Into, and I had my final tile, ready for saving to the web as a GIF image.

After spending a great deal of time messing around with ideas of how to make an Isometric display work in a web interface I think I’ve found a solution that I’m happy with in concept.  I still need to tidy it up a lot and stop wasting so much screen real estate, but it works.  The tests can be seen on the mondestia site (www.mondestia.com).  They may take a while to load and draw as they are being fully created on the server with no local javascript.  Once the final decision has been made, I’ll work on optimising everything, but at the moment, being able to quickly write and test code is more important.

The first test, a quick display test, drops isometric tiles in a layered display to fit a general rectangle rather than the standard diamond.  It works nicely enough but the ragged edge is just not attractive.

The second test does a couple of other things.  Firstly, it drops some monsters on the map to further test the display, as objects naturally overlap tiles and the edge of the map.  Secondly, it tries to smoothen the overall display by placing a filler border around the ragged edge.  Although it achieves what it sets out to, it still isn’t attractive.  It does nothing to hide the fact that we’re drawing with tiles (even though the tiles are way too vivid and have no smooth seaming) and also, should a building or object cover two or more tiles, we won’t be able to see any squares that are right on the edge, between the jags.

The third test takes a much more traditional viewport approach to the isometric graphic system.  It places a decorative (hopefully useful) frame around the display, neatly cutting the jagged edges away.  Because the monsters are quite large, and as such will always stand higher than any tile on the top row, there has to be a large portion of frame ‘above’ the display.  It doesn’t make sense to leave it as a simple part of the frame, or even a title as there would be far too much of it.

Because of that, I decided to use the upper part of the frame as part of the interface display.  Quite what it will show I’ve not decided, and the simple mock up is an extreme waste of screen space.  However, it will be used somehow as the overall image is quite appealing and I can use the side parts of the frame for other things as well.

It also means that the display fits perfectly into a rectangle and once I’ve decided how big the display is to be, stylesheets can be designed around it.

Just when I thought I’d decided to ignore isometric and go down the route of semi top down, I had a bit of a play…

Granted, the display isn’t very good yet, and I need to drop a border on to trim the tile excess, but it works and still holds within a rectangle.

I’m going to spend some more time playing with it and see if I can’t make it tidier, but I might be leaning back to isometric again.

Ho hum

As I am now working the site into a more presentable form, I need to make some decisions on how to display the games, particularly the ones where you control a character walking around.

It makes no sense at all to have each environment or game use completely different graphics (unless of course, they are meant to look completely different).  Not only would it require more art to be created, but it would also detract from the integration of the site as a whole.

Because of this, although the gameplay in Dungeon Escape is far simpler than in Mondestia RPG, and there isn’t the same control as in the Home environment, they should all use the same map and display system as I only have to code or fix one system.

My main concern at this point is to ensure that everything Dungeon Escape needs is coded, but I need to make sure that the system can cope with everything I need for Mondestia RPG, even though it is not being developed yet.

Graphic Style

I’m currently aiming for the semi top down approach (like the older console RPGs like Zelda, Secret of Mana, etc).  Mainly because of its practicality and use of the available space.  The display fits a rectangle perfectly and therefore makes it easy to include in an interface design.

It doesn’t give the same three dimensional feel of an isometric display, but is very clean and avoids the argument of which way is up.

Another issue with the semi top down view is only being able to see the front and top of things.   This is bound to cause some annoyance for me when designing levels, especially when I need exits in all four cardinal directions in Dungeon Escape.

Interface Practicality

Another thing that has steered me towards semi top down is the practicality of the interface for the user.  As it is essentially a grid of squares (even though large objects and people will ’spill’ over to squares behind them), selection of a target square is very easy as well, as opposed to an isometric system.

Design Implications

The final decision of whether to go for semi top down or isometric has to be reached very quickly as so many things rely on this decision.  One thing that is definite though, is that the main display interface is to be a fixed sized rectangle.  This will allow the rest of the interface to be designed around it.

I already have some semi top down graphic examples on the mondestia site (www.mondestia.com) and I need to do a couple of isometric versions to test practicality before I abandon such a view.

So far, the alpha testing of Dungeon Escape hasn’t shown any problems in gameplay, which is a relief.  The game balance still needs to be checked with some more methodical testing, but generally the game works as it is expected to.

Therefore I think it’s time to start making it look like its eventual release.  This means that I need to complete a lot of the encompassing interface and graphics, as well as a proper user registration and login system.  Not to mention making sure that the game code fits into the modular structure of the site.

When that is all done, complete with the privilege system, I will be able to open up the site for testers to come and playtest and also try to break the system to identify any potential problems before I go to open Beta.

Off the top of my head, the things I need to either complete or implement are:

Mondestia Shell

• Single user registration and login to access the site and its environments
• Avatar system
• Environment system
• Multiple language system
• Personal preferences system
• Two wildly different site styles rather than re-coloured versions
• Privilege system to restrict access to certain environments on a per user basis
• Central achievement system
• Forums
• Personal message system

Dungeon Escape Environment

• Environment for Dungeon Escape
• Hero creation
• Outfit system for heroes
• Dungeon editor
• Dungeons
• Monsters
• Items
• Achievements that are recorded in the central player record
• The game itself
• Multiplayer support framework (doesn’t need coding yet but it needs to be catered for)

Dummy Environment

Create an environment which is secure and no-one has privileges to, to see if people can access it somehow.

One thing that really annoys me on online games, especially ones where things do not have to be typed in a rush, is the quality of typed text.

I’m not saying that all messages should pass the strictest spelling and grammar checks, that would be unfair, especially to non native English speakers (although many non native English speakers write far better English than the natives).  However, people are getting lazy or just simply learning too many bad habits from others.  Sometimes to try and look ‘kewl’ or 1337 and speak in text speak.