I had an idea for a new Perl (programming) game today, let me know if it already exists or I am crazy.

Group Code (temp lame name)

Group Code is a project based game and teaches coding in groups as well as expands the players understanding of the language or at least the diversity of it.
One person acts as the "Manager" they decide what needs to be coded, time allowed, team size, and constraints (aka requirements).
Once the Manager has determined everything, people volunteer to be on a team. Once teams are created the Manager then randomly assigns the first round of coding to one of the team members. The team member is NOT allowed to know who the Manager is. The team member will receive initial requirements and guidelines and can start anywhere they want on the project. They will also receive a time/date that there work has to be returned by no matter what state it is, in. They can forfeit their turn, in which case the code advances with no revisions (see points below). When returning the code to the Manager the player can/should include a file called "HELP" which would contain questions about the project or aspects of the project. The Manager can then decide to revise the requirements based on the HELP file or simply forward the HELP file with the package to the next player. This continues until each player returns the code ball stating they feel it is complete.

Now for the really fun part, you can't talk to the other players. You are given the code blind of the other players. It relies on honest players, since I can think of a dozen ways that a person could include contact information inside of the code ball innocently enough, but the Manager should look for any blatant attempt to supply contact information.

Points are awarded by finishing ahead of time and satisfying all the requirements. Extra points can be earned by adding beneficial features as long as the requirements aren't compromised. If a player returns the code earlier then the date originally suggested by the Manager, the Manager has to decide if the player should be penalized or rewarded, based on the reason for the early return, returning because they feel it is complete is NOT eligible for penalty or reward.
The final code ball would be placed in a public location and judged by whom ever wanted to download and test the project. Since I would like this to be a part of the Perl Monks, there could be XP awarded to the winning players and the players could vote on how well the manager did his job to determine how many points they earn.

To test the game I thought it might be fun to make the game the first project. Create a system that would support game play, that is does the auto select of the first person to get the code and the order in which the code would be passed to the other teams. It would manage the return of the code ball, notifying the Manager the ball is waiting for review and then send the ball along once approved again by the manager. It would also allow a user to mark the ball as completed. The players would be able to see how many players there are, the date they should expect to get the ball, and how many players have marked it as complete.
Another idea is to have the system related with Perl Monks and Monks can select to be included in their profiles and the gaming system would auto create teams based on XP and make an even spread of "assumed experience".
I know this is a much more complicated sport/game then Perl Golf, but I think it holds more real application then Golf.

THIS WOULD NOT BE A WAY TO GET A PROJECT DONE. IT WOULD DEAL WITH ABSTRACT CONCEPTS THAT COULD BE APPLIED TO "REAL" PROBLEMS. "REAL" PROBLEMS THAT ARE COMMUNITY RELAVENT (perlmonks site, common problems) WOULD BE FAIR GAME.

This is just food for thought.

Replies are listed 'Best First'.
Re: Fun new game ???
by Juerd (Abbot) on Apr 15, 2002 at 16:37 UTC

    Such a game already exists, and unfortunately, many people are forced to play it daily. The only good thing about those people being forced to play it, is that they get paid to do so, and get a nice "Software Maintianer" title. The ones who actually start the game, didn't know about the rules when they started, but for some undefined reason, they abide by all rules specified.

    There is a small difference between your rules and the rules of the game that I know is currently being played. In the real life version of this game, the players are allowed to talk to the Manager, but that does not make it any easier. The Manager has no knowledge of what is happening, and because he manages so many projects, he thinks using Tie::Hash::Cannabinol may help.

    When requirements change, players get two days to finish the project unaltered before the new requirements are told, so they can train making modular programs that can easily be changed. Another type of special person comes to play in the real life version: the Maintainer. The Maintainer is the only one allowed to write documentation, and makes sure the project can still be run when the game has officially ended. The Maintainer does not get to have a gun, although he does get to use some other LARTs, if - and only if - he manages to rewrite the entire project. 

    - Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

[reply]
      Interesting verbiage, "forced to play it". I would say that is not true. Many people may be "forced" to take on certain types of jobs, but I can't remember any time that someone told me they became a software developer because that was the only option they had.

      On a more (or less) serious note, the scale of the "project" within my imaginary game is very small/limited. I also think that perhaps if played on a small scale people will be able to identify problems that may arise on a large scale. It also gives people that are not currently in management an oppurtunity to try their hand at it if they are so inclined.
      I will admit my first proposed game would most likely turn into something less then small/limited, but in a way that is part of the fun/challege. Making something that solves a problem without generating equally as large if not bigger problems is a real part of software development.

      I do agree that it might be tedious to people like myself that do development everyday, but it would also provide exposure to those that don't have any as well as that are thinking of becoming managers.
      Another aspect that I didn't bring up in my original post was the post game recap. The Manager and players could post their summary of how things went, problem areas, etc. It would be interesting to see how certain problems were attacked by different people in a non threatening (non-work) environment. So in that vain I guess obfu code would result in point reduction.

      Just like firefighters burn real buidings for training we should have a fun place to do development training. If there are other ways to do this in a non-production team environment let me know.
[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.

Back to Meditations