Kimball

It's not that Trac is "uncomfortable" for artists, it's more of a matter of convenience. It'd be great to keep things all in one place, but Trac was designed with code in mind. Many of the parameters and the concepts of tickets in and of itself are simply not coherent with art-related tasks. Tickets usually apply to bugs, while art is developed as needed. Very seldom does a bug occur in art. I'm not opposed to the idea of using Trac for artists, but I feel like simply inputting and maintaining current art tasks into Trac would be somewhat of a waste of time.

Though I recognize that this page is a bit outdated, http://www.wildfiregames.com/~gamedesign/dd/formation2.htm describes a minimum number of units required for some of the formations.

A third set of icons would indicate to the player that the formation would be available if certain criteria are met (units added to group). In some cases, a certain formation would give the player an advantageous edge, so it may be useful to him to know what is available to his faction. And they also wouldn't be very difficult to make.. the tooltips would likely be the most complicated aspect of the idea.

QFT. Kinda the @#$%.

It'll certainly be challenging for the programmers who get it done, but in my opinion it'll be more rewarding and ultimately more fun. Our engine is constructed around the ability to micromanage individual units - not large scale armies like in RTW. We'll leave that niche to them.

Since some of these formations require a certain number of units to be selected before they are available to the player, we'll need a third set of icons that are even more grayed-out. A tooltip that informs the player how many more units (and of what type, in some cases) are required for that formation would be helpful. Also, since the testudo formation is only available to the Romans, we should hide the icon unless the player chooses them.

Listen.. trajan. I can see that everyone has been very patient with you over the last few days about your dreams and aspirations for this game. Unfortunately the development team is a very busy group of people. Contrary to popular belief, we don't design games 24/7. We also have lives that include real jobs. Remember that we aren't being paid to do this. Therefore, for the free time that we are able to allocate toward the development of this game, which is also our dream - not just yours, we'd prefer to dedicate to implementing features that are absolutely necessary for development. The work we do is ultimately geared toward the next release - Alpha 3 for the time being. Perhaps when we "go gold", we can help you realize your full modding potential, but that just isn't one of our goals at the moment. Thanks for understanding.

Just in case this comes as new information to you, this button will let you add to what you've written rather than posting again: Otherwise, have a great day!

Nice work man! Loving that marsh map.

I'm also feeling that terrain density/opacity brush setting.. that could make for some interesting terrain painting.

This.

Unfortunately that would be WAY more complex. Just some cool editor tricks like lights and the custom waterfall thing would be neat.

In regards to that thread, having the ability to create a light source in Atlas would be outstanding. You would really only need two settings once placed - color and strength.

I love this idea, and I love the fact that you've already got a lobby set up! Two suggestions for your lobby: - Ability to choose a nickname (eventually log in using forum username, but that requires some login knowledge of our MySQL database that you'll have to speak with the web team to access) - Time stamp for chat. And some eventual suggestions for when the lobby can communicate with the game: Ranking based on: - Highest statistics (most units killed in one game, most resources gathered etc.) - Win/Loss ratio (requires a certain number of games to be ranked - a 1:0 ratio shouldn't put you in first place if there are people with 73:32, for example) - Fastest campaign completion time? Sort games based on: - # of players - Preferred playing style (Deathmatch, Conquer etc.) - With or without territories - Preferred map - Factions (pick one you like to play against or one that complements you for ally situations) - Availability of teams (or just FFA) Match-making based on: - Amount of time played - Difficulty of campaign completion - Win/Loss Ratio Since initially the multiplayer community will be small, we won't offer many options for match-making. Pushing the button will just put the player in a waiting room until equally-ranked players are found. Hosting a match-making game will only allow you to limit the number of players that may join. Once players are found, the game will pick the map/game/settings based on whatever is most popular online at that point. Somewhat like in Halo, players in the room will be able to vote up/down the option displayed until a consensus is reached.

2 things: In defensive mode, have units stop pursuing enemies once they exit the 10-tile radius. If they pursue them into the SoD, you may find a defensive unit wandering around the map if they're faster than the unit they're pursuing. In passive mode, units should still respond to being attacked. If they just stand there and let themselves be killed, there is no purpose to this stance.

I completely agree with a basic matchmaking service that lists current games and allows player to sort based on map, # of players etc. However, I don't think we should implement any sort of ranking or tiered matches until the big 1.0. There are just too many features missing right now for that to make sense.

This is actually the same error I'm getting building on my MacBook Pro. Does it have something to do with it being a MacBook and less to do with the OS? (Complete terminal output posted here: http://pastebin.com/e6yberLd

Nice work Phillip! This was a much needed feature!

Updating forum software.

Yes, it's true that we have many of the originals.. but not all.

By converting existing textures to PNG, we wouldn't be solving any of those problems. Since we don't have most of the originals, the existing artifacts and ugly compression would remain, the file would just be bigger.. and lossless for future changes (ie. icon sheets).

I see no harm in leaving the current DDS files in place. Part of the reason we picked DDS in the first place was file size, so switching everything over would not only take a considerable amount of effort, but would drastically increase checkout time and the size of complete packages. Would it be possible to implement something like textureconv that detects PNGs and TGAs are present in the mods folder when the game starts up and then converts them to the proper DDS as necessary? The only major issue I can foresee is converting a file to DXT3 when it needed to be DXT5, etc. This could present the player with a loading bar at the beginning to let them know that the extra loading time is attributed to their mods being implemented.

It is. Check Jason's link.

It depends on the model. Sometimes the texture is the hardest part, and sometimes it's the model. Mapping is the hardest part when you're dealing with rounded surfaces, like an animal, a helmet or a really complex building.

He means he would like to see you model some Greek/Persian buildings for 0 A.D. if you're interested. In which case, feel free to add me on MSN and send me a message when you've got some free time!