Contest ideas for next year

[jdarling]

Well, seeing as how this years contest is over, and some of us have already made some suggestions. I thought I'd start a thread of ideas for next years compo. Here is mine:

PGD Casual Gamming Contest

Causal Gamming has become one of the next areas for breakout games. Can you design and build a casual game that will take over the world? This is your chance, make your game, submit it to PGD, and see if you can compete with the likes of Solitaire, Tetris, BeJewled, and many more.

The idea is a simple one, design a game that follows the casual game common features:
• Extremely simple gameplay; usually a puzzle game that can be played entirely using a one-button mouse or keypad
• Allowing gameplay in short bursts, during work breaks with no need for saving games
• No plot or character, or simple ones with no bearing on the game's mechanics.
• Little to no music, but often catchy and musical sound effects
• 2D, abstract graphics (3D is also acceptable, but be careful as its easy to cross the lines into a non-casual game)

Some Rules:

What would a contest be without any rules? Well here are the constraints:
1) Stay within the common features:
a. Extremely simple gameplay; usually a puzzle game that can be played entirely using a one-button mouse or keypad
b. Allowing gameplay in short bursts, during work breaks with no need for saving games
c. No plot or character, or simple ones with no bearing on the game's mechanics.
d. Little to no music, but often catchy and musical sound effects
e. 2D, abstract graphics (3D is also acceptable, but be careful as its easy to cross the lines into a non-casual game)

2) Keep the game download small. Casual gamers’ don’t want do download 800Mb to install your game. Heck most of the time they don’t want to download 20Mb. So keep it small.

3) DO SOMETHING ORIGIONAL! Don’t just build another version of Tetris, we have all seen them, and you won’t get originality points (a large share of the points).

4) Build it in the time allotted. Yep, it looks like a lot of time up front, but keep in mind that you have to meet your deadlines, or loose points for not doing so. In the end the final game is what matters most.

5) PASCAL: All entries must be made using Pascal, Object Pascal or any of the Pascal-based languages available. The most popular of these compiler aned IDE tools are Delphi, Kylix, Free Pascal, Lazarus and Dev-Pascal.

6) PLATFORM: The only platforms we will be accepting games for this year will be Win32 and Linux. Bonus points for cell phone versions, but if it wont work on the judges phones no points from that judge.

7) OPEN SOURCE: This year we are letting the competitiors choose to include source or not. This will allow the games created in this competition and their engines to be used for commercial use afterwards. The option is yours, but you don't have to include it to compete this year.

8) STAGES: Again this year we will be breaking the competition into several stages. Each stage will have a set deadline. Each stage you will be given a set number of development goals to complete which will each be worth a set amount of points.

If you have any number of incomplete goals, you may still continue until the end!

9) SCORING FOR GOALS: Each stage will be scored as FULL points or NO points for completed and in-competed goals. If a goal is partially completed, it will be scored as incomplete and awarded NO points.

10) FINAL SCORING: After all the stages are complete and the final submissions are uploaded the judges will then begin awarding each entry with scores for each of # categories; graphics, sound & music (minimal), stability & lack of bugs, most importantly fun factor and addictiveness.

11) SUBMISSIONS: You must submit a working executable on or before each stage deadline to show your completed goals. If no entry has been submitted by the deadline all goals for that stage will be considered incomplete and NO points will be awarded.
Each submission will be either a single archive, compressed with a common format(Zip, RAR or GZip), that contains the executable and ALL other required game data and library files that are CLEANLY organized within OR a single installer that will both install and uninstall cleanly.

The easier it is to setup and run you game on any Linux or Windows system, the happier the judges will be about trying your entry!

12) SIZE: Even though casual games should be small, we will allot a total Zip compressed size of 20Mb to your game. Over this and your DQ’d, staying under this could gain you some extra points.

The Stages:

Stage 1: Design (1 Week)
20 Points, submit a full workup of your game idea. This should be a complete design similar to what you would put in front of a major game design firm. Yes, you can add/remove things as you go, but your final game will be judged against how closely you followed your design.

Stage 2: Basic Concept (2 Weeks)
10 Points, Get a basic engine up and running.
10 Points, Get a mockup of your game running in this engine (this could be as simple as scrolling though some bitmaps showing the idea).

Stage 3: Get it running (2 Weeks)
20 Points, Get the final version of your game flow working. This means making the game actually play the way you want. No sound or advanced graphics are necessary at this stage.

Stage 4: Make it flashy (2 Weeks)
20 Points, Now is the time to put those pretty graphics in place, add the sound effects, background music, and the rest. Remember to keep the common features list in mind, and don’t go overboard taking from your games addictiveness and size.

Final Scoring:

Size:
0-2.0Mb: 20 Points
2.1-5Mb: 10 Points
5-10Mb: 5 Points
Over 10Mb: 0 Points

Time Management (Stages 2-5 Goal Points Added) - Max. 100 Points x 2 Judges = Max. 200 Points

Graphics (Judged Score) - Max. 100 Points x 2 Judges = Max. 200 Points
Music & Sound (Judged Score) - Max. 100 Points x 2 Judges = Max. 200 Points

Game Stability (Judged Score) - Max. 100 Points x 2 Judges = Max. 200 Points

Fun & Innovation (Judged Score) - Max. 100 Points x 2 Judges = Max. 200 Points

Total Score - Time Management + Graphics + Music & Sound + Game Stability + Fun & Innovation = / 1000 Points

[tux]

whatever we do for the next one. please do not have stage goals and deadlines! (just the last big deadline) that pretty much killed our entry as we were plodding along getting bits done and then suddenly we realise we have to do 3 main things for the next deadline and rush it.

[jdarling]

whatever we do for the next one. please do not have stage goals and deadlines! (just the last big deadline) that pretty much killed our entry as we were plodding along getting bits done and then suddenly we realise we have to do 3 main things for the next deadline and rush it.

The deadlines make it more realistic, IMHO. When you designing a game for a company, you don't get the option of performing or not performing a task on the list. Sure you can move it to another "deadline" but that only ends up in you looking bad. I also believe that the deadlines presented in this years compo were a bit, umm.. off. They could have been orginized in a different manor, but overall they were exactly as I've seen in real world applications. Get the thing running, get the basics in, advance the backend, advance the frontend, produce it. The only real complaint I have is that design documentation was not required, and thus adheriance to it was not required. With deadlines, this is a must!

[grudzio]

whatever we do for the next one. please do not have stage goals and deadlines! (just the last big deadline) that pretty much killed our entry as we were plodding along getting bits done and then suddenly we realise we have to do 3 main things for the next deadline and rush it.

I second that. Actually stages and deadlines were the reason why I did not enter the competition. I am a hobbyst programmer, making games is my hobby. Sometimes I can work on my projects four hours per day and sometimes it is four hours per week. With one final deadline there is a chance that I can make it. Otherwise it is no point for me to take a part in a competition.

Another problem is a timeline. How to design it, so that length of each stage reflects its difficulty which is relative. Some people would like more time to create game engine and less time for level design and some would like the opposite.

The Casual Gamming Contest sounds like interesting idea but I would prefer something more in the style of a GameDev Four Elements Contest although less weird (This Emotion stuff is really bringing me down).

[AthenaOfDelphi]

I actually agree with Jeremy.

The stage goals should encourage you to plan the work, and should if organised correctly, provide incremental functionality gains. This is a good way to work for two reasons. The first, you feel like you are making progress because you can see the improvements... sitting their coding without seeing any gains can be very disheartening and this is an all to easy situation to end up in if you don't plan. And there is the second big plus... good planning (whether you are a hobbyist or a seasoned pro) can make the difference between success and failure and if you have goals that you can mark off... its more progress that you can see, which of course helps the first reason.

It should also be remembered that the goals only account for 20% of the final score. If you have a blindingly original concept that is implemented well, looks nice and plays well, then you could still win by getting high scores on the other sections.

Overall though, I like the general concept of casual games... I also quite like the timescale. Its not so much of a commitment and so more people may compete.

Just my $0.02

[Zenophran]

I honestly think that without the deadlines (as much as I hate them) we wouldn't have completed our entry. They are one of the big things that gave us the motivation to keep going. Especially after seeing some of the other entries (Tanx and SCAG, I was looking at you :-) )

To be honest though, monthly deadlines would have made things a little easier.

Another thing that would have been nice is to be able to see how all the competition is going through development. I know most people wont agree to it, but if each submission required a screenshot you could get a development gallery going to keep people interested. I admit I was one of the ones that didn't put anything up, mainly due to lack of hosting, however I think it would give people incentive to try that bit harder.

Z

[michalis]

I'm after the deadlines. They were a great idea to force me to actually focus on more important things, instead of polishing some invisible things. I'm totally after making deadlines for the next competition. And as AthenaOfDelphi said, the time points are not so very important, so if someone really can implement in 2 weeks the same thing that takes others 2 months, he can still win the competition

Seeing various opinions about dealines in this thread, maybe such thing deserves a poll ?

I'm unsure whether I like Casual Games idea... Advantages are that such theme will make for a short competition, so more entrants, and originality will be awarded more. Hmm.. OK, maybe I like this idea actually

My idea for next year's competition was more like forcing people to do serious network fun. Maybe even something along MUDs/MMORPGs. But like Will said, that's not a "gameplay theme", it's a "technical theme", so I should probably rephrase it somewhat Other disadvantage is that such theme would require much more time and careful network testing. On the other hand, making an innovative and popular network game with free access could really promote Pascal among the Internet.

[grudzio]

The stage goals should encourage you to plan the work, and should if organised correctly, provide incremental functionality gains. This is a good way to work for two reasons. The first, you feel like you are making progress because you can see the improvements... sitting their coding without seeing any gains can be very disheartening and this is an all to easy situation to end up in if you don't plan. And there is the second big plus... good planning (whether you are a hobbyist or a seasoned pro) can make the difference between success and failure and if you have goals that you can mark off... its more progress that you can see, which of course helps the first reason.

I agree that good planning is a must. (Like Japanese say: Lots of planning wins, little planning loses not to mention not planning at all). I just do not like that the schedule is enforced on me. I would like to do it by myself.

As for the 20% penalty, well, in this year contest the remaining 80% of points would be enough to take the fourth place - I doubt anyone could win with only 800 points. For sure not me

And yes. The poll would be a good idea.

[cragwolf]

My idea is this:

1) All content (e.g. textures, music, models, etc) should be procedurally generated. In other words, we take our cue from the European demo makers.

2) Game theme, anything you like, except no violence. See if you can make a game where you don't shoot something.

3) Cross-platform in the sense that it should work on at least two platforms, one of which must be Win32 or Linux.

4) Open source. We learn from each other that way.

5) No stage goals. Are we working for a company or are we doing this for fun? One thing I would like to see is the requirement to generate a tutorial or article describing an interesting techniqiue or algorithm that you used in the game. We need more articles at PGD!

6) Time frame, let's say the deadline is Xmas. Gives us plenty of time to come up with something nice, and to talk about procedural generation of content.

[dmantione]

I think a requirement of supporting multiple platforms would benefit a lot of people here, but, I get the idea that many constestants have never used anything besides Windows. Since they would need valuable time to get experienced with another platform, this would prevent many developers from entering the competition. IMHO a multi-platform requirement is therefore a bad idea.

However, the current situation is not really fair either, since being multi-platform costs you extra time to develop and test for the other platforms. Therefore it would be a good idea to reward people.

It could be done with a formula, for example:
* 50 points or somthing like that are rewarded for multi-platform development.
* The game that supports the least platforms gets zero points.
* The game that supports the most platforms gets all 50 points.
* The score for games that are in between gets interpolated, i.e. score := 50* (platform_count-minimum)/(maximum-minimum)

For example:
* Game A supports Win32.
* Game B supports Dos and Win32
* Game C supports Linux, FreeBSD and Win32.

Game A supports 1 platform, B supports 2, C supports 3. The 0 points go to game A. Game C gets the 50 points. We interpolate for game B: 50*(2-1)/(3-1) = 25 points.