Hi guys,
after reading a bit some posts in the forum, I am realizing more and more that the project lacks a big part of the DESIGN phase.
Let me explain.
In the last 4/5 topics I have read, I have always found discussions and posts about features and implementations of features in OC in a really mixed way.
For example in the topic related to the inventory system there are discussions regarding features of the systems, way of implementing them, interfaces, menus, buttons, down to the precise keyboard buttons that the user has to press in order to achieve.
Now. As I said in some past topics, I am not a real expert in game developing. But as far as it comes to software developing I have a lot of experience, and I can tell you that this method
1)doesn't work really well: it creates confusion and long-eternal discussions that are almost useless to the real development
2)will make some people unhappy and generate criticisms for people wanting different approaches to specific topics
What I propose:
First of all:
separate design from implementation. Before discussing how to implement something, everybody should agree (or at least know) on what to implement.
WHAT to implement, not HOW.
There should be a feature list of things that are willed to be inserted in the game, from a very high level point of view.
Things like "the user should be able to directly use a limited number of objects" instead of "the user should have two slots for using objects"
Thngs like "the user could use any object in more than one way" instead of "the user should have a modifier on ctrl,shift and alt to allow throwing an object"
Things like "the user should have an inventory to store many objects he can use, and he could switch the objects between the inventory and the list of objects directly usable" instead of "the user should have a ringmenu by pressing right click with blablabla"
When everybody agrees (or at least a decision is taken) on these high-level features, it is THEN possible to discuss about the best way to implement them.
All in all I am just talking about steps that are done in all software projects that involve a lot of people and features:
requirements analysis
analysis and design
and optionally some UML analysis: use case diagrams and use cases, feature lists, sequence diagrams, class diagrams, etc...
we need a high level view on the system that at the moment only few people possess, and this
-prevents new developers from easily joining the project
-will make the system much more difficult to manage when more and more features are added
Second
There should be a clearer place where to keep tracks of the features decided, the one to implement, the one implemented, etc.
I know that this for the average developer developing for fun on his free time is really really stressing, but we need documentation and we need to use the wiki
We need a place (the wiki) where to write what has been agreed upon, what is the state of the project, todos and stuff.
A post in the forum doesn't work. People can always reply, discuss, create so many delays..... we need a page on the wiki where we say
"ok, these are the features that we want for milestone 1. Nothing else. All the rest goes inside the ideas forum, and can be pickup up for roadmaps of future versions"
THEN
we can go on the forum/irc/whatever, discuss the best way to implement it. Then it's up to developer to implement it in the best way he can/thinks.
(and if possible, document afterwards on another page in the wiki the implementation of the feature, explaining to everybody what he did and why)
Considerations
Guys, I know this kind of proposals are boring and stressing, most of all when there is so much work to do on the code...
I know that it is just much more rewarding in jump in the code and implement a cool feature or effect.... I am myself tempted about this thing everytime I am doing a software project... you just want to code, and make the system work as soon as possible.. documentation and other stuff seems only to slow things down...
...but in my opinion these things are really necessary for:
-let everybody know and agree upon what is the direction of the project and what are the next steps
-spread the knowledge and attract more developers
-increase cooperation between developers
-avoid risks in later developing phases
It will time some time, i know, but I am sure that if we start doing it everybody will be happy that we did it in 6 months from now...
It will slow down things now, but will make them smoother later on
I think this community has great potential, we have many skilled developers, but we lack a bit of project managing. I see newton doing a bit this role, and I really appreciate it, but I guess we need a bigger effort in this direction.
Usually it's always overlooked as something that is not that useful, but believe me, in a few months it will make a huge difference...
after reading a bit some posts in the forum, I am realizing more and more that the project lacks a big part of the DESIGN phase.
Let me explain.
In the last 4/5 topics I have read, I have always found discussions and posts about features and implementations of features in OC in a really mixed way.
For example in the topic related to the inventory system there are discussions regarding features of the systems, way of implementing them, interfaces, menus, buttons, down to the precise keyboard buttons that the user has to press in order to achieve.
Now. As I said in some past topics, I am not a real expert in game developing. But as far as it comes to software developing I have a lot of experience, and I can tell you that this method
1)doesn't work really well: it creates confusion and long-eternal discussions that are almost useless to the real development
2)will make some people unhappy and generate criticisms for people wanting different approaches to specific topics
What I propose:
First of all:
separate design from implementation. Before discussing how to implement something, everybody should agree (or at least know) on what to implement.
WHAT to implement, not HOW.
There should be a feature list of things that are willed to be inserted in the game, from a very high level point of view.
Things like "the user should be able to directly use a limited number of objects" instead of "the user should have two slots for using objects"
Thngs like "the user could use any object in more than one way" instead of "the user should have a modifier on ctrl,shift and alt to allow throwing an object"
Things like "the user should have an inventory to store many objects he can use, and he could switch the objects between the inventory and the list of objects directly usable" instead of "the user should have a ringmenu by pressing right click with blablabla"
When everybody agrees (or at least a decision is taken) on these high-level features, it is THEN possible to discuss about the best way to implement them.
All in all I am just talking about steps that are done in all software projects that involve a lot of people and features:
requirements analysis
analysis and design
and optionally some UML analysis: use case diagrams and use cases, feature lists, sequence diagrams, class diagrams, etc...
we need a high level view on the system that at the moment only few people possess, and this
-prevents new developers from easily joining the project
-will make the system much more difficult to manage when more and more features are added
Second
There should be a clearer place where to keep tracks of the features decided, the one to implement, the one implemented, etc.
I know that this for the average developer developing for fun on his free time is really really stressing, but we need documentation and we need to use the wiki
We need a place (the wiki) where to write what has been agreed upon, what is the state of the project, todos and stuff.
A post in the forum doesn't work. People can always reply, discuss, create so many delays..... we need a page on the wiki where we say
"ok, these are the features that we want for milestone 1. Nothing else. All the rest goes inside the ideas forum, and can be pickup up for roadmaps of future versions"
THEN
we can go on the forum/irc/whatever, discuss the best way to implement it. Then it's up to developer to implement it in the best way he can/thinks.
(and if possible, document afterwards on another page in the wiki the implementation of the feature, explaining to everybody what he did and why)
Considerations
Guys, I know this kind of proposals are boring and stressing, most of all when there is so much work to do on the code...
I know that it is just much more rewarding in jump in the code and implement a cool feature or effect.... I am myself tempted about this thing everytime I am doing a software project... you just want to code, and make the system work as soon as possible.. documentation and other stuff seems only to slow things down...
...but in my opinion these things are really necessary for:
-let everybody know and agree upon what is the direction of the project and what are the next steps
-spread the knowledge and attract more developers
-increase cooperation between developers
-avoid risks in later developing phases
It will time some time, i know, but I am sure that if we start doing it everybody will be happy that we did it in 6 months from now...
It will slow down things now, but will make them smoother later on
I think this community has great potential, we have many skilled developers, but we lack a bit of project managing. I see newton doing a bit this role, and I really appreciate it, but I guess we need a bigger effort in this direction.
Usually it's always overlooked as something that is not that useful, but believe me, in a few months it will make a huge difference...
btw, I am one of this "external" developers wanting to join the project but finding many difficulties in the process... so I will try to help in document and analyze the biggest problems in doing it, so it can help others to do the same.
I will also try to create high level documentation of what I can understand on myself.
However since I never developed clonk code, a help for people that know the system would be really really appreciated
I will also try to create high level documentation of what I can understand on myself.
However since I never developed clonk code, a help for people that know the system would be really really appreciated
Another point that could help is using a source documentation generator like doxygen in the source code...
..maybe starting from the new classes/methods, and in the long-term expanding it...
but this is not completely necessary if a good standard documentation is available on the wiki
..maybe starting from the new classes/methods, and in the long-term expanding it...
but this is not completely necessary if a good standard documentation is available on the wiki
![[ua]](/mwf/flags/ua.png "Ukraine")
I totally agree. When some ideas appear on the forum they are at first heavily discussed and it usually ends with it (no further implementation). We really ned some "pages" where not ideas but general concept is posted. Then everyone will not what is done and how the things that are not done yet will look in the future. I suppose the thing you are suggesting should be named something like "centralisation". Just a brief example for reference (from my own experience):
- There's been a request of modelling a catapult object
- After some discussion I manage to make more or less adequate model.
- Since I am not good in 2D art (I mean, not good AT ALL), I made a UV-map and posted it to the forum hoping that someone more skillfull will help me with the texture
Then the question: How much time will pass since we remember that the model already exists and we do not need to make another one?
What if someone make (for instance) an inventory icon for a catapult and post it to the forum? It will probably stay there untill the catapult object is implemented and then... who will remember that there is already IS a catapult inventory item.
Not mentioning the documentation for the catapult explaining how and for what purposes it should be used. And so on.
(Do not think that the catapult is a big issue here - it was just an example of what can happen).
What I wanted to state is ... yes, I'm in. I also want everything to be done 100% perfect and since I kinda like to write different explanatory/manual/other docs I will gladly help with the documentation (if, of course, the idea is approved)
EDIT: About UML and other similar notations: you are right, the work on big projects in most of the commercial companies starts with a thorough planning/designing phase but it is not fit very well to the open-source approach (since a lot of people will want to create something rather than involve themselves in incomprehensible discussions where they miss most of the point). But yes it is necessary nevertheless. For example, we have a good c++ programmer who knows nothing about c4script and OpenClonk. It would be almost impossible for him to gain all the knowledge he lacks since he will have to start from the basics and do A LOT of practice (which will be in vain since he can not do anything usefull due to a lack of knowledge). I suppose with proper documentation on core OC objects (I mean objects in terms of Object-Oriented Programming) are used in OC and how they relate with each other will help him to (more) quickly reach the level of skilled developers/scripters. And graphical notations will surely help a lot.
![[de]](/mwf/flags/de.png "Germany")
I think, the way it's done in the moment is right.
The developers who are able to implement the objects and features, are the most capable people to decide which change is important or needs to be implemented in the moment.
It would be a catastrophy when you implement each idea that TheBuilder has in the forum.
The developers who are able to implement the objects and features, are the most capable people to decide which change is important or needs to be implemented in the moment.
It would be a catastrophy when you implement each idea that TheBuilder has in the forum.
No one talks about implementing every idea. But we need some list of ideas which would be implemented (and probably the list of ideas which would not).I keep thinking of situation when most of the core developers abandon project for different reasons. It would surely mean the death of OpenClonk (since new developers will know nothing about how things work there).
![[us]](/mwf/flags/us.png "United States")
I dont ask to have all of my ideas implemented, besides, how many times do I have to say that all I can do for now is make suggestions. Also what I suggest Is usefull for further consideration.
On teh subject of the topic, this is what Ive tried to do but failed miserably at.
On teh subject of the topic, this is what Ive tried to do but failed miserably at.
I agree, the devs should "drive" the development. I totally agree on this.
I am not talking about listening and discuss with whoever comes to openclonk.org, even for just an evening, and let that influence the project.
Nobody wants that, and that would be a suicide.
I am talking about helping to share knowldege about the project (past and future) to people that could really contribute and help, since at the moment they don't have a lot more than an engine developed for more than 15 years and with more than 450 source files to navigate through without any kind of help.
And
I am talking about trying to reduce eternal, useless discussions on the game's evolution by at least trying to divide features and implementation, and at least having a stated decision on the first ones (at least for the first release). Most of this doc is already available in newton's posts, it just needs to be recollected in a central structured page
All the rest will come step by step...
that's all :)
I am not talking about listening and discuss with whoever comes to openclonk.org, even for just an evening, and let that influence the project.
Nobody wants that, and that would be a suicide.
I am talking about helping to share knowldege about the project (past and future) to people that could really contribute and help, since at the moment they don't have a lot more than an engine developed for more than 15 years and with more than 450 source files to navigate through without any kind of help.
And
I am talking about trying to reduce eternal, useless discussions on the game's evolution by at least trying to divide features and implementation, and at least having a stated decision on the first ones (at least for the first release). Most of this doc is already available in newton's posts, it just needs to be recollected in a central structured page
All the rest will come step by step...
that's all :)
But my experience is that the engine is very easy to overview when you read into some headers.
To find the place, where a feature has to be implemented is even more hard, but it's not impossible.
You could continue writing the engine just by having the source code but no one who knows the single parts of the source.
To find the place, where a feature has to be implemented is even more hard, but it's not impossible.
You could continue writing the engine just by having the source code but no one who knows the single parts of the source.
I am not an experienced game programmer, I am just a software programmer, so I don't ask you to take my experience completely in account,
however I had a few looks at other opensource projects (a couple of games as well, especially wesnoth) and for me there is a huge difference in the source code between the two projects. I am not comparing a project just born with the huge success of wesnoth, but still I see in OC engine:
-a lot of low-level classes, objects and methods that are not really necessary
-a lot of legacy code
yes, it is possible to navigate through the source on your own, and that's what I am trying to do... but to define it as a "very easy" experience in my opinion is a bit too much, most of all compared to other projects and normal standards for opensource coding
So yes, I can live with it, but I still think that some efforts in helping documenting and simplifying the code could really help people trying to join the project and give them a boost in reaching a level where they are useful and productive
however I had a few looks at other opensource projects (a couple of games as well, especially wesnoth) and for me there is a huge difference in the source code between the two projects. I am not comparing a project just born with the huge success of wesnoth, but still I see in OC engine:
-a lot of low-level classes, objects and methods that are not really necessary
-a lot of legacy code
yes, it is possible to navigate through the source on your own, and that's what I am trying to do... but to define it as a "very easy" experience in my opinion is a bit too much, most of all compared to other projects and normal standards for opensource coding
So yes, I can live with it, but I still think that some efforts in helping documenting and simplifying the code could really help people trying to join the project and give them a boost in reaching a level where they are useful and productive
you have to take your time to discover the source, but it isn't impossible
I agree carli :)
I am not saying it's impossible....
I am just saying that it could be easily improved, at least in the documentation.
Without doing anything huge... just a couple of really high-level system diagrams, and a couple of lines that describes the core parts and the more important subsystems... like for example it took me 1 hour before understanding what c4group was for by simply going to and from several classes and understanding their flow, it could have been 5 minutes by just having a couple of line stating that it's the game's packaging format to store resource files together..
I am not saying it's impossible....
I am just saying that it could be easily improved, at least in the documentation.
Without doing anything huge... just a couple of really high-level system diagrams, and a couple of lines that describes the core parts and the more important subsystems... like for example it took me 1 hour before understanding what c4group was for by simply going to and from several classes and understanding their flow, it could have been 5 minutes by just having a couple of line stating that it's the game's packaging format to store resource files together..
Well, I did something like that in a forum post and was met with zero feedback. I could also show you my diagrams of the structure of the networking code. Both were a lot of work and had very limited impact, from what I can tell.
I guess the problem is that it's very hard to tell what a newbie needs once you are "inside" and everything just seems trivial. Right now, I think being available for questions and reviewing patches is the best way to helping them learn the ropes. Well, maybe when enough newbies have gone through the process we get to the point where it seems like a good idea to aggregate a few posts into a comprehensive newbie guide. But right now that's not the case.
I guess the problem is that it's very hard to tell what a newbie needs once you are "inside" and everything just seems trivial. Right now, I think being available for questions and reviewing patches is the best way to helping them learn the ropes. Well, maybe when enough newbies have gone through the process we get to the point where it seems like a good idea to aggregate a few posts into a comprehensive newbie guide. But right now that's not the case.
I don't think you can judge the feedback received on a forum post between many others, especially when you care about the feedback of newbies coming from other places...
I think that very very few people (if someone at all) coming to the website and seeing that it is an opensource project, will ever try to find some technical document to read between hundreds post in a forum, where the average discussion is "hey guys, I got an idea, why don't you put space nuclear sheeps with laser rifles in the game?"
believe me the same exact post you did, (that I didn't have the chance to see before to be honest), put on the wiki could have a really big difference in impact and usefulness...
Even if just me and 2-3 more newbies would read it, it would help the project. And by the way the main loop is exactly what I was looking for 2 days ago when I started looking at the code, and it took me 2 hours to find out all the connections between the varius classes that I could so easily get just by reading your few lines...
You say that the problem is that when you are inside you are not sure of what a newbie really needs... why don't you try to listen to one of them? I am not asking for 5 hours of work to each developer, I am asking for a couple of wiki pages with some high-level structure....
The risk is not that newbies will get more time to "get into it", but that no newbies will be interested at all, since they don't have years of experience and love in the clonk world and they won't get passioned if you don't give them a hand in understanding what's going on.
And by the way, by always waiting "future" for starting doing this kind of things, you are just delaying and delaying without ever starting, accumulating more and more stuff to document and just increasing the problem at the end...
I think that very very few people (if someone at all) coming to the website and seeing that it is an opensource project, will ever try to find some technical document to read between hundreds post in a forum, where the average discussion is "hey guys, I got an idea, why don't you put space nuclear sheeps with laser rifles in the game?"
believe me the same exact post you did, (that I didn't have the chance to see before to be honest), put on the wiki could have a really big difference in impact and usefulness...
Even if just me and 2-3 more newbies would read it, it would help the project. And by the way the main loop is exactly what I was looking for 2 days ago when I started looking at the code, and it took me 2 hours to find out all the connections between the varius classes that I could so easily get just by reading your few lines...
You say that the problem is that when you are inside you are not sure of what a newbie really needs... why don't you try to listen to one of them? I am not asking for 5 hours of work to each developer, I am asking for a couple of wiki pages with some high-level structure....
The risk is not that newbies will get more time to "get into it", but that no newbies will be interested at all, since they don't have years of experience and love in the clonk world and they won't get passioned if you don't give them a hand in understanding what's going on.
And by the way, by always waiting "future" for starting doing this kind of things, you are just delaying and delaying without ever starting, accumulating more and more stuff to document and just increasing the problem at the end...
btw.. I realized that I did read that post, since I am the only one with Newton that replied to it hehe..
You see what I mean? I am really interested in that post, that's exactly what I was looking for 2 days ago, and I didn't even remember that I read it in the past...
Why? Because it is a post in a forum, written on last july, when I was in the last holiday as a student in my life, and not having the time to appreciate it...
You cannot pretend that such a thing is comparable to an introduction page on the wiki...also because on the wiki it could be a starting point to start expanding it and put more useful details and news...
now that I have the right time if that would have been in the wiki I would surely use it and maybe expand it with the things I am starting to get on my own...
You see what I mean? I am really interested in that post, that's exactly what I was looking for 2 days ago, and I didn't even remember that I read it in the past...
Why? Because it is a post in a forum, written on last july, when I was in the last holiday as a student in my life, and not having the time to appreciate it...
You cannot pretend that such a thing is comparable to an introduction page on the wiki...also because on the wiki it could be a starting point to start expanding it and put more useful details and news...
now that I have the right time if that would have been in the wiki I would surely use it and maybe expand it with the things I am starting to get on my own...
that's exactly what I will do... but right now I am at that little happy sunny place called "work"...
> I am not asking for 5 hours of work to each developer, I am asking for a couple of wiki pages with some high-level structure....
I think you are greatly underestimating the time required to build good documentation. And don't even get me started on the issue of keeping it up-to-date. The main loop situation changed dramatically from CR, for example.
> why don't you try to listen to one of them?
Everybody's open for anything that's more specific than "explain me everything". If you have some good questions, post them and we might look whether we can build some comprehensive answers.
> accumulating more and more stuff to document and just increasing the problem at the end...
This "accumulation" has been going on for years, so any development effort now isn't going to increase the problem significantly. And see above, having superfluous documentation is an equivalent thread.
>I think you are greatly underestimating the time required to build good documentation. And don't even get me started on the issue of keeping it up-to-date. The main loop >situation changed dramatically from CR, for example.
I am not underestimating. I already documented software more than once, and I know that the effort required is great.
But I also know that to put down a high-level summary of a few pages is quite easy instead if you have good knowledge of the system.
I only think that the greatest effort is start doing it. After doing it is not that big deal.
And I think you are greatly underestimating the time that something like that can save to all the people that can potentially be in the situation of having to learn the system.
A person might lose a few hours, but it makes 5,10,20 gain many more
And even outdated documentation can be a wonderful starting point. We don't have to go in details here, we just need to give initial hints to people that doesn't know anything about the system...after it's up to them to keep on from there
>Everybody's open for anything that's more specific than "explain me everything". If you have some good questions, post them and we might look whether we can build some >comprehensive answers.
True, and I will, don't worry :) Just give me a few times to have the chance to have an appropiate look at the system... after the easter holidays I will surely start asking around and putting some answers on wiki
>This "accumulation" has been going on for years, so any development effort now isn't going to increase the problem significantly.
That's wrong. It doesn't increase the problem significantly from one day to another. There's no difference in starting today, tomorrow or in two weekes.
But if nobody starts to do something to go in the right direction, one year from now we will be in the same exactly situation...and the difference anyway will be there.
Moreover in the past years the development team was closed. The people working on the engine was a very small group, and very closed to each other.
This is an opensource project... in one year or maybe two hopefully there will be many people willing to contribute... and i don't think is really appropiate to wait until that precise moment to start thinking about how to handle it and help them.
>And see above, having superfluous >documentation is an equivalent thread.
There is good documentation and bad documentation, but there is no superfluous documentation. Most of all in projects of this type. As said, even an outdated wiki page could be a wonderful starting point even if next month game->execute() will be changed in superGame->execute().
I doubt that all the major engine subcomponents will be completely transformed, all at the same time, and all in a couple of months.
>In general
I think I am still being misunderstood here..
1)I know the project is young
2)I know the team is small
3)I know making documentation is boring and steals time and energy from developing
4)I agree that at this time of the project, the priority should be the development and situation should be kept similar to the one we have
BUT
I am just asking for a little cooperation in creating a minimum set of resources (wiki pages) in order to put me and the other's that are or will be in my situation in the condition to be more helpful in faster way...otherwise for every little thing we will need to ridiscover everything on our own..... I can do it, it just that it takes so much time in comparison to how it could be with a little resources to look at
> I doubt that all the major engine subcomponents will be completely transformed, all at the same time, and all in a couple of months.
Well, they were. Not all of them, obviously, but we often move around large blocks or even programming paradigms (some people want to use boost now o_O). Having a lot of documentation will probably quickly end up being seen as a massive hinderance. Especially if it's not part of the source code.
Concerning cooperation - no doubt you have noticed that I am the only engine coder so far that has commented on the issue. And I'm not even particularly active in the newer development efforts. Good reasons won't take you far, as you can't force anyone to do anything just because it's the right thing to do. In an open-source project you need enthusiasm, or nothing will happen. To generate that, you need feedback, and writing some text without anyone acknowledging it is the worst-case scenario for that. It's just not a fun thing to do.
>some people want to use boost now o_O
I don't dislike the idea :p
>Having a lot of documentation will probably quickly end up being seen as a massive hinderance.
The point is: I don't want people to generate a LOT of documentation right now, and probably for a long time.
Again: I just would like some starting drafts that describes really general stuff: where the main loop is, what are the main components in the drawing subsystem, how the GUI is organized in the engine (main things: the c4startup set of classes, who calls them, etc), what c4group does, what C4control does (in a short description), where the scripting language rules and functions are, etc... It requires an evening to do that, not more. There is always time to add details, clarify things and etc. But it is important to start.
This kind of things even if they change position or name, are core components of the engine and to understand their purpose and their connection with the rest of the engine is already a huge improvement... and I don't think it requires more than 2 to 3 word pages...
>Concerning cooperation - no doubt you have noticed that I am the only engine coder so far that has commented on the issue. And I'm not even particularly active in the newer >development efforts. Good reasons won't take you far, as you can't force anyone to do anything just because it's the right thing to do. In an open-source project you need >enthusiasm, or nothing will happen. To generate that, you need feedback, and writing some text without anyone acknowledging it is the worst-case scenario for that. It's just >not a fun thing to do.
I completely agree on this.
As i said, good reasons and some posts on the forum won't change anything.
That's the reason I will start the work by myself. I just need some free time (all this and next week I will be pretty busy between work and holidays) and some time on the system in order to get a general idea.
After something is there, I hope (I am an optimisitc guy, what can you do about it... ) that some nice guy will maybe correct the mistakes or add a few things... who knows...
I think there is no more need to convince someone whether we need docs or not. We need them. It looks like PeterW is just skeptic about the extent of it. Nobody doubts that we need some docs/graphs (Peter mentioned something about that he already created such a thing?) about the basic functioning of the engine. Also as a starting point for more exhaustive documentation.I think when the platform for engine documentation exists, others (than Peter) will help with that too. Only this discussion about the sense or nonsense of docs of the engine doesn't get us anywere.
I suggest that you create another topic in the forum about the specific implementation of how the docs should be structured (now, wiki or not? Or perhaps javadoc-alikes? - we had some discussion about that already though) or well, just start a wiki page in the wiki which can be used as a start. And then we will see.
You know, your tutorial how to set up openclonk for Visual C++ was super-helpful for me and I am very sure for many many other people, too. I think you underestimate how that kind of stuff helps the (future) development just because one 1. can't see the results immediately and 2. there is no direct feedback to that. But there is normally no direct feedback to if you solve a bug or build some awesome feature, either.
![[ca]](/mwf/flags/ca.png "Canada")
Agreed, I would never have compiled OpenClonk without that.
>are at first heavily discussed and it usually ends with it (no further impmber lementation)
You always need to note who is posting and who is discussing those ideas, concepts etc. There are people who just post their ideas and do not intend to implement anything, just want to give some input. They don't expect this to be implemented and the devs... or well the people who would implement it may note it and discard the idea. If the concept is interesting enough, if will surely be implemented or talked about in more detail. As for me, often I don't even join into discussions of ideas that I deem unfitting anymore (e.g. stamina bar discussion).
> catapult
Your catapult is not forgotten. The model is ~done and we know, that just the uv map and texture is missing. However currently it doesn't look like it will get implemented in the game soon so there is no haste to do the texture or: there are other things that are more important currently. Just as the modelling and texturing on buildings has been postponed (remember the lift tower?). However I agree with you that it is a pity that noone continued the work on the catapult after the model was done. But at least the capacity of the dev team is limited and the forum crowd is a fickle lot ;-)
Well, maybe a catapult example was not that good after all (for I am perfectly aware that it is a bit early for it). What I wanted to tell... oh, I remeber. I liked this post of yours very much because from it we could see which features (of the earlier requested) are done already and which are yet to be done. A simple glance on a page like this can tell any dev/artist/scripter where additional effort should be but. I think we can create something... a wiki page maybe where all good ideas from the forum are transfered (to make sure they are not lost among dozens of other forum posts).
agreed... if nobody else goes for it first, i will try to setup a couple of wiki pages (I am not sure I have the permissions, I will try anyway :)
First of all, thanks for your input. This is the kind of thing the project needs and which will help the project a lot.First to give you some context: The last few topics I posted about inventory concept(s), gui rework etc. basically were a summary what we discussed at the OC meeting last week with the requirements that have to be implemented (into the engine) for the things that where agreed upon. It is true that I mixed parts that were solid concepts and parts that were open issues and requirements / implementation details in the post; simply because it was taken from the same plenum discussion. The final concept doesn't get decided in a discussion in an open board. I posted the concept and it's open issues in there because to get some input on the open issues and how to best solve them. Also I got to say that the concepting seldomly take place in the forum so don't assume there is none.
I know that a design phase is part of any professional software development project as it is necessary to first set the requirements to be able to design according to these requirements. While this greatly affects the quality of the product, it creates an enormous overhead and as you say - is not really that kind of work that people do voluntarily of their on accord. My experience is that in (open source) projects where the people contribute because they like to do it, it is very hard to get anyone to do concepting on their own initiative.
It takes lots of time to write these specifications and is boring to read them ("we need to be able to access a limited amount of items in the inventory fast" ... oh, really? You don't say!) so there won't be much feedback on that.
Not explicitly writing those requirements down also does not mean that the person didn't think it through and didn't take these requirements into account. Currently I trust anyone on the dev-team to be reasonable and intelligent enough to not design bullshit and implement it without consultation of the rest of the dev-team. After all, it is us who got the last word on how something will get implemented (or not) so even if a lot of random stuff pops up in the forum, it does not mean at all that it will get implemented in that way (or at all).
A big overhead for concepting and designing makes sense if you got many people working on the same system of mutual dependencies that have to agree on one way to do it to not run in completely different directions. However the number of people actively involved in the project is actually pretty small for the number of different areas on which we work (from engine development over content development to texturing and animation).
For example I am currently the only one who is working on the controls (script side), Sven2 is implementing some additional features that are needed for the controls to work engine-side. Much of the actual concepting and discussion about implementation details is only done between 1-2 people who are actually involved in it. Almost every engine developer has his own special thing that he is working on alone so agreements are not really necessary and not really possible. The cohesion in the team is very low which makes it difficult to put together a coordinated and agile development.
A problem of the clonk development - if you want to call it a problem - is that there is not so much of a flexible team that can be coordinated easily to work together on this for one week and after that on that for a week. For the content development, I tried my best so far to coordinate the content development but regettably it turned out to be pretty top-down (imo) which I really not intended. (Also read this - esp. the last paragraph)
I think the methodology that is fitting best for our situation, roundup and of course the status as a (OS) hobby-project is rapid prototyping ?: Get fast to working prototypes but be ready to dismiss these again quick if it turned out to be unfitting for a particular problem. So this results in short iterations in an incremental development rather than big concepting work with completely thought through designs before the implementation began in the first place which will never be implemented because the responsible people are gone. I believe in early phases of (open) clonk development, we have to go through an exploring phase to test out in what direction we go and thus what our requirements are.
Independent of what I wrote I got to say: You are very right and I agree with you on most points. And I am both glad that someone and that you brought up this topic (as I value your opinion very much). And as I said, up till now I (but also some others in the team) tried my/their best to make things easier for people that want to join the project and to make and publish many concepts, decisions, todos etc. to give new contributors an idea what our goals are and what is still to do until the next milestone. You say that you are one of these "external" developers wanting to join the project but you can't really catch up. Well, what you talk about is exactly what we (imo) need, to create this kind of culture, higher cohesion, project management etc. in the project that will help the project long-term and inspire the people working on it. But it takes somebody to pull it through. So if you searched a position in the team, I think you found it!
I suggest that you join us in the IRC on the next meeting which will be on next monday 19:00 CEST if we do not decide on an earlier date. (P.S: You in Germany now?)
wao, epic post, you have put a lot of stuff there...let's see if we can summarize a bit
I understand the point. I truly do. I know what there is in the mind of a young developer shaping its project... most of all in such a cool thing like a game project.
I understand why the situation evolved naturally to an agile prototyping method, and after your explanation (but also by reading and following the community since a long time, even if in the last few months I couldn't be that active) I get the point of how the team works.
Moreover this is the typical situation of an opensource project as you say, so nothing really new on this. Indeed openclonk is a really lucky project, because even if with few developers, the developing is proceeding fast, probably because of the nice skills and talents we have in our dev team, and in their previous knowledge of the engine.
I probably didn't express myself in the most clear way in the first post, in order to signal the problem with some kind of strength. However while I was writing those words I had in my mind a situation similar to the one you describe.
So I know and I totally agree on the fact that to load the dev with a huge amount of doc and analysis to do, most of all at this early stage of the development process, is not something useful to do (and realistic to accomplish).
However in my opinion some steps in the "right direction" could be taken anyway, without killing nobody's willing to live.
Something like creating a high level diagram of the engine core and its subsystems.
Something like creating one wiki page with your TODO forum post as a base, and just a little (little!) more detailed.
Something like a little documentation on the biggest steps already taken or to take in the next future (mesh rendering for example, or the new control systems).
Most of the stuff is already there, somewhere in the forum, somewhere in the old doc, somewhere in some dev's head.
I am not asking for an official IBM documentation on the project that somebody could pay 250.000E for. I am asking for something related to the size, scope, and target of the project (and to the dev's free time and will to do something on this direction).
I understand most of your points, and again, I agree. But try to understand that if people from outside,maybe coming from other opensource projects as well, can manage to start helping the project, after the advantages will be great:
-larger playing community
-faster development
-wider expertise and skill sets of the dev
-cancel the risk of some core dev leaving the project without handover
It's all about having one stament in our head: OC is now an opensource project, and for this reason is a project that should be followed by a community, not by 4-5 individuals...
Thanks god we have these individuals, without them nothing would exist, but sooner or later the project will have to expand to a wider community, or it will die.
And as I see, the only way to help it expand, is through doc. step by step, little by little... but starting is important...otherwise other 6 months will pass and nothing will changed, and the more the time passes, the more it becomes difficult to start.
first thanks for the last words, they are appreciated :) and I appreciated a lot your efforts (and the other's ) to document and talk to the community about what is going on, and to manage the project at least at a minimum level. You might think you didn't do a lot, but you did REALLY a lot.
Second: thanks for the proposal..and I might catch it up :)
My only problem is that the next 2 months will be a bit chaotic for me (I am trying to change job, change country,and go living with my GF at the same time... KABOOM!).. however I really want to start helping (I remember I promised a long time ago that sooner or later I would have helped... and I don't want to be one of those guys that talks talks and never delivers).
So for the beginning I might not be able to really take completely the role, but I will try what I can to start going in the direction I am talking about. First of all I am trying to get some starting knowledge of the engine and the project status (I downloaded the source tonight to start doing it). While I try to do that, I will try to put down some documentation on the engine and on everything else I can discover on my own. Surely a little cooperation would be welcome, but I guess that I can already start on something (maybe that high-level class diagram I was talking about).
The more free time I will find, the more I will try to do... and hopefully in a couple of months I will be able to contribute regularly. However for the moment the situation is like this..we will see
For the IRC meeting: I will have to skip the next one (first days of holidays of work since christmas, going back to italy to see my family), but I will try to join the next ones (work permitting)
(p.s: yes right now I work in dusseldorf since last october. however I am trying to move to the netherlands since my girlfriend lives there, so this might change soon :p )
>First part regarding the actual development team methodologies and the team itself.
I understand the point. I truly do. I know what there is in the mind of a young developer shaping its project... most of all in such a cool thing like a game project.
I understand why the situation evolved naturally to an agile prototyping method, and after your explanation (but also by reading and following the community since a long time, even if in the last few months I couldn't be that active) I get the point of how the team works.
Moreover this is the typical situation of an opensource project as you say, so nothing really new on this. Indeed openclonk is a really lucky project, because even if with few developers, the developing is proceeding fast, probably because of the nice skills and talents we have in our dev team, and in their previous knowledge of the engine.
I probably didn't express myself in the most clear way in the first post, in order to signal the problem with some kind of strength. However while I was writing those words I had in my mind a situation similar to the one you describe.
So I know and I totally agree on the fact that to load the dev with a huge amount of doc and analysis to do, most of all at this early stage of the development process, is not something useful to do (and realistic to accomplish).
However in my opinion some steps in the "right direction" could be taken anyway, without killing nobody's willing to live.
Something like creating a high level diagram of the engine core and its subsystems.
Something like creating one wiki page with your TODO forum post as a base, and just a little (little!) more detailed.
Something like a little documentation on the biggest steps already taken or to take in the next future (mesh rendering for example, or the new control systems).
Most of the stuff is already there, somewhere in the forum, somewhere in the old doc, somewhere in some dev's head.
I am not asking for an official IBM documentation on the project that somebody could pay 250.000E for. I am asking for something related to the size, scope, and target of the project (and to the dev's free time and will to do something on this direction).
I understand most of your points, and again, I agree. But try to understand that if people from outside,maybe coming from other opensource projects as well, can manage to start helping the project, after the advantages will be great:
-larger playing community
-faster development
-wider expertise and skill sets of the dev
-cancel the risk of some core dev leaving the project without handover
It's all about having one stament in our head: OC is now an opensource project, and for this reason is a project that should be followed by a community, not by 4-5 individuals...
Thanks god we have these individuals, without them nothing would exist, but sooner or later the project will have to expand to a wider community, or it will die.
And as I see, the only way to help it expand, is through doc. step by step, little by little... but starting is important...otherwise other 6 months will pass and nothing will changed, and the more the time passes, the more it becomes difficult to start.
>second part: about agreeing with me
first thanks for the last words, they are appreciated :) and I appreciated a lot your efforts (and the other's ) to document and talk to the community about what is going on, and to manage the project at least at a minimum level. You might think you didn't do a lot, but you did REALLY a lot.
Second: thanks for the proposal..and I might catch it up :)
My only problem is that the next 2 months will be a bit chaotic for me (I am trying to change job, change country,and go living with my GF at the same time... KABOOM!).. however I really want to start helping (I remember I promised a long time ago that sooner or later I would have helped... and I don't want to be one of those guys that talks talks and never delivers).
So for the beginning I might not be able to really take completely the role, but I will try what I can to start going in the direction I am talking about. First of all I am trying to get some starting knowledge of the engine and the project status (I downloaded the source tonight to start doing it). While I try to do that, I will try to put down some documentation on the engine and on everything else I can discover on my own. Surely a little cooperation would be welcome, but I guess that I can already start on something (maybe that high-level class diagram I was talking about).
The more free time I will find, the more I will try to do... and hopefully in a couple of months I will be able to contribute regularly. However for the moment the situation is like this..we will see
For the IRC meeting: I will have to skip the next one (first days of holidays of work since christmas, going back to italy to see my family), but I will try to join the next ones (work permitting)
(p.s: yes right now I work in dusseldorf since last october. however I am trying to move to the netherlands since my girlfriend lives there, so this might change soon :p )
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
