# garme engines as free to develop garmes to reconsider garme engines and ir interfaces as ftd ("free to develop") garmes **+** "better not bigger - smarter; to not rely on brute force" **+** note the software tools used to make garme are often far more interesting than any one garme **+** emergent fully procedural artificially alive systems - not engines spewing out dead (static) output at one end **+** more about observing than control - allowing events to happen; playing with fuzzy parameters **+** imagine removing the artificial almost entirely arbitrary line between 'developing' and 'playing' **+** "if i throw a ball at you i don't expect you to drop it and wait until it starts telling stories" **+** fully collapse the interface into teh garme - "like garry's mod only more so" **+** smash all windows - consider little 2d rectangular boxes with slider bars as bizarrely obsolete **+** node based yes - but nodes considered as ants; everything's already on the move **+** less about 'herding cats' or 'knowing the rules' but observing one's own influence in the magnetic field **+** the correct "like lego" analogy; 'tools as play' right now - immediacy; not merely creating complex (computationally and artistically expensive) artificial places before anything _oddly interesting_ begins **+** everything on screen as simultaneously a tool an object and a toy for play and (exploring) garming **+** everything has its own set of modifable rules **+** everything as dynamic inter-dependent (intelligent) systems - "machine tools with personalities" **+** feedback looping: a garme engine system producing its own output dependent on its own inputs **+** garming / play as something that happens in the interactions between tools objects and toys **+** such a garme space could evolve the notion of a 'visual language' of play **+** such a garme-system would more easily allow johnathan blow's dynamical meaning / ian bogost's proceduralist rhetoric **+** (thinking) social spaces rather than dead maps **+** garmes as evolving services able to accommodate multiple (/simultaneous) modes of play **+** "players as the true engine of garme development" "which engine should develop my garme on?": often the entirely wrong question valve: you can't compete with your player base so get out of the way if unity engine / unreal engine was entirely 'free to develop' that might be a good thing reconsider the relationship between a garme engine and its developers like the relationship between minecraft and its user generated content free teh garme development engines and freely (socially) advertise successful developers who feed a proportion of ir profits back into teh garme engine itself: everybody wins? // republic of bob