alpha123

As of Alpha 14 all spearmen are the same. Eventually there will be a lot of techs for Hoplites to make them considerably stronger than other spearmen. Regarding other stuff, you're pretty much spot-on with Celts being underpowered. They are incredibly wood dependent, although this isn't too much of an issue on most maps. More importantly, they're extremely vulnerable to certain unit combinations. Massing up swordsmen is an easy way to win against Celts, as the main units for both Gauls and Britons, spearmen and skirmishers, are both countered by swordsmen. Additionally, lots of archers beat slingers and skirmishers fairly easily, and the various Celtic cavalry are too expensive to be useful versus large numbers of archers (even though cavalry are bonused versus archers, 80 archers will still easily beat 30 cavalry, and archer production is just so much faster). I disagree about Persians being overpowered, although they're definitely on the more powerful side. Really all they have going for them is good archers, and while massed archer is extremely good currently (better than it should be) they have trouble late game since they only have a weak ram for siege. However, since they have a variety of above-average cavalry, and since Immortals are quite good, I'd still stick them as being solidly on the more powerful side. I strongly disagree about Mauryans being overpowered, on the contrary I consider them underpowered, only slightly better than the Celts. They lack any siege equipment and elephants are slow, expensive, and are very easy to take down. Elephants can't even breach a few garrisoned fortresses and towers, as the arrows alone from the garrisoned buildings can kill the elephants. Mauryan archers are extremely good though, and since archers are such a flexible and strong unit right now it gives the Mauryans an edge in the early and middle game, but they're at a large disadvantage late game.

First, I'm a little skeptical of anything mahdi's claimed when he hasn't any real evidence that his alleged C# port works. I'm currently inclined to think that it does work in some form, but I'm quite doubtful of the 3x performance. Second, rendering could be instantaneous but if the renderer is waiting 2 seconds for the simulation update it doesn't matter. Using a newer version of OpenGL would just limit our userbase for no real gain. We'd get a much bigger gain by fixing the O(n^3) pathfinder instead. While something like Boehm GC would possibly be nice, I consider it unnecessary. I think it wouldn't really provide much gain, either in clarity of code or performance. Clean C++ code with RAII is both easier to follow (since nothing weird is going on behind the scenes) and more performant.

If you're referring to using a newer version of OpenGL, that's a good way to lose a lot of users for dubious performance gains. If you're referring to porting the game to C#, that's a good way to spend a ridiculous amount of effort and lose a lot of users for more dubious performance gains.

...So you want formations. We're working on that - slowly - and we know the current "formation" stuff doesn't really work. Basically, it's on the "to-do before 1.0" list, but nobody quite knows exactly how we want formations to work, plus it's very difficult to code, so nobody's really done anything about it yet.

#643 Thanks for reminding me of this, it would be nice to get in the next release.

The nice thing about JavaScript is that it allows us to develop really fast, and since most of the game logic isn't performance-critical speed doesn't really matter. Some stuff that is in JS really shouldn't be though. For example, AIs do pathfinding in JS. We can move performance-critical components to C++ pretty easily, so I really doubt our usage of JS is much of a performance issue. Ha! I thought I was the only one that thinks we should have used Haskell!

Java is to JavaScript as Ham is to Hamster. We use JavaScript.

Is your ship trying to attack an enemy ship? Ships... um... get a little over aggressive and sometimes try to move toward an enemy ship. Try setting the ship's stance to standground. Alternatively, it could simply be because the pathfinder sucks (something we hope to fix with the fundraiser) and the ship is getting stuck just out of range if the units being able to garrison (this happens to me every once in a while).

scythetwirler has made a number of contributions lately (both actual code and some mathematical formulas used for various things). He'd rather not use his real name though, so just put scythetwirler in there.

I think wraitii was referring to the AIs doing the "optimization" if it can even be called that for themselves, not as a means of cheating for people. Incidentally, it would be rather non-trivial to teach the AI to juggle fishing boats around, so that's pretty far in the future. AIs do have the APM to do it though. Well, I wrote the code, and am on the design committee, so I think I'm one of the "relevant people".

Nope. I prefer using constant regeneration for berries and sigmoid regeneration for fish. This strikes a good balance between optimal realism and optimal gameplay value. I outlined the advantages and disadvantages of sigmoid regeneration in this post, and I think I presented a convincing argument that sigmoid has considerably more advantages than disadvantages.

See this topic, there's some interesting stuff especially from Mythos_Ruler in there that you might find useful. idanwin: Yeah, that's pretty much what we want the pilum to be. Not sure if we want it to be more powerful than the melee attack though, it's more meant to soften enemy units up a little bit before melee fighting, not really to kill anything outright.

There are a lot of far more productive ways to cheat right now. zoot, I'm not sure why you think writing a bot to play along side you is a con of the sigmoid function, it's a flaw of the game's lack of anti-cheating measures. And let's clear something up: the resource collection rate doesn't change. The way to "exploit" (which is completely the wrong word here) the sigmoid approach is to remove your fishing boats at the beginning of the exponential part of the curve and add them back at the end of it. This means that the you'll always stay within the fast-regenerating part of the curve. It would not be "vastly superior" by any means, if it would even make a difference at all. It would just mean more food is available faster. This would make precious little difference in practice since fishing isn't meant to be a primary food source anyway. Please stop spreading FUD - which is what your post is - and concentrate on the technical stuff.

That's correct. It would be. I'm not even sure if TheMista could do it properly for any more than about 3 fishing boats. It's a huge amount of effort for small (but tangible) gain. That's actually implemented in the patch on #1973. Sanderd17 has brought up some good reasons against it though (which you can also find on that ticket). I think I'm going to remove the delay. In addition to causing some problems like that the code is ugly and it's not realistic - nature doesn't wait for people to stop gathering from it to regrow.

It's quite possible to get it in Alpha 14, especially since the release will be delayed until the AI is fixed (which could take around a week). Basically once this design stuff is settled I can commit it (although the bit in the patch that handles delay before regeneration is more ugly than I like - I'll either change that or remove it entirely).

I prefer a combination of approaches (as is currently implemented in #1973). Berries should have constant regeneration, and fish should have sigmoid regeneration. Advantages of sigmoid regeneration: It's more realistic: the more fish there are, the more new fish are produced, but when the population gets large enough it slows down again due to less available food for the fish. It takes some time to get "warmed up" from 0. This means that it isn't immediately useful to gather from for a while after it's depleted. Less "game-y" than constant regeneration, which simply seems overly artificial for a resource like fish. Disadvantages: It is possible to micro your fishing boats heavily to optimize food income, adding pointless micro to the game. Counter-argument: As we don't have many fish on maps spreading fishing boats out is not feasible. Counter-argument: This would get prohibitively difficult with > 5 fishing boats - anyone who can pull that off deserves to be rewarded. Counter-argument: This isn't pointless micro - it requires doing a fair amount of non-trivial math in real-time to balance the number of fishing boats, the number of fish sources, and the current resources of each source. Counter-counter-argument: Someone could do the math for X numbers of fishing boats and Y numbers of food sources once and post a table of it, meaning that people could just memorize that and brainlessly micro their fishing boats around. Simplicity doesn't really mean much here; the player doesn't really need to know how it works. I actually think sigmoid may be the more expected form of regeneration from a player's perspective - people expect more fish to reproduce more fish. The advantages of this are dubious, IMO. It would likely not provide a substantial food benefit and the ridiculous APM required to constantly check your fish sources and remove the fishing boats at the necessary time could be put to far more productive things. Nitpick: You wouldn't be optimizing the gathering rate but rather the regeneration rate. It would gather at the same speed regardless, however you would have more food available more quickly if you pulled the fishing boats off at the point the sigmoid curve starts to turn exponential. Those actions could be put to far more productive things. I think you underestimate the APM it would take to constantly check the resource levels of every supply of fish and move fishing boats around constantly. If you're fishing with one or two boats, sure, it might give some extra food, but when you have 5 or 6 boats? Not so easy. Incidentally, I might count this as a pro for sigmoid regeneration: overfishing is punished in real life, too.

Cool. Is this implemented in terms of techs, or did you use some other solution? That will get fixed automatically when we implement formations properly, so I wouldn't worry about that.

You wrote the original GUI code, right? I think you should definitely do this in that case. (Although I sort of want to strangle you; parts of source/gui/ are a little insane. And there's a ton of duplication in the XML and JS. But it works stellarly, so I guess I can't complain too much.) However, I see no reason that we both (and hopefully some other people - leper?) can't work on this - especially with Git it will be easy to collaborate. Pureon: I agree that it looks too busy with the colors in the background. However, I like how the gradients appear more subtle in that version. Perhaps just dim them a bit in the version without the colorful background?

Sorry, that was rather ambiguous. Only the same aura shouldn't be applied more than once, multiple range-based auras should be able to be applied simultaneously. I think we could keep the Aura component as an abstraction over range and formation restricted techs.

At least some auras should be implemented in terms of reversible technologies (i.e. techs that can be "unresearched"). So the tech is automatically researched when the hero is made and automatically unresearched when the hero dies. One thing that complicates things a bit is that some auras (such as the female +gathering aura) should be range-based but most hero auras probably going to apply to all the units in that hero's formation. I don't think we ever decided on whether hero auras are going to be range-based or formation-based but I think we were leaning toward formation-based. Even more complicated, range-based auras probably shouldn't stack. So basically we have 3 main types of auras: Reversible techs (decreasing the cost of a unit, increasing ship speed, etc) Range auras (increase gathering, demotivate nearby enemy units, etc) Formation auras (increased attack, increased speed, etc) On top of that, we have some auras that don't quite fit into the above categories. For example, the ship a hero is garrisoned in moving faster or getting 5 metal for every enemy killed (those are actual hero auras, IIRC from the Athenians and Britons or Gauls). Here's how I'm currently thinking this should be implemented: Most of the latter two types of auras should be implemented in terms of techs that can be restricted to a certain range of influence. That could either be an actual range or a formation. As an example, the female aura should just be a tech that only applies to units within her range. This would be a reversible tech that would be researched when the first female is spawned and unresearched when the last female dies. This nicely solves the stacking problem. Then, the tech manager would, instead of applying the tech effect globally, only apply it to the areas within range of a female. Auras should just have one component, but at least two to reflect the great variety here. Reversible techs in particular should be its own component, since that will likely be reused for wonders. The range- and formation-based auras could be built on top of the reversible tech component and range-restricted techs.

Tentative guess: 2 months. Hop on IRC and bother Philip if you want it sooner. I think we can afford to wait. For one thing, it will go much faster if we have Git since multiple people can work on it easily. For another, we may not actually have to wait: k776 keeps a reasonably up-to-date mirror of the source on GitHub. The multiplayer lobby and attack notification stuff have been developed using that, and I think the new GUI could as well.

Yes. Definitely yes. Redesigning the GUI could, from the coding side, be a bit of a nightmare. That said, I'd love to help out with it. (I'm quite familiar with the GUI code and do happen to have Photoshop.) I suggest we wait on this until the Git migration is finished though - it could take a while, and during it parts of the GUI/the whole GUI could easily be non-functional, so it should definitely be in its own branch. Also, Git will make it much easier for multiple people to work on it, which might be critical to get this done in a timely manner. BTW, I really like your mockups Pureon. As with the other though, I think the gradient on the labels in the diplomacy box looks rather weird. Perhaps it should just have the gradient on labels ending with a colon (e.g. options dialog, etc).

I agree with quantumstate, this could turn into a bit of an organizational disaster. We have the Help & Feedback Forum for this anyway.

Here's a game I played yesterday. We didn't get to finish it (people were getting out-of-memory errors and I had to leave anyway), but I think the result was clear enough by the end anyway (I think the other team was going to win). EDIT: And here's another one:

Indeed, not sure how I missed that... pretty sure I was half-asleep when I was looking at them. I'm not very fond of the slinger's face, although I can't quite put my finger on why. I think it's that the shape of the hair, mouth, and eyes looks a little too cartoony. The priestess's hair and pose I don't like much at all, but everything else looks fantastic! One suggestion: these are Carthaginians, from North Africa. Their skin should be a fair bit darker IMO. Also, lol at the Twilight icon. How do you draw stuff like that?! It's amazing!