Are there balancing changes planned for A24?

[Guest]

AI, maps, simulation, graphics, core engine and gui.

6 components. If everyone took the time to get familiar with just two. The system can be completed by just 6 devs. And yes, this is over simplified. The core engine guy couldnt possibly know every little detail from vfs to the scriptinterface. That is where the author and reviewer do some research and investigation and find those details.

This is not easy and requires much more work. Spending a lot of time analyzing something without writing any code is better in the long run.

Pointless checkmarks being “it should work fine” or “the game runs fine” while being not entirely familiar or even not knowing the underlying behavior and semantics. Inline comments are necessary to weed out syntax errors and likewise. But a review includes much more.

[Stan`]

7 minutes ago, (-_-) said:

This is not easy and requires much more work. Spending a lot of time analyzing something without writing any code is better in the long run.

Is it ? Is it good to have another 1-year hiatus because people are analyzing code ? I mean in the end wouldn't just people forget ? I can't remember everything I coded in the past 5 years.

9 minutes ago, (-_-) said:

Pointless checkmarks being “it should work fine” or “the game runs fine” while being not entirely familiar or even not knowing the underlying behavior and semantics. Inline comments are necessary to weed out syntax errors and likewise. But a review includes much more.

I couldn't find a wiki page for reviews, maybe we should create one.

 

[Nescio]

37 minutes ago, stanislas69 said:

Well the lack of reviews is directly responsible for the lack of commits. 

True, but in principle reviews can be done by non-team members. Getting more people engaged in the development process can be helpful in the long run.

[Stan`]

1 minute ago, Nescio said:

True, but in principle reviews can be done by non-team members. Getting more people engaged in the development process can be helpful in the long run.

I totally agree with that. However it's sometimes get confusing for contributors because they don't know whom to follow. I'm all for getting more people engaged, but we don't have that many people on the line do we ?

[Silier]

8 minutes ago, stanislas69 said:

couldn't find a wiki page for reviews, maybe we should create one.

 

this one? 

https://trac.wildfiregames.com/wiki/ReviewingPatches

[Stan`]

Ah nice, maybe it should be on the first page.

[Guest]

One would hope the development team responsible for the project would know the project.

But yes, if one year is what it takes, sure why not. By some metrics, the project is already stalled.

I really don’t understand the “we don’t have people argument”. Just 3 people forked and they seem to be handling things quite well. WFG have more people if anything.

Edited May 6, 2019 by Guest

[Stan`]

18 minutes ago, (-_-) said:

really don’t understand the “we don’t have people argument”. Just 3 people forked and they seem to be handling things quite well. WFG have more people if anything.

I haven't seen anything they've done so I can't assume anything, I don't know how much time they have on their hands so I can't tell much about that either. I don't know if they still use the same review process they helped put in place, or maybe they just trust each other and commit stuff. I don't have a single metric on their project, so it's really conjectures for my part at this point. I will also assume they don't have much issues handling external contributions

18 minutes ago, (-_-) said:

One would hope the development team responsible for the project would know the project.

And each one does, in their own respect on their own areas. If three people can know 150 000 lines of code, that's really good for them

18 minutes ago, (-_-) said:

But yes, if one year is what it takes, sure why not. By some metrics, the project is already stalled.

Well I'm still working on it, and so are the other artists, so I would assume you mean something else, though I might be wrong.

 

[Guest]

I didn’t mean literal line-by-line basis. Someone familiar with the AI might not necessarily know the details of the floodfill used for terrain analysis.

And yes, all the artists are doing a pretty awesome job. Stalled as in what nescio mentioned.

Btw, what is the total staff count these days?

Edited May 6, 2019 by Guest

[Stan`]

16 minutes ago, (-_-) said:

Btw, what is the total staff count these days?

Officially → https://wildfiregames.com/forum/index.php?/staff/

Now I'd say around 14 though, some people are only here one week out of two, or for single reviews. Some are also working on things that are not directly related to the game, like Implodedok.

19 minutes ago, (-_-) said:

And yes, all the artists are doing a pretty awesome job. Stalled as in what nescio mentioned.

Thanks. Well as I said earlier, borg is working on his mod, and I have high hopes of getting it in

21 minutes ago, (-_-) said:

I didn’t mean literal line-by-line basis. Someone familiar with the AI might not necessarily know the details of the floodfill used for terrain analysis.

Sure, hence why you put them in two different categories.

 

 

[Guest]

GL&HF.

Spoiler

You should not take what I post too seriously. I do not care anymore. I guess I care enough to post here and there (causing unnecessary trouble lol), but it won't take long to reach there.

 

[Stan`]

4 minutes ago, (-_-) said:

GL&HF.

Thanks, have a nice day

[Silier]

@camel you could be a more polite

[Servo]

DoM has only 2 devs with maybe a couple of help but the game is thriving because probably having a realistic mechanics. The game might be very tedious to play but omg it’s really awesome. 

0ad have lots of better things than DoM, just lacking realistic features. IMO. 

[Servo]

https://steamcommunity.com/sharedfiles/filedetails/?id=1730436925

my settlement. 

But I think Neolithic is going to be better with armies, formations etc but still in development by 1 person. 

I can give 1 gift to anyone who likes to play and experience a single player game. Just give me a day or 2. It might be boring but just give it a try, free anyhow . 

Edited May 6, 2019 by Servo

[elexis]

On 5/6/2019 at 12:33 PM, Nescio said:

A can propose a patch, person B review it, and person C commit it.

If the purpose of a review rule is to ensure that the commit was accepted by one person determined by the repository owner to be reliale and trustable, then this clause only costs more time and requires three instead of two people:

If person B was not determined to be reliable and trustable to decide over the fate of a diff by the repository owner, then the postulated purpose of the review is not satisfied anymore (refs 2016, refs Diffusion_of_responsibility).

If person B was determined to be reliable and trustable to decide over the fate of a diff by the repository owner, then person B would receive trust in a formalized way distinguishing it from untrusted members, which is equal to providing commit access for that purpose, without involving an additional person.

So regardless of that clause, the difficulty is developing developers and developing trust. And as WFG history 2003 to today shows, luck in getting computer science students willing to develop on a daily basis.

On 5/6/2019 at 11:10 AM, Nescio said:

Establish some simple and clear procedure, e.g.: 

The process can't become simpler than one person knowing what they do if not sacrificing the objective of the deployment conditions to investigate the correctness of all parts of the development stack.

https://en.wikipedia.org/wiki/Waterfall_model#Model

https://en.wikipedia.org/wiki/Software_verification

It's inevitable that if noone tries hard to disprove the correctness and completeness of a proposal that it will be defective. If each commit adds one or more defects and if the project is not finished until the defects are gone, the process will not converge towards a finished product.

If a developer needs a guideline or someone else instructing them how to review a patch, then that rather indicates that the developer lacks the knowledge how to skeptically examine the correctness and completeness of a proposal to begin with.

The developers that can determine the ramifications of the patch don't need instructions for that.

The developers that can't determine the ramifications of the patch won't benefit from these instructions (because it is necessary to deduce the ramifications of the proposal in order to investigate the correctness and completeness).

On 5/6/2019 at 11:10 AM, Nescio said:

launch a couple of test games, for different maps, map sizes, civilizations, number of AI players, etc. 

For code changes, consider a one-line change to the 6000 lines file in UnitAI. Impossible to test it based on any guideline. For balance changes maybe, although it's probably only reifiying what balance testers already do.

On 5/5/2019 at 8:18 PM, wowgetoffyourcellphone said:

Why so much fear in experimenting?

Receiving 5 times the same bugreport every day for half a year and worse makes one appreciate the silence of users enjoying a balanced bug-free game. Alternatively going offline works too.

On 5/6/2019 at 12:33 PM, Nescio said:

If everyone is reluctant to commit anything, then nothing gets changed

Balance patches were mostly committed by the Wildfire Games members who were actually playing the game.

Reluctancy to commit balance changes is attributable to many reasons, getting artists or programmers to commit balance changes is probably not the most time-efficient or quality-assuring procedure and the reluctancy would be justified in that case. Reviews eat a lot of time, extraordinary much time for reviews outside of the comfort zone. So better figure out who will create good quality without help and let them do their thing. I suspect Wildfire Games members currently don't play the game, there's just a balancing department missing it seems. The question is only whether a balancing department makes sense at all (due to the overlaps with the design department which formulates some existing constraints (DD) and can't operate in the realms of realistic development without knowing the confinements of realistic development).

About balance patches in particular, if the more five most trusted players already have eight different opinions on the patch, it's hard not to become reluctant. If those however would cohesively demonstrate for one balancing patch and can substantiate their claims well, one would have to be reluctant to not commit or provide commit access for the ones identifiying as active Wildfire Games developers.

On 5/6/2019 at 11:26 AM, Nescio said:

I mean get them committed, and that's currently where the problem is. 

Getting someone else with commit access to spend their time is one of two solutions to the stated problem.

(https://www.youtube.com/watch?v=SVY0D37FyBU)

 

[happyconcepts]

Guys, I am here now. Everything will be ok, don't worry.

[GunChleoc]

It could help if proposed patches were available as branches. This way, people who are a bit less techy but really good at testing and breaking stuff could help with that part of the review without having to learn how to apply patches, while people who know the code can look at the code itself. Going down this route has really helped us at Widelands - we have some people in our community who don't know any C++ but are really good at testing. This both increased the quality of the reviews and freed up developers' time.

[DarcReaver]

On 5/5/2019 at 9:17 PM, Stan` said:

Mmmh, in my own POV pros:

1. gameplay mods can strive, if the balancing was perfect, there would be no need for gameplay mods.
   I heavily disagree on this one. A game should always try to have a perfect gameplay/balancing in the first place. Mods should only ever exist to increase the available content for the game (i.e. have moar factions, or add new units) or to create a completely different gameplay experience (i.e. total conversions like putting the game setting into the medieval ages or fantasy setting) or alter the gameplay with a certain emphasis on something like "more realism" or stuff like that. Relying on gameplay mods to actually fix or improve core game mechanics should ALWAYS be out of the question. The game developers are the "experts" for their game. That's why they are responsible for their game content. Leaving the gameplay to external people is asking for trouble.
2. It also keeps the changelog history clean.

On the cons... 

1. It doesn't showcase the full potential of the game
2. It makes external contribution painful and frustrating, even useless sometimes
3. Makes most contribution about the engine, and not about the game.
4. It makes adding new functionality like adding growing fattening or #3488 very complex, because even if the features is good someone needs to take responsibility for committing it.
   Which sort of makes me question the whole "moddability" aspect of the game. If something even this simple is overly complex to be implemented into the core game because of interference with mods or other gameplay features there's something wrong imo. The core game should always be treated with the highest priority.
   
   The modders have to adapt to your game, not the other way around. If that is not the case you get exactly the issues like currently present: lack of progress because nobody can foresee and test all possible test conditions to risk ruining a stable repository version. 
    
5. I can't even think on how hard it would be to get bb #252 and my #2577 in the game...
   
   I certainly understand these points. However, I do think that there should be a prioritising of changes, with engine related engine/new core features being treated with much higher priority than i.e. a new slinger skin. Which is why I think the development should be shifted towards a more centric development progress to get everything streamlined to "whatever is needed is coded".

Of course this is my own opinion, and I might be painting a darker painting, than it currently is;

I answered directly in the post. Though I can understand quite a few of your points, I don't really get the whole development process as a whole tbh.

On 5/5/2019 at 8:40 PM, wowgetoffyourcellphone said:

In your POV what are the pros and cons of this approach?

 

I don't think balancing changes are like adding new code or features. It's basically just tweaking stats or enabling things already in the game. Perhaps balance changes could be given fewer restrictions.

There is no point of balance changes because there is no coherent gameplay in the alpha. This was discussed numerous times in the past already. As long as key gameplay features do not work it's only wasted time that can be spent on other, more useful stuff. Like making planned features work. 

 

On 5/9/2019 at 1:49 PM, elexis said:

 

If the purpose of a review rule is to ensure that the commit was accepted by one person determined by the repository owner to be reliale and trustable, then this clause only costs more time and requires three instead of two people:

If person B was not determined to be reliable and trustable to decide over the fate of a diff by the repository owner, then the postulated purpose of the review is not satisfied anymore (refs 2016, refs Diffusion_of_responsibility).

If person B was determined to be reliable and trustable to decide over the fate of a diff by the repository owner, then person B would receive trust in a formalized way distinguishing it from untrusted members, which is equal to providing commit access for that purpose, without involving an additional person.

So regardless of that clause, the difficulty is developing developers and developing trust. And as WFG history 2003 to today shows, luck in getting computer science students willing to develop on a daily basis.

The process can't become simpler than one person knowing what they do if not sacrificing the objective of the deployment conditions to investigate the correctness of all parts of the development stack.

https://en.wikipedia.org/wiki/Waterfall_model#Model

https://en.wikipedia.org/wiki/Software_verification

It's inevitable that if noone tries hard to disprove the correctness and completeness of a proposal that it will be defective. If each commit adds one or more defects and if the project is not finished until the defects are gone, the process will not converge towards a finished product.

If a developer needs a guideline or someone else instructing them how to review a patch, then that rather indicates that the developer lacks the knowledge how to skeptically examine the correctness and completeness of a proposal to begin with.

The developers that can determine the ramifications of the patch don't need instructions for that.

The developers that can't determine the ramifications of the patch won't benefit from these instructions (because it is necessary to deduce the ramifications of the proposal in order to investigate the correctness and completeness).

For code changes, consider a one-line change to the 6000 lines file in UnitAI. Impossible to test it based on any guideline. For balance changes maybe, although it's probably only reifiying what balance testers already do.

Receiving 5 times the same bugreport every day for half a year and worse makes one appreciate the silence of users enjoying a balanced bug-free game. Alternatively going offline works too.

Balance patches were mostly committed by the Wildfire Games members who were actually playing the game.

Reluctancy to commit balance changes is attributable to many reasons, getting artists or programmers to commit balance changes is probably not the most time-efficient or quality-assuring procedure and the reluctancy would be justified in that case. Reviews eat a lot of time, extraordinary much time for reviews outside of the comfort zone. So better figure out who will create good quality without help and let them do their thing. I suspect Wildfire Games members currently don't play the game, there's just a balancing department missing it seems. The question is only whether a balancing department makes sense at all (due to the overlaps with the design department which formulates some existing constraints (DD) and can't operate in the realms of realistic development without knowing the confinements of realistic development).

About balance patches in particular, if the more five most trusted players already have eight different opinions on the patch, it's hard not to become reluctant. If those however would cohesively demonstrate for one balancing patch and can substantiate their claims well, one would have to be reluctant to not commit or provide commit access for the ones identifiying as active Wildfire Games developers.

Getting someone else with commit access to spend their time is one of two solutions to the stated problem.

(https://www.youtube.com/watch?v=SVY0D37FyBU)

 

"Reluctancy to commit balance changes is attributable to many reasons, getting artists or programmers to commit balance changes is probably not the most time-efficient or quality assuring procedure and the reluctancy would be justified in that case."

Which is why I proposed that you should hire a lead gameplay developer who works on the design doc combined with changing gameplay related stuff. That was almost 2 years ago now.

Edited May 13, 2019 by DarcReaver

[Stan`]

3 minutes ago, DarcReaver said:

Which is why I proposed that you should hire a lead gameplay developer who works on the design doc combined with changing gameplay related stuff. That was almost 2 years ago now.

Which is why @Itms found two people to work on the design document, and we have @borg- working and experimenting balancing in his mod. You can find said design document here. The markdown source can be found here.

If you wish to contribute in some way, please feel free to do so by contacting @Itms directly.

10 minutes ago, DarcReaver said:

I heavily disagree on this one. A game should always try to have a perfect gameplay/balancing in the first place. Mods should only ever exist to increase the available content for the game (i.e. have moar factions, or add new units) or to create a completely different gameplay experience (i.e. total conversions like putting the game setting into the medieval ages or fantasy setting) or alter the gameplay with a certain emphasis on something like "more realism" or stuff like that

Of course this isn't perfect, and I would be much more happier if the game had perfect balance in the first place. However, I was asked what, in my own point of view, were the pros and cons. Since the goal is to try to find pros I thought it was a pretty good one. As @wowgetoffyourcellphone said, balancing needs experimenting (and other stuff).  Mods are a good way to experiment things between releases, as they don't follow the same schedule. It also allows one with no prior experience on balancing the game to learn things. It's kind of a way to get people to be competent with the balancing of the game by having a deeper knowledge.

Quote

. Relying on gameplay mods to actually fix or improve core game mechanics should ALWAYS be out of the question. The game developers are the "experts" for their game. That's why they are responsible for their game content. Leaving the gameplay to external people is asking for trouble.

In the industry, of course yes. Here it's a bit different, all external people are potential game developers. You could also be.

16 minutes ago, DarcReaver said:

Which sort of makes me question the whole "moddability" aspect of the game. If something even this simple is overly complex to be implemented into the core game because of interference with mods or other gameplay features there's something wrong imo. The core game should always be treated with the highest priority. 

That is not the problem here  The issue is that we have to ensure we are not breaking the game, that's what the review process is for: Ensuring quality. @elexis learnt the hard way that stacking patches on top of each other for years make the game unmaintenable and makes it require a lot of cleanup sometimes a full rewrite., so now he is very careful about everything he does which is a good thing. 

It's implemented in @borg-'s mod, and it seems to work quite well, but just because a code works doesn't mean it's good. We can't rely on quick and dirty code. Also, even though I do code, I don't have the programmer's hat, I have exactly the same impact there as say @Angen except I have the rights to commit my own code once it's reviewed.

tldr; The patch isn't implemented not because it breaks mods, but because we aren't sure this is the best way to do it.

23 minutes ago, DarcReaver said:

The modders have to adapt to your game, not the other way around. If that is not the case you get exactly the issues like currently present: lack of progress because nobody can foresee and test all possible test conditions to risk ruining a stable repository version. 

Of course, and we sometimes help them to adapt.

23 minutes ago, DarcReaver said:

I answered directly in the post. Though I can understand quite a few of your points, I don't really get the whole development process as a whole tbh.

Well we are kind in a unique situation to be honest.

 

[elexis]

2 hours ago, DarcReaver said:

"Reluctancy to commit balance changes is attributable to many reasons, getting artists or programmers to commit balance changes is probably not the most time-efficient or quality assuring procedure and the reluctancy would be justified in that case." 

Which is why I proposed that you should hire a lead gameplay developer who works on the design doc combined with changing gameplay related stuff. That was almost 2 years ago now. 

You propose someone to write a different design document.

My point was that the ones who do the implementation should not leave things up to chances but should attempt to keep the game enjoyable (even if you don't consider it enjoyable).

[DarcReaver]

4 hours ago, Stan` said:

Which is why @Itms found two people to work on the design document, and we have @borg- working and experimenting balancing in his mod. You can find said design document here. The markdown source can be found here.

If you wish to contribute in some way, please feel free to do so by contacting @Itms directly.

I'll check out the design doc and see if it fits my views. If so I will start contributing.

Of course this isn't perfect, and I would be much more happier if the game had perfect balance in the first place. However, I was asked what, in my own point of view, were the pros and cons. Since the goal is to try to find pros I thought it was a pretty good one. As @wowgetoffyourcellphone said, balancing needs experimenting (and other stuff).  Mods are a good way to experiment things between releases, as they don't follow the same schedule. It also allows one with no prior experience on balancing the game to learn things. It's kind of a way to get people to be competent with the balancing of the game by having a deeper knowledge.

Not to start a game design <-> balancing discussion yet again - if your game fails to setup even the most basic rulesets for gameplay you've failed at the task of creating a game. The game is a game because of game mechanics. Not because of gfx. Else it's a tech demo or a development skeleton for advanced applications. Ofc you need to create/modify a game engine to fit your needs, and those engine related issues have to be cleaned up prior to gameplay. But still both interact even at a very early stage of development.

In the industry, of course yes. Here it's a bit different, all external people are potential game developers. You could also be.

Yes you are right - potentially everyone can be a developer. But not everybody should BE a developer. There are dozens of good scripters out there who are good at creating code, or artists who are great with 2d/3d art. But they have no idea of how the game making actually works. But it really depends on how you define the term developer. A dev is usually someone who has overall understanding about the inner processes that are required to create and finish the game, along with knowledge about the game content. At least from my point of view. Ofc you can say that everybody is a developer, but the core people are "lead devs" or smth like that who hold the definition above.

That is not the problem here  The issue is that we have to ensure we are not breaking the game, that's what the review process is for: Ensuring quality. @elexis learnt the hard way that stacking patches on top of each other for years make the game unmaintenable and makes it require a lot of cleanup sometimes a full rewrite., so now he is very careful about everything he does which is a good thing. 

Since I've seen myself how hard it is to manually sync multiple svns from different people into a single, most up-to-date repository I can absolutely understand the amount of cleanup required. However, I didn't say anything about stacking patches on top of each other - I stated it's important to focus to get the important core features working and only after that has happened there is a need for optimization along with side effects like moddability etc.

Actually there has too much time passed anyways to not possibly break anything significant. But since noone cared for years that's sort of.. your problem (as a team)...  

It's implemented in @borg-'s mod, and it seems to work quite well, but just because a code works doesn't mean it's good. We can't rely on quick and dirty code. Also, even though I do code, I don't have the programmer's hat, I have exactly the same impact there as say @Angen except I have the rights to commit my own code once it's reviewed.

tldr; The patch isn't implemented not because it breaks mods, but because we aren't sure this is the best way to do it.

Which is absolutely fine. But that's what internal testers are for. You know...... Gameplay developer along with players to test the internal version from time to time to provide feedback and issues. Also, you can't always have "the best way to do it". It's impossible because your resources and time are limited. You need a realistically working version of a script that can be optimized in the long run. 

Of course, and we sometimes help them to adapt.

Well we are kind in a unique situation to be honest.

(sarcasm)

(/sarcasm)

Hmm looks liek the quote system got f'ed up. I'll again reply in the post directly.

2 hours ago, elexis said:

You propose someone to write a different design document.

My point was that the ones who do the implementation should not leave things up to chances but should attempt to keep the game enjoyable (even if you don't consider it enjoyable).

I stated that there are significant differences between the design document and the current "game" that is presented and published. I proved my points multiple times and stated options to put the game in line with the existing design document. I also proposed that a game design dev (or at least someone familiar with game designing) should be included in the team who actually is responsible for the balancing and design aspects of the game. Because that's what the game needs. A proper design followed by some intensive care from balance testers prior to release, instead of fiddling with randomly setup numbers and call that "balance fixes".

I also stated that the design document should be revised to actually provide a unique vision. Noone needs AoE II clones when there is AoE 2 HD and AoE 1 DE which provide the same, but better. Afaik no dev actually plays the game at all. That's how enjoyable the game is in it's current form. Not even the game makers want to play it.

Edited May 13, 2019 by DarcReaver

[Guest]

Maybe its not the design being bad. But the game being just so incomplete.

[Stan`]

1 hour ago, DarcReaver said:

Not to start a game design <-> balancing discussion yet again - if your game fails to setup even the most basic rulesets for gameplay you've failed at the task of creating a game. The game is a game because of game mechanics. Not because of gfx. Else it's a tech demo or a development skeleton for advanced applications. Ofc you need to create/modify a game engine to fit your needs, and those engine related issues have to be cleaned up prior to gameplay. But still both interact even at a very early stage of development.

Sure, and I believe updating the design document to the current state of the game is the first step, though the biggest part is yet to come after that.

2 hours ago, DarcReaver said:

Not to start a game design <-> balancing discussion yet again - if your game fails to setup even the most basic rulesets for gameplay you've failed at the task of creating a game. The game is a game because of game mechanics. Not because of gfx. Else it's a tech demo or a development skeleton for advanced applications. Ofc you need to create/modify a game engine to fit your needs, and those engine related issues have to be cleaned up prior to gameplay. But still both interact even at a very early stage of development.

Well most of the active devs are more on the engine part of the game than the game itself. We are cleaning the code up and updating the pathfinder which are needed maintenance task but only visible to the player through performance improvements.

2 hours ago, DarcReaver said:

Yes you are right - potentially everyone can be a developer. But not everybody should BE a developer. There are dozens of good scripters out there who are good at creating code, or artists who are great with 2d/3d art. But they have no idea of how the game making actually works. But it really depends on how you define the term developer. A dev is usually someone who has overall understanding about the inner processes that are required to create and finish the game, along with knowledge about the game content. At least from my point of view. Ofc you can say that everybody is a developer, but the core people are "lead devs" or smth like that who hold the definition above.

Sure but those qualifications are based on selection, and selection usually takes place when you have the choice  So most of the time we are not adding new "game devs", we are only adding "devs" because we need them for the engine.

2 hours ago, DarcReaver said:

Which is absolutely fine. But that's what internal testers are for. You know...... Gameplay developer along with players to test the internal version from time to time to provide feedback and issues. Also, you can't always have "the best way to do it". It's impossible because your resources and time are limited. You need a realistically working version of a script that can be optimized in the long run. 

Yeah but internal testers are usually people hired to use the dev version. Most of the mod players don't even know there is a dev version, and even fewer know how to compile it and use it. Depending on the platform it's even more complicated for non technical people.

2 hours ago, DarcReaver said:

Since I've seen myself how hard it is to manually sync multiple svns from different people into a single, most up-to-date repository I can absolutely understand the amount of cleanup required. However, I didn't say anything about stacking patches on top of each other - I stated it's important to focus to get the important core features working and only after that has happened there is a need for optimization along with side effects like moddability etc.

Actually there has too much time passed anyways to not possibly break anything significant. But since noone cared for years that's sort of.. your problem (as a team)...  

Sorry when I said stacking I meant that over the years the rmgen code had been added without much consideration about the overall architecture, which is why it ended up biting us before @elexis started to rewrite it. So when adding new features such as the growing and the fattening, the person reviewing the code has to make sure we aren't adding spaghetti code that while being functionnal, might be a big bottleneck in the future.

2 hours ago, DarcReaver said:

(sarcasm)

That's right  I guess we could be more useful

2 hours ago, DarcReaver said:

I also stated that the design document should be revised to actually provide a unique vision. Noone needs AoE II clones when there is AoE 2 HD and AoE 1 DE which provide the same, but better.

Well I don't think there are much rts games with that many factions  Also I disagree on the AOE clone because we are free an open source. It's like saying you don't need blender to exist because you have 3DSmax  

We do have a bunch of features AOE didn't have though, like territories for instance.

Quote

 Afaik no dev actually plays the game at all. That's how enjoyable the game is in it's current form. Not even the game makers want to play it.

That's an issue for me. I just don't have the time which sucks.

 

[wraitii]

3 hours ago, DarcReaver said:

Afaik no dev actually plays the game at all. That's how enjoyable the game is in it's current form. Not even the game makers want to play it.

That's not related to the state or quality of the game (and thus not a proper argument). I enjoy working on 0 A.D. regardless of whether I play it. It could have become a fishing game at this point for all I care.