historic_bruno

Random thought: There may be some value in hotloading maps and civs, which is not currently done (Now you have to reload game setup or civ info dialog in order to see changes).

Thanks for the responses. The icons can be removed for now, indeed they are not implemented yet, only for mockup purposes. I was lacking some graphics, like several transparent sprites for the background, so I didn't make it look as close to Jeru's mockup as I would like. And I wasn't sure I wanted to make those in the first place. It raises the question of whether there should be a different sprite for each level of transparency, or a way to control transparency for a single sprite. Just an idea. If transparency property could be added it would save clutter and data size, vs. having to upload many different sprites to achieve similar effects: <object type="image" sprite="bkTranslucent" size="0 0 100% 39" transparency="50%">

Here's a new ticket which encapsulates the above changes (across a number of other tickets) #590: Game setup / civ selection improvements

When a sound is created, there is an option to load it's gain and pathname from a txt file. This doesn't seem like a very robust solution, as it may be desired to change the gains of multiple sounds at once, but in that case you'd have to find each txt file and edit them separately. Not to mention if you made a typo in the patthname... One solution is to use tags in the sound file. If Ogg supports custom tags then it should be possible to add some kind of "gain" tag to it, which gets read when the sound is opened. There are tag editors out there which should allow mass editing of tag data. Or we can specify the sound properties in one centralized location. Perhaps when the sound manager is initialized it can open an XML and read the properties from there into a data structure that is used for this purpose. Or maybe the sound manager itself shouldn't be responsible for that.

Awesome, I had completely overlooked icons. That's one piece of the puzzle I like the idea of tooltips for icons, if it's not too complex to implement. The reason is they can (optionally) tell the user what an icon means, which is typical in GUIs. Good example: a help screen which references icons from the game in the text. Possible solution is to add a child object for each icon in the text box, with properties that it has the identical size and position of the rendered icon. Also a unique ID would need to be associated with each icon instance. If the icon object were placed "in front" of the textbox, it would be the mouse_over object (for that event). The event handler would need to pass the icon's ID to the script callback function (may or may not be implemented). That would allow arbitrary handling of the event. We would have to make sure to clean up those objects properly when the textbox is updated, as the icons could change or even disappear. I guess that's a lot of overhead, but then icons shouldn't appear in text boxes too often. I haven't been familiar with the GUI engine for very long, so maybe there are good reasons why that wouldn't work.

Any thoughts on dynamic GUI controls? It looks like the GUI manager is static now, meaning it loads all controls from XML. Which is fine most of the time, and it may work all the time. But I'm trying to think of ways to have controls that change number and position based on game data. For example, it would be nice to have a tooltip button next to each entry for civilization info (see above screenshot or Jeru's mockup). The content changes from one civ to the next. That presents it's own challenge in trying to find absolute coordinates of the displayed text. I guess I could pre-define the maximum number of such buttons needed (which constrains the amount of e.g. techs and heroes available for mods), and then hide the ones I don't use. It just seems like not the optimal solution. What about a special character sequence that could be inserted in text and creates a button? Kinda like how the tag works now. // Example of dynamic button techCaption = "Othismos " + '[button name="techToolTip1" sprite="infoSprite" sprite_over="infoSpriteOver" size="0 0 100% 100%" tooltip="The classical phalanx formation was developed about VIII century BC...." /]'; Possible / impossible?

Civ selection and info are working now. It's not the most exciting thing to look at, but the thought that all that info can be changed by editing one XML document - is pretty cool. In fact it is a copy and paste job to add new civs. It's all specified in JSON. It could be livened up by maps, timelines, and GUI themes for each civ (also specified in JSON of course). Screenshot:

#7: Diplomacy - Whatever diplomacy variables were added have likely been lost by now. - Can be supported by adding a "diplomacy" array to each player's data. Numerically, -1 could be enemy, 0 could be neutral/undefined, and 1 friend. Or strings could be used just as easily. - Requires GUI controls and modification of player class (...simulation/components/Player.js), and of course the game logic to use it

OK, it took me a while but I've got player data fully loaded from setup. The best part is: it's all initialized by simulator scripts I'll test some more things and make sure there's no other traces of engine code that modify player data. At first glance it looks good. The ease of manipulating JSON data in scripts makes me think much or all of the civ data should also be in JSON. Inside an XML document seems to work well for those things that *might* be engine specific (since we have a quite capable XML parser). I'll write one up and see how it looks. Agreed. Anything that is likely to be set each game should be in plain view, while less common options could certainly be in an "advanced" panel.

That actually make things much easier. I was wondering how to load the JSON data into C++ data structures which gets ugly fairly quickly. There's just traces of code that look important but don't serve a purpose anymore. If you look at how things are implemented, map settings are stored as JSON data in the simulator but only used to read and write maps. Instead all the game data could be in scripts. An XML -> JSON converter would do the trick. And I wonder if there's a reason for the player data to be defined in JSON... why not all XML? Thanks for the clarification. Factions is a much better word for them than locales

Update: teams and player colors shown in setup, player civ is text-only in a scenario (dropdown otherwise) The "?" button at the top, next to Civilization opens up the "Civilization Info" box, which is something like Jeru's mockup only I've got no data for it yet and it's lacking the nice images. Using formatted text, it should be possible to get something close to the mockup, only I've no idea how tooltips or info boxes could be added dynamically for civ bonuses, heroes, etc. But I like that idea. If there's not already there should be a simple way for a script to set multiple properties of a GUI control at the same time, in an array or something.

Hi, this topic is covered on the wiki only for C++, and it looks like some of the conventions have been carried over to JS. For example if you look at /gui/gamesetup/gamesetup.js, you'll see all the global variables begin with 'g_'. Maybe input.js predates those conventions and simply hasn't been refactored...

I noticed this too after thinking about it. Some simplifications will break existing scenarios, but since it's still alpha this shouldn't be a great concern. I'll just update the scenarios I have to be compatible. My thoughts exactly. I'm working on a structure for the civ XML, using comments here and info from the design document. I noticed there are sometimes multiple "child" civs for a single parent: the Poleis and Macedonians both under the Hellenes. For this I created the concept of Locales, which are added to their parent civ, and contain specific heroes, technologies, and anything else that could vary by location in the context of a civ. Eventually there will need to be a standard way of referring to all the gritty details of a civ (special behaviors and units) in a programmatic fashion, I'm not sure that this XML is the correct place to address those details so I've left them in plain English if at all. Maybe that's better suited to the concept of "technologies." Below is an example XML for the Hellenic civilization, with extraneous data removed: <Civilization> <InternalName>hele</InternalName> <DisplayName>Hellenes</DisplayName> <Emblem image="hele.dds"/> <History> <TimeLine/> <Text> The Hellenes were a people famous for their architecture, fighting ability, and culture... </Text> </History> <Locales> <Locale> <Name>Poleis</Name> <Description>Greek city-states</Description> <SpecialTechnologies> <Technology> <Name>Othismos</Name> <History> ... </History> <Effect>The player gains the ability to order his troops into a PHALANX formation, providing +30% Attack and +30% Pierce Armour if attacked from the front.</Effect> </Technology> ... </SpecialTechnologies> <Heroes> <Hero> <Name>Themistokles</Name> <Class/> <Armament/> <Emblem/> <History> ... </History> </Hero> ... </Heroes> </Locale> ... </Locales> <CivBonuses> <CivBonus> <Name>Oikoumene</Name> <History> ... </History> <Effect>10-15% cheaper technologies.</Effect> </CivBonus> ... </CivBonuses> <TeamBonuses> <TeamBonus> <Name>Oracle at Delphi</Name> <History> ... </History> <Effect>All units and allied units have increased LOS. ~ 10%</Effect> </TeamBonus> </TeamBonuses> <SpecialStructures> <Structure> <Name>Theatron</Name> <Class/> <Emblem/> <History> ... </History> <Requirements/> <Phase/> <Special/> </Structure> ... </SpecialStructures> </Civilization>

Parts of the engine relevant to player data: * Atlas - will need GUI controls for player setup: number of players, names, civs, starting resources, etc. Then properly write these to map XML. * MapReader - will need to load player data from the map XML and parse into entities. also loads summary of map data for setup purposes * PlayerManager - maintains list of player entities * ScriptFunctions - interface for GUI scripts to interact with engine, ie. loading map data * GameSetup - besides GUI changes, will need to properly load map data Parts of the engine relevant to civ data: * Atlas - needs to read civ data for display, possibly to select available units? * CivReader - needed to parse civ XMLs, could be modeled on MapReader? probably belongs in simulation layer * ScriptFunctions - provide interface for loading civ data? * GameSetup - needs to read list of civs from file structure(?), show civ info * CivInfo - parse civ data, and display formatted info on GUI

The detailed civilization info absolutely needs to be in its own dialog, something like the mockup Jeru posted here. In AoK, this data is presented as a technology tree with brief history. There could be a "?" button next to the civ dropdowns, which instantly jumps to the corresponding info dialog? Or something a bit less minimalistic. How about a repository for civ data in /mods/public/civs? The XMLs could go there. Another ticket: #91: Player editor for Atlas - This would modify the map XML to include something like the PlayerData element shown above.

Some open tickets related to this topic: #1: Player Properties #316: GUI - Civ Selection Dialog #527: Display correct player names I didn't see #316 before, any progress on this? The related thread hasn't been updated in a year. Some interesting ideas there, but no patches or scripts yet... I'll assume since the SVN has none of those changes at all (see my screenshot) that progress on that has stalled somewhat. Some related thoughts. 1. There's at least 4 cases of game setup: multiplayer(networked) scenario, single player scenario, multiplayer random, single player random. The code for these is currently in a single script, which is getting ugly as logic is added to handle each of the above cases. For example in random mode a GUI object might mean something different from the same object in scenario mode, while in multiplayer mode there is a need to keep players synced as settings change, but this is not the case in single player mode. My instinct is telling me that some code shared among all game setup cases should be in one script, and then case specific code should be in other scripts. This could facilitate the future addition of other setup cases, whatever those might be. At any rate it may make it easier to read and write code. 2. It's not clear to me yet, how civilizations are implemented. Obviously there are art, technologies, game data, and rule sets which all have to be unified around this concept of a civilization. In keeping with the modular and generic nature of the underlying engine, I guess scripts will be responsible for tying this together. Where can a script, for example game setup, find a list of available civs? For loading maps, it reads a directory for all files matching a given extension. Maybe the same could be done for civs, if I find the "primary" location for that data. Perhaps an XML for each civ, with properties such as internal name, display name, history, and whatever other data could be useful for GUI display. 3. GUI controls really need to be more informative to the user. The state should always be apparent, if it's disabled, it should look disabled. If an item is selected, it should instantly be clear what is selected and what is not. I'm thinking that I saw a ticket for this, but now I can't find it 4. Maps and really any modular data should be checked before use, to verify they are compatible and at least syntactically correct. If you make a syntax error in your script while the game is running, it can potentially lock up the game (this has happened to me). While it's nice to see changes appear instantly, it needs to be safe

I've had a go at this, and here's what I've come up with. For the scenario XML files, I've inserted player data into the ScriptSettings element as follows: Revised: 10-25-2010 ... <scriptSettings><![CDATA[ { "Name":"Scenario name goes here (optional)", "Description":"Scenario description goes here (optional)", "Keywords":["keyword_1", "keyword_2", "keyword_n"] (optional), "PlayerData": [ { "Name":"Player name (optional)", "Civ":"hele/celt/iber/pers/cart/rome (optional)", "Colour": { "r": 0-255, "g": 0-255, "b": 0-255} (optional), "PopulationLimit": 0 (optional), "Resources": {"food": 1000, "wood": 1000, "metal": 500, "stone": 1000} (optional), "Team": -1 for no team or 0-4 (optional), "Diplomacy": [] array of diplomatic stances between players (optional), "Phase": starting phase (optional - not implemented?) } ... ], "GameType":"endless/conquest (optional)", "RevealMap":true/false (optional), "LockTeams":true/false (optional - not implemented yet), "DefaultStance":"holdfire (optional)" } ]]></ScriptSettings> ... As you can see I added some player data that would come from Atlas. For example, starting resources could differ based on the player, as could population limit, and various other attributes. Some of these may be optional, in which case a default would be specified in the game setup script. I also added a name property for the map itself, which allows special characters beyond what the filename supports. On the GUI side of things, I've added a dropdown for selecting map type (random / scenario). The available map list is updated based on this selection. Random really has no point yet as there's no implementation. You'll notice the "civilization" column. For scenarios it is disabled and only for display purposes, for a random map it will be a full list of civs. Since number of players is specified in the scenario, I've hidden extra player slots. Would love to hear comments, criticisms, etc. Here's a screenshot:

Thanks for the quick responses, obviously a very active project here OK, that makes sense. Ideally then the setup GUI would be populated with data for a static map (ie. the number of players, names for historical purposes, civs, map size, etc). Or it would have ways to choose that data in the case of a random map. Looking at existing scenarios, there is a PMP which I assume is some kind of binary data for defining map/terrain. Then there's XML which seems to specify units and a few settings. Could player civilization, name, map size, etc, be defined in that XML, perhaps in a new PlayerSettings element? I haven't looked into the old random map generator, but given the rest of the project it would make sense to be in JS along with the RMSs. There's a lot to think about there, no wonder it hasn't been started OK, I have some ideas from testing the software. Maybe I can get my friend involved as well, he's new to scripting but learning fast, and good with aesthetics too Thanks, Jeru. I found 0 A.D. when I was looking for open source games on Wikipedia, specifically RTS games because though I enjoy AoK, I also get frustrated by it's limitations. I had no idea this project existed until a few days ago. It makes a huge impression though, seeing the professional graphics which are far beyond almost any other open source project

Hi, I'm new here, so first let me say I'm quite excited about this project, as one of my friends and I simply love playing AoK together. I'm a computer engineer who enjoys hacking around, experimenting with new ideas, and making things work. Now, I've delved head-first into the code base, and can see already the importance of scripts in the functioning of the game. It's a great idea. I would like to contribute, and so have selected something simple to play with (or so I thought), which is to modify the game setup a bit. Modifying the GUI layout is trivial (though admittedly would be easier with an editor). I've added a column to choose "civilization" for the players. The problem of course, is when I want to write the script to hook these GUI objects up to the engine. It seems there is a lot hard-coded into the scripts (both setup and map generation) simply to get them to run with a human and some other dummy players, which is fine since it's an alpha. I discovered there's much missing from the scripting interface and it seems in need of some serious thought more than hacking up a bit of additional behavior. I'm also not keen on making changes like this without first finding out who's responsible for it now, and also if there's active work on it. Would be interesting to bounce some ideas around, maybe in this thread. Hope to hear back from some of you, historic_bruno