Database vraagje, kan dit simpeler?

[ZpAz]

Ik probeer een webbased game te maken:

Nu heb ik het volgende.

Ik wil dat je bijvoorbeeld gebouwen kunt maken (bijvoorbeeld barrakken).

Nu wil ik dat het 'tijd' kost om de barrakken te bouwen. Hoe moet ik dat opslaan in de 'database'?

Moet ik dan voor elk 'product' wat ik kan maken 3 kollommen hebben in mijn database? Namelijk:

barrakken (het totaal aantal barakken wat je al hebt)
barrakkenpu (het aantal barakken wat er per uur bij komt)
barakkenu (het aantal uren wat het nog duurt voordat alle barakken klaar zijn)

Want als je dat voor elk product moet doen wordt de database volgens mij behoorlijk onoverzichtelijk.

Of is er een beter manier?

[ Voor 4% gewijzigd door ZpAz op 27-03-2006 13:27 ]

[whoami]

Het aantal barakken dat je al hebt, kan je gaan tellen mocht dit niet te lang duren (select count)
En ik denk dat dit voor de andere 2 ook op gaat.

Verder is je Topicstart te 'warrig' om eigenlijk goed commentaar op te kunnen geven. We missen de context zo'n beetje, zeg maar.

[Pannenkoekkie]

Als je dit zelf bedacht hebt als stabiel back-end voor een online game, dan zou ik meteen de SQL Statement "DELETE * FROM *;" uit gaan voeren. Dat word dus helemaal nix

Je kan beter de barakken afzonderlijk in 1 tabel zetten.

Baraknummer(nummer)
Barakeigenaar(nummer)----(Tabel Eigenaars)
Barakstatus(nummer)---(tabel status "Klaar" - "Constructie")
Barakstatustijd(tijd)---(x minuten voor huidige status verloopt)

Verder kan je hier alle rekensommetjes mee beantwoorden die je wilt

[zwippie]

Aangezien de meeste webgames met 'ticks' werken (van meestal een half uur) zou ik eerder gaan voor het bijhouden van het aantal barakken wat iemand heeft, en dan voor elke barak(ken) die worden bijgebouwd/gekocht het aantal en de eindtik bijhouden. De eindtik is het tijdstip waarop het klaar moet zijn.

[Varienaja]

Misschien is het goed als je eerst uitlegd waarom je een levend object, zoals een Barak wil opslaan in een database.

Ik zie jouw Barak voor me als een of ander object, met daarin een tellertje dat per seconde 1 aftelt, totaan 0. Wanneer dat tellertje 0 is, is de Barak klaar.

Met 100.000 van zulke Barakken in je RAM-geheugen kan je een prima spel bouwen. Met 100.000 Barak-records in een database die elke seconde bijgewerkt moeten worden op disk wordt je spel al snel onbruikbaar.

Wanneer je het spel afsluit, of een savegame maakt zou ik pas de Barakken in een database stoppen. (een los bestandje vind ik ook goed).

[NBK]

* NBK stemt op de zwippie-methode. maar dan wel in combi met Pannenkoekkie's commentaar.

[ Voor 46% gewijzigd door NBK op 27-03-2006 13:44 ]

[ZpAz]

Varienaja schreef op maandag 27 maart 2006 @ 13:37:
Misschien is het goed als je eerst uitlegd waarom je een levend object, zoals een Barak wil opslaan in een database.

Ik zie jouw Barak voor me als een of ander object, met daarin een tellertje dat per seconde 1 aftelt, totaan 0. Wanneer dat tellertje 0 is, is de Barak klaar.

Met 100.000 van zulke Barakken in je RAM-geheugen kan je een prima spel bouwen. Met 100.000 Barak-records in een database die elke seconde bijgewerkt moeten worden op disk wordt je spel al snel onbruikbaar.

Het spel wordt gewoon web 'textbased',

Volgens mij is dat niet helemaal doorgedrongen
Wat bedoel je met levend object? Het is gewoon wat text wat af en toe van 'cijfer' veranderd:)

Varienaja schreef op maandag 27 maart 2006 @ 13:37:
Wanneer je het spel afsluit, of een savegame maakt zou ik pas de Barakken in een database stoppen. (een los bestandje vind ik ook goed).

Maar dan is het niet meer 'live' als je het pas in de database douwt wanneer je 'uitlogt'. Want dan kunnen pas de andere mensen het zien:)

Pannenkoekkie schreef op maandag 27 maart 2006 @ 13:32:
Als je dit zelf bedacht hebt als stabiel back-end voor een online game, dan zou ik meteen de SQL Statement "DELETE * FROM *;" uit gaan voeren. Dat word dus helemaal nix

Je kan beter de barakken afzonderlijk in 1 tabel zetten.

Baraknummer(nummer)
Barakeigenaar(nummer)----(Tabel Eigenaars)
Barakstatus(nummer)---(tabel status "Klaar" - "Constructie")
Barakstatustijd(tijd)---(x minuten voor huidige status verloopt)

Verder kan je hier alle rekensommetjes mee beantwoorden die je wilt

Denk dat ik hier wel wat mee kan
Bedankt:)

[ Voor 24% gewijzigd door ZpAz op 27-03-2006 14:02 ]

[Varienaja]

ZpAz schreef op maandag 27 maart 2006 @ 14:01:
Het spel wordt gewoon web 'textbased',

Volgens mij is dat niet helemaal doorgedrongen

Oh zeker wel. Juist daarom geef ik een voorbeeld met 100.000 records in een database die continue moeten worden ge-update, wat mijns inziens problemen gaat opleveren.

Wat bedoel je met levend object? Het is gewoon wat text wat af en toe van 'cijfer' veranderd:)

Ik neem aan dat je object georienteerd programmeren kent. Ik beschouw jouw Barak als een object. Een belangrijke eigenschap van zo'n barak is hoe ver deze Barak gereed is. (Of hoe lang het nog duurt totdat die Barak klaar is, dat is me om het even). Deze eigenschap verandert voortdurend. En daarom vind ik een Barak een levend object.

Levende objecten horen in het RAM-geheugen. Daar kan je ze namelijk snel benaderen. Vergelijk het met een word-document. Die sla je ook niet op na iedere toetsaanslag; dat kost gewoon veel te veel performance.

Maar dan is het niet meer 'live' als je het pas in de database douwt wanneer je 'uitlogt'. Want dan kunnen pas de andere mensen het zien:)

Ik zie niet in waarom objecten eerst in een database moet staan voordat jouw spel ze in andere sessies kan gebruiken. Sterker nog: ik weet zeker dat 't geen probleem moet zijn om objecten in meerdere sessies benaderbaar te hebben. Ik programmeer dat iedere dag.

Je kunt natuurlijk omwegen maken. Niet OO-programmeren; geen objecten als records in je database stoppen, maar gewoon wat losse getallen. En met wat gereken kan je dan iedere keer opnieuw best uitrekenen hoe lang je Barak nog moet voordat ie klaar is.

Hoe je het ook doet: succes ermee! Als je spel klaar is moest je de link maar hier zetten; dan kunnen wij ook van je resultaat genieten.

[ZpAz]

Varienaja schreef op maandag 27 maart 2006 @ 23:02:

Ik zie niet in waarom objecten eerst in een database moet staan voordat jouw spel ze in andere sessies kan gebruiken. Sterker nog: ik weet zeker dat 't geen probleem moet zijn om objecten in meerdere sessies benaderbaar te hebben. Ik programmeer dat iedere dag.

Je kunt natuurlijk omwegen maken. Niet OO-programmeren; geen objecten als records in je database stoppen, maar gewoon wat losse getallen. En met wat gereken kan je dan iedere keer opnieuw best uitrekenen hoe lang je Barak nog moet voordat ie klaar is.

Hoe je het ook doet: succes ermee! Als je spel klaar is moest je de link maar hier zetten; dan kunnen wij ook van je resultaat genieten.

Ja ik wou gewoon wat getallen in de database stoppen en dan als de pagina wordt opgevraagd berekenen hoeveel barakken er nog worden gemaakt enzo

Als het resultaat af is zal ik het hier wel posten, maar dit kan denk ik nog wel een tijdje duren

[rsmits]

Pannenkoekkie schreef op maandag 27 maart 2006 @ 13:32:
Je kan beter de barakken afzonderlijk in 1 tabel zetten.

Baraknummer(nummer)
Barakeigenaar(nummer)----(Tabel Eigenaars)
Barakstatus(nummer)---(tabel status "Klaar" - "Constructie")
Barakstatustijd(tijd)---(x minuten voor huidige status verloopt)

Verder kan je hier alle rekensommetjes mee beantwoorden die je wilt

Waarom ieder barak als individueel zien? Ik zou er vanuit gaan dat een barak dezelfde eigenschappen heeft nadat deze de status "klaar" heeft.

Daarom zou ik baraknummer weglaten en een aantal toevoegen (de combinatie van eigenaar, status en tijd is uniek, aantal kan je summen)

PS. tenzij je natuurlijk soldiers ofzo aan een barak wilt koppelen

[ZpAz]

Ik doe niet elke barrak apart:) Maar ik wil er wel soldaten 'in' kunnen stoppen, maar dit doe ik gewoon door max soldaten = barrakken * capiciteit

Dus dat als je te weinig barakken hebt dat er dan geen soldaatje meer kan worden gemaakt:)

[Verwijderd]

Incubus666 schreef op dinsdag 28 maart 2006 @ 10:04:
[...]


Waarom ieder barak als individueel zien? Ik zou er vanuit gaan dat een barak dezelfde eigenschappen heeft nadat deze de status "klaar" heeft.

Daarom zou ik baraknummer weglaten en een aantal toevoegen (de combinatie van eigenaar, status en tijd is uniek, aantal kan je summen)

PS. tenzij je natuurlijk soldiers ofzo aan een barak wilt koppelen

wat als je om 12.01 je eerste barak begint te bouwen en 12.10 je tweede.. hoe kun je met jouw methode dan opslaan welke wanneer klaar is?

edit:
je kunt natuurlijk wel een 'bouw-tabel' maken, met de eigenschappen als nr, eigenaar, tijd over en vervolgens wanneer ze klaar zijn pas toevoegen aan het aantal barraken van de speler

[ Voor 15% gewijzigd door Verwijderd op 29-03-2006 16:25 ]

[rsmits]

Ik ben ervan uitgegaan dat je net als de meeste webbased RPG's je turnbased werkt. Dit maakt overigens niet heel veel uit, maar anders is het een bepaald script dat je iedere minuut moet laten werken.

Zoals ik zei: de combinatie van eigenaar, status en tijd is uniek, aantal kan je summen. Doordat de tijd anders is, is het een nieuwe regel in de database (omdat het een nieuwe unieke combinatie is).

Om de zoveel tijd kan je checken of er een X aantal minuten (of een X aantal turns) voorbij zijn en de status in die regel geupdate wordt naar klaar.

Ik loop bij dit idee zelf ook tegen een punt aan; mijn idee was met deze methode om regels te besparen in de database, maar er blijven te veel regels doordat ik de tijd ook uniek laat zijn in de combinatie.

Met jouw idee in je edit (een aparte bouw tabel) kan je dit probleem oplossen. Nadat een gebouw status "klaar" gekregen heeft, het aantal barakken verhogen met "aantal". Zo bespaar je in ieder geval een sum querry (en server load). En de aparte bouw tabel kan je evt gebruiken als history voor de speler