> > 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!
>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..
like I drawed before:
************
*.............*
*.............*
*.............*
*.............*
************
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
like stated before: you indeed need atleast 2 maps, one gfx-map and one
data-map. 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.
then a data-map looks like:
************
*.............*
*..ww...W*
*.............*
*.............*
************
with "w" as seetrough fence and "W" as non-seetrough fence..
but maybe small chars could be used for gfx and capitals for the same dot +
a trigger command!
>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:
* what gfx (l/r/u/d)
* walk area width + height (if the story tells: "you'll find the doctor in
the hospital" you don't want the doctor walking away :)
* random walk or predefined route !!
* walk-speed (young kiddy's run, while old granny's hardly move)
* what txt it should say
* bitmap gfx for use in the statusbar (like in sd-sn)
* a trigger to go to fight-mode
* special actions when YOU come close (ds6, chickens running away in village)
>Maybe we could first make a non-scrolling engine, like that of Pumpkin
>Adventure 3. Once that works, the first games can be made and a scrolling
>engine could be developed for the next generation of games.
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..
>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...
\/\/
Maarten van Strien,
* composer
* sounddesigner
* Ixalance-sound developer
-----------------------------------------------------
http://www.shortcut.nl/
mailto:[EMAIL PROTECTED]
-----------------------------------------------------
Shortcut Software Development B.V.
Julianaweg 9, 3603 AP Maarssen, The Netherlands.
Phone: ++31 (0) 346 579 659
Fax: ++31 (0) 346 579 745
-----------------------------------------------------
****
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
****
