Leaderboard

I will mod whichever version of the game gives me !#$%king battalions.

We welcome the constructive approach chosen by the creators of Fork AD. We didn't, indeed, agree on the design of the development environment, on the communication methods, and on how to ultimately make the process enjoyable for all team members. We are happy that they can still contribute to 0 A.D. as a project, even if it is as a separate group. We are grateful for their many past contributions and we hope that the new situation brings balance to both teams. Nevertheless, Wildfire Games wishes to clarify that we have been making progress on the game continuously and continue doing so. Much of the recent work was either administrative, or targeted at the future Alpha 24, thus could not be directly seen in the number of commits made. Members of the community have expressed a desire to be more involved and informed, so we are taking measures to open up some internal discussions. This will allow our hard work to be more visible. On behalf of the team,

Not necessarily a problem, there is nothing preventing artists from contributing to both 0 A.D. and Fork AD, or to other projects or different mods. Besides, the licences under which most (all?) of the content is released allow them to take whatever they like from the main distribution. Having two or more active branches/forks/related projects allows for trying out different things independently from each other. And if something turns out to work in one, others can incorporate it as well. That's what's so great about free and open source. The more, the merrier

The authentic eyes on the Carthaginian quinquereme aha nice touch!

Greetings! As some of you might have noticed development has nearly come to a halt a while ago. This was not only caused by issues around the initial attempt at releasing Alpha 23, but also regarding how development was done, and a certain number of internal conflicts. A few people were not quite happy with where the development was going, or how the team "interacted" with each other. A long time ago the team at least had each other's backs in cases of conflict. Apparently this ceased to be the case a while ago. You might now wonder why this sad story above is the start of this communication. Well, some of us decided that we were not happy with this, and after each and every one of us stopped considering the current team in this state to be good steersmen we decided to give the whole community an alternative. Please let us introduce you to Fork AD. The amount of changes that have been made to the code since we forked is greater in number than the amount of changes to WFG's SVN repo since May. That may not sound like a lot, until you consider that we've been at this for less than a month, and WFG allegedly has a lot more active members. Now we know you've been craving to know some details of what we've changed so far. Apart from fixing some glaring bugs in the code that were even pointed out to WFG when they were noticed, we are updating a lot of things so we don't place users of our code at risk. There also is a lot better Single Player support, though one could blame that on most of said code effectively being unmaintained, better mod support, improved development tools, a bunch of housekeeping that was needed, and more. If you now ask yourself when and where you can download Fork AD, we still have to defer you to a later point. We will release for all supported platforms, which are still Linux, macOS, Windows, and BSDs, once we are confident that we are releasing something that fullfills your expectations, and is something we can be proud of. Although the progress has already been substantial, we are always open for reinforcement, either from new people or from those disappointed or demotivated by the WFG direction. Artists in particular are very welcomed. As said before, the state of that fork is not yet publicly available, but all information will be given on our website when available. Meanwhile, you can reach us at https://webchat.freenode.net/?channels=forkad Kind regards, fatherbushido, leper and mimo.

I recently got interested in helping with 0 A.D. development, especially optimization. I was thinking how could we accelerate pathfinding and in consequence reduce lag. It already seems quite optimized, A* with JPS optimization. One of things that are still possible to do is to apply parallelism to pathfinding. Toady I've found this: https://www.aaai.org/ocs/index.php/AAAI/AAAI15/paper/download/9620/9366 By using method shown in the article we could not only run many pathfinding requests in parallel, but parallelize a single pathfinding request in a GPU-friendly way. We could use CUDA or OpenCL to implement it. Authors of the article have achieved 30x(EDIT: actually it's only x6 speedup. See my third post.) speedup of A* algorithm, which is quite considerable, however I am not sure how much would it speedup 0 A.D. pathfinding. I am not familiar with 0 A.D. code enough to start working on it, or even assess how much could it actually speedup 0 A.D. pathfinging. I have found few posts from 2012 about running multiple pathfinding queries in parallel(not parallelising single request), saying that this wouldn't be really useful for players without strong GPUs or multicore processors. https://wildfiregames.com/forum/index.php?/topic/16018-supreme-commander-2-pathfinding/&tab=comments#comment-239673 Well, today we have 2018(2019 soon), and even things as basic as desktop environments have multi core CPUs in their requirements, and most 3D RTS games have dedicated GPUs in their requirements. Sure it would be much more useful for player with NVIDIA GTX 1080 than for player with intel i3 integrated GPU, however I think that speedup for most of players could still be considerable. Maybe it will turn out too hard to implement, not as efficient as I assume here, not good for every player, etc... But maybe it will turn out that it really speeds up pathfinding , at least for players with dedicated GPUs.

These People Are Not Real—They Were Created By AI https://motherboard.vice.com/en_us/article/mby4q8/these-people-were-created-by-nvidia-ai https://medium.com/syncedreview/gan-2-0-nvidias-hyperrealistic-face-generator-e3439d33ebaf The truth is… wait for for it… both images are AI-generated fakes, products of American GPU producer NVIDIA’s new work with generative adversarial networks (GANs). The research was published today in the paper A Style-Based Generator Architecture for Generative Adversarial Networks, which proposes a new generator architecture that has achieved state-of-the-art performance in face generation. Since GANs were introduced in 2014 by Google Researcher Ian Goodfellow, the tech has been widely adopted in image generation and transfer. After some early wiry failures, GANs have made huge breakthroughs and can now produce highly convincing fake images of animals, landscapes, human faces, etc. Researchers know what GANs can do, however a lack of transparency in their inner workings means GAN improvement is still achieved mainly through trial-and-error. This allows only limited control over the synthesized images.

Okay, but do you want the player to have to consider all of this? Sure, unit differentiation is good to keep things interesting, but is this kind of differentiation really all that interesting? I would say "no", and I would wager money that most players would say "no" too. I would say that the player shouldn't have to consider all of this in order to make a good economy. Besides, when units are working, even though they still have their "armor" textures for easier recognition, they're really supposed to be in their "work clothes" so to speak, not really wearing any armor (which is indicated by their helmets being removed as they gather and shuttle), making their amor-based walking speeds a moot point. That's another reason why I think we need a ShuttleSpeed element: The units are being "civilians" at this point, not wearing their armor, so why should their walk speed which is largely based on armor stats and combat balance also be their shuttle speed? These are two entirely separate "modes" for these units ("combat" vs. "resourcing").

There has always been a way to change the key binds it just requires a text editor to edit one file look up on our wiki game paths the relevant file to edit is default.cfg If you want an in game GUI based way a reminder we are an Open Source project we are always short of coders so DYI if your in a real hurry Enjoy the Choice

I don't mean that, but by now we aren't sure what they want from artist, probably basic things, a new menu art, logo...etc. The question is... WFG team member(staff) can contribute? Indeed they can, but they should?

Nope, I use ArtStation https://www.artstation.com/victorrossi

Okay, at this point I see enough problems with GPU utilization on pathfinding. Sorted from most important to less important: - it would be hard to keep both GPU and CPU pathfinders deterministic and the same. - not available for all players. - will use GPU resources that are needed for rendering. - probably not needed very much. Multithreading is more important here. Therefore maybe utilizing GPU can wait. There are more important optimizations that have to be done first. Retries? Are retries what we do in a problematic situation? (I haven't read all of the code yet, today I had no time to do it.) Well.... We should not only reduce number of retries but remove them. That is actually multiplying our time complexity by number of retries.(hmm... you probably are already perfectly aware of this sad fact(no, not probably, sure you are)) Well, seems that multithreading and reducing number of retries to 0 would solve our problems with pathfinding. Not however sure if reducing retries to 0 is possibile or it has to be incredibly hard if we haven't done it yet. Well there is still lot of work for me. Thats both good and bad Yeah, @Imarok working with already made pathes is certainly a good thing to do. And it would be nice to talk to people who already worked with pathfinder. Tomorrow I'll probably have lot of time and I will complete reading the code and maybe start to write something. EDIT: This is a nice visualization of some pathfinding algortihms https://www.youtube.com/watch?v=rZHtHJlJa2w

Fine by me. You can also do portraits or a new main menu background, or anything you want to improve

I think reducing retries in pathfinder and threading the pathfinding calls should give us enough performance. Also iirc the bottleneck is not our global JPS pathfinder, but the local vector(not sure if it was really called like that) pathfinder. But @wraitii should be able to tell you more, as he already started improving the pathfinder some time ago (better shortrange pathfinder, less retries and threading). He uploaded some WIP on D13

Here's the finished file Amanirenas portrait.rar

Yes, but in case of N requests you need to do Application > Driver > GPU synchronisation N times, and update all data too (both on CPU and GPU to calculate next request). That's what I'm talking about. That's good. I wish you a nice coding regardless of result you'll get

Yeah certainly it will. I said that this 'boost' may be not enough. Then only option would be redesigning pathfinding. This is mainly what's wrong with it. I will try to multithread pathfinder, but many better programmers already failed to do so. Therefore I'm not sure how much I can do. There are many other things to multithread. Like NetClient or map generation. I can try multithread them too, but I'm really not sure how much can I do here. EDIT: If I do it all I will become a multithreading specialist EDIT 2: I just realized that what I said here may bet quite not nice. I really understand and respect these huge amount of work people have already put into this game. Only pointing out things that are still left undone.

Here actually there is one, https://discord.gg/fMeKkd But WFG team may wanna create new one stan already announced MAC version there

Oh, probably mostly some time. Code is quite well-organized and I'm quickly getting into it. I'm probably too young to be considered a real programmer(15 years old), but I'm learning fast and already have some C++ experience (programming since 11 years old). Probably many of you have programming experience much greater than 4 years but it's better than nothing. My main area of interest is computer science (training hard to get some nice title in Polish Olympiad in Informatics), and that's why I'm mostly interested in things like pathfinder optimizations. My amount of free time isn't very big, but maybe I could still help the project a bit. I will also have good chance to learn something.

Assuming the information in the in-game civ structure trees is accurate, the only soldier that does not have 0.6 Food 0.8 Wood 0.5 Stone 0.5 Metal gathering rates are the Skritiai Commandos which I personally am okay with because their combat ability makes up for it. And then also each soldier type has slower rates as they rank up. I did an experiment hoping to show how much the movement speeds affects wood gathering. The results were less drastic than I expected. I created a scenario where you start with a CC, a storehouse next to an oak woodline (28 trees - total 5,600 wood), some houses, 2 soldiers, and enough resources to build 20 additional soldiers. To make it somewhat realistic I created soldiers in batches of 5. I set the gathering point for all to the same initial tree and did not micromanage which trees they cut. I then recorded how long it took for the last soldier to drop the final piece of wood for each unit type (except Skiritai Commandos and Clubmen). I repeated each unit type twice and got the same results. Here they are: Skirmishers (12.6 Walk) - 09:39 Slingers (10.8 Walk) - 09:51 Archers (9.9 Walk) - 10:01 Swordsmen (9.4 Walk) - 10:19 Spearmen (8.5 Walk) - 10:20 Pikeman (7.2 Walk) - 10:53 Women (9 Walk, 0.7 gather rate) - 10:13* I got 10:13 the first time, the next two times were 10:23-ish but the final woman kept walking back and forth and wouldn't go around the women in front of the storehouse. Here is a minute by minute breakdown of how much they gathered. The last number in parentheses for each unit type is the time at which they had deposited all 5,600 wood. Minutes 1min 2min 3min 4min 5min 6min 7min 8min 9min 10min 11min Skirmishers 80 410 1,030 1,800 2,550 3,280 3,970 4,650 5,270 (9:39) ~ Slingers 60 390 980 1,720 2,470 3,190 3,850 4,520 5,140 (9:51) ~ Archers 70 370 970 1,710 2,480 3,180 3,820 4,450 5,060 5,593 (10:01) Swordsmen 60 390 1,000 1,720 2,420 3,100 3,750 4,380 4,970 5,478 (10:19) Spearmen 50 370 940 1,680 2,400 3,070 3,690 4,310 4,900 5,440 (10:20) Pikemen 30 350 910 1,570 2,240 2,900 3,530 4,110 4,680 5,220 (10:53) Women1 110 520 1,210 1,900 2,610 3,280 3,890 4,530 5,100 5,532 (10:13) Women2 110 520 1,210 1,880 2,620 3,260 3,900 4,510 5,080 5,541 (10:23) As expected, it is the case that the faster the walk speed the faster the wood collection. (The women are an exception because they are created faster.) However, much of the difference occurs towards the end of the woodline when more walking is required. So for the first 5 minutes the difference is at most 80w among the ranged units. Pikemen, though, even in the first 5 minutes pikemen are at least 160w behind other melee units. As the game goes on though the effect does become more pronounced. The end times in the data are important as they show how long it takes to catch up. It takes longer to catch up as the game goes on. For example, at minute 1, skirmishers are ahead of slingers by 20, but the slingers actually make up the 20 within 1-2 seconds. Real game factors - Due to path-finding, the workers move in unpredictable ways that can be inefficient. So faster units can randomly under-perform (as can slower units). - These results do not take into consideration soldiers moving from gathering to defend from a rush or to go on a rush and go back to gathering. On the one hand, if defending with archers instead of skirmishers the archers have longer range and would not have to walk as far from the resource to attack the invader. So theoretically they can get back to gathering faster. On the other hand they deal damage slower and may have to fight longer, especially against spear cav. In fact, the enemy rush could force the weak archers to garrison in the CC. It is not obvious to me if archers or skirmishers would get back to wood gathering sooner. Seems like it would depend on the enemy unit composition. I bet defending with slingers would turn out the best. Obviously melee units that have to chase the enemy down while walking slower would lose the most gathering time. If you go on a rush units with faster walk speeds will get back to gather faster. - Also, it is important to keep in mind that the faster you have resources, the faster you can produce more units, the faster you can gather more resources, and so on. This means that in a real game where you are continually producing units the advantage will increase non-linearly if you have faster workers. So you get more workers sooner, and the new workers you get are again faster moving than the opponent's new workers when he gets them. So how big of a deal is it? Does it matter if archers cutting wood for 10 minutes are 22 seconds behind skirmishers cutting wood for 10 minutes? It doesn't seem that bad looking at the data on the chart but it would feel bad if you were trying to build a ram and had to wait 22 seconds for the wood. Entering a battle with a hero or a siege unit can have a big impact on the outcome. And again, because of what's discussed above in real game factors, the advantage/handicap will be more than just 22 seconds worth of gathering. And if for some crazy reason instead of archers you made mostly melee units you'd be worse off yet economically. At the end of all of this I ask: Do we really want a game where you are both economically and militarily incentivized to produce mostly ranged units instead of melee? If archers must be worst of the ranged units economically, shouldn't archers have some other advantage to make them viable?