On Tue, 30 May 2000, Laurens Holst wrote:
> > 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).
Super Deform has nothing to do with perspective, it just tells you that the
GFX artists had a creative view on human anatomy.
> > > 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.
I meant "number 102" by "#102". The statement above is compatible with both
8-bit and 16-bit tiles. It actually is an approach to remove the need for a
separate data map, thus reducing the number of bits per tile!
> Using 16-bit
> tilemaps and variable sizes (which is absolutely not nessecary) CAN be done,
> but it will make the code more complex.
16-bit is hardly more complex than 8-bit. It uses a lot more memory:
that's the problem.
Why do you think variable map sizes (opposed to only powers-of-two) are
hard? Please outline some algorithm or piece of code that would increase
significantly in complexity.
> > 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.
True. But there is nothing wrong with exploring the alternatives before
you select one. In fact, I think it's part of good design.
> > > * 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.
I really hate it when in RPGs pictures are loaded whenever you talk to
someone. First disadvantage is that the music is interrupted, second is
that the spinning up of the drive will take time, independent of how
little data is loaded.
These kind of graphics are cool, and I would like to see them in an engine,
just not for every character.
> 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.
Both in-game battles and separate battle screens have their own advantages.
There are examples of good games in either category.
> > 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.
Personally, I think that invisible enemies are not a good idea. I didn't
really like that in DS6. And even in DS6, enemies can become visible,
either after you flee from them or after using an item. Also, the enemies
in caves and villages were always visible.
Invisible enemies do make the engine a lot simpler: you only have to know
the chances of an encounter, you don't have to model the enemy's behaviour.
But I think this simplicity hurts the gameplay.
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
****
