Re: A83: Re: Zelda: Test of Courage


[Prev][Next][Index][Thread]

Re: A83: Re: Zelda: Test of Courage




In a message dated 22/03/00 15:42:15 GMT Standard Time, 
gte172i@prism.gatech.edu writes:

> Doesn't everyone else hardcode their assembly games in this manner?  

Not always. Role Playing Games are a law unto themselves. Unlike most
games, which involve whizzing pixels around in fancy ways :) a role playing
game has an underlying structure to it which is not dissimilar to programming
itself ; the flow of the player through a game is a bit like the flow of a 
program.

Much of it has to be coded directly, yes. Things like drawing the screen,
scrolling, pick up and drop etc. all operate in much the same way, and 
are hardcoded (not always !).

Some have an underlying pseudo "programming" language. An example of 
this is the Bard's Tale series from long ago, which has a simple condition-
action scripting language which provides the puzzle element of the game,
and the exploring & bash the monsters side of it was hard coded ; so you
would program "if you are in the castle, with the princess and you have
the sceptre, you lose the sceptre, the princess leaves your party and
you gain 1000EP and 100GP and display "Well done sir knight....."  as 
8 seperate instructions. [3 conditions gives 5 actions]

Origin took a fairly major step forward with introducing an OOP system
to (initially) Ultima 6, which had the approach of looking on the games 
as things filled with lots of objects but had subclassing, [something 
a little tricky in assembler]. So whilst most of the characters behaved
in the same way, one could create an shopkeeper who was part of the
game by subclassing a particular element of his behaviour. This is a lot
less hacky (and more reliable) than having lots of seperate special case
tests in the code.

>> I'm not sure what you are talking about.  Are you asking if we are using 
>> a map  editor?
> We plan to have a map editor... if I ever get around to "hacking" one out.

Well, the tile maps are the easy bits :) Some ARPGs don't get any
further than a nice graphics engine and some basic tile maps. With
a game like this this is the easy bit ; the hard bit is constructing (and
making work) your game flow, something which just really isn't there
in a platform game, for example.

>> I did consider a scripting design but abandoned it on the grounds that it
>> would be  too difficult to do ARPG design without being a programmer (an 
>> aim of my engine). I wanted a point-and-click designer for it :)
 
> My thoughts exactly... Wouldn't an interpreter for a Click-and-Play to ASM
> converter be more difficult than writing the actual game in asm.

Depends what "asm" you use. Rather than using Z80 language create a 
purpose built language which has instructions like "Drop Object" "Test for
potions" and so as single byte instructions. (You can also have links to
Z80 code for really wierd stuff). Most of the actions, even in a game like
Zelda IV, involves very simple tests on status variables and then performing
simple actions, displaying messages and so on in response ; using a 
byte code can simplify the whole thing. Most of the code would be in
using objects, hacking and walking over tiles and so on. You reduce
the possibility for error and development time (hopefully) by producing
a very simple language to code in rather than Z80 assembler. The
engine is finished ; then you have a completely different set of code
which actually makes the game work.

My ARPG is entirely data driven (at time of writing) which does mean there
are some limitations, but anyone can pick it up and write a game with it
(hopefully :)) though it still does require some logic skills ; to avoid the 
classic dumbo bug of having the key to unlock the dungeon in the 
dungeon. 

Mind you, I do like doing interesting designs for the sheer hell of it. So its
probably me :)