Even though this is a good list, I agree with the criticisms that it’s too long for an initial 1.3 release. It should be trimmed to keep only the top priority items to satisfy the goals for the release (built well enough to attract and keep together the community).
I think the devs must decide on few critical items to complete, and some of the complex features that are hard to implement properly (i.e. taking forever to fine tune). I think Swirl would be nice to have in the initial release, but some features can be held back for now.
I’m not convinced that we need a new client. More like we need to bundle the GPP client to make it easy to download and install. Although I like the list for the client requirements, but again, not enough devs…
I thought new human team player models were “in progress”? (shouldn’t be orange?)
Trying to get back to contributing some time, but not finding any these days.
That is incorrect. They are not responsible for the code and community not being ready yet. For this project it is GrangerHub’s responsibility to get the code and the community ready.
It is certainly a possibility that as we make more progress, we may decide to move various items in this TODO for the initial release to the TODO for subsequent updates and have the initial release sooner (the updater/launcher allows for this possibility). But before we would look into making such a decision, lets first have the Swirl and Vanilla Game Modes finished, lets have successful public testing of the updater/launcher with a pre-release client, and lets have GrangerPub/GrangerClub updated with a good enough work in progress 1.3 server and QVM. I would say that completing those milestones are absolute musts.
We figured that it would be better for the expectations of the community to later possibly remove a lot of things from this TODO list than to later add a lot of things to this TODO list.
The 1.3 client even in its current work in progress state is very usable and a much better option than the gpp client, although there is still a bug that prevents downloading from modded 1.1 servers (but once you have those pk3 files the client works on those servers, and downloading seems to be fine for gpp, new protocol, and multiprotocol modded servers). Also like DevHC said, most of the remaining stuff on the Client TODO are not very involved tasks.
Although I just realized that I forgot to include “New Chat UI” in the client TODO (I’ll add that), the current way chat is mixed into a mess in the console sux especially when chat is an essential part of the Tremulous experience.
TremCam would greatly help with the promotion of Tremulous. If no one else implements it by the time I finish my higher priority assignments in this project, I will work on it personally, if not for the initial release, definitely for a subsequent release shortly after. This tool is actually important for another Tremulous project I plan to work on after the initial release.
I’ll address various other points raised in above posts in this topic a little later.
@Hero watching a new player building a base on the NEW 1.3 Tremulous.
srsly find me someone that works 2-3 hours per day for a game that won’t give em any money.
Family, work, etc take much time and you think that they can spend their quality time for release 1.3? Say thanks that at least there are some green items.
This is what open source is for. Linux would have ended up exactly like Tremulous 1.3 if Torvalds kept the code to himself.
By the way, ever heard of Limit Theory? It was a very promising space exploration game, but the author decided to Not Release It Until It Was Ready™. It’s still not done (almost 3 years late) and the last update from the developer was a year ago.
Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose : Wikipedia
I fail to see anything mentioning developers being required to push out the source code before release, so I’m going to have to disagree. I believe you were implying the “collaborative” culture of open source software, which (afaik) the door is open for anyone willing to work on Tremulous 1.3
Okay. However, I’m sure with the power of GOOGLE™ I can also find a counter-[EXAMPLE]. The issue I have is that the example you gave is a game that was abandoned and I don’t see any evidence of this happening to Tremulous 1.3 atm.
However:
tl;dr Lots of bullet points =/= work required to finish 1.3 and as always, things can be cut if necessary.
And it will surely continue to stay this way for awhile. From what I observed just from this thread, talking shit is far easier than doing shit.
Pushing the current team to release what they have now is not going to work (as explained a bazillion times already).
Grab a coffee folks, its going to be released SOON™.
Alright, we’ve reached Step #1. EZPZ. Now on to Step #2:
We need to get some of those people to work on a glorified Quake 3 mod that came out of the asshole of 2006, looks like shit, isn’t easy or intuitive to learn, thats niche, has a low player population, abandoned, tossed around then picked up by a team juggling drama, trolling shitstorms, server administration and forum maintenance while trying to get a release ready to kickstart life back into a game already overshadowed by the likes of Natural Selection 2. And preferably has new features to appeal to a modern audience in a market full of closed sourced, proprietary AAA-budget free-to-play games on social platforms like Steam with almost very little resources of our own, including (but not limited to) free time and money.
i used to spend a shitton of time working on ioQuake3 and Tremulous. btw, the first version of the multi-protocol functionality (for Amsterdam Unlimited; only covering 2 protocols, and having a couple of quirks) took 3 days, each consisting of 18 hours of work.
@DevHC brought up some concerns on the TODO that I share:
Specifically, details on what they pretain exactly. What are they? What do they do? How do they benefit Tremulous? Is the X amount of work required to finish them really worth the Y amount time it would push back the 1.3 release?
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.
Why is it so bad if you use an honest indication system about your progress?