Re: Hey Larry "Wanna Get Away" hehehehehehehe
The Better Way to Email You have received a video message from [EMAIL PROTECTED] - Original Message - From: "darryl pollard" <[EMAIL PROTECTED]>To: BrothersGolf@googlegroups.com Sent: Sunday, September 14, 2008 2:04:15 PM (GMT-0800) America/Los_Angeles Subject: Re: Hey Larry "Wanna Get Away" hehehehehehehe riff-raff down and gaming the system in various ways to get special > favors while denying them to others. Like defining wage increases to > be inflation, and bringing the full power of government to bear to > prevent them. Collaboration, as in microfinance or the Sarvodaya > Movement, is the actually effective development strategy in practice. > > See also Axelrod, The Evolution of Cooperation. > > On Thu, Aug 21, 2008 at 12:46 PM, Robert Myers <[EMAIL PROTECTED]> > wrote: > > 1. Project name : Village > > 2. Existing website, if any : > http://wiki.laptop.org/go/User:Rmyers/Village > > 3. One-line description : economics simulation game > > > > 4. Longer description : game simulating simple economic > activity. > > Buying, selling, trading, developing resources, competing and > colluding. > > The player tries to maximize his wealth, but the village as a whole > also > > has to succeed. > > : > > : > > : > > > > 5. URLs of similar projects : > > > > 6. Committer list > >Please list the maintainer (lead developer) as the first entry. > Only > > list > >developers who need to be given accounts so that they can commit > to your > >project's code repository, or push their own. There is no need to > list > >non-committer developers. > > > > Username Full name SSH2 key URL > > E-mail > > - > > -- > >#1 Rmyers Robert Myers > >#2 Nikki Lee (possible) > >#3 Andrew Bouchard (possible) > > ... > > > >If any developers don't have their SSH2 keys on the web, please > > attach them > >to the application e-mail. > > > > 7. Preferred development model > > > >[X] Central tree. Every developer can push his changes directly to > the > >project's git tree. This is the standard model that will be > > familiar to > >CVS and Subversion users, and that tends to work well for most > > projects. > > > >[ ] Maintainer-owned tree. Every developer creates his own git > tree, or > >multiple git trees. He periodically asks the maintainer to > look > > at one > >or more of these trees, and merge changes into the maintainer- > owned, > >"main" tree. This is the model used by the Linux kernel, and > is > >well-suited to projects wishing to maintain a tighter control > on > > code > >entering the main tree. > > > >If you choose the maintainer-owned tree model, but wish to set up > some > >shared trees where all of your project's committers can commit > > directly, > >as might be the case with a "discussion" tree, or a tree for an > > individual > >feature, you may send us such a request by e-mail, and we will set > > up the > >tree for you. > > > > 8. Set up a project mailing list: > > > >[ ] Yes, named after our project name > >[ ] Yes, named __ > >[X] No > > > >When your project is just getting off the ground, we suggest you > eschew > >a separate mailing list and instead keep discussion about your > project > >on the main OLPC development list. This will give you more input > and > >potentially attract more developers to your project; when the > volume of > >messages related to your project reaches some critical mass, we > can > >trivially create a separate mailing list for you. > > > >If you need multiple lists, let us know. We discourage having many > >mailing lists for smaller projects, as this tends to > >stunt the growth of your project community. You can always add > more > > lists > >later. > > > > 9. Commit notifications > > > >[ ] Notification of commits to the main tree should be e-mailed to > > the list > >we chose to create above > >[ ] A separate mailing list, -git, should be created > > for commit > >notifications > >[X] No commit notifications, please > > > > 10. Shell accounts > > > >As a general rule, we don't provide shell accounts to developers > unless > >there's a demonstrated need. If you have one, please explain here, > and > >list the usernames of the committers above needing shell access. > > > > 11. Translation > >[X] Set up the laptop.org Pootle server to allow translation > commits > > to be made > >[ ] Translation arrangements have already been made at > ___ > > > > 12. Notes/comments: > > This game was started earlier this month at the ILXO game jam. I'd > like > > a git to facilitate further development. > > __
Re: Wellington testers + Activities vs 8.2-759
Hi Martin, > Well, I get a "3 block" puzzle. Perhaps I don't understand the rules > completely, but clicking on the blocks didn't do anything interesting. > Other testers suggested I tried the larger games / blocksets and with > those I managed to get some implosions going, though I didn't manage > to solve one. The way the game works, you can only remove blocks if they are in a contiguous group of size *three or more*. There are other score-based games (like SameGnome) that allow you to remove blocks in groups as small as one or two, but Implode is intended to emphasize logic over accumulation of score, and the three-piece rule leads to puzzles that are more obviously solvable. I've tried to make the game "discoverable" by only highlighting the removable groups as the mouse cursor passes over them. There should always be a series of removals that clears the board. It sounds like you might have tried unsuccessfully to remove groups of one or two on the easy level and didn't try removing a larger group. Is this the case? If so, does the game perhaps need some sort of tutorial or hint mode? If you actually encountered a puzzle where it didn't let you click on *any* blocks on the board right after the board was generated, that would be a bug. The easy puzzles should be easily solvable -- even random clicking on blocks works for many of them. Thanks, -- Joe ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wellington testers + Activities vs 8.2-759
Hi Martin,
Thanks for testing!
> Implode-4
> - works well an 3 XOs tried!
> - The first ("easy"?) puzzle is not one you can use so it's fairly
> confusing.
> - Loading a large puzzle is also quite slow. (Is it trying to compute
> whether it's "winnable"?)
Yes, Implode tries to only create solvable boards; the time taken depends
somewhat on the random number generator and increases with the size of the
puzzle.
I'm not sure what is meant by "the first puzzle is not one you can use"...
If you mean that the puzzle is not solvable, that shouldn't happen, and
should be considered a bug if it did. But I have not yet encountered such a
board; in my experience every puzzle that initially appears unsolvable
turned out to be solvable when I undid a few moves and tried again. Or did
you mean that "easy" is not easy enough?
Thanks,
-- Joe
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [sugar] where is Walter?
On Mon, 2008-04-21 at 18:22 -0400, Walter Bender wrote: > > Thank you for all of your support over the past two years and for all > the feedback and encouragement you have given me. > > regards. > > -walter It really sucks to see OLPC shriveling up and dying. -- Resistance is not futile, it's (2PI * FREQ * L) / Q ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project hosting application: Implode
I figure now that people are playing this, using it as an activity-loading
test case, and filing trac tickets for it, it's probably overdue for source
control. :)
1. Project name : Implode
2. Existing website, if any : http://wiki.laptop.org/go/Implode
3. One-line description : Falling-block puzzle game
4. Longer description :
The game starts with a grid partially filled with blocks. The player
makes a move by removing adjacent blocks of the same color in groups of
three or more. When blocks are removed, higher blocks fall to fill their
space, and when a column is cleared, the blocks on either side close to
fill the gap. The object of the game is to remove all the blocks. Since
the patterns of blocks above changes when lower blocks are removed, the
player must carefully decide what order in which to remove the blocks so
that there are no isolated blocks left at the end of the game. (The
levels are generated in such a way that there is always a sequence of
removals that clears the board.)
5. URLs of similar projects :
http://www.chiark.greenend.org.uk/~sgtatham/puzzles/doc/samegame.html
http://live.gnome.org/Same_Gnome
6. Committer list
Please list the maintainer (lead developer) as the first entry. Only list
developers who need to be given accounts so that they can commit to your
project's code repository, or push their own. There is no need to list
non-committer developers.
Username Full name SSH2 key URLE-mail
- --
#1 leejc Joseph C. Lee http://jotaro.com/olpc/key.pub joe
at jotaro.com
If any developers don't have their SSH2 keys on the web, please attach
them
to the application e-mail.
7. Preferred development model
[X] Central tree. Every developer can push his changes directly to the
project's git tree. This is the standard model that will be
familiar to
CVS and Subversion users, and that tends to work well for most
projects.
[ ] Maintainer-owned tree. Every developer creates his own git tree, or
multiple git trees. He periodically asks the maintainer to look at one
or more of these trees, and merge changes into the maintainer-owned,
"main" tree. This is the model used by the Linux kernel, and is
well-suited to projects wishing to maintain a tighter control on code
entering the main tree.
If you choose the maintainer-owned tree model, but wish to set up some
shared trees where all of your project's committers can commit directly,
as might be the case with a "discussion" tree, or a tree for an individual
feature, you may send us such a request by e-mail, and we will set up the
tree for you.
8. Set up a project mailing list:
[ ] Yes, named after our project name
[ ] Yes, named __
[X] No
When your project is just getting off the ground, we suggest you eschew
a separate mailing list and instead keep discussion about your project
on the main OLPC development list. This will give you more input and
potentially attract more developers to your project; when the volume of
messages related to your project reaches some critical mass, we can
trivially create a separate mailing list for you.
If you need multiple lists, let us know. We discourage having many
mailing lists for smaller projects, as this tends to
stunt the growth of your project community. You can always add more lists
later.
9. Commit notifications
[ ] Notification of commits to the main tree should be e-mailed to the
list
we chose to create above
[ ] A separate mailing list, -git, should be created for
commit
notifications
[X] No commit notifications, please
10. Shell accounts
As a general rule, we don't provide shell accounts to developers unless
there's a demonstrated need. If you have one, please explain here, and
list the usernames of the committers above needing shell access.
11. Translation
[X] Set up the laptop.org Pootle server to allow translation commits to
be made
[ ] Translation arrangements have already been made at ___
12. Notes/comments:
-- Joe
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
