Summer PySomething?

knowledge on 2016/05/07 13:39
— edited on 2016/05/09 20:19

As we all know, blake decided to have 2 PyWeeks this year and that next one will be in early September here!

He also suggested PyWeekend in summer in that post.

While PyWeek veterans commented about improving PyWeek site, I haven't seen any thoughts about PyWeekend despite m0dem's! He said one weekend would be too short.

I would definitely like to have PySomething in summer (according to the survey most people want to), so we need to decide:

Whatever will it be, we need to hurry if we want to have anything this summer!

What are your thoughts, ideas and concerns?

(log in to comment)

Comments

Master47 on 2016/05/09 09:35:

Hello knowledge!

In my opinion, a PyWeekend should last two days. Of course, we can also do something which lasts longer, but then I would go for something like two weeks; maybe a PyFortnight?

I would also prefer June.

Well, the name probably depends on how long it will be. Or we could also go for a name like PySummerEvent, as you have said; I don't have a problem with that.

Hacking each others game so one has to debug it to make it run again sounds like a good idea to me; you can count me in. We probably need to either organise another event for that, or include it in the PyWeekend (or whatever it will be) event.

I can assist in organising it, if assistance is needed.

blakeohare on 2016/05/11 02:14:

I feel like any attempt to run a PyWhatsitamajig for a weekend via the current site infrastructure will end in unforseen technical horror, since everything is so hard coded to the PyWeek rules (e.g. theme voting, judging, etc). So this would more or less have to run as an informal message board thread or something.

Of course, someone who actually has write access and familiarity with the PyWeek codebase can completely refute the above assumption/course-of-action I'm making. I'm just a dude with magic permissions on my site account, but server-side I have no power.

If there's a polish-and-extend-someone-else's-code sprint, here are some hypothetical rules I'm making up as I type:

  • Everyone put their code in github if it isn't already.
  • Create a branch off your master branch called 'pyweek-polish'.
  • Go to someone else's pyweek-polish branch and fork it to your own repository.
  • Have fun over the chosen weekend.
  • Create a pull request at the end.

And of course it would be entirely up to the original owner to accept the pull request/merge back to master.

(although I feel a bit funny typing this knowing that I've already ported my master branch to another programming language >_>;;)

The great part is that even though it'll be fun if everyone does this at the same time (I hope they do), the above protocol doesn't actually require anything from the Pyweek site itself and you can do the above at any moment if the chosen weekend isn't ideal. Or if you're having a blast adding features to someone's code and want to keep doing it after "time's up", you totally can.

The only caveat of course is it should be organized to an extent that we don't have tons of people editing the same codebases in unpredictable ways resulting in sadness at pull-request-time. So maybe an informal sign-up sheet?

starheap on 2016/05/12 19:33:

I put basically this in the other comments of the poll posted in the other thread but i wanted to post it here for more discussion plus i've changed it a bit since then. We should only have a hack event. This event would be multiple rounds, the number of rounds would depend on how many days it will last, and generally what time zones people are located in. I would say for the first round you should be able to choose any entry from the past 3 years, as long as no one has already claimed it. Each round that follows you must swap codebases with someone. Basically In each round a codebase will only be in the hands of one person. Github should be required imo, so that if someone disappears in the middle of the challenge the chain of code isn't lost. If someone goes missing during a round, or needs to skip a round for various reasons. The orphaned project will be put back in the selection pool for the next round regardless if it works or not. In order to win each game at the end of the 3 days will be rated. The scores of all of the games you worked on will be averaged and whoever has the highest average score wins. We could also think about weighting the average scores at least emphasizing the first and last games someone worked on.

starheap on 2016/05/12 19:36:

I cant seem to edit the post, ignore the 3 days towards the bottom(leftovers) and yeah no formatting... :(

knowledge on 2016/05/12 22:28:

starheap, I thought more or less same thing when I proposed rounds and hacking a hack.

While I'm personally totally OK with that (and when I think about it, it seems even better than I first imagined) I'm not sure what others think.

Main difference between your and my plan is that I want to make games specially to be hacked on event (so called Main Event) which will be before Hack Event.

When making a game for Main Event people should:

  • make game easily expandable
  • make game code clear and readable
  • comment code (not much but at least weird parts)
  • do more mechanics and core things than polishing, level making, enemy types adding etc.

I generally don't follow these on ordinary PyWeek and when you try to hack game that hasn't got clear code and isn't easily expandable, I think it may be too hard.

I told you my opinion but I need other answers and opinions to be sure how will it be run.

starheap on 2016/05/12 23:09:

Well I sometimes actually like hammering terrible code into shape... But thats probably just me haha. Though I have a larger opensource project with plenty of need for this already so... yours sounds fine to me as well. I think mainly it will be awesome to see how games evolve going through person to person.

knowledge on 2016/05/16 20:47:

From responses in Poll and comments I concluded that PySomething will:

  • include one Main Event where games will be made and several Hack Event rounds where games from Main Event will be hacked
  • have Theme
  • start (Main Event) on 28.5, at 0:00 UTC
  • last 8 days (so Main Event ends on 4.6 at 24:00)
  • have 4 rounds of Hack Event, each 4 days long
  • have rule that in each Hack Event round hacker needs to hack latest version (in first round everyone will hack original, in second someone can hack original only if game wasn't hacked in first round)
  • have voting for 14 days after last Hack Event round (it starts on 21.6 and ends on 4.7)
  • use normal PyWeek categories for voting original game and final product (after 4th round)
  • use only one category (progress) for each Hack Event round
  • have special category for hacker of a game (code clearness, extensibility and documentation)
  • be entirely on GitHub

Theme and name will be decided later!

Do you have any questions, suggestions or comments?