Since the specs of judges machines have not been released (and may still be unknown for all I know), I think the safe bet is to make your game playable on as many machines as possible. The judge will be rating you submission, and if it doesn't run on their system then it will negatively affect their opinion of it.

Personally I like this, since it simulates what you'd experience if you were releasing your game as shareware/commercial.

KittyMac Wrote:Personally I like this, since it simulates what you'd experience if you were releasing your game as shareware/commercial.

However if you release a game and there is a problem you can fix it when informed of that problem. But in this contest if the first you hear of it not working on a judges machine is when you get negative marks then the whole month has been wasted.

Also if you were releasing a shareware / commercial game then you would be spending longer than the entire contest timeframe on just your beta testing.

With Unity how is it possible to tweak the game to run on a lower spec machine when you do not have access to the source code? Is the only option to tell the judge to run it at 640 x 480 with the fastest setting?

Andrew Sage Wrote:However if you release a game and there is a problem you can fix it when informed of that problem.

Not true. First impressions are everything, and if your product doesn't work it is much more likely to hit the trash can than it will generate a bug report for you to fix. You can lose a majority of your revenue if you send out a buggy initial release.

Quote:spending longer than the entire contest timeframe on just your beta

Its all part of the experience. It becomes a time management problem (same when you release a game). You have 30 days... you need to budget what part of that is design, what part is development, and what part is your (beta) testing phase. How much time you put in each part is up to you.

Personally, I think it is a pretty safe bet the judges will have some form of hardware OpenGL acceleration and vertex shader support. I would not assume they have fragment shader support, but that's not something you should assume if you're releasing a game now anyway.

As I said I like it, but I also like small(er) restrictions on the download size (for the same reason above). Perhaps I'm just wierd like that.

KittyMac Wrote:It becomes a time management problem (same when you release a game). You have 30 days... you need to budget what part of that is design, what part is development, and what part is your (beta) testing phase.

If releasing a game / application that has not been sufficiently tested then you put back the release date until it has been. This is not an option for this contest so pointless to spend the 4 weeks sending out to beta testers to see if it runs on G3 iBooks just incase the judges have them if you do not even have a 'finished' release to be tested until week 3.

You have deadlines when releasing games, and the majority of the time you have absolutely no control over them. Publishers have deadlines too, and if you miss you a deadline there are can be very real consquences.

Quote: see if it runs on G3 iBooks just incase the judges

Think about your example a little deeper. Let's assume one of the judges has a G3 iBook (little or no hardware accel?), most of them have some newer Powerbook G4/iMac G5 ("ok" systems), maybe one has a new MacBook/Mac Mini and one has a new Mac Pro. In an unscientific way, to me this also seems like reasonable representation of the current Mac market.

It is the 3DU contest, and all entrants are required to be "true" 3D. This means that a majority of the entrants for the judge with the iBook may not play well, and that judge basically becomes a non-issue (he'll be lowering everyone's scores similarly for not playing on his machine). There may be one entrant who when through hell to get their game to run well on his system, and they will get a little boost in score as a result (as they should!).

A Powerbook G4/iMac G5 is still a popular machine, and should run any "reasonable" game in this contest. That means a decent number of polygons on the screen, vertex shader support, no fragment programs. If you make your game REQUIRE fragment programs it's your own fault it will not run on these machines, and you'll get a lower score for it.

The MacBooks/Mac Minis make life interesting for everyone, since they're like the earlier video cards where you cannot just throw gobs of vertices at them, but they have fragment shader support. IMHO these are the wildcards you'd have to deal with anyway, since they are NEW machines and you can bet a judge or two will have them!

If your game doesn't run for the 1 guys out there with a decked-out Mac Pro, then you have some serious issues.

------

The 3DU contest cannot REQUIRE a judge have a certain caliber of machine, so it really doesn't matter. You will encounter customers/judges with non-ideal systems, and you will have to deal with it. There are real deadlines in life, and real consequences to shipping a buggy product.

KittyMac Wrote:There are real deadlines in life, and real consequences to shipping a buggy product.

Working in real life I know all about deadlines for software.

I am also aware of the serious problems when something ships on time but with so many bugs that it is unworkable. I am also aware of the benefits of delaying shipment of a product in order to ensure it is fully tested. The customer is more than happy to wait that extra time if they know it is going to work instead of having their time wasted installing something that does not work.

If you say to your publisher - do you want it now and full of so many bugs that you will get so much bad publicity that shares will drop or do you want it delayed by 2 months and not have the bugs?

If this was a real world case then getting the target specs would have been part of the initial sign off before development even begun. If the target specs are delayed by a month then the whole project slips back by a month.

Andrew Sage Wrote:I am also aware of the benefits of delaying shipment of a product in order to ensure it is fully tested.

And this very cost vs risk decision is what I like about the contest. You can choose to devote more time to add new graphics/features, or you can choose limit your game a little and spend time fixing bugs and reaching a broader audience. The judges should and will be judging the full experience of playing your game, it is your responsibility to make that experience the best you can in the time allotted.

Quote:If you say to your publisher - do you want it now and full of so many bugs that you will get so much bad publicity that shares will drop or do you want it delayed by 2 months and not have the bugs?

And do you think the producers and publishers will work with you next time, since your inability to deliver cost them hundreds of thousands of dollars? They have marketing dollars invested in the game, target selling seasons to hit. They may very well decide to drop your game right then and there instead of taking a (potential) loss on the project.

KittyMac Wrote:And do you think the producers and publishers will work with you next time, since your inability to deliver cost them hundreds of thousands of dollars? They have marketing dollars invested in the game, target selling seasons to hit. They may very well decide to drop your game right then and there instead of taking a (potential) loss on the project.

If this is the case then why are so many products (be they games, applications, operating systems or games consoles) never shipped on time and delayed by years some times?

Seeing that the contest is sponsored by the Unity lot then I guess the specs on their site for using Unity should be a good baseline. Any body care to verify / shoot this down in flames?

System Requirements

Mac OS X "Panther" 10.3.9 or later
Radeon or GeForce graphics card with 32 MB of RAM
Will run fluently on any Intel Mac
On PPC based Macs, we recommend a 500MHz G3 processor or better
(games will run on Windows 2000/XP and Mac OS X "Jaguar" 10.2,
and a Rage 128 graphics card or better depending on complexity)

Maybe it would be useful for us to all note what we developed it on in our official entry thread?