Hi.
I decided to follow the discussion here and add remarks about the PA3
engine./ (see my message further down) so people can get some ideas of the
possibilities.
>
> > > like stated before: you indeed need atleast 2 maps, one gfx-map and
one
> > > data-map.
The PA3 engine uses only 1 map of 16 kb. There are 2 gfx sets of 255 tiles.
each room is build from one set, this can be
selected per room. Each gfx set has 4 types of tiles. These are A, S, V and
X types.
Only 3 extra bytes are needed to determine what kind of tile the player is
walking on, namely: A types start at 0 to x1, S types start at x1to x2, V
types start x2 to x3, X types start at x3 to 255
To build the room, 3 pages are needed. In page 1 the room is build
completely, in page 2 the room is build only from tiles V and S. When the
player walks, first the background is copied from page 1, then the player
over it, then the over layer from page 2, this is copied to page 0.
A-type tiles are tiles were the player can walk over completely. S-type
tiles are tiles were the player can walk behind completely. X-type tiles are
tiles were the player can not come at all. V-type is a special type, the
player can disappear behind it, but only two tiles deep (so 16 pixels deep),
thus he can disappear completely behind them yet when he is he cannot walk
further down. This type was designed to make editing easy. Actually, only A
types and V types are needed to build simple rooms.
> Yes. But the tiles are still 8-bit, not 16. At least not in my engine.
> You see, it might be oh-so-useful to have more than 256 tiles (although I
> doubt the limitations), but there must then also be someone to program it.
I
I agree, more than 256 tiles would be extremely useful, but your mapdata
becomes twice as big, and it would allow you
to have 256x256 (65535) tiles, only this can never be realized in VDP
memory, so it is a waste of good space. To give areas somewhat more variety,
we have 2 sets of 256 tiles, only they cannot be used in the same room.
> >
> > This approach gives more flexibility than the PA3-like fixed background.
> > But it also uses more memory.
exactly The background layer in PA3 is only used for the see-through parts
like fences and trees. the rest of the background can be edited with A-type
tiles.
> > > >background (like YS3) or in the foreground.
Is possible with the PA3 engine, a good programmer would even have little
trouble to enhance the possibilities there are now (and even they are
already quite extensive. The Lost World only used a little bit of them at
the end of the game, since that's when I started developing the possibility
to have big animations in the back/foreground.)
>
> > > * walk-speed (young kiddy's run, while old granny's hardly move)
> >
> > An easy way to implement is to store the delay between two animation
> steps.
> > In that way, not only the movement of kiddies is faster, but also the
> > animation.
This might also be possible in the PA3 engine, most programmers should be
able to change it. At the moment it is not there.
> > > * what txt it should say
> >
> > This often depends on game progress. For example, after the PC saved a
> > village from a horrible monster, the villagers will thank the player.
> >
> > Any thoughts on dialog systems? Cas told me it was very hard to make a
> > system that allows multiple storylines and still produces meaningful
> > messages. To avoid complications, we could either limit the storylines
in
> > such a way that they never cross (independant storylines), stick to a
> > single storyline or make messages more general (the latter can hurt both
> > the story and the atmosphere). Or we could attempt to design a multiple
> > storyline system, knowing that we may not succeed.
> It is indeed the hardest part. I have no idea how to do it yet.
>
The PA3 engine uses simple variables for this problem (and all the progress
in the game, things changing, etc).
Each area has its own program, if there's a forest of about 175 rooms, that
forest is made of 175/35 = 5 areas, so it has 5 program files (woods_1.com
woods_2.com etc)
The check for collisions is done in the engine, if there's a hit, the engine
jumps to a standart routine in the area program file (in PA3 this is called
Kletsen)
This routine takes over and handles what happens next, so if a character
needs to respond differently to 7 situations, it's a simple matter of
IF...THEN..ELSE , load the appropriate text and print it.
There are lots of these standart routines. If they are not necessary because
no such events happen in a certain area, they simply return immidiately.
There are events for collisions with characters or monsters, collisions with
walls or trees or anything (a simple check if the player bumps onto X or
V-type tiles), an event that occurs at the beginning of the area, upon
leaving the area, one that occurs every step the player walks (animations
for example) etc.
To take it a step further, in PA3 it is also possible (when there are really
big changes) to simple load different files upon entering the area. Say, for
example, a village you visited before is now burned down, you simple load a
different GFX set, a different DATA file, a different COM file (different
music) upon entering the area. The Fkernel sees to this.
>
> I will definately use a seperate battle-mode, because of the limitations
of
> my engine. Also, you can do a lot more stuff in a seperate battle-mode.
> Think of the colors for example, you can use a different palette. And
> effects can also be enhanced, and quite some effects look better on a
black
> background.
If I decide to make the PA3 engine public domain, I will include the battle
source of RoA so you can use animations in battle.
>
> > > I don't think scrolling is much different then non-scrolling.. wheter
> you
> > > move up player_x +1 or + 32.. checking for collision/triggers remains
> > > identical..
I think there is a very big difference. Most of the things Stefan thought up
and programmed will never work in a scrolling area.
If I read about all the ideas and problems in this discussion and then look
at how simple everything is done in PA3...
Making an RPG that scrolls is, my opinion, many times more difficult, so
maybe you should ask yourself. how much more fun is an RPG that scrolls than
an RPG that uses rooms? I agree, it is better, much better, but is it worth
the effort? I think when the game is fun, it won't bother anywone that it is
non-scrolling.... besides, using rooms gives lots of extra possibilities,
like the Katana Labyrinth in PA3.
> >
>
> ~Grauw
>
>
> --
> >>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
> email me: [EMAIL PROTECTED] or ICQ: 10196372
> visit my homepage at http://grauw.blehq.org/
> >>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
>
>
> ****
> MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
> and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
> the body (not the subject) of the message.
> Problems? contact [EMAIL PROTECTED]
> More information on MSX can be found in the following places:
> The MSX faq: http://www.faq.msxnet.org/
> The MSX newsgroup: comp.sys.msx
> The MSX IRC channel: #MSX on Undernet
> ****
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
the body (not the subject) of the message.
Problems? contact [EMAIL PROTECTED]
More information on MSX can be found in the following places:
The MSX faq: http://www.faq.msxnet.org/
The MSX newsgroup: comp.sys.msx
The MSX IRC channel: #MSX on Undernet
****
