Design and Programming - Friends or Foes?
by Axel of Brainstorm

Download PDF version:


ZINE thought it'd be about time to discuss the state of design in today's demoscene productions. Therefore, ZINE gathered some well respected individuals of the scene in graphics, programming and design to shed a light on various aspects of the creation of demos, the questions arising in graphics and design, as well as the workflow and evolution of those processes.

Participants of the round table are Zoom of Conspiracy ("Memento", "Chaos Theory"), Xenusion of Plastic ("Final Audition"), Fiver2 of Farbrausch ("The Popular Demo", "Debris"), Navis of Andromeda Software Development ("Iconoclast", "LifeForce"), Keops of ol' Equinox and the recently created group Orb ("Virtual Escape", "Kings of the Playground", "Frameskool"), and Archmage of Andromeda ("Nexus 7", "Noumenon").

Design - driven by today's possibilities?

Back in the '80s and '90s, machines were programmed to do things people have not seen before. Programmers came up with tricks and visions. Today it seems to be the way that code plays a smaller role, and that design has taken over completely. "First off, I think that you need to distinguish sharply between the '80s and the '90s," comments Archmage. "The statement is correct when speaking about the pioneer age of the demo scene, namely the '80s. Back then, design wasn't really a demoscene word. Graphics in the '80s seemed to be dictated by the fact that home computers all of a sudden could display colours. And once you had colours, you wanted to show colours no matter how damn random they were."



"Design became relevant in the demoscene in the early 1990s, and if one is to try to pinpoint the exact demo where it happened, the one that springs to mind is Mental Hangover by Scoopex," he continues. "In relation to the question, it is kind of interesting that this was actually a coder-designed demo. And this seems to be a trend that moves throughout the scene ever after. When Slayer decided on keeping the same background throughout the whole of Mental Hangover, this was actually a way of showing off code - which incidentally turned out to be design as well."


Frameskool by Equinox

"The transition to demos designed by actual designated designers, mostly graphicians, happened around 1992 or so. One group that needs mentioning is of course Melon Dezign, as these guys made demos that at one point were more designed than coded. Looking at my favourite Melon demo, Humantarget, you see a mix between parts that are coded and parts that are mere brainchildren of Seen - and that may be called design. In later demos like The Romantic Demo from 1993 they basically told the coder to fuck off. From then on, it was all about style, in the most dubious sense of the word."


Archmage

"I do think, however, that this represents a smaller tendency, and that as a whole one might say that designer equals coder rather than graphician in most high quality productions. Why? Ideas and effects are closely linked with design. If you look at any good demo the design that lies embedded in the effects is far more powerful than the choice of colour for the side border."

"I guess a relevant difference between now and how things used to be is that a coder doesn't have to break his neck anymore to actually show stuff on the screen. Consequently, the focus can now be allowed to shift towards a purer degree of design. This is probably the basis for your question. But, in my opinion, the coder has always been in the driver seat, visually."



Keops agrees with Archmage's introductory statements. "Back then, programming a computer was a totally new thing," he says. "It was very challenging and had this ‘let's see what computers can do’ attraction. Sceners were pioneers and discovered an unknown territory. That period is over. Nowadays, most sceners get their code out of Siggraph papers, DirectX and Nehe tutorials, or GPU gems books. Big money, mass market and gaming industries came along and changed it all. From isolated little geniuses tweaking their fixed hardware in their room at nights we now have teams of 30 engineers working full time and paid to develop generic engines over three or four years with budgets now going above dozens of millions of dollars."


Debris by Farbrausch

"I can name dozens of technically impressive demos from the '80s and '90s, whereas I can hardly name any impressive PC demo released those last years." He's quick to add, smiling benignly: "However, it's much more easy to name interesting demos for their concept or design - when it's not stolen." These days, Keops sees the technical battle in the size constraint arena.

Zoom partly agrees. To him it's true that most of today's demos focus on design. Some say the shift from code to design happened sometime in the late '90s. Gaming on the PC really started to become mainstream and advancements in technology began to push the limits way too far, up to the point where it didn't really matter whether you could move 312 or 313 dots on the screen. So demo-makers had to come up another way to beat their buddies on the big screen, thus came the obvious idea to make it not only look geeky but also pretty. "Nowadays, the geeky part is also starting to fade," he adds with a smile.

"The part where I only partly agree is because of the Amiga," Zoom continues. "Now, I'm not really an expert in Amiga demos, but it seems there were much more nicely designed ones from that time. I guess the reason for this could be that Amiga being a much more closed platform than the PC, coders had already reached its limits by that time, so they started to focus on design much earlier."



"Then again, it seems to me that demos on the C64 only started to shift into the design-era just recently, despite being the oldest and most well known platform of all. Dunno, maybe all the effects that could ever be made have already been made, so they got some inspiration from the younger platforms."


Final Audition by Plastic

Xenusion thinks it's a false statement to say that the demoscene of the '80s and '90s was mostly code-dominated while a lot of demos today have their focus on design. "This fairytale just comes from people who aren't able to do something that is on par with today's demos," he explains. "The difference is just that now we have code AND design and not just plain code without any design. So it's just an evolutionary step forward since no one would really appreciate simple single FX scenes bundled together like a slideshow these days. Time has changed and demos have progressed too."



Greek programmer Navis says that the demoscene has gradually shifted from a mere show of effects and hacks to an expression that goes beyond the constraints of the medium. "As a result, the emphasis is a lot more on the design and storytelling than on the mechanics."

Designer Fiver2, whose work included the smash-hit demo Debris by Farbrausch, sees the appeal of the demoscene in the combination of these two worlds - technique and creativity (or art, if you will). "A pure code or pure design demo can be nice but is also missing half the fun," he comments. "To me the demoscene has always been at its best when code, visuals and sound are combined to become bigger than their parts. So yes, I appreciate that today's design in demos is raising the bar for the code side."

But what are the biggest differences for the individuals working on the productions, between making graphics for a production and making the design?

"These are very different things," states Navis. "The design comes first and graphics later. Let's say that the equivalent in terms of cinema would be to say that the design is the director and the graphics the actors. You need both, of course."


Fiver2

Fiver2 is taking it one step further: "Making graphics is work. Designing is fun. Of course making graphics can also be creative, but content creation in general mainly is assiduity to me. In a perfect world I would solely create concepts, effect ideas, do the cutting, fine-tuning and directing. Yet, in this world three-fourths of demo-making keep me at boring content creation."

"If you're doing graphics, you're more or less free, while making a design has much more limits," adds Xenusion. "There are limitations in code, time, size, personal aspects, and probably some other areas."



"For me, design is much more important than graphics, but unlike graphics, it's not really something straightforward," comments Chaos Theory designer Zoom of Conspiracy. "Design means the look and feel which I have in mind for that particular demo, and I (should) have that before even creating the first pixel. Later in the production, design becomes more like direction and it includes, among other things, stuff like the demo's theme or message, the colour scheme, pacing, and ambience, including cutting and camerawork, or harmony between video and audio, also known as sync. Design is also much more dependent on inspiration than the individual graphic elements. Graphics are then created with the main design in mind, but if you have a solid design and do your work true to that dream of yours, it doesn't really matter what the graphic elements themselves are. You just have to make them fit."

On a side note, some people confuse the meaning of "design", and think of transparent, flashy, overlay texts, white diagonal lines, and dirty black borders. While those contribute to the overall look of a demo, they are merely "graphics" in Zoom's book.


Iconoclast by ASD

Archmage responds: "To be quite honest, and in relation to what I have already stated, I can hardly claim responsibility for the design in the Andromeda productions. True, my work has always been about the 2D and 3D art, but I just do small pieces in a bigger puzzle. I consider Hyde and Interphace to be the masterminds behind the Andromeda design that people used to talk about. Over the years, I have adapted a feel for what is fitting, according to the concept they come up with, and I take it from there."

Demos with great code and no design

Navis is a bit hesitant when thinking about the question whether it will be increasingly harder to create a demo solely with great code but without a gripping design. "Yes and no," he answers vaguely; the expression on his face reflecting his emotion while trying to pinpoint what exactly makes him feel uncertain. "There are exceptions for both cases so, on average, I would say that it is not getting harder or easier," he continues. "It is easier to make very impressive effects these days (based on code only) and there is a market for that. That market will never cease to exist."



According to Archmage's taste, a good demo is a demo driven by good effects. The more the demo ideal of the general public strays from this view - which is the current trend - the harder it will become to make a successful demo solely with great code. But this is all presuming that coders are aesthetically blank, and as he previously stated, he doesn't think this is the case. And on the other hand you have some coders that are actually so good that the code in itself just shines.

Xenusion's opinion is that there simply is no successful demo without design.

Keops thinks that we all grow blasé with code or impressive effects at some point, whereas it's harder to grow blasé with design, atmosphere and new concepts.


Keops

Zoom seconds Keops in that regard. "You can have the greatest engine of all times, but it's never going to be a successful demo if the content moved by that engine looks crap," he explains. "On the other hand, if you can code some witty or possibly never before seen effects, that would very well be a basis for a great demo."

Fiver2 even states that it's not only hard but impossible already. "Everything as big as 4k will need that final touch that makes something great look great," he comments. "Otherwise the majority just won't recognize it. People are superficial and the demoscene is nothing but pop culture. Fortunately, I love pop." He laughs.

Chaos of Farbrausch once said in a conversation with ZINE that his design skills are still on the level of the early '90s. The participants of the roundtable aren't too sure how important it is to work with a programmer who's got a feeling for both code and aesthetics/design.



Archmage can't resist chiming in with a joke: "What can I say? It's cool to hear that Chaos's design skills finally caught up with the early '90s. But yes, I think it is important - assuming that there is something like a pure designer out there. In many cases the coder represents the reality check of an effect. He can tell whether a certain idea is doable. But if this coder, in addition, can say: ‘that is doable, but will it not be even better if we do like this?’ you are a very lucky designer."

Fiver2 mostly feels lucky to work with coders, not interfering with his design too much. But often it is important to go for the same vision. Unfortunately, words are a rather rudimentary way to communicate ideas. And no doubt, a code/design one-man symbiosis like Memon or Navis is just perfect in the demoscene universe. "It bridges the gap of idea and execution, which is one of the biggest hurdles of getting the minds of coders and designers together," states Fiver2. "Same goes for design and music, by the way."

Keops, having a view for both code and design, thinks that having a coder who understands design is one of the most valuable assets in a team. "No matter how hard they try, artists and coders just don't speak the same language," he comments. "An interesting case is Noumenon by Andromeda, one of my favorite demos those last years. Hyde coded excellent things for this demo that unfortunately were not shown at their full potential at all. I have seen different versions of some effects, not shown in the demo, and I went like: ‘argh, you should have shown it with those settings, it's totally amazing!’ If Hyde had been a designer while being a coder, the whole demo would have been incredible."

And Keops, too, can't resist commenting on Chaos: "About Chaos's design skills, that would put Hyde 10 years ahead of him then. Looks like Andromeda eventually won and Sanity lost." Laughter.

Zoom takes the opportunity to state his view on that with a smile, too: "If we look at Farbrausch's productions I think the answer is obvious. It's not really that important. If the coder creates an effect, the designer can simply tell him how it could look better. Of course having some aesthetic skills on the coder side helps a lot, but everything can be sorted out with good communication in the group. Also, with the recent, or not so recent, trend of using demo tools, this is even less important."


LifeForce by ASD

"The best combination is to design and code yourself," says Navis. "If you cannot afford to do that, and you completely lack any skill for design, then the other solution is to find a person that does understand about design. Failing to do that, the last resort is to keep trying until you either learn and go with the flow or develop a completely new philosophy on design and blow everyone away!"

Xenusion thinks that it's quite a hypothetical question since the main coder is in most cases the person who tries to dominate the process, meaning he is making the design. "And regarding aesthetics, well, today it's very easy to get away with doing things that are not aesthetic. If you suck, then just claim it's art and fun - while all others don't have fun because they are too busy being so damn serious - and you're the moral winner; queen of the hearts." Take that with a grain of salt, or don't.

"With the aforementioned trend of demo tools, the coders' artistic involvement is being reduced close to none," thinks Zoom. This can be quite depressing because coding a demo tool doesn't produce immediate results. There is no "wow" factor, no satisfaction of work, and this can also become a factor on the crew's morale. Of course, later when the tool is finished and the demos start to flow, the satisfaction will be there, but it's a hard way until then.

Navis adds: "If I had to code somebody else's design - not just a percentage, but the whole lot; a whole demo from beginning to finish - I would feel rotten. Making demos would lose its meaning for me!"

Archmage doesn't think that coders feel limited by working with a designer. "Having that extra resource will always add to the demo, and most decent coders will see this. But of course a coder is in most cases free to do as he wishes, so if he wants to skip on both designer and design, he can."



According to Keops, the problem is probably more about mutual understanding and speaking the same language than about limitations. "A coder is usually not limited by a designer, he's rather pushed forward to make new things, regardless of the hardware limitations. The coder is usually the one who limits the designer, putting a stop to his megalomania."

Xenusion adds: "I can imagine that it might be hard to tell an external designer why you need all those 1459 bobs in a scene even if it looks out of place just to be able to say you have the longest… um, the most bobs on a screen."

The tools of the trade

Tools like Werkkzeug seem to make some more room for experimentation lately, with pieces like "868". It can be argued whether tools expand the possibility to experiment with design. Or would they have to become easier to use so that less technology-savvy artists could still get a chance to play around?

"The most interesting thing about demo tools is the phenomenon itself," says Keops. "Ever since Farbrausch initiated that tool trend, I have seen a lot of people working months or even years on their own tool without ever releasing anything in the end. Some people seem to see demo tools as goals, not as means."

To Archmage, everything made with Werkkzeug lacks "demo feeling". It reeks of German efficiency; it is what he calls cold and sterile, and he can't bring himself to liking it. He thinks that tools in general can be useful when making demos, and sure, Andromeda has some tailor made tools as well, but in the end Andromeda's work will always be about the demo itself. "Artistically, I have much more respect for the Navis approach," adds Archmage. "Everything he does is hand-made, and it shows in the variety, the charming flaws and the brilliance of
the stuff he does."



"Looks like I missed something here," responds Xenusion. "I can't remember any amazing demo coming from people using demo tools of other groups. The people who are good would never use one; they simply write their own tools. A tool itself is a must and helps to save time. There would be much fewer demos if no one developed their own tools. All the whining about today's times where no one is coding anything, but just making some clicks in some tools, is quite retarded and always comes from individuals who lack the ability to stand out in any particular area."

Conspiracy is one of the groups that continually expand their tools. The demoscene is eagerly awaiting the first productions coming from the brand-new version of their tool A.D.D.I.C.T., which is said to make quite a massive impact. "Demo tools are a great help for designers because they help them express their ideas by working in a WYSIWYG environment, instead of creating all the graphic assets in separate programs and then telling the coders what they should look like," comments Zoom. "I mean the graphic assets. On the other hand, demo tools are always limiting you in some way or another because you can only do what the coder implemented in there. Of course, you can always request some new features if the system is flexible enough."

Navis adds: "They are ok for what they are at the moment - tools that are mostly used by the groups that made them and with which some fine demos have and will be made. But it seems that not many other people are willing to use them to that extent, with a few exceptions of course. Why is that? Maybe they are quite difficult to use. Or maybe because using somebody else's tool in order to make a demo would be a bit pointless - and I use the word "demo" with its oldskool meaning; a demonstration of the group's ability to code, pixel and track. I think the answer depends on the occasion and the character of the person in question."

Starting on a production

Everyone starts differently when approaching a new project. This seems to particularly differ between artists and programmers.

While Archmage starts with a chair, a table, a beer, team mates Hyde and Interphace, and a scrap of paper, Keops usually tries to have the soundtrack done before working on the effect of the demo. He hates to work the other way around. It usually starts with Photoshop to help him materialize different concepts and ideas. Once he made up his mind about some visuals, he tries to code them to see if they look good animated. "Those tests usually end up as screenshots that will pass through Photoshop again, either to enhance them or to try other things. That's how our PC prods are usually finished, with a regular exhange between Photoshop and Visual Studio. When nothing good comes out of the first one, I focus on the latter. A weird thing about that exchange is that the final result often doesn't look like what I formerly had in mind at all."


Navis

Zoom teasingly starts out with: "I start by waiting until there is only a week until the deadline." More seriously, he comes up with a good title first. He thinks it's quite important because a good title also determines the concept. Its meaning and sound can show you some directions for the design and gets your imagination rolling.

Navis on the other hand, starts with reading books on art and design. He lives close to nice bookstores (Blackwell's Art and Borders) that have everything he needs in order to get inspiration. "I take photographs and keep a diary," he adds. "I usually end up throwing 99% of these ideas away anyway, but this is the starting point."



Fiver2 always starts by consuming. Watching movies, demos or music videos, listening to music, reading, observing his environment. Most ideas are abstractions of other ideas. Any idea is first thrown into the "save-for-later bin" in his head and, if it is a good idea, eventually copied to the "save-for-later bin" on his hard disk and might then evolve into a real concept. "I guess at that point I'm supposed to continue by raw storyboarding, but usually I start by creating content," he explains, "which is just plain stupid."

Once he has the concept, he starts putting together the team. For once, he would love to start with a great musical track like Keops, and let the design follow the music. "I'm always looking for one of those tracks that initially ignite a vision in your head," continues Fiver2. "Unfortunately, those tracks are hard to find."

The Andromeda camp starts out with a vague concept. This is then fleshed out in ideas for effects and sketches for music and graphics. At this point they usually realize that they have departed from their initial concept, but instead of trying to make amends they try to go with the flow and feel of the project as it evolves. "The design is, as I have stated, very much embedded in the effects for us, but if you are thinking of design in terms of colours, sequence, synchronizing, and timing, this is mostly saved for the second half of the process," sums up Archmage.


Noumenon by Andromeda

As far as the workflow goes, design usually comes first for Keops, then code, then design again.

For ASD, The workflow depends on the demo. Sometimes Navis starts and finishes a demo without mentioning much to the rest of the group, while other times (especially with their larger demos, such as Lifeforce and Planet Risk) it is a collaboration. "The workflow is quite random/chaotic but I usually have the last say, since I'm taking care of the programming - something which, fortunately or unfortunately, gives me the upper hand," he explains. I try not to interfere too much with the 2D and 3D graphics, and especially the music. This balance, I think, makes everyone happy."

While Orb apparently works with music first most of the time, it's more of a parallel process at Conspiracy. After the initial concept is settled, Zoom gives some style and length hints to the musician and starts collecting some tracks to show him the ambience he'd like to achieve with the demo. "Meanwhile I start working on some first graphic concepts, just to try to catch the mood and atmosphere I'm aiming for," he continues. "Then, after the Nth version of the music when it's already close to being finished and the musician wants to kill me by setting me on fire, I sketch up a rough script or timeline based on the music. Most of this happens only in my head, I just need to write down some keywords beside the timestamps and usually this is enough for me to get a full view on the future demo. I just close my eyes, start the music and start envisioning the scenes." He adds with a laugh: "This might sound cheesy, but it's really like this."



Xenusion sees it all less emotional which probably also allows him to stay sane: "Making demos is just a huge chaotic mess and anyone who tells something different is probably lying. I just comment on crappy-looking aspects of the work-in-progress demo and everything else is in the hands of the main coder. Usually I don't give a fart about the story or similar aspects since that's the easiest way to stay cool and not freak out about something you would have done totally differently. If someone wants to implement retarded stuff, I'm fine with it as long as it doesn't look like crap."

The chicken and the egg

So what comes first? The chicken or the egg? Do the effects follow the design or should the design follow the programmed effects? Everyone has a different stance on that.

"Today's demos are a compromise," says Xenusion. "It used to be the latter - the design would follow the effects," counters Navis. "But in recent times (over last 2 years) it is the effects that have to follow what the design dictates. I'm a free man though, and no more a slave of the demo effect!"


Zoom

Fiver2 prefers the code following the design, for obvious reasons. "But every now and then an effect takes control over your design," he admits. "That usually means it is a good effect."

Zoom states: "We don't have too many coded effects and I really regret that, but what we have usually just supports the design."

"Good design should always follow good effects, or even better, be constituted by them," says Archmage. "Do it the other way around, and you won't have a good demo as in 'demo'. You might have something that has bright and shiny colours and flashes and makes lamers shout "hund" off beat, but that is of course something completely different."

Keops doesn't fully agree on that. "In the '80s and '90s, design followed the code," he says. "By now, we should have reached the point where code serves the design or a given concept."

Same old, same old

"The risk of falling into the same design pattern over and over again is not very high unless you decide to do a demo with the exact same effects as in the previous one," stats Archmage. "The main reason why certain groups fall into the same design patterns over and over again is because of pure recycling of effects. You can only make so many varieties of that Finnish tunnel before it becomes repetitive."

Keops raises a different question in that context: "Why should it be seen as a risk? We are not an industry with customers. We design and create things we like at that moment and that we would like to see in a demo. It's not like one owes anything to anybody when making a demo, especially when one spends a significant amount of time."



"Be it laziness or lack of time, the risk of reusing ideas or even old pieces of graphics or effects is always there," admits Zoom. "The risk of releasing lots of demos with the same design is even greater, I guess, because usually the design is tied together with the individual style of an artist. And with the same artist comes the same style. Of course it largely depends on personal experience and influences but as time passes it really becomes an art of its own to be able to always come up with something fresh and new."

Xenusion jokingly raises a provocative question: "Should this imply that all TBL demos are crap? Well, they've ripped the style of others for their 'Suicide Barbie', haven't they? Is this better from a design point of view? Improving existing things can help you to progress forward a lot, but of course there is a line when you have come to an end. I think it's an individual decision when this point has come."

Fiver2 agrees with Xenusion: "I don't see design patterns necessarily as a bad thing. There is a big difference between having your own style and repeating yourself. I would start worrying if every next production felt like a remix of your last, but one should not be afraid of varying a theme. E.g. in my work I see certain light effects, camera work and syncing as recurring themes and I am not planning to change that. I could use a new color scheme, though."

And this is when we get to the end of the round table, where ZINE tried to get a feeling for some of the pressing matters in both programming and design of today's demoscene. Navis sums up the round table quite well, by saying that diversity in design is key. Your audience should never know what to expect from you next. This is one sure way to stay in the collective memory for a long time.