Schrift
[thread]3358[/thread]

Datenbankdesign: für Onlinegame



<< >> 6 Einträge, 1 Seite
pktm
 2003-10-13 16:17
#35543 #35543
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
Hallo!
Wer verwandtes durchlesen will hier: http://www.perlunity.de/cgi-bin....=2&pn=0

Also ich bin dabei, ein Onlinespiel zu entwickeln.
Dabei habe ich mir folgendes Datenbankdesign ausgedacht:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Table structure for table 'karte'
#

CREATE TABLE karte (
sektor int(255) DEFAULT '0' NOT NULL,
typ tinyint(1) DEFAULT '1' NOT NULL,
platz tinyint(2) DEFAULT '20' NOT NULL,
besitzer varchar(255) DEFAULT '0' NOT NULL,
rohstoff varchar(255) DEFAULT '0' NOT NULL,
menge int(255) DEFAULT '0' NOT NULL,
buildings varchar(255) DEFAULT '0' NOT NULL,
PRIMARY KEY (sektor),
UNIQUE sektor (sektor)
);

#
# Dumping data for table 'karte'
#

INSERT INTO karte VALUES ( '1.1', '1', '15', 'pktm', 'K', '20', 'HQ,');


Das Spiel funktioniert so: man kann in einem Bereich auf der Karte (wo man startet) Gebäude bauen, EInheiten produzieren und andere angreifen (wer hätte es gedacht).
Ich sitze gerade am Gebäudebau.
Laut obigenr Datenbank hat der Spieler also einen Sektor 1.1, der aus dem Landschaftstyp 1 (Wald) besteht, er hat noch 15 Felder Platz zum Bauen, heißt übrigens pktm :) , kann in diesem Sektor Kalium abbauen, welches mit der Menge 20 (willkürlich gesetzt) vorhanden ist und der Spieler hat bereits das HQ inne.
Jetzt die Frage: Soll ich soviele Felder in die Datenbank einbauen, wie der User maximal Gebäude in das Feld bauen könnte oder soll ich eine Liste mit den gebauten Gebäuden hinterlegen?
Hört sich jetzt nach Pupes an, aber ich glaueb, bei ein paar tausend Spielern wirds doch viel. Korrigiert mich wenn ich falsch liege. ;)
Weil, wenn ich die Liste hinterlege muss ich diese mit einem Script auswerten,w as Rechnerlastig ist. Wenn ich aber xxx Felder anlege braucht das wieder mehr Speicherplatz.
Also Rechenleistung kontra Speicherbedarf.
siehe Frage :D
mfg pktm
http://www.intergastro-service.de (mein erstes CMS :) )
Strat
 2003-10-13 16:34
#35544 #35544
User since
2003-08-04
5246 Artikel
ModeratorIn
[Homepage] [default_avatar]
buildings in der haupttabelle zu speichern ist laut der Normalisierung von Datenbanken nicht besonders guenstig, weil es alles sehr unflexibel wird.
Ein Spieler kann mehrere Gebaeude haben
Ein Typ von Gebaeude kann auch von mehreren Spielern gebaut werden:

primaere felder sind unterstrichen
spieler(id,sektor, typ, ....)
gebaeude(id, name, ....)
spieler_gebaeude(spielerId, gebaeudeId, livepoints, ...)
oder, wenn du jedes gebaeude unterschiedliche livepoints haben kann, sogar:
spieler_gebaeude(spielerId, gebaeudeId, nummer, livepoints, ...)

such mal nach Normalform und Datenbank (z.B. http://ffm.junetz.de/members/reeg/DSP/ )\n\n

<!--EDIT|Strat|1066048545-->
perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/
pktm
 2003-10-13 20:43
#35545 #35545
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
[quote=Strat,13.10.2003, 14:34]buildings in der haupttabelle zu speichern ist laut der Normalisierung von Datenbanken nicht besonders guenstig, weil es alles sehr unflexibel wird.
Ein Spieler kann mehrere Gebaeude haben
Ein Typ von Gebaeude kann auch von mehreren Spielern gebaut werden:

primaere felder sind unterstrichen
spieler(id,sektor, typ, ....)
gebaeude(id, name, ....)
spieler_gebaeude(spielerId, gebaeudeId, livepoints, ...)
oder, wenn du jedes gebaeude unterschiedliche livepoints haben kann, sogar:
spieler_gebaeude(spielerId, gebaeudeId, nummer, livepoints, ...)

such mal nach Normalform und Datenbank (z.B. http://ffm.junetz.de/members/reeg/DSP/ )[/quote]
Hallo!
Erstaml danke für die Hilfe, werde es mal umsetzen.

Also ein Spieler kann auch mehrere Sektoren haben.
Aber ich denke, es macht der Sache keinen Abbruch, wenn ich die ID in der DB_Spieler nicht "unique" angebe, so dass Mehrfacheinträge möglich sind.
Livepoints? Nein, aber unterschiedliche Ausbaustufen.
mfg pktm
http://www.intergastro-service.de (mein erstes CMS :) )
Strat
 2003-10-13 21:06
#35546 #35546
User since
2003-08-04
5246 Artikel
ModeratorIn
[Homepage] [default_avatar]
zu sections und spieler: wenn da eine n:m beziehung herrscht, ist da eine zwischentabelle meistens besser (du willst ja wahrscheinlich nciht, dass eine section verschwindet, wenn sie kein spieler besitzt, oder?

spieler (id, hier alles, was von spieler abhaengig ist, ....)
sections(id, hier alles, was von section abhaengig ist und nicht von spieler)
spieler_sections(spielerId, sectionsId, hier nur, was sowohl von spieler als auch von section abhaengig ist, aber nicht von einem)
perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/
pktm
 2003-10-13 23:03
#35547 #35547
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
Also ich habe mir jetzt mal dashier überlegt:
Code: (dl )
1
2
3
4
DB_Spieler(spieler_id|sektor|spieler_name|Volk|Aktionen|Resourcen1|Resourcen2|last_login[timestamp])
DB_Sektor(sektor|typ|platz|gebäude_IDs)
DB_Aktionen(aktion_ID|desc|Geb_id[welches Gebäude]|time2do[timestamp wann fertig]|where[sektor, brauche ich das noch? -> s. DB_Spieler]|spezifischer_wert)
DB_Units(id|name|att|def|def_cav|geschwindigkeit)


Praktisches Beispiel:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
DB_Spieler(1|1.1|pktm|Volk_A|7,8,9,|100|200|timestamp)
DB_Sektor(1.1|0(Wald)|12|1,2,3)
DB_Geb(
1|HQ_Stufe_1|5|Kontrollzentrum|?
2|Kaserne_St_1|3|Einheiten_Ausbild|Faktor
3|Schmiede1|3|Waffenproduktion|?
4|HQ_Stufe_2|6|Kontrooz+Verteidigungsturm|+10%
)
DB_Units(1|Soldat|20|10|5|7)
DB_Aktionen(
7|Geb_Ausbau|1|timestamp|1.1|Geb1->Geb2
8|Einheiten_Prod|2|timestamp|1.1|5 * Unit1
9|Forschung|3|timestamp|1.1|? +1att, wie ich das mache? ka
)

Und, was sagst ihr?
Ruhig alles kritisieren, es ist noch keine Tabelle angelegt.
mfg pktm
http://www.intergastro-service.de (mein erstes CMS :) )
pktm
 2003-10-15 00:59
#35548 #35548
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
So sieht es jetzt aus:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
# --------------------------------------------------------
#
# Table structure for table 'aktionen'
#

CREATE TABLE aktionen (
id int(255) NOT NULL auto_increment,
beschr varchar(255) NOT NULL,
building_id int(255) DEFAULT '0' NOT NULL,
time2do timestamp(14),
sektor varchar(255) NOT NULL,
was varchar(255) NOT NULL,
PRIMARY KEY (id),
UNIQUE id (id)
);

#
# Dumping data for table 'aktionen'
#

INSERT INTO aktionen VALUES ( '1', 'Ausbau', '1', '00000000000000', '1.1', 'ausbau1_2');

# --------------------------------------------------------
#
# Table structure for table 'buildings'
#

CREATE TABLE buildings (
id int(255) NOT NULL auto_increment,
name varchar(255) NOT NULL,
platzbedarf int(255) DEFAULT '0' NOT NULL,
Funktion varchar(255) NOT NULL,
Wert varchar(255) DEFAULT 'undef' NOT NULL,
PRIMARY KEY (id),
UNIQUE id (id)
);

#
# Dumping data for table 'buildings'
#

INSERT INTO buildings VALUES ( '1', 'HQ1', '5', 'Kontrollzentrum', 'undef');
INSERT INTO buildings VALUES ( '2', 'Kas1', '3', 'Einheitenproduktion', '*1%');
INSERT INTO buildings VALUES ( '3', 'Sch1', '3', 'Waffenproduktion', '0_0_0_0');
INSERT INTO buildings VALUES ( '4', 'HQ2', '6', 'Kontrollzentrum & Turm', '+10%');

# --------------------------------------------------------
#
# Table structure for table 'sektor'
#

CREATE TABLE sektor (
id varchar(255) NOT NULL,
typ tinyint(1) DEFAULT '0' NOT NULL,
platz tinyint(2) DEFAULT '0' NOT NULL,
buildings varchar(255) DEFAULT '0' NOT NULL,
einheiten varchar(255) NOT NULL,
UNIQUE id (id)
);

#
# Dumping data for table 'sektor'
#

INSERT INTO sektor VALUES ( '1.1', '0', '15', '1', '50_1');

# --------------------------------------------------------
#
# Table structure for table 'spieler'
#

CREATE TABLE spieler (
id int(255) NOT NULL auto_increment,
sektoren varchar(255) DEFAULT 'sektor' NOT NULL,
name varchar(255) DEFAULT 'name' NOT NULL,
volk tinyint(1) DEFAULT '0' NOT NULL,
aktionen varchar(255) DEFAULT '0' NOT NULL,
login timestamp(14),
Punkte int(255) DEFAULT '0' NOT NULL,
PRIMARY KEY (id),
UNIQUE id (id)
);

#
# Dumping data for table 'spieler'
#

INSERT INTO spieler VALUES ( '1', '1.1', 'pktm', '1', '0', '19700102010000', '0');

# --------------------------------------------------------
#
# Table structure for table 'units'
#

CREATE TABLE units (
id int(255) DEFAULT '0' NOT NULL,
name varchar(255) DEFAULT 'Unit' NOT NULL,
att int(255) DEFAULT '20' NOT NULL,
def int(255) DEFAULT '10' NOT NULL,
def_cav int(255) DEFAULT '5' NOT NULL,
geschw int(255) DEFAULT '7' NOT NULL
);

#
# Dumping data for table 'units'
#

INSERT INTO units VALUES ( '1', 'Standard-Einheit', '20', '10', '5', '7');

Jetzt müsste eigentlich alles wesentliche drinne sein.
Was mri noch nicht so ganz gefällt, ist, dass ich Listen mit Wertepaaren hinterelegen muss. Z.B. bei der Tabelle Aktionen.
Dort kann ich das Gebäude(ID1) ausbauen (zu Gebäude ID 2).
Dazu muss ich "ausbau1_2" schreiben.
Ich kann dann zwar mehrere Aktionen in eine Zeile schreiben, aber irgendwas sagt mir, das das nicht der normalisierten Datenbank entspricht.
Das selbe Problem habe ich beim Feld Einheiten von der Tabelle Sektoren.
Dort kann man natürlich mehrere Einheiten in unterscheidlicher Stückzahl haben, so z.B. die Standardeinheit 50 mal (also 1_20).
Wenn ich aber für jeden EInheitentyp ein Feld anlege ist das auch wieder doof.
Sollte ich dafür vielleicht eine Zwischentabelle anlegen? So aus Spieler_ID, EinheitenID und Menge?
Ist das effizienter?
mfg pktm
http://www.intergastro-service.de (mein erstes CMS :) )
<< >> 6 Einträge, 1 Seite



View all threads created 2003-10-13 16:17.