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
3d.jpeg