wraitii

I like this tech-web idea quite a bit. Though we could definitely go even more web-ish (like Civ Beyond Earth is doing).

It's working fine for me too.

Central limit theorem should apply iirc assuming what needs to be assumed. Samples are most likely not normally distributed. It'd need to be checked but something like a Poisson law seems more likely as there's a "normal" run-time and more reasons for it go slow than suddenly faster, with lock-ups being fairly random in length. I'm fairly sure there's a class of function that acts a lot like a Poisson law in R but can't recall their names. Probably not a big deal.

That's actually completely unrelated to multiplayer connection or what have you, it's because we're using big turn lengths. We probably could lower them.

I think I see what you mean with unit selection but not with camera movement. Any details?

It seems like pushing back to after A17 has no drawback other than "it makes A17 weaker"? Given that Philip is afaik still looking for a job, it would be better to ask him when he estimates he'll be over with this. I haven't really followed your progress but I don't think it'd be a good thing to push A17 back.

I kinda like the curved in roofs. Looks different.

One big decal is much better than 15 small ones performance wise.

It's a wonder, I don't really mind if it's always green. However one big green decal might work better than 15 small.

The thing is: as long as there is a possibility, a casual gamer against a "for fun" AI will use it. Even if it's utterly unpractical. The only key element is that it must not be overpowered so as to not break more competitive MP (even between amateur players, MP is much more often about winning, whereas against an AI which gives you a lot more leeway, you can go crazier). SP at lower AI difficulty can be as unbalanced as you want. And I agree that the AI should use most of the features. Just be slower or not attack.

niektb: There is no such thing as balancing for a casual player either. This is called playing SP. And making SP fun isn't called "balancing".

It's actually totally why this change was made. I complained to scythe that in the early game gathering wasn't smooth enough, and he agreed. Wheelbarrow techs are an afterthought that give an opportunity to reduce eco-microing in the mid-late game. You seem to think on the whole that A16 allowed you to do everything, whereas in the balance branch you cannot research/train/build everything in a game, is this right? WhiteTreePaladin: there is no such thing as balancing for inexperienced players.

I can't fix this unless someone debugs it further. I simply don't know what could cause this and it's not anywhere near happening for me. Plus it's an error that doesn't make sense In the meantime, just disable HQ water effects.

If the football club is in France, it's in France

I can't vouch for scythe's intentions beyond what he said: trying to make the game more fun, more strategic. I will say from my reports that we do seem to be on slightly different pages, but we have had no real discussion in the team about gameplay, and even less consensus. The only consensus is that A16 seems broken. As for me, I have played the game at 1x speed, at 1.5 speed, at 2x speed (at different alphas but the feel stayed similar), and I feel 2x speed is somewhat what I would want. However it gets really, really frantic. So I think simply having units move faster will give the proper impression of speed while not speeding gameplay up. I will however ask everyone to remain civil, and absolutely refrain from vague personal attacks.

Trees aren't really an issue with the updated long-range pathfinder. Not that supporting Pentium is realistic.

AoM had very dense forests compared to us.

Imo the walkspeed from scythe is good enough, but it was a bland +3 to everything, so we should probably refine it by unit and more.

You probably would get a better result by simply thinning the posts at the bottom over water, to have a grid.

This is very cool . If you do enough wall variations, we could probably add it to the in-game auto-placer.

The unit speed issue has been noticed by a few team members (at least me and Scythetwirler) so it's likely to change.

My personal preference for AI behavior would also have two criteria, but those would be "difficulty" and "personality". Difficulty would basically make the AI use less varied, less efficient strategies. Personality would range from "efficient" to "plays for fun/excentric". "Efficient" AIs would try to win the game as quickly and as ruthlessly as they can. "Play for fun" AIs would just play, attacking once they've amassed a formidable army or things like that, use a wide variety of strategy (some not necessarily really efficient). Basically they'd be in control, so if you attacked them they'd retaliate and stuff, but wouldn't necessarily try to beat you as quickly as possible. The "efficient" AI would simulate a "real" MP game between players that want to win, the "excentric" one more of an MP game between two laid back players. But that requires a much more efficient AI than what we now have. For now, I agree with WhiteTreePaladin.

I've updated my script to take counters into account and changed a few other stuffs, here are the new results. The lack of hardcoded counters paints a very different picture overall. It also seems you've buffed all units attack up. SVN:balance comparison.zip

I'll look into it, thanks for reporting.

A quick guide to what C++11 can offer us (near the bottom): http://isocpp.org/wiki/faq/ Stuffs like "auto", decltype and range-for statements can improve readability. Lambda improves usability and readability. Proper usage of "move" can avoid using pointers when they should not be needed, and can help with memory management in some algos. Initializer_lists are more convenient and improve readability. It also cleans initing up a bit. Usage of "nullptr" instead of "NULL" could help us alleviate some issues with uninitialized stuffs. There's also improvements to types, and more structs can be recognized as POD (I'm fairly sure we have a few of those). You can also force arrays to be aligned as whatever you want, though I doubt we'd see the use for that. There's also language static asserts, so we will be able to ditch our macros for that, and these kinds of conveniency. Finally the STL has been revamped with convenient things like initializer lists, the move operator (good example of how a simple syntax works better now), more functions, the "unique/shared/weak_ptr" family, and we also get some useful new ones such as unordered_set and unordered_map, for which we would have had to rely on boost. And std::array if you want to.