pouët.net

Hi,

as a software developer, who loves Demos but did not participate actively in the scene yet, I am interested in getting to know more about the high level design of demos and intros. I found many information on the web about effects and low level tricks, but nothing about the organising code. I could not get much out of the released sources either.
So my question is: Are Design Patterns (esp. GoF stuff) often used in Demos and if so, then how? And do 64k intros differ much in this aspect because of the size restriction?

Dobi

Frankly, I think anti-patterns are in more common (and deliberate) use.

It really depends on your approach to be honest. I know people like Kusma and Navis never really build frameworks or basic libraries and maybe only have a bunch of helper functions, whereas people like Duckers or Chaos like to big one monolithic codebase or tool and then just iterate on it as long as it's possible. There isn't really One Widely Accepted Solution.

Generally, I think the idea is that if you spend more time building a system for the first demo, then your first demo will quite possibly suffer from it because you spend less time on "creative" coding, but maybe you can win that time back on your later demos because your loaders / management stuff already work. If you decide to just wing it instead, then you can do a lot of prototyping on your first demo already, but then you might have a lot of copy-pasting and re-boilerplating to do on your second / third / etc.

Personally I'd recommend a hybrid approach where you hack together your first few demos and when you feel you reached the point that your system is unmaintanable, you start building something more coherent.

Another slightly more human aspect might be that most people who do code for work are using design patterns for their work code, and they may feel that breaking away from properly encapsulating everything and building templates and all that tedium is a well deserved break, and just peppering your code with magic numbers and copy-pasted math functions is PERFECTLY FINE because noone cares about demo code quality as long as it works. :)

And the fact, that in order to compete in a competition, your demo/intro only has to work one time on a single, known in advance piece of hardware, really doesn't push the need for nicely structured design- or best practice patterns.

Sceners have been killed for producing code that fulfils that criteria (well, probably not killed but gotten a lot of downvotes) -> even if it may sound comfortable, don't do it. :P

Punqtured: The problem is, that "one time" doesn't necessarily mean the compo ;)

@Zavie: I do not agree with the article you posted. ;-) It seems like a general argument against abstracting problems. But I think patterns (like abstractions in general) can be very helpful as a mean. They do not have to be an end (but of course one can use them in that way if wanted). It should not prevent someone from thinking out of the box, but rather increase the number of possibilities you can come up to solve problems. It's a personal choice what level of abstraction is preferred and helpful. Everybody abstract to a certain degree, even if not consciously Perhaps it comes down to the difference of *N** to *S** in the Myers-Briggs Type Indicator again. ^_-
btw: I like statistics.

@Gargaj: The human aspect is interesting. I work as a software delevolper (mostly C++ and object recognition stuff) and for me it is completely different. At work I have to balance time spend with code beauty, because I want to be efficient. Code that is more likely to be reused (especially by others) thus needs a different style as code for small parsing tools I only use once internally or so. When I program in my free time, I can use as much time as I want to satisfy my desire for perfection. Of couse my code is far from perfect, but the intention counts. ;)
The times in which I wrote code that "just had to work ... somehow" are over. Coding is now only fun for me if not only the output of the executable is nifty but the code also looks lovely to me. I am seduced to try to delevop something like conspiracies addict2 tool, but perhaps I should really focus more on getting something smaller done first. ;)
A 64k intro is my goal. I hope that trying to code clean will not result in a big size penalty. But I will see. Well, premature optimization is known to be the root of all evil, so I will just start and see where the flow carries me to. Learning something and having fun is more important to me than winning a compo anyway. :)

Saga Muzak: "oh no, thumbs down on pouet!"

In my experience, design patterns are rarely useful in demo coding. Their main purpose is for simplifying business logic when you have lots of sub-systems working together - but in demos, most of the "interesting" code is in algorithms, not those sorts of interactions between objects.

One exception is Werkkzeug-style demo tools, where you're deconstructing the demo-writing process into building blocks and relations. Even then, it's important not to take it too far - the YAGNI principle is very relevant here. One of the biggest mistakes you can make in demo coding is to get too carried away with stuff like "Hmm, I can make my plasma into a subclass of Effect... aha, and then rather than hardcoding it to be a sine plasma, I can encapsulate the sine function into a generic Parameter interface!" System architecture can be fun, but I eventually learned to channel my enthusiasm into demoscene websites, not over-engineered demotools.

Dobi: As I said, it differs from person to person. For example, if you're blatantly uninteresting in delivering a prod to any specific party, sure, your free time is basically "infinite" - otherwise, it's a horribly shrinking commodity ;)

As far as content-based 64k's go, I think there are some paradigms one can follow (code reuse, code/data separation), but I think again that's up to your discretion.

Another note I should add is that it counts a lot who the "director" of the demo is. If it's you as the coder, then you can rely on your own code when you assemble the final product and it's entirely up to you how you solve the problem of crossfading from one scene to another. If you're working with an artist as someone who does the editing/compositing, you're probably way better off having structured code (or even a tool) so that when a request comes in, you're not blindsided by it.

crossfading was not a very good example Gargaj :P

I don't want to state the obvious here, but instead of debating whether or not to use design patterns, why not just make a demo (intro, in your case) about it?

rudi: crossfading is a thing where most "rigid" engines balk ;)

My current line of thinking is that the meat of a hobby project should fit into one file, with no more than ~1k LOC and should be finish-able in roughly a week (and then two further weeks for getting things in shape). Not much space for going overboard with either engineering or scope. :)

Design patterns are a disease, and demo making is the cure.

GoF is probably used for engines, that should be used for a longer period of time. But short term engines usually use quick'n'dirty code, since it wont be reused much again, I guess.

@Korvkiosken: What does that mean? (Sorry, I'm new here. ^_-)
@gasman: Yes, YAGNI is of course always important, but I think it more focuses on the number of features you implement, not that much on how you implement them. but of course the concepts are not completely orthogonal.
@sagacity: Sure, but somethimes thinking about how one wants to do things can help with what one is doing. :) I guess I may sound like some theoretical guy here, who never finished a project, but I can assure you that this is not the case. I just finished a small game (to get to know SFML) I was writing during the last few weeks. You can have a look at it if you want: http://daiw.de/share/Dron.zip (source included)
@ _-_-__: Lol, OK, we will see if I will be cured. ;-)
@Salinga: For me it's more about practice then about the final product. But I will keep in mind to exaggerate with the abstractions.
@Gargaj: Thanks for your feedback. I will just start messing around and see where it will carry me.

i guess what folks are trying to say is that demoscene is more of a "just do it" school of thought. so the best way to figure out if design patterns can help making a kick ass demo is to just try it out and endure the haters.

Dobi: That's pretty fun :)

psenough, although I think that you can argue that "design patterns" abound in demos. Just not necessarily in the code :)

true

Because it's not specific to demoscene. If you follow the usual tricks, 64k is a LOT of code. You can organize your code like in any software. I always stay away from the design patterns and the GoF, but again this is not specific to demos. :)

For your first demo, focus on the content, not on the tools. Don't try to do something over-generic. Keep your code simple.

The trick is to code drunk. I can assure you that in a drunken state, it rarely occurs to me to use the so-called "design patterns" (ok, to be completely honest, I don't use them being sober, either). Now, C++ is not a very fun language to code drunk anyway, so you can as well as choose a language which obliterates the need for these design patterns...