FeXoR

hollth: It more Mythos_Ruler's idea with my thoughts added. Concerning the work: - The "wall connector" has to be modeled for every wall style (nut sure how much work) - The code needed to replace the entity should be very similar to the "wall to gate" upgrade (simple) - In wall placement methods the wall tower would have to be replaced with the "wall connector" (trivial) So I can't see any real problems here. It would be nice to have an upgrade animations, though (instead of instant entity replacement).

True, haven't thought of that

Got an AI related error as well: Version: SVN 14696 Map type: Scirmish Map: Alpine Valleys AI: Aegis (easy) Civs: Macedonian(Player), Random(AI) Settings: Otherwise default settings Cache: Cleared before starting the game Local modifications: None Error: commands.txt system_info.txt mainlog.html interestinglog.html

I think even in visible areas some things might be better hidden. An enemy territory border e.g. enables you to walk around his territory without the risk of being attacked by a tower. IMO only those parts of an enemy players territory should be shown if it restricts your or an allies territory to be expanded.

So textures don't generate any lag GPU wise and all lags (like e.g. cased by many entities) is CPU related? Well, then I'm out of arguments (Still don't like explicit cruelty... but war games. I must have a twisted mind ^^)

Thanks, now I'm on the track. What about replacing all wall towers with the connector (independent on the appending wall parts length) and make them upgradeable to wall towers (like long wall parts to gates). This way the wall on it's own can be cheap while wall towers could be as expensive as defense towers. Then the player can decide what he wants - but for a price. I don't like minimum range but in case of buildings and if it's historically accurate it seams sensible. It should be longer then a siege ram but shorter then a siege tower IMO (if this value exists). The maximum range, however, should be higher then that if a normal unit because of the higher position. Making wall towers more expensive would enable us to balance this. A drawback of this concept is more micromanagement though.

I don't doubt that. Still: I think you can do the following to make the game twice as fast if you have a poor graphics board: - Find a component that is not gameplay relevant and remove it to get thinks take 98% of the time or less they would take with it. - Do this 20-30 times. Ofc. ATM there are bigger issues like pathfinding and player/unit AI and until the game reaches final state graphics boards are most likely to not cause any lag. Still, many components with little effect add up to a quite notable effect (ofc. thats might also apply to the look of things: the game might look much better then). AFAIK there are some graphical drawbacks as is though: (Not sure if they're memory or processing time bottlenecks) - Many entities/actors on the screen e.g. trees - Zoom out far (mainly the same reason). And having a good overview of the map is a gameplay relevant thing for me. As the development goes now I get the feeling 0 A.D. is more viewed then played (and so components will be made more shiny as graphic boards evolve in fact leading to graphical related lags until the development process stops).

Yes, that will be OK for visuals. I still don't understand why this is whanted from a balancing point of view. The cost of (closed) walls (at least on most maps) is much higher than the cost of the siege units to raze them. Since both sides need units in case of a siege to win the sige walls hardy seam overpowered in general. They might counter some tactics effectively though but that's what they're for as far as I understand it.

I totally agree. Showing not-well-defined-properties may be cooler but stats should be informative. Having those in addition to the well-defined stats would be OK though - for less "mathematic oriented" PPL (likely the majority). How much they say about player skills remains to be seen...

Prodigal Son: Yes, true. Thought more of less military based/organized civilizations like Celts. We'll have to look closer how balancing works out in the end. Because not only the (many) factions have to be balanced but the different units in one faction compared to each other as well. With the many core concepts (civil soldiers vs champions (vs. civil cavalry only able to hunt so unique, too), enhanced damage vs., damage/armor type) it will be hard to balance those factions while keeping them feel different.

I am amused and like it, too. However, this "argument" conflicts with historical accuracy and in many ways with my taste of a well designed game (not graphically but in general). So... I tend to disagree (though in this case I don't really mind because it doesn't hurt performance in any way ... and look cool ^^) (Just feel that favor style over performance is a bad idea) I like stanislas69's approach very much.

IMO Champoin units should stronger but less cost effective (have a lower cost/combat value ratio - in case I confuse terms). That way it's good to have many civil soldiers and a few champions - and that's the way it was AFAIK.

It's a matter of taste but I don't want the game to become slower to annoy me with cruelty....

Why do you want to restrict wall towers close to each other? For me walls/wall towers already have a bad price/value rating due to the lag of range. I feel defense towers/fortresses are more effective. Besides: Not placing towers between short/medium walls will - Make the original wall idea obsolete (considering length relations and so we could directly make a new concept that might work better). - Will cause problems (like pinnacles rising into the parapet walk) due to the design of walls.

Yea, it was only 1.2 MB back then and consisted of the exe file only (so no installation needed). That's my taste of an efficient program ^^.

I don't know what you have in mind but to play around a bit some links: Some heightmaps: http://www.flickr.com/photos/tags/heightmap/?page=2 Small, fast and free image viewer that can resize/resample, convert to grayscale, color correction(contrast/gamma) and some global filters (blur). It also supports many formats. Really one of my favorite programs: http://www.irfanview.de PNG pictures are not always imported correctly in Atlas so JPG is the format of my choice. If the compression create to many artifacts you can lower the compression after editing while saving.

You can import a heightmap (jpg/jpeg or PNG grayscale) of other sizes to get a base for a map. I don't know the limit (And if I got that right nobody knows ^^) but it seams to depend on the hardware, not only the software. 2048x2048 is possible for me but I don't think such a gigantic map would be suitable to be played.

@Zeta1127 about the Iberian Wall: It's possible. I'm busy ATM but I'll look into it (and other things) in about a month. However, it's quite likely that the base would not grand enough space with walls and walls (or buildings in general) near/on cliffs cause problems. I guess the Cantabrian Highlands start location hills are randomly shaped clumps. The shape is not predictable and so the walls have to be placed with care. Also the unit drop points of wall towers have to be fixed first. Otherwise un-garrisoned soldiers will likely spawn in the area between the wall and the cliff. @wraitii about polygonal graph heightmapgeneration: At first glance the process looks quite computational intensive. I'll check in the semester break. I noticed an inconvenience in Atlas heightmap import function: - JPEG files generate waves at rough cliffs due to compression - PNG files are not correctly importet (or at least not all, e.g. )

Is there a documentation about such .xml files (about it's structure and what can be done)? Can they be used for random maps as well (and if, how)?

Lion.Kanzen: Sorry, I didn't see your request. A link to the official law in question (German): http://www.gesetze-im-internet.de/stgb/__86.html There is no official translation (or I couldn't find it). This law does not say anything about the swastika but refers to it as a "symbol of a party or organization declare unconstitutional by the Federal Constitutional Court" (translated by me as literally as I could). This includes the NSDAP and this includes the swastika as one of their symbols. Nothing is mentioned about how close it has to be to the "original" symbol to a crime to "make it publicly available in a database" (close translation of the part related to our issue). Though (as said before) it's quite unlikely that a German court would declare wildfire games (or whoever charged) guilty it's already a crime to show (host a picture of "make it publicly available in a database") the swastika (a "symbol of a party or organization declare unconstitutional by the Federal Constitutional Court"). (Don't hit me. I didn't write the law) (Don't try to interpret it, it will stay a chargeable crime) (For me this issue is settled: I just don't care enough)

I agree that it's very likely a court wouldn't judge Wildfiregames (or whoever gets charged) guilty. However. It's still a valid reason to open a trial in the first place - and that's bad enough IMO. So I'd be more cautious.

newcivs: Maybe for you it's "better" (And I don't see any relation to "better" battles...) but as is nudity/gore and potentially offensive symbols "better" is subjective as well. More objective would be "more efficient code", "higher frame-rate" etc. an those would even drop by some of the discussed features so for me (subjective) those are "worse". Just keep in mind that most things discussed here are subjective and "is better" does make no sense in this case (but more like "I'd like more/less").

A very nice collection of games. Voted for 0 A.D. - I like Flare and Zero-K too, though.

512 is the maximum of tiles available in Atas or the game setup (guess for the engine as well). Otherwise: http://trac.wildfiregames.com/wiki/ArtDesignDocument#ScaleandProportions (Pretty outdated though) On the other hand: http://trac.wildfiregames.com/wiki/Rmgen_Library#MapCoordinateSystem So that was my error. 1 Tile = 2 Meters then (I edited my previous post accordingly). 1 tile width = 2 meters = 4 model space units = 366 engine hight units I have no information about the engines units in the plane. (If it's range is 0xFFFF (65536) as well it would be 1 tile = 65536/512 engine width units = 128 engine width units) Would seam strange to me though if hight and width had different resolutions in the engine. EDIT: The engine supports maps at least to 2047x2047 (I resampled the .png to 2047x2047 and it still worked) At 2048x2048 I get: ERROR: CRenderer::EndFrame: GL errors occurred (That doesn't necessarily mean I hit an engine limitation but I guess it does because I can't see anything in Atlas despite the fact it's "only" 1 tile larger in each direction). For comparison of the hight range on different map sizes: (All with the same increased contrast. About the maximum without getting a flat cut hill top) 128x128 200x200 (original) 512x512 With gamma correction the focus of detail can be set to different heights: More details on lower parts by increasing it, higher parts by decreasing it.

Well, looks like a camel riding a dwarf, so a "camel rider" ^^