> > tiles that cause events should by my opinion be handled by using
triggers..
>
> What exactly is a trigger?
If you step on such a tile an event takes place which causes a piece of code
to start (or something like that).
> > could be a walk-map with walls.. collision with walls could be checked
by
> > using top-view style rpg.. but drawing ofcourse is 3d/birdview
>
> Hmmm, I seem to use the term "birdview" for a different view than you do.
> Does anyone know for sure, what is the Metal Gear type called and what the
> SD Snatcher type?
Both birdseye.
SD-Snatcher is also Super Deform (hence the SD).
> > like stated before: you indeed need atleast 2 maps, one gfx-map and one
> > data-map.
>
> Another option would be to have all the properties of a square on the map
> determined by the tile. For example: tile #102 is always a wall, tile #103
> is always walkable. When there is a tile that can have more than one
> set of properties (illusional wall looks like a wall, but is walkable), it
> is duplicated into multiple tile numbers, all with the same graphic.
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
won't, since I want my engine to be fairly simple to adapt. Using 16-bit
tilemaps and variable sizes (which is absolutely not nessecary) CAN be done,
but it will make the code more complex.
> Whether this approach will work or not, depends on how many tiles do not
> have fixed properties and how many combinations of properties are
possible.
> In the best case, this saves a lot of memory because a data map is not
> necessary. In the worst case, the number of tiles becomes too large.
>
> > I think a forground-layer can be defined, also in de datamap.
> > This requires special gfx setup, like: see-trough gfx like fences must
be
> > drawn at the top of a picture (first line with dots) with the forground
> > part, seperatly drawn right below.
> > so, by using 2 maps instead of 3 you save RAM.
>
> This approach gives more flexibility than the PA3-like fixed background.
> But it also uses more memory.
1 map is still the smallest. And it can be done.
> > >And animations haven't been discussed yet. Sprites (either real VDP
sprites
> > >or copied sprites) are necessary and maybe we also want animations in
the
> > >background (like YS3) or in the foreground.
> >
> > each non-human-controlled player should have info like:
>
> There is a term for it: NPC = Non Player Character.
Good to know.
> > * what gfx (l/r/u/d)
>
> There should be more than just 4 animation frames for NPCs. To make a
> character walk, at least 2 frames are needed (in every direction).
> Ofcourse, some sprites won't have to face in 4 directions.
'Sprites' are a different issue. 8x 16x16 = 128x16. So is you want to use
1/2 of a screen for the sprites, there is room for 16 different sprites.
Should be enough, and otherwise it can be expanded to 3/4 of the screen (at
least in my engine, although it is not preferred since I then have no room
left in page 2 anymore, while I also need to put my (real hardware)
spritedata somewhere. I want to keep page 3 completely free for the
battle-mode (characters & animations).
> > * walk area width + height (if the story tells: "you'll find the doctor
in
> > the hospital" you don't want the doctor walking away :)
>
> Not just width and height, the entire rectangle should be defined. Maybe a
> rectangle is limiting, but I think defining non-rectangular areas is too
> complex. Unless we define them on a tile-by-tile basis, like in the data
> map.
No, you are correct.
> > * random walk or predefined route !!
>
> What about a pointer to a movement algorithm routine? That would even work
> for the player character (PC), it could call a keyboard + joystick read
> routine. The advantage is that it would be easy to make the PC follow a
> predefined route during certain scenes (this can be seen in many RPGs).
I plan to create features like this in the 'event'-file; "move to x,y",
"move up/down/etc."
> > * 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.
Good.
> > * 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.
> > * bitmap gfx for use in the statusbar (like in sd-sn)
>
> I think not all characters should have this. It looks real nice, but it
> does require a lot of graphics, putting a burden on both the GFX artist
and
> on the VRAM.
If they are not too big they can be loaded from disk really fast.
My engine doesn't have a status-bar, but the idea was that if you press
space (enter menu), and then select status, you will see the character's
images. Further I plan to create an ability to let images 'appear' within a
conversation (like in SD-Snatcher or Phantasy Star 4 (SEGA Genesis)).
> > * a trigger to go to fight-mode
>
> Including some identification of the type of enemy, so the battle engine
> can get the right stats, graphics and algorithms.
>
> By the way, you seem to assume a separate battle screen, like SD and PA3.
> Battles in the playing field are also possible, like Ys and Xak. An engine
> for that may be more complicated, so we shouldn't attempt it at first, but
> it could be an option once the engine is more mature.
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.
Although Chrono Trigger's (SNES) battle engine is REALLY awesome...
And Beyond Oasis (Genesis) is also a _very_ cool game...
> > * special actions when YOU come close (ds6, chickens running away in
> > village)
>
> Yes, I remember chasing after the DS6 chickens... :)
:)
> > 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..
>
> From a functional point of view, there is some difference. For example, in
> a non-scrolling engine monsters will usually stay on the same screen. So
> the game only has to calculate behaviour for visible monsters. But in a
> scrolling engine, the game also has to calculate behaviour of monsters
that
> are outside, but near, the screen.
There is a slight difference, but not much. Also, you can choose to let
monsters 'surprise' you (like in the first part of DS6 or in Phantasy Star).
> It would be strange if the player sees a monster near the edge of the
> screen, walks towards it to attack it, the monster moves out of the screen
> and when the player reaches the place where the monster was, it is nowhere
> to be found (assuming the player runs faster than the monster).
Calculating
> behaviour for all NPCs in an entire scene will probably be too much work
> for the Z80, so there should be a zone around the screen in which NPC
> behaviour is calculated.
IF you choose to let the enemies be visible.
> If you look at performance, there is a big difference between scrolling
and
> non-scrolling. Scrolling must be fluent, or it will hurt the game. To make
> optimal use of both the VDP and the Z80, parallellism is needed: you
> shouldn't do all the VDP commands first and then all the CPU work, because
> the CPU will be waiting for the VDP and the VDP will be idle when the CPU
> is working. Parallellism is always tricky to program, although it is very
> cool once it works.
And it is not only cool once it works, but also very cool to program.
> > >The same for the toolkit: I described some advanced features that would
be
> > >very nice to have, but most are not necessary to produce a game. So
first a
> > >simple toolkit could be made and features added later. But it's
important
> > >to have a structure that allows the adding of features.
> >
> > that's what we try here...
>
> OK, then we have the same idea.
>
> It seemed Laurens wanted to rush into coding phase right away.
> (Correct me if I'm wrong, Laurens.)
I am already coding (even before the discussion).
I wanted to set something up, a base to talk about. That way, (I hope) there
will be less babbling and more results. Not that I mind the babbling, but
some results are also nice. I have seen to many ideas die out here...
snif...
~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
****
