Re: [palito-dev] Some questions about Palito

[zed]

> On Thu, Jun 26, 2003 at 08:31:26PM -0300, address@hidden wrote:
> > > -Palito clearly isn't meant to be an exact clone of Total Annihilation, as
> > 
> > we are mimicking only the game design.. but i see little problem in copy
> > the stats as well, at least for a game mod ("TA Classic" or something)
> 
>  Sorry, I'm not understanding exactly: "we are mimicking only the game
> design", do you mean that game design won't be exactly the same, OR
> that the game design *is* meant to be exactly the same, but nothing else is?

TA game design is the starting point, but we are not strict to it.

>  I'm sure it wouldn't be possible to make *every* detail of Palito's game
> engine act like TA, but it'd be nice if it could act as similar as possible,
> to allow for a game using TA units to seem like the original.

as i said, ideally we would have the engine modular enough to 
make it possible to implement a game pretty like totala
(at least on it's game design, maybe not the visuals..)

but it shoud be only one mode of game. i think there should be others,
more interesting modes, like we always wanted to have while we played TA.

> > 
> > we are aiming for 2d initially (for simplicity), but 3d improvements are 
> > starting to show up (the height field, for example, also the aircrafts).
> > maybe there will be a opengl version with some TA-like perspective.
> 
>  After looking a bit deeper at Flush, it's looking a lot like OpenGL
> anyways, with the stacks of transformation matrices... Very neat!
> 
>  But last night I tried to learn a bit about it, by making my own unit
> (an Energy Storage building). I didn't really understand what the  { }
> brackets were for, except they seem to go with the "push" command. I
> also found that the "rgb" command doesn't seem to have any effect at all!
> I had a go at putting a line like
>  flush_fg(rgb2int(r0,r1,r2));
> in the case ITR_RGB:  section of cpu.c, and this seemed to make it work a
> bit, but I couldn't get anything to be filled in with the colour I chose,
> until I changed flush_fg() to flush_fgbg() instead. I don't know if
> these things have been forgotten there, or if they're meant to be done
> somewhere else, or what.
> 
> I guess all the units are getting drawn in blue because that's the team
> colours, but it'd be pretty bad if all a teams units were all just one
> colour...

barrett were working on it, the interface to control the colors and fill
changed 2 or 3 times recently..  but he's back from his trip.. 
i hope he will answer all our questions very soon.

> 
> > > -As you want to implement maps with pictures and heightmaps, do you plan
> > > on using the method that TA used (maybe it was only for the Core Prime 
> > > maps,
> > > I don't remember) of having lots of preset tiles that each have a picture
> > > and heightmap, that then get put together into one big map? It sounds like
> > > a good way to help lots of maps to be made.
> 
>  You guys had been talking on your website about ways to get good maps,
> and using program X and Y and having a heightfield, and so on.
> But TA's *map editor* just had lots and lots of tiles (of different sizes,
> IIRC, but generally squares that were maybe 6 solar-collectors wide or so),
> that you could put together very easily into a nice big map.

i see, you are thinking about tile presets to make it easier to the users
to build maps..  i am just thought that it can be done with photoshop,
and probably gimp, very easily .. chaining two layers of texture and heightmap
for a tile, and moving them together, duplicating and even fixing the seams
between them, on areas they dont connect too well.  this would be a simple 
version of map editor using tiles.. our worst problem about it is still the 
art, 
thats why we have a sticky-game (well... despite the fact it is pretty cool ;)

without tiles it can be done with a heightfield generator (fractal or something)
and povray for the surface texture... or bryce for both. (the 1st version of 
the maps [palito.9hells.org/data] were made on bryce.. as many great TA maps)

> 
>  But where would the metal deposits be defined? Perhaps it could be defined
> in the heightmap (maybe flip a bit to show metal), but that doesn't sound
> very good, it might make the code that uses the heightmap slower. *shrug*
> I suppose metal deposits would want about 2 (or 3?) bits to describe how
> much metal there is. And maybe as deposits are usually in patches of a
> certain size, it could be defined in a different bitmap that was much
> lower resolution than the heightmap.

we were thinking about it.. a separate bitmap seems good,
maybe with the blue component being the metal, 
the green being vegetation.. and the red lava or something else =)
.. it wastes a bit. but will be fine for a start.

the idea is to have a texture map, a height map and a "feature" map.