wraitii

Allright then. Indeed, it's more logical that way. To do some "idiotic stuff", I've tried renaming the app bundle... Still works. Atlas starts, but I get a wxWidgets error when I try to move around :"../src/osx/cocoa/combobox.mm(114): assert "item >= 0 && item < [m_comboBox numberOfItems]" failed in SetSelectedItem(): Inavlid item index."

A slight concern: what about horses? Are they assumed to be able to turn 90° in an instant? They will one day be able to charge, how to implement this?

There is certainly space to simplify my code, even without any API changes... I've modified stuffs from qBot while not necessarily removing them, changed things, made some pretty idiotic design choices now and then (It's now changed, but I asked the "game" for the entity associated with an ID... By asking said entity to give its ID. In other words, I asked for informations I already had while using it). I'll try to clean the code, to remove most errors, and to optimize the code for the next version... I'm currently cutting the map into smaller squares for the economy manager so it won't have to loop through every resource on the map each time it wants to assign a unit a task... It's working much faster (on Gambia river, a forest-ridden map, it's at least twice faster for each unit, so it's quite quickly 5 or more times faster), but it demands quite serious code change.

Well, there are 4 batches of wood on the right and 8 on the left... My concern was more about "reachability"... The players on the left are much closer to the wood since it's more packed... This is not a huge concern, but I'm reminded from my old AoE II age that this can sometimes make a difference (particularly since they wouldn't have to build a dropsite) That's why I suggested moving the town centers a bit farther from the Nile: all players would benefit from building a dropsite in the early game. But it's not really anything too important.

Gave a look at your code, I see why it would be fairly complicated... Given the way the map is designed though (river starting from the top going to the bottom and the sea is at about 2/3 of the map), perhaps you could factor in a "WATER_WIDTH * Math.max(1,(iz - (mapSize*0.6) / 10.0))" instead of simply "WATER_WIDTH", which would effectively enlarge the width after you reached 6/10 of the map's height. (I'm not sure this code is clear to you, I think I used your variables, if you have any questions, do ask). edit: giving this a try... For now it flooded the whole map, which was fairly fun but not very playable. edit 2: gave this a few tries... it's possible using a finely tweaked "1/(-x+2)^3" sort of function, but given that the lowest part of the island is not always exactly on the same spot, can't be done every single time.

Gee, that's really good for a random map algorithm. I only have one playability concern: the players seem to have unbalanced resources (ie the bottom left one has more nearby wood) which I think should be avoided as much as possible in random maps. Perhaps the players could start more into the desert?

That's great, historic_bruno. Very nice work Just one question: you seem to export the collada models directly, ie not use the library... Any reason for it? Edit: just tried it. Downloaded, started from the dmg (which sometimes can cause bugs), and everything worked fine on 10.7.2 on a MacBook Air. You've really done a great work.

Could you quote the log, just for information?

Okay, so here's the fixed version. I think the next update will be in more time, since it seems like whatever I will add now has to be fairly significant. This fixes many insidious bugs in many things, but mainly the defense and the attacks. As a result, Marilyn works overall better ate defending, and at attacking too. I've also slightly updated the queuemanager: things that have been in the waiting queues for more than 30 seconds will gradually become more important, and this helps reducing a phenomenon I encountered which was "in the endgame, Marilyn builds no citizen soldiers and few villagers". Did a few further testings, on Serengeti... Fixed a house building bug by the way. Marilyn generally behaves on par or better than qBot. On Oasis, Marilyn/Hellenes vs qBot/Persians is won by Marilyn in about 30 minutes. The other way around is perhaps more to the advantage of qBot, but it appears qBot behaves better with the Persians, while Marilyn does pretty much the opposite. On most other maps, I expect the results to be about the same, with perhaps a slight advantage for Marilyn. On maps where animal are a threat, Marilyn is the clear winner. Download link Oh, and I've figured git out, too. I'll get the qBot from SVN and play against it (couldn't manage to compile SVN, but with a very benign tweak svn qBot should work on alpha 8). edit:darn, forgot to check out a debug in plan_building.js ... Search for "obstructionradius" and remove the debug. Marilyn.zip

Could the end of the river running toward the sea be enlarged? It would look more natural. Otherwise very good.

I think the shallow straits are way too blocky, but otherwise it's pretty good... Any way to make the transition from wet sand to dry sand smoother though?

Isn't the sea on the left too big? I feel like it could be reduced a bit, it would speed things up slightly.

Actually, I tried yesterday, but I ran into a problem... I think I'll try to figure it out later on though, because it could indeed be useful. I've discovered a really crazy amount of bugs in my defense manager and my economic managers, that should now be fixed, so I think I'll do some testing and release another version... Then try to test against the SVN, and use git. I also did a few changes to the queue, basically: after 30 seconds, queues raise in importance with time (ie older queues are given priority)

Shall try, but I'll fix the trouble I'm having with the queue manager with (seems like Marilyn sometimes stops buildings citizen soldiers, and a few weird stuffs).

Okay, some more bugfixing... Apparently there was a problem with javascript interpreting my variables as pointers, and a few stuffs I forgot to do in the tactics manager. There are still a few bugs left when the attack manager can't find a path to the enemy, but those should basically only happen after said enemy's death so not a serious problem. The tactics manager (ie battle manager) is now designed so that units will only change target once their former target is dead (works much better). Did some more testing on Sahel Watering Holes, the map being crowded with elephants and nasty fauna... And Marilyn is definitely much stronger than qBot on that map, thanks to the new "animal killing" capability she has. She always defeated qBot (or both qBots, actually, but in this case they simply annihilated each other) in under 30 minutes (and it was basically over after 25). edit: see below

This. This this this. It's okay if they don't have a warship, as long as they're slightly stronger on land... But then you absolutely need to make a "random for sea maps" options.

Okay, so I worked most of the day on Marilyn... I think it did some good... I've seen it once crush qBot in 25 minutes, but that seemed to have been a lucky strike... Overall, she's now much more resilient, and again, I've laid ground for further upgrades New stuff (basically): -fixed Fortresses building improperly. -Houses are now far away and more concentrated. -Attack Plans can now continue during an attack, or be used properly by the defense manager. -The Defense manager is overall more efficient, and able to detect attacks better. I've also laid grounds for different types of attack recognition, though it's not yet implemented. -Ability to take care of annoying animals attacking citizens. To playtest this, check out Sahel Water Holes: Marilyn deals with the elephants (particularly true for player 3). This makes her MUCH more efficient than qBot on this particular map. -Attack plans keep their tactics manager over several turns. Thus they should work better, I'm not sure what effect if has but it can only be good. -refined a few stuffs in the queues to make everything easier, and made Marilyn build units for plans by batch of 3 and not 1 -Added a few stuffs here and there. edit: see post below. Overall, I did a few test drives, and I'm finding Marilyn much more resilient against the mighty qBot (alpha 8). She's more rarely defeated and I've seen fairly clear victories. On maps where animals are threat, she will now be much better than qBot. There's a lot of tweaks to do (she builds too many fortresses, for example, and more importantly: making the defense manager understand that attacks too far away should not be pursued.), but I think I'll be able to actually add some stuffs in the next days (early scouting, raiding against villagers, this sort of things).

Thanks for the report. The error is actually fixed, it had something to do with counterattacks when all units are dead. I'm upgrading the defense manager for now, using a defcon system. Also, a few economic stuffs.

Design choice then, no problem, I'm merely worried that it might break choosing random civilization on multiplayer... Perhaps you could set a "random", "random with boats (ie not iberians" option. Of course, since random maps are barely existing right now, it's not the hugest concern.

Side question: is there any other way to win than "military" in this game? Or at least planned? Because it seems like Iberians are pretty much sure to lose on islands map in other cases.

Thanks, I certainly could not have guessed that. I'm not comparing with qBot so much for actual comparison as for having a basis to compare with, so I'll wait for alpha 9 I think, unless you add some drastic changes (from what I've seen, there have been many smaller changes, but no drastic ones).

This is really extremely strange. Has anybody else tried on SVN?

I just noticed a fairly serious issue with the economic manager that caused it to concentrate much less on food than it should. Something about my "maxperfield" parameter working and not my "maxpertree". Anyways, this made Marilyn very easily defeated in the long game. I'm also updating my tactics manager to be usable over several turns instead of having to be reconstructed each turn, and a few other stuffs in defense. edit: looked at the svn updates since Alpha 8... Can't see anything that would cause such an issue. Edit: okay, this is worth another upload. here's the latest version: Download Changes are that Tactics is now usable over many turns (the defense manager uses it), and fixing a few balancing problems with the economy manager. In the games I tried on Oasis (qbot vs Marilyn, with both playing both sides ( tested twice each configuration )), Marilyn is now superior to qBot in basically every aspect, but she's not that much of an attacker, so the game is pretty much a stalemate. Edit2: actually, another update: I incorporated some of the svn-qBot changes, and mainly I optimized a lot the "reassignidleworker" function, so you should not experience any lag spike.

Ah indeed, perhaps this has changed, I'll give a look. (darn developers developing ) Edit: I don't see any of that particular code having changed... Seems like qBot does the same. Quantumstate, any idea?

@Quantumstate: no, testing against Alpha 8. Haven't got around to get the svn because compiling can be a bit of a pain on OSX for now. I don't see any reason why it wouldn't work, however (bar the fact Romans are not supported yet). @Mythos_Ruler: that's weird. You're sure you have the "common-api" folder in your ai folder?