wraitii

Yeah, the game is hardly balanced but afaik it was not a concern (or at least, a very minor concern) for the Alphas. Then again, 0 A.D. will have to come out of Alpha someday, and it looks like it could be soon enough (well, relatively). BTW, Mythos, I see you decreased starting resources to 300 each, that's probably something you want to put in the "release info" on the homepage.

Hence why I think, at least for the first age, it should probably be "5 buildings of the village phase or higher", aka "5 buildings".

Correct me if I'm wrong, but isn't it even weirder if you can't go to town phase while already having, say, 5 buildings from the town phase? Agree with the starting resources being lower. 1000 is a lot.

Is it really necessary for structures to be village structures then? It seems a bit counterintuitive to me.

Expect it within 2 weeks, perhaps 1. Apart from the many bugfixings, Alpha 10 features, as you said, neater walls, technologies, but also healing and AI improvement. And many many bugfixing.

Perhaps 2 could be implemented as "shift+ungarrison all" or something.

Well, removing "village" is a possibility, since you can only build "village structures" anyway. Perhaps "Requires 5 buildings" would probably be the most explicit/short. "Of any type" makes it looks like they must be the same type or something, it's kind of confusing. I still think 5 is a lot, BTW... I know 0 A.D. ain't much for rushers anyway, but perhaps it could be set to 3 or 4. Or perhaps as a civilization bonus.

The best thing is that Quantumstate implemented correctly something I was too bored to implement: counting how many gatherers work an any supply. I think i'll steal that code in return . I'll have to test the new qBot, it's probably going to be a great benchmark for my new economic implementation in Marilyn.

This looks very good already on buildings, I'm extremely unsure the game needs anything more for buildings, given the maximal zooming of the camera. However, Parallax mapping on the terrain could give a very cool effect for things such as grass, where it would be MUCH better looking, and I think you should focus your efforts on that.

Allright, following Pueron's advice, I'm revising the economic manager, and making interesting progress. The new idea is that I keep a list of resources that I want to collect from for each resource type (ultimately, perhaps subtype too), and then I'll assign the most efficient workers to each. Still much of a WIP, but I think it can be very efficient. And as it seems like Quantumstate added a way to count the number of entities working on a resource at any given time, I'll probably get some inspiration to do that from him.

Parallax mapping only really needs to be implemented for buildings and terrain, however, which considerably simplifies its adoption. This all looks particuarlry promising anyway, keep up the good work

Any update?

Oh yeah, should have remembered that from when I tampered with HDR on Ogre. I still think the effect is too strong, because for example in your screenshot the whole ground is bloomed... at such a scale bloom should only happen on extremely white stuffs, I think (which should solve the 'units lose their shadows' problem). But hey, that's for the art department to decide, and anyway, it's very cool .

Yeah, Mythos and Bruno seem to be on that... I've sent him a PM about this, but then I figured that it's probably not too expensive to count the number of workers on any given resource at any time, so the PM I sent him is really a non-issue... I intend to fix it, and along with some clever UnitAI, it'll be.

Yeah, the effects might be a tad too strong (it looks like someone upped the contrast a bit too much), but it does give this sort of "I don't know what they're doing, but it looks niiiiice" feel that is really cool. Not applying SSAO to the terrain would indeed fix the halos. My guess is that most units wouldn't require it either (or as a setting for really advanced graphics, since that would computationally be slower.). Afaik, specular is dealt with on a case-by-base basis already, can't SSAO be done that way too? Buildings could use finer SSAO, while most units hardly benefit from it. For the terrain, you could have, on the contrary, a very rough filter that would have the effect or pretty much not detecting units, but would make the inside of forests darker or something (perhaps a huge downscaling, or something, I have no idea of the technical details behind all this).

Ouch, that hurt . i've got to learn to play this game properly... Anyway, thanks for the test... I noticed Marilyn being quite confused when you attacked during her attack, which shouldn't be... Will look into that and this error.

I think it's because of a failure to reload the GL screen or something... They're aware, it's been disabled in the last SVN afaik. Though I liked it, this CTD was the fastest way to quit the game when debugging

Good to know, thanks! Allright, I'll keep watching. No problem about the technologies, take all the time you need, better done well than rushed. Another thing about the API: I see you use "VectorDistance" for "ByDistance" filtering... I've done checks in the past, and at least on my computer (but I'd expect on most), it was faster using SquareVectorDistance, even with the added multiplying (though by very little). Since afaik this will trigger for every position change for every entity in any entitycollection that requires it, I think it could be a, however little, welcome addition (if for some reason, one comes to do it 1000 times per turn in some extreme cases, it could make a difference).

You're a very good beta-tester in that Allright, it's fixed in the lazy way: it won't return an error, and the code should still work consistently. There's no practical and cheap way to check if the unit has a position in entityCollections.

Thanks for the report, Pureon... I think it's again a case of unit garrisoning... I think you had an army of soldiers of some sort and you suddenly garrisoned all of them, causing the entity collection GetCentrePosition function return undefined. Any other report?

Yeah, typeof seems dodgy with anything that isn't explicitly a javascript type, that's why I replaced it with some other check... I'm not sure I understand Philip's explanation, but I guess he knows enough . Anyway, it's good it's fixed now.

I've got to say, I didn't really try to reproduce it... It's a weird bug for sure, I didn't either notice anything that would have caused a recursion... Perhaps it was a special case cause by something I did that was unexpected in Javascript... I'm really unsure what the circumstances of that particular crash were, though it was when an entityCollection tried to attack a gaia unit (iirc). Unless it comes up again, I think you can ignore it.

Allright... This being my last day of holidays before at least 3 weeks of hard work ( ), I'm releasing Marilyn in its current state as a "proof of concept", if you will. Please report any error, suspicious warning, or weird behavior, this will allow me to tackle them when I have time. Note: it should only work with SVN. There is one non-lethal known bug: sometimes, the game will freeze for ≈10 seconds, before resuming with lots of "out of memory" errors. Afaik, there is no following crash or problem, I don't know what causes this, any help is appreciated. If it causes a crash for you, please report. Otherwise, I haven't really thoroughly checked, but it should be mostly working, at the very least in the 15 first minutes. I haven't actually played a game much longer than that since I started recoding, so I don't really know what could happen . It does about all the things the former Marilyn did: -Attacking. It will create armies, and will send them after the strongest enemy (I think), though it might get stuck sometimes, perhaps. -Defend. Marilyn will reliably attack any incoming army, and will deal with animals and lonely scouts. I'm not too sure what happens if one of its unit is out of its territory, but that should be a fairly rare case. I think the defense manager is actually more reliable than the former one at this point, even though it's not yet fully implemented. -Build stuff, much like the former Marilyn, only it chooses the templates dynamically using a system of roles. -The economic aspect of things is basically the same, I haven't touched it much, but because the plan manager is not yet perfect, it may have a few troubles building enough villagers in the mid/late game. What it doesn't do: -Raiding... And some things during attacks, such as responding to being attacked. I haven't had times to recode this, as I've basically scrapped using the old Tactics Manager, and haven't really coded anything new to replace it. -It's completely oblivious to technologies. Do not be surprised if Marilyn builds a fortress as its first military building. -It won't build towers or fortresses for now (though most civs will likely build a fortress as its first military building, bar perhaps the Persians). What it does better: -The Defcon system for defense has been revamped, and now Marilyn will garrison/ungarrison females. The defense manager is also more clever, it's able to pause attack plans if it takes their units. -It's not "better" per se, but Marilyn is now mostly dynamic for unit training and building. All civs are supported. This doesn't change much compared to qBot, but you'll notice Marilyn training champions for its attack plans instead of anything, and building fortresses instead of Barracks, things like that. Technical side of things: I use entity collections everywhere. In the two "census "files, which are the unit/building info manager that Marilyn uses to know what it has/what it can build. In the defense manager, for enemy targeting/knowing which of my units attack. In the enemy watchers, that keep track of enemy armies. It's very neat, and very dynamic. Quantumstate, if you read this and have some time, I think it could be interesting to look at the code (most notably in the attack plans/defense manager), there are likely some stuffs that you can put into qBot. There might be a git repo in the file... Ignore it, I haven't updated yet. Marilyn.zip

I tried it quickly (in an inelegant way, and I want to leave the implementation to howlingflute anyway) and I guess something that ranges from alpha 75 to alpha 175 for a lack of resource from 0 to 500 would work well.

Good idea. Not sure if that's actually feasible, but I think using the resource icon and not the name would improve readability. Ever so slightly, but still. Also: it might make it look a lot like a Christmas tree, which would be bad, but have you tried coloring more and more red as the resource lacking are important (with alpha)? So that at a glance, we'd now how much we need more. If it works from an aesthetic point of view, it could be useful. I think the effect can be quite potent even with small differences in the alpha, so that it looks good, and useful. Edit: I also recommend changing your code in Unit_command.js to this: if(guiName == CONSTRUCTION || guiName == TRAINING){ selection.hidden = true; var totalCosts = {}; var multiplier = 1; if (guiName == TRAINING && Engine.HotkeyIsPressed("session.batchtrain")) multiplier = 5; for each (var r in ["food", "wood", "stone", "metal"]) totalCosts[r] = Math.floor(template.cost[r]*multiplier); var neededC = Engine.GuiInterfaceCall("FindCostNeeded", totalCosts); if(neededC.length){ //only put on the red overlay if the button is not already grayed out if(button.enabled != false){ button.enabled = false; selection.hidden = false; } button.tooltip += "\n[font=\"serif-bold-13\"]Insufficient resources:[/font]\n"+neededC.join(", "); } } It will show red properly if the user clicks on "shift", which is much more intuitive. It doesn't take into account the batch size, though, I'm not too sure how to get that.