German Diago Gomez

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.

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.

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.

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).

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. 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.

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%

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.

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.

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 :-) I don't know the internals well. But then, this is somewhere to put more resources in, for what I read.

Same as 1 but game could be built with non-core features and disabled by default, being able to activate. Pros. Doesn't discourage non-core contributions as much. 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. I have no doubt that is true, and I congratulate you guys for your hard work. But that doesn't replace a need to look for a way to organize that works. You say there are many downloads, but, are people really playing the game or just toying around with it? If we can get stats, as you suggest, it would be great. I'm a player, I prefer to play a game with 5 features well polished that one with 20 features unfinished because the "unfinished" thing will very likely make the game truly unplayable. That's my rationale for cutting and only going to the essence. Yes, open development is good. But we also need an assets sheet of what's in and what's out for the core. Open doesn't mean disorganized. I don't know if such a document exists, but should make a clear distinction as well about what's in and what's not. The problem: we need to present info more explicitely. For you guys it's easy, but for someone coming from outside, he should take a look and know more. I saw some features are "should have", "must have", etc. Why not making two separate tables? One for core things, another for non-core things. Separate. This way I take a quick look and I immediately can see what's useful to do for the game.

I do appreciate it :-) We cannot organize as a studio, so let's try to organize in another way. But organization is key to success. 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. Proposal 1: Split features in core and non-core. (I know there is a classification already, but it should be more explicit in the wiki. Different tables for core and non-core, for example, so that's easy to look at at first sight. Stablish a process for core features. Core features MUST be in on the game. Well tested and bug fixed. Non-core features: optional. Go in when quality is good enough. Pros. Contributors are well aware of what's really useful to go towards the definition of a "complete game". People who don't want to focus on core features are still able to do it. Cons. Everyone likes to see his contributions in. Non-core are not in by default. Proposal 2:

I don't know why I can't post a long post. I will come back when internet works better. It's performing horribly.

I'm sorry about the format for the post :-) Can anyone tell me how to quote multiple times the same person? I'm going to reply by hand cause I keep getting an error of unbalanced quote.../quote This post reply is for historic_bruno. I will mark between dashes his comments and will use red for my comments. ---------------------------------------------------<p>You need to appreciate 0 A.D. as a free open source, volunteer-driven project with only one developer who has received compensation for his work, and even he has significant outs

Ok, let's try the other way. Let's make a single player game and postpone the network multiplayer, which is a big feature. For example. The thing is to come up with something we all agree. We can propose 2 or 3 drafts about the features supported for each proposal and vote based on that. Once voted, we make a plan and stick to that.

Make me aware of where you think I can help, of course :-) About futile in the past. You speak from the experience, of course :-) But maybe you didn't explain (I guess) the contributors WHY it's important to focus on some set of things and not on others. Of course, this is for fun, but if you really get in people motivated about having a finished game, I think it's enough for them (including me) to forget about the boring tasks. They will help with those as well in order to see a finished game. What I would like us to come up with is with a project that looks like a finished game. It doesn't need to have all the features in the world. You say that we must make it interesting to play. I agree. But first you need a basic FINISHED game and after that you can make it rock. If you add and add and add again, without stopping for bug fixing, controlling quality, etc, you will have a never-ending and failed project in which players cannot really play the game because it's buggy. In general, the steps I would follow: 1.- Make a basic game that contains all the essence of the game. Not much content, which adds a lot of review overhead, not "fancy" extra features. Just the basics. When I say the basics, I mean basic. 2.- Get this feature set and make it really solid (well tested and bug fixed and make contributors aware that it's important to contribute for those if we all want a game). 3.- You have a solid playable game, which is essential. 4.- From there, develop on top of that finished game where all basic features work, the game you really wanted from the beginning, as a 2nd part of the game and adding incrementally over the solid base you already have. About features: Why AI? AI is complicated. You can make a first release without campaign and centered around a solid multiplayer online game. Why ships? Why not doing everything without sea for a first release and we get rid of the ship associated implementation of features? Ship ramming. Improved ship movement. Advanced ship movement. Dynamic ship animations. Different Game Modes ("Default", Classic, Others?) <---- Choose only one from here. Let's not point to the sky if we don't have enough resources, it's absurd, we wouldn't ever finish. I'd rather have a finished game, even if not as nice. At least it would be seriously playable. As said before, I'm willing to help. But the cut must be heavy to have something deliverable. I propose to discuss about what could be cut further (depending on the status of the implementation). Remember that for every feature you put in, even if it looks trivial, you need to implement it + test + bug fix. It takes time.