Refocus of the demoscene
category: general [glöplog]
Quote:
why do we don't see that many (good) demos from the land of the free, home of the brave?
What, Scotland?
CRM? Content restriction management?
Demoscene should simply quit the computer sphere.
Future is in ecological resources and environment recovery.
Then to move slightly towards it, there should be gardening contest "best tomato, realtime harvesting..."
Then leave the open GL world to do real cows in 3D with flesh and horns.
Future is in ecological resources and environment recovery.
Then to move slightly towards it, there should be gardening contest "best tomato, realtime harvesting..."
Then leave the open GL world to do real cows in 3D with flesh and horns.
Yes, scarily I've said exactly the same thing as the original post many times before.
Successful cooperation between people will only ever work if someone takes charge and makes sure everyone is doing their part and delivering stuff when its needed. Unfortunately "taking charge" is antithetic to the scene because it's a meritocracy.
Literally thousands of productions are probably lying unfinished on harddrives everywhere because nobody took charge and set goals to get the product finished. It's a similar reason to why many talented sceners never reach their potential in life/career/success/whatever.
Yes, it's management speak, but that doesn't mean it's wrong.
Successful cooperation between people will only ever work if someone takes charge and makes sure everyone is doing their part and delivering stuff when its needed. Unfortunately "taking charge" is antithetic to the scene because it's a meritocracy.
Literally thousands of productions are probably lying unfinished on harddrives everywhere because nobody took charge and set goals to get the product finished. It's a similar reason to why many talented sceners never reach their potential in life/career/success/whatever.
Yes, it's management speak, but that doesn't mean it's wrong.
Management is ok 40 hours a week at work, certainly not during my sparetime when coding/designing demos.
They take the time they take to be made, no pressure, no deadline, no stress, only fun and passion, or else I don't even to hear about it :)
(and yes, that probably sounds cheesy, but that's the way it is)
They take the time they take to be made, no pressure, no deadline, no stress, only fun and passion, or else I don't even to hear about it :)
(and yes, that probably sounds cheesy, but that's the way it is)
(in case some people took this thread seriously ;) )
Indian people obviously dont make demos because they dont get paid for it! You can change that!
Bollywood demos would rule
(just replying about what debase and keops wrote)
Well, I guess management is boss a good and a bad thing.
Since I'm a software developer, I naturaly tend to adopt "processes" that helps me delivering things on time with a certain level of quality: design ahead, organise feature list in things that are "core" and things that can be "dropped", I use source control software, fast iterations, ask for regular feedback, negociate precise descriptions of how we should handle assets (file format, size, number of colors, etc...) and clearly states how long it takes to integrate a new change before it can be published.
Result is that the last time I did that, we managed to release the Creators part for the 20years anniversary compo on time, but the team nearly imploded because they were not used to such organized process.
So I wonder, should I have just used "dilettante" way of doing thing, and try to get the intro finished "when it's done", or was this important to meet the deadline...
Don't know.
Well, I guess management is boss a good and a bad thing.
Since I'm a software developer, I naturaly tend to adopt "processes" that helps me delivering things on time with a certain level of quality: design ahead, organise feature list in things that are "core" and things that can be "dropped", I use source control software, fast iterations, ask for regular feedback, negociate precise descriptions of how we should handle assets (file format, size, number of colors, etc...) and clearly states how long it takes to integrate a new change before it can be published.
Result is that the last time I did that, we managed to release the Creators part for the 20years anniversary compo on time, but the team nearly imploded because they were not used to such organized process.
So I wonder, should I have just used "dilettante" way of doing thing, and try to get the intro finished "when it's done", or was this important to meet the deadline...
Don't know.
arg. "boss" => "both"
Pouet definitively need a "preview" window...
Pouet definitively need a "preview" window...
Quote:
I guess management is boss a good and a bad thing
What a lapsus linguae :)
I have hired 40 polish coders for 1 Euro a month to code demos for my demogroup. Out(in)sourcing rules...?
If the team works well, you don't need any more processes. When implementing new processes, make sure that you have a plan on how to convince the others that the processes actually make the demomaking less painful and
more productive.
[Dbug: We have largely the same processes implemented as you do. The difference probably lies in the details. After each demo is done, we discuss what things went wrong, and how things could be done differently; then we change the development process for the next demo.]
Before you start off, make sure everyone wants to make the demo, and know WHY they want to make it too. Talk about it. Talk about the processes. (And do some market research; perhaps Decepticons are unfashionable this year?)
We usually make a storyboard first; either a simple textfile which briefly describes what's going into the demo, or a full-fledged series of sketches or mock-ups of the different parts. The storyboard helps in several ways:
* Everyone on the team gets a better idea of what the demo will be like
* Making a visual storyboard requires you to agree on what the parts look like and what they really are about
* Communicating with the musician(s) is easier
Make sure that at least one person is excited about each part/aspect of the demo. (That person will then informally 'own' that part of the project.) That person will evangelize is to others, and get them interested too. Otherwise, when noone cares about a given part, it will not get done.
Show results often. Whenever someone completes some piece of art/code/music, publish it to the entire team. Seeing that others are eager and productive is the best motivator.
Some people (me, for example) find it difficult
to get started. The best remedy against this lack of spirit seems to be to work for a few days in the same room as someone else who is starting/started with his work on the demo.
If you're not working with professional software developers, ensure that everyone knows their options when development isn't going according to schedule - work harder, redistribute workload, cut content, extend the deadline, or cancel the project. All five are valid choices, as long as it keeps people happy (that's why we are doing this in the first place, right?).
And finally, the most important thing of all: Make sure that everyone is working toward the same goal. This goal should usually be something like "the best demo experience possible". People who focus solely on their own parts of the demo can sometimes improve their bits, while affecting the whole-demo experience negatively.
more productive.
[Dbug: We have largely the same processes implemented as you do. The difference probably lies in the details. After each demo is done, we discuss what things went wrong, and how things could be done differently; then we change the development process for the next demo.]
Before you start off, make sure everyone wants to make the demo, and know WHY they want to make it too. Talk about it. Talk about the processes. (And do some market research; perhaps Decepticons are unfashionable this year?)
We usually make a storyboard first; either a simple textfile which briefly describes what's going into the demo, or a full-fledged series of sketches or mock-ups of the different parts. The storyboard helps in several ways:
* Everyone on the team gets a better idea of what the demo will be like
* Making a visual storyboard requires you to agree on what the parts look like and what they really are about
* Communicating with the musician(s) is easier
Make sure that at least one person is excited about each part/aspect of the demo. (That person will then informally 'own' that part of the project.) That person will evangelize is to others, and get them interested too. Otherwise, when noone cares about a given part, it will not get done.
Show results often. Whenever someone completes some piece of art/code/music, publish it to the entire team. Seeing that others are eager and productive is the best motivator.
Some people (me, for example) find it difficult
to get started. The best remedy against this lack of spirit seems to be to work for a few days in the same room as someone else who is starting/started with his work on the demo.
If you're not working with professional software developers, ensure that everyone knows their options when development isn't going according to schedule - work harder, redistribute workload, cut content, extend the deadline, or cancel the project. All five are valid choices, as long as it keeps people happy (that's why we are doing this in the first place, right?).
And finally, the most important thing of all: Make sure that everyone is working toward the same goal. This goal should usually be something like "the best demo experience possible". People who focus solely on their own parts of the demo can sometimes improve their bits, while affecting the whole-demo experience negatively.
Well, I guess that is what it takes to release a winning demo every year.