Ykkrosh

Hmm, that's a good point. We'd probably have to limit the closeness of buildings anyway because of their terrain-flattening behaviour - it's not good if a new building change the terrain underneath an older building, so we'd probably want to guarantee at least one free tile between them (which means a distance of sqrt(2) tiles apart in case they're going diagonally). That's probably enough space for any individual unit to fit through. As long as the tile-based pathfinder underestimates the size of buildings (i.e. it considers partially-obstructed tiles to be passable) it should find the gaps between them, and as long as the buildings are far enough apart then that gap really will be large enough for the unit to fit, so units won't get unexpectedly stuck. (Just got to be careful not to underestimate the size of e.g. thin walls so much that they effectively disappear.)That doesn't prevent the spacing problems entirely (there's still buildings placed by scenario designers, and trees and rocks and all sorts of other things that mean the tile-based approximation will never be perfect), but it should make it less common in normal play when you're telling units to walk through a player-built town. Once the fundamentals are in place I expect we'll need a lot of heuristic tweaks like this to make certain cases work more intuitively for players, so it'll need a lot of user testing

That's the 'arch = "amd64"' problem from before - why did it work in your previous post (until it reached the nasm problem), but not any more? Maybe the HOSTTYPE thing doesn't work and you still need to patch premake.lua as before, if you reverted that patch?

Looked briefly at Warzone 2100 too; buildings are locked to tiles (no rotation or arbitrary placement), units all do acceleration/steering etc and try to steer their way smoothly between waypoints. Roughly the same as Spring. (Also it has 12,000-line source code files - I think I prefer 0 A.D.'s rather more modular approach...) I've currently got an implementation of the AoM-style system that appears to mostly work now - you can make units move to a point (vaguely avoiding walking through other moving units), move to a target (units spread around the edges of the target when attacking/repairing/gathering), move to inside a maximum range from a target (for ranged attackers), move to outside a minimum range (for ranged attackers who are too close, or for telling units to get away from construction sites or volcanoes etc). Still quite a few missing features (impassable terrain, group/formation movement, etc) and probably a number of bugs, but I think it's almost ready to commit and start testing properly. That's true, but I think that only becomes a danger when the tile-based long-distance pathfinder thinks there's space there and so the unit runs up to that point and then gets stuck because it can't quite fit. As long as the two pathfinders generally agree then the game should be self-consistent and hopefully nobody will notice Yeah, currently I have it so that both units stop and try to find a new path simultaneously. That doesn't work well when one unit comes from the east and one from the west, and they collide and both decide to head around the north of the other unit, so they both move north and hit each other again, then both decide to head around the south of the other unit, and repeat many times. I guess simply telling one unit (based on some arbitrary priority) to wait for ~1 second before computing a new path would help with that. Don't know. It wouldn't be nice if units appeared to have perfect information about the world while the player could see very little of it; but recomputing paths every time visibility changes is inefficient. I guess it needs some balance between using imperfect information and recomputing paths when the information has got sufficiently better to make it worthwhile. Maybe the new short-range pathfinder should use perfect information (its range is currently limited to a distance of 12 tiles around the unit so most of that should be visible anyway), and the long-range tile-based one should treat shrouded areas as passable but expensive (so it'll prefer to avoid them) and recompute the path every ~32 tiles or whenever it gets stuck, or something like that. Currently it keeps the old long-range path, and recomputes a new short-range path to the next waypoint (avoiding the new obstable). I don't think that's great, though - it might get stuck weirdly if e.g. someone builds a long wall in its path. Need to make the code more robust when paths become invalid or the unit gets stuck, without allowing one unit to eat up an unfair amount of CPU time, but I'm not sure how to do that properly - it'll probably needs lot of testing and tweaking.

You're far too much of an optimist . Fiction has taught me that all people in post-apocalyptic worlds fight each other (or become postmen).But it also seems optimistic to have continent-sized superpowers in a world where modern communication methods and long-distance travel and existing militaries and governments have presumably all been destroyed by global war - it would be impossible to get people to cooperate on that scale, and there's no clear reason why they would want to cooperate anyway. What brings each faction together? Geography? Economics? Ideology? Fear/respect of some leader? Fluoride in the water supply? It'd be nice if there was some fundamental reason for each faction to exist, which differentiates them from the others and leads to their own particular style of warfare - that would help make each faction be a meaningful entity that players could understand and care about, rather than just an arbitrary name attached to a collection of gameplay stats. I expect it would take days or weeks at most to add some kind of reasonable air unit support into the engine, so that wouldn't be a problem compared to the years of work needed to create all the art and balance all the gameplay for a mod like this

That edge case is a theoretical issue, but I don't think it will be a gameplay problem - a unit of width 'w' will be able to walk between two parallel buildings (regardless of orientation) that are a distance w apart, and can only walk between those opposing corners if they're sqrt(2)*w apart, but that's okay because units are quite small so it's not much difference. Just build the buildings further apart if you want your units to get through, or further apart if you want to keep the enemy out I think optimising the collision outline seems likely to be complex and a bit slow (unless there's some simple clever method I'm unaware of). There aren't many buildings and the biggest problem is units (since there can be a huge number in a small space), but units keep moving so you can't easily precompute anything. In typical cases the A* algorithm will quickly find the goal and doesn't have to bother constructing much of the visibility graph (it doesn't compute the edges for a given node until the A* has decided to look at that node), so any extra up-front computation is likely to slow down those cases. The worst case is when the goal is unreachable (since it has to examine the entire visibility graph to determine that), so I think the most important optimisation is avoiding that case: if the goal is inside a building/unit then pick a new goal that's outside and more likely to be reachable, etc. That seems quite messy - you could try to pick the nearest point that's on the obstruction's collision outline, but if that's obstructed by another object then you're a bit stuck, and I can't think of a better way to recover than spiralling outwards from the goal until finding an unobstructed location and hoping the player didn't fill the entire map with buildings so there's no free space anywhere. I guess I should focus on simply making it work first, and then it'd be good to look more at optimisations

In a game design with that much focus on ports, presumably it also needs a lot of focus on ship movement and combat - it's not good when ships act exactly like floating infantry, with instant turning and no momentum etc. How do you envision them working (in an ideal world where implementation complexity is not a concern)?

Are you using the pre-alpha release version of the game? If so, that's a known problem (#484) - you could try getting the latest version from SVN, as described here (just download the code, ignore all the stuff about building and Visual C++ etc) and run its binaries/system/pyrogenesis.exe. It'd be great if you could let us know whether that fixes the problem or not

Actually the octagonal outline is just complicating things for no good reason - nobody's going to notice if they're kept as squares. So I've got some code now that does this - white is the tile-based pathfinder, dark blue is the collision outline of units/buildings, cyan is the outlines expanded by the radius of the current unit (i.e. the closest that the unit's centre can get to the objects), the green lines are connecting each vertex to every reachable vertex, and red is the shortest path to the destination using those lines. The code's very hacked-together and inefficient and missing important features but it still looks like it actually works quite nicely when it's integrated with the tile-based pathfinder. (The tile-based pathfinder is also very hacked-together etc but it can be replaced independently of this new code). So I'm continuing to think that copying AoM is good

Oops, I probably need to run the autobuilder again. Should be uploaded within about half an hour. (If you look at the in-game console then it should have a lot of error messages indicating the problem - I changed the entity XML format a bit, so the old version of the engine thinks they're invalid and rejects them.)

Yeah, a lot like that, though the collision outline is more like this for rotated obstacles. It won't work if there's many dozens of obstacles, since there'd be a huge number of potential edges to check, but hopefully it should be okay if it's only over a distance of a few tiles. The normal tiled-based A* pathfinder would still be used for long distances - this is just for avoiding collisions while following the path's waypoints. AoM's approach seems to be to ignore moving units in all of this, and then just stop if there's ever a collision and resolve it somehow (one unit can have a higher priority and try to move around the other), which may be fine for us. We don't have worker units running backwards and forwards between resource supplies and collection buildings (they just stay at the resource) so there's less need for more complex cooperative avoidance.

Continuing my general rambling and checking briefly for other implementations to potentially copy: Glest/GAE looks like it just forces units to stick to tile centers (movement between tiles is purely graphical interpolation), which is not good for smooth movement or for non-axis-aligned formations. Buildings are snapped to tiles and have tile-based footprints and can't rotate. Spring snaps buildings to tiles and doesn't allow rotation and has square tile-based footprints. Units have slow acceleration and slow turning etc, so ground units all do roughly vehicle-type steering. They seem to pathfind around buildings and just steer to try to avoid hitting other units. It seems very unreliable - they keep sliding around buildings and hitting each other and randomly running off in the wrong direction if they can't quite reach the target. ORTS makes my computer's video output freeze so I have to reboot. Looks like units/buildings can have arbitrary positions, and are either circles or axis-aligned squares or arbitrary lines. Don't know how the movement actually works (it's designed as a extensible framework so it's hard to find the code that will actually run). Since this is now the 21st century, I think we really want rotatable square buildings (like in AoM) so that the game doesn't look blatantly tile-based. So none of these games are helpful here, since they have different constraints and don't seem to do anything very fancy.

Thinking a bit more about implementation: Squares seem a good idea. If everything is squares, and if a unit doesn't rotate its square as it moves, it's straightforward to produce a list of waypoints for the unit to navigate through a collection of obstructions. Treat the unit as a point, and expand each obstruction square outwards by the size of the unit's square in order to get shapes representing the closest the unit point can get to the obstruction. If the obstruction and unit have the same alignment, the expanded shape is a square; otherwise it's an octagon. Treat impassable terrain tiles like any other square obstruction. Now you've got a load of vertexes and a load of impassable edges. Add the start and end points as vertexes. Connect every vertex to every other vertex by a straight line, if that line doesn't cross an impassable edge. Now you've got a graph of lines that the unit can safely travel along, so you just do A* over the graph to find a path from the start vertex to the end vertex, and the unit can follow that path precisely. I think the worst-case cost is O(n^3) in the number of shapes, which is probably okay over very short distances (which is all this should be used for). Circles break this because you can't convert them to a list of vertexes. Rotating square units break this because the set of vertexes becomes invalid each time the unit turns. Non-rotating squares seem like they should work gameplay-wise for most units, though they'll be a bit rubbish for ships. Does anyone happen to know other ways of solving the problem of having units navigate busy environments (with lots of buildings and other moving units) over short distances? I've seen loads of articles about pathfinding but basically nothing about this aspect of RTS unit movement . I'll keep looking, but it'd nice to have a roughly decent implementation in the game soon so that units can walk near other units and attack without it all breaking.

I was looking at AoM for some ideas about unit movement, and this post is an attempt to briefly describe what it's doing technically. I'm ignoring some edge cases and probably making various mistakes and invalid assumptions, but I think this is the general idea of what it implements. There's some useful settings you can put in a config file, to help understand the internal behaviour: showPaths 1 renderPathingQuad 1 renderObstructionManager 1 renderUnitGroups 1 The collision shape of a unit is an axis-aligned square. The largest looks like exactly one tile, the smallest normal unit is half a tile width (things like arrows are smaller), some are somewhere in between. Buildings are non-axis-aligned rectangles. There's four different colours of obstruction: buildings, static units, moving units, non-obstructing units (flying units, arrows, corpses, etc). There's an adaptive quadtree type of thing, initially with 8x8-tile regions, subdividing down to 1x1-tile regions depending on the presence of buildings and terrain. For each region, each edge can be marked as impassable. There's two main levels of pathfinding. The first level seemingly uses that quadtree to compute long-distance paths, i.e. based on just terrain and sufficiently obstructive buildings. (A single building is usually not enough to split a region and make an edge impassable, so it gets ignored here, but cities and walls typically have an effect). That gets converted into a series of waypoints, at most 8 tiles apart but sometimes closer, though it seemingly uses more terrain detail to compute the waypoint positions. That path is kept and never recomputed. The second level computes a path towards a future waypoint from the first path, keeping about 10 tiles ahead of the unit. That new path takes account of the exact shapes of buildings and static units (not moving units), and computes a series of waypoints around them. It recomputes every so often, to smooth out the path and to stop the unit getting stuck if some units move into its way. It's exact (based on the unit/building squares), not tile-based. Movement then consists of travelling in a straight line towards the next second-level waypoint. If it's blocked by moving units, then one of the units seems to stop for a fraction of a second and the other tries recomputing a new path. When you tell a (non-widely-separated) group of units to move, the game does a single pathfinding operation (the same as for moving an individual unit). It also picks a desired formation for the units (e.g. a 4x2 grid with some spacing between points). A single group proxy object moves along the path, and all the units attempt to move in a straight line to their position in the formation relative to that moving proxy object. They speed up a bit if they're lagging behind. When a unit can't find any way to reach its next waypoint, it gives up and stops.

Uploaded an updated version with examples for the datatypes, and with the grammar disabled by default (toggled by a checkbox, unless you're using a stupid buggy browser like Safari or Chrome which don't handle dynamic updates with the '#show-grammar:checked ~ * div.grammar-box' CSS selector).

I thought this was only supposedly needed for Win2K/XP, since Vista/7 have HPET support built in? Seems much safer and easier to just disable the driver entirely on non-XP.

It doesn't need to be fooled, it just needs to be coded . Various units will already have to have different views of terrain passability (some only like water, some only like land, some might cope with shallow water, etc), so it wouldn't be that hard to have the bridge tiles be considered passable to both ships and land units (and then cheat (e.g. with this teleportation) so that the ships don't jump up onto the top of the bridge when passing it, or get meleed by infantry standing above them, etc).

I could just get rid of the Grammar section entirely, because the other descriptions ought to be sufficient for anyone who wants to edit the files. (People who want the explicit grammar for other purposes can get it from the source code). Mostly it's there so that I can see bugs in the conversion script, which is hopefully only a temporary need For the data types, maybe a couple of examples each time would be helpful, and would be easier for readers than checking back to the top of the page each time they forget? so it could say "integer (e.g. -5, 5)", "positive integer (e.g. 1, 5)", "non-negative decimal (e.g. 0.0, 0.5)", etc.

I've committed a change to tell nasm to use the macho64 output format - if you update and run update-workspaces.sh and rebuild, does it work better now?

The game's various unit types are defined in XML files like this. It seems useful to have documentation for the file format, so that people can understand what it all means. With the old simulation system we have documentation on the wiki that describes the syntax and the higher-level design, which is good. But one danger is it becomes incomplete and inaccurate, e.g. the armour syntax there doesn't match what's actually used in the old entity template files. So what I'm trying to do with the new simulation system is have the syntax definition embedded in the source code, so that it's easy to keep in sync with the code and so it can be used for automatic error-checking of the entity XML files too. The XML validation part is already implemented and running, and now I'm trying to generate human-readable syntax documentation. I have a conversion tool that half works now (using XSLT on the RNG schema to generate HTML), and I'd like to check with people if the output is generally sensible and whether there are changes that would make it more understandable, more informative, prettier, etc. The current output is here - lots of components are missing text, but Armour and Attack and Health and Position are mostly complete. I don't want to do anything extremely complex here but I'd be happy to make some changes to help people who'll have to read this and use it to edit the entity XML files. Any thoughts?

See the file binaries/data/config/default.cfg, which says how to create a local.cfg, which can contain windowed = false xres = 1024 yres = 768etc to make it run in fullscreen.

That's not true - you suggested the possibility of making one earlier today, and I think it's be something that WFG people might be interested in discussing if there's a detailed design or prototype of a game derived from parts of 0 A.D., but currently there's nothing official or definite at all.We released the game as open source partly because we want other people to benefit from reusing the content for whatever purposes they want - the world is a big place and it's fine for the content to be used in several different games. So I'm happy for anybody to make as much use of it as they want

I assume you didn't compile it yourself so you need to wait for the autobuilder, which finished 7 minutes ago

Committed a version now. Various minor things are missing but it should basically work.

Hmm, sounds like it's possibly a system configuration problem - Boost wants to know the locale so it can handle filesystem paths properly, but the C++ locale stuff doesn't like your locale. It may be this problem (add the LANG you use to /var/lib/locales/supported.d/local, run sudo dpkg-reconfigure locales). I think we can't really avoid the locale issues (it's necessary for loading paths as Unicode) so perhaps we should just warn when there's a problem. See #495.

Hi, it's great to see your interest . I've been making major changes to the gameplay system recently, so that's still an area that needs lots of work (I think it's the most useful thing to focus on now) but there isn't a stable overview of what's needed - probably the most relevant is this page which covers the features we likely want to have. There's a few specific tasks listed here and some others in the general Trac ticket list. Someone (silnarm) has worked on a pathfinder for Glest and has apparently been looking at integrating it here, but I don't know what the current status of that is; I don't think anything else is being actively worked on, except for whatever I'm doing.