hyperion

Capturing is the biggest reason, people playing tiny sized maps another and finally the ever reduced average game duration is what made territory less important than it was. This potentially breaks carefully crafted maps, acropolis bay might even be affected. Something else to think about here is build distance restrictions.

Mostly within, also imagine again the super ultra wide display where the exit button needs half a day of mouse moving to reach

If moving to the side due to ultra wide screens is undesirable this is the the next best solution to preserve art. Dead center is almost always problematic. I agree on this one.

Single-player vs Multiplayer, me thinks either both should use a hyphen or neither, tho I admit I'm not that great in English. Also I agree with Freagarach that the center bar is not ideal. For your background it works somewhat but most existing ones will have important elements cut out. They are fine pieces of art and deserve better Maybe an approach like the bottom bar could work with a corresponding font or maybe just move those 3 buttons to roughly where they were in the original design. Guess they won't be any less prominent there than if they are dead center.

Glad someone still remembers this freetype builds out of the box with cross mingw, haven't looked into glad2 as of yet. Also form discussion the move to compressonator is very likely and as such another blocker would be out of the way.

If you hadn't said anything I could still happily think of it as a temple, now I'll be irritated whenever I see it

Splitting anywhere else than project boundaries is a bad idea IMHO. For the sake of argument let's assume binary assets are an issue or are anticipated to become an issue then lfs is a superior solution to some hand crafted custom setup. For me engine and game are two different projects. Two projects can live in the same repo in theory but it takes a lot of discipline. In practice this rarely ever works. Let's have a look at 0ad premake.lua with the lofty goal of building multiple static libs so they can be used on their own outside of pyrogenesis. In practice there is tight coupling, even plenty of cyclic dependencies, further stuff in third_party was made dependent on pyrogenesis as well. Then look at the directory public, supposedly the game, which contains plenty stuff which belongs to the engine making the engine unusable without the game. The engine having a proper API one day is pretty much out of reach in such a setup. pyrogenesis has 0 cve listed, so the most secure piece of software ever ...

The scope of the discussion isn't particularly clear, going by title and poll it seems a debate svn vs git. I'm a proponent of git. For most part either works, and whoever prefers to work with the other can do so independent of what the master repo uses. So what would one gain from migrating to git, there is quite a list but I limit myself to what I think is most important for 0ad mostly based on commit history and what comes to mind right now. Git unlike svn respects authorship. Pyrogenesis/0ad is a volunteer project as such attribution is of paramount importance for many if not most. Git workflows encourage commit often. As such commits are far more likely to be properly split, i.e do one thing only and do it properly. Git workflows don't differ between diff and commit. Often subject and message of the commit are even more important than the code change itself. Using a git workflow both are made part of the review process. With git you push commits. Bad commits, which happens to the best, can be fixed before publicizing. Some points made in this thread I think are worth addressing with a few words. Git and binary handling: Well, the current binaries in tree and their history are a non issue when using git. Stan mentioned lfs, there are other means of binary handling as well, all with their own pros and cons. Discussing them might make sense but can be ignored just as well. Autobuild: It's _very poor_ practice to store build artifacts in the repo irrespective of vcs. Also last I checked there were more Linux than Windows users therefore we need to replace them immediately with Linux binaries to maximize the use for our users. A proper solution if people want to use prebuilt artifacts is to add a script which fetches them from CI. This would work for any commit and not just selected ones plus for all supported platforms. Regular proper pre-releases for testing could be provided as well, so pure testers wouldn't even have to bother with a vcs at all. Split repo: If pyrogenesis/0ad is considered an engine plus a game and not just a game a split is almost mandatory. We can have a very lengthy discussion about this but is out of scope here. First, yes, a proper split is more complex than putting public into it's own repo. Second, as for why spidermonkey as a dep sucks for us/distros is to a large part that it's in the same repo as firefox.

And I bet it ignores relativity, so like most other games a fantasy physic engine. Good choice as no one want's to play a realistic space shooter

if you want to display 7 blender cubes per second as warp 3 it's a one-liner for your mod ... If it makes you happy you can also mod 0ad to append li/h to speedvalues to give it a "realistic feel" for most units, the engine doesn't care.

Increasing females gathering rates would be mostly the same, just that unit spam is probably to common in 0ad, so I'd try out adjusting CS (including cav) to have 80% of current gathering rates of females for any resource (including hunt so the scout is more likely used for scouting instead of butchering chickens) instead. This needs quite some testing tho as it has quite far reaching impact on the current meta. Females being always better at eco will force a trade-off for CS, which is what you desire and I can imagine to be good for gameplay, as for lore one can argue the arms always carried around dragging the CS down.

Ok, create a cube of 1m x 1m x 1m in blender and import it into 0ad. IFF a unit with effective speed of 7 moves anything other than the distance of 7 cubes lined up per second it's a bug. Anything else you find confusing or unreal goes under artistic freedom.

It's m/s, never ever km/h. As alre correctly pointed out, there is some ridiculous scaling involved, like a sea having a width of 200m. The only thing that is somewhat realistically scaled wrt in-game meters are buildings. No surprise a 4m tall spear man walking at 7m/s or a ship crossing the Atlantic in less than a minute.

So you are saying CS are to cheap for their economic/military value => adjust price/economic value/military value. There are plenty of possibilities to add new unit types, so question to answer are: Are more and more unit types a good thing for gameplay Do specialized economic unit types add anything to gameplay Do they fit the game lore For point 2 I only see more micro intensive eco management, whether to treat this as a good thing(tm) is up to each and everyone.

We don't need dozens of pseudo features possibly all with own options in vanilla. Map creators already have the tools necessary to do whatever they please. Where pyrogenesis is lacking is ease of sharing such content. Maybe support download from host, maybe support fetching from github repo will do. If you want exciting content for single player start creating campaigns!