vv221

I’m strongly in favour of using the single player campaign as a milestone to drop the "alpha" label and enter the "beta" phase. Keeping in mind that I am biased by being a long time player who almost never plays multiplayer. What I look for in RTS are skirmishes that do not get boring (so many kinds of maps, and playable civilizations that are not mirrors of each other) and either a long campaign (like in Warzone 2100 or Age of Mythology) or several shorter ones (like in Age of Empires).

On game stores like Steam and GOG, this is actually tiny. People used to buy games there won’t back down due to the game size.

No a lot. I would not be surprised if more than 90% of GOG customers were Windows users.

I don’t think there is any such version of the source code (A26 + OpenAL 1.24 fix), nor that it would be planned.

A fix is now included for Debian sid, and will be part of the next upload. This bug report will be automatically closed when this upload is sent.

I can confirm that on a system that uses ALSA, without PipeWire nor PulseAudio.

A basic 64-bit (x86_64) build using dynamically linked libraries is what would be expected, as well as a list of libraries that should be installed by the end user. The target should be an "old enough but not too old" system, like the current (or previous) Ubuntu LTS. GOG does not provide official support for any Linux distribution besides Ubuntu, so users of other distributions are expected to find out by themselves how to get games to work (like translating the list of dependencies to the package names provided by their system). Anyway, for Linux users installing from their distribution is always going to be the best option, providing a Linux build of 0 A.D. through GOG would be more about visibility than usability.

GOG uses their own installers, that are based on InnoSetup for Windows and on MojoSetup (+ Makeself) on Linux. I don’t know what is used for the MacOS installers. I don’t know the exact process, but I strongly suspect these installers are done by GOG, not by the game developers. That would be surprising, as there is not a single game page doing that on GOG for now. Customers of this store already know about 0 A.D. and talked about it positively on their forums over the years. But according to the low popularity of this wishlist entry, it is not (yet) a game that many people would expect to see distributed on GOG: https://www.gog.com/wishlist/games/0_ad It would be much better not bothering with that and not trying to support it in any way. The goal is to get more visibility, not a source of extra work Whatever we do, if 0 A.D. is added to GOG it would automatically be downloadable/runnable through Galaxy, but we should not waste time and energy working on Galaxy integrations with things like cloud saves or achievements.

I can’t say how easy or hard it would be to pass through their curation process, but I think 0 A.D. would be a great fit for GOG, if distributed there as a free game. It would no even need an "early access" label (it is already in a much better state than many *released* commercial games). Many GOG customers are starved for RTS games, and multiplayer games that can be played without going through a store launcher/DRM. Many of them joined the store for "old" games and are still waiting for Age of Empires, so having access to 0 A.D. could scratch their itch. I expect launching the game on GOG would have a bigger effect on 0 A.D. popularity than what itch.io did, if only because of the small catalogue leading to each game getting more (relative) exposure. To get an idea, here is their full list of so-called real-time strategy games (most of these are not even what we would call RTS): https://www.gog.com/en/games?genres=strategy&tags=real-time&hideDLCs=true It would be very easy for 0 A.D. to shine when compared to most of these games. --- On the topic of the alpha version, I too am in the opinion that it does no longer help. I would suggest dropping alpha, beta or whatever and stick to the 0.0.27 naming scheme (0.1.0 would be first beta, 1.0.0 first "complete" release). Alpha/beta could stay in internal discussions, but no longer has an useful meaning for distribution.

For the discussions we currently have on #0ad-dev (I do not follow #0ad), I think IRC is already the best option. So we would only need to switch to a server with support for TLS encryption, my preference here would be OFTC (already used by Debian). I would be happy with XMPP too, even if I think it has too many features for our needs (and unused features are bugs lying in ambush). From an user point of view, it would be very similar to IRC with better support for private messages. I think it can be used without an account, but I don’t remember having tried that. The ability to link the discussion channels with the game lobby would be a very big upside, if it were considered that would make XMPP my favourite option. My experiences with Matrix have all been really bad, so this is not an option I would support. The clients especially seem to mostly be either awful (Element) or incomplete. I do not know anything about Zulip yet, so I won’t comment about this one. --- TL;DR: 1 vote for IRC, and 1 vote for XMPP.

This is a very apt description, and having no problem at all wrapping my head around pointers might explain why I do not see submodules as really confusing.

It looks like I have been a bit too slow with my EDIT

I do indeed think that per-dependencies repositories would be easier to work with than a common repository for all libs. Then the way we include these, be it with curl+tar+patch or submodules, is in my opinion not of a big importance. I think the best option is the one the people who will actually maintain the build tools would rather work with.

The difference would have been the ability to patch the source more easily, but Stan` wrote above that we use OS-specific patches, something that submodules could not help with. --- EDIT: Actually the OS specificities could still be handled as per-OS git branches, so applying the patches in these repositories instead of doing the patching at build time is an improvement that could still be done. Improvement that could be done no matter if we chose to go with submodules or tarballs, so this is not really an argument in favour of submodules themselves.

I think they do bring another upside: we need to patch the source of some dependencies, like SpiderMonkey. If we used submodules instead of the curl+tar+patch dance, we could provide an already patched source instead of maintaining patches in the 0ad repository. I am assuming here that the repository fetched by the submodules is not the upstream one, but something we would host ourselves. --- To avoid confusion: I am not advocating that we *should* use git submodules. What I mean here is that *if* we decide that they could help us, I am willing to work on them to make their use as painless as possible.