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.