This book is a work in progress, comments are welcome to: johno(at)johno(dot)se

johno säger: värst vad du är online nuförtiden. läget?

Erik säger: alltid uppkopplad är melodin! nä men jag stänger ju aldrig av min dator på jobbet så MSN får rulla. och så har jag bara dig och Hobbe typ på min lista så inga "hej periken.." läget är bra! kodar lite cutscene stuff, is nice. själv då, allt bra?

johno säger: jodå, är i Arvika igen

Erik säger: För sista gången nu eller? Du är ju jämt där!

johno säger: well, multiplayerkursen är slut nu, men jag blev kontrakterad att hålla några föreläsningar om smidiga små tekniker för att vara mer produktiv inom agileprojekt

Erik säger: Har du lärt dem allt du kan? Finns det några labbar i den kursen? Vore kul att kika på nåt sånt..

johno säger: och sen blir det lite "simulate a DICE interview", samt lite bara sitta på plats och vara handledare

Erik säger: sweet! vem vet, snart kanske du jobbar som lärare på heltid. Simulate a DICE interview?!! you're shitting me

johno säger: de fick några Winsockuppgifter, typ en chat server/klient, samt att göra ett multiplayer spel. nej, kursansvarig hade varit i kontakt med någon på DICE, DICEInvaders kom upp på tapeten

Erik säger: haha, fan vad kul! så de ska alla koda Dice Invaders? underbart ju... jag vill nästan göra om mitt Dice Invaders för det var inget vidare den gången

johno säger: så jag gav dom en uppgift som är motsv i storlek, där de fick gfx och ett litet DDraw lib, och så skall de koda spelet, sen blir det intervju och Gru-style "why did you do it this way" gestapo-invervju. denna gången blir det PacMan, med min coder art

Erik säger: I love it! Känns som den där utbildningen är ganska målinriktad på att få jobb... inte en massa flum. Coder art rulez!

johno säger: jo absolut, KY är verkligen så till skillnad från Universitet så det passar mig

Erik säger: Just det ja, KY var det ja. Men ska du grilla dem på "intervjun"? Någon mer? Dice kör ju alltid två personer som grillar och sen en snäll person från HR som bjuder på saft

johno säger: hehe well ungefär, det är i grunden en arkitekturuppgift, jag har märkt att det är den biten som det är minst täckning för i de olika kurserna. jag har såklart kört mycket MVC med dom, och det behövs att någon ifrågasätter deras tendenser. en stor grej har varit IM vs RM

Erik säger: yes box, alltid bra att förklara sig. IM vs RM? Immediate mode versus R? mode?

johno säger: Retained

Erik säger: aha, så klart... vad betyder det...?

johno säger: dvs alla professionella "renderers"

Erik säger: ah.

johno säger: well såhär, på DICE har ni bergis nån slags "entity" som är en transform och en mesh och kanske lite shader info, inte sant? en sådan abstraktion för "något visuellt"?

Erik säger: nja, vi har ju entiteter och vissa av dem har en visuell representation med en mesh och shader-sets etc. men de flesta entiteter har även en massa logik, tror inte vi har speciellt många entiteter som är "bara" visuella

johno säger: ok i c

Erik säger: detta är iofs på grund av destruction. eftersom allt man ser ska gå att förstöra så räcker det inte med en mesh, man måste ha information om vilka delar av meshen som gått sönder

johno säger: men då frågar jag såhär, går det generellt till så att ni anropar motsv: void drawMeshHere(transform, mesh, texture); ? eller är det snarare: myVisualThing.draw(); ?

Erik säger: Aldrig myVisualThing.draw() nej. Det finns ett antal renderare som hämtar ut alla entiteter av den typ som den stöder och sen loopar igenom dem och hämtar ut transform, mesh från dem och dunkar in i renderingspipen. typ.

johno säger: ok då är jag med

Erik säger: så drawMeshHere() ja

johno säger: men i princip eftersom, som du beskriver, att det finns något objekt som håller ihop en relation mellan en transform och en mesh, då är det någorlunda retained. MSV hade så, det fanns nåt i renderaren som hette MR_Instance, som var en transform plus en mesh, och man kunde ju typ flytta runt och orientera den, osv;

Erik säger: men ger du dina stackars studenter exempel på flera sätt man kan göra saker eller kör du stenhårt på Johno's Way och ristar det i sten?

johno säger: vad gälle RM och IM så har diskussionerna varit mycket kring "hur spelbranschen brukar göra", och det är konsekvent RM, och det känner de till, Ogre funkar så osso

Erik säger: oki. Ogre?

johno säger: alla proffsrenderers jag har sett i sverige funkar så, Ogre = open source grej, ganska avancerad, många KY använder den. vad jag har försökt göra är att gå till grunden med varför det brukar se ut så, och sen prata om alternativa metoder

Erik säger: Vi har ju ingen direkt MR_Instance. Det som placeras ut i världen som ska renderas är StaticModelEntity. Den har förutom en mesh även kollision, kan animeras, har health states för att gå sönder och därmed byta mesh etc. Så själva renderingsbiten är bara en liten del.

johno säger: just det, förstår, så funkar i princip även Massives grejer nuförtiden

Erik säger: schysst att ge flera sidor av saker och ting! tror ett problem med att ta in folk från branschen annars är att de säger "så här är det".

johno säger: jepp, men detta är ganska kopplat till MVC, och det har varit mitt huvudsakliga intresse sen tiden på Massive. just trenden att StaticModelEntity har kollision, mesh, logik, all in a single blob, så funkade i princip EX_Player grejerna i GC2 osso. everyone is doing it

Erik säger: Men det är vad du förespråkar också? Eller inte? Jag måste nog läsa din bok för att förstå vad du menar. Skriv klart den nu!

johno säger: hehe, eftersom då frågar så vill jag vara tydlig: nej, jag tror inte på den vägen

Erik säger: aha.

johno säger: men för att vara rättvis mot studenterna har jag pratat mycket om bägge delar. vad jag i grunden inte gillar är att en VISS visualisering, i ert fall 3d ultra uber, är hårt bunden till er "entity", dvs state och logik

Erik säger: jag har nog ett alldeles för litet intresse för arkitektur. bryr mig sällan om "the right path", bara jobbet blir gjort och resultatet är vad man vill att det ska vara

johno säger: MVC, enligt käre Trygve Reenskaug, säger att visualisering skall vara skilt ifrån "modellen", dvs "domain model", dvs "state". state = position, orientation, osv i spel å en typiskt "entity" (gillar inte den termen). en stor poäng är att man skall kunna lätt ha multipla olika visualiseringar. klassiskt exempel är att Model = int a, b, c; sen har man flera views, ett stapeldiagram, en piechart, en spreadsheet, etc

Erik säger: skilt på vilket sätt? för att veta hur man ska visualisera något man måste man ju veta vad det är, alltså state. om man ska rita en människa måste man ju veta om den är fet/smal, ligger/står/sitter. state.

johno säger: ja det stämmer ju, men det intressanta i till exempel ett spel som BF är vilken del som är "del av visualisering" och vilken del är "pure state". ta till exempel en klassisk minimap, där är det mer prickar som går omkring. enligt MVC är 3d vyn och minimap vyn 2 exempel på visualiseringar, och isf hör allting som är "3d uber ultra stuff" till 3d "vyn", och allt 2d stuff till 2d "vyn". typ så, i grova terms

Erik säger: nja, prickarna är spelare. spelarna finns i EntityManagern (Model). de ritas ut i 3d i en världsvy och som prickar av hud:en. är det inte precis som du vill ha det?

johno säger: jo i princip, men frågan är om varje Entity (som du säger del av Model) har en ref till en 3d mesh?

Erik säger: yes box, det känns ju rätt praktiskt att spara den där "for easy access". men du vill helst inte att en "entitet" har något som bara rör visualisering?

johno säger: (nu glider vi mer in på Model-View-Controller än IM vs RM). om man skall vara PURE (hehe...) så inte, dvs Entity skall inte "veta om" hur den eventuellt visualiseras, dvs Model skall vara oberoende av View. det skall vara externt. detta har ganska vida implikationer

Erik säger: http://www.joelonsoftware.com/articles/fog0000000018.html

johno säger: hehe, roligt att du kopplar till det, men jag är snarare åt andra hållet, jag skulle påstå att DICE är mer Architecture Astronauts med era fina Entity heirarchies "all is an entity..."

Erik säger: förvisso sant, abstraktioner är en annan sak

johno säger: men min fixering vid MVC är att de flesta verkar missa vad som händer när man binder state till en viss, eller några stycken, visualiseringar hårt. och hårt blir det om en entity vet vilken mesh han har. compile and link deps...

Erik säger: men hela den här grejen att en entitet inte "får" hålla reda på en mesh för det inte är "pure" känns lite som att göra livet svårare än det behöver vara. solve the problem, ship the game.

johno säger: jo absolut, om man "vet" att man skall ha en 3d och en minimap view, osv. sure why not? u shipped it! men vad jag har märkt är att utvecklingen blir MYCKET enklare om man tänker på det här. less code, less broken caches, simpler program

Erik säger: om man inte vet vad man ska göra för spel så bör man ju inte börja koda innan man vet. iofs ändras ju saker under tiden eftersom allt är iterativt, så man ska ju vara redo för förändring, men ändå. hela Model/View-tänket känns bättre att applicera på typ spreadsheet-applikationer.

johno säger: ungefär det där är vad jag hade förväntat mig som reaktion. you must unlearn!

Erik säger: Nu säger jag iofs mest emot dig för diskussionens skull. =) Jag skulle gärna prova nya sätt för jag kan ju inte säga att koden här på Dice är smidig att jobba med.

johno säger: There u go, i owned u

Erik säger: *doh*

johno säger: dags för ett DF meet kanske. iom boken och kurserna jag hållt har jag ganska mycket kött på benen på det här. jag vill försöka träffa "the source" på detta område, dvs Trygve himself

Erik säger: men du hade haft en del kontakt med honom, eller?

johno säger: inte för att han kanske kan hjälpa till vad gäller spelbiten... jo mejlat lite om IMGUI. han fattade inte sa han

Erik säger: hehe, det är rätt lurigt att ta till sig sånt här om man inte sitter ner och snackar om det och/eller har konkreta exempel i kod. jag är lite i samma sits. är inte hundra på poängen.

johno säger: jo absolut, man är ju van vid den kod man jobbar med varje dag. btw, ni kör client server va?

Erik säger: jepp

johno säger: i BFBC? hur är det, har ni typ en client side entity heirarki, och en motsv server side entity heirarki? såsom det var när jag var med i BFMC grunden?

Erik säger: yes box, precis samma kod som när du var med oss. jag gillar verkligen inte den hierarkin, duplicerad kod och annan otäckt

johno säger: just just en sån sak hade vi på GC2 osso. men där var det worse, för att varje "spelartyp" hade en egen stateduplicering. en för EX_Player (3d klienten), en för AI, en för script; it was hell

Erik säger: kladdigt värre.

johno säger: but here is a point for u: med MVC så blir man av med det HELT. det finns EN variant av hela programmets tillstånd, dvs Model, även i client-server apps. still with me?

Erik säger: det vore ju spännande att designa om BFBC-kodbasen på papper och se alternativa lösningar.

johno säger: ja särskilt med tanke på att ni har en sån logisk parallellism. i MC var det ju till och med en data-parallell osso om jag minns rätt

Erik säger: usch ja, den är borta nu iofs.

johno säger: skönt det

Erik säger: måste springa, men vi får snacka vidare om det här sen! ska försöka få ut en klasshiearki på vår kod så kanske man kan ta ett specifikt exempel. lejtor!

johno säger: sure cu