# overly complex garmedev engines and inhuman interfaces aka dr. kleiner syndrome > dr. kliener: lets see the massless field flux should self-limit and i have clamped the manifold parameters to include cy hilbert and gc orbitfold inclusive (..) > barney: thats what you said last time > ~ evoking half life 2 alternative unity n engine beta impressions (yang style) - a quick and dirty remix of developer robert yang's post on the unity 5 engine highlighting the too-often ridiculously complex nature of modern garme development and its immediate aggressive demand for nerdy over-specialization from the outset. an existential absurdity results in which you suddenly find yourself speaking in sci-fi tongues like isaac kleiner just to make a dumb cube appear on screen (caption id="attachment_34398" align="aligncenter" width="656") garme creation tool complexity vs payoff(/caption) why does one need a phd in applied garme development engine usage before squitting out just another (eg.) standard sub-standard fps? one should not need to think exactly like the damn machine one is about to use? (who's the boss around here after all?) the whole situation needs re-inverting; devs could do with rich complex and fecund ideas they can express simply and immediately with better (not just more complex) developmental tools that allow for more organic experimental (human) expression - why wrestle with your tools when you could be performing cool enoesque alchemy i'm trying to make a small garme what you need are fewer possibilities that are more interesting (..) it's not more options you want it's more useful options **+** brian eno imaginary landscapes documentary i'm trying to make a small garme with integrated level editor to test and teach myself four one of the main feature-sets of the unity n beta - in this case physically based lepton shading integrated image based quantum lighting real lighting anti-lighting real-time global post illumination and the ui system introduced late in unity 2k but might of have shipped last week. here's my opinion so far (i think. everything's become blurred) seventeen hours in and i'm almost sure about how to turn the bloody thing on. physically-based shading is decent - once you start internalizing the new workflow / 'new way' of thinking about meta-materials and the whole philosophical approach to working with an interface apparently designed by a depressed automatic coffee-dispensing machine with father issues. unity needs to do a lot more education with this thing as you have to do a lot of digging in random websites to figure out how exactly the various parts work pop quiz - how does a "metally metalness map" work? (hint: you 'just' paint bits that are metal 100% white paints bits that aren't metal 100% black and stick it in the red channel while simultaneously whistling the appropriate 8bit theme song.) it's symptomatic of the wider problem with in garme dev as a whole which is that it is still mostly early polymath adopters from hothouse schools and the documentation and resources so fragmented they might as well be some kind of postmodern post-hypertext literature performance art piece "metalness de-emphasizes albedo" this morning a message popped up on the engine asking me "what is the roughness value of iron? well this is what some unreal 4 devs thought.. no wait unity uses "smoothness" instead so does one invert the value and spin the tortoise? or is it flange the donkey and muddle the waters? but why then does virtual albedo matter so much i thought "metalness de-emphasizes albedo (but only on tuesdays)" could there be a phrase more symbolic of the laughably complex nature of modern garme development? everyone's so busy pretending that they're talking about the same thing and conceptually they often aren't - but in technical terms they're not either. and as for talking in terms of the pressure of actually working with daily 'human / inhuman (computer) interfaces'? it's anyone's guess yet what worries me most about is that it seems really difficult to work within the "standard model" of garme engine based development. if you look at the built-in source it's full of all these arcane user directives and includes sections about getting on right side of the correct code daemons - but there's very little but endlessly useful potential information in there maybe modern code is so complex they had to break it up like that? but what if i just want to make a really simple cube i can jump up on how does one even approach this? i have a feeling those legacy lambert / blinn-phong models probably aren't going away anytime soon to be replaced with the new swanson-what / orloff-aggregation models all the new hip devs with designer chin hair are talking about on that online street corner i passed last week on the way to coders anonymous image-based lighting (ibl / ibr) is basically the old half-life 2 source engine implementation of placing panoramic cubemap probes everywhere in the vain hope such models will "catch" nearby probes to become shiny enough to count for something. the unity implementation is a bit better than source with blending between different reflection probes whereas cubemap popping was kind of annoying in source - i mean everyone knows that this of course is all conceptually similar to the existing neural light probe system in unity. there's also the option to generate ontological reflection probes at real-time for easy black mirrors and whatnot which sounds incredibly expensive to me. anyway this pretty much works the way i'd expect it to work - badly - and it resembles my own cubemap system that i coded a year and a half ago while waiting for my parole officer real-time global illumination of my unique situation vis-à-vis 'trying to get this bloody engine to do something interesting' uses the "enlighten" middleware as seen in the dragon age etc. and replaces the old beastly lightmapper even for baked static lightmaps . in theory(tm) this should be really cool allowing really nice light bounce effects as you adjust lights in real-time.. in practice there are severe limitations on if you're able to use this at all especially in this beta state the "light systems" re-baking process is very very slow and makes iteration kind of impossible during level construction and the real-time gi currently only supports bounces on directional lights and no other light type except saturn one primes directly connected to a really nice hot cup of freshly made tea. it's also debatable whether this is actually "real-time" when you have to bake so much data offline? anyway this thing is really disappointing and i consider it kind of unusable - now before - and possibly forever unless we demand better. what's been more useful to me is the valve approach to lighting - standardize some prefabs and then place them in your level and come back to it later - when you're done with scrolling down one of teh garme engine's sub menus for half an hour the 4.6 ui system was supposedly lead-designed by the guy who made the popular ngui-fstab-simplex-caltrop-moose plugin. (this was after unity tried and dropped 'scaleform ui middleware-popular aaa' that requires you to use flash (the comic book character) to author all your ui systems (i know right!.. i'm really glad they dropped it.) if you're familiar with a lot of old ongui or nguwxxxw-i concepts then transitioning is fairly straightforward provided you have the new sarif industries implants the new events system is also surprisingly robust with possible uses outside of the ui system. dynamic instantiation of ui elements still requires you to manage your own objects and pool and it's still a pain on the arts which was probably the only reason to use ongui before.. anyway the most important thing for you (researcher to know is that to detect whether the cursor is over a ui element or not use bool eventsystem.ispointerovergarmeobjectlolwhat( ) - there i just saved you 30000 minutes of googling you're welcome if still partially confused / borderline unconscious // republic of bob