Yves

F00, quantumstate and I had a discussion on irc about the designs: http://irclogs.wildf...-%230ad-dev.log Here some other versions we discussed: http://i.minus.com/jEbnXPvZsp1Xu.jpg https://i.minus.com/jhx5se5yW1WST.jpg http://dl.dropbox.co...28_00-18-11.png http://i.minus.com/iUsM0hazsTbdv.png I think we agreed that the last version is the best.

Here's a new concept including the chat. The map description can either be moved into a seperate tab or kept where it is. I think it would be better in a tab because then all information about the map would be at the same location and we could use the space on the left. Note: The resolution is 1024x768 which is the lowest we support as far as I know... and it works. What do you think? Did I miss something?

Hmm all those design concepts lack the chat which also uses a lot of space. Probably we should make the map and the description tabbed or we could use a dropdown for map selection.

What about this layout? For me it feels more common to have the picture on the upper right corner. It's also more logical for the "workflow" of configuring a game. You first choose the map and how large it should be and after that you setup the players.

LOD is also not very effective in our case because you usually have a top-down view which means most of the object are about the same distance away from "the camera".

I think i was wrong, I shouldn't be too complicated. I've played a few games in the last days and it feels like after a certain point in time you're constantly in a huge battle. The main thing I was doing was setting rally-points somewhere near the front and keeping the stream of units rolling while keeping a balance between siege weapons, melee soldiers and ranged soldiers. It would have felt wrong if peace-music started playing at any time during the last ~20 minutes. This scenario could be easily covered with a kills/time ratio. However it could be different for campaign missions and for new players who aren't that aggressive . Probably it would still be sufficient to cover most of the situations by having a short-time kill-ratio and another longtime kill ratio. Let's say 6 kills in 10 seconds are the short-time trigger for small battles in the early game. the battle sound could continue playing for another ~30 seconds when the condition isn't met anymore. For the lategame we could have another long-term trigger. Let's say 50 kills in 5 minutes. It would be calculated regularly and if it goes below that threshold, it would switch to peace-music again. The idea is that it doesn't switch back to peace-music too quickly in the late-game.

Units on walls would indeed be cool, but it's currently out of scope for part 1. http://trac.wildfire...ayFeatureStatus As far as I know the reasons are increased complexity for pathfinding and because it wouldn't add very much to the basic gameplay. However you can still garrison units in the fortress or in towers.

I watched the whole thing and really liked the short part when he sings with a little deeper voice. Looking at some other videos on youtube I think it's a shame that he rarely sings with a deeper voice... but there's no accounting for taste. Something else: http://www.youtube.com/watch?v=TNv7MgZUF44 Unfortunately I missed a concert in Switzerland last month

You've got a point there.

Isn't that what's described here under "Keeping a Branch in Sync Without Merge Tracking". http://svnbook.red-b...ging.stayinsync That shouldn't be a problem anymore since subversion 1.5 because it has merge tracking.

I think battle alarm is something completely different than battle music and much simpler to handle. Battle alarm should be triggered whenever a unit gets attacked and a certain amount of time passed since the last attack and/or there's a relatively long distance between the current attack and all attacks in the past X seconds. The goal is to inform the player about attacks but he should not be annoyed by multiple alarms of the same event. Battle music is a lot more complicated, because it should only be triggered by significant battles. The first question is if battle music should be triggered globally or if the music-type (battle/peace) should vary for different players. It could add to gameplay if you hear battle sound and know that something significant is happening but you have to find out where first. The second question is what should be considered significant enough to trigger battle music. We could start with some use cases before we try to find a good algorithm for decision. Use cases (YES/NO if battle music should be played or not): YES: Two relatively large attack forces meet on the battlefield NO: One scout discovers a large enemy attack force far away from you base and gets attacked YES: One scout discovers a large enemy attack force close to your base and gets attacked NO: Two relatively small groups of soldiers meet on the battlefield in lategame YES: Player A attacks player B with a large attack force, player B has no military units left or only very few and will be defeated NO: Two scouts meet in the early game, one attacks. YES(PlayerA threatened): Lategame: A small group of 9 military units which consists of 90% of PlayerA's military units meets a large group of 40 units which consists of 50% of PlayerB's military units close to the base of PlayerA. NO (no player threatened): Lategame: A small group of 9 military units which consists of 90% of PlayerA's military units meets a large group of 40 units which consists of 50% of PlayerB's military units close to the base of PlayerB. The game is close to the end and a lot of smaller and larger battles happen everywhere. ... to be continued Looking at these use-cases you can see a few factors which are important: - Absolute number of units involved - Absolute number of units involved per player (see use-case 2) - Relative number of units involved per players (see use-case 4) - Relation of the troop strengths at the battlefield - Distance to a players bases (see use-case 2,3,7,8) - Game phase (early or late-game). We could use an indicator for economic power like the amount of resources and the increase speed of resources. The idea is to find out how quickly a player can recover from his losses in the battle. If you have enough resources and many unit training building, it often doesn't hurt much if you loose, let's say 60% of 50 units. - Number of different units attacked in the last X seconds (see use-case 9) The next step could be figuring out the relations between those factors. Well, this seems to be quite complicated. I think for optimal results it needs to be that complicated. There's a reason why there are commercial games that failed getting it right in a lot of situations.

What's the important difference compared to commiting a local working-copy and compared to how git does it? Basically you always have to keep in sync with the changes in trunk.

Very interesting inteview! Isn't that something for the news on the homepage?

Are braches on the serverside supported for our repository? Wouldn't that solve the problem? As far as I know it would, but I didn't yet use braches much, so I'm not sure if it works in practice.

I think I can sign that. We've had a discussion on irc yesterday and even though it would probably be possible to have the research buttons in the according buildings and express all current relations more or less clearly, I think it brings too many disadvantages. - It's not flexible for more advanced tech relations. - It's probably still not a 100 percent clear from the begining on - It uses a lot of space in the UI - It constatly (or very often) shows a lot of information that is rarely needed. - It probably requires additional clicks to get done what you want In my opinion a separate tech tree is the cleanest solution. I also liked that buildings get a bit more significance when you need them to research the related techs and I would like to keep that and represent that in the tech-tree in a more obvious way than with tooltips. Probably very similar to techs as icons which are above the tech-icons in the tree.

I think it's a bit confusing too, but the idea is to show that you can't research both techs. There's also another problem with e.g. the technologies that improve stone or metal gathering. If you research the stone improvement first and then in the next phase the metal improvement, it's not quite clear if the previous upgrade is still activated or if it gets replaced or if you didn't get the highest possible upgrade for metal because you selected stone first. At the moment I think we can only express these relations in a techtree and not in the small space for unit-training and research when you select a building. Maybe we should remove the icons there and only allow research in a techtree gui?

No problem, it's not your fault. I guess my current situation (very little time available during the week but a lot time needed to get all the required background knowledge) doesn't fit well for this kind of task and how we are working on it. Collaboration means being able to give feedback or answer to feedback within a relatively short period of time, being available on irc. etc... I started working on this because I remember that about a year ago we already discussed about Mac deployment but nobody wanted to work on it and nothing really happened since then. Now it looks like there's actually some progress and people working on it. I don't want to constrict that progress by taking tasks and not "allowing" other people who can do it faster to work on it. But I also don't want to spend my time on something I don't know if it will be used even if the quality of the final result is good. At the moment I have even a bit less time than normal and next weekend I'll have to work at least on Saturday. Working with the required pace on this task would be quite hard in that situation. For those reasons I decided to stop or at least interrupt my work on Mac deployment. I'll think about this decision again in about a month, but probably it will already be done by then. I hope nobody misunderstands that in any way. I'll still participate in the discussing when I have time to and I will probably do some smaller tasks in the meantime... and would be happy to get feedback to the minimap-patch.

It's good to see some progress, but it's also frustrating that you have done the same thing I've worked on the last two weekends and was close to getting a patch too. One purpose of this thread and the Wiki article was to avoid such a situation. I said I'd do this task and also updated the wiki article accordingly in this post. About the savegame location. That has been discussed in this thread too. Savegames are data the user could like to access for making backups or sharing it between computers/people. At least on Windows some games I know place savegames in mydocuments. My opinion is that they belong into ~/Documents on OSX. EDIT - Some feedback to the patch: Game data root: Your patch doesn't change the behaviour as specified in the table. However, it's still possible to define INSTALLED_DATADIR to make it work in a bundle. My approach was doing some basic validation of the paths at runtime which is checking if the directory exists in this case. If it doesn't exist, the default directory executable_path/../data/ is used. However the question is if this path is even needed at all if we can have separate paths for its subdirectories (like mods). Mod-paths: I've had a quick discussion with Philip about this topic but didn't update the wiki-article. We sorted out that we currently have at least three kinds of mod-directories. 1. Deployedmod: Usually public.zip which contains the "default mod" we deploy with the game. 2. mods: the directory containing all other mods. 3. usermod: the directory where atlas saves maps etc... (4. downloadedmods) there's another potential directory for automatically downloaded mods... but current it should be sufficient to just have "mods" instead. The reason to have a separate "Deployedmod" directory is to allow us including it in a simple app-bundle. We can't have the mods-directory in the app bundle. Directory validation: That's another problem I tried solving with my path. Currently the game just crashes in most cases if some required directories don't meet the requirements (don't exist, wrong permissions etc...). User-customizations: A nice feature would be allowing user-customized paths for all those directories... but that's just nice to have. My approach My approach was bit more radical. I've created an interface-class for well-known system paths and derived an OS-specific class from it for each OS. class WellKnownSystemPaths { public: virtual ~WellKnownSystemPaths(); // Directory containing the game's data (e.g. binaries/data). // Required access: Read virtual const OsPath DeployedDataDir() = 0; // Directory where the main executable is started from. // Required access: Read virtual const OsPath ExecutableDir() = 0; // Directory containing the bundled libraries // Required access: Read virtual const OsPath CacheDir() = 0; // Directory containing User-Data. Userdata is basically all data whose creation is triggered // by the user and which the user might also want to access from outside of the game. // Required access: Read, Write virtual const OsPath UserDataDir() = 0; // Directory containing the users customized settings for the game // Required access: Read, Write virtual const OsPath UserConfigDir() = 0; private: }; I've also added a new class representing a game directory and containing all properties and functions such a directory could have. The definition of this class: // Validation flags #define GAMEDIRECTORY_VALIDATE_EXISTANCE 1 #define GAMEDIRECTORY_VALIDATE_WRITE 2 class GameDirectory { public: // The user is responsible for checking the return-value and acting appropriately! bool ValidatePathsAndChoose(); void SetUserPath(OsPath UserPath) { m_Paths[DirectorySources.USER] = UserPath; } void SetOSDefaultPath(OsPath OSDefaultPath) { m_Paths[DirectorySources.OS_DEFAULT] = OSDefaultPath; } void SetGameDefaultPath(OsPath GameDefaultPath) { m_Paths[DirectorySources.GAME_DEFAULT] = GameDefaultPath; } void SetValidationBitmask(Byte ValidationBitmask) { m_ValidationBitmask = ValidationBitmask; } // Can return undefined results if ValidatePathsAndChoose isnt used properly! OsPath GetPath() { return m_Paths[m_ChosenDirectorySource]; } private: // Directory sources in order of priority enum m_DirectorySources { USER, OS_DEFAULT, GAME_DEFAULT }; const int m_DirectorySourcesNbrOfElements = 3; OsPath m_Paths[m_DirectorySourcesNbrOfElements]; Byte m_ValidationBitmask; DirectorySources m_ChosenDirectorySource; bool Validate(OsPath Path); } As you can see each GameDirectory can contain three paths (USER, OS_DEFAULT, GAME_DEFAULT). It also contains a validation bitmask specifying the requirements of that directory. ValidatePathsAndChoose() validates each directory according to its requirements specified in ValidationBitmask in the given order (User, OS, Game). It will use the first valid path it finds. A nice aspect of this solution it that you can define all the directories at one place in a consistent way: #ifdef USER_CONFIG_DIR m_Paths[m_GameDirectoriesEnum.CONFIG].SetUserPath(OsPath(STRINGIZE(USER_CONFIG_DIR))/""); #endif m_Paths[m_GameDirectoriesEnum.CONFIG].SetOSDefaultPath(WellKnownPaths->UserConfigDir()/subdirectoryName/""); m_Paths[m_GameDirectoriesEnum.CONFIG].SetValidationBitmask(GAMEDIRECTORY_VALIDATE_EXISTANCE | GAMEDIRECTORY_VALIDATE_WRITE); I don't know if this approach is better and I can't provide a patch yet because it's not yet working. Now it probably doesn't make sense working on it as you already have a working patch.

I currently listen to Calvin Russell. And because I like unplugged version very much:

Some of them have more or less . Different people created trac-tickets about the same thing or similar things. You see in the article that I tried matching some of the existing tickets to tasks but some tasks are still without ticket. I will create new tickets for those tasks without tickets if that's how it should be done.

Task nbr 6 completed in changeset 10946. I've closed ticket #947 because it's about the broken app bundle. I've now also taken Task nbr 1 because that's a requirement for even a first basic app bundle. Btw. I was looking at some codeblocks-problems on OSX but gave it up. Premake is really a mess on those "less supported" platforms and I hope CMake is much better.

About the repository, It's probably useful if we want to share the data more often and collaborate more closely. I've never made a repository on github/gitorious, so if you could create it, I'd support it and upload my work in progress there too. I will have to think a bit more about it because I don't really have important pro or contra arguments . Yes, that's true. I guess a few lines of code can explain best what I meant (see attachment). It's a very early work in progress, so don't expect too much. bundle-script.zip

Not sure if we need that. I think we won't change many existing files. That's quite similar to what I'm doing with my script except that I'm not using the bundle the current build-process creates but create a new one instead. What else could we do in the future? The installnames are predefined by our repository structure because after building it should work as it is for testing and development. Currently we tend to only support x86_64 on the Mac. Most of the clients support that and it makes it a lot easier in the first place. Why should we link it static? Changing the installname is easy.

I think we have enough overview and can start doing some work. We can still change any of those paths later if we need to. I've added some description to each task on the wiki-page and made a note who is assigned to that task. Feel free to take an unassigned task. I've only taken those tasks I already started working on, but If nobody wants to do the others, I will take care of them. @historic_bruno I've assigned you one of the tasks because I think it covers one of the ticket's you are assigned to. Is that OK? edit: wrong link.

The user doesn't choose where to put the files, but he at least triggers creating/deleting of savegames. Also the savegames aren't tied to a specific system and someone could want to copy them from one computer to another, share them with friends or whatever. I would tend to say they are more user-managed than game-managed. About the mods I'm not sure because I don't know enough details about how they will work and how they will be distributed and used. Probably Application Support is better.