On using tools like Notch for making demos...
category: general [glöplog]
Ok, then let's drop the rediculous rankings, prizes etc from compos.. deal?
Just have a cozy forum where everbody "hat sich ganz toll lieb" instead of real compos.
Seems much more fitting to the vibe i am getting from current demoscene anyway
Seems much more fitting to the vibe i am getting from current demoscene anyway
Quote:
also, the ugly demos made with tools kinda suggest it isn't all that 'press this button for a fairlight wannabe demo'-easy as some demoscene puritans make it sound
Exactly. Which makes it painfully obvious to me that "democratization" in the sense of "letting in" folks that could not "afford the entrance fee" prior to emergence of readymade engines because of lack of technical knowhow probably does not result in more good demos. "Ugly demos" made with demotools simply would not have been made at all without those demotools. What it boils down to imho is this: imagine Notch (or something like that) was 100x easier to use. Now, do you think that would result in a new stream of good demos or a new stream of horrible demos?
Same with AI. Only turned up a few (hundred) notches. My main problem with AI demos is not connected to the problem I have with AI in general. My problem with AI demos is that they are objectively crap, but they are often made and loved by people who, well basically can't seem to distinguish between crap and cake. When cake was all we've been served I thought we all liked cake. Now, they make something that they think resembles cake and seemingly really think it IS cake. It's just more very low hanging fruit, a stronger invitation for low effort, low talent crap. And, no I'm not trying to twist this into another AI discussion, so be free to disregard the last paragraph.
Quote:
I do enjoy occasional Notch/Tooll/Enreal/Unity/etc demo, but for all I care they could have been done with Blender/Houdini/whatever and rendered to video. (I suspect that's how (rendered to video) most of the audience will see them anyhow). Oh, but then (if it's not a realtime demo but a video)
I wonder how much of a thing this is nowadays? The ”it’s an animation/video” thing, that is.
I mean looking at modern AAA games made with engines like Unreal on modern hardware.. Some of those look pretty darn photorealistic, and I don’t think your average joe goes ”it must be a pre-rendered animation as it looks so good” anymore.
In the demoscene i guess you could still render your Unreal demo as a video if you wanted to save some disk space, though…
Uncle-X: Unreal build sizes have reduced considerably with recent versions
Arm1n i know. I’ve been slowly developing a game with UE the past few years. The release build (Windows, UE 5.3.2) was only around 350 megs when i had zero assets are included. My comment was a slight jab at a certain group known for releasing ”somewhat” bloated UE demos at Assembly in the past ;)
Im trying to make a demo with cables for Evoke 🙂
cables in cables
Hi there, Devil's advocate here!
I do enjoy occasional V2/4klang/Protracker/etc tune, but for all I care they could have been done with Ableton/Cubase/whatever and rendered to audio.
Quote:
I do enjoy occasional Notch/Tooll/Enreal/Unity/etc demo, but for all I care they could have been done with Blender/Houdini/whatever and rendered to video.
I do enjoy occasional V2/4klang/Protracker/etc tune, but for all I care they could have been done with Ableton/Cubase/whatever and rendered to audio.
Quote:
Im trying to make a demo with cables for Evoke 🙂
HMU on Signal if you need some tips or help.
you mean that group that included a 1.2GB forest asset pack in their UE5 demo for ONE TREE? :P
Quote:
Quote:Im trying to make a demo with cables for Evoke 🙂
HMU on Signal if you need some tips or help.
I might if something useful starts happening, for now I have a cube and a tune!
add a tunnel and you're ready
Quote:
Uncle-X: Unreal build sizes have reduced considerably with recent versions
Well, 790MB for a one-minute demo (no matter how cool it looks) with a bunch of walls/corridor/eyeballs assets. Not exactly my definition of "reduced" :)
I got into coding with C64 Basic and using it got me curious on how to make games like the ones in the store or at the arcade as that was clearly not possible to achieve in Basic.
Then I got into AMOS on Amiga and more stuff could be done, but still not as good as the stuff in the store or the arcade. So I needed to learn assembly finally.
My point is that it should be fine to start at a high level using a tool and then as you discover the limits of that tool, you may be curious to dig deeper.
Then I got into AMOS on Amiga and more stuff could be done, but still not as good as the stuff in the store or the arcade. So I needed to learn assembly finally.
My point is that it should be fine to start at a high level using a tool and then as you discover the limits of that tool, you may be curious to dig deeper.
Quote:
I got into coding with C64 Basic and using it got me curious on how to make games like the ones in the store or at the arcade as that was clearly not possible to achieve in Basic.
S.E.U.C.K.
Quote:
And also: Why would anyone doing an impressive top-notch Unreal/Unity demo bother to release this in context of the demoscene instead of uploading to YouTube and potentially getting much more attention?
Same goes for any other prod/artwork/etc.
Seriously, why does the demoscene have a monopoly on a certain style of content? You can make demoscene-style content outside the context of demoparties, Pouet, etc.
no one is stopping you
Quote:
Well, 790MB for a one-minute demo (no matter how cool it looks) with a bunch of walls/corridor/eyeballs assets. Not exactly my definition of "reduced" :)
Fra: I was referring to a minimal build without content. What demo creators make based on that is a whole other story, of course.
Quote:
Seriously, why does the demoscene have a monopoly on a certain style of content? You can make demoscene-style content outside the context of demoparties, Pouet, etc.
So then what sets demoscene productions apart from "outside" communities anymore?
Quote:
So then what sets demoscene productions apart from "outside" communities anymore?
We have pouet.
Kaneel wins. Thread closed :)
First of all, I fully admit that my view of these issues of creation and legitimacy within the demoscene is entirely subjective.
Throughout my “career” as a scener, I have only used tools and engines developed by other sceners, which puts me in a slightly strange position, somewhere between “fully custom 3D engine” and “off-the-shelf technology”.
My first demos, some more memorable than others, relied on scene “players”. Around the turn of the 2000s, this was not necessarily considered the most prestigious way of making demos. Looking back, I think that was a perfectly acceptable position.
From 2013 onwards, I returned to the scene using GameStart3D, an engine developed by Xbarr and based on his experience in both the game industry and the demoscene, although it was fundamentally designed for making video games. These few prods made with GameStart, the most successful of which reached third place at Evoke, allowed me to test my skills in 3D development, or, more accurately, as a technical artist. All my demos from that period were a mix of polygonal 3D assets, 3D scenes assembled in a custom tool, Squirrel code (a derivative of Lua) and a fair amount of GLSL tinkering.
Eventually, driven by a blend of hubris and ambition, GameStart3D became HARFANG 3D through two or three major rewrites. Alongside our attempts to turn it into a commercial product, with mixed results, and while I was gradually learning the engine and Lua, which had replaced Squirrel, I continued to release a few prods that were more or less appreciated. I say this without any bitterness: that is simply how the demoscene works.
Between these two periods, I also spent time making Amiga and MegaDrive demos, all written in C, sometimes alone and sometimes with a partner in crime, while ignoring the well-meaning advice of friends telling me to “switch to assembly”.
So, in all honesty, I consider myself an average programmer who trades a lack of deep technical expertise with a certain degree of artistic skills and an ability to polish my productions until they reach a standard I am reasonably happy with.
To sum it up, my entire career as a scener has relied on tools that were already quite mature, but nowhere near the level of maturity and functionality offered by monsters such as Unity and Unreal. As a result, I tend to judge prods made with those engines with a certain lack of generosity. Some are absolute masterpieces; others are complete garbage ... at least in my eyes.
To make this admittedly unfriendly judgement even more biased, I also recognise that I am negatively influenced by Unity’s particularly aggressive commercial strategy. I am equally saddened by the fact that Fortnite’s apparently endless money-printing machine does not prevent Epic from carrying out massive layoffs from time to time. This typical illustration of what I consider predatory capitalism would almost make me choose Godot over Unity if I ever decided to make demos with an off-the-shelf engine.
At this point, one might assume that I hold a radically anti-AI position. After all, AI somehow manages to combine IP theft, the exploitation of clickworkers, fossil fuel and water consumption, and the destruction of entire sectors of the economy. And yet, I remain curious about what these systems (I find the word “tools” too limited to think about what they are) might bring to digital creation in general. I must admit, however, that with one or two exceptions, Pouet’s list of “AI prods” looks like a shit show to me.
In any case, I would like to see more prods based on custom engines. But having participated in the creation of one myself with my dear demoscene fellows, I know only too well how many years it takes to build such a thing.
For now, hope may come from the 64K, 8K and 4K competitions, which continue to push the limits of hardware that appears to have none (ever since GPUs “killed the scene” for the first time).
Ultimately, I think that clearly displaying a production’s tool dependencies during party screenings should be an absolute requirement, as is already done at Revision, for example. Everyone can then make up their own mind about the value of a prod. Demozoo’s tag system seems to be moving in the same direction, even though it is not always used consistently (and I am not blaming anyone for that).
Regarding the use of AI, I do not feel entitled to judge anyone. I understand the absolute disgust, fear and sadness expressed by those who see this technology colliding with entire parts of our society. I share some of those fears. But having already lost my job, and with fairly limited prospects of finding another position as a technical artist at the age of 51 while living in a small French city, I decided to challenge myself by pursuing a PhD. It is currently in progress at a university in Paris that was generous enough to welcome my project
.
I could never express enough gratitude for everything the demoscene has given me: a field for experimentation, access to real-time 3D engines ten years before Unity even existed, and meeting extraordinary people. I trust in its ability to evolve, just as it did when moving from the C64 and Amiga to the PC, adapting to GPUs, adopting Pouet.net and then Demozoo, moving from IRC to Discord, and so on.
AI represents a new challenge, with a very risk of a split within the community, a decline in motivation to create, or the loss of certain practices and skills. But we have survived many technological disruptions, often while showing the way forward. So perhaps it is possible to imagine that this will continue ?
Sorry for this very long contribution, especially to those who made it all the way to the end. I do not have a ready-made moral conclusion to offer, and I admit that my position contains some potentially contradictory aspects.
Love.
Throughout my “career” as a scener, I have only used tools and engines developed by other sceners, which puts me in a slightly strange position, somewhere between “fully custom 3D engine” and “off-the-shelf technology”.
My first demos, some more memorable than others, relied on scene “players”. Around the turn of the 2000s, this was not necessarily considered the most prestigious way of making demos. Looking back, I think that was a perfectly acceptable position.
From 2013 onwards, I returned to the scene using GameStart3D, an engine developed by Xbarr and based on his experience in both the game industry and the demoscene, although it was fundamentally designed for making video games. These few prods made with GameStart, the most successful of which reached third place at Evoke, allowed me to test my skills in 3D development, or, more accurately, as a technical artist. All my demos from that period were a mix of polygonal 3D assets, 3D scenes assembled in a custom tool, Squirrel code (a derivative of Lua) and a fair amount of GLSL tinkering.
Eventually, driven by a blend of hubris and ambition, GameStart3D became HARFANG 3D through two or three major rewrites. Alongside our attempts to turn it into a commercial product, with mixed results, and while I was gradually learning the engine and Lua, which had replaced Squirrel, I continued to release a few prods that were more or less appreciated. I say this without any bitterness: that is simply how the demoscene works.
Between these two periods, I also spent time making Amiga and MegaDrive demos, all written in C, sometimes alone and sometimes with a partner in crime, while ignoring the well-meaning advice of friends telling me to “switch to assembly”.
So, in all honesty, I consider myself an average programmer who trades a lack of deep technical expertise with a certain degree of artistic skills and an ability to polish my productions until they reach a standard I am reasonably happy with.
To sum it up, my entire career as a scener has relied on tools that were already quite mature, but nowhere near the level of maturity and functionality offered by monsters such as Unity and Unreal. As a result, I tend to judge prods made with those engines with a certain lack of generosity. Some are absolute masterpieces; others are complete garbage ... at least in my eyes.
To make this admittedly unfriendly judgement even more biased, I also recognise that I am negatively influenced by Unity’s particularly aggressive commercial strategy. I am equally saddened by the fact that Fortnite’s apparently endless money-printing machine does not prevent Epic from carrying out massive layoffs from time to time. This typical illustration of what I consider predatory capitalism would almost make me choose Godot over Unity if I ever decided to make demos with an off-the-shelf engine.
At this point, one might assume that I hold a radically anti-AI position. After all, AI somehow manages to combine IP theft, the exploitation of clickworkers, fossil fuel and water consumption, and the destruction of entire sectors of the economy. And yet, I remain curious about what these systems (I find the word “tools” too limited to think about what they are) might bring to digital creation in general. I must admit, however, that with one or two exceptions, Pouet’s list of “AI prods” looks like a shit show to me.
In any case, I would like to see more prods based on custom engines. But having participated in the creation of one myself with my dear demoscene fellows, I know only too well how many years it takes to build such a thing.
For now, hope may come from the 64K, 8K and 4K competitions, which continue to push the limits of hardware that appears to have none (ever since GPUs “killed the scene” for the first time).
Ultimately, I think that clearly displaying a production’s tool dependencies during party screenings should be an absolute requirement, as is already done at Revision, for example. Everyone can then make up their own mind about the value of a prod. Demozoo’s tag system seems to be moving in the same direction, even though it is not always used consistently (and I am not blaming anyone for that).
Regarding the use of AI, I do not feel entitled to judge anyone. I understand the absolute disgust, fear and sadness expressed by those who see this technology colliding with entire parts of our society. I share some of those fears. But having already lost my job, and with fairly limited prospects of finding another position as a technical artist at the age of 51 while living in a small French city, I decided to challenge myself by pursuing a PhD. It is currently in progress at a university in Paris that was generous enough to welcome my project
.I could never express enough gratitude for everything the demoscene has given me: a field for experimentation, access to real-time 3D engines ten years before Unity even existed, and meeting extraordinary people. I trust in its ability to evolve, just as it did when moving from the C64 and Amiga to the PC, adapting to GPUs, adopting Pouet.net and then Demozoo, moving from IRC to Discord, and so on.
AI represents a new challenge, with a very risk of a split within the community, a decline in motivation to create, or the loss of certain practices and skills. But we have survived many technological disruptions, often while showing the way forward. So perhaps it is possible to imagine that this will continue ?
Sorry for this very long contribution, especially to those who made it all the way to the end. I do not have a ready-made moral conclusion to offer, and I admit that my position contains some potentially contradictory aspects.
Love.
Thanks for the interesting read, @fra (and wish you the best of luck in finding a new job!)
Here are some "random thoughts" regarding tools (and high level engines): (background) I wrote my first scroller in 6510 asm (on a C64 in 1988), the first sine scroller in 68k asm (on an A500 in 1989). Point is, that's how I learnt programming (i.e. from the ground up) and I therefore used to say "learn assembly first, then you know _why_ you need higher level languages when things become more complex".
Nowadays I am not so sure about that anymore. Actually, I am fairly certain that it's the other way around now, i.e. "learn a high level tool first, and only if you are missing low level functionality and/or want to understand what makes things tick, learn lower level languages (like C and assembly)".
Technology is so complex nowadays that if you start at the lowest level, chances are high that you either get stuck there, or lose interest because it takes so much effort to get to the higher levels (that being said: I am always happy to see younger coders write amazing N64 hacks or EFI games and the like, these kinds of people fortunately still exist!).
My ideal demotool is something that is more like a Shadertoy-on-steroids (with e.g. color, envelope, timeline editors) but generates lower level code which can then be examined/studied and be included in a larger (handwritten) project (a demo, or a game), and be executed without an "engine-runtime".
I am still working on that (but with low prio since I got so many other projects on my plate, in addition to a (part-time) job).
So far I've used it to build some simple demos which were shown on exhibitions (i.e. not scene-related) but it's slowly getting there (hopefully).
One thing I am still a bit undecided about is how this should link to another codebase/process during development. One way (a) would be to have a small interface library that talks to the editor (and can later be removed for the final release), the other (b) would be to write editor plugins that run basically the same code as the final product. (a) would probably be preferable, I guess (?)
And well, the reason I'm a bit torn about this is that (due to the way I learnt things long ago) demos always used to be quite a mess and any kind of tool integration requires at least a little bit of formalism (like "these are my objects", "these are the position / color / .. attributes and their ranges", ..).
All I know (well, just my opinion) is that entirely giving up on lower level code can't be it in the long run (which excludes fully self contained engines).
Last but not least, about LLMs. Also torn about that. Tried it locally to see what the fuzz is about, and yes, they can be helpful in understanding things (when using them more like a search engine that can also generate code snippets) but I also let it generate e.g. a fluid simulation (which worked perfectly well) but meh, it felt like I had downloaded someone elses source code. Wouldn't use that.
Just thinking out loud (and I am mainly thinking about future generations here and what could be done to get them up to speed without providing ready-made solutions for every effect/aspect imaginable)
/thinkingoutloud
Here are some "random thoughts" regarding tools (and high level engines): (background) I wrote my first scroller in 6510 asm (on a C64 in 1988), the first sine scroller in 68k asm (on an A500 in 1989). Point is, that's how I learnt programming (i.e. from the ground up) and I therefore used to say "learn assembly first, then you know _why_ you need higher level languages when things become more complex".
Nowadays I am not so sure about that anymore. Actually, I am fairly certain that it's the other way around now, i.e. "learn a high level tool first, and only if you are missing low level functionality and/or want to understand what makes things tick, learn lower level languages (like C and assembly)".
Technology is so complex nowadays that if you start at the lowest level, chances are high that you either get stuck there, or lose interest because it takes so much effort to get to the higher levels (that being said: I am always happy to see younger coders write amazing N64 hacks or EFI games and the like, these kinds of people fortunately still exist!).
My ideal demotool is something that is more like a Shadertoy-on-steroids (with e.g. color, envelope, timeline editors) but generates lower level code which can then be examined/studied and be included in a larger (handwritten) project (a demo, or a game), and be executed without an "engine-runtime".
I am still working on that (but with low prio since I got so many other projects on my plate, in addition to a (part-time) job).
So far I've used it to build some simple demos which were shown on exhibitions (i.e. not scene-related) but it's slowly getting there (hopefully).
One thing I am still a bit undecided about is how this should link to another codebase/process during development. One way (a) would be to have a small interface library that talks to the editor (and can later be removed for the final release), the other (b) would be to write editor plugins that run basically the same code as the final product. (a) would probably be preferable, I guess (?)
And well, the reason I'm a bit torn about this is that (due to the way I learnt things long ago) demos always used to be quite a mess and any kind of tool integration requires at least a little bit of formalism (like "these are my objects", "these are the position / color / .. attributes and their ranges", ..).
All I know (well, just my opinion) is that entirely giving up on lower level code can't be it in the long run (which excludes fully self contained engines).
Last but not least, about LLMs. Also torn about that. Tried it locally to see what the fuzz is about, and yes, they can be helpful in understanding things (when using them more like a search engine that can also generate code snippets) but I also let it generate e.g. a fluid simulation (which worked perfectly well) but meh, it felt like I had downloaded someone elses source code. Wouldn't use that.
Just thinking out loud (and I am mainly thinking about future generations here and what could be done to get them up to speed without providing ready-made solutions for every effect/aspect imaginable)
/thinkingoutloud
We used to call freeriders, wannabes and users of demomakers: lamers. If you can't code, get a coder on board of your group.
