About the game roadmap

[zoot]

Let's make these risky features non-core and let's move them to core as we see fit. Because putting this into the core is the exactly the kind of thing

that goes against completing the game in a timely manner.

This is the kind of thing that Git does well. Basically, it makes it simple to let new features gestate in a branch of their own.

[kosmo]

Well, I came from outside and I did find the Trac pretty fast. Beside that, I'll propose a stick to the proverb "Never change a running system" ;-P

And I think it would be pretty hard to make all non-core features optional, as what would be done if they add to the gameplay itself?

[zoot]

Well, I came from outside and I did find the Trac pretty fast.

AFAIK, there's lots of patches waiting for review. As a side-effect, reviewers feel bogged down and potentially become less productive.

[historic_bruno]

This is a contributor-driven project. Let's organize things to make possible to have a game finished and to organize. Because it's open source doesn't

mean we shouldn't organize. The point is to find a way of organizing that works well enough and goes towards our common goal: have a finished and playable

game.

With all due respect, I don't think that would make much difference. There are lots of arbitrary ways to organize and we can produce all sorts of fancy tables, graphs, and documents which no one will ever read but which need time for maintaining. The critical point is this: as a volunteer project, we simply can't dictate what people choose to work on, and if someone doesn't care to work on e.g. advanced AI or unit conversion, does it matter if it's classified core or non-core, high or low priority? Similarly if someone wants to work on it, does it matter if it's core or non-core, high or low priority, or if we preferred them to work on something else? If they work on it and make progress, it's better than if no one worked on it. The most we can do is make suggestions and motivate, which we do

There's another complication. It's not all about new features or even improving existing ones, but there are a substantial number of bugs, some higher and some lower priority (some as a result of recently added features, etc), which take time away from strictly focusing on "completing the game". Though depending on a bug's severity it might prevent completion of the game. We're not so much focused on bug fixes at this point but they frequently arise and need fixing in the short-term (something breaks the build or the game stops working on OS X, etc).

I think for now the combination of http://trac.wildfire...ayFeatureStatus, http://trac.wildfiregames.com/report/3, common sense, and asking a developer is a good way of finding out what's important or not (doesn't include art tasks, as stated above they haven't used Trac or public forums, this may change out of necessity - we'll see)

AFAIK, there's lots of patches waiting for review. As a side-effect, reviewers feel bogged down and potentially become less productive.

There are about 20 open tickets with a "review" keyword, but not all are needing immediate review. Some are postponed for various reasons (read the comments to see why), some are very low priority tbh and will naturally take longer to get around to them, some need a more detailed review which could take hours, while some need the expertise of one individual who might be especially busy atm We just happened to have a flurry of patches over the past months but that hasn't always been the case. Meanwhile we have to push forward with other things as well.

[German Diago Gomez]

This is the kind of thing that Git does well. Basically, it makes it simple to let new features gestate in a branch of their own.

Yes I agree with that completely, but I didn't want to enter technical terrain yet. First we need the process, after that we can think of tools :-)

AFAIK, there's lots of patches waiting for review. As a side-effect, reviewers feel bogged down and potentially become less productive.

I don't know the internals well. But then, this is somewhere to put more resources in, for what I read.

[German Diago Gomez]

With all due respect, I don't think that would make much difference. There are lots of arbitrary ways to organize and we can produce all sorts of fancy tables, graphs, and documents which no one will ever read but which need time for maintaining. The critical point is this: as a volunteer project, we simply can't dictate what people choose to work on, and if someone doesn't care to work on e.g. advanced AI or unit conversion, does it matter if it's classified core or non-core, high or low priority? Similarly if someone wants to work on it, does it matter if it's core or non-core, high or low priority, or if we preferred them to work on something else? If they work on it and make progress, it's better than if no one worked on it. The most we can do is make suggestions and motivate, which we do

For what I saw all the data is there. But it could be better organized. It takes time to maintain: that's why I offer myself to do so. It's what I'm supposed to do at work. And it improves overall efficiency for the teams implied if you manage it well. Core/non-core, high/low priority. I think it's important (I used to think otherwise) how info is organized. I would say it's almost critical. If every contributor's barrier to entry is to take a deep look, research, ask developers a lot, be suggested... they will feel lazy because barrier to entry is high. I want to help improving this process.

But if you have a very clear page with a clear roadmap (yes, separating core/non-core features explicitely), a new contributor gets a much better feeling about the organization, and, what it's more important, receives much more information (not data, information) in a first look. Believe it or not, this makes a BIG difference. It's about making things easy, clear and manageable.

I have stories like that working always. You send a mail, actually it's not clear enough or well organized enough, the other side doesn't understand completely, so they don't help as you would expect. After that, you say, I'm going to put half an hour into organizing this in an excel file (for example) with comments. Result: What it was taking 5 days with mail back and forth takes an evening to solve. Yes, it works, and it comes from my own experience, not from guessing.

You're not going to make people contribute where they don't want to. But you can make people aware (with a better wiki organization) where it's worth putting the effort. That, in itself, could motivate some contributors to move the effort from toy things to useful things.

[plumo]

What you say is certainly the case for companies, where productivity is important, not in the least because of financial reasons.

This is an opensource game, even if it takes a few more years to ''complete''... I don't mind. That's my opinion ofcourse.

Slowly but steadily they're getting there.

[zoot]

I don't think the developers have unbounded resources, so it is not inconceivable that some things could be done in a better way. On the other hand, I don't think they want to release a game that feels mangled by cuts either.

[German Diago Gomez]

I'm taking a look at the svn structure, the wiki, the tickets, etc. From monday to friday I have not much time. It seems quite complete to me and it's decently documented. My purpose, organization-wise, would be organize information in a more friendly and coherent way in a single page from where to access the rest. Making it more visual would help:

• Status visible in a single page (some kind of summary) -- Status of bugs, kind, etc.
  
• Tasks split into groups (core, non-core, high/low prio) to see where useful work can go taking a look.
  

The goals:

• Lower barrier to entry to contribution.
  
• Have a clear summary of the status all the time so that we can:
  
  • Make contributors aware of where they can put work towards the effort of having a complete game.
    

The problem about what to contribute is not solvable (people choose themselves). But at least, we can show the info to have the summary more accessible.

I don't discard to contribute coding, but I think this first step is more important, since the game is contribution-driven, meaning that people come and go and are no experts about the process, directory structure, etc. This makes info organization more critical than for a group of people that already know the code base and process.

[zoot]

The goals are certainly sympathetic. Perhaps another item that could benefit from clarification is what "a complete game" means. It honestly isn't even clear to me if there will be a full multiplayer experience (with rankings etc.) nor if there will be a full singleplayer campaign. For all I know, the final release could just support playing against bots and via direct IP. The developers say they want to do full multiplayer and singleplayer, but there are no firm decisions to rely upon. This makes me less enthusiastic about contributing great amounts of time towards any of the core areas, even if I understand that they may not feel able to guarantee that they won't release anything unless it is superb.

[German Diago Gomez]

Perhaps another item that could benefit from clarification is what "a complete game" means.

Yes, I already thought about that. That's the single first thing that must be thought. My knowledge falls short now to know that. Must be discussed with the community and main developers.

But certainly, I already saw examples of WHAT to avoid. For example, why rewrite complete parts? I saw GUI rewriting somewhere. I don't know the purpose, but is it really worth it? These are the kind of things that need much time and we could put them somewhere else. Remember that every feature is implementing + testing + bug fixing. The smallest feature takes its time to integrate. A big one takes way longer.

Some will say that the contributor wouldn't do anything otherwise. Ok, that has its point but... did we present the contributor a summary (big picture) of the status of the project and where it's worth to put the effort in the first place to go for the goal of completing a game? At least he/she should be aware of that.

<p>If that dev were me and I'm a fan of the game, I wouldn't hesitate to move my effort into more productive areas. I don't mean the GUI in this case%

Edited June 18, 2012 by German Diago Gomez

[German Diago Gomez]

Perhaps another item that could benefit from clarification is what "a complete game" means.

Yes, I already thought about that. That's the single first thing that must be thought. My knowledge falls short now to know that. Must be discussed with the community and main developers.

But certainly, I already saw examples of WHAT to avoid. For example, why rewrite complete parts? I saw GUI rewriting somewhere. I don't know the purpose, but is it really worth it? These are the kind of things that need much time and we could put them somewhere else. Remember that every feature is implementing + testing + bug fixing. The smallest feature takes its time to integrate. A big one takes way longer.

Some will say that the contributor wouldn't do anything otherwise. Ok, that has its point but... did we present the contributor a summary (big picture) of the status of the project and where it's worth to put the effort in the first place to go for the goal of completing a game? At least he/she should be aware of that.

If that dev were me and I'm a fan of the game, I wouldn't hesitate to move my effort into more productive areas. I don't mean the GUI in this case is not useful, I really don't know. It's just an example of the kind of things that we should try to avoid, like entire system rewriting for fun, if what we want is that the complete game sees the light of day.

It honestly isn't even clear to me if there will be a full multiplayer experience (with rankings etc.) nor if there will be a full singleplayer campaign. For all I know, the final release could just support playing against bots and via direct IP. The developers say they want to do full multiplayer and singleplayer, but there are no firm decisions to rely upon.

What we need is a discussion, a real design document (yes, boring task, it's not coding ) that is realistic (can be completed some day) and to follow that. But this is not only saying we will have campaign or we will play against bots. If there is campaign it must be completely specified (level by level with all details). If it's against bots, also a design must be specified of how it will be accomplished. Of course you don't need a full spec from the beginning, you can (and should) iterate, but you DO need something to follow and complete the document over time. And more important: this is something that all of us can follow and that we know it's going to be in when finished.

As I always say: I can help to open discussions on these points if you allow me to do it. I think the talent is there, we just need more organization.

[Jeru]

More organized documentation is always welcome

Is the Trac wiki open to contributions?

[zoot]

But certainly, I already saw examples of WHAT to avoid. For example, why rewrite complete parts? I saw GUI rewriting somewhere. I don't know the purpose, but is it really worth it?

No one on the team has suggested that, to my knowledge, so that shouldn't be much of problem.

[German Diago Gomez]

No one on the team has suggested that, to my knowledge, so that shouldn't be much of problem.

My opinion here again: I didn't take a deep look to everything. You say noone on the team suggested it. Ok, I couldn't make a quick difference about wether it was or not a team/core proposal. So, let's make it explicit. I will try to make a more solid proposal on how (and not what, for now) to organize information by this weekend. Not a final one, but at least a draft of it. Now back to work

I will put the proposal first on the forum, I want to have the approval of the main contributors to the project. I want to make the info useful to them (although they already know how to move inside the project) and, above all, to external people that want to contribute (these ones are the difficult ones to hook cause they come without knowing anything).

Edited June 19, 2012 by German Diago Gomez

[zoot]

My opinion here again: I didn't take a deep look to everything. You say noone on the team suggested it. Ok, I couldn't make a quick difference about wether it was or not a team/core proposal.

Sorry, you must have meant this. That was indeed a team proposal, but as the thread progressed, they seem to have settled on a much narrower redesign of just the unit panel.

[Sonarpulse]

Well, let me just through this out here: For people interested in FOSS highly portable games, projects like this are more captivating because they are under constant development. I know I for one got over Minecraft about the same time it was finished. Even with the most radical game, once you "beat it" (or multiplayer seems to hold no new surprises), that's it, the game has nothing more to offer. With a game always in development, the replay value is endless because there is always something new.

While it is important to prepare the occasional stable snapshot for those "conventional types" interested in polish (who I imagine are little into 0ad at the moment) when the time is ripe, I would be perfectly happy of development of pyrogenisis carried on indefinitely, with the goal of basically making the engine the superset of every other RTS engine ever

[Gen.Kenobi]

Well, let me just through this out here: For people interested in FOSS highly portable games, projects like this are more captivating because they are under constant development. I know I for one got over Minecraft about the same time it was finished. Even with the most radical game, once you "beat it" (or multiplayer seems to hold no new surprises), that's it, the game has nothing more to offer. With a game always in development, the replay value is endless because there is always something new.

While it is important to prepare the occasional stable snapshot for those "conventional types" interested in polish (who I imagine are little into 0ad at the moment) when the time is ripe, I would be perfectly happy of development of pyrogenisis carried on indefinitely, with the goal of basically making the engine the superset of every other RTS engine ever

Couldn't agree more. The most rewarding thing is to see the development of something, help it out and see the updates going on and on and on.

A final game is important. But as the word say, it should be final. And when the time comes for a final game, it shall be realesed with polished engine and art. There's no rush here.

[German Diago Gomez]

While it is important to prepare the occasional stable snapshot for those "conventional types" interested in polish (who I imagine are little into 0ad at the moment) when the time is ripe, I would be perfectly happy of development of pyrogenisis carried on indefinitely, with the goal of basically making the engine the superset of every other RTS engine ever

The "continuous evolution" perspective doesn't go against what I'm proposing. It's just about setting sensible milestones, in a way that looks like a complete and coherent game. You can always add more features later. My point is to make a playable game.

Of course there are little interested at the moment. Because it's done the other way around: when you have a "full product" people will come for it. When you have a "working title" many people won't bother to play it seriously and people who come are primarily interested in adding content.

I think we should then mark two goals to keep everyone happy: continuous evolution with well defined milestones.

Edited June 20, 2012 by German Diago Gomez

[k776]

There are already well defined milestones for each release (the set of features targeted for it, the 2-monthly release schedule). The problem is getting things done during that time. We need more active developers. If you want to help, go see if you can drum up some free time C++/Javascript developers willing to help out for free.

[Pureon]

We urgently need some experienced Blender Skeletal Animators too - otherwise we'll be stuck with moonwalking elephants and a limited variety of unit body meshes to work with

[German Diago Gomez]

There are already well defined milestones for each release (the set of features targeted for it, the 2-monthly release schedule). The problem is getting things done during that time. We need more active developers. If you want to help, go see if you can drum up some free time C++/Javascript developers willing to help out for free.

Please, provide me the links so that I can take a look. I didn't find anything immediately visible :-)

You say we need developers (I could be one myself). Also animators (in the post below you). I will try to find the appropiate places to look for them. But I cannot guarantee anything. Let's move!

Please, tell me what exact tasks are to be done by these people or point me accurately where to find these tasks (not all of them, the concrete ones you really need help for).

Also, if you can provide me the links on how they could begin inspecting how to do things, it would be great, to lower barrier to entry and encourage people to do it. Let's make it easy for them.

Edited June 21, 2012 by German Diago Gomez

[Zeta1127]

I wish I was qualify to be a C++/JavaScript developer, because I only know C# and Java, and have limited experience with JavaScript. I really should start learing C++ soon, since game development is what I want to do, but I am extremely busy trying to wrap up my Bachelor of Science in Computer Information Systems from DeVry University.

[German Diago Gomez]

I wish I was qualify to be a C++/JavaScript developer, because I only know C# and Java.

One advice. Remember one thing when you start with C++. Repeat with me: Java/C# are not the same as C++ although their syntax looks similar. Hehe, really. Be careful:

- Java/C# --- Garbage-collected, object-oriented. Primarily reference semantics. Managed.

- C++ --- More oriented towards value semantics. Not garbage collected. Native.

Many people miss the point and when they use C++ they start to do indiscriminate new Something() everywhere. You will have to code with other styles.

[Sonarpulse]

Honestly, your knowledge of those languages is probably good enough to let you do JavaScript. There might be some corner cases where doing something in a Java/C# way will introduce a bug or other unexpected behavior, but you'll be able to do 75% of a task not worrying about the differences.

For me, the best way to learn a new language is just to dive right in, and C#, Java, and JavaScript are clearly similar enough for you to do that.