Amazing Demo Scene Guy (bit techy)

[guythp]

I saw Courtney Pine in Norwich the other week. A similar comparison, I feel, can be drawn.. What I saw was amazing, all the performers did amazing things with their instruments; an almost C64-like arpeggio from the violinist (who later put his electric violin through a wah-wah), a drummer who kept time whilst going 'jazz-crazy', Mr. Pine who, whilst running things and doing some incredible reed-instrument playing, took time to stand back and let the others give it some...

Now, I'm not a huge jaz fan. In fact, I don't really like it. However, the technical ability was what shone through that night. As with (in my opinion) turntablism and beatboxing. It doesn't necessarily sound great, but it's bloody impressive stuff.


To conclude, this is my opinion of demos, from my late-coming to them in the Atari ST days, to the A1200, DOS PC and finally windows PC (and the mac - I was quite impressed to see 'Mikrostrange' running on my G3 imac). These guys do some impressive stuff however, it's all set. I imagine if they did an OS it'd be bloody fast, but crash at any given moment and probably kill your machine and any in a given mile radius..

All hail the demo makers!

[sack]

I've not written any demo code for ages (and released nothing on the PC save for some crappy scrolling stuff ages back) - but from what I know talking to more productive demo coders they are less fixed then before. In the past everything was carefully interleaved and timed (often to the CPU cycle) but now there seems to be an engine-like approach to thing - build an engine and some tools or importers and build your production from there. Same kind of discipline as games really.

So I think demo coders can probably create 'real world' code better than you give them credit for - but I still maintain that most of them can't produce good games

[sty]

Good post Sty.

Thanks


BTW, just to be clear what I was referring to was business or even 'normal' PC/Mac software (like Word, or iPhoto, or iTunes, or ...) Games are always different because of the drive to "push the hardware" and the competition in the industry.

I've always held games development up as an example of people delivering incredible software when I talk about traditional business SW. Up until recently one of the things that blows my mind about Games development is the need for "Zero Defect" delivery, basically once it's burnt to disk it can't have any errors as the cost to throw away all those console games and start again is prohibitive (obviously that's all changing at the moment a little but it is still 99% defect free). In the commercial SW world I have seen successful software go out the door that is in all reality only 30% complete, and it's an accepted fact that SW that delivers on 50% of it's requirements is deemed a "Success"

I know quite a few people in the games business, on here and elsewhere, and I have to say that they are some of the smartest and best coders I know of, and those that are in the management and production side of the industry are equally sharp and impressive. The wider SW industry could learn a lot.

[Peet]

So I think demo coders can probably create 'real world' code better than you give them credit for - but I still maintain that most of them can't produce good games

I don't see why this would be limited to just _demo_ coders, specifically.

Also the comments in that Hideo-Kojima-would-like-more-space story are pretty surreal.

[Firefox]

I've not written any demo code for ages (and released nothing on the PC save for some crappy scrolling stuff ages back) - but from what I know talking to more productive demo coders they are less fixed then before. In the past everything was carefully interleaved and timed (often to the CPU cycle) but now there seems to be an engine-like approach to thing - build an engine and some tools or importers and build your production from there. Same kind of discipline as games really.

To be honest, I thought the decline of the "fixed" platforms like the Amiga and ST, and the rise of highly variable commodity PC hardware would kill the demo scene. But they've found new challenges to compete on - like 64kB intros - and the stuff they're producing is still as jaw-dropping as ever.

I've always held games development up as an example of people delivering incredible software

I work in realtime embedded systems - hardcore engineering stuff. But I've learnt an incredible amount over the years from reading articles and blogs written by games programmers, and I have the utmost respect for them. The feats of programming that they pull off on a daily basis and the technology that goes into their games is quite amazing.

[gumboot]

There's a really fine line between producing effective code in a modern 'business' workplace and the waste and crap coding that we all talk about.
[...]
Now what you really highlight here is that there is a difference between professional software developers and people who choose to hack, or do demos, or write games, or in general who code for fun and a hobby. BAsically 80% of your professional SW developers just treat it as a job, and they learned enough to get the job and keep it.

I don't think there's a fine line. I think it's a continuum, and that people are just sliding further and further down the wrong end of it.

So remember that it is probably the 'hobby developers' that are breaking the new ground and saving the industries.

It's interesting that you use the term 'hobby developers' the way you do. The majority of really bad code that I see is open-source software, which is generally developed as a hobby. Whereas, at work I see people getting paid to write proper, efficient code.

Up until recently one of the things that blows my mind about Games development is the need for "Zero Defect" delivery, basically once it's burnt to disk it can't have any errors as the cost to throw away all those console games and start again is prohibitive (obviously that's all changing at the moment a little but it is still 99% defect free). In the commercial SW world I have seen successful software go out the door that is in all reality only 30% complete, and it's an accepted fact that SW that delivers on 50% of it's requirements is deemed a "Success"

I'm sure that'll come to an end soon.

Embedded software took a sharp downturn once flash program space became standard issue. All of that "don't fuck this up, it's going on masked ROM and it'll cost us millions of dollars to fix it" design philosophy changed to "we really have to get this out the door before anybody else does - is there anything outstanding that we can't patch in the field?", then "wouldn't it be cool if we could release this and have it work first time?", and then "fuck it. They'll only have the thing for six months and then they'll buy a new model anyway".

Now check out this comment from Wikipedia:

Java creator James Gosling, at the conference, suggested that the inclusion of a Java Virtual Machine as well as network connectivity in some BD devices will allow updates to Blu-ray Discs via the Internet, adding content such as additional subtitle languages and promotional features that are not included on the disc at pressing time.

So now they don't even need to get movies right before they release them.

Certainly PC games have been coming with constant streams of patches since the early 90s, if not earlier. The consoles are just waiting for the technology to be able to release half-baked software... and it is coming.

I know quite a few people in the games business, on here and elsewhere, and I have to say that they are some of the smartest and best coders I know of, and those that are in the management and production side of the industry are equally sharp and impressive. The wider SW industry could learn a lot.

That, too, I see taking a downturn in embedded, and so I'm sure games wil follow.

[Firefox]

Embedded software took a sharp downturn once flash program space became standard issue. All of that "don't fuck this up, it's going on masked ROM and it'll cost us millions of dollars to fix it" design philosophy changed to "we really have to get this out the door before anybody else does - is there anything outstanding that we can't patch in the field?", then "wouldn't it be cool if we could release this and have it work first time?", and then "fuck it. They'll only have the thing for six months and then they'll buy a new model anyway".

It might be that way in yon cheap Chinese MP3 players, but when you're developing a control system for a fuck off big jet engine you still have to be fairly careful.

[Dio]

My experience of game code is that it's pretty universally of low quality, driven by the short timescales and overworked staff layering hack over hack over hack, by too many games guys not having a solid engineering base to their mindset, and by too little time spent developing a clean prototype in the 'cheap' phase before staffing up for full development.

Egregious misuse of C++ is probably the most frequent problem, with incomprehensible uncommented stuff and spaghetti logic following close behind. Certainly on the graphics side, there's also an awful lot of things that could be done better. Five years ago I honestly thought that I'd never see another game being so utterly daft as to draw the sky first, but I couldn't have been more wrong - the games that do it right are still in the minority (and those are usually ones where the graphics companies have had some engineering input). Similar problems are endemic.

Maybe the quality of the internal code has improved in the last few years but I'm far from convinced that's likely given that the quality of the 3D command set seems pretty constant.

Games guys do produce incredible results, but the schedules really don't allow for producing great code along with it. Get it right now and get on to the next task is key. My personal feeling is that in the long term this actually hurts the schedule, but that's far easier for me to say from the outside than it would be to do it on the inside .

[arron]

Fantastic thread this!

IIRC I had a conversation with one of Gravy's associates in his kitchen down in Portsmouth about the procedural generation of data in computing and games specifically. The push to more detail means that the artistic effort in designing and building this stuff by hand rises steadily to infinity, and if you could build a mathematical model to texture, build and augment a entire city without needing to open a graphics editor, then this would help solve the "exponential content crisis" I could see looming. And mathematics is scalable - you can have infinite amounts of generated data from it, you are only limited by the architecture you have to play with, and the time you have to do it in. Low resolution, High resolution..it comes down to the number of points you generate. It would certainly take the mystique out of fiddling around with points and surfaces when the maths can do it for you.

This was back in the days when the original XBox was still current gaming technology and it was considerably easier to get people to draw and edit stuff, rather than generate it, so I think that my argument was treated with more than a little scepticism by the guy I was talking to..

However, I'm hardly some kind of prophetic visionary, as this has been done for years by a lot of other people a lot clever than me, and nature builds us from a DNA template (seed data) and biological processes (code) so I guess we're only copying nature after all. However, if you can build graphics (and other) data from code, what about building procedural code from code? You can sort of do this with genetic algorithmns, but if you know the random seed and "random number generator" which when cranked a number of time gives you the executable to a program, then you don't need a CD full of program data. It would work with movies or sound data too. Everything we fill DVDs with could be generated from one small program and some seed data..

[gravy]

My experience of game code is that it's pretty universally of low quality

Is that PC games? I thought you didn't work on console

[Darkflame]

I think the problem is, once you start trying to generate exact data rather then merely "types" the seed and "space" for the seed to existing in has to be so big as to be pointless to use.

Generateing a brick-wall, grass, sand textures, or melodys, or even meshs's is possible and they could look great.

But createing specific brick walls, grass tunes or whatever would take more procredral data then youd get by storeing the file normaly.
I think code falls into the specific camp.You could certainly have randomised code, or code which "unpacks itself" to some extent, but I dont think youd get much benifit out of it. It would be like other self-altering codes.

[arron]

I think the problem is, once you start trying to generate exact data rather then merely "types" the seed and "space" for the seed to existing in has to be so big as to be pointless to use.

Generateing a brick-wall, grass, sand textures, or melodys, or even meshs's is possible and they could look great.

But createing specific brick walls, grass tunes or whatever would take more procredral data then youd get by storeing the file normaly.
I think code falls into the specific camp.You could certainly have randomised code, or code which "unpacks itself" to some extent, but I dont think youd get much benifit out of it. It would be like other self-altering codes.

But the mathematics is layered to avoid complexity. One layer builds the basic brick structure of the wall, another gives a rough surface of the bricks, another give the bricks some aging through "random brick damage" for example. That's how you avoid building a big program by running the same code with different values.

You can also add user content. If you had a picture of graffiti for example, you get the computer to fit splines to it and then you can put this maths through other "procedural modifications" to give aerosol spray texturing for example and then add this data onto the wall as another layer on top. In theory, you could probably fit the data file to drive this as a few K of text, if you wanted to, or compress it down into some byte code.

I'm using a similar technique in my PhD to reduce several gigs of data on the human body down to a few hundred K (I hope) by having humans that don't exist by anything other than mathematics, some seed data, some random number generators and a series of overlapping boxes to drive the system. And what I'm doing is a lot more complex than a few bricks in a wall..

[Kemper_Boyd]

Five years ago I honestly thought that I'd never see another game being so utterly daft as to draw the sky first, but I couldn't have been more wrong - the games that do it right are still in the minority (and those are usually ones where the graphics companies have had some engineering input). Similar problems are endemic.

Wasn't the argument in the past that drawing the sky would save explicitly
clearing the buffers? Whereas now you'd want to draw occluders to fill the
z cache. It's a good example of a design decision that goes from being just
right to totally wrong as the hardware evolves.

[PaulCunningham]

...and if you could build a mathematical model to texture, build and augment a entire city without needing to open a graphics editor, then this would help solve the "exponential content crisis" I could see looming.

Introversion are doing some interesting things in this field for the Subversion game.

See the It's all in your head entries.
http://www.introversion.co.uk/blog/index.php

[gumboot]

Embedded software took a sharp downturn once flash program space became standard issue. All of that "don't fuck this up, it's going on masked ROM and it'll cost us millions of dollars to fix it" design philosophy changed to "we really have to get this out the door before anybody else does - is there anything outstanding that we can't patch in the field?", then "wouldn't it be cool if we could release this and have it work first time?", and then "fuck it. They'll only have the thing for six months and then they'll buy a new model anyway".

It might be that way in yon cheap Chinese MP3 players, but when you're developing a control system for a fuck off big jet engine you still have to be fairly careful.

I don't know... I had a workmate from aerospace, and he had scary stories. They were doing all that MISRA crap, and using peculiar strategies for reliability auditing... it all sounded like somebody there had less of an idea about software reliability than your average demo coder.