Game Design - Online Role Playing Games - Staffordshire, Stafford, Stoke-on-Trent

Game Design - Online Role Playing Games

Web Site News

Leading Web Design Company in Staffordshire

Just my opinion, but this is the leading web design company in Staffordshire.

Leading Web Design Company in Staffordshire »

New Website Live

A new website has just been launched targetting Corporate Graphic Design.

New Website Live »

Staffordshire Companies!

I'm currently seeking Staffordshire based companies for possible partnership in online ventures - I'm interested in offering comission based websites...

Staffordshire Companies! »

Featured Pages

Web design can cover many aspects, these pages are web design articles, tutorials or university projects that I have documented online:

David J. Farmer - Staffordshire University - CM9379-3 : Route Project (2002 - 2003)

Game Design - Online Role Playing Game (RPG)

CONTENTS

INTRODUCTION

SCHEDULE

CONCEPT DOCUMENT

LITERATURE REVIEW

METHOD

DESIGN

IMPLEMENTATION

REFERENCES

APPENDIX 1: DESIGN

APPENDIX 2: IMPLEMENTATION.. 88

INTRODUCTION

Abstract

Computer games have become a common form of entertainment, since the early 1970’s with the introduction of the first successful coin-operated computer game; they have captured and used our imaginations, judgement, reflexes and intelligence. Throughout the presence of computer games the internet has continued to develop into what we see today. Game developers have used this technology to advertise, distribute and build online communities for the players, meanwhile the games themselves have used technology to allow multiplayer/multi-user gaming to take place worldwide.

Within this documentation you will read about the approach taken to develop a structure to allow a type of online interactive story telling Role Playing Game (RPG) to be played online.

Outcomes

The goal of the project is to develop a rapid prototype showing a method for allowing a type of multimedia based ‘interactive story’ to take place online. The solution must be multi-user and streamlined for its medium and target platform. More focus will be placed on the programming side of the solution than the multimedia aspect of it, as limited development time will constraint what can be produced and its functionality and abilities are more important than its aesthetics.

The problem that underlines the entire brief is that interactive stories are incredibly difficult to write; they have often been referred to as the ‘holy grail’ of multimedia (Herz J. C., 1997). So when developing a structure to allow a type of interactive story to be presented, many game playing and storytelling concepts must be taken into account.

Learning Outcomes

It is expected that while developing the artefact a good fundamental knowledge of game design, character design and project management will be learnt, along with knowledge of a server-side scripting language and relational database design.

Beneficiaries

Those who will benefit from the development of such a concept principally include game players, who will play the games created using the developed structure. It is also expected that should the prototype be released as open-source freeware, other developers can observe a method for producing this type of RPG or interactive story for use online.

Deliverables

The artefact will consist of an “interactive ‘short’ story” (written to show the potential of the programmed structure), and a bulletin board to initially allow for feedback during the designing and testing phases (to be adapted later on for use between gamers).

This type of ‘mostly’ text based game would also be suitable (and potentially successful) for use on Personnel Digital Assistants (PDA) so designs and/or a prototype will be developed showing how the original World Wide Web (WWW) version could be broken down and redesigned for use on PDA’s.

Work Involved

Research will need to be done in many areas in order to get the short story and storytelling structure to be created to a satisfactory and a highly playable/useable level. Story telling, gaming concepts and character design will need to be looked at, and research into designing for wireless technologies and online communities will need to take place.

A critical review of past and present games that show ‘interactive storytelling’ qualities will also need to be produced; these reviews will be used to show what the artefacts must take into account to be successful as a game, and show how successful or unsuccessful developers have been in the past in regards to producing an ‘interactive’ story.

The development of the prototypes ‘structure’ and interactive short story will need to take place, the bulletin board will need to be created and finally designs will need to be proposed for the PDA version of the original artefacts.

Resources

Required resources for the successful development of the artefacts include any software and hardware that will be desired and human resources which will be used for alpha and beta testing (a more list or available hardware and software, and justification for them can be found later in the method section).

SCHEDULE

The completion of the artefacts and the research report must be delivered before 16th May 2003, below is a plan of action and a log of activities have taken place.

Action Plan

Semester 1
  • To plan out the documentation and learn a few of the fundamental skills needed to produce the artefacts.
  • To complete the literature review and critical software review.
  • To begin planning the method of producing the artefacts and to begin designing them.
Semester 2
  • To develop the artefacts to a full working prototype level.
  • To test the artefacts on various platforms, various users and to get feedback.
  • To implement changes.
  • To complete the documentation.

Log

Semester One
Weeks 1-4

The selection of the topic for the project has taken place along with initial research confirming its requirements, usefulness and scale.

Nic Shulver was chosen to be the School of Computing (SOC) supervisor; on week four he gave initial advice and feedback on project ideas.

Weeks 5-10

Having heavily researched background areas associated with the projects topic the first draft of the literature review was completed along with critical reviews of software spanning across the history of computer games and related genres. Nic Shulver redirects me to Rich Macefield as SOC supervisor, Paul Lucking chosen as Art and Design supervisor (A&D).

Weeks 10-12

Introductory meetings arranged with each new supervisor, each gave their thoughts on the project, how it should be approached and what could be achieved.

Semester Two
Weeks 1-4

Meetings with both supervisors throughout the weeks have spotted significant additions to the documentation and to the artefact. The documentation needed to include much more of a ‘scoping’ section and the artefact needed to include a way to include more different types of media (especially sound).

Weeks 5-10

Unforeseen circumstances have limited the amount of time spent discussing the project with supervisors and have restricted its development time. However the project has still progressed on schedule, but not to its full potential.

Weeks 10-12

The project has developed nicely and user testing at various stages has taken place with some feedback from users applied. The unforeseen circumstances affecting the project are still present, but what has been achieved is relatively high in quality and broad in scope.

CONCEPT DOCUMENT

What?

Krig is an online interactive story telling game that includes elements of Role Playing Games (RPG’s) and puzzle games. It takes the form of a text-based adventure, similar to those that were popular in the eighties as both books and computer software, but includes several interactive multimedia areas that brings the experience of playing the game up to date and much more involving. The game forms a substantial part of a web site that is an online community for RPG players, and the site is available on various platforms, including Personal Digital Assistant’s (PDA’s).

Originally these types of game were awkward to use, due to the continuous turning of pages and rolling dice, or were restricted to being played in only one location, but with the benefit of wireless technology and the Internet they become mobile, and exceedingly easy to use. With the inclusion of multimedia elements the game becomes much more submerging, and generally will be a more memorable experience.

The story of the game is set in a post apocalyptic style world, and the quest of the player is to find and defeat the arch enemy in battle. The player will meet many unusual characters on the route that they choose, and using their luck, intelligence and judgement; they must complete a series of puzzles and win fights against any enemies they meet on their way. The story ends when the player’s character dies or the story is completed, and any players that complete the story have their names and scores listed on an area of the site.

The site also consists of an advanced bulletin board, game reviews section, and a news section, users can also send ‘ecards’ to friends to challenge them to complete the game and to join the community.

Why?

Firstly Krig uses the player’s imagination and intelligence; these are two fundamental things that many computer games fail to achieve. Secondly, RPG’s and mobile gaming are areas that have individually become increasingly popular, but there are very few examples of where the two subjects have been successfully combined, Krig bridges this gap. And finally, interactive storytelling is something that has many benefits and Krig shows how these stories can be designed successfully.

Who?

Krig is aimed at younger gamers, aged around thirteen, but is available to be played by anyone. This is because children of around this age have much better imaginations and are more willing to use them, something that Krig needs in order for the game to be successfully played. Also, with the steady decrease in the price of mobile technology, I foresee that it won’t be long before children of around this age will use PDA’s and other wireless hardware for both learning and leisure.

LITERATURE REVIEW

To solve the problem research of various principles, concepts and technologies needed to be undertaken. In this section a summary of researched areas that affect the design, functionality and behaviour of the artefacts is presented. The main artefact will be gaming structure itself, so most of this section is devoted to research into the factors that will affect it, however some research has been carried out in other areas.

Story Telling

Story telling is a traditional form of entertainment and communication, and although there is no solid evidence; it would appear that people have been telling stories for a very long time (Tannenbaum R. S., 1998). Its roots can be traced back into the very early days of human civilization where communicating life experiences to others was part of survival. As humans developed their imaginations, story telling became a way to gain power within their tribes (through lies) and a way to entertain one another. Experiential and imaginational story telling has also helped humans to communicate their reasons on why things happen, it can be held responsible for the development of myths, superstitions, rituals, morals, traditions, rules, codes, laws, religions and even gods. In short, story telling has had an incredible impact on human life since its conception and it will continue to do so as politicians, entertainers and parents use stories for, among other things, motivation, laugher and guidance respectively. Story telling is a very underrated, potentially awesome power (Hamilton D. L., n.d.) and its presence can be found in most forms of entertainment, including computer games…

Computer Games

The first computer game ever created was Spacewar; created by Steve Russell, a student at MIT in 1962, it was played on a computer the size of two refrigerators. This was the first computer to use a screen and not use punch cards, and it is interesting to note that as soon as the industry had the technology to create computer games, it did. However, it was ten years later before the first game was released that gave an indication for the things to come. The simple coin-operated Pong, took the world by storm, its simple and only rule of ‘avoid missing ball for high score’ was enough to get the ball rolling, and money began pouring into the industry (Faber L., 1998).

From these early days computer power has increased by a factor of thousands, and so has the money that is pumped into the computer games industry. The games are now much more graphical and complex, and the number of genres they cover and platforms that they are available on are constantly increasing. Computer games are no longer a novelty found in entertainment complexes and bars, but are a hobby, past-time and form of entertainment and have been for over twenty five years (Herz J. C., 1997).

Why People Play Computer Games

Game playing, as with storytelling, has a long history associated with the development of the human race. ‘Play’ itself is something that is has become associated with children learning and physical development throughout their childhood, but other than video games being the next form of traditional entertainment and education, there are many other reasons why people (not just children) play computer games (Lewinski J. S., 2000).

Many players play computer games as they provide a challenge, often associated with learning, challenges, when completed, show how the player has applied their knowledge and mental skills to achieve a goal or to win (Rouse III, R., 2001).

Games also provide a way for players to socialise with one another, and they do this in many ways. Multiplayer games for example allow players to interact through the game with one another, and they can do this head-to-head or turn-based, locally or worldwide. Games that can be played over Local Area Networks (LAN’s) or the Internet tend to have built in communication aids to encourage players to talk. But even single player games encourage social interaction; players of computer games tend to discuss the games that they play, they seek advice, talk about results, but more than likely they will be bragging about their progress (Rouse III, R., 2001).

Not all games require a social aspect to their game play in order for them to be successful, some games are designed to be a solo experience, they offer the player the chance to be entertained using an interactive medium without the need for other players and this gives the player more general game-orientated control than that of traditional forms of entertainment (Rouse III, R., 2001).

Games also allow the player to be involved within an experience that is orientated within a fantasy based environment. It is safe to say that players can take part in activities within a game that would be dangerous, anti-social or unachievable. Many game designers exploit these facts and also allow players to use their imagination and unlike a movie or a book, players get to interact within these fantasy environments (Lewinski J. S., 2000).

As with more traditional forms of entertainment users may be looking for some form of emotional experience when they play a computer game and the way in which games can express emotional feelings can be related to the goal of art (Rouse III, R., 2001). The vast majority of games encourage the user to feel excited, tense, despaired and elated, but more recent games have been aiming for more subtle emotions, but many downfalls prevent current games from conveying them (Greenfield S., 2002).

Rewards are a key concept relating to why people play computer games and these rewards come in a large variety of forms. The human need to feel victorious is one of the main primal psychological rewards, throughout history this has often been achieved through the use of physical activities, but now we are more civilised computer games support some of this urge (Lewinski J. S., 2000).

Having discussed some of the reasons why people continue to play games, there have to be reasons explaining why they began playing in the first place. Firstly it is fashionable to succeed in the art of playing computer games, and with the increase in accessibility caused due to the affordability, portability and popularity of gaming systems many new gamers are easily subjected to the video game phenomenon. It has also become a new-tradition, parents that grew up through the seventies accept that computer games are a great form of entertainment, and they will encourage their children to get involved by calling on their nostalgia.

The final thing to mention is that the computer game industry is forever evolving the games that they produce and it will continue to do so. The industry collapsed in 1977 due to the lack of variation and quality to the games that were produced, but as the specification of the hardware doubles nearly every eighteen months, games will account for their new boundaries and will never begin to get repetitive again (Herz J. C., 1997).

Role Playing Games

This highly popular genre of game combines elements of adventure and strategy, but relies more on the development and growth of characters. Conversation, strategic combat, puzzles and exploration are the key elements in virtually all RPG’s and their character development system. The storylines for these games are often non-linear and smaller side/sub quests are usually present (Saltzman M., 1999).

The roots of role playing games are in the 1970’s table top games published by the TSR Corporation, which were played with dice and cards (Herz J. C., 1997) and the Fighting Fantasy game books written by Steve Jackson and Ian Livingstone in the 1980’s (Poole S., 2000). The computerisation of these games saved the tedious setup, repetitive turning of pages, rolling of dice, movement of figures and writing of statistics. With the inclusion of graphics and other multimedia elements, the gamers became videogame players, rather than dungeon and dragon geeks (Herz J. C., 1997).

Computer based RPG’s come in a variety of forms. They originally started out as text-based adventures, where the player would navigate through and interact with a nonlinear story using a series of keyboard commands. But as the hardware of computers has increased, so has the complexity, interaction and amount of media that the games use, however the principles are still the same. Elements of RPG’s have also began to creep into other genres and have completely merged with others, for example, in the extremely popular Tomb Raider series you not only take part in a platform adventure game, but you learn about the characters history, interact with None Player Characters (NPC’s) and develop your characters skills and usefulness by collecting different objects.

RPG’s will continue to be a successful genre of computer game as their elements of fantasy and adventure are things that will always remain popular in what is already a fictional area. The only downfall to more modern RPG’s is they are slowly but surely using less of the player’s imagination and in many cases using less of their judgement.

Interactive Story Telling

This is the core concept of many RPG’s and other related genres of computer games; it is a skill that has often been described as extremely difficult, as not only does it require the skill of writing a normal story, but it requires the ‘threads’ of the interactive story to fit together seamlessly at the end. Interactive storytelling is also something that has been seen as “the holy grail” of multimedia and it is a highly sought after skill to be able to conceive how that might work effectively (Herz J.C., 1997). So how should the task be approached and what should developers be weary of?

Firstly there are different kinds of interactive story, the first being a set story that you work your way through by completing puzzles, and the second being a series of options that navigate through a map and vary the story as you progress. There are other kinds, such as a set story that allows you to go into more unessential depth in certain areas by exploring the environment, but these are less significant and by far less popular. The concept that suits the project best is the story map idea, where the player chooses their own route through the story as seen in the Steve Jackson and Ian Livingstone Fighting Fantasy books.

When it comes to writing interactive stories of this nature, there aren’t many sources of information that give advice on their physical creation, but on one web site three short passages have been written documenting the methods that three authors took when creating their own versions of the fighting fantasy stories. Most methods seem to involve the actual drawing of maps; all of the possible routes through the story on paper, using arrows and ‘nodes’; simple shapes to define options, actions and character involvement etc. They also seem to draw these maps on top of actual maps that resemble the environment that the story takes place in. Once the structure is complete, each of these nodes is assigned a number, and the passage for each is then written based on the notes on the map. This is a time consuming process but the end product should be error free and functional (AdvancedFightingFantasy.com, 2002).

Multiplayer Games

Multiplayer games originally began as having more than one controller and allowing competition to take place directly, or by allowing players to take turns on games, and although both methods are primitive, they have always been popular and increased the popularity of the game they have been present on.

The reason why multiplayer video games have always been popular is that games in general rely on an element of competition, and what can be better than competing against fellow human beings? The problem with video games where the computer is the opponent is that the computer doesn’t have intelligence (yet) and will become predictable quickly; falling from the same mistakes over and over again and never learning your strategies (Jones E., 1998).

More recently games have provided more methods of allowing multiplayer gaming; not only can you compete directly or in turns, but you can play through networks and over the internet.

Online Gaming

The first game that revolutionised the way that games are played online was ID Softwares Doom. Originally online multiplayer games were text based and played through Telnet, but Doom started off a new era, and various other game developers saw the potential of this and began to implement online gaming into their own games (Jones E., 1998).

Role playing games and war games are both genres that have extreme popularity for internet play. Due to their slow pace, lack of high speed physical control and mathematical game calculation; they don’t require fast internet connections and are therefore very accessible (Poole S., 2000).

Some of the first internet playable games were RPG’s that were based in text based Multi-User Dungeons or Multi-User Domains (MUD’s). These games were popular and played through Telnet, but they have gradually lost their appeal, as more graphical and complex online RPG’s have taken over, such as Origins Ultima Online (Saltzman M., 1999).

Online gaming as a whole has rapidly increased in popularity, this is due to the increase in games that are available to be played through the internet and the amount of games that are available on the World Wide Web. Sources predict that revenue generated through online gaming in 2004 will run into the billions, and with the further development of games consoles being connected to the internet, the trend of online gaming doesn’t look likely to stop (Mulligan J., 2001).

Wireless Gaming

Wireless technologies for mobile devices are still yet to make a big impression on the way we communicate with one another and entertain ourselves. Wireless Application Protocol (WAP) wasn’t as popular as everyone within the industry had hoped, and the development and spread of 3G is making slower progress than expected. However this area of the communications industry does hold lots of potential for mobile gaming.

Currently there are two forms of wireless games; embedded or downloaded video games and games that you can play ‘online’ through networks. The first of these two types are always available, they are within or temporarily stored on the hardware and can be played anywhere without being connected to a network. The second involves being connected to a network, and play takes place through SMS, WAP or 3G services (Game-Research.com, 2002).

Games designed for these services are at present mostly very primitive, SMS games being the simplest of all. SMS games tend to be quizzes or other kind of short text based games, they are extremely limited as to what they can achieve, and are not at present very popular, however lots of revenue can be generated through them (Zsigo K., 2002). This has caused the industry to produce more of these games, and slowly, but surely they are beginning to catch on, especially with teenagers (Fox D., 2002a).

WAP games are slightly more advanced, but are still primitive, simple games such as hangman, tic-tac-toe and basic card games are all that are available due to its only medium being text and wireless bitmap images (Game-Research.com, 2002).

Finally 3G games are at present the most advanced, simple 2D platform games, space invader type games and motor racing games are available for play through networks, but most of the available games are downloaded or installed onto the hardware for a set fee (Fox D., 2002a). These games are mostly written using either Java or BREW (Binary Runtime Environment for Wireless) when the platform is a mobile phone with 3G capabilities, or built around either PalmOS or Pocket PC 2002 languages if the platform is a PDA (Personal Digital Assistant), palmtop or ‘Smart’ phone (Fox D., 2002b). PDA’s also have Macromedia Flash capabilities, and therefore Flash based games are available on them.

Over just the past few years, mobile games have jumped boundaries that took over twenty years to pass when these games were originally created for use on standard computers or consoles, but this is more than likely because the technology is already there and the programs have already been written.

Internet and wireless gaming have opened more doors to multiplayer and multi-user games, and when these games have been developed they could hold the key to making wireless technology more popular and 3G more successful.

Common Features Of RPG’s & Adventure Games

All genres of games have common features that help to define what kind of game they are, this is no different for RPG’s and adventure games. So what should be included in these genres to make them easily definable and more popular to traditional RPG and adventure game players?

The first thing that comes into my mind which separates RPG’s and adventure games from all other genres are the rules that they dictate. Dungeons and Dragons (D&D) rules have been adapted and used in most fighting fantasy style RPG’s since their inception in 1972 by Gary Gygax and Dave Arneson. These rules have expanded and are now in their third version, they form a relatively complex structure that defines how RPG’s should be balanced and played (Loijens J., 2000).

Adventure and RPG’s both have one key aspect that is not present in most other genres; they rely on a good solid story that has quite a lot of depth being present for the character to travel through and develop within (Saltzman M., 1999). Other genres do tend to have some kind of story behind them, but it is usually nowhere near as deep or concise as the story behind an adventure or RPG.

Characters play a key role in most genres of game, but with RPG’s and adventure games they are especially important. In a good RPG players get emotionally attached to believable and unique characters that they can relate to, and are interested to see how their story unfolds (Brian, 2000a).

All genres require some kind of playing environment, but with RPG’s the environment is especially important as it reinforces the story and characters. Good RPG environments are easily explored, unique, and vary as you progress through the story; they help to keep the game interesting (Brian, 2000b).

Control of the game differs in RPG’s than from most other game genres. As the pace of the games tend to be quite slow, keyboard commands and mouse use tend to be the norm.

Retro Gaming

Retro gaming was something that was guaranteed to occur; you couldn’t possibly have that many people doing the same thing at the same time and not generate any kind of nostalgia. Also yesterday’s teenage video game players are now coming home and finding that they are ‘nine-to-five’ workers, it’s no wonder they want to grab their old consoles or computers and relive their carefree childhoods, however it was the introduction of the Internet that really put retro gaming on the map.

Not only are there retro gaming communities, and places to play old games online, but there are trading sites for the hardware and software of yesterdays. The internet is a fitting place for retro gaming as it was developed by computer programmers, and is dominated by a generation of people whose first introduction to digital multimedia was video games.

Software producers have also taken notice of the demand for retro games to become available on newer platforms and they have re-released their own software as budget titles and have compiled collections of their classic games. Emulators also play a key role in retro gaming, and as most are available for free download or distribution, this provides an easy way for gamers to play old titles on new technology (Herz, J. C., 1997).

Game Design

Since the beginning of computer games design issues have played a very important role in producing a successful game. More recently though game design concepts are something that have become broader and cover much more depth due to the complexity and scope of the games. There are many sources of information that give advice and strategies on game design, most seem to revolve around entertainment and Human Computer Interaction (HCI) factors. Below are summaries of passages that relate to the project that were written by professional game developers.

Bob Bates of Legend Entertainment (cited in Saltzman M., 1999) suggests that the most important strategies in creating an adventure/RPG game is to concentrate on entertaining the player from moment to moment and to always use what he calls ‘player empathy’.

The first of these two concepts suggests, among other things, not to force the player into performing a complex action twice, to allow the player to save their status frequently, to allow the player to skip cut scenes and most importantly prevent the player from getting bored.

‘Player empathy’ is the concept of considering the players thoughts at any time, and using them to streamline the game for maximum entertainment.

Chad Freeman of Dreamforge Entertainment (cited in Saltzman M., 1999) emphasizes on the importance of the story within the game. He points out that although the game Quake is a classic first-person shooter, Half-Life, while having similar game play, will always be better due to its great storyline.

He also recommends that work shouldn’t take place in a vacuum, feedback and advice should be given throughout the design and development process, and that games should be developed within the creator’s limitations.

Tom Hall of ION (cited in Saltzman M., 1999) Storm gives advice recommending that the player should always be taken into consideration, and that the player should be grabbed within thirty seconds. Players should always feel that they are participating in the game; they should always be having fun and within the first half minute of playing the game, they should have an idea of the ‘coolness’ of the game.

Character Design

As previously stated, one of the key areas that make RPG’s and adventure games unique are the characters that they use.

A computer game character in an RPG has several types of characteristics; how they look, how they act, and who they are. These all define what makes a character unique and fit into the games aesthetics, mechanics or story respectively. The character itself may or may not have their own personal story, some characters rely on the players own interpretation and speculation as with some games, but their presence must support the games story if there is one. Characters also form part of a games fantasy, and if interesting or heavily personalised can help the player to immerse themselves within the game (Smith H., 1999).

Character design is a unique development skill in its own right, below are summaries of documented advice that outline what makes good, suitable and interesting characters for games.

Tony Gard of Confounding Factor (cited in Saltzman M., 1999) was the designer of Lara Croft, he recommends that when creating a lead character for a video game that it should be something that you really like, and are not just happy with. He also points out that characters should iconic, simple and clear, but the most important feature of any computer game character is that the player should have respect for it. He stresses that the characters should be someone that you wouldn’t mind stepping into the shoes of; after all, that’s the whole point.

Shigeru Miyamoto of Nintendo (cited in Saltzman M., 1999) was the designer of Mario, he points out only two important factors. The first being that the character has to be fun, games should be fun, and anything that pushes this factor helps to achieve the goal. His second is that the designers of the game will not be able to properly comprehend how players will feel when they see the characters and play the game for the first time.

George Broussard of 3D Realms (cited in Saltzman M., 1999) breaks down characters into characteristics; personality, appearance, motivation, catch-phrase and name are all characteristics that help to make a distinguishable character. Most of these are fairly straight forward, but simple things such as using a catch phrase and interesting name are often overlooked and can have just as much if not more effect on making a memorable character. For example a determined, inquisitive loner, wearing a black suit and tie, working for the FBI could be one of many characters, but when he says “The truth is out there”, you know its Fox Mulder from the X-Files.

Online Communities

Online communities are something that have been around since the development of the internet, they were present before the introduction of the World Wide Web; they originally used email systems or Bulletin Board Systems (BBS) that were accessed through Telnet and the like. More recently though, online forums and bulletin boards have been created in conjunction with the World Wide Web and they are more popular due to an increase in accessibility, ease of use and more attractive appearance (mostly). Online communities are popular because they allow communication to easily take place worldwide, and allow users to socialise, discuss common interests, and to work collaboratively (Boetcher S., Duggan H. & White N., 2001). They will also continue to be popular as the increase in technology will allow the fantasy aspect of online communities to become richer and more immersive, and the entertainment value will become stronger. Online communities will continue for the near future to be a place to escape to and be whoever you want to be (Ki A. J., sited in Boetcher S., Duggan H. & White N., 2001).

This element of fantasy is why online communities nicely tie-in with RPG’s and other similar genres of computer games. Most modern online RPG’s include some form of online community, and others have highly detailed worlds where players can travel and join other ‘living’ communities while playing the game itself.

Conclusion

All of the briefly discussed concepts and design principles related to RPG’s and the like are nicely associated with creation of Krig and its accompanying online community. They show the need for software such as Krig, especially in its wireless format, and they outline that an online community related to this area of entertainment would be successful if approached in the correct way. Before the implementation or design of the project can take place, it would be good to review available software of similar natures, and to take ideas from them. Details of the reviewed items can be found on the following pages. Choosing which software to review has been difficult as not only is there so much to choose from, but as retro gaming needs to be taken into account, it would be good to spread the selections of games across the past three decades.

Zork 1: The Great Underground Empire

Produced By: Infocom
Year Released: 1980
Format: Multi-format
Description: Text Based Adventure/RPG
Cost: - (Currently Free)
Target Audience: 9+
Requirements: - (Platform based)

Initial Comments

Zork was one of the original text based role playing adventure games, there were many others, but Zork remains as one of the most popular and well regarded games of all time. The game was released on many formats in the early nineteen eighties, which increased its popularity and was one of the first games to have many sequels. The only input device required to play the game is a keyboard, which may not seem completely user friendly now, but was the only common input device on all target platforms when the game was released.

Story Telling Aspects

Originally when the game was released a booklet entitled "A complete history of the underground empire" was packaged within the box, along with some other merchandise. This booklet would have given a background on the story so far and other information that would be useful to gameplay. When the game starts you are only told that "You are standing in an open field west of a white house, with a boarded front door" and without reading the booklet, players are forced into making up the background story using their imagination and pieces of information that they pick up while playing the game. But that is what the designers of Zork planned, and they make this clear by stating "It’s like waking up inside a story" on the back of the game packaging (Infocom, n.d.). This lack of knowledge even helps to make the game more involving as it is natural for humans to feel curious, want to explore and discover things.

Game Play

The game is initially very tedious, as it takes a while to get used to the third person commands that need to be typed to navigate, browse and perform different actions, but once the commands have been learnt, control is quite straight forward and an entity does give assistance when you make mistakes.

Characters within the game are never described in great detail, but are rather classed as being a thief, troll, spirit etc. This lack of detail also occurs in the description of environments and objects in the game world, detail is only given to show functionality, areas that can be explored and areas that should be of interest; in this way it gives the player a clue as to what to do next and how to approach things. This lack of detail also allows players to use there imaginations more, and as the game didn’t have the hardware to produce highly detailed life-like images or stereo quality sound, it avoided disappointing players with low resolution images and virtually meaningless sounds.

In general Zork is a very addictive game, and its simplicity helps this. Even now there are online communities and tributes that are dedicated to the Zork series; it is a retro game that has made a great impact on all gamers that played it when it was originally released.

Design Concepts

When it comes to analysing the use of typography, digital media, designed characters, and Human Computer Interaction (HCI) factors; all things that can be associated with any recent RPG, we find that they all become mostly inapplicable. The only design matter that applies to Zork is that the structure and layout of the ‘run-time constructed’ text makes it as easy to read as possible, every other factor is more associated with the mechanics of the game.

Elements For Inclusion Within The Design Of Krig

The story throughout Zork is written in a very witty manor, and it is humorous in areas, this makes it very entertaining to read and is something that should be present in all ‘unserious’ text based games. The key concept of the use of imagination and logical thinking that Zork requires in order to be played successfully is something that must be included within the design of Krig in order to make it successful and entertaining.

Screenshots

View Image #1 View Image #2

Dungeon Master

Produced By: Faster Than Light (FTL)
Year Released: 1986
Format: Multi-format
Description:D&D Maze - RPG
Cost: - (Currently Free)
Target Audience: 9+ (Assumed)
Requirements: - (Platform based)

Initial Comments

Dungeon master was the original real-time 3D D&D RPG that was build using 2D sprites; it won numerous awards at its time of release and has many tribute web sites devoted to it. It was also one of the first games to use Mouse control as its most suitable means of input (Fontanel C., n.d.).

Story Telling Aspects

The game originally included a manual which gave an eighteen page back story on the quest; recent games generally come nowhere near to this. The back story of Dungeon Master revolves around how the characters have come to be present and why the quest to recover the ‘Firestaff’ is so important. While playing the actual game though, the story doesn’t develop in any extreme depth, it is constructed by the player’s ability to complete the mazes and puzzles they meet along the way. It is not, as such, a complete interactive story as it tends to be pretty much the same for all players, should they complete the game.

Game Play

Although the in-game story of Dungeon Master is lacking, the game was, and still is quite addictive. The graphics are very limited due to the hardware specifications of the target platforms, but the objects and characters act like icons allowing the player to use their imagination on what they would ‘actually’ look like.

The characters are, as with Zork, not described individually, but are classed as being one of many types of creature or being, and the environments are constructed in similar way; they are built using combinations of sprites, to make basic templates feel unique. This simple method kept the hardware requirements within the target platforms limitations, and allowed the game to be larger; it also looked more advanced than it actually was.

The game is also nicely balanced, and it gets progressively harder as the player travels through the dungeons and comes closer to completing the quest, this forces the player into thinking strategically and adds elements of excitement and panic.

Design Concepts

The HCI designs within Dungeon Master are very basic, but are well suited to their requirements. Navigation through the maze takes place through either the use of the keyboard arrow keys or through using the mouse to click on arrows symbolising rotation and direction. All other actions are drag and drop, for picking up and using items, or simple mouse clicks for organising the characters inventory. The inventory is the only complex area where players may initially have difficulties with control, but with some trial and error, most players should get to grips with the interface.

The graphics and sounds used within Dungeon Master are basic due to hardware limitations, but they have been used as effectively as possible and do, on balance, benefit this style of basic 3D maze RPG. The characters for example are more like icons than what we now see in modern computer games, their most important attributes are the statistics that they carry, which define strength, health, stamina and magic power etc. and are completely associated with the mechanics of the game and not the aesthetic qualities of it.

Advanced design features, such as use of typography, detailed character design, stereo sound effects and music etc. don’t really matter to a game such as Dungeon Master; its main purpose is to encourage strategic thinking and to balance the game out nicely, something which most modern games should concentrate on more.

Elements For Inclusion Within The Design Of Krig

None of the story telling methods that Dungeon Master uses apply to what Krig should include as they are all shallow and do not represent as what many see as being an interactive story, but the concept of maximising strategic and logical thinking is something that would benefit all computer games of this nature. Simple tasks used in Dungeon Master that increase logical thinking include working out the combination of switches to open a locked door and working out combinations of symbols so that the characters increase the number of spells they are capable of. Dungeons Master also uses strategic thinking by allowing users to organise their inventory so they are better suited to defeating the enemies that they are most likely to meet depending on which level they are on.

Screenshots

View Image #1 View Image #2

The Secret Adventure Of Monkey Island

Produced By: Lucas Arts
Year Released: 1990
Format: PC - CDROM/Floppy Disc
Description: Graphic Adventure/RPG (‘Point-n-click’)
Cost: -
Target Audience: 11+
Min. Requirements: 286 10 MHz Processor, 640 K RAM, VGA.

Initial Comments

Monkey Island is one of the first and greatest ‘Point-n-click’ adventure games of all time and sequels to the original are still being produced today. It is a 2D adventure game that revolves around the adventure of Guybrush Threepwood and his quest to become an almighty pirate. The game consists of a variety of long winded puzzles and short ‘instant’ puzzles which are presented by the characters or environments that are encountered throughout the game.

Story Telling Aspects

The story begins when a character walks into view and introduces himself and his quest to the player, from here the user is in control of the character and must work their way through what is a very entertaining story. The story is basically the same for all users, and is not, as such, a true interactive story. However users feel that they are involved within the story, and the story does not progress until the player has achieved all of the required tasks so that they can continue to the next section. The characters throughout the story are very interesting and humorous, and this increases the entertainment value of an already witty story.

Game Play

The story of Monkey Island is well backed up with excellent game play, making it a truly complete game. Control takes place using the mouse, clicks on the screen for navigation and selection of environment set objects, and clicks in the console for selection of actions and items in the inventory. This gives the player more knowledge of the available actions and objects, and is very simple for most users to get used to.

The graphics were cutting-edge at the time the game was released, and they still do have a nice rustic charm; just the same as when modern 3D cartoons are compared to traditional 2D hand-drawn animations. The sounds used in Monkey Island were also perfectly suited to their purposes, although only MIDI based, they add atmosphere through music and increase the amount of feedback players get from their actions with sound effects.

The puzzles were also balanced nicely, and characters or objects give constant clues on how to solve them, however, occasionally the game suffers from not making these clues totally apparent, and the player is forced into trying every combination of object, command and person or ‘environment object’ until they get a result.

Design Concepts

The game features lots of basic animation which brings the game to life, and when combined with the games interactivity, players can easily be motivated to continue playing and to experiment with different objects.

The HCI concepts used within the game not only involve the basic control of the game, as mentioned above, but include how the game makes objects in the environment selectable. It would be too obvious if the selectable or useable objects in the environment were brighter, or had a border around them and this would hamper gameplay, Monkey Island uses a textual cue; when a useable or selectable object in the environment is rolled over with the mouse a brief description of the item is used to show that it is active. This space is also used to construct the game commands from the actions panel, inventory and game environment, and is incredibly useful for such a simple concept.

The main characters within the game are all completely individual, and each has a personality, different appearance and different role to play in assisting or hampering the player’s journey. They also have unusual names, catch-phrases and attitudes, all of which were mentioned in character design advice from George Broussard (cited in Saltzman M., 1999).

Elements For Inclusion Within The Design Of Krig

Krig would benefit from a witty storyline assisted by an entertaining series of events which is what basically drives the story of Monkey Island. It would also benefit from having individual characters throughout the story as it makes Monkey Island constantly interesting; players never know who they are about to meet. These characters would also benefit from being designed in a similar way to those found in Monkey Island; basic, yet different and identifiable characters with personality massively increase the game play and general aesthetic qualities of the game.

Screenshots

View Image #1 View Image #2 View Image #3

Discworld II: Missing Presumed!!?

Produced By: Psygnosis
Year Released: 1996
Format: PC - CDROM
Description: Graphic Adventure/RPG (‘Point-n-click’)
Cost: -
Target Audience: 11+
Min. Requirements: 486 DX4 100 MHz, 16MB RAM, SVGA, Sound card.

Initial Comments

Discworld II is different from the other reviewed software up to this point as not only is it a sequel, but it is based on a book; software like this increases the players expectancy level of the game and often leads to the games downfall. Discworld II was a successful game, and although it was released six years after Monkey Island (a similar genre and style of game) it doesn’t show any major advancements in graphics, game play or story telling aspects.

Story Telling Aspects

The game itself doesn’t present any background information on the characters, but an animated sequence does show where the story begins and why. However the instruction manual supplied with the game gives details on both background story and some of the main characters which are all taken directly from the Terry Pratchett books. Throughout the game itself, the story continues as tasks are completed; it is structured in just the same was as Monkey Island, where the story will only continue when a set of criteria has been reached. Therefore Discworld II is not as such an ‘interactive story’, but the player does feel involved within the plot and feels as though they have control over the fate of the characters.

Game Play

The game does have great playability, and although players may find it tedious occasionally, due to repetitive tasks, slow progress in plot and difficult challenges, the game is humorous, cleverly written and follows a cunningly written story. The characters also increase the game play, as you never know who you’re going to meet next and what information or plot they are going to present you with.

The game play is also boosted by excellent sound effects and atmospheric music, which increase the feedback that the player gets from their actions within the game.

The puzzles and challenges are also nicely balanced, and clues are presented from characters or objects within the environment, however as with most of these games, occasionally the clues are not totally obvious and the player gets stuck until they solve the task through trial and error.

Design Concepts

The game uses lots of animation that makes the game feel like an interactive cartoon, however, there are slight bugs within the animation that make the game look slightly unprofessional.

The in-game control takes place through the use of the mouse, and although it should be simple, it does get tedious as both the right and left mouse buttons are used, along with double clicks; it is easy to get confused. Small icon filled menus are used to control character and object interactions, and although the icons are not obvious, they are easily learnt through trial and error. This method tries to replace the text based command approach completely, but fails as it doesn’t make control as easy to understand or as easy to get used to.

Characters used within Discworld II are mostly adapted directly from the books that the game is based upon, and as they were originally designed purely for storytelling purposes the characters suit this genre of game. Each character has their own name, personality, catchphrase, appearance, and when you first meet the main characters they each have there own short story to tell. This relates directly to the series of books, and keeps original readers interested as it puts fictional characters into a virtual object based world that can be explored.

Elements For Inclusion Within The Design Of Krig

There are no significant features or concepts that Discworld II uses that would significantly increase the interactive story-telling, playability or aesthetic qualities of Krig, however its attempt to reinvent a method of playing this style of game is something that could be looked into; the original text based approach was always awkward for new or younger players.

Screenshots

View Image #1 View Image #2

Images captured by British Telecommunications plc, February, 1997.
http://www.gamesdomain.com/gdreview/zones/reviews/pc/feb97/dw2_05.html

Ultima Online

Produced By: Origin
Year Released: 1997 (Original Version) | 2002 (Latest Expansion/Version)
Format: PC - CDROM & Internet Play
Description: Mass Multiplayer Online RPG (MMORPG)
Cost: Game Price, Monthly Fee & ISP Costs
Target Audience: ELSPA 3+ (11+ Assumed)
Min. Requirements: P166, 32M RAM, 550M Disk, 8x CD, 16-bit Graphics

Initial Comments

Ultima Online is one of the most highly played MMORPG’s and its roots can be traced back to early text based MMORPG’s of the eighties. It won lots of awards at the time of its original release, and continues to win them as the game is constantly updated, expanded and redesigned. It takes the form of a 2D (although now partly 3D) isometric world that can be explored, where all characters that are met, fought or challenged are other players of the game.

Story Telling Aspects

There is a back story to the game, but throughout playing the game there is no structured story or type of ‘interactive story’ that is followed. Instead the player creates their own story as they travel throughout the world and allows their character to ‘live’.

However, this type of game in itself could be seen as being a true ‘interactive story’; player and character interaction, completely personalised story, intelligent opponents and a virtually-infinite amount of possibilities, give the game more interactive storytelling qualities than most other games that claim to be ‘interactive stories’.

Game Play

Ultima has fantastic gameplay, players get addicted to the game as not only is it a fantastic game in itself, but there is so much to do and so many different characters to meet. It is a game that is easy to play, yet difficult to master; this makes players learn some of the game mechanics and explore the games functionality in order to increase their ability. In general it is a very addictive game which makes players feel involved in a huge online community and gaming environment.

The game play is also boosted by its aesthetic qualities, and atmospheric music, and while playing the game players feel they need to explore so that they can view the different types of architecture, landscape and wildlife which create the unique environments.

The game also has several sub-games; players can play chess against one another and many other types of board game or card game or other type of competitive challenge, this adds massive variation to the game and increases its playability.

Design Concepts

Due to the game being so massive in environment, player numbers and scope, the user-interface is something that has had to be well designed and consistent throughout. In short, inventory use and other similar control takes place through the use of various windows, which are accessible from one another and from clicking on objects in the environment. Character movement or action mostly takes place through use of the mouse by clicking directly on the environment, but the keyboard can also be used. Overall the interface is initially quite difficult to get used to, but after playing for a while it becomes quite obvious; the consistency and general user-friendliness helps this.
The character design used in Ultima differs from normal RPG’s as players require their character to look as unique as possible. Ultima allows the player to choose a basic race of creature, and then allows them to add detail and individuality through the use of various templates. It is also possible to create a new type of character from scratch, but most players seem to use the template system.

In general Ultima Online is well designed and is very suitable for its medium; it has been streamlined for use on the internet (through the use of universal templates) yet has kept the game environments looking unique, pleasing to the eye and mostly lag-free.

Elements For Inclusion Within The Design Of Krig

The concept of having intelligent opponents is something that needs to be looked into. When playing computer based opponents, games can become repetitive and therefore boring. However when you are competing against or collaborating with other human players, not only do you get feedback from them, but you can learn from them and entertain one another; it massively increases the amount of interaction.

Screenshots

View Image #1 View Image #2 View Image #3

Images captured by Christian Schock, December, 1997.
http://www.intelligamer.com/rpg/uo/uo.asp

METHOD

After summarising the current state of RPG’s and associated concepts, and reviewing a selection of games that have spanned across their computer based history, it is now time to discuss the design principles that will need to be included and to begin drafting up some design concepts for the artefacts that will be produced.

Initial Thoughts

The WWW version of the game will consist of the game itself and an online community; it would be good to integrate these two sections so that the interface is consistent, users only need to sign up once for full access to the entire site and the main navigation can be used to access both areas. Once the WWW version has been completed, it can be cut down for use on mobile devices, as the game will function in the same way, but will be required to be streamlined and adapted for use on various PDA’s.

The game itself, as previously mentioned, will be mostly text based, but graphical elements from the reviewed software will be taken into account, along with character design principles, HCI issues and other concepts. The key elements of any successful game seem to be the use of fun and fantasy within an environment that feels complete; this is a fundamental target for the project to reach.  

Target Audience

The game itself will be targeted at users of around the age of eleven to fifteen, however, anyone can play the game and it will be written so that it is suitable for all ages. This age tolerance gives lots of flexibility in the design of both the HCI issues and game mechanics, and as long as the game is user-friendly and game mechanics are relatively easy to understand the target audience should present no immediate problems. It is also expected that most of the players and community members will already have an interest in RPG’s and therefore will not need to be given as much information on what RPG’s are and as to what they can expect to find, however this information will be made as clear as possible to new players without discouraging already knowledgeable users.

It is expected that the target audience will be, most likely, accessing the internet through 56.6kbps modems, using Microsoft Internet Explorer 5+, have at least 800x600 resolutions with 16bit colour, and have JavaScript 1.2+ enabled according to statistics provided by TheCounter.com (2002). However the web site should be designed so that it is accessible to all users, therefore some cross-browser compatibility will need to be taken into account, along with other design features that effect accessibility.

The target audience will also require the latest version of Macromedia Flash Player to be installed within their browser. Flash player requires Microsoft Internet Explorer 4+, Netscape Navigator 4+, Mozilla 1+ or Opera 6+, this means the target audience will require a hardware specification that is suitable for any of the above browsers. Mozilla v1 requires a minimum of 233 MHz Processor and 64Mb RAM on either a Macintosh, Linux or Windows platform, other browsers require a similar specification.

The wireless version of the game will require a PDA with internet access and internet browsing software. In order for the game to be as accessible as possible through wireless devices it must be designed for some of the older PDA’s; 160x160 resolutions, use of only web safe colours and only compatible HTML tags must be taken into account.

Hardware

The required hardware for the creation and testing of the artefacts consists of hardware for both the creation of the items and a server to host them on. Currently available for the creation of the artefacts are the systems on the Staffordshire University campus, on average Pentium III 550 MHz with 128Mb RAM systems, and a home PC, a Pentium IV 1.7 GHz with 512Mb RAM. These should easily have a high enough specification to run any required software.

The server that is available to host the artefacts for testing is a Pentium III 1 GHz with 512Mb RAM, it has unlimited high-speed bandwidth and has a history of 99.99% uptime. This will run any of the pre-hypertext processors that will be required and will complete any database interactivity that is needed.

Software

The artefacts will all require to be created through the use of various software packages or programming/mark-up languages, the selection of these can have dramatic effects on the work-flow, functionality and quality of the work.

One of the most significant choices is choosing which combination of database type and server side scripting language or pre-hypertext processor that should be used. Currently Microsoft Active Server Pages (ASP), Pre-Hypertext Processor (PHP) and Allaire/Macromedia ColdFusion (CF) are the most commonly used (Lim J., 2000), with MySQL, MSSQL or MS Access databases. The best, and most suitable combination would be to use PHP and MySQL. PHP is free to use, is quick processing and is supported on virtually all platforms, whereas ColdFusion, although powerful and easy to write, is expensive and has less online user support. ASP is long winded to write, is slower, and is gradually being used less often. MySQL is the best database type to use with PHP as through testing it has been found to be quicker, and it is generally more well integrated and compatible with PHP (Lim J., 2000).

The HTML and PHP will be created using a text editor; Notepad for example, is a simple text editor that is suitable. However for the purposes of the project PHPEdit v0.6 will be used, this is because it is freeware and has several small features that are incredibly useful, for example, coloured co-ordinated text to contrast tags from other text and more than one undo history. These simple text editors are better than ‘what you see is what you get’ (WYSIWYG) editors, such as Macromedia Dreamweaver, as it gives the user more control over the code and makes it easier to integrate PHP and HTML together.

Graphics for the game and web site will be mostly created using Adobe Photoshop v6 (PS) and ‘sliced’ where needed using Macromedia Fireworks v4, however some characters will be created using MetaCreations Poser v3 and finally touched up in PS. PS is an incredibly robust tool for creating high quality images, it also has an excellent image compression feature designed for saving images for use on the internet. Fireworks is a useful tool for slicing up images for use as navigation or layout structure, it also has a ‘behaviour’ toolset to add interactivity to the slices. Poser is a simple way of creating expressive 3D characters from templates and when combined with the flexibility of PS high quality and detailed characters can be produced. These three software packages should be all that is needed to create the site, game graphics and characters.

The multimedia elements for use within the game will be created using Macromedia Flash v5 or MX. Flash has excellent compression and streaming tools for audio, and has the ability to use animated vector images. When combined with ActionScript, Flash is a relatively simple tool that can provide lots of interactivity and compressed media.

The Storyline

The storyline of the game is something which should effect the look and feel of the site and some game design concepts. It would be pointless having a massively colourful web site for a game that is based on horror or terror, a darker, more low-contrast setting would be much more appropriate. The characters, theme, typography and maybe even the mechanics of the user-interface are things that need to be designed in relation to the storyline.

The storyline of the game, as mentioned in the concept document is unique; it is based in a post-apocalyptic style world. This gives lots of flexibility within the game mechanics, character design and game features as there is no history that needs to be followed, characters that need to be included or quests that need to be set. Positives of this include that anything can happen within the game, there are few boundaries, and therefore it will be easier to include entertaining events and new challenges. However people do like ‘traditional’ events in stories, games like Monkey Island, Doom, Tekken and Max Payne would not have been successful if you didn’t get to defeat the archenemy at the end. Therefore a good game will introduce many new things, but will also include popular traditional events.

Characters

The character in the game will reinforce the storyline and fulfil their purpose as obstructions, assistants or informers to the player’s quest. Each character will look individual unless they are creature or other type of being that are identical to one another. Main characters will have a personality, unique appearance, their own motivation, and a catch-phrase and catchy name where appropriate; they will be iconic, clever and fun to interact with. The player will see the characters as they are met, they will take the form of static 3D images and information about the characters will be present in the story text, within the images or in a statistics panel about the character. However the wireless version of the game may require a slightly different approach to presenting the characters due to technical limitations.

Themes

The entire look and feel of the site and game will reflect the storyline; colour schemes, icons, typography, layout and site structure will all assist in reinforcing the storyline and cause no confliction between playing the game and using the rest of the site. RPG’s always have themed features that relate to the game, for example, Discworld II used a jesters head to symbolise ‘to talk jokingly’ to other characters, and this suited the style of game and witty storyline that Discworld II uses. These themed features must also be used within the design and functionality of the artefacts; it will assure users that they are participating within a RPG.

Typography

The use of typography is an essential part in boosting the aesthetics of the site, and the ‘emotion’ and mechanics of the game. With advanced typography, the level of perception goes beyond simple recognition of shapes used within strings of two-dimensional letterforms; words have two meanings, the word image and the typographic image created using its holistic visual manifestation (Bellantoni J. & Woolman M., 1999). Therefore within the RPG the design based typography used should cause no confusion between its look and the storyline, however the function based type should serve its purpose more than its need to increase the aesthetics.

The use of typography within the wireless design will also be limited due to technical constraints; however, some will still be used where necessary.

Human Computer Interaction Issues

As the prototype that is to be produced is a game that takes the form of a web site there are lots of Human Computer Interaction (HCI) issues that need to be discussed. Games themselves tend to require individual interfaces regarding their design, whereas web sites tend to be designed following set structures, layouts and universal interface design concepts, such as the underlining of hypertext.

When designing an interface for a game it is important to remember that the player of the game could be looking at the game for hours, so the screen layout must be aesthetically pleasing. Vital information must also be easy to get at and players should roughly understand what is going on at a glance. Game genres also have certain conventions that apply to them, and if they work and are liked, it is best not to change them (Bates B., 2001).

The mouse is a good input device to use within games, as it is easy to use, accurate and virtually always available on the Personal Computer (PC) platform. Using the mouse makes games very easy to jump into, since they minimise the amount of time players spend learning and adapting to controls (Rouse III, R., 2001).

In general, computer game interfaces work best when they do not look sterile and business like, but when designing more aesthetic interfaces it is important to consider if the design takes away the players ability to understand the functionality. A common design mistake is to try and include too much detail or too many commands within a games interface, the balance between functionality and complexity must be weighed up (Rouse III, R., 2001). The more familiar the interface is to both experienced and inexperienced gamers the better (Garriot R., cited in Saltzman M., 1999).

Web interfaces tend to orientate around navigational aids as primarily navigation is their main purpose, to travel from page to page is what ‘surfing’ the web is all about. They tend to be designed using less original, less experimental and more conventional ideas unlike game interfaces which strongly depend on their genre.

As the web lacks the physicality of the real world, exact locations are often not seen as being really important; a user may be more concerned about their available destinations and general sense on how to get where they are going (Powell T. A., 2000).

When designing a game for use on the web concepts from both types of interface need to be taken into account. For example Powell (2000) suggests that when people navigate through the WWW, they often ask the following primary questions: “Where am I?”, “Where can I go?” and “How do I get to there?” along with many secondary ones, including “How long will it take to get there?”. While it is essential to try and answer these questions while designing a conventional web site, the prototype doesn’t really want the user know how to get ‘there’ (to the end) or how long it is going to take, the user needs to figure it out and doesn’t want to see the game being ‘given away’. However the player should know where they are, although not precisely, and know what options they have before them.

Another common web user question identified by Powell (2000) is “Have I been here before?”, and although this may not immediately be necessary for the player to know, as they may not get the opportunity to revisit pages during their experience with the prototype, it is something that would need to be accounted for in a more heavily developed version. Alternative story text would be required to inform the player that they have revisited the page.

The site structure of the prototype that will be developed will also break many design rules that many experts have proposed for use within conventional web sites. Kentie (1997) explains that site structures shouldn’t be too deep or too wide, but in the case of the prototype it will be both deep and wide to allow for the story to be as interactive and deep as possible. The structure will also not follow a discernable structure, such as a linear, grid or hierarchy, but it will follow what Powell (2000) describes as ‘pure web’, see diagram below. A ‘pure web’ structure can be found difficult to use because it lacks spatial orientation and although the users destination can be found quickly if the correct choice is made, often they will choose the incorrect route. Therefore is the ideal structure for the prototype, even though it would more than likely be unsuitable for use on a conventional web site, it will benefit the prototype by hopefully making players think less about where they could be and more about where they can go.


Powell T. A. (2000)

However it is worth mentioning that prototypes site structure is ‘virtual’, players will not realise that they are actually revisiting the same page over and over again, and the data that is displayed will be called from a database. If the player was to draw what they think the site structure was as they progressed through the RPG, what they would have actually drawn a ‘pure web’ representing a list of relationships between records in the database. In this way other game mechanics will also need to be hidden.

Landmarks are again something that are often used within web site navigation. According to Powell (2000) they can be effectively used to symbolically reference progress through a web sites structure, to help users to memorise visited locations and to help users to feel more orientated. Within the prototype landmarks can be used in all of these ways to aid the player, but can also be used while writing the story to help the author remain in control of the script.

It has been decided that the interface for the entire site will be designed over three consistent layers; site navigation, area navigation and tool/functionality use.

Site navigation will give access to the different areas of the site, for example, access to the game, forum, links page and member directory etc. It will be located in a prime position, and be distinctive and very easy to use. It will probably take the form of graphic based rollovers at the top of the page.

Area navigation will be related to a specific area of the site, for example, accessing areas of the forum, or a certain post within the forum. These links or buttons will be located in a secondary position, but will again be distinctive and easy to use. They will probably take the form of colour co-ordinated text based links, with or without accompanying icons.

The third layer will be related to a task within an area, for example, replying to a post on the forum, viewing the next ten posts or controlling the actual game. This third layer of interface will be less individual than the others, as it covers much more functionality and will not be found in one certain location, but it will yet again be as distinctive as possible and easy to use. It will probably take the form of colour co-ordinated text based links, buttons and icons and will be consistent only for its particular function.

Yet again the interface of the wireless version will follow as many of the concepts above, however technical constraints will still limit the interface design.

The discussed interface design should increase the user’s ability to use the solution as their cognitive models will be quickly created and/or adapted through the consistency of the interface and its familiarity with the user’s previous knowledge (through the use of conventional design principles).

An experienced user of the prototype would also be able to use part of what Barfield (1993) describes as ‘muscle memory’ among other user models. It is hoped that instead of the user interpreting the interface and weighing up their available interactions and how to use them, they would just browse the page and use the interface without direct thought on how it works, how the mouse functions or where the cursor is.

Minimum Expectations

There are minimum expectations that must be met in order for the game to be successful, useable, and to show off its possibilities of a complete game. It will be designed to be completely useable, but due to limitations, mainly time restrictions, it may take the form of several prototypes.

The game must be playable, display how its advanced functions work, follow a story map, and include characters, challenges and puzzles. Its accompanying community must reflect the storyline, be as functional as possible and its design must be integrated with the game. Finally the wireless version of the game must show how the original version can be cut down for access through PDA’s.

The minimum game features that need to be present include the ability for players to be able navigate from page to page, and to pick up and use items. However it is expected that many more game features will be built into the prototype so that it truly shows more of its potential.

Limitations

The biggest limitation to the creation of the artefacts is the time constraints; in time anything is possible, but with only a relatively short amount of production time (100 hours approximately) not everything can be achieved. This lack of time also limits the amount of new software or programming languages that can be learnt, but fortunately most of the software is commonly used and knowledge of it has already been gained.

The most significant limitation to the actual design of the artefacts are the mediums that they are being designed for. Designing for the internet has always had limitations attached to it; download time, cross browser compatibility, colour depth and resolution etc. have always caused problems and when designing for PDA, even more limitations are attached.

DESIGN

After discussing some of the methodologies that will be taken, and discussing some of the design concepts, it is now time to plan out the design of the artefacts in a practical manor. In the following section are passages discussing design documents; outlining their purpose, features and functionality.

Structure

The design for the underlying structure has been represented through the use of a flowchart (see appendix 1 for flowchart). It can be seen that there are two main areas; the presentation of the ‘game’ page, and the updating of the players status before they are redirected back to their next page (which is actually the same page again, but with different data displayed). These two sections could be combined to only one PHP document, but for the sake of error trapping, and ease of programming they will span across two.

It is also worth mentioning that a vast amount of the data held within the database will need to be prepared before it is ready for presentation or the updating of the players record. This will mostly include the concatenation of strings, which will form URL’s and paths for filenames, and simple mathematical formulas to calculate variable values.

Database

The MySQL database will need to have four tables within it, holding data about the pages, items, characters and player details and status. In order for the game to work ‘multi-user’, all details that need to be stored relating to a single players actual history of game play will be held within the players table. All other tables will not change from player to player. This multiplayer aspect will increase the number of relationships within the database, and the database must be designed to allow it to work for an unspecified scale of ‘interactive’ story.

The structure has been designed alongside ideas relating to the functionality and programming methods of the game, it will more than likely be expanded during development (see appendix 1 for schema of database).

The database schema is not a ‘pure’ relational database. If entity relationship diagrams were to be drawn there would be "many to many" relationships between the ‘Page’ table and the ‘Items’ table and between the ‘Player’ and ‘Items’ table, and in any ‘pure’ relational database, these would not be present. This has been caused by using arrays of integers (secondary keys) separated by commas held within single strings instead of a using separate tables called "Page-Items" or "Player-Items" which would hold only foreign keys to relate the tables without using any "many to many" relationships.

‘Pure’ relational databases tend to be used to reduce duplicated data, to decrease querying time and to reduce the amount of programming within any application that uses the database. However in this case, after much thought, it is expected that less data will be present within the database, fewer lines of PHP will need to be written to retrieve the data, and the speed at which all of the queries will be completed will be generally quicker due to the removal of several tables.

Pseudo Code

A rough idea for how the basic game structure can be programmed has been represented using pseudo code; it is worth mentioning that initial ideas will be heavily expanded upon during the development process (see appendix 1 for pseudo code).

Both the pseudo code and the flowchart do not show how the players will have the ability to pick up items. But they do show how the navigation from page to page takes place and how the player’s statistics are changed as they access a new page, this is the more significant part of the game structure. How players pick up items will be built into this basic structure.

Snippets

The development of the prototype will make use of many PHP and JavaScript functions, however, having thought about the structure of the database and the structure of the code, the following ‘snippets’ will be used once adapted.

The conversion of a list of integers held within a string separated by commas into an array using PHP. This will be used to loop through item lists etc.

$string = "1,2,3,4,5,6,7";
$stringarray = explode(',',$string);

The removal of one integer from a list of integers held within a string separated by commas using PHP. This will be used to remove items when used.

// "start" and "end" included within "string" to place commas on either side of each integer.

$string = "start,1,2,3,4,5,6,7,end";
$toremove = "7";
$newstring = str_replace("," . $toremove . ",","",$string);

The identification of one integer placed in a list of integers held within a string separated by commas using PHP. This will be used to check if the player has a certain item.

$string = "start,1,2,3,4,5,6,7,end";
$tocheck = "3";
$got = strpos($string, ",$tocheck,");
// $got equals "false" it not present.

The addition of an item to the string of separated integers while using the "start" and "end" values.

$toadd = "8"
$string = "start,1,2,3,4,5,6,7,end";
$stringarray = explode(',',$string);
$noofints = count($stringarray);
$stringarray[$noofints - 1] = "$toadd";
$string = implode(',',$stringarray) . ",end";
// $string now equals "start,1,2,3,4,5,6,7,8,end"

The opening of a pop-up window for the display of images using a ‘reusable’ piece of JavaScript.

// The JavaScript function.
function openWin(sImg, iWidth, iHeight)
{
window.open('' + sImg, 'the_window', "width=" + iWidth + ",height=" + iHeight + ",resizable=yes,scrollbars=no");
}

// The HTML
<a href="javascript:openWin(‘filename’, '300', '300');">link</a>

The refreshing of a parent window on the access of a pop-up window using JavaScript.

window.onload=function(){opener.location.reload()}

Layouts

The layouts of the game display (game.php) will always depend on the data within the current page record page (if the data is not present, no HTML for it will be written); simple diagrams show how the layouts are structured (see appendix 1 for sample layout diagrams).

Media Elements

As mentioned in the method section, it has been decided that heavily interactive multimedia elements, will be built using Macromedia Flash. In order for the elements to integrate with the game, variables will be required to be embedded within the ".swf" movie clips. These embedded variables will include the player’s statistics, the page options and any character statistics.

For the prototype only a limited amount of time will be spent developing media elements, but it is hoped that the few examples that will be present will show how Flash elements could be integrated into the story telling structure.

Potential uses of Flash within the structure would include player to character interaction, puzzles and games etc.

Sample Story

As limited development time governs the time that can be spent writing the story, it has been decided that there will be no back-story to the game, even though this would be desirable in the full version. Instead the story that will be used will be short, and its main purpose will be to show the potential of the game structure instead of being primarily written to entertain. However it will be based around the original briefly described story ideas and the characters and objects will more than likely be reused in the final fully developed version.

Colour Schemes, Fonts & Text Size

Colour can be effectively used if implemented carefully and conservatively; emphasizing and deemphasising text, relating separated fields of data together, identifying and categorising information, and assisting the user in their searches for information, are just a few examples of the many uses of colour (Galitz, 1981 sited in Brown C. M., 1999).

CSS style sheets will be used to control the format of the text and hypertext throughout the entire site, reinforcing the view of Brown (1999) who suggests that colours should be defined and consistently used and formatting should be universal. It is crucially important that the text on all pages is extremely easy to read, especially when regarding the story text.

Background colours will all suggest a dusty, drab, deserted and murky kind of environment, but they will be light enough for black text to contrast upon. This should massively increase the atmosphere created just though using colours, and with some abstract images that reflect exploration, it should give users an idea of what the site is about before they are actually required to read anything.

Using a little experimentation it has been decided that all HTML written text will be of the Arial font, as not only is it a system/device font but its characters are all clear and it is an easily readable typeface. Non-system fonts will be used for headings, ‘header’ navigation and the title of “Krig” (sizes will be chose at the time of implementation) (see appendix 1 for font range).

Characters

Characters have been designed that will be used throughout the sample story, it is intended that they will be adapted and reused in the final, fully developed version along with many others (see appendix 1 for character design sheets).

Bulletin Board

The main purpose of the bulletin board will initially be to get centralised feedback on the design idea, but it needs to be designed to allow easy adaptation and expansion so it can be used in the future as a forum for game players of the fully developed version of the prototype.

As this is a secondary part of the project, no designs for it will be discussed; however the bullet-in board will need to have:

  1. The ability for users to add new posts.
  2. The ability for users to reply to posts.
  3. Various categories for posts to be placed in.

Why The Design Would Work

The design would meet the brief as it reaches all of the minimum expectations; player’s can move from page to page, through a story map and they can pick up and use items. Player’s statistics can also be changed as they travel through the story map, and it allows for the inclusion of Flash based media elements. Also target page options can be limited by looking at the player’s statistics.

However it was previously mentioned that these minimum expectations would be expanded upon. It is hoped that the prototype would also allow:

  1. Limitations to be placed on the number of items that a player could carry.
  2. The player to drop items, and to pick these items back up.
  3. The players to revisit pages, and see alternative text if appropriate.

These expansions would allow more player interaction to take place, and make the game more individual to each player through increasing the number of options that could be explored. Limitations in the number of items that a player could carry would also make the player think more strategically, and adds yet another twist to their journey.

Conclusion

It is expected that one hundred hours will be required to develop a prototype advanced enough to display the potential of the designed structure and to develop the sample story to use for initial feedback that can be posted on a simple, expandable bulletin board.

After this time it should be possible to see if there is a future for games similar to the prototype through reading the feedback and viewing how far people have progressed through the sample story.

Designs for the wireless (PDA) version of the prototype will follow the completion of the development stage, as in short, the wireless version of the prototype will an adapted version of the WWW version.

IMPLEMENTATION

According to Bates (2001) the best development model for most new games is rapid iterative prototyping, insights show the prototype towards its final stages of development (see appendix 2). The latest version of the prototype can be found at http://www.davidjohnfarmer.me.uk/krig/home.php

Each different ‘page’ shown during the play of the game varies in appearance depending on data held within the database (see appendix 2 for examples). A commented schema of the database shows how a records value can affect the layout of the relevant ‘page’ and the functionality and use of each field (see appendix 2 for the commented schema of the database).

Each of the page records within the ‘page’ table are interlinked though the specified options (foreign keys). The story map shows how the player can progress through the sample stories structure (see appendix 2 for the story map).

The prototype at this time towards its final stage of development has reached around two thousand lines of PHP; the main documents are game.php (the games visual page) and game2.php (the main update page), most other sections of the game used adapted structures that were used within these pages. These two main pages follow extended versions of the pseudo code drafted in the design section and have been well commented and structured (see appendix 2 for code examples).

RESULTS

The Results Of Initial Alpha Testing

At the alpha testing stage the prototype was fairly basic; a typical player had the ability to explore from page to page and to pick up items, player statistics could also be updated, and items could be removed on access of a new page. The visual design of the site was also limited, the main navigation was fairly complete, but no images were used within the actual structure of the sample game.

General feedback and testing was requested from known experienced gamers and from users of various online bulletin boards, communication took place through various means, but not through the use of this projects forum as it had not yet been developed.

When concerning the actual structure of the game, most users liked the style of game, many commented on how it was similar to older games, such as Zork and Fighting Fantasy game books. However they could see that it was limited, and they all strongly suggested increasing the interaction through being able to do more with items, and being able to revisit locations.

Having discussed the database design with an experienced database designer, he had various things to say. Firstly he strongly disliked the use of arrays within the tables; as he was very much a "purist" in regards to the structure of relational databases; he disliked the many-to-many relationships that were present. After a long discussion it was decided to keep the database the same, but to consider rebuilding the database once the prototype was complete.

Most users appreciated the design of the navigation, it was often commented on as being "neat, simple and easy" which can never be a negative thing. Comments were also made on the colours and typography, they were all generally positive, however some disliked the use of uppercase letters within the navigation.

Other comments or pieces of advice that were given included the use of refreshing the main page on the collection of an item, as it would show the item immediately within the players inventory, and the use of a divide to separate the story text from the players inventory.

Conclusions

Although this initial alpha testing was brief, and aimed at knowledgeable users of the Internet and experienced game players some interesting comments were made and potential problems found.

A suggestion that was instantly implemented was the refreshing of the main page when an item is collected. This worked well, but required items that the player had already picked up to not be shown on the refresh so the player couldn’t try and pick up the item again.

Most other suggestions will be developed over time, or were to be developed anyway, however some will be left until after beta testing to see if there purpose is sought after by the target audience.

The Results Of The Beta Testing Stage

At this stage the prototype was fairly complete; users now had the ability to drop and pick up items, they could revisit pages and examples were present to show how the structure could integrate with Flash based media. The sample story was also fully written, however it didn’t fully show the potential of the structure, and therefore may need rewriting for final user-testing, should there be enough time.

More game orientated feedback was required from sample users that had less knowledge of the Internet than that of the alpha testers, but still had a keen interest in RPG’s. Half of these beta testers were aged sixteen and under, the other half were what could be classed as retro gamers, as they had knowledge of early games such as Advent and Zork.

Feedback was mostly given on a one to one basis as it was important to see the speed at which players progressed through the sample story, and to see if they encountered any problems that probably would have gone unaccounted for should no direct observation have taken place.

Watching these sample users progress through the software reinforced some design concepts but encouraged the redesign of others. A good example of this was the fact that each block of story text, of which there were three, was limited to two-hundred and fifty characters in length. Players of the game appreciated not having to read through more text than this before having to make a choice of a target page, and due to limited data being retrieved, the speed of the database was also improved. The only downfall to this was that when writing the story, these limitations often narrowed the amount of descriptive text that could have been used.

It was also good to see thought and logic being applied to the game as players reached certain locations. For example when they were asked if they would like to buy certain items, they would often weigh up the potential benefits of the item and consider how it could be used later in their journey. This reinforced one of the key principles that the game was to achieve, the continuous use of intelligence and imagination.

Negative observations that were made included the fact that the sample story strongly limited the interactions that the players could participate in, and for the sake of the players experiencing more of the gaming concepts they occasionally were asked to follow a certain path through the story map. If time is found a new sample story will need to be written.

One problem was also found during this beta testing stage; if a user has JavaScript pop-up windows disabled they will not be able to pick up or drop items. It has been decided that, for now, a message will be show in the site requirements on the main page, however for the fully developed version, it could be better to allow item interaction to take place from the one main page. According to statistics provided by thecounter.com (2003) only 9% of a recorded 355,292,543 visits throughout the month of March 2003 had JavaScript disabled or it was found to be not present. It is worth mentioning here that sites monitored by the thecounter.com are often associated with experienced Internet users, and therefore the actual percentage of JavaScript disabled or not-present browsers population using the Internet would be less as most typical users would have JavaScript enabled, and be using more modern browsers with JavaScript present.

No significant comments were made by these sample users regarding the structure of the game, however they did comment on how easy the game was to use. All users liked the fact that the target page options became easier to read once the mouse had rolled over them. None of the users had problems reading any of the text and each thought the layouts were clear and straightforward.

Many comments were made regarding the in-game graphics, all players thought that the characters were “cool” and they appreciated the use of thumbnails to represent items. They all would have liked to see more images reinforcing the story text though, but due to a limited development time, only a few sample images were used on the initial page to show that they could be present.

An interesting comment that was made by one of the players was that they would have liked to have seen the characters talking. This could be done using the prototypes ability to use Flash based media within the storytelling structure, and is definitely something that could be looked into should the prototype be developed further.

The Flash based media that was present at this stage included a fighting console, and a simple basic puzzle that users could interact with. It was generally accepted that the users would have liked to have seen more interactive puzzles within the sample story; this again is something that would be present within a fully developed version, as at present most of the limited development time has been applied to the prototype.

Conclusions

Although this beta testing stage has only had feedback from a limited number of people (ten), it was easy to see that if experience game players (retro gamers) or younger game players with an interest in RPG’s were to truly enjoy playing a game developed from this prototype it would need to be much more media rich. However the prototypes structure does allow for Flash based media to be included within the story, and as this software is currently non-commercial what has been achieved is credible.

The only changes that will be made to the prototype for the next stage of testing revolve around slight alterations to the HTML to make it more cross-browser compatible and to remove any unnecessary code within the PHP structure.

The Results Of The Final Testing Stage

At this stage the prototype was virtually complete; however the sample story was still constrained due to short development time and only a limited number of images were being used to reinforce descriptive text on the pages.

General feedback was required from anyone willing to play the game, and feedback took place through the use of the bulletin board developed to accompany the prototype, and through occasional direct conversation. It was chosen to keep the feedback anonymous where possible, as should the prototype be developed further the players of the game would not be known.

The URL for the prototype was posted on various bulletin boards across the Internet that discussed a large range of topics, it was also forwarded through email and asked to be passed around, and various people were also asked to play the prototype through conversations on various Internet Relay Chat (IRC) rooms.

Many comments were made regarding the game itself, the most popular or significant comments revolved around the initial character set-up, the use of an enhanced item inventory, the use of media and the fact that there was no restart option.

In general players would have liked to have seen more individuality to the character that they control, at present a players character only defining feature is its name. Players would have liked to have seen an initial character set-up routine where they customise their character, or choose from a list of predefined characters. A good method increasing individuality would be to have an option where the player can upload an avatar, and then be given a limited amount of gold where they can equip their character through travelling through a small market or armoury at the very beginning. This would also be a good place to introduce the player’s quest, and some back-story to the full game. This is certainly something that would be included in a fully developed version of the prototype and PHP easily allows images to be uploaded and with more development to be automatically edited.

Many users also compared the prototype to games that they had played in the past, and although the medium of the WWW has more limitations than that of the CDROM for example, there are concepts that can be applied. One user suggested that players should have the ability to combine items together to form new items (Zork style command: “Use item with item.”) and this would be very advantageous. Implementing this would cause and increase in player interaction and players would need to apply more logic throughout the game. This is certainly something that would be applied should the prototype be developed further.

As mentioned in beta testing players generally would have liked to see more Flash based media, and without going into depth on this subject again, it has to be said that this would also be implemented in a final version of the game as this reinforced feedback that was given earlier.

The biggest complaint from most of the players was that once they had died there was no restart option. This was done for a variety of reasons; firstly it encouraged the players to give feedback, as they would obviously be peeved with not being able to restart. And although a restart option would be present in a fully developed version, it prevented the players from using trial and error to complete only a short story, if they are aware that they must complete the game straight away it is likely that they would apply more thought to their actions.

In general users found no problems with using the software; however one user suggested using an image border around image based hyperlinks to increase the visual identification of the available interaction. This idea was experimented with during earlier development, but the visual complexity of the pages was a distraction with this applied when reading the main story text.

Feedback from users often mentioned the story itself, when users were asked if they liked the story, most comments were positive and mentioned the way that humorous events made the game more memorable and interesting. However it is also worth noting that most users also were disappointed with limited plot and scope of the sample story, a fully developed game would need to cover much more scope and have more depth.

Users also suggested having a way for players to interact with one another while within the game and although this was something that was earlier thought to be a necessity, the prototype shows no development for this. It would be beneficial if a full developed version of the site had a sub-game attached to the forum, where players could maybe fight against one another. But as far as the main game goes, this was not seen to be required to present the abilities of the prototype at this relatively early stage.

Conclusions

Although the amount of feedback that was given was much less than expected it was obvious to see that most players enjoyed certain aspects of the sample game, but disliked some others. A fully developed interactive story built using a slightly more advanced version of the underlying PHP structure should take into account all of the relevant applicable feedback and therefore generally boost positive opinions and decrease negative ones.

Having spoken to several of the final testers about the possibility of developing this structure for use on PDA’s many commented on how playing this style of game wirelessly is beneficial. During one discussion it was decided that this genre of game is very suitable to play ‘on the move’, due to the low-paced nature of the game, and the limited input players can frequently temporarily or permanently stop playing the game as their status is automatically saved.

PDA DESIGNS

Now that is has been deemed that converting the game structure for use on PDA’s is worthwhile it is time to discuss and plan how the design would need to be adapted for its new platform. Hardware limitations discussed in the method section of this documentation need to be taken into account.

The WWW version of the prototype heavily relied on pop-up windows; however a fully developed version would be adapted to allow all interaction to take place within one window. This feature would have to be applied to the PDA version, as the limited screen size would make using the pop-up windows extremely awkward and tedious for the user.

Other than taking the limited screen space into account, some of the HTML tags will need to be removed and the structure of the pages adapted. Most PDA browsers support HTML v3.2, and this restricts use of some HTML tags that can be used for most recent browsers, other rendering differences will also need to be taken into account. A good example of an incompatibility between designing for PDA and the WWW is that form submit buttons need to be changed so that they are constructed as normal form buttons with a JavaScript submit function, as apposed to using a standard form submit button (Reichley K., 2001).

The use of colour will also need to be taken into account; older PDA’s are either greyscale, with sixteen different shades, or colour, using the web safe colour palette, whereas modern PDA’s can have up to true-colour capabilities (Ramos A., 2000). For true-colour raster based images this is no major problem as they can be compressed as dithered web-safe GIF images and they should appear pretty much the same as the originals even though they now use many less colours. However colours mentioned throughout the HTML must be web-safe to ensure that the prototypes appearance is the same in all colour supporting PDA’s and that when converted to greyscale there is enough contrast to make everything visible.

The PDA version may also require alternative versions of Flash media based pages, as the vast majority of older PDA’s do not have Macromedia Flash Player support. This is something that would need to be concentrated on during a further development stage of the PDA version; it may require an alternative story to be written that doesn’t require the need for Flash based media.

Using images as examples, rough designs have been created to show how the prototypes interface, layout and colours would be adapted for use on the PDA platform. The images have been based on a PDA with a resolution of 160x160, such as relatively early versions of the Palm Pilot (see appendix 2 for PDA designs).

Notes

From the designs you can see that various data that was originally included on each page of the WWW version would now been included on a separate pages to reduce the length and complexity of the main ‘in game’ page. Content that would be found includes the player’s item lists (inventory), the character profile, and item descriptions. Using Design Space Analysis (DSA) developed by McLean of Xerox Labs, it was possible to weigh up which design options were most suitable (see appendix 2 for sample Question Option Criteria (QOC) diagrams).

The main site navigation has also been changed; the only hyperlink that is present on each page that goes to a location not related to the game page is the ‘home’ hyperlink, all other areas of the site would be then linked to from here.

The final change is how the players statistic would be presented, the space they would consume has been cut-down through using the single letters ‘H’, ’L’, ’S’ and ’M’ to represent the words ‘Health’, ‘Luck’, ‘Magic’ and ‘Strength’.

Conclusion

These designs show how the structure of the prototype could easily be converted for use on PDA platforms. They show how all of the original functionality could be maintained even though technical limitations would be present.

The benefits of the game built for these PDA platforms are numerous, but in short, the most significant advantage is the ability to play a computer game with no difficulties on a platform that has, by default, inadequate input and key hardware limitations.

CONCLUSION

Having finished the process of designing a RPG for use on the WWW and implementing a rapid prototype, there are clear and distinctive conclusions that can be made regarding the prototypes abilities and the future of similar styled games.

Although the sample story doesn’t display the prototypes programmed functionality too well, it is possible to do the following things while designing a story for use within the structure with various automatic validation routines already present:

  1. Allow players to navigate from page to page through a story map.
  2. Limit the available target page options to the players through the use of criteria that look at the player’s statistics or items.
  3. Change the player’s statistics as they access a new page.
  4. Allow the players to pick up or buy a limited number of items.
  5. Allow the players to drop items that they have picked up, and pick them back up again if they return to the same place.
  6. Change the player’s statistics as they pick up items.
  7. Remove items as players access a new page.
  8. Allow the players to sell items through combining points 2, 3 & 7.
  9. Allow players to return to the same page and view a different ‘story text’.
  10. Display a character profile alongside story text.
  11. Display Flash based media with embedded variables for use in many ways.
  12. Stream background sound through the use of a pop-up window that can be closed or replaced automatically.
  13. Include images on the pages to make the game more graphical.
  14. Automatically clear the player’s arrays at ‘flush points’ to keep the script processing quickly.

With this functionality it is possible to produce an ‘interactive’ story or RPG for use on the WWW that has similarities to classic games such as Zork 1: The Great Underground Empire and the Fighting Fantasy game books by Steve Jackson & Ian Livingstone. However it is possible to achieve a much more multimedia based experience than these two examples. In general the majority of the user feedback was positive, many users commented on how they would like to see a fully developed version of the prototype, but it has to be said that the sample story limited the amount of play within the game. A more demanding sample story would have boosted the level of ‘play’ within the prototype, but limited development time restricted the time that was spent making changes and adapting the sample story.

Limited development time is a reason behind why many games are designed ‘the way that they are’. Zork I for example was ‘The Great Underground Empire’ because if everything is dark, less descriptive text is required and, in a way, the black background and white text represented the darkness of the environment. Dungeon master was created using a series of templates that built the three dimensional environment, and this saved lots of development time. The prototype has been developed to quite a distant point considering the short development time, but in order to complete authoring an entire game with a large and deep interactive story using the structure it would take quite some time.

The prototype succeeds in its gaming objectives; the use of player intellect and imagination is key to successfully playing and enjoying the game. It also meets all of its minimum expectations as defined in the method section, and improves on these through its increase in programmed features. It also has a nice retro aspect to the game play that many testers welcomed.

While developing the prototype it became apparent that it could be used for training and educational purposes. For example, an interactive story or RPG that taught youngsters fundamentals in business terminology could be done by basing a story on the players quest to get rich quick by buying and selling items in a market place. Obviously the prototype would need adapting slightly, but this could easily be done and the prototype itself would become a means for presenting edutainment.

Other Problems

Throughout the development of the prototype other problems also evolved or just appeared that weren’t related to the main problem of development time. The most significant of these other problems was that the programmed PHP structure quickly got out-of-hand, and although it was structured well and well commented, it was very easy to get lost amongst the code especially when several ‘if’ statements span across most of their document and only the indentation can be used to relate the start and end of each. This problem could have been solved by using a text editor that had the built in functionality to highlight both the beginning and end of statements, functions and related characters even when they span across the visible portions of the document governed by screen space.

Another tedious problem was that PHP was not installed on any of the machines that were being used to write the documents on, each time new code needed to be tested, it needed to be uploaded to the server. Difficulties in installing the PHP processor on the available standalone computer cased this, and should the prototype get developed further it is a problem that would need to be fixed.

An unforeseen problem that was greatly unexpected was that the number of users testing the software and leaving feedback during the final user-testing phase was much less than expected. Although the comments that were left on the bulletin board were mostly descriptive and beneficial, it would have been much better to have more feedback. In future testing and feedback sessions, should they be required, an alternative approach of getting people to play the game would be needed, maybe through the use of some kind of virtual reward for use within the game that they receive when they signup, play and leave comments.

The most unexpected problem encountered was that when it came to adapting the prototype for use on PDA’s, there were very few tutorials or guidelines available on the Internet explaining how to design for them. It can be assumed that this is because it is a relatively new technology that is quickly evolving; the tutorials that were found already seemed to be dated.

Many other problems were encountered and overcome, such as various code errors and database problems fixed by trial and error, or referring to textbooks, but in general the development ran quite smoothly and should another project be attempted that is quite similar, the location of help and advice is known.

Where Next?

Plans for the WWW prototype include making the code easily adaptable and customisable so that it can be released as freeware taking the form of downloadable scripts (open-source).

A fully developed version of the WWW prototype would ideally require a development team, as in order to satisfy most users it would have to include much more media, and a much deeper story; all of which would be too much for one person to develop. Story writers, sound developers, character designers, and developers of Flash based media would be required, not to mention PHP programmers to adapt and add to the structure of the game. Game development is no longer a ‘one man on a mission’ venture, as in the early days of video games, now they really do require development teams if they are to compete with the rest of the market and make the most of the available hardware.

However, the PDA version of the prototype does have potential; the available hardware limits what can be achieved, and as previously mentioned, a game such as the prototype is well designed for a platform with limited input. Development of the PDA version would also not need as much development time as the WWW version, and therefore could possibly be created by a single developer.

Personnel Comment

Hall (cited in Saltzman M., 1999) once said "Your first ten games will suck" and although this is the virtually the first game that I have developed it has to be said that most testers quite liked the ideas that were present within the prototype. It would have been much better to have a further developed story embedded within the prototype to show off its functionality and possibilities more, but due to development time this was not possible. Bates (cited in Saltzman M., 1999) suggests not writing for game if you don’t know how to, so I suppose by choosing to only use a short sample story, I ended up doing the right thing and using available time well.

At the beginning of the project I stated all of the things that I wished to create, achieve and learn along the way and now that I have finished the project I am happy with the progress and confident that the brief that I set has been met. However it is worth mentioning that the initial scope has changed slightly, instead of producing a prototype ‘game’, what has been produced is more of a structure to allow a game to take place once written into the database.

It has been interesting to see how the process of developing a game differs from developing any other form of interactive multimedia, especially when using programming tools (PHP, JavaScript) that were not specifically designed for such applications. I have also learnt many new concepts, such as fundamentals in game design, characters design and writing for games.

Overall it has been a very experimental project, many new skills have been learnt, and older ones developed, for example my knowledge of PHP and general database design has greatly improved; I have done things while developing this project that I will definitely use again, and other things that I certainly won’t.

REFERENCES

AdvancedFightingFantasy.com (2002).
[Online]
Http://www.advancedfightingfantasy.com
Accessed 13th November 2002

Barfield L. (1993). The User Interface: Concepts & Design.
Addison-Wesley Publishers Ltd.

Bates B. (2001). Game Design: The Art And Business Of Creating Games.
Roseville, California. Prima Publishing

Bellantoni J. & Woolman M., (1999). Type In Motion - Innovations In Digital Graphics.
London, Thames & Hudson.

Boetcher S., Duggan H. & White N. (2001). What Is A Virtual Community And Why Would You Ever Need One??
[Online]
http://www.fullcirc.com/community/communitywhatwhy.htm
Accessed 20th November 2002

Brian, (2000a). RPG Game Design Tips - Character Design
[Online]
http://www.silvernetwork.net/~gmg/rpggamedesign/page3.shtml
Accessed 17th November 2002

Brian, (2000b). RPG Game Design Tips - Dungeon Design
[Online]
http://www.silvernetwork.net/~gmg/rpggamedesign/page2.shtml
Accessed 18th November 2002

Brown C. M. (1999). Human-Computer Interface Design Guidelines
Exeter, Intellect Books.

Faber L. (1998). Re:play "Ultimate Games Graphics."
London. Laurence King Publishing.

Fontanel C. (n.d). The Dungeon Master & Chaos Strikes Back Encyclopaedia
[Online]
http://dmweb.free.fr/
Accessed 15th November 2002

Fox D. (2002a). Will Mobile Games Sweep the Nation?
[Online]
http://www.oreillynet.com/pub/a/wireless/2002/10/31/mobile_games.html?page=1
Accessed 15th November 2002

Fox D. (2002b). Developing Cutting-Edge Mobile Games.
[Online]
http://www.oreillynet.com/pub/a/wireless/2002/11/14/game_dev.html
Accessed 15th November 2002

Game-Research.com (2002). The Art, Business And Science Of Computer Games.
[Online]
Http://www.game-research.com
Accessed 14th November 2002

Greenfield S. (2002). Emotional Involvement In Games.
[Online]
http://www.techtv.com/extendedplay/videofeatures/story/0,24330,3387966,00.html
Accessed 5th April 2003

Hamilton D. L. (n.d.). "The History Of Story Telling" (Taken From "The Mind Of Mankind" - Human Imagination, The Source Of Mankind's Tremendous Power!)
[Online]
http://pages.prodigy.com/suna/storytel.htm
Accessed 12th December 2002

Herz J. C. (1997). Joystick Nation.
London. Abacus.

Infocom (2002). Zork I.
[Online]
http://www.infocom-if.org/games/zork1/zork1.html
Accessed 14th December 2002

Jones E. (1998). Multiplayer Gaming.
[Online]
http://planetquake.org/futuregaming/trends/multiplayer/
Accessed 15th November 2002

Kentie P. (1997). Web Graphics Tools And Techniques.
Berkeley, California. Peachpit Press.

Lewinski J. S. (2000). Developers Guide To Computer Game Design.
Plano, Texas, Worldware Publishing Inc.

Lim J. (2000).
[Online]
http://php.weblogs.com/popularity
http://php.weblogs.com/adodb_benchmarks
http://php.weblogs.com/php_vs_cold_fusion
http://php.weblogs.com/php_asp_7_reasons
Accessed 4th January 2002

Loijens J. (2000). Dungeons & Dragons: Games in the Works.
[Online]
http://www.gamespy.com/legacy/articles/dnd1_a.shtm
Accessed 15th November 2002

Mulligan J. (2000). Odd Bits And Pieces.
[Online]
http://www.skotos.net/articles/BTH_04.html
Accessed 14th November 2002

Poole S. (2000). Trigger Happy - The Inner Life Of Videogames.
London. Forth The Estate.

Powell T. A. (2000). Web Design, The Complete Reference.
Berkeley, California. Osborne/McGraw-Hill.

Ramos A. (2000). The Web on PDA’s.
[Online]
http://www.andreas.com/pda/index.html
Accessed 4th April 2003

Rouse III, R. (2001). Game Design Theory & Practice.
Plano, Texas, Worldware Publishing Inc.

Reichley K. (2001). Make your Site PDA-Friendly.
[Online]
http://www.webmasterbase.com/printTemplate.php?aid=467
Accessed 4th April 2003

Saltzman M. (1999). Game Design - Secrets Of The Sages.
Indianapolis, IN. Brady Publishing.

Smith H. (1999). Player Character Concepts.
[Online]
http://www.gamasutra.com/features/19991108/smith_01.htm
Accessed 18th November 2002

Tannenbaum R. S. (1998). Theoretical Foundations Of Multimedia.
New York, Computer Science Press.

TheCounter.com (2002). Global Browsing Statistics.
[Online]
http://www.thecounter.com/stats/2002/December/index.php
Accessed 1st January 2003

TheCounter.com (2003). Global Browsing Statistics.
http://www.thecounter.com/stats/2003/March/index.php
Accessed 1st April 2003

Zsigo K. (2002). Making Money Writing Wireless Games.
[Online]
http://www.wirelessgamingreview.com/articles/konny071602.php
Accessed 15th November 2002

APPENDIX 1: DESIGN

Flowchart

View Image

Database

Page

Type

Comments

ID

Integer

Primary key, auto-incremented.

Text1

Text

Story text.

Text2

Text

Text3

Text

Option1

Integer

A target page ID’s.

Option2

Integer

Option3

Integer

Optiontext1

Text

Target page descriptions.

Optiontext2

Text

Optiontext3

Text

Criteria1

Integer

Values used to see if the relevant option should be shown or not based on comparing positive or negative values to player statistics.

Criteria2

Integer

Criteria3

Integer

Items

Text

An array of items.

Media

Text

An array of image names, or a single flash movie.

Characterid

Integer

A character ID.

Useditems

Text

Items to remove upon access of the page.

Changescore

Integer

Values used to change player statistics upon access of the page.

Changehealth

Integer

Changeluck

Integer

Changestrength

Integer

Changemagic

Integer

Player

Type

Comments

ID

Integer

Primary key, auto-incremented.

Email

Text

Unique combination; used for log in along with password.

Password

Text

Charactername

Text

Players character name.

Score

Integer

Used to determine how well they have progressed.

Gold

Integer

Player statistics.

Health

Integer

Luck

Integer

Strength

Integer

Magic

Integer

Page

Integer

The ID of the player’s current page.

Items

Text

An array of items.

Character

Type

Comments

ID

Integer

Primary key, auto-incremented.

Name

Text

The name of the character.

Description

Text

A description of the character.

Health

Integer

Character statistics.

Luck

Integer

Strength

Integer

Magic

Integer

Item

Type

Comments

ID

Integer

Primary key, auto-incremented.

Name

Text

The name of the character.

Description

Text

A description of the character.

Cost

Integer

Values for how the item changes the player’s statistics and score.

Score

Integer

Health

Integer

Luck

Integer

Strength

Integer

Magic

Integer

Layouts

Normal Game Page (No media)

View Image

Media Game Page

View Image

Font Range

Story Text

- Arial



- Refluxed (with different spacing between the “R” & “I”)



- Whorn

Characters

Personality traits:

Friendly unless attacked.

Appearance:

Muscular, tired, unhappy.

Motivation:

To defend or to guard, military, employment.

Catch-phrase:

N/A at present.

Name:

N/A, referred to as The Guard.


Personality traits:

Friendly but continuously lies.

Appearance:

Happy, cheerful.

Motivation:

To travel and meet new people.

Catch-phrase:

N/A at present.

Name:

N/A, referred to as a Nomad.


Personality traits:

Fierce, cannibalistic.

Appearance:

Dark, angry.

Motivation:

To hunt, fight and to control.

Catch-phrase:

N/A at present.

Name:

N/A, referred to as a Cannibal.


Personality traits:

Discrete, quiet, yet wise.

Appearance:

Muscular, unapproachable, heavily tattooed.

Motivation:

To guard and fight.

Catch-phrase:

N/A at present.

Name:

N/A, referred to as a Swordsman.


APPENDIX 2: IMPLEMENTATION

Screenshots

View Image #1 View Image #2 View Image #3 View Image #4

Story Map

View Image

PDA Designs

Example 1a – Web Safe

Example 1b – Greyscale

 

Example 2a – Web Safe

Example 2b – Greyscale

 

 

Example 3a - Web Safe

Example 3b - Greyscale

Design Space Analysis (sample QOC diagrams)

View Image #1 View Image #2 View Image #3

© 2001 - 2010 : Staffordshire-Web-Design.co.uk - Freelance Web Designer (Staffordshire Web Design & Web Designer)

Staffordshire Web Design

Staffordshire Web Design | Terms Of Service | Privacy Policy | Site Map

Valid XHTML 1.0 Transitional | Valid CSS! | Level Triple-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0 UK Web Design Association - Staffordshire Web Designer