Spil - gemme data

det vil nok være det mest oplagte at bruge en database, hvis du har mulighed for det .... det kan jo være vældig meget data du kan få brug for at gemme der - altså hvis du skal gemme historik over tidligere spil, scorelister og blabla.

så længe du kan lave en relationel model over det du skal gemme - er det nok det nemmeste for dig.

jeg ved ikke lige hvad jeg skal give dig et eksempel på - det er sådan lidt omfattende det du har spurgt om, men eksempler på at hive data ind og ud af databaser, kan du naturligvis godt få.
er du mere interesseret i at finde ud af hvordan man arbejder med serialisering (omænd jeg ikke tror at det er en løsning for dig i denne situation) - så kan du skam også få det.

kan du gemme det i databaser - kan du også gemme det som xml.

mvh

selve den interactive del skal vel gemmes i en memory struktur
enten med rod i Application eller egen singleton

historiske data skal naturligvis persisteres og database lyder umiddelbart
bedst

da alle sessions bruger samme memory struktur er kommunikation ikke et problem

hvis spillerne skal skiftes til at goere noget er det ogsaa relativt nemt at styre

hvis du ikke skal tabe noget ved nedbrud skal du enten koere flere maskiner
hvor memory strukturen replikeres eller du skal ogsaa loebende persistere den
i databasen - det sidste kan godt koste en del i performance

Det med at gemme historiske data i en database lyder fornuftigt og var også det jeg havde tænkt mig.
Det jeg virkelig er interesseret i eksempler på er, som arne_v nævner, til den interaktive del.
Hvordan kan hver spille få fat i alle data undervejs hvis det gemmes i session hørende til den enkelte spiller?
Der findes jo fælles objekter og ikke fælles objekter. F.eks. er bordet og bunken jo fælles objekter, mens spiller og hånd(måske kun til dels) er personlige...

der er forskellige steder du kan gemme tilstand, som arne nævner kan du have root i
Application eller en singleton, som han har lagt en artikel omkring her:
http://www.eksperten.dk/artikler/37

for at lægge noget i application kan du bare:

Application["someTime"] = DateTime.Now;

og du kan så hente igen med
DateTime time = (DateTime)Application["someTime"];

Du har desuden en Cache - som også er fælles for alle, og som giver muligheder for expiration mv.

Og session har du så også - som du selv nævner - og benytter du version 2.0 har du profiles, der giver fine muligheder for at håndtere brugerspecifikke oplysninger.

mvh

jeg ville have en single tree structure saaledes at de faelles oplysninger har
referencer til alle de individuelle oplysninger

husk paa at fordi koden der koerer paa server side har adgang til nogle data saa
betyder det ikke at brugeren ude med browseren har adagng til det

Det lyder jo alt sammen vældigt fornuftigt... Jeg tror jeg forsøger mig med Application. Singleton giver vel kun mulighed for ét objekt pr. klasse, ik?

ja

men du skal vel ogsaa kun have 1 spille site ?

1 spille site -> N spil -> N * M spillere

Det er selvfølgelig rigtigt...
Hvad er fordelen ved singleton frem for application?

du undgaar at blande dit spil med oevrige web app ting

du kan lave din app i layers hvor BLL layeret ikke er afhaengig af web kontekst
fordi det bruger en generel singleton og ikke det web specifikke Application objekt

om det er vigtigt for dig - tja ...

Damn...der fik du sat mig af :-D
Well, jeg prøver at læse lidt om singleton.
I skal have tak for hjælpen....
Bare smit et svar begge to...

det har naeppe den store funktionelle betydning om du bruger Application eller
egen singleton

men det fleste erfarne programmoerer vil have en eller anden opfattelse
af hvad er mest rigtigt - men ikke noedvendigvis samme opfattelse

og et svar

Så må vi hellere lukke... endnu engang tak for hjælpen.

beklager .... jeg er lidt tung i det en gang imellem :o)
mvh

:-) Sådan kan det jo gå...

http://www.eksperten.dk/spm/697390