German Diago Gomez
-
Posts
18 -
Joined
-
Last visited
Posts posted by 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.
-
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.
-
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).
-
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.
-
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%
-
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.
- 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.
- Status visible in a single page (some kind of summary) -- Status of bugs, kind, etc.
-
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.
-
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.
-
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.
-
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:
-
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.
-
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.
- Ship ramming.
-
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.
- 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.
I look forward to your response. And... go on! the game looks promising :-)
- People won't play an unfinished game.
-
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
-
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
About the game roadmap
in Game Development & Technical Discussion
Posted
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.