pouët.net

Also it would be fair for those prods who got shoved into a bigger compo because theirs got canceled.

I disagree, for the same reasons as I've already stated. Just look at the comments on Pouet for prods that were below the size limit of the compo they were in -- like 1k's in 4k compos, or 32k intros in the 64k compos. Half of the comments are like "OMG?! <x bytes> under the limit? AWESOME!" -- which is, again: rubbish. I mean I've been guilty of that too, but I'm no longer impressed by such things, because the prod itself is far more interesting.

Each compo has a sizelimit. If the prod is under the size limit it's rules-compliant. End of story.

did I mention i think it would be interesting to see a 16k compo? =)

if the size of your prod is one of its strongest points, you would show it in the prod already.

gloom: please don't discard the fact that the human doesn't decide on numbers alone but actually might show some kind of intelligence when voting.

d.fox: and thats exactly the reason why the numbers shouldnt be hidden on purpose.

Productions that end up half the size of the compo-restriction could have been double as good if time and inspiration allowed them to be. End of story ;)

Demos should be about code porn with style, not only code porn.

"Given two demos of equal visual quality, content and interest", the remaining qualifying factor seems to be namevoting, not size :)

As stated earlier: people can use the description text to write something about the size if they want to. Or the custom option field in PM. Or name their entry "GreatDemoInOnly12bytes".

If you start showing size, why not include the team-strenght? A 20mb demo made by one person might be more impressive than a 64k intro where 10 people were involved. Or how long it took to code it.

As gasman said - there are too many metrics that could be included. Size is just one of them and it doesn't really matter since other facts might be more impressive.

I'm not agreeing with gloom but I also don't think that showing the filesize would change anything.

Also - people can download the entry before voting and check the filesize themselves ;)

d.fox: I think gloom's point was that sometimes people completely misinterpret the size (or architecture) of a demo.

Well, sometimes people are stupid. That's not fixable :-)

So when you say "might show some kind of intelligence when voting", the emphasis was on "might"? :D

As in: we're all biased when voting. Sometimes we make a concious decision based on all facts such as quality and mood, and sometimes we just vote because we know the guy who made the production.

I agree, but then the question is, is throwing in yet another (often misleading) factor a good idea? I mean isn't that why we have size-limited compos in the first place, to make sure the audience 1) is aware of what size (generally) the entries are and 2) what the context is?

I don't think it's necessary. As said, the author has many possibilities to do that himself.

Let's get back to the context here: in a 4k compo, is it really necessary to show that one prod was 3289 bytes, the second was 4096 and the third was 2105? My opinion is that it isn't. They're all 4k intros, and the fact that they all don't hit the ceiling of the compo restriction is completely irrelevant.

In the case of a combined compo where all kinds of entries are smashed together because of lack of entries (or whatever) then showing that compo they were originally entered into should also suffice. In fact, especially in this case.

In the case of "showing the filesize not changing anything" I have more than one example (from my own parties and others) that this is simply not the case. People in the scene (and especially people with just one foot in it, viewing, not making) are especially drawn to small files. That's just plain fact :)

a.k.a NAMEVOTING \:D/

Agreed with britelite and you...

@preacher


Maybe if people (non demoscene related) were more demanding on size/speed matters we would not have a xxx Mb operating system that demands ages to bootup...
Apart from that it matters to me, and considering the 64k/40k/4k/1k etc trends in demos, it matters to many people, no?

There's tons of stuff I'd like to know about a prod before voting - size, any 3rd party libraries used, which bits are realtime or precalced, whether that nifty smoke effect was just a jazzed up plasma or a complex fluid simulation.

Problem is, if you start adding more info like this it turns a demo compo into a "who has the best marketing guru" competition.

So, count me as a vote for "clearly show if it's a 4k entry in the demo compo because there weren't enough 4ks, otherwise fuck off."

I disagree with the notion - being put forward by people on both sides of this argument - that compos should be conducted in a certain way to push the voting towards "good" judging criteria, the ones that are supposedly "in the spirit of the scene". You can argue all you like about whether efficient coding (beyond what's imposed by intro compo rules) is a desirable thing to promote: ultimately, it doesn't matter, because the characteristics of a "good" demo are not decided by committee. A "good" demo is defined by *what people vote for*, so trying to steer voting towards demos that deserve to win is like trying to lift yourself up with your own bootlaces.

Yes, that means that if demoparty audiences ever reach such a level of stupidity that compos are consistently won by a bouncing scroller saying "ZOMG this intro is only 55Kb!!!!1!", or an Amiga playing a prerendered animation of a monte-carlo-rendered photon-mapped naked woman, then we have to concede that those things really are what makes a great demo, at which point we can declare the scene dead and all go home.

If the creators set out to make a smaller-than-usual demo, then there's nothing wrong with choosing to judge it based on size - just as it's not wrong to judge a demo on humour value if the author intended it to be funny. BUT: it is stupid to judge demos on the basis of things they weren't trying to achieve. Don't vote down a big demo because it's big, don't vote down a serious demo because it isn't funny, and for fuck's sake don't vote down a demo because it uses too many DLLs. :-) Which is why my vote is for "don't show filesize unless the author specifically wants to promote that (which presumably they will, if it's a 1K intro in a 4K compo, or a 64K in a demo compo or whatever)".


Incidentally, a point which we've more or less skipped over but needs to be said: using file size as an indicator of how much precalc fakery a demo contains is really, REALLY dumb.

gasman put it well there.

gasman: my problem with the size-obsession is that the general perception seems to be "smaller = better", which just isn't true.