this is better phrased as being in the server component, ie. is server-side, but is not in the gamelogic module.
the first and most important thing is to design a karma system, to try to find out whether such a system is possible without it being counter-productive.
or just say why the feature should be included. or, if the case is obvious, then simply request the feature.
additionally, if not just saying why, then one could use a better file (patch) transmission medium than this forum.
I moved a bunch of posts to best keep the discussions on this thread on-topic and still have the conversation make sense. To keep this topic productive, I ask that all further posts in this thread be about which items should stay, should be removed, or should be added to the list, as well as about the status of the items on the list.
Red: nothing because it includes NOTHING DONE or WE PLAN BUT WE HAVE NOTHING SO… yes nothing.
Orange: NOTHING or MOST because we can call 1% or 0.01% a progress and 99% aswell so what does this tell me? NOTHING.
Green: SOMETHING works or its NEARLY DONE means: 50% ? 80%? 99% ? Another NOTHING to me because GREEN LIGHT means to me = lets go, ready! but here it means: maybe or hmmmm
So if you assign this to Tremulous 1.3 it simply means: NOTHING IS DONE because its either NEARLY DONE or ITS NOT DONE. What a fuckup!? I don’t say that you didn’t accomplish something but how hard is it do design a common sense based “to do list”?
The reason we are calling green working prototype or near complete is because as we continue to develop new bugs related to those items may be discovered, or we may find that some fine adjustments may be required in those items from continued tests. We wouldn’t say that any of those items are absolutely completed until the initial release.
But when all the items on the list are green (and we may decide to remove a bunch of the items on this TODO for the initial relase and move them to the TODO of a subsequent release) we will be having the initial release shortly after, and any further bugs or needs for fine adjustments that might be discovered for those items at that point would be addressed in subsequent releases.
So in other words, if an item is green, that particular item no longer stands in the way of the initial release, so in that respect it does mean “lets go, ready!”
Every red item on the list has already been planned/designed, and we do know how to approach the work on those items, but we aren’t counting the planning as part of the progress, we are only counting tangible progress like coding and asset production.
Regarding having something more definitive on the rest of the color scheme many of the items require different amounts of work. Some items on the list single features/enhancements, other items are whole new systems. Additionally we can’t anticipate potential tricky bugs or other unexpected hurdles related to development that may be encountered. So it is very difficult to quantify the progress for each item on the list via a general scheme.
The best we can do is indicate that we begun working on a particular item, and then indicate if that item has gotten to a state where we would be satisfied with that particular item if the initial release happened at that moment.
Actually there are a couple of the orange items on the list now that we will be changing to green probably in the next week that may not require any more coding, but I want to see how well they work out in a couple of more dev games before changing their status.
Makes sense but on the other hand its a nasty way to cover the project’s real progress state.
That has nothing to do with saying: its done or not. You can say a bug is solved or not or at least ballpark the amount of work left or done and if you don’t know then its simply not done. Also that is the savest way to be honest and genuine.
Like saying ‘we work on it’. Why is it so bad if you use an honest indication system about your progress?
You know, thats the statements that make me angry again. Wishy washy statements, repeated again and again.
Once more: if you change it to green then what does it tell me? Orange means: not done, green means: not done.
You say it MAY require more coding in the future: not done!? Can you reproduce my confusion?
I’m talking about bugs that emerge as we develop an “orange” item, we can’t say before hand how much work it would take to fix bugs we don’t yet know about. Additionally often times many aspects of an enhancement/feature/system may require trial & error before getting it right.
What I mean by it being green is that when we have the initial release, and nothing changed with that item, we would be satisfied with its inclusion in the initial release. But I can’t say that it is “absolutely done” in the sense that there will definitely not be any changes to it before the initial release (such as further fine tuning from dev game observations, or fixing some later discovered bugs related to the item).
Even when we have the initial release, we can’t say that the project nor any part of the project is completely done, as we intend to continue to work on Trem after the initial release and have more subsequent releases. Additionally we hope that more independent developers will continue to mod trem. So we can’t use the term done, we can only state if an item is good enough for a release.
Orange means that progress started but it isn’t ready enough for the initial release.
Green means it is ready enough for the initial release.
This indication system is honest, it just has some fuzzy aspects. If we assign a percentage of the progress of an item chances are it would either be overestimated, or underestimated, which either way sends an inaccurate indication of the actual progress of the project. The most honest way I see we can indicate the progress of these items is to just say for which items work has begun, and which items are ready enough for the initial release.
Additionally, the public can observe the results of the progress for many of the items firsthand on the test7341 server, on the website, and (when we get to that point) with the public tests of the updater & pre-release client.
We also started a page that has an rss feed with our private repo that shows the title, date, and author of commits. Although that page can use some improvement (cough, cough, @romdos , cough, hint, cough), like the ability to scroll back a couple of hundred commits, have a prominent link on the main website and in these forums, and show a few more key branches like “develop”, “swirl-vanilla-common”, and “vanilla-dev”.
The main thing is that we have a public definitive list of the items that we are requiring for the initial release, so that it can be understood that when all of these items are ready individually for the initial release, we will be ready to have the initial release.
Nothing is absolutely done but SOMETHING can be done for 1.3. ANYTHING after that would be 1.x or 1.3.x whatever. This is common. The way you use ur todo list is still confusing and covering the real state of your project. If you still want to keep this then add another color for: DONE FOR 1.3!. At least then i see what is done and what isnt because the other colors doesnt tell me jack shit as i wrote some posts before. I think this is logical and i don’t think there are any good reasons not to do this.
OFFTOPIC: blizz is probably joking but there are people who legitimately think this. i don’t understand this mentality. tremulous is open source and at the end of the day, the community just wants the best possible tremulous successor. i’d say we should be grateful that there are multiple interest groups willing to resurrect this shitty quake 3 mod from life support.
@dGr8LookinSparky@Matth maybe we need to have some rough estimates of difficulty or developer points for each item and percent done or hours left kind of remark next to them.
@Matth we’re not full time devs here so it’s really difficult to estimate how long something is going to take because it depens on irl availability of ppl.
You seem to be giving the impression that reorginization of the TODO™ is necessary. I disagree. Reorganizing assumes the developers are spending their [time + effort + energy] inefficiently. For example: Improving code < writing up a PDF instruction manual. I doubt this is the case based on what I’ve read from this thread.
The inadequacy of organization isn’t the issue, it is clearly the inadequacy of resources (people, free time, effort).
tl;dr Stop talking shit, start doing shit. Kids are busy with school. Just get shit done. That is basically what everyone (including the detractors) actually cares about.
The above sentence is a general statement, not a direct one to cengique.
The primary purpose of a public TODO is to better inform the general public of the status and progress of the project, especially since there are significant parts of the code not yet released. While we might be working efficiently on the development under the circumstances and with the available resources, that doesn’t mean that the communication of the project’s status and progress can’t be improved upon.
NOTE: I am not trolling and I am not unfriendly. This is just my POW.
Much of this what I read here in first post is not important for the general players.
First thing what I don’t understand is 3 Game Modes. Stock 1.1. Style Chocolate Swirl?????
What is that?
I thought that game modes are Free for All (FFA), a classic deathmatch, Team Deathmatch (TDM)Capture The Flag (CTF), things like that…
For me Stock 1.1. Style and Chocolate are just a MODs.
Swirl is another perversion.
From the list what I saw and read here it is a MOD, nothing less, nothing more.
Much of things on the server list is not important for the normal players and it belong in another list. After reading again, Server list, I saw that many of things belong in the Client list.
Most of things here in TODO list is mix of everything what is already published.
Client’s really don’t care about technical aspects of the engine, they care only about for example from what I saw on the list HUD Improvements, New Alien Classes, New Human Gear/Equipment, Improve Evolving, Nice main menu with more complete settings / options
Something what they will see on initial screen and after map loading, more eye-candy things. Here is the example.
What people will see when they start game and load map? GUI and assets.
As player in my case, why should I care about Multiprotocol support, Server-side demos, TremCam / TremMME or for SQLite DB. I don’t want to offend anyone, but I really don’t think that “normal” or common players will ever use that, that thing is only important for the administrators and for people who know what is that.
One note also, supporting older things will 100% “I-KNOW-KUNG-FU” hold you down and give you hard time to introduce new things and make the game more advanced and better.
From what I read, as I wrote here, most of things what are in the initial TODO list (with any color) is already there and with my point of view is not needed.
After reading all this, my first impression was “wow, it is good, just who will use all this and why to create feature-creep”. What is the point in all this.
I give you all kudos with new assets and new maps, new textures. Nobody can say anything against that.
KUDOS.
In my humble opinion only with new assets you can bring old players, old developers and new players, new developers.
Why is it so bad if you use an honest indication system about your progress?