Jump to content

wraitii

WFG Programming Team
  • Posts

    3.434
  • Joined

  • Last visited

  • Days Won

    76

Everything posted by wraitii

  1. Agreed. It's a little saturated (perhaps it looks different in-game though, seems like this is a Blender render with some approximate AO). I'm a little concerned some buildings will be too decorated, but if the texture is for fancy buildings it should be all-right. (and I'm hoping you will give the Egyptian building the same sort of "resting in the sun" feel as to the Carthaginians one. Dunno where that comes from, though. Might be that they have a stronger AO.)
  2. This would require severely limiting farming, though. I do agree with the Aura idea. This all depends on if farmlands are implemented. If so it's obvious: make corrals better on non-farmland areas, and farms better on farmland areas (actually better than corrals). With a few twists, this will make farms hard to defend, farmlands interesting to have, and this will also create real diversity in food sources. It's a choice for the player, and it seems like it would be pretty fun. I mean, that's at least a case for having farmlands. It would solve that issue very nicely.
  3. Certainly in RTSs like AOE2/AOE3, there was an obvious early game food source: hunting, and an obvious late-game food source: farming, with hardly anything in between. I even recall a very detailed study on AOE3 which showed that whatever the situation, corral was useless. So that's bad. Right now in 0 A.D. things play out much in the same way: the corral is generally worse than farming late-game, worse than gathering/hunting early game. Thus it never gets used, even if it's in itself in the game. So the game "apparently" has diversity, but in fact only two actual food sources (three if you count berries apart) instead of 3/4. I'm not against having hunting better early game and farming better late game, it's "semi" realistic, a fairly basic mechanic, and it's still interesting. Furthermore the advantage from hunting/gathering really goes away because food gets scarce, so if you're motivated you can still do it later in the game right now. Corrals however are problematic because they are basically a blend between farming and hunting: fairly micro-intensive, static, average gathering rate. So they're never the better choice. So what could be done about this? Perhaps farms should be more limited in how you can use them: perhaps we could only allow them to be built on farmlands, which could be scarce. So you would fight for them and otherwise rely on corrals. Other solution, as Alpha123 said: make farms require more workers or more space for the same efficiency (perhaps make their yields more diminishing). This would be trickier for players, but it could be interesting. Basically you'd need huge farm fields with a few workers on each, which would be harder to defend from raids (and obviously costlier to build)… than only having one or two corrals in your base. Final solution: find a way to make corrals better in some specific strategies. A possibility here would be to rely on techs: through some clever playing around with stats we could probably make corrals more attractive if you want to rush for food in the beginning (like making them cost minimal wood, I dunno. This needs to be faster than hunting quickly, though), which would make them more attractive than farms to rushers. Then with techs we make the corrals even more attractive, but specializing on corrals (through linked techs) makes farming less interesting as time goes on and you never really switch back. For a slower player, farms could still be the way to go. So that would make corrals do something, allow farms to still retain a use, and also keep hunting/gathering as the early game gathering resource. I'm saying this about rushes, but we could make it more interesting for some actually more daring of even more specific strategies, or some specific cases. At least, they should be different enough that they're attractive in some situation. For example, right now cavalry units hunt at an insane rate. If it's also true for sheeps, it could be interesting for an early all-cav rush. I think the key here is to make corrals useful in different situations than farming. Not making it more or less equally good, as the players will always end up with one solution, the ever-so-slightly better one. I don't really have an opinion on the farmstead vs city center thing. I'd be ok with them being required to build fields. Perhaps simply a bonus to gathering rate of fields around farmsteads would make them more attractive than city centers to build farms around. (afaik, hunting is basically always the best choice for food in terms of gathering rate right now, even late game, if you upgrade. However the hassle gets big. So I think that balances itself nicely.)
  4. None that I know of. Reddit hasn't really gotten around to know about 0 A.D. yet. Which is in my opinion both a shame and a chance, since it would probably be pretty successful there, but then we can wait until the game is actually ready for advertising there.
  5. I think we should aim to make effective/doable as many different playstyles as we can, in fact. (obviously as long as it doesn't infer with other realism/doability/fun rules)
  6. If you need some input about not saving things or optimizing thsize, feel free to ask.
  7. (Just giving my opinion) I think any 3 of the top elements would already make a strong release, and in particular running and building capturing could probably be split over two releases as they're really major gameplay element (and running might require a new pathfinder). I probably won't be able to do much of anything beyond try to fix the AI serialization for this release unless it draws until July/August.
  8. That's my code in the fancy water shader... Looking at it it appears like GroundDirection is obsolete code and should be removed alltogether. WaveforceHQ does appear to be incorrectly not deleted (probably should be done after its last use, or line 543 in WaterManager.cpp)
  9. I think opt-in is likely better for AIs. But yes, the current system was quickly done and is fairly ugly. It is indeed not too trivial to fix those issues. It basically requires Ais to save things sanely, but to recreate them sanely... Basically instead of the "do everything in the constructor" approach, we would require a "Init" function that is only called once at game start, and which deserialization simply overrides with the deserialized contend.
  10. Thanks for the report. I can't seem to load the saved games, is there something special about quicksaves? I can't think of any reason for your first error, frankly, it seems like it should only happen if the AI no longer has entities. Your second one is annoying too as it probably should not happen either... Given what time I have, I'm not going to be able to go through and properly fix those, so I suggest switching back qBot in the meantime (and/or add to Aegis' description that it doesn't really support saved games.)
  11. I've committed a fix for the specific error above, but there could be others remaining. I'm at home till monday, won't have much time but some quick fixes could be done. Please play the game, try to save/load regularly (particularly interested in games when Aegis prepares an attack, or when it has started an attack: the army should stall and do nothing, but should be reused for the next plan.) If you encounter errors, I'm interested in the saved game.
  12. Might be able to fix those, but I fear this will be mildly hard to do, and not before this WE. Probably should un-default Aegis then.
  13. Not exactly relatively simple, but not too hard, so it should be fixed in the latest SVN. Requires an autobuild but I haven't run one yet as perhaps it would be worth waiting for other commits? Basically I hacked together serialization for the shared script, which makes Aegis serialize properly. it's fairly hacky. Not sure how well the AI will react, but it loads and resumes playing. It makes the saved games slightly heavier, but not significantly. I tested serializing Aegis, qBot and No AI at the same time and it worked (along with each alone), so I assume it's working alright. I won't be available for too much debugging though, so if it should actually fail, feel free to revert those changes.
  14. I just moved the topic from the dev forums to the public forum (removed posts about that too for readability). Copied, in spoilers, are 3 of my posts originally in the dev forums about some more specific AI stuffs. Again, I stress that this is mostly informative. Defense: Multi-base support: Naval Manager
  15. Gave a look at this, should be fixable to some extent, in fact.
  16. Err, actually the error messages are really not that trivial to fix (basically they'd require making it serialize/deserialize fully, more or less). At least I believe. I can give if a look if it's considered nice enough that Aegis fails silently to make it default, else it's probably not worth it. Have qBot be default again if this is bad enough, then (should be trivial enough in the current SVN). I'm not 100% sure but I think I have added this to Aegis' description though. Will check. BTW, this would need to be verified too, but I'm fairly sure while qBot doesn't give error messages, deserializing it is also not that nice, so we probably shouldn't pretend too much that saved games with AIs work.
  17. Known issues, zoot, but thanks for reporting them, this could be useful. I'm assuming it's a punjab map? Basically to fix this requires rewriting many things or improving upon many things, which is planned but not for now. sanderd17: might be fixed actually, defense and attack were not mixing together so well because of an issue.
  18. Ok, I've given this some thoughts. I like your idea of the "restrict selection to bounding box" thing, it could be useful, but I also think we could try to avoid it if we had options for selecting particular stuffs in the bounding box directly. SO we do have the "add only military units" to selection. This should definitely pair with a "add only females to selection". We probably could use one for "Add only idle units to selection". I also do not think you can "deselect" a type of unit by any key combination when you've selected many right now, but I might be wrong (I mean in the GUI screen at the bottom). Furthermore I was re-reading the reviews to Celtic Kings (old, unknown RTS/RPG hybrid that was pretty interesting) and it appears they had hotkeys for "select weakened units", "select veterans", things like that. I'm not saying it's high priority, but I think it'd be fairly cool to have something like that.
  19. Think you mean the first 4 alphanumerics being "0", " " , "A" and "." which are all usually on top
  20. I see. I must say I can't think of anything in the AI code that could cause that. Use of random is still limited to the seed in the beginning. Furthermore I can't really see how a whole army could be missed. I'm kind of baffled.
  21. Any way to be sure this is related to the AIs? (also, to be perfectly honest, if it is indeed AI related, it's probably a weird issue, and I won't have time to fix it for Alpha 13…)
  22. Basically with 6 barracks it should hardly have to queue anything, though there's often a few barracks that do nothing. I'm not sure how efficient the AI is exactly at that but generally speaking it should not be too overkill. Choice of building to attack should be more optimal than it currently is. I think it has something to do with the stance of siege units. I'll try changing it to defensive yo see what it does. The fact it didn't attack the siege rams is more surprising. Perhaps it was busy elsewhere, there might be weird reactions in those cases.
  23. It has been changed anyway. Thanks for the report zoot . So anyway, I'll be going back to school now, I expect I will not have any time to work on 0 A.D. for the next weeks. Please report any errors (here or in the bugreports forum) nonetheless, and any weird behavior (if possible, try to debug them as much as possible, or try to find a way to replicate these errors, as this will considerably facilitate debugging). (edit: I committed a change this morning that may or may not be good. I'll test it, and revert if it's not).
  24. I'm opening a new topic since the API version 3 has now been committed. Kind of a conclusion on the past 2 weeks' work before I head back to school, and probably abandon developing 0 A.D. for a good 2/3 months. Warning: this is a huge wall of text, mainly intended for my own reading later, so that I may pick up where I left off without too much trouble . So basically I'm fairly happy of how much progress has been made on Aegis in these 2 weeks of holidays I got (on top of the work I did back then). Defense has been fixed to a fairly great extent, the attack has improved, the economy has learned how to deal with technology and phases without really losing much in terms of efficiency (there's room for improvement, though), and generally everything has been made more robust than it was before. There is however still a lot to do, as most players and myself can already tell. I would like it if we could release a "Hard" AI that did not cheat. Currently hard mode cheats by gathering 33% faster (and very hard 66%). In order to do this, many things to consider: First, the AI build order needs to be perfected. I've watched replays of mainly Quantumstate and Alpha123, but there is still work to be done, everything is not perfect. Furthermore the economy manager still isn't completely rational in the way it assigns workers, which makes the AI lose a few precious seconds now and the, but this is particularly problematic in the early game. Also, it doesn't trade. Secondly, the AI is still very hardcoded. I've switched most of the "time" checks to "number of workers" checks but this is far from enough. The AI is generally hardly aware of itself when it takes decision, thus leading to average decisions, and mostly to a lot of trouble with unexpected cases. In particular, raiding the AI early currently tends to cripple it, as it does not recover well enough, trying to start attacks instead of focusing on rebuilding an economy, things like that. Thirdly, building placement in general needs to be improved. the code for dropsite placement is in itself fairly efficient, and returns generally pretty good results. However, the code that decides when to build a dropsite is extremely inefficient. Placement of most other buildings is basically random with a few tweaks and doesn't really follow any particular logic, when it probably should. Third big issue: the defense system is still quite flawed, both from the "no sense of self" effect of the AI, which will make it defend useless things, defend in obviously losing battles, or not defend enough when it ought to, and the many flaws in the logic. It's basically very "instant" defense, it doesn't really consider what happened in the past or what might happen. Case in point: a tower on the border near an AI dropsite will basically make it get all its workers killed as it doesn't really notice. Fourth big issue(s): attack and unpredictability. The first subpoint is that the AI sucks at attacking. Basically it makes relatively balanced armies, but it sends them to the enemy and doesn't really consider how to use these units the most effectively, making its attack mostly useless against a skilled (micromanaging) player. Secondly, the AI is extremely predictable. It has only one real "strategy", if you can call it so, which is also extremely hardcoded and not at all enemy dependent. Work on that is less of a priority, of course. The AI should probably handle the above points first, and then we will be able to consider making it actually do interesting things. Finally, I'll post again the "to-do" list I had posted on the AI API version 3 topic back in early november, as most of the points are still valid -No real naval support. It can handle attack over water, in a basic way, but that's it (Update: that actually might have become slightly buggy) -No handling of multiple-island realms. For Aegis, its starting island is all there is on the map. -No handling of the cases where the AI runs out of resources to gather. It will start lagging and clogging the queue manager. Linked with the above points. -The defense system is really basic. It can't handle continuous frontier skirmishes, placement of defense buildings is not logical, no wall building, it's not reacting perfectly to attacks either. No sense of "this is a dangerous area, I should avoid going/collecting/building there". No support for building units that counter the enemy favorite units. So many other things... -No diplomacy support (see Fexor's post in the general development forum) -Economy is still perfectible: drop sites placement and building could be optimized, as could be building construction, or even Build Orders in general. There are some slightly insane behaviours here and then. Generally this is probably the area where the AIs hold up the best, particularly Aegis. (Update: see above.) -Very partial technology support. Aegis goes up in phases, but it's not flexible. The API support for tech may not be perfect either. (Update: actually, it now researches all techs, but chooses them randomly. So work needs to be done on that). -Partial attack system. It's OK at strategy, but bad at tactics and will generally attack inefficiently (though Aegis is better than qBot at that). -no LOS/scouting support. AIs see everything. (Update: this is actually linked to making the AI react naturally: even when cheating, it should be aware of its enemies and take decisions based on them) -optimization is far from perfect, though it's slowly getting better. Some possible improvements: hierarchical entity collection filtering, getting the AIs not to iterate over all units in a single turn once in a while but balance the load... (Update: probably better now, but there is still ton of room for improvements). A last word about something that is still bothering me: the queue manager. Currently it gives "accounts" to each queue which grow over time as the AI collects resources. It works fairly well, but it has a tendency to make the AI sit on resources, particularly when the gathering rates are low and the needs high. I think going for the most human approach here is what would work best, but I must say I actually have little idea of what the "human" approach is. Basically we might need the rest of the AIs to register what they will probably want to train/build in the next minutes for the future needs to be fairly stable (which will also help econ…). Then we need the AI to actually pass stuff, making sure it doesn't sit on tons of food just because the next item needs a little wood, and to do it with the maximal efficiency. I am not sure what the best system for that is, but I think the current queue system isn't quite perfect. Edit: moved to general forum.
  25. I think it does pretty well on Oasis. But generally it should be mostly equivalent on all maps. Aegis doesn't really like crowded maps though (tons of lonely trees that go in the way of building things), but it's not too damaging either…
×
×
  • Create New...