feneur

Well, the issue with the latter is probably more the opposite. Setting up a kickstarter project or something similar, and especially having some studio do some of the work, would mean the introduction of deadlines, and more importantly, the need to have something to show at a set time. (Even if that wouldn't be required when setting up the kickstarter project/wouldn't be stated, it would still be implied and expected.) And that would mean that we might have to release something we're not satisfied with. Regardless I doubt getting enough money to support a larger team working on the project isn't likely to happen, I mean it took 3 and a half month to reach 3250USD. Either way, the problem is probably more to be able to find someone/someones to do the work. The current team members don't generally aren't able to/want to, and it would take quite some time for someone else to know the code good enough for us to entrust with working on the game for money during a longer time. Once/if we'd have the funds necessary it might be enough to convince someone to spend the time to get knowledgeable with the code (provided we'd get the money without having someone, it's not so trustworthy to just say "we want to have a lot of money, if we get it we might find someone to pay" ). By then we'd probably be finished with part 1 anyway =) All that said, once part one is finished all cards are on the table again. If some members of the team wants to go through all the work and do part of the work/something different but still using the same engine/etc as a professional (i.e. for profit/or at least with paid developers) studio, then that's something we have to decide at that point. For now though it's out of the question. (The game is open source after all though, so it's not like anyone is forbidden to try and do something like what you describe )

Ah, doh That makes some sense, so I wonder why I didn't think of it. I guess it is because walls, or at least one "wall building session", feels like one building to me and I associate shift with constructing multiple buildings. I'll have to test it to see what it truly feels like, but at least conceptually it does sounds a bit cumbersome to have to press the shift key. That will have to be tomorrow though, don't have time tonight.

Testing a bit, and as far as I can tell I can only build one stretch of wall at a time (at least with palisades), i.e. to make the wall go in another angle I need to start anew, or am I missing something? (I am using the autobuilt exe and revision 11775 if that makes any difference) Shouldn't you be able to build walls going in new directions? I seem to recall seeing something like that in the videos as well, but I could be wrong, or am just not doing it the right way =) The way I'd imagine things should work would be Left click to place first wall tower, drag to determine length of straight wall segment, left click to end straight segment, continue to do the same or right-click to cancel the construction. That's based on how I remember other games doing it though

Maybe I just should have quoted the second part of that post To be sure it was clear that my intention was to offer a suggestion to another way to quickly shut down the application rather than to comment on the general issue

Hmm, I would be very surprised if they would dull their axes by hacking away at a stone wall. Either way, for gameplay reasons it's better to separate unit roles a bit, so you have to use all kinds of units to properly defeat your enemy. Not giving ordinary soldiers the ability to attack walls should also make walls more worth building, since the enemy will have to use siege weapons to take them down. And siege weapons are both more expensive and slower, so the walls will actually make some difference since the enemy can't just throw a bunch of ordinary units against them We do intend to include such a feature yeah, it is not included yet though.

Doesn't Mac have Alt+F4 or something equivalent?

Does it occur in latest SVN? I.e. after revision 11765. From your response it sounds like you could be talking about how things were previously.

Hmm, that would be fixing one issue by doing something completely different rather than fixing the main issue =) I'd say it's better in that case to increase the health of the Champion units, though with healers (included in Alpha 10) I doubt that's necessary, at least there should be some more testing before making too radical changes There are also techs which boosts the stats of Champion units, I don't remember which stat it is they increase, but either way that improves them, which also makes it less relevant to add another ability to them.

Sometimes grammar is relevant "Were originally" and "were not intended" Now palisades are included and will continue to be so.

The XML data isn't necessarily very likely to be useful in another game, they're likely to do things differently than us and would most likely require completely different files to go with the models.

Or to do it permanently see http://trac.wildfiregames.com/wiki/Manual_Settings for instructions

Probably the next time it's updated =) Hopefully it should be added to SVN today/tomorrow, and then it will be added to the dev PPA as soon as that's updated

As hinted by the other replies: It might be a good idea, but due to people leaving/joining/becoming busy for long time/etc it's too much work to keep such a list up to date.

Generally that should work as well, it just uses the OS method of doing it. On Windows at least it should take a screenshot and put it in the clipboard if you press "PrtScn" as it's known on my keyboard at least =) Then you'd of course have to paste it into e.g. Paint/Photoshop/Gimp/etc to actually use it, but it does grab a screenshot (I think there might be another shortcut to save screenshots to disk directly even just using the OS commands, but I haven't memorized it =) )

As Aviv hinted at, the main reason we don't publicize this more is because it's not as well defined as one could wish (especially with people leaving/joining =) ). I'd rather see it as this: Management: Me (Erik), Michael (aka Mythos_Ruler, for the artists), Aviv (aka Jeru, for PR in general), Kieran (aka k766, overseeing programming contributions, both in-team and from other contributors), Brian (aka bstempi, web dev lead) Art: Several official contributors and a few who contribute every now and then, but who don't want to join the team Programming: In theory Jan is dept head yeah, but due to having very little free time (and having moved to Singapore) he's more of an advisor at this point. Philip is definitely the lead programmer though. Apart from them there are a couple of official programmers and several who contribute in various ways as Aviv said. Music: See Aviv's post Web: Actually three Brian, Geek377, and gerbilOFdoom. Brian is the web dev lead, but Aviv oversees it as it's part of PR. PR: See Aviv's post (though he missed to mention that he's in charge, at least formally, with real life sometimes getting in the way it's not always feasible in practice + The History guys, though they're not as active anymore as they're not needed as much anymore. Another thing that makes it harder to keep a too strict hierarchy is that after a while the lines start to blur a bit Someone might have joined for one thing, but end up doing a bit of this and that in addition to the main task

Attack move is pretty likely to be implemented yeah.

I'm pretty sure he means ranged infantry units yeah Not sure how good Romans should be against ranged mounted units, the little history I know seems to indicate that's where they had there biggest weakness

Have been tired (remnants of a cold + lots of pollen in the air doesn't make things better =) ) and fairly busy the last couple of days, but now here's my reply True But it wouldn't be as versatile, it would just be a search and destroy thing =) But it's probably best to implement it as one in either case Hmm, this is probably the hardest part. We can't give the UnitAI too much power because that would lessen the role of the player (and it's probably hard to make sure it makes the correct choices in all cases), but on the other hand we should remove things which are just tedious micromanagement without any strategical value. It's hard to decide exactly where to draw the line imho. Yeah, attack-move interfering with stances (or stances interfering with it rather I guess =) ) doesn't sound too good

And also, the final implementation isn't decided until we've got something already in the game that we can test how it works in actual gameplay (Something that may sound great in theory might prove not to work at all in reality for example) So there's a limit to how much we can say when we can't be sure ourselves

Citizen Soldiers (representing the fact that some soldiers in the ancient times were both ordinary farmer/workers and soldiers) can already repair structures. Champion Units (representing professional soldiers who fought for a living and didn't work in any other way) on the other hand can't. While this might not be 100% historically correct, Roman soldiers were probably some of the best builders of ancient times, or at least some of the most efficient, it serves a gameplay purpose as it makes the different units have clearer roles. If all units can do everything there's no reason to choose the one over the other

Thanks, done

Should be fixed in revision 11698

http://www.wildfiregames.com/forum/index.php?showtopic=15797&view=findpost&p=236241 I'll add this to the Known issues topic even though it's not specifically an issue, enough people have suggested it to count as one anyway =)

Thanks for your concern. Formations do indeed require quite a lot of work before they're fully working. As it is a known issue I've added this to the "known issues" topic, and will close this as there are better places to discuss the actual implementation and we're already aware of the issue.

Take a look at your private messages here in the forums if you haven't already...