pouët.net

In general I try to get one core effect done very well, and if it is good enough I try to see how I can articulate something around it, and then across the demo I try to get things that keep the whole together (visual clues, color palettes, way of doing transitions).

Also you know that you have "mandatory" sequences: You will want to have some ways to hide precalcs or boring loadings, you will probably display the title of the demo, some greetings, and some credits as well.

You can use some of this to introduce or transition to some others.

Like the cool picture displayed while you load or pre-calculate, then use some transition that introduce nicely the picture (can be a similar color, some "freezing flash" (the good old 3d animation that is caught in a nice picture detailing stuff), some shape (a tunel effect that transition on a picture of something round), etc...

Or you could do something "a la cadavre exquis", which is you do local transitions from one sequence to another (good example of that is ASD LifeForce, look at the video version, and move back and forth to see which element of the previous scene is kept and morphed into the next one).

But yeah, easier said than done :)

maybe you could start by releasing some of your individual effects as "cracktros". single screen effects presented with a nice colour scheme and logo with text routines overlaid.

cracktros are a great way to get the creative ideas flowing before you move on to something more ambitious, with multiple screen/effects.

Well... the difference between a productive coder and a non-productive coder is for the most part that the productive coder knows how to write good tools, good frameworks and good base code. It's not "effect coding", but it's certainly still coding, and I'd argue it takes more knowledge and talent than "effect coding". A good framework and toolset is not some trivial thing that just takes a lot of patience to get right, it's what coding is all about these days (and I don't think that's a shame, either, as it actually gives us some new territory to explore).

To answer Spinor's question, I'd say, forget about coding effects and start focusing on coding framework and tools. "Effects" are a minor aspect of what makes a good demo. It's not even clear to me what an "effect" is, anyway. If it's supposed to mean a self-contained routine that produces entire frames of animation (as it did in the old days), then demos like fr-025 don't contain effects.

I think things like this are pretty individual: Something works for someone and something else for someone else. Personally I like to have the music first and then start coding on top of that.

If you want to use what you have now (and I think you should, nothing motivates further like releasing a demo), my recommendation is to first try to get some kind of a common colourscheme for all the effects (just steal it from somewhere if you have to, all that matters if that you have one and it looks good) and then try to get fitting music from somewhere (shouldn't be too difficult, e-mail me if you don't know any musicians and I'll hook you up). In the end, it all boils down to what you want to do: You can probably make a demoish demo with what you have, or you can try to integrate some kind of a concept into it and be a bit more ambitious.

Finally, I think I'd pick option #3 like others have suggested. Pick a party, pick a deadline (reasonably far away), finish the demo and preferably go to the party yourself. Maybe making something that's not that "personal" might be a good idea too: You'll get the useful experience on how to do the cliched toruses and whateverthingies, and then you'll have a clean slate to start your next production that you can plan ahead a bit more.

Okay, I checked out your website. You got the music side covered :)

@spinor: It could have been nice if we could download your stuff. :)

Wow, lots of replies overnight. Thanks everyone for the useful suggestions! I like the idea of picking a party with accompanying deadline, so I've decided to visit Evoke and deliver a demo there (that is, if DX10 is allowed in the compo there, whoops). My designer friend will probably agree to help me at least with a good color scheme and some fonts or even a logo type of thing.

I certainly understand what doom is saying, and coding a good reusable framework + toolset is what I eventually would like to do, but for now I need to work on the demo itself or else I will lose interest before I'm even halfway there. At this moment I'm mostly driven by a very strong desire to do something with this hard-as-nails drum&bass track I'm working on... if I first spend a couple of months on a decent toolchain the desire will slowly fade away I'm afraid.

@decipher: yeah, sorry about that - I'm very lazy when it comes to updating websites after the initial upload. :P

or you could try to release on some random oldschool platform.. then it is "tolerated" to have no coherence whatsoever :)

Getting engrossed with framework writing and reusable code has a very _unfortunate_ side effect: it enables one to procrastinate on the demo and instead spend countless hours writing and rewriting stuff that in the end does not matter as much as it appears.

So it is not something to encourage as a goal.

^ indeed. Go for the effects first, especially since it's your first demo.

oh, this is easy: do one effect demos.

I'm not sure I made it clear enough, because:



The point I wanted to make is that the framework/toolset is the demo. This distinction between framework and "the demo itself" doesn't make sense if you want to move "beyond random crap".

Writing effect after effect is a dead end. You might complete a whole demo or two, but you will find any project more and more frustrating as it grows into more and more of a monster, and what's worse, even if you complete a project you're left with virtually no reusable code so the second project will be just as big a challenge, in fact probably even bigger because now you want to do something "more" but you're in no better position to do "more" than you were at the beginning of the first project. It's the surest way to demotivate yourself.

And a good framework doesn't mean you can't get your hands dirty right away. It simply means you have to think about the high-level aspects of your code. Don't do self-contained effects, avoid global states and compile-time setup, divide everything into small and agile classes that plug into one another in flexible ways, and so on. It really doesn't slow you down that much in the short term and if you don't think too big it will probably have paid off tremendously even before you've finished your first production.

doom: except, if it is your first production and youre new to this, most of the decisions you make first time around will probably be wrong and you have to start over anyway.
go for that tool/framework when you know why you need it and what you want from it. probably around production 3-4.

Funny, you just described our approach.



Then you just end up rewriting your class hierarchy all over again without ever managing to do anything useful.

Also, C doesn't have classes.

I'm with pommak

With those specs, I'd like to see the source to some big-ass mfx demo :)

Preacher: trust me, you wouldn't :D

I always check the sources to MFX shaders whenever they release a new product. And if the shaders are like that I believe the actual source code of the demo might be looking more like an abortion :P.

I'll say what smash and pommak already said, in a slightly different way:

Care about the result, not the methodology at first. You won't know what works for you and not before you've tried a lot of things. There's more productive ways of making demos than there are demo-coders. That doesn't have to mean that you don't try to make things easier for yourself, it simply means that you'll have to experiment. And yes, that's parts of the "coding random crap"-stage, but it can also be part of the "making a demo"-stage.

Also, use GNU Rocket. ;)

plus ask Solo2 about it ;)

Which is why I say don't think too big, cause you will run into "refactoring" along the way. But that isn't the same as having to start over from scratch every time.



My deepest sympathies.



Which is why I say don't think too big. ;) A compact class hierarchy can go a long way, too.



C has structures and function pointers.

>Then you just end up rewriting your class hierarchy all over again without ever managing to do anything useful.

True for me. years lost.( for demos). But computer-science-like interesting.

If the description is correct, I'm not quite sure what you can/should do with it in a demo dev context.


If the sources of their earlier demos are any indication... maybe you don't. ;)

krabob: Are you talking about karate?