palito-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [palito-dev] Some questions about Palito


From: Tom Barnes-Lawrence
Subject: Re: [palito-dev] Some questions about Palito
Date: Sat, 28 Jun 2003 01:58:40 +0100
User-agent: Mutt/1.3.28i

On Thu, Jun 26, 2003 at 08:31:26PM -0300, address@hidden wrote:
> 
> i will try to answer the better i can now,
> but barrett must be coming soon...
> ...he probably will have better answers for your questions.

OK, I'll remember that.


> > -Palito clearly isn't meant to be an exact clone of Total Annihilation, as
> > it looks so different. And it looks like the units are meant to be different
> > to TAs, too. But is the actual engine of Palito meant to be exactly the
> > same as TA, or just similar? I would quite like it if I could make it
> > exactly like TA by using the stats of TA's units.
> 
> 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?

 Only I saw earlier posts discussing things like how to work out how much
resources should be required for repairs, saying that it should take some
amount of metal equivalent to damage taken, and such things, but the TA
strategy book I've got says that repair should take only energy, and no
metal. Things like that.

 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.

> > -Flush is a pretty cool system, it reminds me of a LOGO-like program I
> > wrote a while back (but much better!). I'd like to understand it much
> > better (the documentation for it is pretty short...). But as this display
> > shows units from directly above (unlike TA), won't this make it hard to
> > clearly show units like radar? I'm sure many such things could be very
> > hard to recognise from such a view.
> 
> 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...


> > -What things are stopping the client-server code from being finished?
> 
> real-life or something like it ;)
> besides that, we were discussing possibilities of how to implement it,
> some maybe-too-complex-for-now ... but seems that barrett already found
> his path on it.. he were advancing considerably just before he leave.

  Well that's cool, then. I think this would be one of the most important
things for Palito at the moment.


> > -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.
> 
> we are aiming to one-big-picture maps.. no tiles yet, and i dont know if
> ever be any.. there is enough memory for that today.. what you think?
> 
> ah.. there's other possibility been explored.. fractal/procedural maps..
> ..its a low-memory high-cpu alternative for one-big-picture maps.

 Sorry, I think I didn't explain my idea well.
 I wasn't thinking about savings of memory, that didn't even occur to me.

 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.

 Each tile had a different appearance, and maybe showed a flat area
with a metal patch, or a small hill, or the left-slope of a big hill, or
2 different levels of flat land (like on Core Prime maps) with a small
ramp between them, and so on. They also had the heightmap associated with
them (that maybe wasn't 100% the same as what they showed, but was very
similar). IIRC they also released new tilesets to download, too.

 Now, maybe maps made by this wouldn't be saved with a file-format that
looked like lots of different tiles, maybe it would be saved as one huge
image and one huge heightmap. Or maybe not, so that the map editor could
change it easily. But the *advantage* here, is that you can decide lots
of features that would be good in a map, create simple heightmaps for them
(possibly rendering the pictures automatically from the heightmap), and
then by using such a map-editor, anybody can create LOTS of cool maps
quickly and easily.

 Using such a scheme prolly wouldn't stop you also having a built-in
random map generator that just makes one huge heightmap (and then renders
an image for that as with the tiles).

 Rendering images from heightmaps could be done by applying a shallow
noise to the heightmap, and then passing that to some very simple
renderer just for Palito: maybe render each point with just flat shading
(maybe add small specular highlights too), with no calculation of shadows
from other points. Such a scheme would prolly be very quick and it wouldn't
matter if it didn't look exactly the same.
 Map types like the Core Prime maps TA has (maybe Palito could have City
maps or something instead) could be done differently. Presumably a 3d tilable
texture that could be applied through all the surfaces, and then a heightmap
could be worked out that gave walls and things as appropriate. Er.

 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.

Just my thoughts,
  Tomble




reply via email to

[Prev in Thread] Current Thread [Next in Thread]