Leaderboard

I've tried my luck with the pantheon and this is what it looks like: I think it's quite ok for the start. It's my first project so it'll probably still have some flaws I'd be happy if some people could give me a feedback, I'll attach the blender files so maybe someone can also give me some technical advices. For everyone who wants to try it in Atlas, you can just copy the folder to your mods folder:) About textures... I think the mesh could have less triangles, maybe dissolve some faces and so on, but what I kind of struggled with are the textures. First I tried it with the texture of the existing pantheon and added a roof of rome_struct.png. Then I was thinking about creating a new texture file just for this building, but my texturing skills are too limited. In the end I ended up using four of the existing textures that I found already in the game. That's why in the end the mesh is sliced up in so weird props:D Anyway, it somehow worked, but still I got some unclean parts of texture on the mesh. The one on the left is the original one, the one the middle new mesh with old texture: So for the future, what would be the best workflow for texturing? First unwrap everything and make a perfect UV map, then paint a texture? Or use an existing texture and scale the UV islands according to it? How important is it to save disk space by using existing textures? Thanks a lot in advance! Pantheon.zip

What do you all think? I'd say it looks like a proper garrison force. We could try this out in the community mod along with faster build time. perhaps this is off topic, as the discussion is really on AI. I will post a pic in the community mod discussion.

I was doing different refactorings of our engine for last 1.5 years. It's allowed me to add a new backend (graphics API) - Vulkan. It's relatively new API (as D3D12) which allows us to have a more predictable and stable performance. And in some cases even better performance. But not always as we use it in a single thread yet. Vulkan drivers from different vendors are usually much lighter than GL ones. That's the way to have less driver bugs and crashes. But we still need testing how it works on different hardware. So everyone who has a Vulkan compatible device please try to enable it in options (along with feedback). If you're able to run SVN then you already can test it. Else wait for the next RC. Note: to run the game you'd need to download and install a separate mod with precompiled shaders (it'll be bundled in RCs and the Release): https://releases.wildfiregames.com/rc/0ad-spirv.zip. Vulkan can't run pure GLSL shaders (which we use for GL), it uses a special binary format for shaders: SPIR-V. Vulkan allows us to use different interesting features. For example it allows to select the most appropriate GPU to use. It means no more crashes because of wrong GPU, I hope Also Vulkan supports multithreading. If you still have some time you could run the game with validation enabled. It makes the game slower but validates a lot more different internal things. It should help to make Vulkan stable for the release. To enable validation you need to add the following lines to your usef.cfg: renderer.backend.debugcontext = "true" renderer.backend.debuglabels = "true" renderer.backend.debugmessages = "true" renderer.backend.debugscopedlabels = "true" Known issues: Screenshots aren't implemented yet, but going to be during Feature Freeze rP27552 Some precompiled shaders are missing, please report if the game says so macOS isn't supported yet, but we have plans to do so via MoltenVk rP27488 Missing silhouettes rP27418 Unsupported depth formats cause an assertion rP27421 Stretching on window resize after fullscreen switch rP27422

I know this is less likely to happen in practice, given it would likely require significant engine changes for something many might find too unusual to be worth it. At the same time, especially considering Pyrogenesis can be used for different products and genres including space / scifi, I definitely don't see it as something too wild to consider at all. So yeah, I was thinking about planet maps. Right now a map must be flat, circular though rectangular edges are also supported if I'm not mistaken. Were this idea to happen both custom and random maps would support an additional spherical format: When used the terrain is generated as a sphere rather than a plane. Obviously it could only produce unrealistically small planets you can easily circle around... even so it could be an interesting concept for sure. Such maps could provide both unique mechanics and visuals alike. Mechanically the biggest change is everything warps around, you can attack from different sides which would make the gameplay special. Visually it would also be an unique feat rarely done in an RTS: Apart from having an actual horizon where distant terrain covers while buildings have different inclination (think the effect in Animal Crossing), imagine being able to zoom out and see the whole planet from space! Obviously this would imply big changes to scrolling and movement: The camera would work differently as it pivots around the center point of the sphere, moving the view would also rotate it. All unit / building models will need to point toward the center of the sphere, otherwise just be aligned too the spherical surface and that should be it... not sure if pathfinding would have bigger issues getting adapted. Daytime and atmosphere would be a trickier one since we don't even have a dynamic day / night cycle for existing maps (although I think one can be scripted), seeing the proper time of day based on your camera position would be the cherry on the cake were the the rest to be implemented successfully. If supporting actual sphere mapped terrain is impossible, a simpler alternative would be allowing rectangular maps that are seamless and repeat around the edges. This would surely be easier to implement, main hurdle being a technique to render copies of terrain and models across seams while also allowing the camera to scroll seamlessly. However this method wouldn't allow zooming out so you can see the entire planet and manipulate it like Google Earth, zoom would have to be limited or you'll see infinite copies of everything.

I don't build stone walls, not because they are weak, but because I devote my workers and resources to making an army, military production buildings, and getting blacksmith upgrades. If you wall off your town that is nice, but you generally cannot wall off a safe space for woodcutters. If you are stuck behind your walls with an inferior army, your opponent can continue to outgrow you, take map control, and attack you when you venture out. I think there is a case for making walls when your opponent is using cav armies and I'm interested in exploring that.

On the model 12k tris is way too high. Maybe 4k-6k would be acceptable. Congrats on removing the unseen faces, it's usually where stuff goes wrong. You forgot to remove those from the inner roof though... Your building is way too round with faces, you should use smooth shading instead. There might be a way to get away with less faces on the front porch.

Usually the best workflow is to use one texture, maybe two for props.

Sure for release and CI builds anything newer then windows 7 sdk isn't an option, just meant to say if you build for yourself choose what you like.

my main suggestion for buffing walls is to lower heavily the stone cost of walls towers, which are in themselves pretty useless, but contribute significantly to the overall cost of walls.

I think I have better understanding now (after ~15hours of debugging ). In CounterManager.js, the onPress method must be defined to handle onPress events. The event seems to be triggered even prior to any GUI interactions after the game loads because it prints uninformative errors all over when onPress is not defined. The onPress mehtod from CounterManager.js overwrites the one I would define in CounterResources.js I try to make the resource icon / counter a button that would make a simple chat message: Engine.SendNetworkChat("I have " + this.count + " of " + this.resCode + "!"); I tried to bind variables resCode and count in various ways. I tried to make a renamed method in CounterResource like: class CounterResource { constructor(resCode, panel, icon, count, stats) { //... this.onResourcePress = this.onResourcePress.bind(this); } onResourcePress() { Engine.SendNetworkChat("I have " + this.count + " of " + this.resCode + "!"); } } For it to be callable in the CounterManager: class CounterManager { constructor(playerViewControl) { //... this.counters = []; //... for (let resCode of g_ResourceData.GetCodes()) { let counter = this.addCounter(resCode, CounterResource); counter.onPress = counter.onResourcePress.bind(counter); } //... } //... onPress(counter) { counter.onResourcePress(); } } I don't know how much syntaxes I've tried... I feel like sorry I can't make this seemingly simple thing to work. If you have any clues of what I'm missing, please tell me!

My $0.02: - Improve anti-lag (as many players coming from other RTS/Strategy games want bigger battles than 20vs20) - Rework trading path for AI, maybe even allow for custom path drawing (if there is enemy CC between two AI allies, they will just send their traders right through enemy base) - When AI is about to attack, it will always make a "build-up" spot, where most of army gathers (and pathfinder starts to sweat), maybe this can be improved? - When AI garrisons tower/fortress, it is easy to move units back out of map visibility, so AI will force defenders out of the buildings, then kill then and capture tower/fortress - Check if collecting game statistics (units killed etc) affect game performance, if it does then allow to disable collecting game stats - Gaia ships on some maps hit very hard, it is not possible to achieve same damage per shot with any civ