# garme engines as services and player based design in which there's a shift in focus from developer-based video garme design to players themselves a simple extension of the same way players on a server vote for the next map to play player based garme design (pbgd) means thinking in terms of emergent open design 'scenes' 'scenarios' or 'potentials' for play - rather than just (obsolete) 'maps' or strict garme types that is expand the definition of 'garmes as services' to "garme engines as services"; hyper-modular extremely modifiable realtime intelligent and reactive garme spaces that are 'playable on demand' consider "garme design as a garme" and 'garme engines' as exactly that - engines for and of garming generally not merely for 'a particular garme' consider the phrase "get hyper" ('hypa!') as player slang for the process of "creative (social) garming" - the idea of 'messing around together' online with/in virtual worlds aka "shenaniganning" // video here notice the casual vibrant joy manic glee and vital immediacy at (serious) play here - something instantly familiar to any modern postmodern player (mpp) note the most interesting thing in this garme space are the moving players themselves; player based design implies everything in / as the world also 'moves' thinks and reacts we're still stuck however in what 'synthesist' brian eno calls "screwdriver mode": the desperately slow pixel-perfect tweaking of maps and other features that 'discourages bold strokes' and only encourages fiddling around with minor nerdy details details are important - but maybe they should take place during play - as another 'dynamic garme space element' consider garme design as fast as traditional map design (only) seen in time compressed videos // youtube video here in reality such maps usually take several hours if not days to make - but then this isn't real garme design needs to be as fast as typing (playing) the following garme space generating code (setup): castle / old / foggy / cycle day-night 7mins / prop + wall respawn 1min the new idea behind garme engines: for player's immediate needs for 'self expression through dynamic play' "play" is always artistic and creative; player based design positively increases the emphasis on player style people are infinitely more fun than garmes: players of video garmes are already 'hyper' smart and intensely creative and so should be able to more organically 'play art' that is the development of a "visual (garming) language" - garming grammars expressed from moment to moment - player based design as "how i play (/design) is what you see" indeed garme engines are now being seen as garmes themselves to reiterate: consider "brian eno" an important answer to every interesting still as yet unasked question about video garmes // republic of bob