About the game roadmap

[German Diago Gomez]

Hello everybody,

My name is Germán Diago and I work as a game producer for gameloft in Android publishing in Ho Chi Minh City, Vietnam. I have a strong technical background. I studied computer science and I'm strong at c++. I love software (and specially games) development. But I didn't come here to talk about that :-)

Just wanted to give you a personal opinion. You have a great game in your hands. I think it's the single best open source game I've ever seen. But my opinion is that you are failing management-wise.

Although I haven't followed the game development closely, I see you keep changing and adding new things all the time. I think that you should take this approach.

1.- Publish a roadmap with the minimal set of features you think can do a 1.0 game with the primary goal of having it complete in not a long time from now (maybe 6-8 months?):

- Choose only one platform (maybe PC) and focus on that.

- Choose a manageable number of civilizations/features (let's say 3, but I'm not the expert to say this).

For the roadmap you should be VERY accurate about what's in and what's out.

2.- Stick completely to that, even for contributions.

3.- Release a 1.0 version of the complete game.

After that, you would have a finished game (which is VERY important) and it should be a matter enlarging the scope for the consecutive versions you publish. Maybe a port to Android, more civilizations, bigger campaign?

I offer myself to help with organization matters (no time to code now, but I'd love to).

I hope you get this post as a good critic and not as something bad to you.

If I can talk to developers through IRC/MSN it would be great to help to organize, but I will have a ton of questions first .

Regards,

Germán Diago Gómez

Germán Diago

[zoot]

For what it's worth, Gameloft makes great games. Which titles have you been involved with? In any case, welcome to the forum

[German Diago Gomez]

First game was Texas Hold'em poker 3, but it's not out yet cause it's been redesigned and it got delayed. Last game was Men in Black 3 game (see in google play or Gameloft shop, I'm in there in credits :-) ). You can also find it in Amazon store for kindle fire.

Next one, I won't say because I don't know if I'm allowed. We do what it's called mass-porting, not game creation. We follow iOS creation version and port the game to more or less 250-300 devices on HD+ and HD- devices.

The challenge is that there are several resolutions, aspect ratios, texture compression, different CPUs and GPUs. So we find problems and have to redesign the game for several screens, optimize, fix color saturation, adapt controls to Xperia version, etc.

If I can help, as I said, don't hesitate to contact me. I would like to talk to developers to see if I can be of help organization-wise :-D

Edited June 16, 2012 by German Diago Gomez

[k776]

The issue isn't organising what goes into a release (we have a roadmap of what each release should get done). The issue is the speed of developing features, getting them reviewed, and then included into the game. Things constantly get pushed back.

Choose only one platform (maybe PC) and focus on that.

One of the selling points (metaphorically of course - the game is free), is that the game runs on Windows, Mac, and Linux. We're not about to start supporting only one system.

Choose a manageable number of civilizations/features (let's say 3, but I'm not the expert to say this).

Art/Civs are developed separate from the rest of the games features (different team of people), so these don't slow down the programming team.

We appreciate your feedback, but you must understand, we aren't a paid company. We don't have a team of people working on it each week. We're all free time devs, so trying to push a commercial style roadmap/planning system on us won't work. It might even backfire and get less work done.

That said, if you'd like to help contribute to the games code, please feel free. We could use some skilled people.

[German Diago Gomez]

The issue isn't organising what goes into a release (we have a roadmap of what each release should get done). The issue is the speed of developing features, getting them reviewed, and then included into the game. Things constantly get pushed back.

One of the selling points (metaphorically of course - the game is free), is that the game runs on Windows, Mac, and Linux. We're not about to start supporting only one system.

Art/Civs are developed separate from the rest of the games features (different team of people), so these don't slow down the programming team.

We appreciate your feedback, but you must understand, we aren't a paid company. We don't have a team of people working on it each week. We're all free time devs, so trying to push a commercial style roadmap/planning system on us won't work. It might even backfire and get less work done.

That said, if you'd like to help contribute to the games code, please feel free. We could use some skilled people.

With PC I meant those 3 operating systems you are already supporting (I think it's reasonable). But my point is:

• People won't play an unfinished game.
  
• It's better to have a finished game in one platform than having poor support and unfinished ports. I saw a port to android and the game is still in alpha status. In my opinion, that effort should go elsewhere. I understand you cannot mandate contributions, but we should make contributors aware of where it's better to put the effort to have a finished game, which is what we all would like to see, including people that contribute to the project :-).
  

I took a look to the documentation (design document, etc.) and all looks pretty organized.

My point is that maybe you are trying to get a too big game for so few resources. Cutting is essential if we want a finished game.

I didn't see a roadmap (maybe I missed something, I didn't take a look to Trac yet).

I feel that if there is a need for a central and realistic roadmap that makes contributors conscious of where it's really useful to contribute.

I offer myself to contribute an organized and coherent roadmap proposal if you allow me to do it. I would need to contact developers to have a talk and retrieve info.

My goal would be to make a realistic roadmap:

• Cutting features (and postpone for a 2.0 version, for example).
  
• Estimate how many resources we're going to have available in average and what kind (programmer, artist, review, testing...)
  
  • This means also doing the boring parts, like test rounds, etc, but in the end we will all be happier if we see the finished thing.
    

  [*]Set milestones with some flexibility (taking into account that this is contribution driven project).

  [*]At some point we need to feature freeze and correct bugs to improve quality.

  [*]Set a coherent process for the whole thing (when to code, when to release, when to test, when to stop adding features, when to bug fix)

  [*]Coordinate contributions and prioritize so that they are coherent.

  • Make contributors aware of what's useful for the game to get finished.
    
  • Organize feature-oriented. Less features but complete is better than more features that don't work correctly.
    

I look forward to your response. And... go on! the game looks promising :-)

Edited June 16, 2012 by German Diago Gomez

[feneur]

Well, apart from some things which potentially could be cut (formations, maybe not have as advanced diplomacy as we'd like) there's really not much more we can cut. Apart from smaller things (and performance fixes etc) there's really just diplomacy, and the sound system and pathfinder rewrite (both of which are being worked on). A multiplayer lobby server would be good to have as well, and I guess that can be seen as pretty large. There's still a bunch of smaller things of course, but most would really not be worth cutting, we need to have something to set 0 A.D. apart from other similar games or at least make it worth playing. And with all the things we've already cut, triggers, cinematics, etc there's really not much left to cut (See http://trac.wildfiregames.com/wiki/GameplayFeatureStatus )

About e.g. the Android port and other things, it would most certainly be nice to have all the more important things done first, but in most cases it's a matter of either have some less urgent feature implemented or none at all since it's people doing things because they find it interesting. Also, at least that work proved useful since it brought about some architectural changes which made things work better on the other platforms as well.

I'm not saying your thoughts are wrong, just that it's proved to be futile in the past to try and do things more strictly There are still things where I'm sure you could help out, but you need to be aware of the issues

[German Diago Gomez]

I'm not saying your thoughts are wrong, just that it's proved to be futile in the past to try and do things more strictly There are still things where I'm sure you could help out, but you need to be aware of the issues

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.

Edited June 16, 2012 by German Diago Gomez

[Mythos_Ruler]

Part of the problem is that many on the team are not multiplayer gamers and they are not interested in building a multiplayer-only game.

[German Diago Gomez]

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.

Edited June 16, 2012 by German Diago Gomez

[kosmo]

Imho, I do not have the impression that this is necessary.

[plumo]

I can only speak as a member of the community (no contribution except donation), and I'm perfectly fine with the way things are going up until now....

[JuliusColtranePille]

... really not be worth cutting, we need to have something to set 0 A.D. apart from other similar games or at least make it worth playing. And with all the things we've already cut, triggers, cinematics, etc there's really not much left to cut (See http://trac.wildfire...ayFeatureStatus )

this list (it's new to me) sounds perfect to me. and the planned features for the second part sound very very interesting, too (units on walls, strategic campaign with round based kind of interface)

so i have to agree with plumo. - things are going well. and i guess there will be a lot of user-generated scenarios with - at least - accurate maps and circumstances which will countervail the lack of an in-game campaign with triggers and narrative content.

i think the only remaining major issue is the poor performance and an easy, stable and usable multiplayer interface.

when having achieved this, the game will already be very enjoyable in my eyes!

[FeXoR]

There's another problem with voting. Assuming the community votes in the end they may vote for something that the programmers don't want or at least don't want to do. Then the propellent forces pushing development forwards - motivation to code for 0AD in the free time - will start to fade.

I think the team is doing a great job! Even if I don't agree with all concepts I think they are on the exactly right track of how to create an awesome open source project and am sure they or their successors will reach finalization.

Another minor thing: I think for an unfinished game this one is played by quite a few people. And AFAIK the game is in general getting better playable each alpha release (and additionally more feature-complete and pretty/ambiance rich). Many positive comments (like my first glance) was about how much care is taken here for the detail. Though I'm only a fan for detail if it's not very time consuming/resource needing other's might say that's what make a game great.

Edited June 16, 2012 by FeXoR

[zoot]

A different approach to accelerating development could be to do it more openly. Many decisions seem to be made on the staff forums. Not that there is anything wrong in that but it prevents other folks from taking 'ownership' of that part of development. If it is decreed that triggers (say) can't make it into part 1 then people will tend to accept that. If on the other hand it is 'opened', like laid out on the forums - "how would you guys implement triggers if we were to include them in part 1?" - then people at least get the opportunity to think about it, talk about it and possibly even begin writing some code about it...

Edited June 16, 2012 by zoot

[feneur]

Well, in the specific case of triggers etc it's not just about the triggers themselves but all the other things needed to be implemented with them and more importantly the campaigns/scenarios would have to be created (which would take several months at the very least). Also, I'm not sure what would be the value of diverting the development effort even further, as said above the development can be split enough as it is with people working on what they want (and as above I'm not saying that's all wrong, I just don't think it's something we should encourage even more). If someone wants to implement triggers, sure go ahead, if you really don't want to do anything of the other things, if it's good enough we'll include it. That's probably where my main point is though (apart from the fact that if we e.g. asked the community "what features would you like to see the most in part 1?" we'd get all kinds of responses, everyone listing their own pet features, and many which aren't relevant to the main idea of 0 A.D.), to know the code well enough to be able to implement one of these bigger things you'll most likely need to have spent so much time and submitted patches etc that you already are on the team

As for open decision making, apart from "too many cooks..." (an important reason, though opinion may differ as to how relevant it is) it's mostly due to 0 A.D. having been a non-open source project first and it's hard to completely shake that mindset (not as important in terms of value, but probably more important in terms of what actually affects how things are done). Either way I don't think the solution to moving the project closer to completion is to start discussing adding more features =) I most definitely think we should do a more open overview of things when we're done with part one and start deciding what's going into part 2 and in what order (That said, there's always the risk of some people with a louder voice being heard over other people who might have a more valid point to make, so I still think it's relevant for a limited number of people to make the final decision. )

[zoot]

Yeah, I don't really buy into the 'louder voices' line of thinking. This isn't an assembly hall, it's a website forum. If I make a convincing argument, that doesn't prevent anyone from going back and reading other people's posts too. Furthermore, if someone's arguments fell short before the decision was made, it will still fall short after the decision is made. We can't really coerce people into sharing a poorly articulated vision.

I'm not suggesting it's an easy task in any way, just that you'd want to consider very carefully if there are decisions that you have made in the past that could benefit from being reassessed in a more open way.

[historic_bruno]

(this is not a reply to zoot's last post )

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 outside commitments We're not organized like a game studio, maybe 8+ years ago it would have been good to take that approach, but back then we weren't FOSS either so it's a moot point. I believe we have been FOSS for just shy of 3 years? In that time we've completely rewritten the core of the game (with significant benefits); art and music have been mostly revamped from late 90s to 2010s standards.

There's nothing wrong with an evolving vision of the game. Some things you simply don't know whether they will work until you try them, and on closer inspection they may be a really good or really bad idea. In that sense, 0 A.D. is not solely concerned with finishing something ASAP though that's nice, but also providing room for research and experimentation on new ideas and techniques, so that when we reach beta, we have a bunch of really good, thoroughly analyzed ideas instead of a few decent ones pieced together with hacks (a constant struggle to find that balance). Also it helps to keep developers interested since we aren't being paid or contractually obliged to contribute, little side projects and experiments are one way of keeping things interesting. That shouldn't be confused with not having a focus.

I don't feel that we strictly need to "accelerate" development, it seems everyone who is working on 0 A.D. is already doing the best they can with the time/expertise/interest they have. We have up and down periods of development, but I'm sure that would be the case no matter what high level decisions are made. And I'm constantly impressed by our community contributors who help us complete the game, they are dedicated, knowledgeable, and willing to take on technical challenges. Probably the "last resort" is to cut the features and aspects that at least bring 0 A.D. on a level with existing RTSes (e.g. multiplayer, AIs, naval warfare). Actually I see no reason why we can't go beyond many of them (since we don't arbitrarily limit ourselves) - which would be a coup for FOSS[oftware].

You say people won't play an incomplete game (which is debatable given how many people download our alpha releases - 120,000 downloads this year from SF alone, we could get Philip to generate updated usage stats to see how that translates into actual playing ), but are they more likely to play a game with substantially less features than the average RTS? Why? I think people don't mind playing an incomplete game as long as we update it regularly and each update provides a noticeable improvement. Further, open source communities seem to thrive when people are willing to use and test "incomplete" software.

A different approach to accelerating development could be to do it more openly. Many decisions seem to be made on the staff forums. Not that there is anything wrong in that but it prevents other folks from taking 'ownership' of that part of development. If it is decreed that triggers (say) can't make it into part 1 then people will tend to accept that. If on the other hand it is 'opened', like laid out on the forums - "how would you guys implement triggers if we were to include them in part 1?" - then people at least get the opportunity to think about it, talk about it and possibly even begin writing some code about it...

On the programming side of things, the staff forums are surprisingly little used. It's rare to have a technical/design discussion there. We much prefer active discussions in IRC, forums, and Trac. IRC logs are now publicly accessible so even that is open. Certain planning decisions are made in private because it's not really helpful to have everyone give input on every decision - some things are best left to the team to reach a consensus. Even those decisions tend to filter to the public view, leaving not much that is exclusively private.

The art side is a different matter, since they've had a certain approach that has worked well enough for years (likely from pre-FOSS days). They may re-evaluate that approach in the future for various reasons. We're basically all in favor of open development though

BTW, http://trac.wildfire...ayFeatureStatus makes it pretty clear (I hope) that not everything we want to do is listed because there are many minor features and bugs to be resolved (http://trac.wildfiregames.com/report/3 is just a taste), but also that it's not set in stone. I can't think of a reason why we'd outright reject someone contributing triggers for part 1, as long as it didn't distract from what we consider higher priority. And if everything else was finished, why would we delay part 1 for e.g. advanced water effects if that proved too difficult -- it's a low priority feature. So you see, it's fluid.

[zoot]

Can you give me an example of a decision that would not benefit from public input?

[historic_bruno]

Can you give me an example of a decision that would not benefit from public input?

Who said our decisions don't weigh public input? I'm sorry if that's what you take away from this discussion, as it's not true at all. It takes all of 30 seconds to create a new topic or post on the forum, and people are free to do so on any topic related to 0 A.D. Often a developer reads it and comments if they have time, sometimes it becomes a lengthy debate. In this way a number of things have already changed about the game, new features added and existing ones changed. It's not like you would be banned for opening a topic on triggers and debating their importance to the game If you made a strong enough argument, it might change the prevailing view.

Even if we put every decision to an open vote, I don't see it speeding development, I would expect rather the opposite. People are more likely to consider only their own limited personal preference and not, say, the resources the project has available, technical feasibility (some things are hard to explain/understand), and long-term goals. You'll just have to trust that the developers are reasonable and competent enough to make decisions on behalf of the community and for the good of the project, as evidenced by the results of those decisions

[zoot]

I was posing a genuine question not making a statement about what the developers' preferences might be.

[German Diago Gomez]

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

[German Diago Gomez]

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

[zoot]

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

Here is how this post was formatted:

[quote name='German Diago Gomez' timestamp='1339922651' post='242301']
I'm sorry about the format for the post :-)
[/quote]
[quote]
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
[/quote]

[German Diago Gomez]

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 outside commitments We're not organized like a game studio, maybe 8+ years ago it would have been good to take that approach, but back then we weren't FOSS either so it's a moot point.

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:

Edited June 17, 2012 by German Diago Gomez

[German Diago Gomez]

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.

There's nothing wrong with an evolving vision of the game. Some things you simply don't know whether they will work until you try them, and on closer inspection they may be a really good or really bad idea.

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 don't feel that we strictly need to "accelerate" development, it seems everyone who is working on 0 A.D. is already doing the best they can with the time/expertise/interest they have.

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 people won't play an incomplete game (which is debatable given how many people download our alpha releases - 120,000 downloads this year from SF alone, we could get Philip to generate updated usage stats to see how that translates into actual playing )

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.

The art side is a different matter, since they've had a certain approach that has worked well enough for years (likely from pre-FOSS days). They may re-evaluate that approach in the future for various reasons. We're basically all in favor of open development though

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.

BTW, http://trac.wildfire...ayFeatureStatus makes it pretty clear (I hope)

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.

Edited June 17, 2012 by German Diago Gomez