Re: [Adonthell-artwork] v0.4 gfx request

[cirrus]

Kai Sterker wrote:
> 
> You might think it is a bit early for this, but IMO we should start with
> making the graphics for v0.4 ASAP, i.e. now. One thing that delayed v0.3
> was that work on the data did not start before the engine was almost
> complete.
> 
> This time we shouldn't make the same mistake. So here's a request for the
> graphics we will need. If you read the v0.4 plot proposal, you should
> already have a pretty good idea which that are, but I'd like to go a bit
> more into detail.
> 

Hmmm... well, I do want to start gfx asap but I don't think that is now.
Ben and I wanted to spend some time making some proper rules for the
naming of gfx files and the directory structure of the mapobjects tree.
This is related to the mapeditor too - we had some ideas of naming
convetions that would allow the editor to automate things. For example,
if we say animation frames must be named file_f01, file_f02, ...
file_fnn then choosing one of those files could case the editor to
automatically load all the other frames. And that's just one of many
ideas. Also I've found it helps a lot when designing gfx to have a
fairly detailed understanding of how they are used by the mapengine. I
don't think I would have had the walkable veranda idea if I didn't
understand how the gfx worked.

Basically what I'm saying is that there a few conventions that need
sorting out and I'd like to have some exact definitions of how the
mapengines new features will work before doing any serious gfx.


> Espacially for the forest I would like to see a 'real' forest, with each
> tree being a single mapobject, like the tree in the yard of the Redwyne
> Inn (and unlike the surrounding wood or the forest of v0.2).
> 
> The most important reason for this (apart from my personal dislike of the
> 'forest pattern') is that you cannot go exploring away from the roads that
> cut through the forest. You can only follow the roads, and that is pretty
> boring and also gives away good opportunities for secrets and such for no
> apparent reason.
> 

I had considered that approach for 0.3 but dismissed it because the
forest wasn't really used (it was just decoration) and I was worried
about performance - wouldn't that approach mean a LOT of transparency
calculations? I suppose on newer machines it's not such an issue but it
might be worth thinking about.
I think for th outside forest edges a mixture might be a good idea - the
is a forest texture (remember you can have a selection of compatible
tiles to vary it a bit) with some individual trees to make it more
interesting (and perhaps hide the odd item) but if you walk into the
forest you switch to a submap where the trees are individual and the
treetops are left away.

This is a bit more realistic since the trees you find in a forest will
be, say 4-5 times as tall as you whereas the ones towards the edge will
often be lower. Also, you wouldn't see the character most of the time if
you are looking in from above the treetops! What I imagine is tht most
forests will have a few obvious entrances and the once the player
disappers below the treetops the view changes to the inside and you can
wander around more freely.


> It's also much easier to make a good looking forest that way. Given a
> large enough number of trees and bushes, you will get visuals that are far
> superior than a repeating forest pattern.
> 

It's easier to make the gfx too! :) No need to worry about seamless
tiling!

> The trees itself could be made up of a trunk, the top (what's the right
> word for that, btw.?) and the actual leaves. The leaves could be available
> in versions for spring, summer, autumn and winter. Basically, a tree is
> then composed of three parts. Say if we had 3 trunks, 3 tops and 3 leaves,
> we could already make 3*3*3 = 27 (slightly) different trees. Say, we have
> 5 to 10 different 'tree-sets', that should make an impressive forest
> already.
> 

I don't know about seperating trunks and treetops. Perhaps not on every
tree but we can off some that have that capability. As for the leaves: I
was hoping the mapengine will be able to change the hue of graphics on
the fly (once we add weather/season fx) and so I though of making leaf
gfx as if it was summer and come autumn they just get turned orangy (if
this is done on the fly we can have a smoother transition too - it could
fade from one to the other over say one game week) by the engine. As
winter begins the leaf gfx could just fade out gradually and if there
hapens to be snow we fade in a snow pic for that tree (made so it
matches the branches of the tree). That way trees only need one leaf
graphic and one snow one AND you get nicer transitions.

That reminds me of another graphics convention I'd like to introduce -
all graphics should be designed so they look like they are being seen on
a sunny summer day. Darkening them at night (and perhaps tinting them
blueish a bit aswell), making them more grey (ie reducing saturation) in
winter or when it is raining and so on should all be handled by the
engine. For that to work convincingly the raw gfx need to be the same.

> Oh, and the leaves could be animated, as if they were moving in the
> wind :).

By all means :) That could be controlled by python right? So if there's
no wind it just stays on one frame but in bad weather it plays the anim.

> 
> Needless to say that the trees can be reused in the final game. The same
> is true for the mountains, the mines of Uzdun'kal.
> 
> Depending how the hiding place would look like, it might also be reuseable.


Hiding place? Is there already a 0.4 plot??


        -James
-- 
   ___    ___  ___       ___ 
  /    / /__/ /__/ /  / /__                 Reg. Linux User #148821
 /___ / / \  / \  /__/ ___/@linuxgames.com  www.twiddles.com
                                            adonthell.linuxgames.com