Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Potential Schedule  (Read 17366 times)

0 Members and 2 Guests are viewing this topic.

Jebbs

  • Moderator
  • Sr. Member
  • *****
  • Posts: 358
  • DSFML Developer
    • View Profile
    • Email
Potential Schedule
« on: July 12, 2014, 10:32:37 pm »
Hey all,

I have been putting together some thoughts on getting the jam automated, and I am at a point where I am trying to nail down an actual schedule for when things will take place. Since we will be switching to voting rounds, I obviously want to give enough time for that in case we need to do many rounds, so things are set out far in advance. I'm just looking for people's opinions on if the ranges for things are too long/short.

Here's what I got:
2 months before the jam starts theme suggestion opens
2 weeks later theme suggestion closes
1 day later first voting round starts
5 days later first voting round closes
1 day later second voting round starts
5 days later second voting round closes
repeat voting cycle
1 hour before jam starts theme is announced
Jam goes for 72 hours
Entry submission opens 24 hours before jam ends
Entry submission closes 1 hour after jam ends for the stragglers and slowpokes


This gives us time for 6 rounds of voting, and plenty of time to get a game done and submitted. The only things I am thinking of changing at the moment are increasing the time people are allowed to submit and closing entry submission a little earlier.

Thoughts?
DSFML - SFML for the D Programming Language.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11032
    • View Profile
    • development blog
    • Email
Re: Potential Schedule
« Reply #1 on: July 13, 2014, 01:25:46 am »
Too much.

Six rounds of voting is just way too much. Personally I'd go with two rounds or if that's not enough maybe three rounds. The issue with the voting we had in the past, was that your only votes went to a huge list of subjects and thus you pretty much were overwhelmed with information, that most of the time you'd just choose whatever came to your mind. So the first voting (multiples votes) would be about selecting the most wanted top 5 and then start the second round of voting (single vote) would be about choosing the subject that sounds interesting and people will most likely think about it a lot more, if they can only choose one and have a very short list.

So over all the timing, would reduce itself to one month or even less.

But don't forget to announce Jams ahead of time, at best multiple times.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Potential Schedule
« Reply #2 on: July 13, 2014, 01:44:50 am »
I also agree with eXpl0it3r... having a fixed number of rounds isn't the best idea. Normally, multi-round voting is the result of an unclear result, where some form of majority is needed. As an example, if a specific theme already gains 90% of the votes in the first round, I don't think even a second round would be necessary. This probably won't be the case, but it will be relatively clear after maybe 3-4 rounds. I think pre-emptively ending voting once a clear consensus has been reached is the way to go.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Jebbs

  • Moderator
  • Sr. Member
  • *****
  • Posts: 358
  • DSFML Developer
    • View Profile
    • Email
Re: Potential Schedule
« Reply #3 on: July 13, 2014, 02:00:25 am »
Ah, perhaps I should have explained better. The number of rounds isn't fixed. 6 is the "worst case" type situation. A theme is going to be chosen only if it has greater than 50% of votes. If something is picked sooner then there just won't be any more voting. I just want to make sure there will be enough time if it ever comes to a not so quick selection.


By the way, my plan for voting is that after each round any themes that have 0 votes are automatically dropped and any theme with the next lowest number of votes(or maybe a little more depending on the round, number of votes, and number of themes voted on)  is dropped too. If we had done that for the last jam, it would have cut the number of themes to vote on in half in just the first round.
DSFML - SFML for the D Programming Language.

Flaco

  • Newbie
  • *
  • Posts: 36
  • Glory to Arztotzka!
    • View Profile
    • Core Unit
    • Email
Re: Potential Schedule
« Reply #4 on: July 13, 2014, 06:13:18 pm »
Why not just using a pseudo-random number generator to pseudo-randomly pick a theme?

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Potential Schedule
« Reply #5 on: July 13, 2014, 06:23:41 pm »
I think 3 is the absolute maximum for the number of voting rounds... more is just tedious.

Flaco, because we would like to have a theme that most people enjoy developing, rather than one that was just brought in without deeper thinking and has to be implemented although nobody is actually in favor it.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Flaco

  • Newbie
  • *
  • Posts: 36
  • Glory to Arztotzka!
    • View Profile
    • Core Unit
    • Email
Re: Potential Schedule
« Reply #6 on: July 13, 2014, 08:24:20 pm »
@Nexus: I see! :)

Also; 3 seems cool, even if I'm not really familiar with game jams planning and organization 6 seems redundant and a painful (and long!) process.
It's better to have more time to prepare and check the other aspects of the jam. :)

Good evening y'all!

therocode

  • Full Member
  • ***
  • Posts: 125
    • View Profile
    • Development blog
Re: Potential Schedule
« Reply #7 on: July 14, 2014, 05:09:12 am »
I think a strict schedule going over a few months like this is not a that good idea. For the same reason that I think that set dates for when the jam should be (i.e. every X months) is also a bad idea.
The reason for this is that the people who are managing and organising the jam are just doing it on their spare time, and spare time can be unpredictable. For example, the last jam was not very fun because we had 1 submission in the end, all other people had no time. Not even the arrangers had time to join or such.

That's why in my opinion it would be better to not have set schedules or dates, but instead plan/announce the jams when there is time available and enough interest by people joining them. That way we can have more qualitative jams, instead of a long succession of jams that not many people ended up having time for.