Re: [glob2-devel] globulation graphic

[Stéphane Magnenat]

Hi,

I will continue to answer you questions/suggestions:

> 3 about the water... with 3 overlapping layers moving with different angles 
> i could make some "morelookinglike" water^^

If you provide us with the graphics, adapting the code is easy. We probably 
need a single layer for "low-quality" graphics, for people that use the 
software renderer.

> 4 the area borders should have a lower alpha.

Do you mean the same colors with alpha? Which percentage of alpha would you 
like to? It is very to change in the code :-)

> 5 adding 2 algorythms to the map generation:
> tile duplication check based on a per tile grid check, to avoid massing 
> of identical tiles in the same space.

Do you have a suggestions for this? Such as always taking a different tile then 
the one at top and at right?

> tile incidence, to add "special tiles" to the map less times than "common
> tiles" based on a 0-7x70% 8-11x20 12-15x10% for both 16 grass and 16 
> sand tiles

Ok, we can do it indeed. Do you need more then 16 tiles or 16 is enough?

> 6 (i know this one is weird) fix the pixel lines of the areas so it s drawn
> only in the inner side of the box (if you notice, there is a pixel glitch^^)

I am not sure to understand, can you send us an annotated screenshot?

> 7 make the working/harvesting dots of the buildings 1 pixel wider and higher

Ok for me. Who does this? Do we still have a TODO list?

> 8 draw put the miniressources in the middle of the unit's graphical square,
> so it can be integrated with a new unit animation set which may seem that
> the unit is actually "carrying" the resource.

The is interesting. So you would like to have the same amount of frame for 
miniresources then for the unit? Here as well, if you provide us with the 
graphics we can very easily to adapt the code. In general, the graphics code 
is easy to change, because you can quickly see the result :-)

> 9 draw the units/buildings hp and hungry points only when a key is pressed
> or when they are below 25% (since the unit movement is automatic you dont
> really need to know it everytime)

That is interesting. Historically it was disabled by default and a key showed 
it. I let the hardcore gamer choose, but you proposition is nice. What does 
the community thinks about it?

> 10 the stones only show from 2/5 to 5/5, the 1/5 is missing

Hum that is a bug, do we have an open bug on it? So it appears in the map 
editor right? Can the people who rewrote the map editor have a look at it?

> 11 (this requires a bit more time) add a 3rd tileset "unbuildable" (like
> rocks) so the sand becomes buildable and the terrain can have a really nicer
> variety. the new tilesets should be 16 rocks (for example), the rock-sand
> transitions and the rock-water transitions.

I agree that it would be very nice, and confirm that it would require much 
tuning in the code, but it is probably not that difficult to do, and could add 
a 
much more 3D feeling to the game. So if you do the graphics, I would try to 
adapt the code as well, even if I have few time to work on glob2.

> 12 change the circle for selected units, add some png for it for 1x1 2x2
> 3x3... so they can be changed ;)

That is a nice proposal. If you provide us with the graphics, we can adapt the 
code.

> 13 add a 4 or 8 frames based animation to buildings for when they are
> working, just a simple loop (even just based on the alpha of the player
> color mask) so it doesn't look too static

Actually there is different frames for the building but they show the level of 
destruction. We can change this and add support for animations in the normal 
frames and support for destruction by appending some -destruction to the 
sprite name. Or we can do as you propose, by alternating between two slightly 
different hue. What do the other people think?

> 14 (maybe needed) add a percentage based building reference png, like at
> least 0% and 50% (even for buildings that builds at once, just for further
> improvements)

I do not understand, we already have frame for buildings in progress. It is 
named: BUILDINGNAME|LEVEL|c|FRAME_NUMBER.png (substitute the words in captial 
with actual words and remove the | to get the final filename).

> 15 for the sake of who is doing the graphic, can you read some of the files
> in a texture all at once instead of composing it from hundreads of many
> little files?^^
> it would be really nice to store the unit movement animations in a single
> tiled file instead of having like 128 of them^^

Well, this is a problem if the frames have a different sizes. However, for 
images of all the same size, we can add support for this in addition to the 
normal ones. If you provide us with images of this type, that is, with a 
single line of frames (not a 2D grid, it adds complexity) of all the same 
width, we can imagine to write the width in the filename and let the image 
loader do the cut.

> gameplay suggestions:
> I know that the game is not finished yet and you will add more units and
> buildings but honestly I would change 2 things:
> 1 make the swarm tiles 5x5 instead of 4x4, since it is the main building and
> reduce by 2 the racetrack and the swimming pool (it's my personal opinion,
> but the game is already nice as it is).

We have already reduced the racetrace and swimming pool with respect to 
original size. For the swarm, I let the hardcore players to decide, they have 
better experience. Anyway that is technically easy to do because specifications 
of buildings such as width/height are written in a text file.

> 2 this should be really needed, move the units according to distance and not
> tiles. i' ve noticed units move faster on the diagonals and always occupy
> the center of the square. doesn't look that nice. probably this is the only
> game feature I would really work on. then give them a 16 steps of rotations
> instead of 8.

That would mean a big change in the engine. I do not see how to do it easily 
with the current engine. Adding the number of frame is easier to do.

> bugs:
> when you draw an area then switch add/remove, then u delete an area
> overlapping another one, if you switch to the other overlaying area later,
> the last square added or deleted of the first area is added or deleted to the
> second one too.

Ok. Leo, do we know this bug?

Have a nice day,

Steph

-- 
http://stephane.magnenat.net