Kimball

Open up the XML file and look for where I assume it currently says "Unnamed Map." Change that.

That's exactly how we intend to handle this.

*Added a work examples field - there's no reason why we should keep having to ask for this.

I like the first idea, but we also need a clear indication of each commander's behavior in the UI. The second option actually detracts from what benefit AoE2's terminology provided - not all of our players are going to be history experts (or even enthusiasts, for that matter). We need to simplify the descriptions so that even the most naive of downloaders understand how each AI will behave at a glance.

Hey guys, welcome to the community! Interesting offer, but I'm sure a programmer could better point you to the ideal area to direct your focus to. In the mean time, I would recommend spending some time familiarizing yourself with the source code (although I assume you've already done this to some extent). We don't actually have Korea as a faction (unless of course you have plans to add them into the game).

Agreed, should be good to get some community input on this. Moved.

I wish that was the case.

I get this error when I try using the auto start (for whatever reason, maps don't display when I just use the menu): ERROR: JavaScript error: simulation/components/AIInterface.js line 63 ReferenceError: IID_AIInterface is not defined ()@simulation/components/AIInterface.js:63 ERROR: JavaScript error: simulation/components/AIProxy.js line 20 ReferenceError: IID_AIProxy is not defined ()@simulation/components/AIProxy.js:20 ERROR: Failed to find file: "simulation/templates/special/pathfinder.xml" ERROR: JavaScript error: simulation/helpers/InitGame.js line 6 ReferenceError: IID_AIManager is not defined InitGame((void 0))@simulation/helpers/InitGame.js:6 ERROR: Failed to find file: "simulation/templates/special/pathfinder.xml" ERROR: CXeromyces: Parse error: gaia/flora_tree_date_palm:1: Did not expect element AIProxy there ERROR: CXeromyces: Parse error: gaia/flora_tree_date_palm:1: Element Entity has extra content: AIProxy ERROR: RelaxNGValidator: Validation failed And then 100+ more lines listing failure to load every object on the map.

Oops, yeah I meant the other way around.

Type "cd " and then just drag the system folder into the window. Should give you the correct path.

Honestly I think the only issue I can foresee with the aging textures is leading the player to mistakenly assume that the building will eventually crumble and they'll have to rebuild it. With seasons, as you said, we can simply include states that specify a slower gathering/walking rate, which ultimately I think has far greater benefit to gameplay than an old building. While seasons are perfectly reasonable to see having effect on the game, is the player to assume that the building he built 20 minutes ago is already looking to be 200+ years old? Because if it needs to be noticeable, that's ultimately the direction we'll end up going in art-wise.

Good to hear that there's someone else to confirm that I'm not crazy! See the ticket here for some details of the same error: http://trac.wildfiregames.com/ticket/683 Unfortunately no one has figured out why this happens yet. The good news is that this only occurs when you're in full screen mode. To get into windowed mode, either hit alt+enter while you're in game, or you can manually define the size of the window like this: Open /0AD/binaries/data/config/default.cfg Near the top you should find a line that says "windowed = true". Just change this to 'false' instead. If you want your window to be a bit bigger than it normally is, change the xres and yres settings to suit your preferences. I would strongly recommend you don't change these to be whatever your screen size is when you're in windowed mode. Take at least 100px off of each value or else the dock/header bar will inevitably get in your way and cut things off that you'll need, like the quit button.

Thankfully, no. If you've built the game, theoretically you'll never have to do it again! Although I would absolutely recommend recompiling once Alpha 4 makes an appearance - there's some new stuff that you won't want to miss. Unless you create an application via Automator, you'll have to do it by command line each time. When you run the game, type this into terminal: cd /Users/.../0AD/binaries/system ./pyrogenesis_dbg If you don't want to have to open Terminal each time, you can do what I've done (until of course we've released an official binary for OSX - don't worry, it's coming): Open Automator On the left panel looking through the library of commands with the "Actions" tab selected, search for "Run Shell Script" and drag this into the work area on the right. The drop down on the top should already say "/bin/bash". If so, leave it alone. In the text area, paste the same two commands that you'd type into Terminal on separate lines, obviously replacing the "..." with wherever the path to your 0 A.D. folder is. Save this as an Application to wherever you want. Since your file paths are not relative, it doesn't matter where you save the file. As for recompiling, just do these commands in order each time (after updating SVN of course, which depends on your client): cd /Users/.../0AD/build/workspaces/ ./update-workspaces.sh cd gcc make -j3 Additionally, you don't need to edit your workflow application(s) each time you compile. Just wait for 'make' to finish and you can run your fresh build from the same apps.

"Dirty" models is a whole different story. That's an entire mountain of new art that we'd have to develop for what I'm currently seeing as a relatively insignificant feature, unless you've got some compelling evidence otherwise. Also, you can't really fade a model per se. If your intentions here are to fade into the aged art, we're essentially limited to texture modifications. @ Erik But of course, that calls to question: do we want both seasons and aging textures?

Well the production of that sort of art is almost trivial. Making all of them look aged would take me under a week. The value, however, is where I struggle with this particular request.

It would be incredibly easy to create two sets of textures for buildings to show the old/new. There's two problems I see with this is the transition between the two. At what point do the textures change? If they don't fade, I assume the abrupt change will be a bit ugly to say the least. You mention fading the texture in over the course of 30 mins, but I assume that if all buildings are doing this simultaneously it could be rather costly for the CPU. Secondly, what gameplay purpose would this serve? Players are right to assume that anything they see change visually will affect the game in some way. Unless "older" buildings are more susceptible to crush damage or have fewer health points, I see little benefit to have the buildings change in appearance at all.

Excellent news! Mainly for the reasons Erik described.

That will depend on the player's abilities and the difficulty of the AI (which I assume could also factor into all this).

Yeah, maybe destroying the enemy's units instead of creating more of your own would earn experience. Since the AI should be producing units at a relatively constant rate regardless of the player's actions, that seems like a better idea. The only way that could potentially go wrong is if the player intentionally sends just enough units to kill off most of their units/buildings and waits for them to rebuild. Of course, we can't stop the player from torturing the AI - we want them to have fun with it like that. Now the longevity idea is interesting. How about we reward players for the number of units promoted? Only units who last in combat are promoted to advanced/elite, and I think that could be a great way to ensure that players are motivated to maintain their army. That certainly pushes the player in the right direction.

All good points. Given all that, we could just as easily only reward players for victories, at diminishing return for consecutive wins vs. same faction on the same map. The only thing I want to avoid here is only rewarding a player for something once and not telling them that they're not earning anything for the second time around. If we only reward them with new maps/factions the first time they try something new, they have no indication of whether or not they'll earn another if they keep playing. They also have no indication of how well they've done in the grand scheme of things - did they do better than last time? The experience system functions as a visual indicator of their progress. While we inevitably can't prevent players from performing mundane tasks to "level up", we can create failsafes to prevent them from wanting to. Ultimately, we will always have players who grind for something, even without rewards - they'll be working to optimize their speed/strategy/whatever. I guess my point is, we can never prevent the player from doing things that we don't find inherently fun. Like you said, you ran around the map looking for the present - perhaps the hunt was enough "fun" at the time. Who are we to say that the player grinding for something isn't fun?

Yes, the "license test" model would be specifically to teach aspects of the game, not mindless goals to reach. We would also of course set the time limitations would be reasonable enough to be attained and encourage players to optimize their use of the game. While they may still advance through the ranks at a normal pace, to earn the higher rewards they'll have to make use of hotkeys, build orders and other techniques to optimize micromanagement and speed. This doesn't always mean an early rush strategy, this just means that players are using all aspects of the game to run whatever approach they take quicker. You can still "turtle" at a fast pace, so long as that means that you're actively managing your economy. That's what the rank promotions will facilitate. People will become better accustomed to our game environment and learn some helpful tricks along the way. As for rewarding those who make stupid decisions to gain experience, this is where we would need to fine tune the system so that the players who do only train large quantities of useless units don't gain more experience for it. For example, where a player would repeat a scenario over and over again, the experience earned would be a diminishing value. A player would be better off diversifying his player style, training different types of units and using different strategies to accomplish goals, as this will earn him more experience. That being said, winning a match will inevitably earn you more experience than simply gathering a bunch of resources and training a bunch of units. Also, experience could only be rewarded to those who do win the match. In the effort of providing incentive to the ultimate goal of winning, perhaps you only earn 50% of the experience points you've accumulated if you lose. Also, you wouldn't lose experience for losing a match. Players that fall asleep at the wheel will simply be unlucky and only earn that 50%. If they're falling asleep mid game, we've got work to do in other areas anyway. The experience system wouldn't be the fundamental method of rewarding the player. Winning matches would be what would ultimately reward the player with additional content, not doing the same thing over and over until they earn something. For example, let's say initially, you can play with the choice of two factions on 5 maps against any AI faction. For winning using one faction on three different maps, you could perhaps earn a new set of maps (e.g. the desert biome set). Winning with both factions or winning a certain number of games against some other faction would enable you to play as them. The amount of experience points earned is certainly not our primary motivator here. In this sense, we are in no way diminishing the single player experience, but rather providing the player with incentive to try the game out, use all the factions and try out all the different maps. When they've earned a new faction or map, we can almost guarantee that the first thing they'll want to do is go try all of the new stuff that's available to them.

I'll wait until you've got time to read it then. It's not necessarily a cheap "easy way out", rewarding players for arbitrary things like winning a certain number of games. You'll see.

Although I can't seem to locate the original link, a few months ago someone posted an article discussing how game developers are using psychological evidence to get gamers hooked. While I am not suggesting that we aim to get people addicted to 0 A.D., I propose that we not rule out implementing certain features based on inspiration drawn from the same features discussed in that article. This primarily consists of complex reward systems that keep players coming back to achieve that next level that they're just "so close to." For Christmas, I got Gran Turismo 5. It has been in development for 6+ years now, and I think the reason is a lot of this theory has been thoroughly discussed and eventually implemented into the final project. Though their GUI is a mess, they've essentially built the game around the community and their rewards system. In playing this game, a few ideas came to mind for 0 A.D. that I'd like to share with the team. I've written a little comparative outline describing some of the ways we can mimic this system to develop a powerful method of training and retaining our fan base to play the game. 0AD_derivinginspiration.GT5.rtf I beg of you, please take this with a grain of salt. 100% of what is written here is purely hypothetical - I want the team to review these ideas, discuss the pros and cons, and eventually decide on what we want to take from this. I am not suggesting that we implement all of these ideas into our DD immediately, nor am I suggesting that our game will suck without these features. Perhaps the game would be better off without any of the ideas outlined - so be it. I'd rather have evaluated the possibility of a rewards system thoroughly and come to a logical decision collectively than to have produced a final product that not everyone is content with - including the fans. I have also not taken into account the amount of work necessary to implement these features. As the game remains in the alpha stage, I suggest that we not eliminate the possibility of developing additional features. Rather a game that we can be proud of that the community waited for than disappoint everyone with a rushed product. Release dates should not be of much concern to us at this stage, even though we have made significant headway in recent months. Anyway, time to hear your feedback.

Sneaky bot is sneaky.

I haven't seen it yet, but it looks like an interesting film. Thanks for sharing!