Jump to content

WhiteTreePaladin

WFG Retired
  • Posts

    2.319
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by WhiteTreePaladin

  1. Some thoughts on ships: I think ships should be treated more like naval buildings rather than naval units. In other words, they should be more rare, not interfere with regular unit training by having build limits instead of using population, they should train units, and they should be able to be captured. I think that would result in ships better supporting land battles and in more fun and manageable naval battles. Build limits rather than population (Featured in AoE3) It's annoying to build up an army only to have to delete units in order to build ships to reach the enemy. The computer player isn't too good at this. If you attack the computer player and manage to destroy the enemy ships while keeping the computer busy training troops, then the AI player won't have the population room to train any boats. On the other hand, if you let the computer player build unlimited ships, it will often build so many that the land population is handicapped. This excess of ships more often than not will get clumped up and the AI will block itself it in. This prevents naval trading with allies and traps the ships near the dock that have the units the AI wanted to use in an attack. Training units (Featured in AoE3) I think we might already do this to a limited degree, but I think it might be nice to expand it. This prevents shuffling as many units back and forth. This is particularly valuable during exploration as you wouldn't have a smaller and smaller force as you left units behind to build on each island. The reinforcements provided at a battle would help with offensive attacks as attacking over water gives the defender enormous advantages. It wouldn't be too powerful, since there would be build limits on the ships. There wouldn't be enough ships to train large armies, but just enough to keep an attack going. Units trained from ships should have a longer train time than ones trained at buildings. Capturing The current arrow attack would remain, but an additional capture attack (accessed by holding CTRL) would be available that only works on other ships. It would move your ship next to the other ship (like load/unload) and your boat would attempt to capture the other ship. The other ship could fight, attempt to capture you, or flee. If the other ship tried to flee, you would have to trap the ship in order to try to convert. Once a ship is converted, the units inside convert too. (Heroes would be an exception. The hero would be removed and the original player could ransom the hero. (Basically, just repurchased as if the hero had been killed.) A tech like heresy in AoK could be researched to prevent conversion of units, but the ships themselves could still be captured. Garrisoning units would affect capturing in the same ways is it does for buildings currently. Unmanned ships would be especially vulnerable to conversion, while fully manned ships would be nearly impossible to capture unless the ship was heavily damaged.
  2. I think the market tech that allows collecting resources at an ally's dropsite requires three traders to be trained before the tech can be researched.
  3. I think it would be really nice for skirmish maps to allow fewer than the max number of players. You can currently unassign players, but that leaves a do-nothing player rather than an empty base. The BFME series allowed this on skirmish maps. BFME also made the starting bases visible on the map preview image and you could assign the starting point for each player if you didn't like the default starting positions. A player number was displayed on top of the starting position icon and directly clicking on those icons on the preview image cycled through the remaining player numbers. We can indirectly do this in 0 A.D. by rearranging the players, but it requires trial-and-error to see where everyone actually ends up.
  4. Yeah, I definitely agree that getting any generic, multi-purpose changes added to the main game is the best case scenario to limit future maintenance. I think the things like swimming in water, etc. are probably generic enough to be added because there are a lot of modders that would like those features. There are new public releases for 0 A.D. around twice a year. While that's not as fast as 3-4 months, it might be worth waiting. I think for your more ambitious players that can't wait, they would need to apply your mod to the dev version of the game. If most of your players use windows, then they could use the autobuilt exe in the dev version and wouldn't have to build it themselves. This makes it much easier to use the dev version because your players won't have to worry about setting up all of the dependencies needed for compiling. The only other option is to package the dev version, but that's a significant time investment for something that is potentially buggy.
  5. @LordGood had an excellent animated trebuchet in the ponies ascendant mod. Should be easy to extract that from the mod. There are a lot of nice medieval things in that mod actually. The fortress and civil center are too large though and should be scaled down a bit.
  6. Actually, Blender works great for models. In fact, many of the current models (and animations) in the game were created in Blender. Gimp is good choice for textures if you do not have access to Photoshop. [edit] He is one of the reasons 0 A.D. exists. Here is a link where you can read more about him: https://wildfiregames.com/forum/index.php?/topic/9732-ken-wood/&tab=comments#comment-167828 Each alpha version has a unique name, so the next alpha will be called something different. There is nothing wrong with wanting to rename your version. I think someone already posted a way to do that. [edit2] You will have edit a lot of places if you care about translations, but the main place appears to be in: ./binaries/data/mods/public/gui/pregame/mainmenu.xml: <translate>Alpha XXIII: Ken Wood</translate>
  7. You do not have to provide a free download of your game. You do have to make the source code available for free if it is GPL. This only applies to source code, so you don't have to provide free binaries. You can charge for those as a convenience, but people are free to compile it on their own if they have the ability. If you created your own artwork, you can license that however you wish. That does not have to be given out for free, so it is possible to use GPL for code and still prevent people from distributing your game for free. If you base the artwork on 0 A.D. artwork, then Creative Commons would apply.
  8. I don't understand this. They will always be able to play our game for free regardless of what changes you make. You can somewhat try to hide that your game is a derivative of 0 A.D. However, because our game uses the GPL license, you will still legally have to provide your game's source code for free to anyone that requests it. The only way around this is if you write your game completely from scratch and do not use any 0 A.D. code. The artwork in 0 A.D. uses the Creative Commons license which has its own set of rules.
  9. The 16 GB of RAM is surely overkill for regular playing even for max settings. I guess that the beta version probably is doing a lot of logging and debugging to recommend that much RAM. As for the graphics, 4K does take a bit, so that doesn't seem unreasonable. Processor and video memory seem about right. The 10 MB must just be a starter file that downloads the rest.
  10. This would provide new players with a better experience because it is easier to manage 200 than 300. (The increase in performance would also help with first impressions.) Itthink it is something we should still do even if we want to wait for some AI work first. Should probably put a ticket in. I'm going to be too busy to add the ticket for awhile, but if no one else does, then I'll try to add it eventually.
  11. Technically, victory could occur before the timer runs out if the player with the wonder manages to defeat all of the other players first (destroys all opponents units, structures, etc.), but I don't think the message should reflect that as that's just too confusing. "Will win" is probably the best way to handle it as the wonder message should really focus on the wonder timer and nothing else. This applies to any victory type that has a timer condition.
  12. I was not aware of the max population in a tooltip or the objectives. The objectives could be shown off in a tutorial and the max pop could also be mentioned in a tutorial. You are probably right that many may forget or ignore it. The AI handles the lower populations fine, but is dramatically easier to beat. This is because the AI cannot overwhelm the enemy with large forces as easily because some have to be reserved for civil duties. This makes skirmishes more defensive which favors newer human players who are not as skilled in the game. (It makes turtling much easier.) Once an adequate defense has been built, a large army can be constructed. The human player can opt to build a wonder and/or make all gatherers into fighters for a significant population advantage over the AI. This works well against the AI because the it will generally not do either of those.
  13. "Will have won" is in future perfect tense which is slightly different than the regular future tense. Future perfect tense implies that the event will occur by a certain time, not necessarily exactly at the time mentioned. Future tense implies that the event will occur at that time. So in our case, the future perfect tense "will have won" means that victory will occur by the time the timer finishes, whereas the future tense "will win" implies that victory will occur when the timer finishes.
  14. While most labels should probably use title case, it's OK if some things are not title case if it is more natural to not use title case. It depends on the circumstance and the nature of the label. The important thing is consistency; we don't want title case on one label and not have it on an equivalent label right next to it. [edit] As for that particular example, it should probably use title case, but I don't have a strong opinion and it's fine with me if you leave it as is. Thanks for working on this.
  15. I'd probably let scenario designers add those details. Adding it to the model will give it a more square footprint which is more awkward for a rectangular building. (You end up with an "unwalkable yard" around the structure.)
  16. I think AoK had 75 for default and 200 max. AoE3 was 200. Another nice feature in AoE3 was that ships didn't use population. They had build limits instead which worked very well. Considering that our game mostly occurs on land, I think using build limits rather than population for ships would be a good idea also.
  17. I've been playing on both 200 and 150 pop recently. A lower population limit makes it more difficult to defeat another player by using quantity of units alone. A variety of units types and some tactics are required. This makes it easier to survive the computer player's attacks because while the AI's growth is good, its tactics are average. This increase in survivability allows the game to be more accessible to new players. It also increases performance by quite a lot. Because of this, I think we should lower the default population limit from 300 to 150 (or maybe 200). One caveat with a lower population limit is that wonders become necessities for longer games because of the hardcoded population increase. Perhaps the population provided by a wonder should be a percentage rather than an absolute? (Would be nice if there were some visual indication when the max population limit was reached. This would prevent building additional houses just to see if the limit increases when the max is not readily known. For example, because the Persians have a 10% bonus, their max pop is 165 when the global pop limit is 150.) I think the AI should be encouraged to build wonders more often when the population is constrained. Even with deathmatch resources, the AI does not tend to build wonders. I found a workaround: wonder victory with a maximum timer forces the AI to include a wonder in its strategy and the long timer provides enough time for the players to be defeated naturally. It would be nice if a workaround were not required so that wonders would be built with other victory conditions.
  18. That would be nice. I think 16 was mentioned before.
  19. That sounds like a bug. It's certainly not expected behavior. (I guess it somehow uses different code?)
  20. Couldn't you give Gaia a "population limit" check before spawning units?
  21. I think that has been discussed at some point. I like the idea. I don't know if there is a ticket for it though.
  22. I just think it looks odd to see the same player listed twice in the list. It's incredibly minor though.
  23. I noticed that if you capture additional wonders, they are all listed in the wonder countdown timer message. Ideally, it would only show the oldest wonder message per player. When a player's oldest wonder is destroyed or captured, then the player's next oldest wonder should appear in the message.
×
×
  • Create New...