Ykkrosh

I don't follow why that would be the case. If there is a single lobby/matchmaking/etc server that works adequately, why would people bother setting up their own that compete with it? (I'm assuming that single server would be maintained by WFG, or if WFG dies then by some other single group that wants to continue supporting the game. The server should be designed to support forks of the game engine (maybe by treating them like mods, or like completely independent universes of players, or whatever) so non-WFG forks could choose to still use the WFG server and wouldn't need to set up their own.) If it's true that there would be multiple matchmaking servers that could potentially interoperate, then I agree it'd be good to design a way to let them interoperate, but I don't see why we can't (or shouldn't) prevent that fragmentation in the first place.

For private servers, do we need anything more than the ability to connect to an arbitrary IP address (i.e. how the game works now)? For LANs, I think the game should switch between finding players via the standard online lobby server and via LAN broadcasts (without any server at all; just do a UDP broadcast and see if any clients on the LAN respond), which doesn't sound too hard in theory. (In any case I think we should let players choose a different lobby server as a config option if they want to do something special, and the server software ought to be designed to be relatively easy for them to set up their own local copy, because I don't like trying to enforce lock-in, though I still think we should encourage convergence on a single server to provide the best experience for players by default.) I think afeder's suggestion was something a bit like C--.. ..--M | \ / C-----L-----M | / \ C--'' ''--M while the simple model with a single central lobby+matchmaking service is like C--.. | \ C-----L | / C--'' where C is a game client, L is the lobby server (controlled by WFG), M is a third-party matchmaking service. C<->C communication is what we do now (i.e. clients connecting to each other by IP address, using ENet, to run a match) and will remain basically the same. C<->L communication is largely the same in either model, but L<->M communication is new if we're supporting third-party matchmaking services (coordinated by a central lobby server). The C<->L API is relatively easy to implement robustly, since we know exactly what technology will be used on either end of the connection and can optimise the protocol for that, and it will probably be the same people implementing both ends so there's little danger of miscommunication. L<->M would be much more complex since (as I understand it) the whole purpose is that there are multiple independent implementations of M, so the protocol needs to be more technology-independent and much better documented and tested. So we need the C<->L API in any case, and my concern was just that implementing the additional L<->M API robustly would be hard.

That looks like the NVIDIA legacy driver (designed for ancient hardware); the most recent normal (non-legacy) release (290.10) says it still supports GeForce 6800 so you shouldn't need the legacy drivers. Are you able to test with that?

If I'm understanding correctly, I think the biggest problem is that you're proposing the game should support multiple independent matchmaking services, which will cause a fragmentation of the player community across the services. The value of a matchmaking service increases non-linearly with the number of players it can match between - 8 services with 1 player each would be useless (since nobody could find anyone to play with), and 1 service with 8 players would be much more useful. If some services are better than others, then it adds significant effort for players to learn about which is the best to use, and adds risk of them choosing a sub-optimal one. So I think the ideal situation is that there's only one matchmaking service and it's selected by default - anything else would make it worse for players. In terms of implementation complexity, building a robust API between a central lobby server and third-party matchmaking service would probably be harder than just building a single central lobby+matchmaking service, given the difficulty introduced when multiple parties have to coordinate. So my current inclination would be to focus on designing a good 'official' matchmaking system (I'm not sure what would count as "good" so I imagine we need lots of input and research), rather than trying to spread the work to unspecified other people, since it's probably easier and should give a better result.

No, just libxml2.

NVTT does DXTC/S3TC compression of textures at runtime. (We cache pre-compressed textures in releases, but support runtime compression for modders). We don't need any of its fancy features like CUDA support or image-loading tools, just the basic CPU-only compression library, so it should be buildable with no significant external dependencies (though its build system might need fixing). We can't use V8 (we rely on some complex API features so porting would be a huge amount of work). SpiderMonkey isn't API-compatible or behaviour-compatible across versions, so it'd be best to use the same 1.8.5 release as we use on PCs if possible; I think the standard releases are meant to work on ARM so that should be okay. We use a customised/bugfixed version of FCollada, so a port of the standard version of FCollada probably wouldn't work.

We used Google AdSense on the web site for a brief period many years ago, but complying with their requirements was a bit of a pain (I think they didn't allow ads on non-content pages of the forums) and the amount of money it made was about zero, so it wasn't worth the effort of continuing to use it. In-game ads would likely be much more complex to set up (both technically implementing it in the game, and also finding advertisers who'd agree to support it), and provide much less return (since far fewer people would be exposed to the ads) - I don't have any real numbers so I'm just guessing, but I'd be very surprised if the numbers could make it worthwhile.

Could you upload the content of the file ~/.config/0ad/logs/system_info.txt ? (That might show that e.g. it's using a software OpenGL renderer, which would inevitably make it very slow.)

Oops, it looks like I forgot some update for the OpenSUSE packages. I've updated the scripts now, and they should get recompiled within an hour from now - I can't test it myself so it'd be good to know whether the updated packages work for you or not

The most time-consuming problem would probably be porting all the rendering code to work with OpenGL ES - I don't think that would be particularly difficult, but it's quite a lot of code to change. (I think we could support GLES 2.0+ and desktop GL with mostly shared code (just with some fallbacks for fixed-function hardware) so it doesn't need to be a fork - we could incrementally modernise the main codebase to support GLES.) Apart from that, I guess the main technical difficulties would be getting the build system and third-party libraries to work properly in the new environment. I'd imagine the bigger problem is that a lot of the gameplay design is influenced by the mouse+keyboard UI system (e.g. we assume experienced players will use hotkeys, and we assume everyone can click precisely on small points on the screen, and we assume we can fill a 1024x768 screen with small text and players will be able to read it all), and those assumptions may not be valid on non-PC devices, so the gameplay design may work very poorly. It might make most sense to port the engine and then develop a new mobile-oriented gameplay mod (using the existing art and gameplay concepts but perhaps streamlining the game design in various ways), if someone wants to make a game that works well in that environment.

Yeah, you should only do "svn co" once. It looks like it might have aborted before fully completing - running "svn up" in the "0ad" directory should get it to download anything it missed. Also you really shouldn't be logged in as root when doing this . (Only the apt-get should be done as root.)

Oops, I got too focused on the ā́ and forgot to check everything else . Presumably the font just doesn't include glyphs for the ḗ/ṓ codepoints. I suppose the simplest consistent solution would be to use the combining-acute in all these cases in the XML files, and I ought to set up the charset-checking script to detect these problems automatically.

The game works with any version of libjpeg, so if you replace the "libjpeg8-dev" with "libjpeg62-dev" on the command line then it should work better (hopefully).

The simulation timestep is often something like 500msec, so there's likely to be a fairly huge gap between their quantised simulation position and their interpolated graphical position, so I'd guess it would be very noticeable. (I am just guessing, though; don't know how well it'd work in reality.) It is . Height is a purely graphical effect and has no effect on gameplay. (It's tricky with line-of-sight in particular - that's fairly performance-critical code when you have lots of moving units, and doing height-dependent computation is more expensive, so it would be nice not to make it worse than it currently is. Although I suppose it'd be fine performance-wise to do fancy computation for buildings (so you can e.g. build them on the edge of a cliff and see a long way) as long as units remain simple...)

I committed some support for saving games with AI players. Testing would be helpful - hopefully it will be able to save and load any game containing AI players without triggering any warnings/errors, and the AI will continue running after loading. (It won't run exactly the same as if you hadn't saved/loaded, though - effectively the AI is restarted from scratch after loading, as if it was starting a new game, so it will forget all of its plans. This also means it won't work when rejoining an in-progress multiplayer match that includes AI players - you'll get an out-of-sync error - but it should be okay in single-player.) Technical details: When saving, the engine calls .Serialize() on each AI script object. That method must return some object (consisting of plain (not class-based) objects, arrays, strings, numbers, etc) which will get stored in the saved game file. When loading, the engine constructs the AI script object like at the start of a game. Then it calls .Deserialize(data), passing it the object that was returned by the call to .Serialize(). Deserialize is responsible for resetting the AI script object based on that data. Currently BaseAI implements Serialize/Deserialize, so it remembers the important state like _rawEntities (things will break if we don't store that). If a particular AI script wanted to save its own state, instead of restarting from scratch after loading, I guess it might be reasonable for it to just reimplement Serialize to do whatever it fancies (including a BaseAI.prototype.Serialize.call(this) to let BaseAI deal with the _rawEntities stuff), though maybe we ought to extend the serializer so it can cope with more interesting data types instead of forcing you to convert everything into plain objects/arrays/strings/numbers if that's a pain. Hopefully the current state is good enough for the next alpha release, though

There's some old discussion in a (non-public) thread here (looks like posts #134 to #154 are relevant). (Edit: Oh, Jason beat me.) If I remember correctly, my main concern was that trying to do physically realistic projectiles (like aiming at a unit by predicting where it will be at the time when the projectile hits it) makes the gameplay behaviour impossible to predict. If it depends on the target's movement speed, and direction, and footprint size, and density of formation, and whether they're near the edge or center of the formation, and the distance from the attacker, and the attacker's accuracy stats (several numbers determining the shape of the distribution), and the projectile speed, and the number of turns per second, etc, and then playtesters say "Greek archers are overpowered against spearman", how can we tell what to change to make it better without introducing new balance problems? I think it would probably be better to start from a gameplay basis rather than a physics-simulation basis - have some simple rules like "basic archers hit their target 50% of the time at normal range, elite archers hit 75%; fall off to 25% (basic) / 50% (elite) at maximum range; increase to 75% / 90% for targets flagged as 'Large' (buildings, elephants, ships, etc)" or whatever. That makes it easy to understand what's going on, and easy to adjust the balance. Then implement something that matches the desired behaviour and looks visually alright, like how the current implementation computes the probability in advance and then either fires a heat-seeking missile that is guaranteed to hit its target or fires a dud that will miss and land randomly somewhere nearby. (The current implementation is too simplistic since it always has a probability of 50% and takes no other factors into account, so it certainly needs changing, but I'm not sure how radically it should change.)

The merit of a suggestion shouldn't depend on who is suggesting it, so that's okay . I think everyone agrees the current situation is unacceptable for OS X users and ought to be fixed (and I think it ought to be fixed to the same standard as our Windows and Linux builds, i.e. having the installer integrate properly with the OS and having the releases generated regularly and cleanly and repeatably by scripts rather than requiring manual input) - it just seems we're very slow at fixing it since few developers have access to OS X to develop on (and most of those only have VMs) and I'm not sure what we can do about that.

Debugging into JS code requires lots of internal knowledge of the JS engine (which tends to change incompatibly every few months), so I don't think any C++ IDE has any kind of support for that. The closest thing is some GDB extensions for printing JS values, but there's nothing that lets you automatically step between C++ and JS transparently. When I'm trying to debug C++/JS interaction, usually I just find what .js file contains the function being called (try asking on IRC if you need pointers for a particular case) and then put something like "warn(uneval(['someFunction', arg1, arg2]))" at the top of the function to make it dump the argument values whenever it's called, which is usually enough to help see what's going on. Or we could try to stop using 'for each', and replace it with "bar.forEach(function(foo) { ... })" (or sometimes "bar.forEach(function(foo) { ... }, this)" if you need to use the current 'this' inside the '...' - that's a bit irritating which is why I originally vaguely preferred 'for each').

Looks pretty neat, though how would you implement loading saved maps?

This data is from a while ago, from users who choose to enable the feedback mode (which is seemingly about half the people who download the game, though it's hard to tell, and could be biased towards certain OSes). That's showing 62% Linux (of which over 80% is Ubuntu), 38% Windows, 0% OS X.

Days 10 and 11 Experimented with implementing and optimising the aforementioned JPS algorithm and some related pathfinding things. These are on the 512x512-tile Peloponnese map, with a path (shown in blue) going north around the gulf. The coloured tiles are the ones processed by the A* algorithm (in particular the red ones are on the closed list, and yellow on the open list). In the first image, the standard A* algorithm searches outwards in a roughly circular pattern from the start point, so the red tiles go a long way south, until it gets to around Plataea and heads north-west to the target. The second image, with the JPS optimisation of A*, searches a similar area but it leaves a load of tiles unexplored (white) inside that area, because it realises they're never going to be interesting tiles (there's always an equally good path that doesn't use those tiles). (The chosen path is slightly different in the two cases, but of the same length. There are lots of equally good paths and JPS always prefers one that goes diagonally as early as possible before going vertically/horizontally.) In this particular example and this particular implementation (with various optimisations and hopefully no major bugs), the standard A* takes about 6msec to compute the path, and JPS takes about 1.5msec, so it's 4 times faster. Because our terrain tiles are quite large, and might mark a passage as blocked when actually a unit could easily fit through, it may be useful to use a higher-resolution version of the map: Here it's scaled to 2048x2048 cells (i.e. 16x as many as before), so it can represent much narrower gaps. Standard A* takes about 130msec (22x slower than with the low-res map); JPS takes about 11msec (7x slower than low-res). Bumping it up again to 4096x4096, standard A* takes about 680msec (another 5x slower), JPS about 22msec (another 2x slower). The nice thing about JPS in this situation is that it doesn't care too much about the number of tiles - what matters is the number of 'corners' (in some non-technical sense) that the map contains. That means it'll depend heavily on the number of trees in the map (since each tree adds four corners that paths can wrap around), but if the number of trees remains constant then higher-res maps won't be hugely more expensive. There's two problems with my current implementations of standard A* (simplified and optimised compared to what's currently in the game) and JPS. (Warning: getting somewhat more technical now). Firstly, they assume the target of the path is a single point. In practice it might be a large square (units want to get within e.g. 1 metre of a square building in order to attack it) or a very large circle (archers want to get between minimum and maximum range of a target unit). That makes it harder to tell when the algorithm has reached the goal, and harder (or at least more computationally expensive) to compute the heuristic distance to the target. Secondly, JPS doesn't behave usefully if the target is unreachable - the standard A* can discover whichever reachable tile is closest to the target but JPS might have never looked at that tile. Reachability is a problem with the game's current pathfinder already; units are happy to try forever to reach a target that they'll never be able to, and the pathfinder is very slow at determining the target is unreachable. I think the sensible solution would be to do something like the MM-Abstraction method to precompute a graph of connected regions, then find all regions connected to the source, and then find the closest tile to the target out of all the tiles in those reachable regions. That'll help equally for standard A* and JPS. For non-point targets, I think the easiest efficient solution may be to simply swap the source and target of the path. The source is always a single point (typically the unit that's moving), so it's easy to run A* towards that point. The target may be multiple tiles, but I think it's easy to make A* start with multiple cells (just shove them all onto the algorithm's open list with g=0 at the start). So finding paths from multiple target tiles towards the single source point should be straightforward, unless I'm getting confused as to how this all works. Then it needs to be integrated with the reachability thing for the previous problem, since the target shape might be half reachable and half not. That's probably all doable; just needs some more work to actually do it. The other big problem is how to make units follow the long-range paths while avoiding dynamic obstacles (e.g. other units), and also to not constrain units to moving along tile boundaries (which would look very unnatural). Currently that's the job of the short-range points-of-visibility pathfinder, which uses the detailed obstruction geometry (squares with arbitrary (non-tile-based) location and rotation). To fix discrepancies between long and short pathfinders, it would probably be better if it used the same high-res obstruction tile map that the long pathfinder uses, and then it can add on the dynamic unit obstructions (which can have non-tile-based positions but don't support rotation) to find a usable route, with the added benefit that it will now only have to deal with perfectly horizontal/vertical lines. Alternatively, maybe it would be simpler and/or faster to reuse the tile-based A* over a short range with the dynamic obstructions added onto it (perhaps at an even higher resolution). I don't really know about that - I suppose I need to experiment a bit more. (In any case, this won't get finished before the next alpha release, so I'll have to leave it until afterwards - that's kind of annoying but I think it's worth taking the time to solve the problem properly. Got a PhD viva next week so I won't be able to concentrate on game stuff until then, but I'll try cleaning up some of the quicker problems with saved games and other bugs.)

In case anyone here is interested in old RTS games, GOG.com has Empire Earth available for (legal) free download for the next couple of days (until 11:00 GMT on 14 December). (Also they've got a load of other stuff in their Christmas sale, mostly for $5 (e.g. Empire Earth 2 and 3) or $3 (e.g. Total Annihilation), all with nice easy-to-download DRM-free installers and manuals and soundtracks and everything else, which I think is very nice of them.)

NVTT is developed by NVIDIA but it doesn't require their graphics cards or drivers etc - it's just a standalone library that should work anywhere, so it shouldn't be a problem.

I'd do like this suggests, as in "Etc etc 0 A.D.? Etc etc 0 A.D.! Etc etc 0 A.D. Etc etc." (The space after the "0" is critical in any case )

I expect that computing from both ends doesn't reduce the total amount of work that's needed in common cases (and it definitely doesn't help in the worst case), and it adds significant complexity. Splitting a single pathfind requests across multiple cores is unnecessary (and adds complexity and inefficiency) - performance is only a problem when we have multiple simultaneous requests, and then we could do each one independently in parallel. They won't notice it compared to the current game's implementation, since only one (rarely-used) terrain type has a non-default cost, and units don't follow the long-range path precisely so they won't stick to the low-cost tiles anyway. So it won't be a regression compared to the current functionality, and I've not noticed that non-uniform-cost functionality in other RTS games, so I don't think it's a major problem for players They might notice if a unit walks e.g. two tiles west, two north, then two east, instead of just moving straight two north, which I think is possible with non-optimal algorithms like HPA*. That's probably a rare case, and there are probably ways to tweak the algorithm to avoid most such problems, so it should be okay in practice, though it's nicer if we can guarantee optimal paths instead of hacking around it. Yeah, the actual movement speed can still depend on terrain if we want to - the pathfinder just won't automatically try to avoid the slower terrain. Yep, I think HPA* works just as well as normal A* with non-uniform costs, as long as you're careful to include one transition for each differently-costed section of an entrance. (Performance will suffer a bit from the heuristic being less accurate, as with normal A*, but otherwise it should work correctly.) I don't think that's a huge problem - in the worst case we can just duplicate the pathfinder data structures for each combination of passability class and movement cost class. (We need passability classes anyway, to distinguish infantry and ships etc). Not great for RAM usage or cache utilisation or precomputation cost, but we could probably afford it if necessary. I don't think that would help for very large formations - we usually have too high a density of trees and valleys etc so the formations wouldn't be able to move anywhere at all, if we required formation-sized gaps. For small formations, we probably want them to be able to squeeze through single-unit-wide gaps so we'd have to use the normal unit-size-based pathfinder, and then maybe post-process the paths to nudge them away from obstructions when possible so they don't get squeezed except when unavoidable, or some kind of hack like that. For normal large units (siege, ships, etc), I think we should probably encode the size as part of the passability class. We already effectively compute a separate passability map per class, so we'd just need to expand obstructions by the class's size when rasterising to the passability map. Even if player buildings are locked to 45/90 degrees, we probably don't want to restrict player walls or scenario designers to those angles (since it would look a bit ugly), so the pathfinder needs to cope with rotated obstructions anyway. Imposing a minimum distance between buildings would probably be sensible for gameplay purposes to prevent people accidentally blocking in their own units (which has been a problem in the past), and would stop them constructing complex mazes that would potentially confuse the pathfinder, so I think it'd be good to do that some time.