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

Iverius säger: 1. är det ok att ha viss "state" i sin view (t ex currentInputControllerType, mouse/gamepad etc) eller är det mer "rätt" att ha det i controllers session-state och anropa view oGamePadINput() specifikt

johno säger: ja, jag tycker det känns ganska naturligt att ha state i View... man skulle såklart kunna ha en delad "session" grej som controllers delar på, men de delar ju redan på View objektet, så man kan ju lika gärna ha det där

Iverius säger: okej, så att view måste vara stateless är mer från controllers viewpoint, att den aldrig ska "polla" view för state och göra branching eller liknande på det? internt kan view vara ett monster av state och RM caching

johno säger: känns som jag behöver revidera lite att view skall vara stateless känns inte helt som det stämmer

Iverius säger: eftersom den är en av flera möjliga implementationer av en visualisering, mest

johno säger: till exempel, ibland har jag flaggor och options och grejer som är gemensamma för flera controllers, typ att nån grej är påslagen i view. vet inte om man skall se det som state, men det finns iaf toggles i view som man kan anropa. till exempel att rita debuglinjer eller nåt, frågan är om flaggan skall vara dold inuti view, och när en controller anropar DrawDebug() så ritas det ut beroende på intern flagga. alternativt om controllern skall polla flaggan och anropa DrawDebug() beroende på det. eller alt att varje controller har en egen flagga. det blir typ ganska app specific. ytterligare exempel på state: ponera att man har en gemensam camera abstraktion med state som delas, så den ligger i view, och som används av view för att rendera, men varje controller tar och pillar på den, flyttar den osv. det är nog svårt att bara krasst säga "view får inte ha state". vad jag snarare ville säga där var mer kring hur rendering skall funka, men jag behöver nog ett mer riktat exempel

Iverius säger: jag funderar på om man bara för överskådlighet vill dela upp view i flera klasser ibland

johno säger: ja säkerligen

Iverius säger: t ex HUD-overlay, 3d-view, editor-stuff etc. så kan man invoka varianter av dem, från controller...kanske onödigt, men mycket kod i en klass annars. skulle ju bara bli ett lager till egentligen. snarare egna controllers för de cases jag sade iofs. view blir mer ett toolkit för att rita saker

johno säger: ja sant, typ en för spelet, en för editor, osv. men View är helt klart en samling utils för att "komponera en vy"

Iverius säger: fast jag tror ändå man vill ha flera delar av view också, för alla specials som man vill uttrycka enkelt i controllern, t ex om man editerar vill man säga DoComplexClassEdit(complexgameclass* data), som internt gör massa jox. har man mycket sånt i view blir det en stor jävla .cpp.

johno säger: jag tänker snarare att man har en dedikerat controller till det

Iverius säger: även om det bara är visualiseringen (interactionen måste ju såklart vara controller)

johno säger: jag brukar promota saker till View först när de används från flera controllers. i syfte att undvika kodduplicering

Iverius säger: mm, kanske löser ut sig bra, har ju inte testat fullt ut än. view blir mer och mer retained

johno säger: jo det tror jag, alltså att View är din "game renderer". och därmed är det nog dumt att tänka att den skall vara stateless. vad jag är ute efter att förmedla främst är att det skall vara lätt att byta controller när som helst, och inget i view skall "släpa efter" eller vara konstigt cachat osv. inga "things that are visible"-list, som man måste manuellt rensa

Iverius säger: jupp. fråga #2. vi får gegg eftersom all vår tech inte är särskilt IM. dvs, models rep av t ex en Avatar innehåller en MRB (MainObject), som är NULL på servern, men laddad på clienten och ritas fint etc - det är förvirrande för de som är nya i koden

johno säger: ah just

Iverius säger: alternativen är att gömma caching i view, och bara ha myMRBName. men det är inte helt lysande. värre version är att gå hela vägen till dupliceringen. Client_Avatar-style. vilket vi inte vill. så vi har hitills valt att leva med förvirringen, vilket jag inte lider av

johno säger: låter som CryEngine2's lösning

Iverius säger: men samma data-förvirring visar sig vi ingame-editing - vilka delar är definition, vilka delar är start-state, vilka är runtime params som inte ska pillas på. särskilt som all data är exponerad samtidigt. man får uttrycka den i sektioner i sin data redan, för att reda ut det. men inte helt enkelt alltid

johno säger: men jag tänker, i Model, att varje enhet har rent state såklart, och i det nån slags "my type" som View kan switcha på och visualisera med rätt modell osv? alltså rätt mesh?

Iverius säger: och mycket tankekraft behövs - hade varit skönt att inte behöva tänka så jävla mycket

Iverius säger: mjo, men vi kan ju inte( utan massa meck iaf) göra våra 3d-stuff immediate

johno säger: ah ok, det brukar ju vara det som är problemet

Iverius säger: vi gjorde så förut, men vi behöver delar av saker på servern också, för att animera lowpoly-versioner av avatarer t ex, för hit-detection, så vi kan inte helt ignorera Mr.Render

johno säger: ok men skall man inte bryta ut anim och mesh ur själva renderingen då?

Iverius säger: vi har det nästan, men det behövs ju en mesh för att träffa mot ändå. vi fick våra lånade techies att bygga ett skeletal animsystem

johno säger: jovisst, men därmed är väl meshen del av model?

Iverius säger: sen overridar vi hela mrb:n rakt av med skelettet och gör lite funky shit för att den geggiga render-koden inte ska dö-.- på client. men just lokaliteten på datan. avatar har myHitModel som är lowpoly version och myMRB som bara är !=NULL på client side för visuals. frågan är om det är lönt att bryta ut just mrb:er som ett special case från model, och låta view sköta det, som du säger

johno säger: men om jag förstår dig rätt är det geggigt pga att Model sidan ser en massa shite som den inte vill ha, som är NULL?

Iverius säger: mm, lite så, men datan har ingen annan "plats". och vår design av objekt i världen blev väldigt "class-ig", med entity som ärvs och har components etc, så datan är typiskt lokaliserad till delarna, men jag tror egentligen att det främst är 3d-modellerna som blir förvirrande för vissa. det mesta andra har ett syfte på båda sidor nätet. så man borde kanske testa, som vi gjorde i höstas, att låtsas som om våra 3d-models kunde kallas på immediate-style, DoModel(mrbname, state, currenttime") typ

johno säger: just. men bara för att jag skall förstå, era units i Model har en pekare till en "view animation mesh thingy", som är NULL, och sen på "klientsidan" har ni samma sak, men där är den inte NULL? eller är det samma objekt i local case? dvs inte en kopia på client en på server?

Iverius säger: jo kopia - server/client i varsin tråd så

johno säger: ok, även i local case/singleplayer?

Iverius säger: jess

johno säger: ok anledning?

Iverius säger: att vi började med en MP prototyp, sen hade vi 10 veckor att göra en kickass SP demo, och då var allt redan trådat

johno säger: ok så designen är inte som ni vill ha den mao?

Iverius säger: vi snackade om att göra ett direct case, men vi kör ju vissa delar lokalt simulerade (projektiler, egna player movement), så vi passade på det tills vidare. enda orsaken att göra local case skulle vara för att slippa ökade minneskostnaden för konsoll iom vi duplicerar en massa. det är såklart jobbigt med network crap, men vi hade massa problem på WIC pga det blev 2 cases, asynkront och inte

johno säger: lite svårt att hänga med på hur er ark ser ut. men det känns rätt bad att man har 2 instanser av varje unit, och måste kopiera state däremellan alltid

Iverius säger: det blir som om du hade en server remote hela tiden bara

johno säger: just det. men det "syns" väl i koden? att man gör det?

Iverius säger: hur menar du? synken däremellan?

johno säger: ja precis

Iverius säger: lite grann, vi har en klass som heter ClientLogic /ServerLogic, som ansvarar för att synka den egna modellen innan den kör sin vanliga update. clientlogic interpolerar nätdatan in i local model, typ. vi kör ju med q3-inspired world-state syncs. så den spolar in inkommande worldstate i local model, interpolerar mot stored value för avatar-positions , och sen kör "normal" updates. man få komma ihåg vilka special cases vi kör, så lite geggigt ofc. man kan nog lösa det snyggare med riktiga ärvda klasser som overridar bara det som behövs. vi kommer förhoppningsvis gå in i nån slags preproduction efter sommaren, så jag kommer få titta mer på allt det här, men troligtvis under tidspress. men jag kommer definitivt köra mer på controller-tänket

johno säger: gut. men ang boken, känns som det blir rätt väsentligt att prata med om IM rendering. för det verkar vara det som strular till saker mest

Iverius säger: absolut. kräver också att man planerar sin "tech" efter det lite efter hand

Need to talk about application loops, i.e. input/update/draw vs update/draw/input. The differences have implications concerning IMGUI, and it is probably a good idea to discuess the various tradeoffs. Acknowledges that this is quite individualistic conceptually (i.e. what goes first, also taking the wraparound of the loop into account). Also talk about why someone (like me) would consider differentiating between IMGUI calls (seeing them as input stuff) as opposed to 3d model rendering (seeing that as draw stuff), but how one could essentially do all input/drawing that way (i.e. view.doModel(xform, assets, state)) and always have a transparency concerning any "scenegraphy" stuff (like current IMGUI style) in the background. Important to stress that any scene graph only caches state for the current frame, i.e. could potentially be stack based.