Cedur wrote: ↑Wed Mar 11, 2020 5:39 pm
I thought we wanted a change that encourages people more to finish their projects, and not have plenty of short-lived members making threads that they'll abandon anyway?
If you read my
post in the other topic where the idea is explained... those are not mutually exclusive. My idea does both. I encourage you reading it, but below is a more elaborate form of the thought process:
(In order to read this post it might help to stop viewing episodes and projects as feeding the player's lust for things to play, and more for the designer's interest in sticking around, improving and making more levels in the future)
The issue, as first explained, is "people aren't finishing their projects enough". But who is "people" and WHY are they not finishing them enough?
- People are newcomers who try out the engine and want to do something cool
- They don't finish them enough because they run out of ideas or get tired of a concept
What would enforcing more rules do in those situations?
- Nothing, for people who jump over the initial posting hurdle
- People who cannot might not post their project altogether, cutting them off from receiving feedback and encouragement
The case right now is that the rules in the projects forum don't address people not FINISHING projects, but rather people not STARTING projects. I'll go through these one at a time, starting with "starting".
Why the forum has a misconception about started projects: Projects are more than the levels that make it into the game. Around the level design there is a concept phase and a "marketing" phase. Each of the three is a different area of expertise, and a new designer may find a particular interest in one particular one of the three at any given moment.
Why the forum has a misconception about finished projects: The difference between an episode and a project right now is that an episode is a project where the finished result roughly equals the intended scope. However, one could also think of "finished" as "done with". And when a project creator is "done with" a project and moves on to the next is nothing that can be controlled by rules, since it's personal preference. Fixing that by forcing them to stick with the idea indefinitely is a shitty idea cause it won't be fun for the designer and won't lead to good levels as a result. Projects can be cancelled at the 90% mark and we can't change that.
So how do we ensure that more episodes get finished?
In short, we don't. The people working on them have to. But we can make rules that help them get there. And this is how we get to what Aero posted.
This community has been lacking in veteran-newcomer interaction for a solid decade, which has caused the divide between high and low skill to drift further apart. Old members have fun, stick around, learn more, get better. New members make a level and receive a rude comment and ask themselves if this community i's even the right place for them to be. A few years back a controversy about elitism sprouted on the forums, accusing veterans of forming an elitist clique encouraging the divide. I think the "clique" exists but is a subconscious aspect because this forum doesn't do anything to break the "everyone works on their own" attitude that goes contrary to the concept of a community.
SO. How do concept threads fix all that?
First, it's important to recognize that ideally there should be absolutely no external pressure on the designer to reach their often lofty goals. A project is done when the designer is done with it.
Once the designer is done with it, they should be encouraged by the rules to post what they have, so others can give more feedback based on that and their next idea can be even better. This is necessary because cancelled projects are part of the improvement path of a developer. You've all never seen half my projects because they weren't worth posting because of the divide between cancellation and finishing. I've made a lot of world 1-3s.
Concept threads allow people who are currently more interested in formulating level ideas and project structures to share some of them and receive feedback. They also allow people more interested in marketing to hone their skills of capturing enticing imagery and testing out how to feels to post them at a particular rate.
Concept threads are also project threads. Any project thread should be encouraged to post more details about the going-ons in the project. Stuff like individual level ideas, progression systems, etc. They should especially not be separated because that would just re-introduce external pressure once a project jumps over an arbitrary hurdle even though the project isn't any more likely to be finished in the 5% below the hurdle than in the 5% above it. Regardless of where the hurdle is. Not to mention external pressure. I don't understand the argument of separation brought up earlier because it just sounds like it can be easily fixed by the person only making posts when there's something to say that contributes to a thread, but I figured I would address it here.
With the focus shifting to the developer and imrpoving their learning and fun with the engine, we narrow the gap between newcomer and veteran and allow people to improve more more quickly. As a result, if people who give feedbback remember to follow common posting etiquette, will have more skilled designers more capable of finishing proper episodes, and more half-finished episodes to play for helping these people out. What this suggestion does is not reduce the number of finished episodes, but rather make the path TO finishing a first episode more visible by making the cancelled projects that lead there visible and allowing people to more easily give tips and ideas. I think we might even see more episodes than we do right now, if people continue to actively help each other out. I hope that with this change posting a project thread will no longer feel like a large committment to constant updates, but more like a blog.
Any lingering questions might be explained by the post linked at the beginning of this post. So check that post out before asking.