I would still use a mesh, but remember as we discussed long ago you
still need the graphic representation _and_ the game logic data. i.e.:
the mesh and then something to describe types of terrain, obstacles,
buildings, and so on.
> Any help in the networking would be awesome Markus, actually, quick
> question, I'm using a simple twisted.internet.protocol TCP server. Is there
> any way of accessing all current client transports, or only the current one
> that sent a request (or other signal...)?
Solved in IRC, in case anyone is wondering. ;)
Greetings,
-Markus
I would still use a mesh, but remember as we discussed long ago you
still need the graphic representation _and_ the game logic data. i.e.:
the mesh and then something to describe types of terrain, obstacles,
buildings, and so on.
Yes, you really do need a map editor to keep everything in sync.
Though you could edit the mesh in Blender and then derive things like
heights from the actual mesh data.
As far as formats are concerned, one thing that comes to mind is if
your mesh is in obj format, all the other data can be prefixed with a
comment that way you don't have to accomodate for extra data in any
loaders or break compatibility. This would work for any text based
model format that supports comments or extra data.
-Markus
Are you talking about this proposal?
http://code.google.com/p/galaxymageredux/wiki/Test
If so, I think that one was never really fleshed out well, nor does it
use complete Python syntax. IIRC, aj was against Python as a file
format, whereas everyone else was for it. RB's proposal[1] seems to be
the only one that definitely uses Python directly. I know I intended
to use Python directly in my proposal[2] because I based it off the
original GalaxyMage map format which did also, but now that I look at
it, it clearly is not valid syntax either.
Now that I have reread aj's proposal, I am recalling some issues that
we had to deal with. The reason for separating the mesh and map
description file is because the server has no need for the _art_ data,
it just needs to know the properties of the map, not where individual
vertices are.
Also, the advantage of the mesh was that it allowed you to create a
more detailed visual representation that would not have to match the
grid exactly. You could have various lumps, holes, ridges, draws, and
so on. If you do this, then it makes it very difficult or impossible
to describe the map merely from the mesh itself.
Ugh, now I am starting to favor the procedural method again. Partly
because it seems simpler and RB already had it working(!). I am rather
okay with this game's terrain not being much more sophisticated than
FFT's. Maybe a little more visual appealing and we had already agreed
to use a perspective camera rather than the orthogonal one in FFT.
> But suppose we have multiple files: a 3d model file of the terrain, a few 3d
> models of buildings and shrubberies, and a game map specification file. We
> can archive the files into a gzipped tar and use python's tarfile
> (http://docs.python.org/library/tarfile.html) module to load each file from
> the "maparchive.tar.gz" Which would really be great if we use mostly text
> based files like xml, py, obj, svg, txt, etc. because text compress at
> insane ratios using deflate.
This is an interesting idea. I can see a couple problems though. For
one thing, various models like buildings, shrubberies, trees, and so
on should be shared between maps, so you would not want to package
them up with one map.
Second, subversion is very bad at handling binary files. It has to
store a complete copy of each version of a binary file, so packaging
up text files into a binary file is a huge disadvantage in subversion.
Third, if we want to keep client data out of a server distribution
this again becomes a problem because we cannot separate the abstract
map file from the art file. Personally, I really hate it when a game
server running as a daemon needs to have models, textures, sounds, and
all other things which only clients will actually _use_.
Greetings,
-Markus
[1] http://code.google.com/p/galaxymageredux/wiki/FileHandling
[2] http://code.google.com/p/galaxymageredux/wiki/MapFileFormat
IIRC, there should still be some pathfinding code in svn that Alex
committed. Not sure how advanced it got or if handled cliffs or
anything, but it should at least do obstructions.
> Based on what I am seeing right now I think the procedural approach would be
> best. We already know it works, it has the advantage that the server won't
> need the data even present to parse, and it can allow multiple height
> easily.
Sounds good to me.
> Now the problem I have with that is feasibility - I know we have been
> planning for multiple heights since the beginning - but I can see serious
> issues with having larger maps that have lots of floors and such - ie, how
> will the camera handle? Unless you add something like collision detection
> for the terrain and view rays and such, the unit you are looking at will
> either be behind terrain, or the camera will be in it an aweful lot :S
I think for the most part map makers will just have to restrict
themselves. Multiple 'floors' is really not what we are trying to do.
We are just trying to allow for things like bridges, overhangs, and so
on. Simple extensions to an otherwise convex geometry. Basically what
FFT did. They certainly didn't go overboard with the idea.
Another $0.02 of mine.
-Markus