On Thu, 25 May 2000, Maarten van Strien (cs^tbl) wrote:
> > > Okay, then stop talking and make an editor!
> >
> >Good design includes that you don't just start programming, but decide
> >exactly what it is you want to make first.
>
> and I guarantee you forget something.. really.. this will happen!
Yes, ofcourse. But if you skip the design phase, you will forget lots of
things, instead of a few.
> >Another issue: how should properties of tiles be handled? For example, what
> >tiles you can walk through (open ground) and what tiles block you (walls).
> >And there could be tiles that cause damage (lava, thorns), or cause your
> >movement to become different (ice, water, strong wind). Or tiles that
> >trigger special events (character or monster appears, sound is played,
> >secret is revealed).
>
> tiles that cause events should by my opinion be handled by using triggers..
What exactly is a trigger?
> 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?
> 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.
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.
> >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.
> * 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.
> * 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.
> * 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).
> * 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.
> * 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.
> * 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.
> * 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.
> * 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.
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 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.
> >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.)
Bye,
Maarten
****
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
****
