Jump to content

fcxSanya

WFG Retired
  • Posts

    1.083
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by fcxSanya

  1. That's not a slightly different license, it's a fundamentally totally different license :D. The NC and ND clauses mean it's not open source (see the definition, points 1 and 3), and would prevent it being distributed by most Linux distros (who only want open source content) or e.g. magazine coverdiscs (if such things still exist) or similar channels. Also it prevents you from basing any of your mod's content on the game's CC-BY-SA content (without permission from whoever originally made the game's content), since the SA clause means any derived work must be CC-BY-SA too, as well as preventing the game from ever making use of any of your content. It's about as incompatible as it's possible to be.

    I was intended to wrote something like this, but Philip was faster :)

    Few additional notes:

    * http://creativecommons.org/weblog/entry/8051 - post on creative commons web site about cc licenses and free cultural works;

    * "as our project already is a derivative work" if you mean that since you make a mod it is derivative work it is not make so sense I think: if you create your models/textures from scratch you can use any license which you want; otherwise if you derive from some materials from 0 A.D., as Philip wrote, you should license it under cc-by-sa.

    In any case I like your mod and I look forward to see the progress in it, good luck! :D

  2. I think we probably want AIs to run on every player's computer in multiplayer games, rather than just running on one and sharing its command output over the network, but if AI is expensive and some players have very slow CPUs and fast networks then maybe that's a tradeoff to explore later (the design shouldn't make it impossible).

    I don't know anything about AI in games, so I don't know how this usually implemented, but it seems for me more naturally to execute AI logic on one machine (server) and share its commands among other computers like human-player commands. In case if AI player logic will be performed on each computer this means that AI should be fully deterministic and can't have any random elements and also AI players should be synchronized with each other, right?

    All others in your post looks for me understandable and reasonable :D

    Edit:

    A related thought: preferably this release should focus on getting the AI system done, and programmers not working on that directly should help indirectly by mostly doing things that both the AI and the human player can benefit from. I leave it to you and the other programmers to decide/determine to what extent that is possible, but I really encourage you to find the possibilities.

    I will be glad to help with AI programming, but firstly we should plan what and how to implement and split this huge task to small relatively independent tasks/tickets. And I don't think that someone can do this without Philip :D Also I want to finish units promotion and fixing multiline centered text first, and for this I also need Philip's reviews :)

  3. Just paste your code into http://pastebin.com/ or other pastebin service and post link to it here and then someone can find problems in it. Personally I have not much java knowledge, but if there is some simple error, maybe I can help.

    Also it will be more effective to ask your question on some java-specific forum/mailing list/IRC-channel. For example this: http://forums.oracle.com/forums/category.jspa?categoryID=285 looks like official java forum.

  4. So you need something simple, clean, and small.

    Personally, to achieve that, I think it'd be good to move the minimap to it's own place, in the top right corner below the menu bar. Then increase width of the other panels at the bottom in order to decrease height.

    You end up with something like this: https://skitch.com/k776/rb781/0-a.d-redesign-idea

    Obviously it's a rough sketch (someone with better arts skills could probably blend the minimap a lot better), but the main idea is it decreases the bottom panels height by nearly half, giving more screen space. It also isn't tied to the minimap, so the panels can hide when nothing is selected, and the minimap won't be stuck about 1/4 of the way on high res screens (like mine).

    Are you draw your sketch from scratch, right? This approach seems wrong for me. You should start from that, what we have currently:

    post-9635-1290682573.png

    There is not so many free space on bottom panel (and it will be even less in the future probably), so I think we need to keep area size the same. To reduce panel height by half, you need extend it twice by width (area = width * height, right?), but by moving the minimap away from this panel you will achieve only roughly 1/5 of additional width. But minimap in this case will not fit into other layout and gui will be probably looks even more overloaded. Also the minimap under "menu" button seems uncomfortable for me.

  5. Currently treasures appears like general resources, we need to change a number of things with treasure gathering: collect resources immediately, don't count them in statistics, don't switch to treasures, when searching for next resource for gathering, and vice versa - don't switch to resources when treasure is gathered. We discussed this in the IRC and I hope to implement this in the near time.

    Done in the 8670.

    In my work-in-progress version I added civ icons and widen player name field, so now all counter from first tab don't fit into 1024 pixels and I moved "Civ centres built" and "Enemy civ centres destroyed" to the new "Conquest" tab.

    I committed this version in the 8671, so current layout of the summary screen is following:

    Units/buildings

    Units trained, Units lost, Enemy units killed, Buildings constructed, Buildings lost, Enemy buildings destroyed

    Conquest

    Civ centres built, Enemy civ centres destroyed

    Resources

    Food gathered, Vegetarian ratio, Wood gathered, Metal gathered, Stone gathered

  6. 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.

    Yeah, it is useful feature. I can display some icon if Michael (or someone else) will draw it. Or someone can propose another way to mark out victors.

  7. Some tab ideas:

    Oh, a lot of new counters! :)

    What I thinking about new statistics:

    need other things to be implemented first

    * Settlements Captured, Buildings Captured, Females Captured - need capturing

    * Tribute Sent/Tribute Received - needs diplomacy/tribute

    * Trade Profit - needs trading

    * Technologies Researched - needs technologies

    * Loot - needs looter (I'm working on it, so probably I will be able to implement this counter)

    some questions

    * Total Resources = Food Collected + Wood Collected + Stone Collected + Metal Collected + Trade Profit ? How "Total Resources" is related to "Tribute Sent"/"Tribute Received", should we take them into account?

    * Deforestation - what is it? it is percent of all forests, which is felled by specific player?

    * Kill/Death Ratio = Enemy units killed / Units lost ?

    * Temples - derived from template_structure_civic_temple.xml

    * Special Buildings - derived from template_structure_special.xml

    * Warships Destroyed/Warships Lost - warships - derived from template_unit_mechanical_ship_bireme.xml/template_unit_mechanical_ship_quinquereme.xml/template_unit_mechanical_ship_trireme.xml

    * Number of Super Units - derived from template_unit_super.xml

    * Heroes Killed - here is probably no questions :P

    implementation thoughts

    * Favorite Military Unit - can be implemented as dictionary { unit : count }, when some unit is trained we will search it in the dictionary and increase counter if it is there, or create new record with count = 1 if there is no such unit.

    * Most Bloodthirsty Hero - dictionary { heroName: enemiesKilled }

    * Avg Lifespan - add to Health component "birthday" (time when unit was trained), then when unit is killed accumulate lifespans in statistics.

    Common question about specific unit/building types, should we count them as generic types (e.g. should we count warships as units and civ centres as buildings) ?

    About layout

    Lets start for that, what we already have and see what and how we can add.

    Currently in the SVN we have following:

    Units/buildings

    Units trained, Units lost, Enemy units killed, Buildings constructed, Buildings lost, Enemy buildings destroyed, Civ centres built, Enemy civ centres destroyed

    Resources

    Food gathered, Vegetarian ratio, Wood gathered, Metal gathered, Stone gathered

    In my work-in-progress version I added civ icons and widen player name field, so now all counter from first tab don't fit into 1024 pixels and I moved "Civ centres built" and "Enemy civ centres destroyed" to the new "Conquest" tab. I'm working now on implementing "Map exploration" and "Treasures collected" statistics. I think first should go on the Conquest tab and second on the Resources tab. So after these changes summary screen should contain following:

    Units/buildings

    Units trained, Units lost, Enemy units killed, Buildings constructed, Buildings lost, Enemy buildings destroyed

    Conquest

    Civ centres built, Enemy civ centres destroyed, Map exploration

    Resources

    Food gathered, Vegetarian ratio, Wood gathered, Metal gathered, Stone gathered, Treasures collected

    On the Units/buildings tab currently there is place for one more column so it looks like we can fit up to 7 counters on each tab. I mean regular counters with header like enumerated above and numeric value, if we need values like this (it seems like forum insert space char in the middle of the link and brake it) obliviously we need more space for each of counters :P I think from counters, which you enumerate, the "Most Bloodthirsty Hero" and "Favorite Military Unit" can claim more space.

    It is my first try to place new counters

    Units

    Units trained, Units lost, Enemy units killed, Avg Lifespan, Kill/Death Ratio, Warships Destroyed, Warships Lost

    Advanced units

    Number of Super Units, Most Bloodthirsty Hero, Heroes Killed, Favorite Military Unit

    Buildings

    Buildings constructed, Buildings lost, Enemy buildings destroyed, Temples, Special Buildings

    Conquest

    Civ centres built, Enemy civ centres destroyed, Map exploration

    Gathered resources

    Food gathered, Vegetarian ratio, Wood gathered, Deforestation, Metal gathered, Stone gathered, Total Resources

    Collected resources

    Treasures collected, Loot

  8. Just a note on vegetarian food and the recently added treaure gathering: food gathered as a treasure should not count as non-vegetarian food, it should be showed as gathered food but ignored on the vegetarian ratio (like the food initially provided).

    Agreed. Currently treasures appears like general resources, we need to change a number of things with treasure gathering: collect resources immediately, don't count them in statistics, don't switch to treasures, when searching for next resource for gathering, and vice versa - don't switch to resources when treasure is gathered. We discussed this in the IRC and I hope to implement this in the near time.

  9. Would it be hard to add something like % of map discovered? There are a lot of other things which would make sense to add later, but that could be worthwhile to have already if it's not too hard to implement.

    I will try to add it. Initially I added statistics, which is easily accessible in the simulation code; I think I need to dig into some engine components (and consulting with Philip) to get access to FoW/SoD variables.

  10. Trac is better to have all tasks in one place.

    But I agree with Michael:

    I just don't think artists would be keen to use Trac.

    I think trac is not too comfortable for artists.

    Also some time ago there was there was some not actual old art tasks on trac (see for example http://trac.wildfiregames.com/ticket/401#comment:3, http://trac.wildfiregames.com/ticket/286#comment:8, http://trac.wildfiregames.com/ticket/289#comment:3).

    One more note, we (programmers) sometime created both ticket (to keep track on changes and submit patches) and forum topic to discuss design, UI layout, or even implementation details.

  11. Add these to the ticket: selection box, shift-click to select multiple objects, copy & paste object(s). Imagine how much quicker it'll be to map :P

    Ticket for copy&paste is already exists: http://trac.wildfiregames.com/ticket/96 (already 4 years :) ) Also there is some other opened tickets for Atlas: http://trac.wildfiregames.com/query?status...&order=priority. Maybe it makes sense to plan most important of these tickets to some of next alpha versions.

×
×
  • Create New...