The state of the demoscene: 1991 - 2011
category: general [glöplog]
From someone who hates having to write code.
plek said it all
plek said it all
you are all nyashechki here and i love you so much (esp. Ferris!)!
Bearing in mind - with all flavours of IDE today (mostly "Visual *") and their wysiwyg, point & click setup the last time I actually saw some standalone x86 asm (other than injected into code for db's etc) is kinda indicative of the age of the language.
i often hear coders say, "i want to make a demo but i dont have an exporter" or "im making a tool but i dont have any artists to use it". wtf. :)
see, the irony is some other scenes - "creative coding", openframeworks, processing - have exploded in popularity & interest over the years precisely by not relying on assets, tools, hugely complex routines, 3d artists etc. - but by treating the coder as the artist, doing a lot by hand, designing with code, and using & twisting simple building blocks to make something cool (and they _dont_ take a year to make something). kindof like what democoders used to do.. :) and kindof like what a lot of e.g. 4k coders are doing now. for some reason when people go to think about 64k & demo they throw all that away.
personally i love my tools, asset pipeline, artist input etc - but in the last few years we've come to rely on big heavy art assets less and less, and rely on careful design with effects more and more. our demo release from 2011 had approximately 1 art asset of note, and our 64k had none at all. an obj loader would have been just fine. if anything, i find democoding a whole lot more fun now i dont treat it as writing code to display other people's work as fast&prettily as possible. that was too close to the day job. :)
so no, i dont agree that a good demo has to be an exercise in tools and engine coding. peoples idea of what a demo has to be or how it has to be made is shaped by the leading groups of the time - and when you're surrounded by e.g. farbrausch who excell at pricesely those tools&engine tasks, you're bound to be swung towards that direction. on the other hand, mfx/kewlers & asd did pretty well without. copy them.
see, the irony is some other scenes - "creative coding", openframeworks, processing - have exploded in popularity & interest over the years precisely by not relying on assets, tools, hugely complex routines, 3d artists etc. - but by treating the coder as the artist, doing a lot by hand, designing with code, and using & twisting simple building blocks to make something cool (and they _dont_ take a year to make something). kindof like what democoders used to do.. :) and kindof like what a lot of e.g. 4k coders are doing now. for some reason when people go to think about 64k & demo they throw all that away.
personally i love my tools, asset pipeline, artist input etc - but in the last few years we've come to rely on big heavy art assets less and less, and rely on careful design with effects more and more. our demo release from 2011 had approximately 1 art asset of note, and our 64k had none at all. an obj loader would have been just fine. if anything, i find democoding a whole lot more fun now i dont treat it as writing code to display other people's work as fast&prettily as possible. that was too close to the day job. :)
so no, i dont agree that a good demo has to be an exercise in tools and engine coding. peoples idea of what a demo has to be or how it has to be made is shaped by the leading groups of the time - and when you're surrounded by e.g. farbrausch who excell at pricesely those tools&engine tasks, you're bound to be swung towards that direction. on the other hand, mfx/kewlers & asd did pretty well without. copy them.
By the way, I feel the PC demoscene has stagnated quite a bit since around 2002-2003. Around that time I think a lot of 'oldschool' coders quit the scene simply because they were getting jobs and so on, but also out of frustration of the limited programmability of the GPUs at that time.
Currently we have a few talented coders left (smash, navis, iq and so on) who continue to enjoy pushing limits, thankfully. Having a dayjob that relates to computer graphics helps, probably. But anyway, a lot of other releases nowadays look like they could have been released 10 years earlier as well. I'm not sure why.
Currently we have a few talented coders left (smash, navis, iq and so on) who continue to enjoy pushing limits, thankfully. Having a dayjob that relates to computer graphics helps, probably. But anyway, a lot of other releases nowadays look like they could have been released 10 years earlier as well. I'm not sure why.
Smash: I think that's also why a lot of people have gravitated to the 64k intros in the past, simply because they were mostly procedural (and didn't necessarily required any werkzeug-level tool to build).
smash: good point(s).
plek: I don't thing we really disagree at all. :) There is no question that getting a team-effort demo up and running with all hands on deck takes a massive effort and a lot of people + time.. which is why you don't really see any of those types of demos anymore. Hell, why do you think the last few Excess-demos have been basically just me and Kusma? Because it's way easier.
And of course, your point about 4k intros are entirely correct (apart from the bit where you say there has been an "explosion of 4Ks", which, according to the stats, clearly didn't happen -- though the point comes across anyway :) - ask any 4k coder why they do it and they'll most likely give you one of two (or both) answers: 1) I can do it myself, and 2) just code art, no asset-mucking-about. There are exceptions to this of course (Portal Process and TBC comes to mind), but mostly, it's about not having to rely on a large team, doing it at your own pace and practicing the techiques you want to work with.
..and then what Smash said above. Visuals over tools = win.
And of course, your point about 4k intros are entirely correct (apart from the bit where you say there has been an "explosion of 4Ks", which, according to the stats, clearly didn't happen -- though the point comes across anyway :) - ask any 4k coder why they do it and they'll most likely give you one of two (or both) answers: 1) I can do it myself, and 2) just code art, no asset-mucking-about. There are exceptions to this of course (Portal Process and TBC comes to mind), but mostly, it's about not having to rely on a large team, doing it at your own pace and practicing the techiques you want to work with.
..and then what Smash said above. Visuals over tools = win.
I kinda stumbled over an important point: we don't really see "big team demos" any more, and even though that should theoretically open the gates for more and more quickly made prods, we don't. That's a bit alarming. If we could only get the people that used to make many (and great) demos to get over the imaginary hurdle of thinking that a big team, time and effort is needed, then we'd have a bunch of people being creative and making demos again.. and I'd love to see that happen.
funnily enough, the scene's oldschool roots hold it back in some respects. for example, the "megademo" formula hasn't really changed in years and i dont know if its even desirable anymore - for the creator or the ones watching.
i'd personally rather see more smaller demos which explore 1-2 nice effects really well with an effort put into flow and design. processing/openframeworks/"creativecoding"-style pieces but a lot more high end and technically better. there's a lot of coders in the scene capable of that.
BTW, there's a bunch of pretty good opensource frameworks to get started - like kusma's - and 3d import libraries like assimp.
i'd personally rather see more smaller demos which explore 1-2 nice effects really well with an effort put into flow and design. processing/openframeworks/"creativecoding"-style pieces but a lot more high end and technically better. there's a lot of coders in the scene capable of that.
BTW, there's a bunch of pretty good opensource frameworks to get started - like kusma's - and 3d import libraries like assimp.
I think it was Rasmus who once pointed out that when the coding itself stops to be the primary challenge, creativity and inspiration can become a major hurdle. It did for me, which is why I've not seldomly lost myself in adding more "engine" code and all kinds of features I had no idea what to do with or at least didn't constructively amount to anything on screen to this very day. Realizing that you actually have no idea what to make tears away any hope of being pragmatic and to the point, i.e. getting something done :)
I'm sure this doesn't just apply to me, but stops others theoretically capable of coding a good demo as well. Even if you know you really don't need a complete pipeline and 60 artists -- because I know I never want to work like that outside of a professional environment.
I'm sure this doesn't just apply to me, but stops others theoretically capable of coding a good demo as well. Even if you know you really don't need a complete pipeline and 60 artists -- because I know I never want to work like that outside of a professional environment.
(in response to Gloom, that was)
(also teehee 'assimp', yes, again)
(also teehee 'assimp', yes, again)
Quote:
our demo release from 2011 had approximately 1 art asset of note
Except for the tool used for editing, cinematography, compositing, etc. which in 2011 suddenly does all the difference in the world.
gargaj: im not denying that - but it was a statement on the concept that you need a lot of work on a 3d exporter to make a demo. :)
I think that the exporter is a default example -- the point applies to pretty much any type of code used to work with assets, runtime or offline. But it's still true that "all that" is only necessary if one wants it to be.
One example from my own experience which kickstarted my energy for making demos again is Scyphozoa. It's a single scene, a single deformable object, a skybox, a few random particles, camera controls and two modifiers for the sphere (deformation strength and frequency).
That's pretty much it.
Making something out of basically nothing made demomaking FUN again, and even though the end result might not be in the same class as megademos of the past, it got shown at film festivals and got critical reviews from people both inside and outside of the scene. I think if more people did small projects like this, and just surrendered to the "let's have fucking FUN with it!"-philosophy, the scene as a whole would be a way better off. IMHO. :)
That's pretty much it.
Making something out of basically nothing made demomaking FUN again, and even though the end result might not be in the same class as megademos of the past, it got shown at film festivals and got critical reviews from people both inside and outside of the scene. I think if more people did small projects like this, and just surrendered to the "let's have fucking FUN with it!"-philosophy, the scene as a whole would be a way better off. IMHO. :)
gargaj: but for all of those things, you can just use GNU Rocket, and you'll be laughing all the way to the prize ceremony.
Gloom: blunderbuss did exactly the same for me. making something cool out of one effect over about a week was a great kickstart.
Quote:
Making something out of basically nothing made demomaking FUN again, and even though the end result might not be in the same class as megademos of the past
See that's the problem here. There are big demos and small demos - big groups can make big AND small (after which they usually explain how much fun it was to do a small demo), while small groups can only make small, and it's frustrating.
Quote:
but for all of those things, you can just use GNU Rocket
Find me a graphics artist / designer (who is ONLY a graphics artist / designer, and not a coder-turned or musician-with-spare-time) who's willing to set up coloring and lighting with it and sure, we can talk.
You should probably also account for the experience of the people involved. The reason that (e.g.) Excess and Fairlight can quickly turn out GOOD 'small' demos, is the quality of their ideas (even if it's small ideas). And that quality comes from years of experience.
A group lacking that experience has a much harder time of it - to everyone else their single scene demo looks bad/isn't very interesting, and clearly they didn't put a lot of effort in. So we must try to compensate with effort, which is hard, but leads to experience in the long run.
Someone mentioned scope. It's clear to me that the amount of experience you need to have to produce good demos have gone way, WAY up since 1995.
And acquiring that experience is hard for a newcomer.
A group lacking that experience has a much harder time of it - to everyone else their single scene demo looks bad/isn't very interesting, and clearly they didn't put a lot of effort in. So we must try to compensate with effort, which is hard, but leads to experience in the long run.
Someone mentioned scope. It's clear to me that the amount of experience you need to have to produce good demos have gone way, WAY up since 1995.
And acquiring that experience is hard for a newcomer.
revival: Some of the stuff being done in 1995 was also tricky as hell and I think there was far fewer knowledge sharing being done back then.
Quote:
True, but keep it in perspective -- what was considered good in 1995 is something entirely different from what's considered good today, meaning that the line should remain fairly constant. Or put differently: in 1995, I saw "Dope" and was blown away. In 2011 I saw "Numb res" and was blown away. Had "Dope" been released in 2011 it would have been widely regarded as ugly and old-looking (with a great soundtrack though :), and had "Numb res" been released in 2005, people's heads would have exploded.Someone mentioned scope. It's clear to me that the amount of experience you need to have to produce good demos have gone way, WAY up since 1995.
Quote:
Eyh! :D(who is ONLY a graphics artist / designer, and not a coder-turned or musician-with-spare-time)
I just updated the article with information about demo parties and their correlation with releases for those who are interested in that. Interesting findings.