Programmer Challenge

So who is going to organise the competition - and who is going to judge it?

Is everyone in aggreeance of the water sim then? Just to chime in, perhaps make that the topic and let the programmer decide how they want to tackle it.. you can use physics or basic particle effects etc, whatever you are capable of (to get as many programmers involved).. you can do waves, waterfalls, liquid simulation, whatever.. Just keeping it a bit open rather than having all entries doing the same effect? Just throwing some ideas.. what do you think?

Judges - well, I can annoy some programmer types in the industry to look over the results. Zaph (IMH), Gaffer (Irrational Games), Tony Ball (Krome) to name a few, and if they have time to spare.. and a friend of mine who did the water effects in Jurassic Park : Operation Genesis. How's that to tie in with things [:)]

Anyone want to write the guidelines?

I don't know about guidelines, but heres the first entry:

//Scotts Waterfall

#include

int main(){
while (1){
cout << "~_~_~_~_~_~_~_~_
";
cout << "_~_~_~_~_~_~_~_~
";
}
}

using namespace std;

well seeing that was your offical entry,
YOU FAIL.

return 0;

That's two errors :)

Ohh my. Including iostream.h would also work, but thats bad because it uses old iostream.

The return 0 is redundant as the program will never exit the while loop anyway, rather the user has to click the window "X", but meh. Not compatible with DOS. :D

I can't wait for my game code to get picked apart like this... I'll probably cry.

Scott.

return 0; is redundant in that case, but the compiler will whine that the function doesn't return a value.

Can I hand in a glass of water as my water simulation? :P

you forgot about the case when (1 != 1)

#define 1 0

:P

CYer, Blitz

haha...

*AHEM*
So how about those guidelines?

Scott.

It is a case of who is bold enough to set Guidelines.
I honestly am willing but however am lacking any time. (well besides a lil here and there to have a chuff) but that is really it.
Anyone of note want to set up the guidelines for the water sim Application.

Hows about a call for nominations?

Just thought Id through two cents in ;>

0xBaaDf00d
---------------------------------------
The World is STILL not enough!

Well I dunno if we've got any guidelines left, everyone sort of wanted to do their own take on a given topic. ie "Let's do a water demo" and then code-monkeys would just take it from there.

Hey, Blitz looks important, lets ask him.

:)

Scott.

Guidelines like this? (Feel free to comment and change)

* Executable and content must be under 3MB (That should be plenty, maybe less)
* Since we can't check code, you must be able to explain how things work to a judge. (To stop people from lamely ripping code)
* (Maybe the winners submit code or something for the judges to look at)
* You may use your own code and anything from the list of allowed libs (DirectX, OpenGL, SDL, etc)
* Target machine is a 800MHz, with 64MB RAM and GeForce2MX, or equivelent (Though making it as compatible as possible is better.. more people will be able to watch/use it). So you could use vertex shaders if you wanted, but if people can't run your app, they can't vote for it.
* Has to do with "water simulation"...

For the purposes of being a bit of a pain in the arse, I'll add my two cents.

3Mb of content is a little strange - I'm not sure whether you were a part of the brigade that said any wannabe games programmer worth his weight in crap had some coding framework - but let's say that most programmers participating in this competition do have their own base code frame to work with. What if their code doesn't use SDL? Anyone using SDL doesn't have to write a whole bunch of stuff that wont need to be part of their 3Mb limit (ie distribituble) so they can have more content than non-SDL users. Then we have the problem that some portion of the people will either have to waste time adding SDL to their support list, or they will have to sacrifice content.

And as for checking code - why can't we do that? I'll quite happily pose my code naked in the middle of the street - if we are too scared to show off the code - how are programmers ever going to learn tricks from other programmers, and get better as a whole? PLus if code must be produced, then everyone can be sure that copying isn't occurring because if you do copy code, everyone can see it and you'll look like a tool. Of course it gets complex when code is very similar but not copied. :)

And thirdly - the target machine. I'm pretty sure people don't want to make another 'already-done-before' demo - and restricting something like a water demonstration to
a) An 800MHz processor, and
b) a non-pixel-shader capable card is a little on the crap-side of the demo world. As far as I knew, people wanted to do a kind of old school demo, demo's were always supposed to be about exploiting the current consumer level product to produce something that shouldn't really be possible at that period in time. Last I checked, 800MHz and GF2MX was about 3 years old tech, not even within a whisker of the latest technology.

As far as I'm concerned, any wannabe games programmer worth his weight in crap - should invest in a new rig so they can exploit the latest technology. If you can't do that now, how are you going to exploit technology that is two years in the making when you are out there on the job?

My attempt at some guidelines goes such as this - even though I'm probably not going to compete in this competition because I don't see it as a particularly worthwhile exercise.

* Code is submitted as well as executable - must be your own - or copied code under a certain percentage of total which must be credited.
* Content is either generated at run time, or supplied with the competition guidelines
* Approved libraries with minimal storage based input functionality, mostly output - ie DirectX, OpenGL
* Must be *at minimum* backwards compatible with something ala DirectX8.1 supplied feature set - like pixelshader 1.4 etc (maybe someone else can come up with some ideas here)? but can support newer technology as well
* Should be a demonstration of both graphical water/fluid representation and physical water/fluid modelling.

I agree with maitrek that the 3mb limit is bad... I can understand that if we were doing an old school demo, but thats not the aim here.

Checking the code? I'm 5050 on this one... some people are wary about protecting their work, but I take your point on the sharing of ideas. Perhaps making it non compulsory could work.

As far as the percentage of originality, I don't think this is such a good idea, as frameworks could be shared etc. And whos gonna sit down and read everyones code to make sure its not copied? Maybe 0XBADF00D. ;P

Specs? I don't even have those minimum specs, and most programmers I know spend their money on dog food and whatever else they eat, not fancy computers... though I don't see why people should limit themselves to appeal to the lower range of specs. If you've got em, use em I say. The only drawback is that your code probably won't work on half of the voters machines, so that has to be taken into consideration.

As far as backwards compatability, boo DX8.1. Everyone uses 9 now. Any programmer worth their weight in crap...

Thats my advice on the matter.

Scott.

I got a job at Krome in January. The home computer I programmed my games for the QANTM course last year on (and consequently those same games helped get me this job) was a Celeron 500 with 320mb RAM and a 32mb S3 Savage4. A new rig and exploting new tech can be quite helpful in getting a job, but well coded and well presented demos/games are just as important. Any games programmer worth their weight in crap should know technology isn't everything. PS2 is three year old tech but people still make games for that.

I think you're worth your weight in crap Ethan. [:D]

Scott.

yep for code sharing, no 3mb limit, ps2's being crap, and dog food.
but no for ?no limit for the computer specs?, it would be better if everyone could run it, still put in vertex shaders maby even pixel, but dont go over the top. - "My demo only runs on a 4Ghz with a Geforce FX, and 8Gig of ram, and bio-neural networking". I plan to make mine run on my machine so that should be good enough for everyone seeing that its not very good.
Also did we agree on a time frame for this?
I was also wondering how the contest would be judged, like if a demo shows the basics of water sim in only 10 lines of code then they will be consider the code master, or if its gonna be based more on the executable side of things ?

- i think I'm worth ethans weight in crap..

How many lines of code was my entry? [:p]

Scott.

quote:Originally posted by Maitrek
3Mb of content is a little strange - I'm not sure whether you were a part of the brigade that said any wannabe games programmer worth his weight in crap had some coding framework - but let's say that most programmers participating in this competition do have their own base code frame to work with. What if their code doesn't use SDL? Anyone using SDL doesn't have to write a whole bunch of stuff that wont need to be part of their 3Mb limit (ie distribituble) so they can have more content than non-SDL users. Then we have the problem that some portion of the people will either have to waste time adding SDL to their support list, or they will have to sacrifice content.

Hey, I'm not setting the guidelines here, I just started because no-one else did.

The 3MB limit I suggested was for the entire submission, perhaps the submitted .ZIP/.RAR would have to be <=3MB. That would include all libs etc except DirectX/OpenGL (D3DX is compiled into your exe, so glut would not be excluded from the limit). This is mainly to stop people from including 5MB textures and 10MB data files, which with a bit of work could easily be compressed.

quote:
And as for checking code - why can't we do that? I'll quite happily pose my code naked in the middle of the street - if we are too scared to show off the code - how are programmers ever going to learn tricks from other programmers, and get better as a whole? PLus if code must be produced, then everyone can be sure that copying isn't occurring because if you do copy code, everyone can see it and you'll look like a tool. Of course it gets complex when code is very similar but not copied. :)

I have been working on my engine for many years, I have put many, many hours of work into it, and I don't like to throw it around. I'd be happy to explain to people how I did stuff, but they write your own code. Perhaps just the "game code" would need to be surrenderd, with the engine lib and headers or something (So others can compile it). I am not "too scared to show off the code", infact I am quite pround of my code, I just don't want people

quote:
And thirdly - the target machine. I'm pretty sure people don't want to make another 'already-done-before' demo - and restricting something like a water demonstration to
a) An 800MHz processor, and
b) a non-pixel-shader capable card is a little on the crap-side of the demo world. As far as I knew, people wanted to do a kind of old school demo, demo's were always supposed to be about exploiting the current consumer level product to produce something that shouldn't really be possible at that period in time. Last I checked, 800MHz and GF2MX was about 3 years old tech, not even within a whisker of the latest technology.

This is not a restiction, it was a target, what to aim for. This is around what most people have. If you want to write code that uses all the feature of the R9700Pro, go ahead, but if if can't run on anything less no-one else will be able to watch it.

And don't tell me what a demo is, I have followed the scene for many years. Demo's are meant to do things that aren't meant to be possible, like real-time ray-tracing on a 486, or a 4k Descent-like engine.

quote:
As far as I'm concerned, any wannabe games programmer worth his weight in crap - should invest in a new rig so they can exploit the latest technology. If you can't do that now, how are you going to exploit technology that is two years in the making when you are out there on the job?
[quote]
And if you think that all games are aimed at next-gen tech, you are very wrong. There are many people that still have these machines, and they are a major target for some companies.

800MHz is *plenty* for some nice water effects. 800MHz is also plenty for many games, which also include a full audio system, many more rendered objects, AI, etc

Which is more important, being able to write fast code on a next-gen machine, or being able to write fast code for an old machine? I'm sure that a demo that runs on, say, a 233MHz machine fine is more impressive then a demo that runs on 1.8GHz machine a bit faster.

[quote]
My attempt at some guidelines goes such as this - even though I'm probably not going to compete in this competition because I don't see it as a particularly worthwhile exercise.

* Code is submitted as well as executable - must be your own - or copied code under a certain percentage of total which must be credited.
* Content is either generated at run time, or supplied with the competition guidelines
* Approved libraries with minimal storage based input functionality, mostly output - ie DirectX, OpenGL
* Must be *at minimum* backwards compatible with something ala DirectX8.1 supplied feature set - like pixelshader 1.4 etc (maybe someone else can come up with some ideas here)? but can support newer technology as well
* Should be a demonstration of both graphical water/fluid representation and physical water/fluid modelling.

Those guidlines are quite vauge... my thoughts on code and content are above...

DirectX8.1 is NOT a hardware specification, it only has a base hardware specs that are needed, which is around Voodoo3/TNT2 class hardware... less then the target I gave.

"Should be a demonstration of both graphical water/fluid representation and physical water/fluid modelling."

Ah, that's better then what I had :) But we still need to work out what phsical interactions we require.

Let me note, I became quite angered by your reply (as I did with Sam's). I think it's just that I've been involved in things where there are lots a lamers present that rip code and write crap code and then brag and go around with no respect and insult others who are much better then they are, and been burnt by the experiences. So if I am being harsh, just let me know :) But this is the internet, any lamer can come along ;/

Edited because I for got a / inthe BBCode

Also, How are we going to figure out who wins? Was it going to be juged, or voted for?

I say a community vote to decide the winner.

Scott.

quote:And don't tell me what a demo is, I have followed the scene for many years. Demo's are meant to do things that aren't meant to be possible, like real-time ray-tracing on a 486, or a 4k Descent-like engine.

Don't get me wrong, I think exploiting old technology is great fun, but all thase demo's have been done before, except for convincing "real-time" ray tracing on a 486, obviously I've seen plenty of good ray-casting, but as far as my experience is concerned, real-time ray-tracing on a 486 hasn't been accomplished (at least to my satisfaction of the meaning of the term real-time)... and anyway....I'm just trying to focus on the fact that alot of games programming is designed *to support* technology that may not even be out yet, but will be out by the time you've finished a game. People gave me the impression they wanted this to represent real coding (to an extent), and that's what I'm sortof pushing.

quote:DirectX8.1 is NOT a hardware specification, it only has a base hardware specs that are needed, which is around Voodoo3/TNT2 class hardware... less then the target I gave

I am aware that DirectX is an API and not a hardware spec, what I meant was something along the lines that it must not require anything beyond the realm of DirectX8.1's capabilities. If I wanted to be more specific, I could go on about real hardware specifications, ala PixelShader 1.4, Vertex Shader 1.1 tech etc. I meant that it must *at least* run on those specifications, but can run lower, it doesn't have to use those. Like I said, people's further refinement to that statement would be welcome. I am not the master of hardware specifications exactly.

That is very similar to what your saying. I just thought that saying a target machine of 800MHz and GF2MX is possibly a little restrictive unless you actually are a very very good demo coder, there has to be room for the less experienced coders to flourish, even if that means letting them pound the crap out of the hardware. The cream always rises to the top for sure, but at least the crap coders get to have some reasonable results.

quote:Which is more important, being able to write fast code on a next-gen machine, or being able to write fast code for an old machine? I'm sure that a demo that runs on, say, a 233MHz machine fine is more impressive then a demo that runs on 1.8GHz machine a bit faster.

In *somewhat cheeky* response to that I would say that if someone were to write really *really* good code that ran on a 1.8GHz machine at a reasonable fps (everyone wants near monitor refresh rate frame rates nowadays but I'll say 30fps is reasonable), it would be far more graphically/visually impressive than a demo that runs 30fps on a 233MHz machine and 200fps on a 1.8GHz machine.

quote:800MHz is *plenty* for some nice water effects. 800MHz is also plenty for many games, which also include a full audio system, many more rendered objects, AI, etc

Well if 800MHz can produce some nice water effects, what can 1.8GHz produce...?

On top of that - 800MHz is such a marketing perspective of the speed of computers. Compare an 800MHz Celeron to a PIII 800MHz or a Duron, or maybe an Athlon and you get different results. Seeing as this is a physical/modelling simulation, processor will make a BIG difference - plus what if someone codes some nice 3DNOW and 3DNOW extension support - but a large percentage of judges have Intel processors? We could say "well this reflects consumer base blah blah" but that doesn't really reflect the time and effort in the coding (which is what I always assumed was reasonably important).

And I agree that releasing your whole engine code is a little on the risque side, and I should've refined the statement to include the code specific to the competition entry, written during the competition period, if explanations of "engine" specifics are reequired I'm sure they can be provided. The only reason I'm quite happy to show my code is that it's probably undecipherable (yes I am a bad software engineer).

How about we ask the judges what computers they have and then we will know what the target machines really are?

If this is going to be voted on, then then the target I have given will be the best for everyone :)

Also, do we need a "reference thread"? Like links to physics and fluid motion docs and such? and/or pictures of water? (I had a bunch at one point, I'll try and find them)

A reference thread sounds like a good idea... Sumea has relevant links, but in the interest of speed and ease, a reference thread would be nice. [:D]

Scott.

quote:Originally posted by lava_monkey

ps2's being crap

Word. PS2 dev sux compared to XBox dev :)

I intend on posting my code with my entry (if my computer's working by then). I probably won't hit the 3mb limit anyway, but I don't want to download a 50mb entry.

And it's nice to see you guys relate me with crap :P

I think I'm just going to sit back a watch for a while...I don't think there's anything I could add to this that people would want to hear anyway.

Good luck guys!

ok to get his thread back on topic,

what we have so far:
a liquid demo, it can be any form of liquid demo, waves, waterfalls, liquid simulation...
no size limit, but nothing to big.
no tech limit, but dont go over the top.
source must be shared, but not engine source (unless it contatins vital parts of the liquid effect)
api's allowed, directx, opengl, fmod, glut (unless you can think of anything else)

how about that, is everyone agreeing so far ?

only thing left to agree on is time limit, i say 6-8 weeks.

I say you should have a limit on the uploaded size, just so you can't grab lots of textures and models and that, and so you can't upload movies etc. I'd say something about 5 megs - unless you want to host it at your cost and upload a link for the competition.

If you want to use fancy new tech, then you should also program fallback paths for older tech. You should be able to accomplish this if you are currently using the latest tech. (To about the gf2 standard).

For API's I'd just say use OpenGL or DirectX, no GLUT (I don't want to download those damned libraries - they're for lame-ass try-hard opengl coders only!) We won't really need sound, but since that's not really the primary goal of the demo you should be able to use whatever library that you so desire (only the graphical libraries are limited).

Personally I think that the source code should be submitted in full with the entry, and only available for viewing after the contest deadline date. The thing with demos is that they should be coded from a light framework, so they can be small and optimised, using already existing engines is kinda cruddy, since usually they are large and bulky (heck I could always make a demo using the unreal warfare engine as a mod to the engine, now that would result in a huge download and a lot of cruddyness).

The final demo cannot be a movie, and has to be slightly interactive (meaning that you can't just do a straight movie-like demo, you at least have to be able to move your viewpoint).

And the time limit i'd say would be 2 months, from start (using nothing but a base framework that you would be comfortable in releasing publicly), to finish (the finished interactive demo).