jump to navigation

Exploring Fighting Fantasy June 28, 2009

Posted by markw1970 in Game code and theory, creative, game design.
Tags:
1 comment so far

citadelFurther to my last (admittedly over critical) post I decided to explore a form of adventuring that I enjoyed in my youth. The Fighting Fantasy series has always fascinated me since it is so simple and so creative. It allows the creator to conjur up some incredible scenarios and locations with just words. Images help but it’s the detail in the descriptions that captures the imagination.

For the reader there is a true escape. I admit I prefered the troll style fantasies to the sci-fi but the point was there was something there for everyone.

The mechanics behind the books were really rather simple and consequently extremely accessible. You started the adventure / story with Stamina, Skill and Luck that were determined by the throw of a dice. You had to track your stats as well as inventory items and general notes that might be of some use.
Your Stamina was essentially your health. When zero you expired. Your Skill was essentially your skill in battle and your Luck was your likelihood of winning the flip-of-a-coin situation.
Assembling a game with these core rules is no great task.
So I had a go.

Although it’s not quite ready to post up just now it’s certainly well on the way. I have a number of game elements in place and a game editor that I decided was the best approach for this kind of project. I empower the editor so that I can just sit back and create some exciting locations, monsters and scenarios.
I’m also going to enjoy using pen and paper again after nearly 30 years !

So far the player can be met with one of 5 scenarios per location.

  1. Standard location (no challenge)
  2. Monster
  3. Treasure
  4. Luck test
  5. Stats nudge

All should be self explanatory except perhaps for the last one, stats nudge.
I wanted the ability to reward or harm the player through their stats based on their decisions or success in combat.
It makes sense for a player to find himself surrounded by health potions immediately after battle, for example.
Similarly a player with no luck might find themselves in a room full of slime or poison.
In each case I can simply add or subtract from the player’s core stats: Stamina, Skill or Luck.

Monster fighting and Luck testing are handled by some JavaScript that visibly rolls a dice and determins the outcome of the action.
As in the gamebooks the rules for combat are simple; roll the dice and add to your skill. If the result is greater than the monster’s skill then you hurt them. The same is true of the reverse scenario where the monster is attacking you.

The one element of the game that I was reluctant to try and implement was the inventory and gold mechanism.
Just now the only information that persists across each location is Stamina, Skill, Luck and Game ID. The Location ID changes with each click, naturally.
So I decided that the best way to implement an inventory would be to simply force the player through a location where a new inventory item resides. This allows me to always assume that the player actually carries the item. It might seem lame but it’s a deliberate sacrifice in my pursuit of an arcade text adventure. I want the player to spend 5 – 10 minutes at a time playing this game so the lifespan is short enough anyway and there are other ways to challenge people.

A future enhancement will probably see the inventory feature implemented.

Finally I want to draw some locations. I’m a seasoned artist so sketching out some fantasy locations is right up my street.
The final part of the editor therefore is the image selection tab. For each location I can simply pick an image to display.

I’ll post a link to the game when there’s something to actually see.

Expanding on the thought process behind chat / text based adventure gaming June 26, 2009

Posted by markw1970 in Game code and theory, game design.
Tags: , , , ,
add a comment

The journey home from the office is about 20 minutes and plenty enough time for me to wander with my thoughts. I just can’t shake the idea of organic text-based adventuring just now. Here’s some more thoughts.

I researched a fair bit on amateur adventure game creation this afternoon. There are a glut of forums out there for this kind of thing and I have to say I’m not a member of any of them. Nor shall I be. I’ve done the forum thing in the past and find them to be pretty awful “smart-arsed” howitzer affairs between semi-clued up idiots. But there were some interesting points worth picking out.

Firstly, it seems that amateur adventure game creators appear obsessed with their “systems”.

In my system there shall be this method of trading and that method of combat and some other such method for moving around.
There shall be this elaborate system of talking between characters where certain phrases are allowed and certain actions are allowed depending on the phrases… etc etc

This is common and to me somewhat surprising.
Investing so much time and effort in to a clearly restrictive system for a game that ought to allow for tremendous freedom seems to me like trying to solve an unnecessary set of puzzles.

Second, players are shown everything with fancy icons, graphics and maps.
At first you might think ‘fair enough’. The player wants to see himself, his location and his attributes. But what surprises me is that this appears to be one of the first considerations for the designer – how the game will look. Before any thought is given for the experience it seems that amateur game designers are telling us that their game will look like SNES Zelda and play with a system borrowed from Elder Scrolls. Or some such.

To me both of these things miss the mark by a long way.
Anybody willing to play an adventure game, even a casual one, is probably willing to invest a little of their imagination. At least enough to flesh out the scenario in their mind. The inclusion of rich graphics in an RPG is surely more of a marketing gimick than a true aide to the gamer. Some is good but too much makes the entire process of adventuring a banal affair. Give the player pointers and let him “create” the rest.

I tried to figure out a process where I could prove an adventure game “on paper” by allowing for the most natural decision making process known to man – conversation.

Consider this text transcription.

Although it looks horribly basic try and look in to what I’m trying to achieve. Look at how the decisions are made.
There is no game here. No underlying “system”. It’s purely natural and uses simple, available technology.
You can also see that the game continues to tick in my absence and all I am ever doing is offering myself a window in to the game.

Note: square brackets denote a user action e.g. [ SLEEP ]

Decisions are not tied to a game system. In fact the only system is the means to view information that then allows you to make a decision.

This method of communication is accessible to everybody since it is a form of communication we all know. There would be no instruction booklet to describe your “chat” system.

World of Warcraft appears to dominate the online gaming community. (I still don’t see the relevance of the word Massively in MMO, surely it’s implied by virtue of the world wide web)
I would suggest that a large part of the reason for its dominance is its simple and highly effective communication system. Not only that it actively encourages the formation of guilds.
Talking with a colleague and avid WoW player I understand that simply belonging to a guild is considered an achievement. Indeed of the 200+ members of his own guild he is convinced that a significant portion are there simply because “it’s a guild”.

Gravitating towards like-minded people through conversation and basic human interaction is the most natural process we know.
In many respects this kind of thing doesn’t require restriction.

Just some thoughts. I expect they will evolve.

More thoughts on browser based adventure gaming June 26, 2009

Posted by markw1970 in Game code and theory, game design.
Tags:
2 comments

Sometimes I find myself surprised by the simplest things.
For the last few days I have been working on a simple JavaScript arcade game the killer feature of which is a scrolling floor similar (but not identical) to that of Space Harrier. As I’ve been piecing the game elements together and scaling sprites and other game content I’ve also been pre-occupied with the notion of online adventure gaming.
It’s distractions like this that lead me down all manner of thought trails and ultimately, and inevitably I have to shelve my current project to go and investigate my ideas a little further.

I am not an adventure gamer by rule. I much prefer to play “arcade” games. I rather enjoy the theory if it all but the concept of pretending to be an Orc or a Paladin and venturing off to find treasure in “them thar hills” is a bit beyond me.

Atleast that’s what I thought.

I recently picked up a few old games, one of which was Dungeon Siege. I was convinced it’d get an hour of my time and then I’d uninstall it. To my surprise I played it through and thoroughly enjoyed it. Being a designer of games I decided to invest a little thought in to what it was that actually grabbed my attention so much.

I found the answer was within my definition of the term “arcade gaming”.

To anyone older than 20 years the thought of an arcade game meant standing in a game arcade waiting patiently for a “go” on a game machine. I still remember fondly pacing the grotty floorboards of the local arcade with a fistful of coins looking for a cheap laser thrill. Great days. But arcades of course died a death thanks in no small part to their abuse by factions of society that used them as havens for pushing drugs and getting smashed on cheap booze.
To a modern gamer an arcade game is a simple, casual game enjoyed thanks to the internet. Probably.

My problem is that I’d always assumed an arcade game was a ton of sprites drifting around with a wee player sprite striving to destroy them all in some way shape or form. Certainly these are the games I love to play.
I re-evaluated this and decided that a truer description was probably better defined by my attitude towards the game rather than the style of the game itself.

In the arcades you were prepared to spend a short space of time playing a game. You certainly didn’t expect to be there for hours on end.
I simply haven’t got hours on end to spare for gaming. Those days are gone.
But I am a keen gamer in that I enjoy the challenge of computer games.

Dungeon Siege allowed me to progress through a fantasy game world at my own pace without the hassles of guild membership or any kind of commitment to a pre-arranged tournament. I’m sure those things are available but I didn’t use them.

So it strikes me that a great game might be found in a fantasy adventure that is designed to be played in short bursts.
A kind of “dip in and dip out” style of game that prompts the player for a decision or action then shuts up shop until the next time the player returns. In the background you might move the game world on a bit so that the player returns to a “living” situation.

This is quite different to the “what do I do next?” style of game that I had previously been thinking about.
Better still the game needn’t use any graphics whatsoever.

I could play the game on my mobile phone and just “dip in” once in a while to see what’s changed and what I need to do to survive.

This may sound pretty pedestrian to anyone used to the graphical thrills of World of Warcraft but from a designer’s perspective (especially somebody happy to consider the more cerebral aspects of such a game) this is where the fun is.

So I am now moving more and more towards an adventure game in an open world where the player initially must simply survive.

Once I’ve finished the “inbetween” game that I’m working on I am going to enjoy sketching out the framework for a big fantasy project.

Rebel Ideas web site finally uploaded June 23, 2009

Posted by markw1970 in game design.
Tags: , , ,
add a comment

website

I haven’t had a lot of time just lately what with babies, work and stuff. But I was keen to finish my web site so that I could finally establish myself properly on the web.

My site, Rebel Ideas, can be found at www.rebelideas.co.uk.

During the development of Invaders from Mars I sent a link to a couple of guys whose work I have admired for some time; Douglas Crockford and Chris Crawford. They were both kind enough to reply to me and offer a few brief comments. I’ve included those comments on the site.

I also sent emails to Eugene Jarvis and John Romero whilst developing Hoth Strike. I figured John as a game designer may be interested and, well, Eugene’s Defender is pretty much what Hoth Strike is modelled on. Again they both replied and were kind enough to offer comment and suggestions.
I included part of John’s comment but as yet I haven’t received permission from Eugene. (I only sent the request yesterday !)

I’m really delighted to now have a firm platform from which to work from and will be diving in to game development with some renewed gusto !

Thinking about text adventure games and a new arcade project June 19, 2009

Posted by markw1970 in Game code and theory, JavaScript Game Template, creative, game design.
Tags: , , , ,
2 comments

I’ve been thinking a fair bit about a new project. In fact I’m a compulsive thinker of new ideas. Even whilst I was trying to bring Hoth Strike to a tidy close I was off in cuckoo land dreaming of a fantasy universe with fancy map and character editors. I still love the idea of having this super rich world with different races living side by side each with their own geo-political issues. I love the idea of different races, communities and individuals having their own particular agenda and I absolutely love the idea of dropping the player right in to the middle of it all. I even started to code a framework to put some flesh on the bones of the idea.

But mid way through something dawned on me. I hadn’t even considered the application for the game. I had no idea how the game would be played and no consideration for the visual appearance / appeal of the game.
I am essentially an arcade gamer. I love the ability to dip in to a game, wreak havoc, obtain a score (high or otherwise) and then just leave it all behind until next time. The games I play are pretty much this sort of game. For some reason I have just harboured this love of computer fantasy role playing and always thought it would be an interesting challenge.

Growing up with a love for Infocom’s Zork probably didn’t help this much. In my youth I wrote all manner of linear adventure games in BASIC. You know the sort, YOU ARE IN A ROOM. DO YOU GO LEFT OR RIGHT. > YOU WENT RIGHT. YOU HAVE FALLEN DOWN A PIT. END. Hmm. Should have gone left.
Those kind of games were littered with GOTO statements and were pretty dreadful to be honest. All the fun was in the creation.

A step beyond all that is the Fighting Fantasy style. These were huge in my youth. I particularly remember Citadel of Chaos for it’s rich definitions and grotesque characters.

mapI got a pen and paper out and sketched out my own idea for a game earlier today. It came out something like the map above. What struck me as fascinating about this was just how easily it translates in to a coding structure. Using JavaScript to create this sort of thing would be a breeze with every location an instance of a Node class of some kind populated individually with specific attributes to prompt the player in to having decisions to make.

So I set about coding a simple structure for this kind of game.

Using JSON I defined the following type of structure:
var locations = [
{
id : 0,
title : "The Entrance Chamber",
description : "You are standing in a tall but rather narrow chamber. Paintings from a long forgotten time adorn the walls and portray past members of the household. They appear to watch your every move. Quietly you turn to face the open door behind you. It creaks in the wind then SLAMS shut. Darkness falls and you are suddenley met with a shiver.",
prompt : "A staircase leads up away from the chamber. A dusty old chest sits in a dark corner.",
actions : [
{
text : "Climb the stairs",
nextlocation : 1
},
{
text : "Open the chest",
nextlocation : 2
}
]
},
.
.

As you can see that array definition could easily go on for several megabytes more. And indeed it will.
Locations 1 and 2 are naturally going to hold information relative to the Staircase and Chest.
I could expand on the location definition to include attributes for light level, HP damage (e.g.poison), gold, inventory items, monsters and so forth. All the game code would be concerned with is picking the details out for that element and presenting the player with a number of choices. As with the map diagram above all roads would ultimately lead you back to the central “spine” of the game until ultimately you reached your goal.

There are two reasons why I particularly like this approach to a game.

Firstly, it’s 100% flexible and easy to replicate. By administering a data source you could rip out a data.js file and bang a new one in there that is a completely different game ! This appeals since I could probably think of countless adventure scenarios.

Secondly, it’s playable on the move. I could simply render text and providing my handset supports JavaScript, CSS and HTML I get a reasonable game experience.

But for the game to really capture my interest it would need a separate combat element. A means of accumulating enough strength, experience, dexterity, intelligence etc to actually do some damage in battle. Further in to the story / game you would then come up against some tough adversaries.

This loosly linear approach to a game also gives me the chance to flex my atrophic literary muscles. I love the idea of being able to go to town describing a location and situation. Better still I could crank up photoshop and sketch out the location with a simple JPG. Where an image exists I simply present it above the text.

There are a great many creative positives to a side project like this. I could have a serious amount of fun just pencilling out the map for the adventure and coming up with a ton of tricky scenarios in which to plant the adventurer.

Check out my extremely roughly coded example here: http://rebelideas.co.uk/proto/adventure1/

Take a look at the data.js file for the structure. You will see that only a couple of locations are coded. But it’s an interesting starting point.

Meanwhile…. I am preparing some graphics for my next graphical arcade game. I’ve already done my own takes on Space Invaders and Defender. Next up I hope to apply a similar spin on Robotron. Somewhere in between Robotron and Gauntlet you will hopefully find my next game, set in a very familiar and extremely popular universe. More soon.

Hoth Strike – new version and some new features June 16, 2009

Posted by markw1970 in Game code and theory, bug fix, game design.
2 comments

Just a few changes.

  • Fixed invulnerability bug with speeder sliding in to probes on direction change and not being harmed
  • Made speeder blink at start of wave to indicate invulnerability (note, this period decays with subsequent waves)
  • Extra life at 100,000. Listen for R2. If you hear him you have the extra life.

Play Hoth Strike v.1.2.1 here.

Hoth Strike – a few changes June 14, 2009

Posted by markw1970 in Game code and theory, bug fix, game design, shoot em up.
3 comments

Well my inbox exploded over the weekend with feedback from this game. I choose to publish my games for precisely this reason so it would be fairly arrogant of me to simply ignore everything that has been said.

In short there appears to be tremendous strength of feeling towards the intro crawler text and the way in which the speeder slides across the screen.

The crawler text doesn’t actually add anything to the game. It only loosly resembles the style of the movie so I figure if anything is droppable it’s this. But it was the number of comments from people saying that they had no clue how to get past it and therefore they quit the game that gave me the greatest concern. The fact that people dismiss the game simply because they couldn’t launch it is a problem.
It bothers me that people don’t just hit the fire button (Z) until something happens but I guess not everyone played the arcade / console games that I played in my youth. Unless it’s spelled out clear as day it seems people just draw a blank.
Either way the intro text is dropped.

The second issue is far more interesting since it affects the way the game is played and also impacts on the “skill” required to play the game.
The largest amount of feedback appears to reveal a preference for having the speeder sit centrally in the screen and not having it slide left – right / right – left when changing direction. Admittedly I greatly exaggerated the swing across the screen and preferred the speeder sat extreme left and right as I was building the game. What can I say ? It just stuck. I loved the way that I could zoom past a few probes then change direction, swing the speeder low over them and blast them all to hell ! It was just so satisfying.
I can fully understand why people object to it but then I objected to Defender’s spaghetti fingered control system at first. Just needed practise.
Anyway, I’m not changing it since it’s a cool feature in my opinion. But I have surpressed alien collision when the speeder is sliding to the other direction. That might help people that can’t be bothered to look at the scanner.

Edit: I pulled the speeder in a bit and played it for a day or so. I admit it works nice. Whereas the speeder was sat at Edge + 16 previously it now sits at Edge + 128. The swing is less pronounced and the game is actually far more playable. I even racked up a 100,000+ score !

This stuff is about artistic expression. Fundamental changes to these games would cease to reflect my own personality. Thanks to those that have offered feedback.

Hoth Strike completed June 12, 2009

Posted by markw1970 in Game code and theory, JavaScript Game Library, JavaScript Game Template, game design, shoot em up.
Tags: ,
10 comments

hothstrike-beta1

Well I’m happy enough for this game to be called finished. I may tweak it a little in the future but for now it’s a pretty intense and (I think) rewarding game.
I’ve deliberately left the code un-obfuscated so that people can see how I constructed the game. Warning! It’s not pretty since despite my best intentions to write perfect JavaScript I wound up just cobbling the code together to get a game out.

Future games will make better use of global namespaces and JSON, for example.

CLICK TO PLAY THE GAME

I hope you enjoy playing the game as much as I did crafting it :-)

MAY THE FORCE BE WITH YOU

ps. my top score just now is 58,850.

Hoth Strike – bug fixes June 11, 2009

Posted by markw1970 in Beta release, Game code and theory, bug fix, game design.
1 comment so far

#1 Fixed a glaring error in the way that the count for rescued rebels and alien kills are handled. The way it was written you’d never end a wave unless you achieved it without losing a life !

#2 There was a problem with Probes colliding with the speeder during the wind up of the wave. I set a gl.fightingchance ticker to give the player a chance to move the speeder out of the way.

New code is now online.

Hoth Strike – Beta June 10, 2009

Posted by markw1970 in Beta release, JavaScript Game Template, shoot em up.
Tags: , , , , ,
2 comments

hothstrike-beta1I’m finally happy that Hoth Strike is a playable and enjoyable experience. There are still a few issues that I want to resolveĀ  but hopefully nothing that will stop the show. So I’m offering the game as a Beta release to anyone that stumbles upon this page.

Play the game at this link: www.rebelideas.co.uk/proto/empire

hothstrike-beta2As with any Beta release I welcome all comments regarding bugs and general “playability”.
I will generally now focus on tidying up the code for the game including implementing a ton of stuff I’ve learned from books by Douglas Crockford et al. It’s come as quite a surprise just how inefficient my coding can be. More on that in due course. For now please play and (hopefully) enjoy the game :)