sanderd17

Lion, could you give some short desctiptions of the names? If it's a famous person, or a region, or something else?

(Dutchies know everything about saving money)

Huge attacks won't let you win, your units will just get stuck until you give up playing. An attack with 100 units is already pretty huge. But to counter aegis, it's best to create an army with only 10 units, as fast as you can, and attack them. Do not come too near the cc, as those arrows kill you raster fast, but try to shoot his units. Meanwhile, keep creating units at your base, and send them to help your small army already there. Patrol around the cc, and try to kill everyone who comes out. When your army there has grown to 50 units, you can attack the cc itself.

See http://www.wildfiregames.com/forum/index.php?showtopic=17969

Erik, also, for the echos you hear. Maybe we should experiment with flushing them all per turn. So you don't get the difference in ms that the JS code gives you when selecting multiple units f.e.. But it's saved, and played all together the next turn. Either with very little time in between (as it's all in a single C++ loop, without JS calls involved). Or even grouped per sound type, and only played once with adapted volume. As a turn only takes 200ms. It shouldn't be that noticeable. Given the speed of sound, a 200ms delay is what you get in real life when you stand on a distance of 70m.

Random maps are coded in JavaScript. So you first have to learn the JavaScript programming language.

But so are the tooltips, while they appear everywhere in game, and the summary screen doesn't interfere with the gameplay.

meters are just game units. Our soldiers are over 2 meters in height (more something like 3m). While on the other hand, buildings are scaled down. Just to fit then all on a map. If you put the unit of measurement to meters, it should really work.

You can also edit the dae in a text editor, and change the unit of measurement to meters (one of the first few lines). The engine expects everything in meters, while while blender reads that unit, but exports it in some default unit.

I don't understand what you want. You can restrict units to certain types of terrain (max slope, min/max distance to shore, min/max water depth, ...), but currently, it's hard to get them to cooperate with other units, out to change their animation when they reach different terrain.

If plundering is just a bonus on the loot, it should be very easy to make an aura for the boat to enlarge that loot bonus. Implementing a loot bonus would cost you something like 10-20 lines of code, with the ability to have it modifiable by techs and auras included. If you remind me of it when the new version is released, I can commit it. But now we're in feature freeze. Letting the boat return with resources will make it a lot more challenging. The pathfinder isn't the easiest part of the project. And this would require two sorts of paths to be synced in some way.

That looks like a nice plan. But I'd like to gather some stats on this first. The lobby could be of great help, as we can collect statistics with it, and use them in different ways, which could be handy for balancing the civs. Or, as you say, giving some nicknames or medals in the long run. But we'll have to study the stats first.

The scores are a bit arbitrary, in fact they only show the breakdown between economy and military. the total score helps a bit with visualising that breakdown, but has very little purpose on its own. The stats on the other pages are more interesting. They show a more detailed breakdown of your play style. Like if you just spawn masses of units, or if your primary goal is claiming more land, or if you invest in defensive structures. As such, you can see what playing style counters an other playing style, and learn from it. Though I have to agree the current stats don't show all of that, but that's why we appreciate someone working on it. Edit: To answer Michael's questions: * Why do we need a statistic screen? To check out the play style of different players, see how well it was executed, and check what strategy wins from another, or which strategies are cooperating well. * Which stats are usefull? We will only know this after playing some games with them implemented. If they're not implemented, we can only guess how important they will be, or how much information they will contain. If the design is made rather modular. It should be really easy to add or remove a stat. * What is the best way to show the stats to the player? A combination of graphs and numbers. Though we are limited by the GUI in this case. Nobody ever got around creating graphs in the GUI. But Santa at least wants to try. Lets see how this turns out and which stats can be better represented as graphs. There will obviously be some stats that will be better shown as graphs. But as long as we don't have the code, we don't really have to discuss this. * What's best for aesthetics? That's something for the art team. I'm no master in GUI aesthetics, as long as it's somewhat consistent, I'm ok with it.

I want to use formations more. Like attack with the entire formation. I'd like to see two phalanx formations fighting each other. But that will cause some problems. So first adding an option to disable formations in the game could help.

These are the sort of things that happen by accident

Does it happen every time? We can't solve something that only happens once. Also, your SVN version is polluted. There are files modified in there that cause errors. Either by you, or by the mod. Can you revert back to the original SVN versions, so we know it's a problem with our stuff or not?

Having their formations a little sloppy won't be that easy to do in the code (though still possible, but it might make the code a bit more ugly). It might be better to do it in the art. If you give the units some different shields, and longer and shorter spears and stuff, the formation will look sloppier by itself. But I think we should consider having them fight absolutely without formations. I plan to add a "no formation" option anyway, so we can add things to formations, even break gameplay a bit, but not be too annoying as you can still play without formations.

The problem with having them walkable is that it needs to integrate with a other components. Like the pathfinder needs to know where the mesh is connected to the terrain, and what parts of the mesh that can be walked. The position component needs to know at which height the units are, to render them correctly. Both those components are quite big, and very performance sensitive (one added feature can easily multiply your lag).

We don't have walkable meshes for now. The gate simply works by enabling and disabling the middle obstruction of the 3 obstructions defined in the gate. Enabling an obstruction is done for every building anyway when it's build. And disabling is done when it's removed (though through different functions, but the backbone is the same). Walkable meshes are only planned for Part 2, as they're too much work, and not important enough for gameplay to include in Part 1.

No, my reasoning also works for individual total score. I don't see a reason to add a victory condition to that.

In the lobby, games with more than two players aren't rated. There are plans to apply some rating there though. But it would require carefull thinking. And I don't think there will ever be a victory condition attributed to the team score, as IMO, it's quite a big achievement if you can win from someone while having a lower total score. It means you mastered your economy and military, without spilling a single unit. While the other one worked on gathering unneeded resources, or building unneeded stuff.

If teams aren't equal, it's normally chosen in a way that the team with less players are considered better. Showing the sum of the scores is still a nice way to compare the teams. Good call, it should probably only be shown when teams are locked.

You need to put it as projectile (line 51)

That's the right file, did you restart the game?

When they gain experience, they upgrade so they can use flaming projectiles.