Print

Crazy Penguins 0.4 – 100lt
IP: 114.134.0.138
Game Mode: Team Death Match
Lives: 0
Max Kills: 15
Version: OpenLieroX 0.58 rc3

Players:
[CPU] Kamikazee!(0 lives, 0 kills)
[CPU] Worm(0 lives, 0 kills)
[CPU] K1ll0r(0 lives, 0 kills)
[CPU] Dummi(0 lives, 0 kills)
[CPU] N00b(0 lives, 0 kills)
[CPU] N00b(0 lives, 0 kills)

Cruel v0.96 – 40lt
IP: 98.218.156.136
Game Mode: Death Match
Lives: 5
Max Kills: 0
Version: OpenLieroX 0.58 rc3

Players:
The White Ninja(0 lives, 0 kills)
WK|1|Gyrspo (2 lives, 3 kills)
GMANATOR(1 lives, 4 kills)

[RuNyoufool]

So, guide the community Run:

Active      Inactive
From our side we can provide structured development

I think i have tried to motivate the devs to start defining milestones, use issue tracking efficiently and work towards a fixed cycle of defining functionality for a milestone and sticking to that, using the issue tracker coupled to milestones and trying to set release dates (even if they are never met, it's good to have something to aim at), taking the time to test with a fixed group of testers on the different platforms, and releasing a stable non-beta version at least every once in a while. None of this has been picked up. Without it, i don't see any real progress happening, because you are working with a team > 2, which always needs management.

I don't want to be all negative here, you guys work your ass off (as have i) but it's a tad disappointing to see there's not a general willingness to build something that has a bigger scope than people's personal programming challenges.

[pelya]

Hm, okay, we have release date set to 3 days ago, we already increased release rate, you may call Beta3 and Beta5 stable releases, and we expecting that Beta8 will be good enough to call it stable release too.
And recently I've made Vote for feature thread, and going to implement only the most rated features (or lower rated if they take much less time).
And we need stable beta-testers group for a while already, for now we're testing everything by ourself, and getting bugreports from users only when we've made release.
BTW who will decide milestone release? Which features should it include? Should it be, say, top-3 of Vote for feature poll, or maybe just one feature, considering the amount of work each feature will require? Or maybe just release half a year or once per 3 months?

[RuNyoufool]

Hm, okay, we have release date set to 3 days ago, we already increased release rate, you may call Beta3 and Beta5 stable releases, and we expecting that Beta8 will be good enough to call it stable release too.
And recently I've made Vote for feature thread, and going to implement only the most rated features (or lower rated if they take much less time).
And we need stable beta-testers group for a while already, for now we're testing everything by ourself, and getting bugreports from users only when we've made release.
BTW who will decide milestone release? Which features should it include? Should it be, say, top-3 of Vote for feature poll, or maybe just one feature, considering the amount of work each feature will require? Or maybe just release half a year or once per 3 months?

The point I want to make is that you should start planning ahead instead of day-to-day. I think you should look at the time it takes to implement a feature, how it relates to other functionalities and if it is a useful thing to add for that milestone. I can see so many crucial things that are currently missing in OLX that implementing the mostly-for-fun features that are requested by the community can easily wait until you have the desired base to work from.  Tweaking high-level, visual stuff off course gives short-time satisfaction to the community, but in the long run you don't gain much from it if the basis is not sound.

Milestones should reflect some vision of where the project is going in the future. For 'Hirudo' the first one could be a rewrite to make code more modular and provide basic methods (i think that's already done), second milestone could contain new optimized netcode (Pelya is gonna work on that if im correct) and a new scripting and modding system - ideas borrowed from gusanos (right?) + physics engine, 3rd one will implement a renewed user interface, but this is the point where you have to know exactly what the game will look like and which elements you want to keep from the current game and what functionality is going to be added in the future.

That's just my view on things. But i don't know what the current state of OLX/Hirudo is. Writing down plans for discussion could help anticipate on unforeseen things (since you can get imput from different groups - (designers, creative developers and developers)).

[Captain Nack Sparrow]

You could simply add some aims here on LXA, like the allied clans. This was a great idea but as I heard a clan is not able to get allied anymore?

[albert]

We don't have the modding features that Gusanos has, [...].

That is a TODO.

We don't have 24/7 quality dedicated servers that could attract a fixed number of players and provide a good gaming opportunity around the clock;

The dedicated server still does not work perfect, but it got a lot improvements since we introduced it and it is much more stable than earlier.

Can you provide us with a server were we can start a dedicated server? Atm I am running the dedicated server always at the server at my parents house, but bandwidth is very limited there and I host a lot of other things there too and my family and I also use the same connection for surfing, therefore I can only provide up to 20kb/sec upload there for OLX. Also, my connection has a force-reconnect (and IP change) after 24h.

If you have a possibility there, please install an acount for me and send me the acount-data via mail. It would be nice to have a server with a good internet connection for testing the dedicated server. It does not need a X-server but you should install the other dependencies (see DEPS file).

We don't have a structured development effort going, there are no real milestones set and issues/tasks aren't managed.

Of course we don't have real milestones (or I am not sure if I got what you mean by that). This is an open source project and we are all doing this for fun in our spare time. And I probably will not work on features I am not really interested in. That is how open source works (if there is no company paying anybody behind): Everybody works on the stuff he is interested in and people share the work and the project grows. If there is no developer interested in some (non-trivial) feature, it is very unlikly that it is going to be implemented. If anybody is uncomfortable with that and really wants to have a particular feature, then why not helping us and implementing it yourself?

But we do have managed tasks. We have the feature request tracker and the bug tracker for that.

Even if countless hours have been put into it, what has come out is pretty much the same game with some added functionality [...].

Exactly that it what the (LXA) community always wants: The *same* game with new features. Therefore we are implementing new feauteres which makes the game different in a way that you can choose, if you want to have the behaviour of the original game or if you want to have the new behaviour.

I think there are already a lot of features which makes the game different if you enable them.

A lot more of them, which would make the game very different, are stated in the feature request tracker.

It's sad because i see people put in so much effort, but most of it is put to waste

Which effort we did was wasted?

(keeping compatibility with an ancient buggy game as a top priority for more then 2 years now.. [...])

Why dropping compatibility if it is not needed and gives no advantages?

Btw., about what compatibility are you talking exactly here?

Maps? Why should we remove the support for the old maps?

Mods? Why should we remove that support?

Network protocol/engine? Why should we remove that? And btw., the network protocol was already extended a lot and the new OLX protocoll is different and extended in each new release. It's just not a big deal to keep compatibility. And a completly new, independent network engine is also planned by pelya.

Network channel? There is already a new one since Beta5. And we will implement another new one for Beta9 because we have figured out some other issues here. And there is also still the old one. But why should we remove the old one? (The game automatically selects the best channel implementation when you are connected.)

Config files and the general structure of the game files? I don't see any important need of changing something here.

[albert]

I can see so many crucial things that are currently missing in OLX [...]

Which ones? Please fill them in the feature request tracker.

[...] make code more modular and provide basic methods (i think that's already done)

That is way unprecise! We still have a lot of old/bad code in it and it is always an ongoing work. And I don't think that we will ever get rid of all old code. But really a lot of work was already done here and I feel much more comfortable with the current code than it was in the beginning.

second milestone could contain new optimized netcode (Pelya is gonna work on that if im correct)

It was optimised in almost each release. And a new network channel implementation from scratch was introduced in Beta5 and there will be another one in Beta9 or so.

Pelya was planning to make a complete new network engine. We will not remove the old one when he is finished with that. The user will be able to choose what network engine he want to use. We are even not exactly sure about how good Pelyas ideas for the new network engine will work in practice (there will be some disadvantages to the old network engine in performance and perhaps other things), but even if it works perfect in all possible ways, why should we remove the old engine?

a new scripting and modding system - ideas borrowed from gusanos (right?) + physics engine

This is pretty much in planning state yet. I am also very much interested in that and if I have some more time (perhaps in summer next year or so), I will work a bit on that.

a renewed user interface

This is a work-in-progress. I am not sure about the current state but I think it is still unusable. It's a big amount of work and I don't know when it is ready. It is already in Beta8, you can try it out via command line parameter. (Ask Karel for details.)

[renewed GUI], but this is the point where you have to know exactly what the game will look like and which elements you want to keep from the current game and what functionality is going to be added in the future.

A good GUI should be flexible and allow possible extensions. There will always be extensions and new features. You don't have to know exactly what the game will look like. And you are also never able to know that.

[RuNyoufool]

it's all about priorities, Albert. As i understand it a LOT has been happening under the hood, which is encouraging, but in 2 years time there haven't been any major new features introduced. I'm mainly talking about modding possibilities as described before and getting all clients to use the same protocols (force them to upgrade to newest versions).

About choices. You shouldn't give all the choice to the user, he doesn't want that and can't make the right ones (user doesn't give a damn about networking layers, etc, he just wants a game that works without unexpected behaviour), therefore some things should be chosen by the developer. There's no reason at all to introduce multiple networking / physics / whatever layers (other then maybe a nice programming challenge). just force people to upgrade, they will. Then all efforts could be pointed to stuff that matters: great gameplay, the best possible network syncing and great opportunities for mod and level builders.

About milestones, they are a GREAT help in deciding what will make it into the next release, and having a good focus point for all developers towards something that you can be proud of.

About the user interface: Creating one is an challenge in itself. I'm not talking about providing the tools to make one, but designing the interface itself (placing the right panels/options in the right places, make it work with different resolutions, use scalable graphics, make sure that advanced functionality is seperated from basic in a logical way, etc). You can't underestimate such a task (developers are typically not interested/capable to/of building a decent UI).

I understand that this is something that people do for fun, but when you are putting so much time in it, why not use some of the proven methods to make things a bit more structured? There are many open source projects that use them succesfully.

I'm pretty sure that a lot of time has been 'wasted' working around the old LX code or finding solutions for very weird problems that happened because the code wasn't easy to understand. Don't you agree that you could have dropped the whole thing more then a year ago and make much more progress.

[edit]:

a new scripting and modding system - ideas borrowed from gusanos (right?) + physics engine

This is pretty much in planning state yet. I am also very much interested in that and if I have some more time (perhaps in summer next year or so), I will work a bit on that.

again, i do understand that it's a hobby for all of us, but this (IMO) should have been a top priority (together with a new codebase) from the moment development for OLX was picked up. And I'm sure that there are people that would have been interested in implementing such a thing.

[albert]

You shouldn't give all the choice to the user, he doesn't want that and can't make the right ones (user doesn't give a damn about networking layers, etc, he just wants a game that works without unexpected behaviour), therefore some things should be chosen by the developer.

That is just a matter of GUI design. It's not a problem to introduce some ShowAdvancedSettings flag and with that disabled, the best network engine is just selected automatically. And if the user chooses some of the new mods (for the new modding engine), he will not get the choice anyway.

There's no reason at all to introduce multiple networking / physics / whatever layers (other then maybe a nice programming challenge).

Not layers but engines. There is no disadvantage of doing so. It only forces ourselfs to produce nicer code, which is important (and not just a challenge) for future use of the code (if we don't want to start always from the beginning when something is ****ed up).

just force people to upgrade, they will.

I highly doubt that. If we just make OLX Beta8 now with an additional check that you cannot play together with LX56 - OLX Beta7 people, do you really think that everybody will just start using OLX Beta8?

(Btw., such checks are there already when you enable some of the new features. But that is more for technical reasons at it is just not possible in older versions.)

Anyway, each new version (also when we have once a new modding system, a new network system, a new GUI and so on) will have again new features, some extensions to the network engines and other new stuff. Should we always drop the compatibility with old version in each single new release?

And, I also doubt that any of the new engines will be the 100% perfect engine that gives no reason to have any other engine at the same time for the same thing. For example I have both Python and Ruby installed on my system as some scripting languages. And I have both Xcode and KDevelop installed here as IDEs. And I have both VMware and Qemu. And I have both iTunes and Amarok. And I have VLC and Mplayer also installed on the same machine. And I have Bash and ZSH. I have TextEdit, Gedit, KEdit, KWrite and Kate. I have Konqueror, Dolphin and Nautilus. I use Jabber, ICQ and IRC. I use both Internet forums, newsgroups and mailinglists. ...

I'm pretty sure that a lot of time has been 'wasted' working around the old LX code or finding solutions for very weird problems that happened because the code wasn't easy to understand. Don't you agree that you could have dropped the whole thing more then a year ago and make much more progress.

With my current time schedule, I would say, I we would start from scratch, we would need around 5-10 years to have everything as far and good working as we have it right now.

[Gaston]

Of course we don't have real milestones (or I am not sure if I got what you mean by that). This is an open source project and we are all doing this for fun in our spare time. And I probably will not work on features I am not really interested in. That is how open source works (if there is no company paying anybody behind): Everybody works on the stuff he is interested in and people share the work and the project grows. If there is no developer interested in some (non-trivial) feature, it is very unlikly that it is going to be implemented.

I don't get this. Unless my impression is totally off the mark, you are more or less some sort of commander in chief for this project (if not officially, at least practically), for the project. That would suggest that you want something more to it than just programming in the features you're interested in. If all you're interested in is programming in the features you're interested in, why don't you allow someone who's burning for the game, to take some sort of management for the project, and point out the direction it should go in, and you could then in turn program in the features you want to program in, and ignore the other ones, and then people who burn a little more for the game and want it to progress, could get more space on the playingfield...

[albert]

Of course we don't have real milestones (or I am not sure if I got what you mean by that). This is an open source project and we are all doing this for fun in our spare time. And I probably will not work on features I am not really interested in. That is how open source works (if there is no company paying anybody behind): Everybody works on the stuff he is interested in and people share the work and the project grows. If there is no developer interested in some (non-trivial) feature, it is very unlikly that it is going to be implemented.

I don't get this. Unless my impression is totally off the mark, you are more or less some sort of commander in chief for this project (if not officially, at least practically), for the project.

Hm, I think that is mainly for technical stuff. I am often pointing into directions how something should be implemented and if something is bad or good.

For the game itself, I was never against any new sensefull ideas (or almost never, I cannot think of anything). I also came up with a lot of new ideas by myself and implemented some of them. And if somebody else got an idea of the other devs, I just gave some advices how to implement them and made extensions to the ideas.

But it was also the other way: If I got a new idea and I wasn't sure about how to implement that, I was talking with the other devs before.

That would suggest that you want something more to it than just programming in the features you're interested in.

Yes of course, I also care about the code style of the whole project and if the other features are implemented nicely. I care much about if the whole game runs stable. And I care about platform and architecture independence, that as much users as possible can use the game. And I care about the whole structure of the code.

[...], why don't you allow someone who's burning for the game, to take some sort of management for the project, and point out the direction it should go in, and you could then in turn program in the features you want to program in, and ignore the other ones, and then people who burn a little more for the game and want it to progress, could get more space on the playingfield...

It does not really work like this in an open source project. I don't think it is a good idea to have somebody who makes the final descissions.

And if it is only about suggestions, then everybody should be able to make them and everybody should be able to discuss about them (or leave the discussion alone about some particular thing if not interested in that).

Also, what exactly do you have in mind with "directions"? Is it about new features? Do you think, if there is a leader and he commands "drop all other work now, the modding system is the most important thing for now" that all other devs have to follow that? If not, if it is more about somebody who makes suggestions, isn't it pretty much the situation like right now?

I do understand the point of Runyoufool and I think the other devs do, too. And it is good that he is pointing that out, that he presents us his ideas and what he would like to have in OLX. But everbody (every dev) should be able to decide on his own now what he will work next on OLX. That is freedom, like in Open Source.

[Tafka]

There we see: OLX was coded the way developers wanted it. There were really no asking from players about it. Albert have you played the game seriously?

I see there are 2 point of views:
1) the developers point of view
2) the whiney player's point of view

The difference is now that coder doesnt want to do dirty job day to day just to make the whiney player feel better. They want to have fun while coding too. So they all just add features to the game they like - and I don't mean just in-game, but they like to code.

Now the whiney player downloads the newer beta, which has better looks and more buttons, he runs into forum and says "good job". He ignores all the new unnecessary buttons that came with newer beta. He just plays the game like he used to. He finds out that he shoots himself too much and doesn't like one thing and another thing. Then he comes here to whine about it a bit, and so does other players come to whine about the same or different things. The coder will fix few of those problems, but by changing something else again.

Now comes another beta with few new features again, and the game physics is again changed a bit - it was just needed to fix the bugs that people were whining about. Now they play with it, but there appears more bugs and so the developers continue changing them. They still ignore the new features like mouse aim and strafe and all the other useless stuff.

Now comes beta n which has so many new features in it, game is so much changed (even if not so much code-wise, but the feeling is different), there are so many new buttons and the game is different that when a beta1 or old lierox user runs the latest beta, he does not feel comfortable. New players will come and see that this game is so cool. They run the latest beta and make weird settings with it and run a few new functions to create a little fun for themselves. They soon find mortars or classic or other mods that older players play and find all the new stuff useless. Or the player does not like the game and just deletes it after a few games.

Now the difference is so big and one part likes the newest beta, but there is also the other half that would of preferred a whole different game.

The other part is not happy about it and does not use it, he just whines about it to forums, but there is nothing done about it. He feels desperate and stops whining and continues playing with his beta2 that had good game-play.



What should of been done is voting about every new function, getting a preview of it perhaps (?), and testing it carefully til it's done. I'm sure if OLX was in starting stage, people would of also wanted better resolutions and net-engine instead of some other things.

[RuNyoufool]

There's no reason at all to introduce multiple networking / physics / whatever layers (other then maybe a nice programming challenge).

Not layers but engines. There is no disadvantage of doing so. It only forces ourselfs to produce nicer code, which is important (and not just a challenge) for future use of the code (if we don't want to start always from the beginning when something is ****ed up).

Alright, so it's more of a test to make sure the code is portable and modular, but there's no denying that making changes to the netcode while keeping full compatibility with older clients caused quite a bit of problems in the past.

just force people to upgrade, they will.

I highly doubt that. If we just make OLX Beta8 now with an additional check that you cannot play together with LX56 - OLX Beta7 people, do you really think that everybody will just start using OLX Beta8?


(Btw., such checks are there already when you enable some of the new features. But that is more for technical reasons at it is just not possible in older versions.)

Anyway, each new version (also when we have once a new modding system, a new network system, a new GUI and so on) will have again new features, some extensions to the network engines and other new stuff. Should we always drop the compatibility with old version in each single new release?

Again, it is all about planning new releases. If you introduce a new networking engine and test it thoroughly you can introduce it at some point and drop all compatibility with older versions (and all users will upgrade, as long as you give them a reason to (simply give them a month, display a message in game that urges them to upgrade, and close masterservers for old versions after this period). From there on, you shouldnt change this part of the code for a long time so you can keep compatibility for the next 1-2 years before another upgrade forces people to upgrade again. There's nothing wrong with that and it gives a huge advantage: stability and maintainability.  If you keep changing major things incrementally with every release, how can you ever work towards a solid game? I' m sure there are always things that could have been done better, but that could be put into  the next version of the engine, which is being worked on in parallel. It's not that hard to plan really. 

And, I also doubt that any of the new engines will be the 100% perfect engine that gives no reason to have any other engine at the same time for the same thing. For example I have both Python and Ruby installed on my system as some scripting languages. And I have both Xcode and KDevelop installed here as IDEs. And I have both VMware and Qemu. And I have both iTunes and Amarok. And I have VLC and Mplayer also installed on the same machine. And I have Bash and ZSH. I have TextEdit, Gedit, KEdit, KWrite and Kate. I have Konqueror, Dolphin and Nautilus. I use Jabber, ICQ and IRC. I use both Internet forums, newsgroups and mailinglists. ...

Gamers don't care about engines. They just wanna play games on the net and have the easiest and best possible experience. It's not a utility software Albert, but something to entertain people.

[pelya]

Also, what exactly do you have in mind with "directions"? Is it about new features? Do you think, if there is a leader and he commands "drop all other work now, the modding system is the most important thing for now" that all other devs have to follow that? If not, if it is more about somebody who makes suggestions, isn't it pretty much the situation like right now?

I do understand the point of Runyoufool and I think the other devs do, too. And it is good that he is pointing that out, that he presents us his ideas and what he would like to have in OLX. But everbody (every dev) should be able to decide on his own now what he will work next on OLX. That is freedom, like in Open Source.

It's just that someone always knows some parts of code better, so it will be better usually to get 3 devs implement 3 different features, than get all 3 implement one feature, where they will have conflicts in the code etc, and final implementation time will be the same.
Though some wise leadership won't be bad I think, especially if we want to corruptinvite new devs. For example Jonanin tried to implement one huge feature, and obviously lost interest to development.

Alright, so it's more of a test to make sure the code is portable and modular, but there's no denying that making changes to the netcode while keeping full compatibility with older clients caused quite a bit of problems in the past.

Yeah, I've spent a week adding connect-during-game with support for older clients to Beta4, but it failed, I've removed that ugly code, and Albert added the nice code for the same feature in just two days to Beta8, without backward compatibility. That's AFAIR the only issue where backward compatibility caused some problems.
So by now everything we're doing is not compatible with old clients, old compatible code just sits here and doesn't require any time to maintain.

Again, it is all about planning new releases. If you introduce a new networking engine and test it thoroughly you can introduce it at some point and drop all compatibility with older versions (and all users will upgrade, as long as you give them a reason to (simply give them a month, display a message in game that urges them to upgrade, and close masterservers for old versions after this period). From there on, you shouldnt change this part of the code for a long time so you can keep compatibility for the next 1-2 years before another upgrade forces people to upgrade again. There's nothing wrong with that and it gives a huge advantage: stability and maintainability.  If you keep changing major things incrementally with every release, how can you ever work towards a solid game? I' m sure there are always things that could have been done better, but that could be put into  the next version of the engine, which is being worked on in parallel. It's not that hard to plan really. 

Hm, we're making releases once per half year ( I count stable releases, Beta3, Beta5 and Beta8), that's not so short period IMO to make development cycle look like Linux kernel
If we'll stumble on some problem that will require dropping compatibility we'll drop it without hesitation. Just for now it's easy to keep it.

And, I also doubt that any of the new engines will be the 100% perfect engine that gives no reason to have any other engine at the same time for the same thing. For example I have both Python and Ruby installed on my system as some scripting languages. And I have both Xcode and KDevelop installed here as IDEs. And I have both VMware and Qemu. And I have both iTunes and Amarok. And I have VLC and Mplayer also installed on the same machine. And I have Bash and ZSH. I have TextEdit, Gedit, KEdit, KWrite and Kate. I have Konqueror, Dolphin and Nautilus. I use Jabber, ICQ and IRC. I use both Internet forums, newsgroups and mailinglists. ...

Gamers don't care about engines. They just wanna play games on the net and have the easiest and best possible experience. It's not a utility software Albert, but something to entertain people.

Cizin is using 0.56b 'cause he has old hardware, and Beta5 is slower than 0.56b almost by half.
And I'm playing TeeWorlds once per week, they still beat us in network engine, and totally beat us in the server count. But we hopefully have bigger community.

2Cizin: Add feature request like "make it run faster" plz to my poll and SF.net bugtracker.
2Tafka: Request a feature like "make it feel exactly like 0.56b" plz to the poll and SF.net bugtracker.
I don't like that bugtracker BTW 'cause you cannot see how much people suffers from the same problem here.

[Tafka]

2Tafka: Request a feature like "make it feel exactly like 0.56b" plz to the poll and SF.net bugtracker.

Was it sarcasm?
I don't mean it has to be exactly like 0.56 at all. Betas up to 3 were as playable, but after that I started feeling uncomfortable.

[Gaston]

Hm, I think that is mainly for technical stuff. I am often pointing into directions how something should be implemented and if something is bad or good.

For the game itself, I was never against any new sensefull ideas (or almost never, I cannot think of anything). I also came up with a lot of new ideas by myself and implemented some of them. And if somebody else got an idea of the other devs, I just gave some advices how to implement them and made extensions to the ideas.

But it was also the other way: If I got a new idea and I wasn't sure about how to implement that, I was talking with the other devs before.

What exactly constitutes "sensefull"? Do you have to approve every idea as sensefull before they're implented, or do the other devs have a say in what is considered "sensfull" here?

Yes of course, I also care about the code style of the whole project and if the other features are implemented nicely. I care much about if the whole game runs stable. And I care about platform and architecture independence, that as much users as possible can use the game. And I care about the whole structure of the code.

Then why are you arguing for the programmers just implenting the features they want, as opposed to it being a managed project? Either this is an "open Source" project where programmers just come and go as they like and make changes to the code, or this is different from it and being much more of a managed project. You can't both have the cake, and eat it...

It does not really work like this in an open source project. I don't think it is a good idea to have somebody who makes the final descissions.

The problem is, that in reality, there will ALWAYS be someone who makes the final decisions. Except in the case where there is no activity on the project. You can't select away the option of having someone making decisions, as someone will always be making them. You can though, do the best of the situation, and be aware of this, and cater around this to the best extent possible, or just think that this is not the case, and in the end creating a meaningless fog around the project.

And if it is only about suggestions, then everybody should be able to make them and everybody should be able to discuss about them (or leave the discussion alone about some particular thing if not interested in that).

It isn't as easy as that. Everybody should be able to make suggestions and discuss them of course, but in the end, SOMEONE will have to make decisions around the game. atm it is left to the programmers, with no real direction if your model of everyone implenting what they want is true. Every program needs a direction. If there is no direction for the program, it is very hard to please the target group the program is aiming for.

Also, what exactly do you have in mind with "directions"? Is it about new features? Do you think, if there is a leader and he commands "drop all other work now, the modding system is the most important thing for now" that all other devs have to follow that? If not, if it is more about somebody who makes suggestions, isn't it pretty much the situation like right now?

There is such a thing as a thing in the middle. A "leader" of the project, wouldn't have to be a dictator and command people what to do, but the leader should be able to stake out the general direction for the project, and what to prioritize. And generally, if the "leader", is a good leader, the programmers shouldn't have too many problems with that. If the programmers or the community have problems with the leader, there should be open discussions around the subject. The "leader" would function more as someone who stakes out the general guidelines for what needs to be done and when etc etc, but the programmers should decide on the specifics etc. ATM there is no general direction for the program, and most programmers follow what they want to follow on the project, which by all means is nice, but in the long run, makes it hard to keep a steady route. IMO an open source project shouldn't just have programmers that wants to program stuff X in, but it should have programmers who really have a relation to what they're programming, and who they're programming for. Which would mean that we would want to attract a specific kind of programmers, and not just generally activly seak out programmers with no frame of reference, if we want to get a structure for where OLX is headed and potential long time goals.

I do understand the point of Runyoufool and I think the other devs do, too. And it is good that he is pointing that out, that he presents us his ideas and what he would like to have in OLX. But everbody (every dev) should be able to decide on his own now what he will work next on OLX. That is freedom, like in Open Source.

If this is what Open Source is to the average programmer, I would rather prefer the game to be closed source personally. Because in this particiulair scenario I care more about the future of OLX than the principles of Open Source programming.

[Desmond]

Everybody has a different definition and interpretation of open source! Look at the mess! Ack!

You know what to do.

[SteelSide]

TL;DR, can you post some shortened down version of the 2 sides (Or people) and what their opinions are? (Forgive me, but this is what you call a wall of text - it's even higher then a wall.)