sanderd17

I love starting from a random map, just because of terrains. Most random maps mix some different terrains for one patch. With the Atlas replace function, you can modify it to your own biome, but keep the nice looking terrain mixture.

See http://trac.wildfiregames.com/wiki/ArtDesignDocument#TerrainTextures for examples. Every tile has a priority (I don't remember if high or low numbers are rendered on top), but in Atlas, you can influence the priorities by left or right clicking when painting. If you take f.e. a 3x3 paint square, and you click left with it, it's blended on top (the borders of your square get the new texture). If you click right, it's rendered underneath (the borders of the square keep the old texture). Atlas does this by setting the priority to less than the minimum or more than the maximum of the surrounding tiles. The rmgen/map.js seems to currently use a fixed number for the priority (see line 403)

I disagree with that. Formations should be stronger, but IMO there should be no default formation (soldiers should move like females when the player doesn't care about formations), and the requirements for formations should be more severe (like battle line may only contain 10 to 20 melee units, skirmish may only contain ranged units of one type, Phalanx may only contain 8 to 20 speermen ...). That formation should get a strength, depending on the type of formation and the number of units (like for Phalanx formation, the total attack of the first line + 80% of the second line + 50% of the third line, then multiplied by some balancing factor). If people can choose to care or not care about formation, I have no problem with formations being stronger. It can be balanced too. I have no idea on how to implement it logically though. Formations are already entities, so I don't think it will be too hard (when we have the right pathfinder interface).

Well, the AI should learn how to attack a wall too (walls used to be attackable by normal soldiers, but now they aren't). This will be rather hard to do though.

Maybe, because 0AD isn't running in windowed mode, your DE doesn't receive any signals, and is configured to log out (or suspend or so) after x-time. Can you try to run the game in windowed mode (see http://trac.wildfiregames.com/wiki/Manual_Settings)? If it works in windowed mode, it has to be a problem with your DE settings (try looking in the power/energy section of the settings).

This is a pathfinder issue. The pathfinder sees it's not possible to reach a target, but doesn't tell why. So it is very difficult to do for the AI. As a result, the AI just tries again and again to find a path, but will never find one.

It's it possible to raise the terrain so it's certainly above water level? As a bonus, you could even add bridge models to the sides of your roads But that's only when you run out of tasks to do.

Your post is interesting, but it would be nicer if you could structure it a bit more (like things that are currently in the game, things that can easily be added, and other propositions). Anyway, I have some remarks here. Also some citations would be nice. The game has a bigger ship for the Celts. The capacity of their ship is 40 soldiers instead of 30. They don't have a quinquireme though because it's not historical. AFAIK, their ships were multi-purpose. A lot of other factions are also known for good trade. I'd like to have a reference comparing the trade capabilities of civilisations in that time frame. Citation? Did the invention happen in the timeframe (500-1 BC)? Or afterwards? Citation and relavance to the game? The sources I find say the Romans learned glass making from the Greeks for example. That's how their models are in game That sounds Latin to me When formations finally work, there's some possibility to add a "flag" unit (like a Roman unit carrying the SPQR flag). For Celts, this could be a unit carrying the Carnyx. We need to remember this one.

I agree with Ludo, interesting map. It does look like some Cycladic Archipelago maps. IMO, the greeks have too much ground compared to the others.

I tested some maps, and they look very nice. Some remarks though: For playability, all players should be able to reach each other. Even via land if you don't want to list it as a naval map. Currently, it's possible (and happens sometimes) that a player is locked in by a dense forest. Where no soldier can pass, and certainly no siege engines. To solve it, I propose the following, after choosing the starting positions. For every starting position, you sort the other starting positions in one of the four quadrants. For each quadrant, if it contains other starting positions, you create a 'path' to the closest starting position in the quadrant (unless it already has a connection due to an earlier step in this algorithm). That path is elevated to a certain height (depending on the height of the connected CCs), the profile is smoothed or completely flat, all obstacles along that path for a certain width are removed (or re-positioned if important), and the texture is changed to a road like texture. To create a random path, you can take some random points (2 or 3, depending on distance) between the two CCs (not exactly on one line), and connect them with something smooth like splines. You can also add some paths to other random places (like edges of the map) to fool players so that not every path leads to a CC. For visuals, I think the random stone and metal mines are placed a bit strange. I think they'd look better near the edge of forests, or near water, I don't know if that's easy to do. And forests are still too dense I believe. Your maps are also missing huntable animals (they also need a logical starting place) but I don't think that will be too hard, as the forests just depend on the height map.

Any reason why that naming schema is used for skirmish maps and not for scenarios? They have the same problem. Btw, if you want to be able to play a 4-players map with only 3 players for example. You can assign the Scaredy Bot to that player. It'll be destroyed immediately.

If users really want, they can replace those files themselves, but the site uses a CC-BY-SA-NC license http://www.forvo.com/license/. So we're not able to distribute those files as is. It should be CC-BY-SA or less restrictive. Edit: Ninjaed by Gallaecio

If you want to help the team as an artist, you should probably write an application: http://www.wildfiregames.com/forum/index.php?showtopic=11297 There you explain what you're good at (there are differences between organic and structure modelling f.e.), and normally, someone from the art team jumps in and gives you a task (with guidance). The other way to do it, without being part of the team, is just playing the game, seeing what's missing and what you like to do, model and present it here. That way, they'll be reviewed one-by-one, and the ones good enough will also be included, the other ones can still be used as concept art. Also see the eyecandy thread in the latter case: http://www.wildfiregames.com/forum/index.php?showtopic=16959

I like what hbruno has done with Atlas. It's great. Thanks for that. @Lion. To make skirmish maps, it's about the same like making regular maps. You just have special entities (type 'skirmish' in the entity search to see them, they're in a separate folder). Those special entities are "dummies" and get replaced when the actual game starts. Like if you put the skirmish CC on the map, it looks like a Greek CC at first. But when you start a game as the Mauryans, the CC gets transformed into a Mauryan CC immediately. You can make your own skirmish entities if you want for your mod. They just contain a definition by what they should be replaced. When you save the map with Atlas, you need to save it under the "skirmish" directory to let people choose their settings. In Atlas, you can also disable some player settings (like player faction) to get a more default view (defaulting to random faction, 300 wood,food ... unrevealed map ...).

did you update your workspaces? Those things are added in files that were only recently added to the project. So if you don't update your workspace, you don't have those definitions.

Oops, forgot to reply on this topic. I changed the bridge edges to be more than actors, and added an obstruction size in the right part (without obstructing the water or the bridge itself). So now this problem won't happen again.

Can you get acquainted with the sound and entity xml structures? Getting the sound in game is the only way to hear if it "works", including choosing the right pitch and gain variations.

The project currently uses two pathfinders, the long and short range one. The long range now has a very rough grid that's used to calculate the approximate path. The short range works grid-less, but is very naive and has a big complexity. Mismatches between the two are the main reason for problems. When a grid cell is unobstructed according to the long range pathfinder, it's possible that a unit is too wide to fit through, so the short pathfinder kicks in and calculates a route that's far too long, which is very expensive. The other case is also possible, where a unit would be able to pass through a gap between buildings, but the long range pathfinder doesn't see the gap. You need to manually approach your units to there, so the short pathfinder kicks in immediately to calculate the path through the gap. There is being worked on a new pathfinder (http://trac.wildfiregames.com/ticket/1756 - reading the patch might give you an idea on where to look). The new way to do it is using a much denser grid, and share that grid between the short and long range pathfinder, so there are no mismatches. Because A* is very bad with all equivalent paths, the algorithm has been transformed to A* + JPS, which is great on uniform grids. When this change is complete, the short range one must also be re-written to work grid-wise (for consistency, as I explained). For your algorithm, it looks like you'll have to redesign both pathfinders to guarantee consistency. If you can pull it off, I'll be interested in the results, but I fear that a non-grid-based pathfinder will be too expensive for long paths (from one side of the map to the other) with 1000s of obstructions in between.

As the American eagle refers to the Roman one, this isn't too bad http://en.wikipedia.org/wiki/Eagle_%28heraldry%29#Modern_usage

There is no performance problem with the languages. There is a problem with the algorithms we use though. Some of the algorithms (like the short range pathfinder) were just implemented to get the game to work. But now they have to be improved because it's a real performance problem. Switching to a different language would just cause us to re-implement and re-design all algorithms (also those that work well). And switching the engine to something like the Torque engine would also require us to implement lots of algorithms (those engines don't have pathfinding f.e.).

They fall outside the timeframe for part I (500 - 1BC) Those were rather isolated. Some discussions have resulted that it would be best to keep it to civilisations that have fought with each other. The eastern civilisations didn't fight with the western ones (the Himalayas were too big), so they aren't included.

If you play against Athenian AI. Just build a wall. It can't attack that wall, and as it will run out of resources eventually, it will go down. You can keep up your own resources via trading.

We already have a big amount of languages in the project (C++, JS, Lua, XML, JSON, Bash ...) I'm not really in favour of adding a new language. But if you can get it to work with the current build system on all platforms (so you don't have to compile it separately), I'm not against.

Well, I hope it was fixed If you still find the issue, I may need to dig deeper.

There is a demo campaign (under the demo maps), but it's not playable yet. And nobody is really working on it. Not on the art side (it needs very low-poly decoration) nor on the programming side.