FeXoR

Thx! It might take a while though until I focus on terrain texture and props. First some general problems have to be solved. Circular maps will be supported, yep. Fell free to use everything as you see fit. If you have a better graphics card you can make better screenshots on your own. I don't think a number (like 11001011...) can be stolen at all. In my world such things are not "owned" by anyone. Nice of you to ask though! I'm not as flexible as your spelling of my name might hypothesize. But sometimes I'm a bit inordinate so my name is fexor (more like Latin ferox or English ferocious).

Yes, we could scale the randomness/roughness depending on the distance to the start locations. Yes. Thats how Island or Lake type maps would be defined for example (examples in line 357 and 358). Enjoy ^^ You can. Just generate them in Atlas and save them as a Scenario. Than you can manually tweak things and add start locations and stuff.

Indeed adding start locations could be much simpler than in Belgian Uplands due to the different hightmap generation (Diamond-square algorithm) capable of presetting the general shape of the heightmap (including mid level relatively flat player locations I hope). I'll try this after implementing a gaussian terrain smooth tool (for the start locations to be used after global heightmap generation). Thx much!

Here's just another approach to generate terrain in Random Map Scripts. Aim - Realistic Terrain - Great Variety (see screenshots or better try it yourself) - Fast Generation (about 10 sec for a Giant Map) - Parameters to tweak (For a more general purpose of this approach) Parameters easy to tweak and fast to implement with this method: - General Terrain Shape (Island, Islands, Highland, Continent, Lake, ...) - Terrain Smoothness (Already implemented) - Water Coverage - Max. Water Depth - Amount of Plains/Mountains - Amount of Resources close to the start positions - Amount of Resources in total - Wind Speed/Direction (Changes Erosion, could also change cloud speed, water (e.g.) waviness and (if implemented) how far/fast trees swing) Other things that could be tweaked but are to slow yet (or not implemented at all): - Water Erosion forming riverbeds (implemented for RMS but to slow, see here, No ingame implementation). - Water actually flowing ingame or at least forming lakes at different hight (No ingame implementation). With an interface implemented to choose (some of) those parameters before game creation (then given to RMGEN) this could also be used to generate more "random" random maps. Task of this topic and the actual RMS Since there is some (reasonable) doubt that this can lead to playable maps at all the task of this topic and the map (hopefully) evolving here is to demonstrate that a well playable realistic random map can be generated this way (and even faster than the average random map as is now). So it's only meant as a proof of concept to later (hopefully) add support to choose parameters from the GUI and then generate the map according to those parameters. First fast actualization The first implementation mainly generates a realistic hightmap (well, more realistic than the average random map or scenario). Then some simple and fast global erosion functions smoothen the hightmap (decay (gravity, sun, low seismic activity) and wind). I just added some terrain textures from the random biome system and some actors (this is far from final - I just threw them in). So the focus is ATM the realistic hightmap which can be later improved for playability. Screenshots Some random screenshots to show the vast variety (already - without any parameter changed): The map: RealisticTerrainDemo2013-9-22.zip NOTE: This is an old version of the map! Later ones are added to later posts.

No. Assigning "treasure-hunters" seam sane to me. And why don't you want that? It's convinient in the end.

In random maps you can freely select your civ. In scenarios they are fixed. Not sure how many civs to come but for the time being those already in should do. Moders will surely add further ones if the game is finished (remember it's only in Alpha state yet).

Before we add ANY terrain alteration ingame we should have a concept of how this should work in the end. As many times stated terrain flattening under buildings RAISES the maximum steepness of the terrain in the surrounding area. Giving the player the ability to deform terrain in general (for some resources or just time to let workers deform it) would work out, I guess. However, workarounds like terrain alteration just for certain buildings I'd consider a bad hack (with unpredictable consequences for gameplay).

The Murus Gallicus has an "inside" and an "outside" and so only one axis of symmetry in opposite to all other civs walls. The RMS wall builder can handle this but the ingame wall placement method has then to be reworked because the player should be able to define where "inside" is. Additionally the "earth" is not walkable because entities cant be walked on (yet) which makes it a bit strange. I like the style though and in principle like entities that can be walked upon (like bridges). I don't know if this feature is planned for part 1 though.

Thanks for your hard work. I especially agree with you on: Keep it going .

I have made some progress. Here's a short report: With another approach (I think it's about the 20th) I managed to get stable, riverbed-digging water erosion. It now calculates the acceleration (so driven by gravity) which seams to make the difference. Some screen-shots of the same terrain with a different amount of water erosion cycles applied. On tiles with water texture the water hight is more than 1/16th (~6%) of the maximum water height on the map. (So where no water texture is there is really not much water) Lighter water tiles mean the water runs faster, darker mean the water runs slower. The other tiles are just painted by height. 20 cycles: At first the water gathers... 50 cycles: ...and forms rivers. 100 cycles: Then it reaches a stable state (It rains all the time and the water slowly drains/evaporates). Sadly the erosion process is really slow... I'll post again when I produced a random map with this. The files: FeXoR-hightmap2013-9-14.zip

A web search engine for example searching for e.g. "open source real time strategy game" (the wikipedia link e.g. has 0 A.D. as the first item in the list) (?). Not sure if I got your question.

Thx, feneur. I agree mostly. I just don't see the need of adding 0 A.D. to Steam/Desura/GOG though. In opposite to other sources that just adds dependencies. That's why I would not support them by adding 0 A.D..

As far as I can see this is already the case. Do I miss something?. I don't get what the problem is/was? BTW: Is there a mirror of the 0 A.D. Webpage (http://play0ad.com/) and if where? If not is it wanted? Steam is a commercial platform. 0 A.D. is an open source game. That does not match well in general. Some specific reasons: - To play 0 A.D. no registration/login should be needed (if for statistics/ranking this should happen on a non-commertial platform) - Steam would raise the requirements to play 0 A.D. e.g. to have an internet connection in single-player (or download the account data) - Steam is a security risk (Reference at Wikipedia) ...and many more. Torrent: Since it's open source everyone is free to add a torrent. This would be an alternative way to distribute 0 A.D. IMO. Sourceforge seams to be the first choice for me though.

That would be nice. On the other hand, since the game is open source, security issues might occur with this feature.

I don't know how many points the original meshes have and how they are distributed. Since they are not made for smoothing purpose I assume they will not be very good. So the second would be better (as far as I understand it). Maybe adding "bones" to those structures/actors might be another solution?

That would indeed be very nice.

About terrain change during play in general. There are two ways possible IMO: 1.) Terrain change does not happen at all in-game. 2.) Terrain can be transformed in-game - that would include terrain flattening below buildings (which on it's own has its problems besides pathfinding mentioned by historic_bruno (http://www.wildfiregames.com/forum/index.php?showtopic=17405entry270541) and the topic link in that track ticket) as well as some kind of terrain transformation commands to make paths though otherwise unpassable areas as well as making walls and cliffs for defensive purpose. But it seams the favor is leaning towards a mix (again) that only fixes the visual issue while granting no gameplay feature. Maybe it's just me but I strongly reject such things. For me the graphic has to represent the gameplay features and add a specific mood and feel to different regions of a game. If a graphic enhancement comes along with a nice gameplay feature that's quite cool. But making units be able to walk extremely step ground near buildings (because the pathfinder was not updated) but not allowing that on the rest of the map seams quite absurd to me.

I was thinking of answering this topic but you more or less hit what I had to say. Anyway, some additions: The priority of Blizzard RTS games (with it's maximum at Starcraft - Broodwars) is set to fluid gameplay, faction diversity and balance, modability, a mixed micro and macro management play style and action from about minute 5 to 30 (30 min is about the time a game lasts, so quite fast for an RTS game). To enable the developers to reach these goals things has to be kept simple. This includes the game rules (no arbitrary or extreme bonuses but bonuses based on size (starcraft) or armor type (warcraft) of about 25%), the "physics" (all projectiles are "missiles" even arrows and all melee attacks hit despite the distance to the target when the damage is calculated - physics are only used for graphic representation), maps (all blizzard games are tile based, buildings are placed on a grid to enable the player to fast and accurate build his base, map "topology" (for gameplay) only depends on cliff height - the "topology" is only for visuals again) and viewport (despite the fact they are 3D they still "lock" the camera to a specific angle to not confuse the player) so gameplay and graphics are as far as possible "unlinked".The Number of different things that can be build per faction is high enough to have great diversity but as low as possible so they can still be balanced - about 8 buildings and 12 units. Before Starcraft the general RTS game experience for developers was not high enough to do those things. After starcraft things went 3D - which was maybe necessary to fulfill the mainstreams demands but quite questionable in sense of gameplay. However, Warcraft III (Blizzards first 3D RTS) had much lower population cap than any other RTS I know to keep things fluent - the game is in average won with only 15 combat units. That way micro management became much more vital. The map editor of WC3 on the other hand made a huge jump - by far the most powerful game tool I have seen until that time and still only met by the starcraft II map editor. However, those are games much different from 0 A.D. and that's good! 0 A.D. is a build up strategy game as Age of empires II - Age of Kings/Age of Conquerors (the best of it's type until now IMO) and not an action RTS game like those of blizzard.

...or this: http://codeflow.org/entries/2011/nov/10/webgl-gpu-landscaping-and-erosion/#video (with sourcecode)

I think responsiveness/feedback to the player is not a "small detail". It's extremely helpful and should happen with the least delay possible (while the more calculation intense actual order may be executes with some delay without causing problems because the player knows the order is given).

I don't like fixed caps. They are extremely unrealistic. Reducing efficiency would be a much more realistic way to deal with it. How is that? ...well, OK, it slightly increases but only by 3% comparing 50 and 1000 while it's decreased by ~65% in total. The idea is to get rid of the much more odd (IMO) population cap. (1 - 1/50) ^ 50 = 0,36416968008711706521737398145318 (1 - 1/100) ^ 100 = 0,36603234127322950493061602657252 (1 - 1/200) ^ 200 = 0,36695782172616738683789723976933 (1 - 1/500) ^ 500 = 0,36751125485715890552210364359175 (1 - 1/1000) ^ 1000 = 0,36769542477096404462680613922046 ...and you are right that "populationCap" is not the correct term here (because there will be no such ting any more). It suits the same purpose though: Disable the players to building to many units so the game stays playable. Yes. It could even be a civilization bonus e.g. for civs with weaker units but larger population. It would effectively limit the population because gather efficiency (and with it the time you need to gather the resources for/build units) would become harder the higher the population of that player is. In addition it would "shift" players with different skills closer to one another which is a good thing on it's own. I'm sorry x) To lazy ATM to explain further. Other things to be thought about: - Defensive structures would need to count to the population as well. Otherwise towers would become more efficient with the game time (and it should be the other way around). Indeed I think all buildings should count to the population (especially in this concept). - The function might reduce efficiency to slow especially at high populations. I'll think of something...

Actually most realistic would be a function the gather rate would be scaled by a function: gatherSpeed = baseGatherSpeed * (1 - 1/populationCap) ^ actualPopulation ...and have the fixed population cap removed. If actualPopulation = populationCap the gather rate will then be about 1/3rd of the baseGatherSpeed. Units can still be build but the efficiency of resource usage would shrink. That would simulate the administration effort needed to organize vast amounts of citizens and soldiers and the growth of corruption that will appear if a social system becomes big and inflexible.

Starting from http://play0ad.com/c...ty/participate/ you will find most design documents. Some specific: Design Document: http://trac.wildfire...Design_Document Technical Design Document: http://trac.wildfire...gnDocumentation Art Design Document: http://trac.wildfire...tDesignDocument Coding Conventions: http://trac.wildfire...ing_Conventions Modding Guide: http://trac.wildfire...i/Modding_Guide Random Map wiki and Design Tips and Conventions: http://trac.wildfire...m_Map_Generator Map and Biome Guide: http://www.wildfireg...showtopic=15562 Path finding design document "The Pathfinding Saga Continues": http://www.moddb.com/games/0-ad/news/the-pathfinding-saga-continues

Welcome to the 0 A.D. community, RacerBG! 1.) I run it myself on a laptop with weak integrated video card... it's playable. The main performance problems are CPU wise. Multi-core-threading is not supported yet, pathfinder and AI use a lot of resources currently but it's worked hard in that area. 2.) Look here: http://trac.wildfire...rtoiseSVN_Guide 3.) Not sure, perhaps this helps?: http://play0ad.com/c...ty/participate/ Reporting bugs is always something that helps: http://trac.wildfire...ReportingErrors And here's a list of tasks (Track): http://trac.wildfiregames.com/report/3 4.) That depends on the field you want to contribute. It it is art this might help: http://trac.wildfire...tDesignDocument 5.) Theres a forum function to see what articles you read and which you did not. I use this to keep track on progress. Theres a chat as well you can ask questions: http://webchat.quake...g/?channels=0ad (or more for developers: http://webchat.quake...hannels=0ad-dev) Have a nice stay! P.S.: We are used to much worse English than that (from me for example) Browse the forum and see for yourself ^^

I'm not as sure as I thought first x) But I think it's: Positive X is right, positive Y is bottom (or top, not sure!) and positive Z is backwards (at default rotation) in the engine. (If Y is top that would be a left handed coordinate system which would be strange... On the other hand Y not beeing top seams strange to me as well...) I'm quite sure about the general directions though not so sure about the positive directions. If this is confirmed I'd like to add that to http://trac.wildfire...oordinateSystem That way it can be found at least somewhere. An engine documentation would be better ofc. but I couldn't find a fitting one (only the doxygen documentation and the quite outdated one not saying anything about the coordinate systems directions).