OK...

[RB[0]]

As you may have read, I have been planning on using the PYGGEL 3D
engine I have been developing for GMR.
I have just released the second version of it now - and it has all the
features I think we will need for the game, so I am going to start
setting a very basic 3d world viewer we can begin to build on over the
next week.

Cheers,
Matt

[Markus Martin]

Looks like things are coming along quite nicely. Just checked out svn
head and things are looking nice. Robocalypto was interesting.
Performance seems to be a bit of an issue and things aren't incredibly
smooth sometimes. I'll be interested to see your progress though.

Best of luck.
-Markus

2008/12/15 RB[0] <Roe...@gmail.com>:

[Robert Ramsay]

PYGGEL looks great. I don't think that aj's code for the battle
engine was worth removing. But it's still in devel, so if it is
useful we can just bring it back. I guess this begs the question are
any of the Wiki's obsolete?

[Joseph Hager]

I would say that all the old code and wiki pages are most likely obsolete.  Matt is starting fresh here.  The only thing I really had in there was some network code examples.  There might be something useful in there, but I doubt it. 

Looking great so far Matt. Can't wait to play it sometime in the future. Good luck!

[RB[0]]

Thanks guys :)
Yeah, I plan on moving the stuff of aj's that is compatible back here, but I wanted to get the basic code set up again so we can get moving.
About the wiki, I am looking at it now.
I think most of the logic oriented stuff will still be applicable, assuming we actually remember to adhere to it. I guess we just have to decide - do we want to keep that model we laid out before? I think so, we will probably change some things, but it will save us a lot of work now if we capitalize on the work we did there.

As far as the story - I'm not sure about the current one, it just doesn't seem "right" to me.
As far as 3d models - I am thinking perhaps we should go back to the billboarded sprites from the original Galaxymage. The reason being is that the "great" GMRM mesh format Markus and I cooked up earlier this year failed miserably, due to some differences between how we load it and blender presents it for saving.
There is a basic OBJ file loader in PYGGEL, and the next version will hopefully provide a cal3d loader - but for now I think the sprite method will be the simplest.

Otherwise I think most of the stuff is ok.
But I am definitely going to keep the network stuff from before, because I don't have a lot of experience with twisted myself. Similarly I don't have any experience with unittests - so you probably won't see many from me.
That is a problem, but mostly based on how I code which is very lazy. I really think we need them, because what killed the original GalaxyMage project, IIRC.

One thing I will probably remove for the time being is the map-editor proposal. I think ajhagers original suggestion of using a mesh for the map is a good idea. We will simply divide the mesh by tile size for each tile, and then we don't need anything special in the code to even, say, make insanely awesome looking terrain.

Cheers all :)

[Robert Ramsay]

That seems to match my thinking. What I'm interested in helping out
with is the Wiki, the battle engine logic, and unittesting. First
thing is that I need membership to the galaxymageredux project, but I
can also help out with PYGGEL if you would like.

Tonight I'm going to try out PYGGEL with some of my girlfriend's 3d
models.

Thanks.

> On Wed, Dec 17, 2008 at 1:56 AM, Joseph Hager <ajha...@gmail.com> wrote:
> > I would say that all the old code and wiki pages are most likely obsolete.
> > Matt is starting fresh here. The only thing I really had in there was some
> > network code examples. There might be something useful in there, but I
> > doubt it.
>
> > Looking great so far Matt. Can't wait to play it sometime in the future.
> > Good luck!
>

[RB[0]]

Unittesting help would be great - as I have zero experience there - and, to be fair, I have generally had a bad view on it, but that is changing ;)
I will set you up with membership to both GMR and PYGGEL immediately now :)

Looking through it, I think we may end up changing the battle system and such - I am writing up some networking code, but basically, I think we can write something that is way more straight-forward and simple, and still achieve the same result. But we can look at that once we have something we can put it in :)

Cheers

[Markus Martin]

Sounds like a good plan, RB. I am pretty busy with my current project
(in C++ *gasp*), but I would be happy work on some network code or
other things in general as the project moves along a bit.

Also, I would also be in favor of re-using as much as possible. Then
less of our time before seems "wasted". I guess we did learn a few
things along the way though. ;)

Speaking of which, I would like to know why MapFileFormat was outright
deleted from the wiki with no explanation. There are two other pages
which cover this topic with conflicting information (Test and
FileHandling). Rather misleading titles too.

-Markus

2008/12/17 RB[0] <roe...@gmail.com>:

[RB[0]]

Hmm, I think I will restore that. I have not truly decided whether we will use that or the OBJ loader method we also discussed. I am still weighing pros and cons (though I do see how my previous post made it appear like I had come to a hard decision, sorry)

At this point I have not come to any firm conclusions for what we will do differently than before, mostly I am musing to myself a lot of the time. That can get kind of confusing at times (just ask Markus or aj LOL)...

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...)?

Cheers :)

[Markus Martin]

2008/12/17 RB[0] <roe...@gmail.com>:

> Hmm, I think I will restore that. I have not truly decided whether we will
> use that or the OBJ loader method we also discussed. I am still weighing
> pros and cons (though I do see how my previous post made it appear like I
> had come to a hard decision, sorry)

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

[RB[0]]

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.

Well, the issue then is you would then need to have two files, or somehow encode the data in the mesh...
I don't know, I was thinking perhaps just a simple mapeditor (pretty quick to whip up)  that will just save stuff for whatever terrain you want...

[Markus Martin]

2008/12/19 RB[0] <roe...@gmail.com>:

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

[Robert Ramsay]

I was thinking the same thing: the comments would be a great way to added game specific information to the .obj files.  And of course we could either have a basic map format that is upconverted to a 3d object file with game data in comments, or just extrapolate game data from the models themselves.

Currently, I think the simple effective format that AJ posted in the wiki is good for three reasons.  First, it can be used directly by the battle engine because it's just a python file with the definition of a multidimensional array.  Second, it can easily link to it's own 3d model.  Also, FFT has some rather simple battle maps, which could be easily replicated with flat square tiles at varying heights on a 10 by 10 (or so...) grid.

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.

--
Rock. Revolt. Rinse. Repeat. Robert Ramsay

[Markus Martin]

2008/12/19 Robert Ramsay <dura...@gmail.com>:

> Currently, I think the simple effective format that AJ posted in the wiki is
> good for three reasons. First, it can be used directly by the battle engine
> because it's just a python file with the definition of a multidimensional
> array. Second, it can easily link to it's own 3d model. Also, FFT has some
> rather simple battle maps, which could be easily replicated with flat square
> tiles at varying heights on a 10 by 10 (or so...) grid.

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

[RB[0]]

Ok, I did not read *everything* in all those posts, I only have a sec so I skimmed ;)

For the map format - the tiles are not going to be simply flat, IIRC in my devel branch I have a map_example or something that shows what I had in mind - which was the primary reason for wanting a mesh, so we could have as detailed or not as an artist wants. The one in my example, like Markus said, is procedural, ie, each tile has a height, and then it's edges go to the midpoint between it and the tile next to it, that should be enough, but artists may prefer the mesh format if they want absolute control...

Now, as far as the server - I intended to make the server actually know the vertices, and use those to derive the cliffs, movement costs, etc. from. That way, instead of the map maker having to define those, you have one uniform way to handle them, which is a must for me. With the procedural one, you simply check the height of the tile against the height next to it to see if it is a cliff, if not it will slope and a movement cost will be imposed based on the difference - cliff would be impassible.
The server will not need to have the render data - in fact parsing it will probably just toss it out - each client will oad their own copy anyways.

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.

I am thinking up a simple map editor right now, but basically you would simple store a group for each level of height for the map. The map would always have one level - the floor, this can vary in height all over the place, but it is still in the first level. Then you could more levels for bridges and such.

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

Cheers

[Markus Martin]

2008/12/20 RB[0] <roe...@gmail.com>:

> Now, as far as the server - I intended to make the server actually know the
> vertices, and use those to derive the cliffs, movement costs, etc. from.
> That way, instead of the map maker having to define those, you have one
> uniform way to handle them, which is a must for me. With the procedural one,
> you simply check the height of the tile against the height next to it to see
> if it is a cliff, if not it will slope and a movement cost will be imposed
> based on the difference - cliff would be impassible.

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

[RB[0]]

Pathfinding code? I'll have to look into that :)
Do you know which dev area that would be in?

Otherwise yeah - I think that we could do overhangs that way - not like the map controls will be hard, so meh, we'll see...

Thanks for the $.02 - only $75k more to go :P