[OLPC-Games] Anyone interested in a Game Jam? +(SF)

Samuel Klein meta.sj at gmail.com
Fri Oct 26 21:23:13 EDT 2007


Mike, This is a great list!  Can you post it to the wiki?  I'll be in
San Francisco that weekend myself, is there anyone in the Bay Area
who'd be interested in helping to organize a get-together?

SJ

On 10/26/07, Mike C. Fletcher <mcfletch at vrplumber.com> wrote:
> Myles Braithwaite wrote:
> > I am definitely in.
> >
> Alright, as of now it's just Myles and I, with Soni maybe showing up if
> she's got time that weekend.  Anyone else interested?  We're still
> thinking of the weekend of the 16th of November.  (Same time as the CMU
> Game Jam IIUC).  With such a small number of people we might be able t
> hold it at Linux Caffe.  I'm going to be in Taiwan come Wednesday, so if
> we're going to have more people I'll need to know about it soon so I can
> find a bigger venue (and/or book a table or two at Linux Caffe).
>
> Here's a trial balloon for a very abstract real-time-strategy game.
> Very simplistic social modeler, with very limited set of units and rules.
>
>     * Grid playing "field" of a given size
>           o To start with, a simple grid
>           o Might allow for adding "dead areas" to the grid eventually
>           o To start with, regular territories within the grid
>     * Each player gets X starting units and places them on the board one
>       after another until the units are all placed
>           o All players must join before start-of-play
>           o Loss of a player stops play (game can be stored and restored
>             by any participant at any time, potentially with other users)
>     * Resource Production
>           o Resource production is proportional to the number of
>             productive units with adjacent empty land (regardless of
>             whether the land is within the territory the unit is in or
>             how many units are "farming" it).
>           o Productive units begin producing when they are adjacent to
>             empty land
>                 + They retain their production counter internally until
>                   it is used
>                 + Usage of resources is done evenly across all units in
>                   all controlled territories
>           o If a unit converts allegiance or moves to a new territory
>             then they take their collected resources with them
>           o A player's current wealth is the sum of the wealth of their
>             productive units in those territories that they control.
>             They may dispense this wealth as they see fit (given
>             constraints on unit maintenance)
>     * Unit Production/Maintenance
>           o Unit survival requires resources
>                 + Each existing unit requires a certain amount of
>                   resources to survive
>                       # this value is comparatively low for productive
>                         units (say 1/10 of a unit's production)
>                       # this value is comparatively high for military
>                         units (say 2/10 of a productive unit's production)
>           o All units must be fed (starvation)
>                 + No unit production possible if starvation
>                   (insufficient food for all units) occurs
>                 + In process unit production is canceled, 50% of
>                   resources are lost, 50% recovered to feed units,
>                   oldest production is stopped first, until all units
>                   are fed or all in-process production is canceled
>                 + If no units in-production, non-productive units are lost
>                       # Non-productive productive units (most dense area
>                         first)
>                       # Military units (those without empty squares in
>                         their area first (random), then any (random))
>                       # Maybe start off with simple random kill-off
>                         (easy to program)
>                       # (Note: I'd rather have the units switch
>                         allegiance that are in the
>                         other-player-controlled territories, but that's
>                         probably too involved for now)
>           o Controlled territories can produce new units
>                 + If there is no controlled territory, no new units are
>                   possible
>                 + New unit production requires significant resources
>                       # Setting for each unit-type, along with other
>                         requirements (e.g. city status, control of
>                         territory)
>                       # Maybe 500% of unit's production for a productive
>                         unit
>                 + Wealth remains with the productive unit until a
>                   controlled territory begins producing a unit
>                       # if you do not create units your productive units
>                         become targets for takeover
>                 + If a territory is taken over (control shifts to
>                   another player) while it is producing a unit, the unit
>                   becomes the unit of the controlling player (the unit
>                   is assigned to the controlling player at the moment
>                   the unit is created, but the cost is borne at the
>                   moment the unit is ordered)
>           o Cities
>                 + Very dense population centres, (i.e. those which
>                   occupy every point in a territory), will produce more
>                   mobile units which do not produce resources when
>                   occupying, but which contribute to
>                   controlling/occupying territories (military versus
>                   productive units)
>                 + Larger cities will produce ever more mobile units
>                   (i.e. two adjacent city territories)
>                       # e.g. one-territory city, 2-unit military,
>                         two-territory city, 3-unit military
>                 + Military units require exponentially more resources to
>                   produce for each level (e.g. a unit that can move 2
>                   squares at once would cost 4 times as many resources
>                   as a farmer, those moving 3 squares, 9 times).
>     * Territoriality
>           o Territories are controlled by having the largest population
>             in a territory (equal population splits available resources)
>           o Territories provide access to the controlling player to the
>             resources of that player's units in the territory
>                 + Players use resources of all of their controlled
>                   territories to start production of units
>           o Territories are YxY grid fragments, marked visually, so that
>             users can see the territory "boundaries" (it would be nice
>             to allow overlapping, shifting boundaries, but not likely to
>             be feasible)
>     * Conversion
>           o Each territory has a balance of power represented by a
>             simple count of the total number of units within it, with
>             the maximum count being the power in control (equal counts
>             == no controlling balance)
>                 + Each unit retains an internal counter of "allegiances"
>                   (one for each player)
>                 + Time within a territory controlled by another player
>                   increases the unit's allegiance to that power (without
>                   upper bounds, so a very old farmer is going to be far
>                   harder to sway than a young one)
>                       # Military units are less affected, but still affected
>                 + Units start with reasonably high allegiance to the
>                   player that created them, enough to withstand 10
>                   minutes or so in a foreign-controlled territory
>                 + Units belong to (respond to the commands of, provide
>                   resources for) the player to whom they have the
>                   greatest allegiance
>                 + Unit conversions will be reported to the user,
>                   individual unit's allegiances can be viewed one-by-one
>                   by hovering over the unit
>           o Player with balance of power for a territory can use the
>             resources of their units in that territory to produce new
>             units in any of their controlled territories
>     * Motion
>           o Movement is instantaneous, that is, it occurs at a discrete time
>                 + All units can move across un-occupied spaces in
>                   response to commands by user
>                 + Productive units can only move slowly through
>                   un-occupied space (e.g. 1 square at a time, every 15
>                   or 20 seconds)
>                 + "Military" units can move farther/faster  through
>                   un-occupied space (e.g. 2 squares at a time, on the
>                   same period)
>           o Controlled square motion
>                 + Units can travel instantly through a chain of their
>                   own units
>                 + Productive units cannot move through opposing units'
>                   occupied squares
>                 + Military units can move across opposing unit's squares
>                   if there is an empty square within their movement
>                   range (i.e. a 3-square military unit can jump two
>                   opposing player's squares, but a 2-square unit can
>                   only jump one)
>                 + Military units can combine a move through a chain of
>                   their own units and a jump over an opponent.
>           o Player can move as many units as they want as often as the
>             units are allowed to move (real time operation)
>                 + New units appear at the closest un-occupied square to
>                   the center of their creating territory
>     * Goals
>           o Report "success" at any point in time along various measures:
>                 + Territoriality (Conquest, number of territories
>                   occupied/controlled)
>                 + Resource Base (Money, total income over time)
>                 + Technology (Maximum "tech" level (military distance),
>                   number of cities)
>                 + Population (Simple count)
>                 + Loyalty (Average allegiance of population)
>
> Implementation Ideas
>
>     * UI
>           o Simple grid playing field (easy to program quickly in PyGame)
>           o Unit-type icons required
>                 + At least two icon types (military and productive)
>                 + Each player gets their XO colours assigned to their icons
>                 + Need to look into colour-reliance issues, may need to
>                   provide different icon sets so that black-and-white
>                   mode is playable
>           o Single-unit-selection only
>                 + Hover to see unit details (including timers)
>                 + Click and click empty square to move, click on piece
>                   again, another piece, or territory to cancel
>           o Territory Icon
>                 + Click to create new unit
>                 + Hover to see territory details including unit
>                   production progress
>           o Heads-up-display
>                 + Overall map, new unit notifications, statistics
>                 + Current resource production (rate)
>                 + Current maintenance resource usage (rate)
>                 + Current unit-production resource usage (rate)
>                 + Count of units in foreign-controlled territories (or
>                   maybe a cumulative allegiance change rate)
>                 + Individual unit display (hover to see statistics)
>                 + Potentially a "noisy" mode that tells you all changes
>                   that all players are making
>           o Store/restore UI
>           o History viewer?
>           o Observer view?
>     * Simulation code as a separate engine (i.e. not directly connected
>       to the display code, so that we can replace the display should we
>       need to)
>           o Speed control (new users wanting to play slow, to learn,
>             experienced to play fast, very experience to play slowly and
>             chess-like)
>     * Host will run the simulation (for now we won't worry about "cheats")
>           o Use whole-board-updates from the server to the clients
>             (reduce synchronization problems)
>           o Allow anyone to save off the board at any time (and
>             potentially resume it later with different players, share it
>             with others, etceteras)
>           o Controls are mostly of the nature of "move my unit there" or
>             "produce new unit"
>                 + State conflicts will be reported back as flashes or
>                   the like highlighting a blocked move
>                 + Updates should be first-come-first served
>                 + We may want to introduce an arbitrary delay into the
>                   host child's updates (to prevent them having an edge)
>     * Keep the various simulation parameters as controllable parameters
>       so that we can tweak game-play through development, a few of these
>       might be exposed to the player
>           o Board size (e.g. start with 30x30)
>           o Territory size (e.g. start with 3x3)
>           o All periods/rates
>                 + Resource-collection rate per productive unit
>                 + Production rate per unit/distance
>                 + Period before auto-placement
>                 + Cost per unit
>                 + etc.
>
> No way we'd finish all of that in a weekend, though... still, it would
> be interesting to see how far we got.  I'm sure a smaller game would be
> far more practical.  Or we could just cut it down a lot and consider
> basic playability the goal, with the various extra rules as secondary.
>
> Anyway, this is *so* not what I was intending to work on today, must get
> back to it... oops, and now someones triggered the fire alarm.  Bah.
>
> Enjoy,
> Mike
>
> > Mike C. Fletcher wrote:
> >
> >> Hi Everyone,
> >>
> >> It's been very quiet on the list (mostly my fault).  Let's kick-start
> >> some discussion with a straw-man proposal...
> >>
> >> I'd love to have a Game Jam some weekend, come together Friday night,
> >> Saturday and Sunday to produce a working game for the laptop.  We can
> >> likely find sponsors willing to provide us with work-space, maybe even
> >> some food here and there.  We'd try to make the code usable as sample
> >> code, so using e.g. Telepathy for networking, PyGame for graphics and
> >> the like, but the focus would be on making a game that children will
> >> actually enjoy playing and which might teach something of value.
> >>
> >> I'm thinking mid-November, maybe the weekend of the 16th, though that's
> >> just a date pulled out of the air.
> >>
> >> Anyway, consider the straw man open for kicking,
> >> Mike
> >>
> >>
> >>
> >
> > _______________________________________________
> > Toronto-dev mailing list
> > Toronto-dev at lists.laptop.org
> > http://lists.laptop.org/listinfo/toronto-dev
> >
>
>
> --
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>
> _______________________________________________
> Games mailing list
> Games at lists.laptop.org
> http://lists.laptop.org/listinfo/games
>


More information about the Games mailing list