Leaderboard

Hopefully It takes in account Lordgood's Enrique's and Radagast, advices. BlackSmith.7z

There might be ways to use a GPU to implement certain kinds of pathfinding efficiently, but that article is not one - it looks like about the worst possible way you could use a GPU . If the maximum path length is N (with maybe N=1000 on our maps), it has to execute N iterations serially, and GPUs are very bad at doing things serially; and each iteration is a separate OpenGL draw call, and draw calls are very expensive. And it's only finding paths to a single destination at once, so you'd need to repeat the whole thing for every independent unit. It would probably be much quicker to just do the computation directly on the CPU (assuming you're not running a poorly-optimised version written in JS on the CPU). AMD's old Froblins demo used a similar (but more advanced) technique ("Beyond Programmable Shading Slides" on that page gives an overview). So it can work enough for a demo, but the demo has much simpler constraints than a real game (e.g. every unit in the demo has to react exactly the same way to its environment, it can't cope with dozens of different groups all wanting to move towards different destinations) and I doubt it can really scale up in complexity. (Nowadays you'd probably want to use OpenCL instead, so you have more control over memory and looping, which should allow more complex algorithms to be implemented efficiently. But OpenCL introduces a whole new set of problems of its own.) And performance on Intel GPUs would be terrible anyway, so it's not an option for a game that wants to reach more than just the high-end gamer market.

Sorry bout that, i hadn't fitted the dude model to the dae now fixed. Nimrud Tiara.7z

Now that you've mentioned it I remembered there is a religious ceremony somewhere in Japan once a year in wich a archer has to shoot from a running horse. Let's use the yabusame rider as well, then.

Final Nimrud Tiara.7z

Orange patches on the minimap are for berry bushes, green for trees, brown for huntables, white for treasures/Gaia gray for stone, etc.

Here's a proposed list of units. Note that those are merely descriptions rather than definitive names: INFANTRY -Samurai -Ashigaru Arquebuser ("musketeer") -Ashigaru Pikeman -Sensei (martial arts master) -Ronin -Warrior Monk -Archer CAVALRY -Mounted Samurai -Mounted Pikeman SUPPORT -Male Peasant -Female Peasant -Ox cart -Shinto Priest Just some I thought of. I also think that the samurai would be the most powerful infantry unit in the game, so, not to give the Japanese too much vantage over other civilizations, the samurai would be very expensive and would have a limit of 10 trained by castle ( that is, 20 in totality, since there are both mounted and unmounted classes). This also agrees with the fact that, since the samurais were nobles, they would exist in much smaller number than other warriors. The ronin, in the other hand would have no limit and would be trained in the dojo. We need to figure out more hand-to-hand units.

A saved game will never replace the commands.txt. A saved game only saves the current state, while commands.txt saves the history of all actions.Otoh, a commands.txt can't replace a saved game either, as replaying the commands.txt to get to the last state takes way too long. You can't have saved games that take 15 minutes to load. And it's easy to make a proof the AI can be saved game compatible, the current state of the AI is a proof of that. We just lack the man-power to implement it. It will cause a lot of code cleanup on the AI side, which is hard when the AIs are constantly changing, without any AI dev caring about saved games.

I have reproduced the issue which Ykkrosh mentioned. When the point precisely on the edge, we will get a very bad path. I modify some code in previous patch. It seems fixed now. //------------Modified Begin//If this is an axis-aligned shape, discard non-silhouette points easily.if (vertexes[n].quadInward == QUADRANT_BL) if ((vertexes[curr.id].p.X > npos.X && vertexes[curr.id].p.Y > npos.Y) || (vertexes[curr.id].p.X < npos.X && vertexes[curr.id].p.Y < npos.Y)) continue; if (vertexes[n].quadInward == QUADRANT_TR) if ((vertexes[curr.id].p.X < npos.X && vertexes[curr.id].p.Y < npos.Y) || (vertexes[curr.id].p.X > npos.X && vertexes[curr.id].p.Y > npos.Y)) continue; if (vertexes[n].quadInward == QUADRANT_TL) if ((vertexes[curr.id].p.X > npos.X && vertexes[curr.id].p.Y < npos.Y) || (vertexes[curr.id].p.X < npos.X && vertexes[curr.id].p.Y > npos.Y)) continue; if (vertexes[n].quadInward == QUADRANT_BR) if ((vertexes[curr.id].p.X < npos.X && vertexes[curr.id].p.Y > npos.Y) || (vertexes[curr.id].p.X > npos.X && vertexes[curr.id].p.Y < npos.Y)) continue;//------------Modified End

Just came across this article of a guy doing pathfinding with WebGL, which is slow because getting the texture back is only supported pixel by pixel. However, his Game of Live using same architecture is freaking fast, so OpenGL might support a faster way. If I understand it correctly the algorithm resolves multiple paths requests per call and time only depends on size of map. Probably the expertise of writing a shader to do pathfinding is quite rare within single mind, but 0AD has shown quite some prolific synergy effects, so I wanted to check if this solution rattles some nerves.

That's nice =D But what will happen on people using Intel Graphics ?

Thank you Zophim, it's exactly what I meant. reusing Hittite Spearman (the basic). This also means you have less work in the Hittite Design Document as the basic Hittite spearman is already described in the Assyrian document. I realised that there is the Assyrian Raider and already created the xml for it. Once other WIPs are settled (e.g. the Mod Configurator) I'll start creating those units with Lion. Modelling buildings also is easy due to the many reference images in the book you recommended in the design doc. Excellent work.

If you're going to make a city building game, make sure it has realistic unit sizes and supply lines! nah just kidding gl with your project

Ok, there are already some things I see that will be hard to do. We have no cinematics (that's something missing in general, not just for triggers), and triggers can't ask for special GUI windows (like the selection you propose). The other things should be possible. Though may require some extra code to make them easier.

This is good news indeed, I don't use MacOSX personally but knowing more people can play 0 A.D. is always a good thing.

Yes, I'd say it wouldn't be too difficult to turn 0 A.D. into a city building game. It would mostly need a different gui, and different simulation scripts. So if you're an artist, you can start working on art for our engine, and some programmer might drop by. In the mean time, your art can be used as eye-candy here (if you release it as CC-BY-SA), so your work won't be lost.

Until support has been added, we can simply assume that the units have gephyrophobia.