PDA

View Full Version : Contest ideas for next year



jdarling
10-07-2006, 02:14 PM
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
10-07-2006, 02:19 PM
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
10-07-2006, 02:53 PM
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
10-07-2006, 04:14 PM
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
10-07-2006, 08:37 PM
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
10-07-2006, 09:31 PM
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
10-07-2006, 10:36 PM
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
10-07-2006, 10:48 PM
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 :P

And yes. The poll would be a good idea.

cragwolf
11-07-2006, 09:47 AM
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. 8)

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
11-07-2006, 12:12 PM
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.

michalis
11-07-2006, 12:55 PM
I'm after requiring open-source. I said this in the old thread when this year's competition started... but some people answered that they just don't want to go open-source. I think that at least some significant points should be rewarded for being open-source.

As for being multiplatform, I agree with Daniel: it should be rewarded wth points. Judges will probably have to limit the possible platforms that "count" anyway, surely these platforms that "count" should at least include Win32 and Linux/i386.



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.


That's interesting idea... But requiring *everything* to be procedural could make things too limiting, after all the "demos" are often pretty far from what we usually call normal "playable" games. I would rather allow textures and music and creature/object models to be stored in a normal way, but require procedural *levels* instead. This could make interesting fun to develop good level generator and make a game based on it...

Huehnerschaender
11-07-2006, 01:05 PM
I like the idea about a contest which is about randomly generated levels.

jdarling
11-07-2006, 01:16 PM
Bonus points for cross platform is a good idea, but the benifit does need to be small (50 points is about right on a 1000 point scale). This adds some real qualities to the cycle. Companies that do cross platform, get a little bit of gain (if they do it right).

Also the point for Open-Source points is a good one. This though should be a higher percentage of the points (IMHO). I think of it this way, if someone wants to enter into the compo but doesn't want their source displayed to the world then I wonder what/why/who they did wrong. Worse yet, what they are going to do to my system :).

In my scenario, something like 200 "Bonus" points could be awarded:
100: Open-Source
50: Multi-Platform
50: Size limitations (thus procedural generated stuff would get this if done right)

My only problem with a contest based around procedural generation is that I'm not sure how many people we would completely put out with the idea. Getting on a team this year was near impossiable if you didn't know anyone (I know I tried early on before I started my own). New developers may or may not have the time/knowledge/wits to pickup procedural methodology and make it work.

On MUDDs and MMORPGs; I see this as more of a long time running compo. It is a great idea, but you would have to take almost a year (if not more) and have detailed rules, regs, and a great deal of support hardware. This is even to judge the entries. If you place the blame of running the hardware on the entrants, they may not have the money to put up such a beast. Remember that most MMORPGs and MUDDs are server heavy beasts. I'm up for the compo, but I think it should be held seperately from the PGD anual.

Of course I still stand by the Stage Goals!

Just my two cents to try and keep the ideas going, I can't wait for next years compo :).

Zenophran
12-07-2006, 08:12 AM
Procedural content sounds interesting, but I don't know the first thing about doing it. Are there any tutorials on it? I admit to not searching first, but just trying to get a feel for how many people out there are up to speed on the techniques.

I like jdarling's bonus point idea (and agree on the milestones/stage goals).

dmantione
12-07-2006, 08:55 AM
I came to the conclusion that a big bonus for open source won't work. The reason is the open/closed source is a decision, and the bonus would therefore be based on decision instead of the work the team did.

Near the higher places, a 100 points bonus might sound reasonable for having source code. Near the bottom, 100 points means really a lot, I could image it could mean five places higher in the ranking. As I believe judging should primarily be about the game and not about the license, this is too much influence.

Zenophran
12-07-2006, 12:49 PM
Another option is to have two categories, open and closed source. I guess it really depends on what the competition is about. Is it purely promoting the fact that pascal is a capable language for coding games, or is it for promoting the use of pascal to code games?

If it's the latter, then an open source idea would be far more useful. Perhaps the entries could be dual judged - "Complete Game" and "Complete Game as a Tutorial"? This could extend to design docs, etc. Teams could choose not to enter a category if they wish.

Just a suggestion...

WILL
12-07-2006, 06:37 PM
Some interesting ideas and thoughts here.

The stage system is in place, but allows for any amount of stages/deadlines, from just 1 up to any 11 digit number, if so needed. (but I doubt that you'll see anything more than a double digit number) and also you can have any number of deadline goals too. It's all up to the rule-makers of the next PGD Annual.

It will of course maintain a gameplay theme... and be different from previous years. So I guess you can count out 'head to head or direct player vs player' and 'bosses and levels/stages'... But thats all I can predict being almost a whole 5 months ahead of the time to start really thinking about it.

Open source vs closed source is interesting... we decided to do closed because we wanted to see the reaction to offering closed sources. And I sort of felt that to offer the game up to the IGF in the hopes that the game would find an interested publisher there and/or 'make it' as a hugely successful commercial game (with it's obvious indie origins) it would help to have the sourcfe hidden to make this more possible for them.

These things should be carefully considered in the future, since the PGD Annual and the success of winning and popularizing your game is that it attracts this kind of commertial attention. And you can't sell what you've given away. So that might be one of the modivators of doing entering and doing all this in the first place. Who doesn't want to make video games for a living, right? :)


One idea I had pondered since after the first one... was that in time we could eventually expant the PGD Annual event and include smaller side competitions in addition to the main one. The Developmental Excellence Awards would still be offered to all competitions, but instead of going into the long competition (16 weeks this year, 10.5 weeks in 2005) it would give the option of then instead doing a much smaller one with a lighter theme and set of goals to complete.

This would be great for offering those that are looking for smaller competitions and those that really liked the 3-4 month big race to create the next great 'Doomafied' success per-say. Prizes would be smaller than the main competition, but thats only because of the scale of the main competition it's self.

This concept of course requires heavily on sponsorship, the judges and their time and available effort. It may be possible to gain judges from the sponsors themselves saving the need to put poor full-time workin' stiffs like Dean Ellis and Eric Grange to work for us and making them slave over hours of unpaid testing and game playing. (I guess it helps that games typically are fun, no? :))

I believe that GDNet does this with some of their competitions. It might work for us too in some respects. Perhaps having them judge the main event and leaving the side competitions to the part-timers.

It's something that I think I may propose to Dom for next year... but my doubts about being involved in the management of PGD for the main portion of 2007 still remains unlikely. Time will tell...

At least I got to enjoy the 2006 PGD Annual. ;)