Quote:Original post by Zefrieg

Quote:Original post by Prozak
None the less I have to judge what is delivered, and not what is promised.

Wow, I am sorry that you feel that way about my updates. I wasn't trying to promise anything. Those updates are just there so people who might be playing these will understand what I was shooting for. My initial entry certainly is horrible. I would hate to leave it that way.

You are right though, you should definitely be judging on the entries listed on capn_midnight's page.

uh? :S

I'm happy you're still updating your game m8. I just wanted to make it clear to other contestants that what I judge was the initial entries, and none other.

I'm glad everyone enjoyed themselves. I've been competing in programming contests for 2 years. The contests covered general algorithm implementations, and usually there were 6 to 8 problems for the 3 hour time span. So the 3H-GDC is quite a different programming contest. Most people that I told about the contest were convinced that nothing of merit could be done in such a short timespan. All of you proved them wrong.

You are also building confidence in your own programming skill. It's very important to know what you are capable of and in what kind of timeframe you can complete tasks.

I find it interesting to note that, in the space of 3 hours, you ALL have created games that (with minor bug fixes) rival the games of 30 years ago. This shows just how far we have come with technology, that we can now complete projects in a miniscule fraction of the time that it once took.

I encourage everyone to continue working on their base code. It's this code that will make you more succesful in the future. Stop reinventing the wheel for each project, try to reuse as much code as possible. One person can only devote so much time on a project, if it's all spent on getting a rendering window up with simple input each time you start a project, you'll never finish anything.

I also encourage everyone to continue making these types of small games. It's all about practice. Try to make something ever so slightly more complex next time. You may not complete the project, or it may not work as you expect, but remember that you have not failed, you have just found 99 ways that don't work.

Yeah, i loved it. I participated in several coding competitions (Ludum Dare) and it's always great fun and an immense learning experience.
Esp. as i found that a usual code snippet i used doesn't work nice with different frame times (my random TV stampede).

So when's the next competition? :)

Quote:Original post by Endurion
Yeah, i loved it. I participated in several coding competitions (Ludum Dare) and it's always great fun and an immense learning experience.
Esp. as i found that a usual code snippet i used doesn't work nice with different frame times (my random TV stampede).

So when's the next competition? :)

I think we'll skip this weekend so that I have some time to get a little more organized. Going to make up a submission form and a judging form, some other stuff.

Oops, pretty often? Dang, i'm on vacation next week.

Well, don't work it too hard!

Quote:Original post by d000hg
For what it's worth, my advice in such events would be always submit a working entry. Take the deadline as the deadline - you're going to be disappointed if after your hard work you fail to even qualify. I'd try to get the shell up first and then flesh it out, rather than end up with something that doesn't run, or looks good but you didn't have time to implement the "move" controls!

I don't know if I'll ever enter such a short event though - my speed-coding skills aren't so great and I'd have to tidy up my support/utility code before being prepared to show it to the whole world. Out of interest, If I provided base classes to initialise D3D, DSound & DShow would that be allowed? So I can get my blank screen, initialise DirectSound/Show and load/play .wav/mp3 files? What about image loaders, are they allowed - or the whole of D3DX come to think of it, which gives you image/mesh loading and a whole bunch of maths functionality?

If I could use D3DX I might think about taking part, otherwise I'll spend 3 hours writing a .bmp loader or getting text on-screen or something!

the original rules state that any language or API may be used.

What may NOT be used are Game Creators (i.e. something like this), Game Engines (i.e. Torque), or renderers, either 3rd party or custom (i.e. Ogre, Unreal, etc).

As DirectX is an API, it is allowed. DirectX doesn't fall under any of the restricted categories. D3D being a component of DirectX, is therefore allowed.

There is one restriction to what languages/APIs you may use: you must handle distribution on your own. You may use Visual BrainF***.Net 2005 v72.0, but you cannot expect the judges have it. You shouldn't even assume that the judges are code developers of some type. You must view the judges as average gamers, who will throw your game away if they cannot play it on the first load. Yes, this is because I'm lazy and don't want to hunt down dlls and libs and stuff. But it's also for your good, too, because any regular user is just as lazy.

Code like init code for rendering windows, setup for running audio, math, etc. are all pretty standard stuff. Any time you right them, they come out pretty much the same way. Between two projects or two coders, this code will pretty much come out the same. It's an excercise in monotony to rewrite it all. That's why such base code is allowed.

Code like game logic loops, AI, or renderers are very subjective, not cut and dried, and could go in so many different directions. This kind of code is more art than science. That is why it is NOT allowed, you MUST create new code for the contest.

The base code submission process has two purposes. Primarily, it is meant to even the playing field. The contest is not meant to be about pure coding skill. It's about design and gameplay. While in my judging I did take technical aspects like graphics and control into consideration, I specifically formulated a judging criteria (for myself, it appears the other judges have done something similar for themselves) that emphasized gameplay, design, and originallity over mere technical issues like pretty graphics and smooth control. So, by submitting the base code, all contestants are theoretically on an even playing field, and the technical aspects of the games are mostly equalized, leaving only design, gameplay, and originallity.

The second purpose of the code submission is to cover short-sightedness in the rules on allowable base code. After the rules were written, a contestant asked if custom Math libs were allowable. I reallized that this fell into the same technical category as setup code. The code submission provides a level of review for which we may expand the allowable set of code.

For the next contest, I'm considering that the theme will be a basic sprite package that everyone will have to use to some degree. Since the contestants are not "artists", and the purpose of the contest is to compete on the grounds of gameplay, then the sprite package will even up the graphics quality.

Given the scope of the games, one will never reach a point where performance should be an issue. 2D games with only basic features will not tax any processor, by far. Therefore, I think the people that have been using technologies like Pythong, PyGame, SDL, etc. are on the right track. While C/C++ (when used properly) will make amazing 3D games that will blow away anything made in Pythong, it cannot be done in the timespan given. Do what's fastest.