Next compo ideas


_wb_

Microbe
Staff member
Joined
Apr 5, 2012
Messages
5,390
Age
42
Location
Brussels, Belgium
After the very successful ReBirth compo in early 2012, and the DragonBox compo in early 2013, it makes sense to continue the "tradition".

EvilDragon has said that he wants to have a kind of "running competition" with regular deadlines, maybe every 4 months. This seems to be a very good idea to me.

I'm starting this thread to collect some ideas on compo rules etc.

Here are my thoughts:

1. Prizes are not that important, the goal of the compo is not to bankrupt ED or extract money from the community, but to have a friendly community competition that gives devs a goal to work towards and everybody a bunch of new releases to look forwards to. It's more about the community recognition and "glory" than about providing financial incentives for devs. So I wouldn't mind at all if future contests would have no prizes or only small symbolic ones.

2. There should be plenty of time for everyone to try everything. It should be encouraged that as many people as possible participate in the contest, not just devs, but also people who take the time to vote, write reviews, etc. Community feedback is a very good motivator for devs. Maybe there should be prize for the best reviewer.

3. It makes sense to have separate categories, especially to distinguish original stuff from ports. The 4 categories of the previous compo are a bit too much though. I would propose just two categories: "port" and "original".

4. The mix of community votes and jury is a good idea, I think we should keep that.

5. There was some discussion about the licensing requirements last time. I would still prefer an open-source-only compo, but I know that not everyone agrees with that. Still, I think open source should be promoted, and I don't think a prize bonus is the best way (cf. point 1 above). Here's a proposal: if there are going to be regular competitions, we can make some of them open-source-only, and some of them any-license (even commercial if you want). For example:

  • July 2013: open-source only
  • November 2013: open or closed source, but free (gratis) download
  • March 2014: anything goes (even paid stuff, but the jury members have to get a free copy)
  • July 2014: open-source only again
  • and so on
That way anyone can participate eventually, but the open-source stuff can participate all the time while the closed-source stuff may have to wait up to 8 months and the commercial stuff up to 12 months.
 
Hi,

I am waiting for a new competition, too. :D

Some nice ideas, let's comment them.

EvilDragon has said that he wants to have a kind of "running competition" with regular deadlines, maybe every 4 months. This seems to be a very good idea to me.
I think, he even thought of every 3 months. I was unsure about this short time, but I understood the argument in the end: There is no competition begin, only ends. That means, if you need more than 3 months to finish your project, just participate in the NEXT competition dead line. :) Especially with your first point, that would make sense.
1. Prizes are not that important, the goal of the compo is not to bankrupt ED or extract money from the community, but to have a friendly community competition that gives devs a goal to work towards and everybody a bunch of new releases to look forwards to. It's more about the community recognition and "glory" than about providing financial incentives for devs. So I wouldn't mind at all if future contests would have no prizes or only small symbolic ones.
Hm... I don't do my stuff for money, but I am proud and happy, if I win something. But vouchers about 400€ don't have to be indeed. But little vouchers or more sd-cards (until now I won 3 sd-cards ^^) would be nice motivations.
2. There should be plenty of time for everyone to try everything. It should be encouraged that as many people as possible participate in the contest, not just devs, but also people who take the time to vote, write reviews, etc. Community feedback is a very good motivator for devs. Maybe there should be prize for the best reviewer.
Good idea, but I don't know, whether this really helps. Often it seems to me, that the "short voting time" is just an excuse for not taking the time to test. We can of course just test it, but I don't think, that we will get much more voters and review writers.
3. It makes sense to have separate categories, especially to distinguish original stuff from ports. The 4 categories of the previous compo are a bit too much though. I would propose just two categories: "port" and "original".
I think, that is a good idea. With point 1 the price pot could be much smaller, too. ;)
4. The mix of community votes and jury is a good idea, I think we should keep that.
That is a point, where I am quite unsure... In the discussion I really liked the idea of mixed voting, because the community voting more for colourful than for finished projects, but I we look at the last votings, I was surprised and disapointed about the jury vote. First thing: The jury voted roughly like the community. So, why should we need it then? Furthermore the developer just got votes from the jury, but I hoped for some criticism, too. ;)
5. There was some discussion about the licensing requirements last time. I would still prefer an open-source-only compo, but I know that not everyone agrees with that. Still, I think open source should be promoted, and I don't think a prize bonus is the best way (cf. point 1 above). Here's a proposal: if there are going to be regular competitions, we can make some of them open-source-only, and some of them any-license (even commercial if you want). For example:

  • July 2013: open-source only
  • November 2013: open or closed source, but free (gratis) download
  • March 2014: anything goes (even paid stuff, but the jury members have to get a free copy)
  • July 2014: open-source only again
  • and so on
That way anyone can participate eventually, but the open-source stuff can participate all the time while the closed-source stuff may have to wait up to 8 months and the commercial stuff up to 12 months.
The last idea is interesting, too. It solves indeed most of the problems. I like it. With 4 dead lines per year maybe on "commercial period" could be only 9 months instead of a year.
Just my thoughts about your thoughts. I REALLY look forward for a new competition. :D
 
You know, if a new compo comes soon, I could enter The Tournament Hub (as I'm now calling it)... Quick get it sorted ;)

BTW - if you have a short cycle for compo's, you can't really have a detailed testing/voting time. Gotta play one or the other. Personally, I don't think you need them more than twice a year
 
Last edited by a moderator:
I all against simplifying categories to just "port" and "originals" since in my opinion you simply cannot judge a game versus an emulator or a software. It's like trying to say certain apples are better than bananas, while they are both fruits they are completely different (in taste, look, texture, smell, etc.).

Furthermore I agree with Ziz in that I felt the developers did not gain much from a jury vote.

The jury should allow insight into their voting process (by publishing the individual rankings or point tables for example - all anonymized of course) and in any case must give feedback to every author (just a paragraph will suffice).

I know this is much work (and off-putting), but if they don't do it a jury vote is not worth much, since it's just a few individuals whose vote is worth more for one reason or another (no disrespect to anyone in the last jury, they did a good job). Winning a competition (and a few golds) is not nearly worth as much as getting educated feedback on your work imo, also everyone below the winning ranks gets something out of the compo.

Therefore the jury should be comprised of expects in the respective fields and there may be a category specific jury (with certain individuals overlapping).

Though I see this is way too much work for a quarterly competition and more suited for something long running (like the Rebirth compo).

Finally, I have to mention this again: There needs to be more publicity and press - even just in this very forum.

The last two competitions have just been announced, then forgotten, then suddenly results. This does not generate enough attention worth the price pot and work developers put into their creations.

Best case would be a group of people conducting interviews, giving short status reports, etc. WHILE the competition is running, so everybody on the forum knows what's up and what to expect (apart from secret projects though - those might be teased however). I think Uni did a great job of this with the RIOT compo (see here). We now have an active blog, so this might not be as impossible as last time.

This generates attention and people will start following projects they like, it might shorten the voting process (since people know what to expect and are eager to try stuff), in any case it will lead to more people voting.

We have had banners for the last compos, these can be displayed on the forum (like last time), but also the shop, the repo and any other site Pandora related.

I also want to take the time to thank ED and everyone involved for taking their time and money, while I personally feel the last compos can be improved, I cannot deny that they lead to a few very nice applications and games.
 
Last edited by a moderator:
I vote "no" for making it mandatory to be open source :) there are couple of gems which would not have been rewarded (see DraStic, Aquaventure and others) if the compo was open-source only last time :)

I'm ok with a reward/bonus if something good is made open source, but I think the license is a matter of personal FREEDOM :D

Finally, I have to mention this again: There needs to be more publicity and press - even just in this very forum.
I can guarantee more visibility through Pandoralive for the next compo. I don't know if you count that as Press, though :)
 
BTW - if you have a short cycle for compo's, you can't really have a detailed testing/voting time. Gotta play one or the other. Personally, I don't think you need them more than twice a year
Not necessarily; there doesn't have to be any relation between the compo deadline frequency and the testing/voting time. If needed the voting for contest N could even still be going on when the deadline for contest N+1 arrives. Also the jury for contest N and N+1 doesn't necessarily have to be the same. And with a shorter cycle there are presumably also less entries per compo.

That said, I think a compo every 3 months is too much; every 4 or 6 months would be enough.

We could also have a series of small compos (say 3 or 4) with small prizes (say, biggest prize is worth 50 EUR or so), and then a big "Best of the best" compo which just contains all the top entries from those small compos together, with a long voting period, a jury that gives feedback, and bigger prizes.
 
Not necessarily; there doesn't have to be any relation between the compo deadline frequency and the testing/voting time. If needed the voting for contest N could even still be going on when the deadline for contest N+1 arrives. Also the jury for contest N and N+1 doesn't necessarily have to be the same. And with a shorter cycle there are presumably also less entries per compo.
Who's going to care about the previous compo when the new one arrives? Everyone would ditch the last compo to look at the new entries.
 
I can guarantee more visibility through Pandoralive for the next compo. I don't know if you count that as Press, though :)
I do, any kind of words about the compo are fine really and posts on your blog are the closest we will come to "press" probably ;)
 
I am against simplifying categories to just "port" and "originals" since in my opinion you simply cannot judge a game versus an emulator or a software. It's like trying to say certain apples are better than bananas, while they are both fruits they are completely different (in taste, look, texture, smell, etc.).
Yes, I get that point. But in the previous compo we had original emulators and ported emulators thrown together into one "Emulator" category, which is not really fair either, and we had one "Application" category where original little applications had to fight against big ported stuff like LibreOffice - also not really fair.

So to be fair you would need "Original game", "Ported game", "Original emulator", "Ported emulator", "Original application", and "Ported application". But that's not really going to work, some categories would get zero or one entries.

Besides, how do you compare a first-person shooter to a puzzle game? Or a word processor to a web browser or dev environment? It's apples vs bananas everywhere, unless you make very narrow categories, but then you have to restrict the compo to one or a few specific categories (e.g. "original platform games" and "ported scientific software"). And then people who want to make or use stuff outside those specific categories will not be happy.
 
Not necessarily; there doesn't have to be any relation between the compo deadline frequency and the testing/voting time. If needed the voting for contest N could even still be going on when the deadline for contest N+1 arrives. Also the jury for contest N and N+1 doesn't necessarily have to be the same. And with a shorter cycle there are presumably also less entries per compo.
Who's going to care about the previous compo when the new one arrives? Everyone would ditch the last compo to look at the new entries.
Maybe. Anyway, with a compo every 4 months you still have at least 3 months for testing/voting (assuming entries for the next compo are not released earlier than 1 month before the deadline).
 
I propose the following categories:

  • Entertainment
  • Entertainment (ported)
  • Helper
  • Helper (ported)
  • Worst abuse of the rules
 
Besides, how do you compare a first-person shooter to a puzzle game? Or a word processor to a web browser or dev environment? It's apples vs bananas everywhere, unless you make very narrow categories, but then you have to restrict the compo to one or a few specific categories (e.g. "original platform games" and "ported scientific software"). And then people who want to make or use stuff outside those specific categories will not be happy.
While I see your point, I strongly disagree.

In the end it comes down to judging how much you enjoyed or used an entry and how much work the author has put into it. (in which you can compare different genres, although that also is a matter of taste of course)

While you can enjoy a ported game just as much as an original one, the author of the original game has most certainly put more work in his creation, because the other game already existed. I feel like that should be rewarded.

I am not saying there is not work or effort required in porting, there certainly is and the good ports require quite a lot and also creativity that goes beyond simply compiling the app (like how to arrange controls on the small screen, etc.). But it is a different kind of work and should be judged differently to the work required to make an original game (music, graphics, gameplay, code, design, etc.).

EDIT: I am not sure how to solve this, creating 6 or more different categories is absurd, but having only "port" and "original" on the other hand also is in my opinion.
 
Last edited by a moderator:
How about that idea for the categories problem. We start the competition with two main categories "ported" and "original".

Furthermore we have the sub categories (for each main category), that have to be discussed, like game, application, helper and so one.

Every game is submitted to one specific category-subcategory-constellation. But however every subcategory with too few entries is merged to a "rest"-subcategory. With the attempt we have for every competition good seperating, but not empty categories.

As improvement of this idea, a tree could be a good idea, too and if a leave has too few entries all leaves of the node are merged as a new leave with more entries. E.g. (only for one main category):

1. Game

1.1 Platformer

1.2 "Mind-Games"

1.2.1 Puzzle games

1.2.2 Number games

1.2.3 Other

1.3 Strategy

1.3.1 Real Time

1.3.2 Turn Based

2. Application

etc.

If now only 1 game is in puzzle game and 1 in number games, the node could collapse to a new leave 1.2 "Mind-Games" with 2 entries. ;)
 
I vote "no" for making it mandatory to be open source :)
I agree. People may vote open source entries higher if it is very important to them.


As for categories, it worked well enough last time. Some suggestions here have been "over engineered" to be polite! For simpler, I agree with Christoph.Krn :


- game/emu (orig)


- game/emu (port)


- app/tool (orig)


- app/tool (port)


- abuse of the rules lol IDK maybe
 
Last edited by a moderator:
I would be careful with the frequency that you have competitions. I think everyone a competition more than every four or five months is too many. It would really dilute what makes them special.


In addition I recommend you check out these competition ideas from tigsource.com. They are very varied and appeal to many different groups of people.


http://www.tigsource.com/2008/10/05/demake-compo-results/


http://www.tigsource.com/2010/01/20/assemblee-competition-voting/


http://forums.tigsource.com/index.php?topic=13392.0


http://forums.tigsource.com/index.php?topic=13392.0
 
Would it be an idea to make each competition have a main theme?

So for the first competition: platform games

second competition: general/misc applications

third competition: emulators

forth competition: 3d games

etc
 
Nice idea Ziz, but then there is no way to tell in advance (before all entries are submitted) how many categories there are going to be, so it's a bit hard to announce prizes in advance. On the other hand, if you require (say) at least 4 entries per category, then it is highly unlikely that there will be a huge amount of categories, because that requires a huge amount of entries spread evenly along the leaves of that category tree.

A simple solution would of course be to merge nodes until the total number of categories is low enough.

I like this!

We would have to agree on a suitable category tree though.

How about:

A. Original

A. 1. Original Game

A. 1. 1. Original Action/Skill Game

A. 1. 1. 1. Platform game

A. 1. 1. 2. FPS game

A. 1. 1. 3. Arcade game

A. 1. 1. 4. Racing game

A. 1. 1. 5. Other

A. 1. 2. Original "Mind" Game

A. 1. 2. 1. Puzzle Game / Logic Game / Blocks Game

A. 1. 2. 2. Board Game / Card Game

A. 1. 2. 3. Strategy Game (RTS, turn-based)

A. 1. 2. 4. RPG / Adventure Game

A. 1. 2. 5. Other

A. 2. Original Non-Game

A. 2. 1. Original Emulator

A. 2. 1. 1. Game Console Emulator

A. 2. 1. 2. Computer Emulator / Calculator Emulator

A. 2. 1. 3. System/OS Emulator (stuff like apkenv or qemu)

A. 2. 2 Original Application

A. 2. 2. 1. Office/Productivity Applications

A. 2. 2. 2. Music / Video

A. 2. 2. 3. Graphics / Drawing

A. 2. 2. 3. Education / Science

A. 2. 2. 4. Programming tools

A. 2. 2. 5. Alternative OS'es (e.g. RISC OS, Slackware; these will most likely be in the "ported" subtree though)

A. 2. 2. 6. Other

B. Port

B. 1. Ported Game

...

B. 2. Ported Non-Game

...

Let's say the previous DragonBox compo was organized in this way, with a maximum of 4 categories.

The entries would be as follows (I'm not sure about all the classifications, but this is just an example):

(Original games)

A. 1. 1. 2. FPS game: Escape from Castle

A. 1. 1. 3. Arcade game: Chav Fighter, Earth Invasion

A. 1. 2. 1. Puzzle Game / Logic Game / Blocks Game : AquaVenture, EvalMaster, Frootopia, Hexgem, Number Mind, Puzzletube

A. 1. 2. 3. Strategy Game (RTS, turn-based): Muon, Microbes

(Emulators)

A. 2. 1. 1. Game Console Emulator: 8Blitter, DraStic

B. 2. 1. 1. Game Console Emulator: PPSSPP

B. 2. 1. 2. Computer Emulator / Calculator Emulator: arcem

A. 2. 1. 3. System/OS Emulator: apkenv(.ui)

(Applications)

B. 2. 2. 1. Office/Productivity Applications: Claws Mail, LibreOffice

A. 2. 2. 2. Music / Video: EasyTag, Gmu Music Player, Imagination, PLUM

A. 2. 2. 3. Education / Science: Xplanet frontend

A. 2. 2. 4. Programming tools: Cz

B. 2. 2. 4. Programming tools: Code::Blocks

B. 2. 2. 5. Alternative OS'es: RISC OS, SOLEIL

B. 2. 2. 6. Other: psp-maps

(Ported games)

B. 1. 1. 2. FPS game: DukeNukem 3D

B. 1. 2. 1. Puzzle Game / Logic Game / Blocks Game: Xlogical

B. 1. 2. 2. Board Game / Card Game: PanLink

B. 1. 2. 3. Strategy Game (RTS, turn-based): Stratagus, Widelands

First we merge nodes until no node has only 1 or 2 entries. We get the following:

A. 1. 1. Escape from Castle, Chav Fighter, Earth Invasion (3)

A. 1. 2. AquaVenture, EvalMaster, Frootopia, Hexgem, Number Mind, Puzzletube, Muon, Microbes (8)

A. 2. 1. 8Blitter, DraStic, apkenv(.ui)  (3)

A. 2. 2. EasyTag, Gmu Music Player, Imagination, PLUM, Xplanet frontend, Cz (5)

B. 1. DukeNukem 3D, Xlogical, PanLink, Stratagus, Widelands (5)

B. 2. PPSSPP, arcem, Claws Mail, LibreOffice, Code::Blocks, RISC OS, SOLEIL, psp-maps (8)

We still have 6 categories left so we also have to merge nodes until there are no nodes with only 3 entries. Four groups remain:

A. 1. Escape from Castle, Chav Fighter, Earth Invasion, AquaVenture, EvalMaster, Frootopia, Hexgem, Number Mind, Puzzletube, Muon, Microbes (11)

A. 2. 8Blitter, DraStic, apkenv(.ui), EasyTag, Gmu Music Player, Imagination, PLUM, Xplanet frontend, Cz (8)

B. 1. DukeNukem 3D, Xlogical, PanLink, Stratagus, Widelands (5)

B. 2. PPSSPP, arcem, Claws Mail, LibreOffice, Code::Blocks, RISC OS, SOLEIL, psp-maps (8)

So in this case the remaining categories would have been "Original Game", "Original Application/Emulator", "Ported Game", and "Ported Application/Emulator".
 
Some really interesting ideas here, and although I'm not going to be able to enter anything worthwhile in a contest yet (beginning coder here), I'd like to weigh in on a couple of things which makes sense to me.

I think that a bi-annual contest seems about right - almost like an (American?) TV season sort of time-table... A Spring/Summer contest & a Fall/Winter Contest.  Three or even 4 contests a year might dilute the quality and quantity of the submissions (IMO).  Although I can see how a "rolling-over" of an unfinished work (being submitted in the following competition) would help alleviate some problems.  That idea has some merit - if you do increase the frequency of the contests.

So I'd vote for 2 compos a year - which would also be less of a burden on ED as far as prizes being awarded is concerned.  Regarding that -

1. Prizes are not that important, the goal of the compo is not to bankrupt ED or extract money from the community, but to have a friendly community competition that gives devs a goal to work towards and everybody a bunch of new releases to look forwards to. It's more about the community recognition and "glory" than about providing financial incentives for devs. So I wouldn't mind at all if future contests would have no prizes or only small symbolic ones.
I think that this is also a sensible stance, at least until the OP Team is out from under it's current financial constraints.  Maybe some SD cards (or extra surplus from ED's shop/vouchers) is better than cash prizes.  Also, along those lines, maybe a certain "badge" (not unlike the "supporter" one) could be placed below the person's avatar.  Maybe a "Gold/Silver/Bronze Medal" icon denoting the winner's placement in the compo for all to see and give praise to.   :)  

Foxblock also alluded to the "feedback" from testers to the devs is important.  I for one - now that I have my Pandora - will be trying out all of the entries from now on and will try my best to give back "helpful" feedback.  Positive isn't always helpful...well, I guess that depends upon your definition of "positive" I guess...so I said "helpful".

Lastly, I'd recommend more than two categories.  That won't be enough to cover all of the types of software.  This will lead to obvious conflicts.  Much like when Metallica lost out to Jethro Tull in the 1st ever "Heavy Metal" category in the 1989 Grammy's...that one still stick in my craw...but I digress (yet again)...  :D  

Anyway, that's just my two cents - but whenever the next Compo hits the boards, I'm looking forward to it and participating in it in any sort of small way that I can.  Thanks for reading (my nonsense)...
 
I suggest an annual 'entertainment' compo (emus, games, media players) and a ('work') compo (office, programming, tools), on cycles six months apart from each other.

In both cases, there should be a small bonus for open-sourcing your work
 
Back
Top