historic_bruno

Mostly it was a test to see what's possible. We haven't really started working on campaigns yet, but if you open the Campaign Test Map scenarios, you'll see a few ideas

Also the image in the spoiler is not the latest model, or not showing off the latest waterfall enhancements.

It's a good start. Can the clients view the options as well or only the host? (The problem if only the host can see them is they have to tell the players what the settings are which is redundant) There's a ticket for this: http://trac.wildfiregames.com/ticket/812 - please a attach a patch there.

I'm not sure what a CSP technique is, but giving every object a thread sounds like a significant architectural change, which I wouldn't expect. I don't think there are major performance limitations in the current simulation architecture, except as Kieran says on the AI and pathfinding side which are currently more like rough prototypes and relatively easy to change (there has been significant discussion on both of these). Also it's true that they should work efficiently in a single thread first since we can't assume everyone has a multicore system, even if most users do, and threads complicate everything.

To add onto Kieran's comment about code formatting, you might also read our page on coding conventions, I corrected some unconventional formatting in the new sound manager patch when committing it. I think the biggest issues were mixing tabs and spaces, and having inconsistent spacing around parentheses. Switching the UI engine is extremely unlikely at this point. I haven't seen any more than words about it. For UI sounds, see http://trac.wildfiregames.com/ticket/948 - they should be a property of the UI XML so they are easy to customize. It's just a question of hooking up the UI engine events with the new sound manager (preferably UI sounds have their own "channel" so the user can easily mute them or adjust volume). We have some UI sounds in audio/interface, hopefully those are good enough for a start

What about having vines or something in the texture? Like one of the Roman buildings I recall has a vine on it. Or moss, everything is alive in tropical climates

Keep in mind that if you do edit Player.js, it will likely break multiplayer games unless the other players do the same thing Eventually this will become a match setup option: http://trac.wildfiregames.com/ticket/812

I'm sure people will be interested, but my enthusiasm for libRocket waned substantially when I discovered it doesn't use standard HTML/CSS

That seems to be the popular inference The same way a fantasy artist could draw amazing structures that never existed in reality, but look feasibly constructed of wood, stone, etc. To me the only difference is one form of art uses paper/canvas and the other is rock-cut caves. Very impressive rock-cut caves, I would consider them a great achievement of the Mauryans. It seems more probable that Mauryan architecture imitated the caves to some extent, not vice versa, and in practice they would be constrained by physics and architectural knowledge. The extant Mauryan structures that I've seen are much less grand than the cave art (I can't prove the reason for this, maybe they are simply lost to time)

Yeah, maybe if it was scaled down a bit. Now that I look at the reference images I do see a barrel roof like that, but different scale. I also agree on the roofs, as awesome as they look, it doesn't seem to match the ref images above. They seem to show un-roofed towers instead, with some distinctive stone arches around the edges (I guess for protecting the body of soldiers standing behind them, while allowing them to see over and possibly fire in between the arches?) Sorry I'm not good on all this terminology I'm referring to these pointy things on top of walls:

How would they have made that massive, bowing, arched roof? I mean that looks like it would be quite a challenge even today, let alone in the medieval period, much less BCE I'm all for buildings looking nice, but it seems there is a lot of exaggeration on the Mauryan architecture so far. Were they renowned for being the greatest architects of the ancient world or something?

Hi, if you would post crashlog.dmp from the logs directory, that will help. You can zip the crashlog to be able to attach and post it here on the forum. In fact while you're there, try zipping all the crashlogs and interestinglog.html as well. You might also try running Microsoft's free DebugView utility, which will let us see what the game is doing at startup. Run DebugView, then the game and after the crash has occurred, copy the contents of the DebugView log into a new post here

Why not start with the player positions defined, and use that as a constraint when generating the terrain? Otherwise you end up with situations where there may be no room to place a player, especially on smaller maps or when there's many players, and as you say the random(?) search for valid positions is time-consuming.

Hello and welcome!

Oops. Tutorial is updated now.

It's already there, just update

That's a good summary luziferius, and don't forget issues like deadlock which start to occur with multiple threads. The simulation will probably remain single threaded to avoid changing the architecture (again!), while things that influence the simulation state and are more naturally parallel may become threaded. Examples: pathfinding (one long path calculation isn't affected by another path calculation, so 100 units could conceivably perform 100 long path calculations in parallel - not sure about short paths), AIs (they might share some state but they make independent decisions and the simulation doesn't need to wait for the AI to send commands). UI is a bit trickier because it still has to be drawn to the video buffer which it would share with the renderer in another thread, not that it's impossible to solve that but we'd need a clear reason for it first. Short term it would be great to optimize the game assuming a single thread, unless someone out there can tackle both problems at once

In AOK, scores were displayed as an overlay with all players listed. Of course it would be listed in the summary. IMO it doesn't do much good to show only a single player's score, you won't know how you're doing relative to other players. What about units and buildings lost, should they be considered? For resources are you counting trade/gather/barter as one stat?

I think only Philip would be able to do anything about that. I haven't really noticed any problems so at least from my perspective it's not a high priority issue. You should try to catch Philip in IRC and discuss it with him. He hasn't been reading the forums in months.

Though I do like the idea of being able to place sound emitter objects in Atlas as an option, it kinda seems like a burden for scenario designers. Especially when so many maps share similar terrain. In AOK, weren't there terrain specific sounds or was it map specific? I remember at least an audible difference when viewing water vs. land. We could somehow add sound properties to terrains (we already have per-terrain pathfinder and material settings, so why not sound?). Then the sound manager would select which ambient sound to play based on camera position and visible terrain, while if the player zoomed out to see much of the map, it could fade to a generic wind sound.

That looks like a different problem. The training/construction complete sounds aren't related to selection. They are basically UI alerts for the player who owns them, I think LOS or on-screenness shouldn't have any effect. It might help to classify the possible sounds in some kind of chart: Sound | Player | Allies | Enemies | Camera relative? -------------------------------------------------------------------------------------------------------------------- Generic UI sounds X No UI alert X No (construction/training/research finished, attack alert) Unit command response X No ("yes?", "attack!", etc.) Unit selection X ? ? No Building selection X ? ? No Action sounds X X X Yes. Visible onscreen only, use position and zoom (gathering/battle/dying/moving) Player-specific music X No Ambient sounds X X X Depends - in the simple case it would be global, (birds, wind) in the advanced case we could have ambient emitters so different parts of the map have different ambience (desert, ocean, forest - all sound different) What if there was a generic "clink" sound? Similar to how we want UI buttons to make sounds when pressed. It would be nice to keep the building sounds for the owner only, then it becomes a useful indicator of when a building is constructed (whereas if that sound occurs all the time, it's less useful)

How about making it so that players only hear UI sounds related to their own units Also I would like a way to control voice and/or UI volume independently of the other volume controls, I don't see a way to do that yet. Music shouldn't cut off abruptly when a game starts, and it shouldn't continue playing in Atlas after the simulation ends (ambient sounds do the same thing IIRC). Music shouldn't just loop forever IMO, periods of silence are not a bad thing. Most of the music code should be stripped out of the UI scripts. Adding sounds to the UI would be nice (button presses, etc.) Double click selection of units plays multiple voice responses in succession. Battles sound terrible with all the repetitive death grunts. There's a few ideas for you, but the biggest problem is sounds not respecting the camera position/zoom. With the new shared ally LOS, I can hear units dying on the opposite side of the map.

Why not look at our existing models and use them as a guide?

It raises a good point though. Is it going to be necessary to contact CGTextures every time someone wants to confirm this agreement? What if they go out of business or suddenly change their mind? Why don't we have this somewhere in writing? The other example is the wolf textures for those Roman units. Someone on the team saying it's "OK" isn't very strong evidence when the law is involved.

Making a realistic random map is extremely difficult