Sonarpulse

Well, the "scaling" issue with number 2 is presumably we want game speed to depend on real world distance, not game tile distance. So we'd need to get the inverse of the terrain stretching and use it as a coefficient for unit tiles/second seeds. Then we would need to feed this same information to the pathfinder, or else it could only figure out the fastest path based on the number of tiles, not real-world distance.

I've personally only really used 3ds Max, but I think if you really want to get into making things for 0ad, Blender is the way to go as the team moves in that direction. If you want to get the stuff you make included in the game, blender files will probably be easier to maintain in the long run.

The issue ASIAK is that the game expects one location per given X and Y, but with an overhang you have two. That said: Fake it method 1: You can chop things and pretend either the overhang or the area below it doesn't exist for game-play. Fake it method 2: With any surface "topological equivalent" (you know the whole donught = mug thing), you can fake it be distorting your coordinates (that's what I meant when i was joking about non-Euclidean.) However then either your pathfinder act dummer, or you need to teach it about stretching which will slow things down. When you can't fake it: things like bridges act are like portals in Portal if you try to stay 2D. Clearly path-finding would really need to be changed to get that to work automatically. (might be neat for pyrogenisis though beyond 0ad seeing the use of teleporters in other RTSs.)

Well for part two it would be fun to have full 3D gameplay. Even if some things (bridges, walking on walls, sapping/tunneling, etc.) can be faked without it, 3D gameplay will lead to a much more robust solution. @zoot even the slightest overhang technically causes those problems. In minor instances, the over extended cliff or covered area below can be ignored like historic_bruno said though. Another solution for increased detail maybe is to sorta mip-map a heightmap based on the slope of a lower resolution. So for example with really flat surfaces the game sample like 4 points for every 4 tiles (making 1 terrain tile for every 4 game types), and on cliffs it samples 9 points for every 1 tile (making 4 terrain tiles for every 1 game tile). Hopefully that makes some sense.

Well, if you have stretched tiles such as you say, then you can do 2D non-euclidean pathfinding, but I think we should keep relativity out of RTSs

I'll admit that I initially asked just out of curiosity, but a potential use would be to know for sure who you are playing. (password protection or even more secure with OTR chat)

Game time affects would be cool too. The implementation I linked works by analyzing the path of water droplets, so as opposed to simulating a bunch at once and then deforming the terrain, one simulate a few and repeat, deforming the terrain in tandem. On the other hand erosion like this an extremely slow process, so I'm not sure how much sense it would make. The primary goal in my mind was to allow maps to (optionally of course) mold really geometric terrain to focus on sheer gameplay (or what ever else), and then let the erosion tool make everything look natural.

Basically with normal multi-planer projection, one uses the same texture for all perspective. I am saying based on the direction the surface normal faces, a different texture is projected. (I edited my first post to make the angles clearer.) E.G. for very horizontal normals (i.e. very steep surfaces, a rock/cliff texture is used, but for very vertical surface normals (i.e. flat surfaces), a grass texture is used.

OK, I actually look a look at atlas, I believe with the current resolution, both heightmaps and vector fields will inherently look about as unrealistic as height maps do now. You may fine some things better with vector fields, but unless you seriously "steal" vertices from flat areas, you just need more data for realistic terrain. On a related note, I think it would be really could get an erosion in atlas (and for random map generators). http://ranmantaru.co...ghtmap-terrain/ seems to have a pretty good idea, and it includes the full source code. (though personally I think the result would be better if a few constants were tweaked).

Cliff textures and "multi-planer" can be combined for super basic "biomes" That would a normal ground type: Then a biome would select different versions of the above based on the angles things faced. You could do things like IF 75-90 degrees (polar angle of normal) THEN clifrock Else If 180-270 degrees (azimuthal angle) THEN snow grass mix ELSE snow This would sort of blur the distinction between manual and generated maps, making both tasks easier. Of course, if map-makers didn't like the way something looked, they could override with a forced normal ground type too. azimuthal angle, and polar angle

I guess it does a bit, but their not too important to the effect. For me, while cliffs are important, what is even more important to recognize, is that erosion shapes values into kind of tree-fractaly things, Simply changing the resolution of the height map solves that. Anyways, my general point is vector fields look nice, but let's push their present setup to it's artistic limit first. This program http://en.wikipedia.org/wiki/Terragen , is pretty well known, and checkout all the things done with it and height maps: http://www.google.com/search?tbm=isch&q=terragen .

can you attach the 0ad client to an existing xmpp account then?

I think the issue is that with heightmaps, the horizontal and lateral coordinates of each point are fixed, so it's easier to figure out where people can go. However, as long as terrain is not deformable, you can probably bake one of your vector fields to a heightmap for pathfinding purposes pretty easily. More importantly though, anything without overhangs can be done with heightmaps, so that big cliff for example is totally fair play. It's just requires more work making the heightmap.

Well, just try it! may not be to long to tell

Yeah, both in-game and lobby chat could be done with IRC (if game is passworded, channel for chat has corresponding password and synchronous login). I think the cncnet thing I linked to has some sort of server implementation as in IRC module too. For LAN play, is their any standard scheme for IRC without a server?

Cool!

Honestly, your knowledge of those languages is probably good enough to let you do JavaScript. There might be some corner cases where doing something in a Java/C# way will introduce a bug or other unexpected behavior, but you'll be able to do 75% of a task not worrying about the differences. For me, the best way to learn a new language is just to dive right in, and C#, Java, and JavaScript are clearly similar enough for you to do that.

Is this template file the last thing needed before 3ds Max can be dispensed with altogether?

Eh, I like having the consistent border for icons. Also, to harken back to the debate a couple pages ago, I think a tech tree like AoK's, but interactive, would be a perfect additional way to research tech. Obviously for skilled players it just slows things down, but for new players, it allows them to get a feel for the civilization they are playing with, and the choices they will face.

You made a very elegant picture of it. Yes it's way more convoluted than the current way of delivering binaries, but I'm pretty sure moving to git (or something similar) will be absolutely essential when games beside 0ad are built on pyrogensis. So might as well make the change at some point ahead of time. Edit, well I had "Code" and "Binaries" as two different branches of the same repository, and "Data" as being configured to pull either repository, but it doesn't really matter and the picture works either way.

I don't know if this works with git sub modules, but there are so called "shallow clones" where git only clones the latest couple revisions. Problem is they come with a number of limitations which may make updating difficult.

Check out this: http://cncnet.org/ code is https://github.com/hifi/cncnet I have personally used this framework a bunch, and I'm pretty sure it solves, or paves the way to solving most everything people want here. Furthermore, I believe it's pretty game/protocol-agnostic at the moment.

Well, let me just through this out here: For people interested in FOSS highly portable games, projects like this are more captivating because they are under constant development. I know I for one got over Minecraft about the same time it was finished. Even with the most radical game, once you "beat it" (or multiplayer seems to hold no new surprises), that's it, the game has nothing more to offer. With a game always in development, the replay value is endless because there is always something new. While it is important to prepare the occasional stable snapshot for those "conventional types" interested in polish (who I imagine are little into 0ad at the moment) when the time is ripe, I would be perfectly happy of development of pyrogenisis carried on indefinitely, with the goal of basically making the engine the superset of every other RTS engine ever

Well this has been discussed to death, but perhaps a two-repository idea would with with git sub modules: http://git-scm.com/book/en/Git-Tools-Submodules . Everything programers use is in one repository. A script clones each new revision of the master branch into a mirror branch of precompiled binaries. Artists check out an art repository, which bulls the recompiled branch of the engine repository automatically.

Wow! That looks great!