historic_bruno

How about some way to see which players won and lost? It doesn't need to be text, AoK had some icons next to the player names (for winning players). Even though right now only one player can win, they can be on teams and have diplomacy. Also I've worked on a change to EndGameManager to allow team victories. So for the summary screen, it would require looping through player entities and checking if their state is "won" or not, and if so do something special. Not a big priority though.

Who's hosting the game? That person needs their firewall to have the rule added (as Feneur mentioned), but also if there's a router you'll need to port forward there as well. Some people like myself have firewall software and a router, so both need to allow this.

Make sure you've completely checked out the latest revision from SVN, and that you ran build/workspaces/update-workspaces.bat first, and then opened build/workspaces/vc2008/pyrogenesis.sln in VS.

Not sure, I'm not working on that

I can try that and see how it works, but that control seems buggy - if you switch pages enough or scroll around for a while it will lock up Atlas. Also the previews will need to be shrunk to fit in a decent size dialog box. On the other hand I can reuse the code that builds the preview bitmaps, so that's handy.

A couple of new things for Atlas. The new map generation has been integrated (roughly) into the UI. I'm trying to keep in mind various comments I've gotten on the layout of the random map controls. It's simple right now, a drop down to choose your map script (this may get replaced by a file chooser dialog or something), then a "Run" button to run the script, and then some seed value controls. Later there could be controls to override things like the base terrain and height of the script. Also it was suggested to allow arbitrary text as seed value, and then hash it somehow into a numeric seed - to make things more interesting. So the "generate empty map" button is gone now, replaced by a new menu item "New...", which brings up a new map dialog as follows: It has a very basic layout so far. Maybe the texture selector could be a list, allowing multiple texture selections, in case you wanted a map to start with several blended textures (randomly). The texture preview box isn't working yet, but eventually it will show the selected texture, so you're not picking blindly. It would be nice to have some shortcuts for handling maps like CTRL+N for new, CTRL+O for open, CTR+S for save. I've not looked into how that would be implemented.

New ticket for troubleshooting Spidermonkey JIT: #658: Troubleshoot Spidermonkey JIT

Tickets relevant to random map system: #6: Random Map Scripting #460: Random maps don't work since the new simulation system The RMS Interface document details an interesting API for RMSs. Maybe worth looking into. I think there should be a higher-level interface (compared to, for example, how the Cantabrian Highlands and Latium scripts work). It could use the concept of Biomes, to avoid needing to specify every texture or object that might appear in a given map. Potentially useful functions: createRiver() - create a river, perhaps from a starting point to an ending point, or following a certain function(s). I think the way water is implemented now, it is all at sea level. Thus the river would have to be level (i.e. not flowing down from a mountain). Maybe in the future, this is something that could change, to allow for waterfalls and more realistic environments. createMountain() - create a mountain range, maybe following two functions, one for position and one for height. createPathways() - Useful for guaranteeing there is a way to get from each player to the other. Could be an actual open path on a land map, or water connections on a water map. createForest() - create biome-specific forest of roughly a given size createLake() - create biome-specific small body of water, like it could be a swamp in some areas createBase() - create a player base, which uses starting structures and units for the given civ (can be specified in /civs/*.json)

Nice mockup! I especially like the "collapsible" option boxes, allowing a larger number of controls in the same amount of space. It reminds me of how some 3D modeling and image editing apps work. That would require a custom control though since it's not a standard part of wxWidgets. One of the things that annoyed me about AoK's scenario editor was that it was a pain to change settings for all the players, because you had to select each one individually. There could be an "All" tab on the player panel that allowed changes for all players at once, e.g. if you wanted to give large stockpiles of resources. Setting diplomacy is another tricky task, as clicking a lot of controls gets tiring, so it may be easiest to use the concept of teams. A game I used to play called Neverwinter Nights, though it was an RPG, had a concept called "factions" for the various NPCs in the game: basically how friendly or mean every group was to all the others. 100 might be a group you'd never attack, 0 you would always attack, and the interactions of the game altered the value. It might not map perfectly to a RTS game like 0 A.D. but it does add some granularity to the concept of diplomacy.

I've been playing around with the Atlas UI, adding controls for some of the settings we use when creating and editing maps. So I added a few to the "Map panel" and then there's a whole new "Player panel" now, which lets you pick settings per player. I guess mostly I'm just trying to get something basic in place, so that we no longer need to edit the map XMLs by hand. But if anyone has suggestions on what could be improved to make the UI more usable, that would be an interesting discussion. Map panel: Players panel:

Ran the same test scripts in FF 4 beta 6 using typed arrays, and it's lightning fast... under 4 seconds start to finish, and I validated the output so it's working fine. That's faster than rmgen, although it doesn't have to write any data to disk at the end. Guess that helps put to bed the question of whether JS is fast enough to do random map generation... Now to harness that power in 0 A.D

Ah, I didn't notice that critical little detail. So running the optimized code takes more like 22 seconds in FF 3.6 with FireBug disabled (JIT enabled) That does tell us that JIT is clearly not working for us in Spidermonkey... but it gives me hope that we can in fact write the whole map generator in JS I think this will be a necessary step, especially if we want to have some kind of integrated web-based editor. The more efficiently it can do this, the better, so it can scale to larger, more complex maps. Other RMSs may use multidimensional noise maps to construct terrain, along with clump placement, I'll be curious to see how they perform.

It occurred to me that since all the scripts are in JavaScript, why not use a web browser to profile them? Here's some profiling results using FireBug in FireFox 3.6.11 - so it's not identical to our Spidermonkey, but it's not far off performance-wise. I wanted to try Firefox 4.0, but FireBug won't install on it yet. mapgen_profile_firefox3.6.11.pdf The optimized version replaces some of the Math library functions with alternatives, instead of Math.floor() there's a hack which uses bitwise OR for typecasting a number to an integer. Judging by the fact that these optimizations cut the run time by about 40%, I'd say that's significant. It also looks like optimization is very poor because that's the sort of thing that should be in-lined (Imagine 25 million calls to a given library function, taking up almost 1/4 of the total time to generate the map!) Note: Since Firefox 3.x doesn't support typed arrays, I had to write a wrapper function which basically creates an untyped Array, all values set to 0. This raises an interesting point. In JavaScript the for...in statement can be used to iterate an array, skipping undefined values. For sparse data, it may be more efficient to create an untyped Array than a typed array, if we only need to iterate over the assigned values. This would require some logic modification, but it's one aspect of the language that may be useful.

I get an "Application not configured properly" error when I try to run that one. Which may be some sort of VS redistributable library issue, but I've got all thee DLLs installed on my computer and copied into the binaries/systems directory. I did finally get the one I built in VS2008 to work. Turns out it's a manifest problem, I guess it needs both VS 9.0 and 8.0 run time libraries to run the upgraded project, but the manifest only had 9.0 listed. Performance is good, it takes 6 seconds to run the Cantabrian highlands script, which includes generating the binary data and XML. Compare that with about 2 minutes to run the JavaScript version... Now I'm curious as to why there's such a disparity

Didn't notice any difference with JIT enabled I think that's worth looking in to, although for now the time it takes to return the data and for the engine to parse it is negligible compared to actually generating the map (using typed arrays or not, again seems to have little impact).

Hello, Matei If you don't mind, I'll ask some questions, but anyone else is welcome to jump in if they have some ideas. Is rmgen fast enough to generate a map, like Cantabrian Highlands in a matter of seconds - reasonable for use in the engine? (I can't get it to run on my system, maybe due to building with VC++ 2008). I'd like to know some details of "RangeOp" as it doesn't have any coments in the code, but I guess at least it has something to do with counting points within a certain distance of another point. The reason I ask about this is that I've used the "Cantabrian Highlands" script as a sort of baseline to see how JS can handle the random map generation. It's very slow, but especially parts that create areas, which rely most heavily on RangeOp (for tile class constraints). As an example, to create 3 small lakes on a 2 player map w/ 208 tile size, the inner loop of RangeOp.get() is called over 1 million times! That's a big deal in a JS implementation, moreso because RangeOp uses integer division, which doesn't exist in JavaScript, so every step is floating point and then has to be rounded down. Does 1 million ops sound consistent with the original design, or maybe I implemented something incorrectly in JS? Also, if I'm not mistaken, the tile class constraints are handled separately. So say we wanted to avoid player, hill, and water classes - to place a forest or something. That would mean 4 separate constraint checks (also avoiding forests) for every point in the area, and that for every forest we wanted to place. That gets complex in a hurry. What do you think of the feasibility of maintaining the tile classes in one data structure, which gets checked once for a given subset of tile classes? I'm not an expert on spatial data structures, but the following seems logical: 1. Get a "map" with subset of tile classes necessary for our constraints (this gets maintained as new areas are added) 2. Find open areas (i.e. where all constraints pass) which are big enough to fit our new area. Maybe they can be sorted by size, making this part fast? 3. Choose an open area at random (maybe the smallest?) and create new area somewhere within it's bounds. What I'm thinking is rather than these algorithms dealing with points, they should deal with "areas," which are arbitrary shapes, possibly approximated as rectangles or circles. We could adjust how "strict" to make the constraints, so maybe areas could overlap in some instances. I'd very much appreciate any advice you can give

Right, it's all passed to the engine as fairly simple JS data as described above. I thought this was more sensible than having to generate a PMP/XML first, because the MapReader already has all the logic for parsing maps anyway, so it's not too hard to get it to parse JS data too (I wrote a few FromJSVal overloads to handle things like an Entity struct and u16 vectors). The nice thing is the game setup hardly needed to be modified at all, because functions like "LoadMapSettings" don't really care where their data comes from as long as it's in the correct form. Instead of parsing JSON from an XML, it can use an entry from the game attributes. That was my concern, the loading screen does lock up, but in my test so far it goes very slow (see below). The MapGenerator class does use its own ScriptInterface, and it's the only part that evals the scripts Well so far, using the "Cantabrian Highlands" RMS as a baseline, it's really slow. Until we're certain of why, though, I wouldn't necessarily blame it on SpiderMonkey. Being able to do profiling would help. Also, it turns out typed arrays do work. I was trying to make a 2D typed array which is silly - the "outer" array has to be a standard Array always, the "inner" array is not a primitive type On the other hand, they don't test as valid arrays using the jsapi macros, so it doesn't work if I try to convert them to a vector As a temporary work-around I copy the typed arrays to standard Arrays before passing them back to the engine.

I've had a go at getting the random map system into a more usable state, including porting it over to Javascript. Any ideas on the shortcomings, bugs, etc, of the old rmgen can go here, as I've not had much experience with it. I'm sure the basic algorithms need work though. Right now I've modified the MapReader with some new methods for "Loading" a random map, which is basically like loading a scenario, except there's some extra data associated with it from game setup (map size, random seed, base terrain, etc) and of course a random map script (RMS). For now a new MapGenerator class is used to handle the details of loading JS libraries for all the necessary classes in their own context, executing the random map script, which then returns some data. This is not progressively loaded yet, so it may be that the RMS will need to be split into multiple functions, registered with the engine and then called piece by piece. The returned data is a list of entities, a list of textures, a heightmap, a list of tiles, an environment object, and a camera object (since it's not unforeseeable that an RMS may alter the environment and camera). The MapReader parses this data from JS into the respective C++ structures and inits everything just like it would for a scenario. The map format is the current version, not the older one used by rmgen. This much works perfectly. So the part that needs the most work IMO is an analysis of the algorithmic complexity of the generator, and some decisions on how high or low-level to make the RMS interface. Re: SpiderMonkey's typed arrays, I don't think the implementation is complete in our version because all I get is "undefined" when I access a typed array. Maybe the constructor API has changed or something.

Good job, can't wait to see something other than a large blank window when I leave the game Re: getting the colors to match with the game setup: once the setup patch is committed, then the player colors will be set from a single defaults file or as specified by a scenario. So, for the summary screen, you could probably just read the colors from the player entities and they will be identical. (This also leaves open interesting possibilities, like cooperative players having the same color, teams with matching colors, etc.)

OK, I added player color boxes (with a new sprite type for solid colors). Also chatting shows the user's name in their player color, but if they're not assigned yet, it will be black. I'm thinking maybe the host should have a different font or something to stand out if there's a lot of chat, but right now players don't actually know who the host is (since even the host is a client treated like all the others).

I agree, as long as it moves smoothly when transitioning height.

Here's a crazy idea, create a border around the player box with the player's color. That way it combines multiple related concepts into one control.

Shouldn't non-hosting players be able to choose their own player assignment (slot #, civ, team # if applicable)? Right now the host has to set everything. Of course if it's a scenario with predefined civ and teams, then those dropdowns would be disabled. At the risk of UI clutter, there could be an option like "lock settings" for the host, so only then can choose player assignments. A "Computer" player assignment should be added for when AI will take the spot. Edit: And while I'm on the subject of dropdowns being disabled, maybe the disabled state could be text with no dropdown visible. Would look less cluttered.

Oops, that's a bug. I think when going from random maps to scenarios it doesn't hide that control again As far the player colors being hard to read, I fully agree. Not decided on a way to address that yet. Maybe the player colors should be in the "assignment boxes" only - with the white background that is more legible. Thanks for the comments, it should be completed soon, once I make sure there are no major bugs introduced.

Ok, I decided to go ahead and implement icon tooltips Also made several other changes to bring civ info closer to Jeru's mockup. I found that you can in fact set sprite transparency, at least when it's a solid color (do this by specifying alpha level 0-255, the 4th element of the "backcolor" property), so disregard that comment. Making some more changes to game setup in general as mentioned here. See what you think: