Yves

Great news! Welcome back, Ben! Of course I remember you. You helped me with my first patch (premake upgrade) and I joined the project after that!

I've worked on an OpenGL4 renderer that uses more modern features like instancing and bindless textures in 2016. My conclusion was also that the renderer is a bottleneck and it's mainly memory bound. I've even tried Intel VTune Amplifier, but switched back to Perf later. By changing how we pass data to our shaders and reducing the number of draw calls, I was able to reduce that overhead by a lot. Unfortunately my work never got beyond the experimental stage. I've written a small blog in the staff forums. I've copied the two most recent post here, if you're interested (still from 2016). The code from the experimental OGL 4 branch is still around on github: https://github.com/Yves-G/0ad/tree/OGL4 Post10: January – Profiling, profiling and ... profiling: Post 11: 10th of July - Bindless textures and instancing:

As I've mentioned a few days ago on IRC, I'm also working on a battalion system. We might be able to share ideas and code, if you don't mind. I've only had a brief look at your code on github. I might want to copy parts of it, especially the battalion selection code. Is that OK for you? I've uploaded the current state to github: https://github.com/Yves-G/0ad/tree/BattalionSystem Feel free to copy if you find anything you can use. It's still very experimental and unfinished in the current state. There's a demo map included with (currently) just two melee battalions that can attack eachother.

Between Spidermonkey 1.8.5 and 38 there have been many profound API changes and it took us countless hours to adapt the code to these changes. The GUI was especially difficult because it used a wider range of different API functions for the object oriented aspects. During the upgrade we have reduced the complexity of this interaction, which helped streamline the upgrade process in the future. You have valid points for the object oriented approach and I'm not against it, in principle. I just advise to keep the upgrades in mind an avoid adding too much complexity and diversity to the C++ <-> JS interaction. I don't know how much the Spidermonkey API keeps changing nowadays, but given how much Javascript is still changing, I suspect that's still an issue.

I had loading times of 40-50 seconds for a few days and now I'm getting http 503 too. I'd guess there's a performance issue with the forum database because files load quickly and other parts of the forum are also relatively slow (like around 10 seconds loading time).

You answered my question only partially. So far you have identified most issues with the current gameplay and you have outlined some possible ways for fixing them. That's a good start, but it's still quite far away from a concept that can be implemented. Decision have to be made where multiple alternative solutions have been suggested, dependencies between features have to be identified and clarified, detailed descriptions have to be written per feature etc. If developers want to help, they need very specific and detailed information how a feature should work. Do you think it's realistic to design such a concept, write it down and then also implement it in roughly 6 months (I guess 3-6 is too ambitious)? As I said, it would not be complete yet, but it should be complete enough to give a good impression of the final gameplay. If you don't know how long it would take to implement something, that's fine. you could still estimate how long it would take until the first parts of the concept are finalized enough so that someone can start with the implementation and how long you'd need for the whole concept.

Do you think it would be possible to implement your suggested changes in a proof of concept mod/branch in relatively short time of around 3-6 months? The scope would have to be limited as much as possible without leaving out anything that is crucial for the gameplay as a whole. For example, it could only focus on one civ, placeholders could be used instead of new artwork and workarounds or hacks for difficult features are OK. What tasks would have to be done exactly and how much help would you need from the team? We are still discussing your application in the team and I can't give you an official answer yet, but such a proof of concept implementation seems to be well supported. The tasks required for it (further work on the concept, setting priorities, defining tasks) are the next step anyway, so it should be ok to get started with it.

I'm looking forward to reading that document! The lack of a coherent gameplay design is the main issue that prevents us from going to the beta stage and eventually releasing a 1.0 version in my opinion. We need someone with dedication for this task! I've been working on game design for several weeks but then got stuck with a problem I haven't been able to resolve yet. There has to be a plan who could implement missing features in a reasonable timeframe, otherwise it's not going to work. As soon as your design includes some very though technical requirements, this becomes an issue. In my case, I felt that fighting mechanics in this game are quite dull at the moment and I wanted to include some formation fighting mechanics (see: http://trac.wildfiregames.com/wiki/FormationsWip). When looking at the technical aspects, I realised that all our pathfinding code is currently designed around single unit pathfinding. The formation system we have is basically a hack that works more or less OK in most cases, but it would require a major overhaul to meet the quality requirements for such a formation fighting system. Because the fighting system has such a strong impact on other aspects of gameplay, I stopped working on the design and started looking into pathfinding. How would you handle such issues? It's always a possibility to work around such technical problems with the design (drop formations, reduce population cap). You actually see that a lot in commercial games. One part of me thinks that perfectionism is misplaced here (if large companies with big budgets do it, why shouldn't we?). On the other hand, I'd like to strive for more than just another generic RTS that copies the same mechanics we have seen in commercial titles for years or even decades now. Maybe both is possible with a very clever design...

Hello and welcome! I like it, that's a nice addition to the hawks which already fly around in some maps. I'm a programmer and not really qualified to give feedback about art, so I leave that for one of the artists. Yes, you can. Have you already taken a look at the existing hawk actor xml here?

Looks like the perfect testcase for the instancing I'm working on.

I don't had anything specific in mind for multiplayer. It's maybe just because I think that multiplayer games are way more interesting than single-player games. They are more dynamic, more surprising and more challenging (even though wraitii, mimo and the others did a very good job with the AI ) . My comment about tutorial videos was just my personal preference. If you have something in mind, go ahead and give it a try.

In my opinion, tutorials how to play the game aren't particularly interesting. There are some around already and even though I've enjoyed watching some let's plays on Youtube, I've never watched a pure tutorial video about a game on Youtube. In addition, gameplay is still changing quite a bit and tutorials could be outdated soon. Traditional let's plays don't seem to work very well for 0 A.D. either. We don't have a single player campaign yet and only some multiplayer videos were really interesting to watch for me. What really sets us apart from other games is how our development works. There's regularly new content to showcase and gameplay frequently changes because of new features or balancing changes. Something like the development reports, but in a video format, could work and could also attract new developers. You can search in the Announcements and News forum for these development reports. I'd say some well commented multiplayer matches would also work and modding or creation of a custom map in our map editor, but I don't know how well the modding and mapping suits you. EDIT: These guys do it pretty well with development reports in video form: wolfire.com

A problem with writing to the config file could be. It would be user.cfg, not local cfg and for the Mac it's in "~/Library/Application\ Support/0ad/" according to the wiki.

I didn't know we take Bitcoin donations. Everything about donating is described here: http://play0ad.com/community/donate/ EDIT: I misunderstood your question. I thought you wanted to donate but don't want to use Bitcoin but it appears you meant the opposite.

Part of what you describe seems normal. The Javascript engine, for example, schedules a Garbage Collection (GC) regularly. During GC, it reclaims unused memory, but it only gives it back to the operating system from time to time. If I remember correctly, it should not go beyond 400 MB, though. But there are other parts of the game that do similar things like the VFS (virtual filesystem). The VFS keeps some data in the cache because it takes longer to load it from the disk than loading it from memory. So it doesn't work to look at memory usage in the first few minutes after the game is started and then calculate a memory growth rate based on that. But... This must not happen and is a bug. When did this happen? Was it in the menu, in the multiplayer lobby or during a game? If it was a game, was it paused?