2008/1/10, Christian Mauduit <
address@hidden>:
> Kasper Hviid
wrote:
> > What if it just loaded the background and the sprites from
the level
> > folder, without any behavior stuff? It is just that it
is a bit limiting
> > that the appearence of the background already
has been designed. Some
> > kinda artist thing ... most people won't
care. ;-)
> >
> > Speaking of the background, would you be
interested in having me fresh
> > up the sprites and textures a bit?
I could also create some alternative
> > ones.
> >
>
> About the GUI, do you want some texture to wrap around the cylinders
in
> > the menu? (If yes, what should the proportions be?)
>
OK, I lately made a new move in GUI / parameters / config files. The
>
idea follows: considering levels are created by people who know better
>
about what color fits for them (that's exactly your case) I decided to
> let the level itself decide of the menu colors. By default, colors
will
> be picked from the level (I'm just coded a quick-hacked algorithm
do to
> that), but of course you can define them explicitely. Same for
hud and
> cursor colors. All in all, I identified 20 colors which can
possibly be
> defined in a level (that's already a lot, I think).
Documentation coming
> soon.
>
> The major side effect is
that, except for texture.jpeg, the rest should
> be purely vectorial
stuff. As for the current water/bubble theme, a
> bubble can be
generated by a program, same for background texture. This
> corresponds
to my conception of the background: make it moving just to
> fancy
things a little bit, but don't try to do heavy 3D realistic
> rendering
in it. This is good for this way, you might have purple,
> green, blue
or white bubbles at almost no cost at all, just give the
> color. It's
a disk-space saver.
>
> For very complex background rendering,
there's always a solution: write
> a dedicated chunk of code for
it!
Thanks, it sounds real cool! Please tell if you need some
vector shapes.
It might also be possible to use a sprite_alpha.jpeg on a "color object".
That could create bitmap sprites with variable colors. If this isn't too much
work, please consider it. Some well designed bitmap background could
add a lot to the game.
> > 3) A file called liquid-alpha.jpeg
could define the opacity for the
> > liquid. It would be used for
places on the map where the liquid is
> > invisible, because it is
moving under an object.
> > It could also be texture.jpeg which was
displayed on top of the liquid,
> > cropped by
liquid-alpha.jpeg.
> OK, now the *BIG* change, which will probably occur
*after* beta3, so
> after January, will be to use layers. I first
thought of using a "depth"
> information, but it's too timid as a way
to go multilayers. What I plan
> is "map.png + layer2.png + layer3.png +
layer4.png + layer5.png", or
> something approaching. Layers are stacked
(layer5 at the bottom, map
> (AKA layer1) on top. Then it's easy to
know where to hide liquid: if
> there's a wall on map.png -> do not
show, it's hidden under! As a side
> effect, this solves the "fighters
disappears here and reappears
> somewhere else" problem. Just dig a
tunnel in layer3, and that's it!
I don't exactly understands how this
will work ... but it sounds real exciting! Please mail me the documentation
when you have it ready, so I can begin using it in my levels.
>
> 4) So far, all my texture.jpeg are variations on the same flat, top
down
> > view, since this is the way the warrior layer is being
rendered.
> > If the warrior layer was wrapped on some 3D
object instead, it would be
> > possible to design some texture.jpeg
with more perspective in them.
> > Possible workflow: Some 3D artist
create a 3D world containing a
> > slightly tilted square. He takes a
screenshot of the scene, and sends it
> > to me. I paste the
screenshot into Photoshop, and paint a texture.jpeg
> > based on
it.
> > The 3D world would need to be static, since my texture.jpeg
would be
> > static.
> > I don't know much about 3D, so I
don't have much idea how impossible it
> > would be.
> 3D
fancy stuff is surely planned. The only point I think is important
> is:
wether your computer can handle or not the fancy 3D rendering, level
>
must be playable anywhere. This is important from a network point of
>
view. I don't want some players to be excluded because they don't have
a
> given rendering capability.
>
> Apart from that,
anything is feasible.
My idea uses 3D, yes. But I wouldn't call it
"fancy" 3D, since only the warriors are shown in 3d, while texture.jpeg are
displayed the same way as in all my previous levels. Even the default menu is
more fancy, since the cylinders contain shadows!
The method has been
used in a lot of earlier adventure games, but has died out since modern
machines are able to display the locations in real 3D. But I think it still as
some potential combined with some good artwork.
The level could also
have an alternative texture, which is used to display the level in the
usual, flat view. That way the level could be rendered on all
machines.
I have attached 3d.jpeg to show the concept:
1st
illustration shows the warrior layer in normal, flat view.
2nd illustration
shows the warrior layer in 3D view.
3rd illustration are the
texture.jpeg which are placed below the 3D warrior
layer.
- Kasper