forked from github/server
90 lines
4.3 KiB
Text
90 lines
4.3 KiB
Text
Was ist das hier?
|
|
Dieses File ist eine Sammlung von kleinen Artikeln zum Code -
|
|
Designgedanken, hauptsächlich, keine Anleitungen.
|
|
|
|
- Die Variable buf
|
|
wird an zu vielen Stellen im Source benutzt. Können wir zumindest in
|
|
Zukunft versuchen, auf sie zu verzichten? Mir ist nie sehr wohl, wen ich
|
|
die irgendwo sehe.
|
|
|
|
- Bibliotheken, module
|
|
Jedes Verzeichnis in common/ erzeugt eine Bibliothek. Je nach Bedarf
|
|
muss aber nicht jeder Server die ganze Bibliothek linken (die ist eher
|
|
was für den mapper), sondern kann die Files auch einzeln linken. Jedes
|
|
modul, item, attribut, usw. sollte eine Funktion zur Verfügung stellen,
|
|
die seine typen initialisiert, also it_register respektive at_register
|
|
o.ä. aufruft. Jede Biliothek hat ein File, das ihren Namen trägt (z.b.
|
|
items.txt) mit einer eigenen init_-Funktion, die alle init_funktionen
|
|
der enthaltenen objekte enthält. (init_items, init_attributes, usw).
|
|
Neue Files hinzufügen heißt also bitte, die Registrierung in den
|
|
"bibliotheks-file" zu machen.
|
|
|
|
- KI
|
|
Beim Anblick des enums mit Rassen-Flags sieht man schnell, das die in
|
|
mehrere Kategorien fallen. Eine davon ist die KI-Steuerung, und könnte
|
|
man die vielleicht getrennt von den anderen speichern?
|
|
|
|
- Worüber man nachdenken sollte, ehe man etwas neues hinzufügt
|
|
90% aller Erweiterungen sind eigentlich optional. Ein Eressea ist z.B.
|
|
auch ohne die Rasse Troll denkbar. Leider ist die rasse Troll an derart
|
|
viele Stellen hartgecodet, das man Eressea ohne Trolle nie übersetzen
|
|
könnte (Im Kampfsystem bekommen z.B. Trolle -1 beim Reitenbonus). Immer
|
|
drüber nachdenken, ob man hartcoden muß, oder ob es auch einen anderen
|
|
Weg gibt (in diesem Fall z.B. ein at_skillmod attribut an der Rasse
|
|
Troll).
|
|
|
|
- RC_SPELL
|
|
Es gibt einen Zauber (Ferne Vision) der Einheiten vom Typ RC_SPELL
|
|
erzeugt, aber 36 Stellen, an denen auf diesen Typ abgetestet werden muß
|
|
(vielleicht sogar mehr?). Können wir das mal auf einen curse umstellen?
|
|
Am besten in Kombination mit einem allgemeinen "diese Einheit/Region
|
|
soll in den Report der PArtei x", das man dann auch für Spionage usw.
|
|
benutzen kann, und das im Fall von Antimagie oder Zauberende durch einen
|
|
Trigger am entsprechenden curse mit zerlegt wird?
|
|
|
|
- Wie komplex macht man einen Curse?
|
|
siehe vorangegangener Absatz. Generell gilt hier: Lieber zwei
|
|
vielseitige Dinge machen, als ein unflexibles - der curse sollte
|
|
lediglich der container seiin, der die wirkung aufrechterhält (das
|
|
attribut an der region überwacht, und per trigger-funktion bei ende des
|
|
curse oder antimagie entfernt). die eigentliche wirkung kann man in ein
|
|
separates attribut stecken, dann ist sie auch in anderen kontexten als
|
|
zauberei verwendbar (gebaüde oder items mit der gleichen wirkung, z.b.).
|
|
Tests sollten so wenig wie möglich auf einen curse gehen (in fact,
|
|
eigentlich nur bei der antimagie) sondern immer auf die wirkung (das
|
|
attribut).
|
|
|
|
- wie benenne ich Sourcedateien?
|
|
lang drüber nachgedacht, bin ich zum schluss gekommen: kleinbuchstaben,
|
|
keien unterstriche. Es kann sich nie jemand merken, ob testplayer oder
|
|
test_player jetzt richtig ist, und wir kommen sicher selten in die
|
|
situation, das wir zwischen opium_bringen.c und opi_umbringen.c
|
|
unterscheiden müssen.
|
|
|
|
- wie benenne ich variablen?
|
|
da gilt das gleiceh wie bei den files, mit einer ausnahme:
|
|
typspezifikation, also zum beispiel at_ für attributstypen, mit einem
|
|
unterstrich. dann ist auch klar, was at_work ist: ein attribut, das was
|
|
mit arbeit zu tun hat, keine boolean-variable die sagt ob man auf der
|
|
arbeit ist.
|
|
|
|
- faction::units
|
|
Die Variable funktioniert und kann benutzt werden. folgendes:
|
|
for (r=regions;r;r=r->next) for (u=r->units;u;u=u->next) if (u->faction==f) {}
|
|
schreibt sich viel einfacher so:
|
|
for (u=f->units;u;u=u->nextF) {}
|
|
und ja, es wird garantiert, das das funktioiniert, und regionsreihenfolge
|
|
einhalten tut es auch. weshalb wahlloses erzeugen von einheiten per calloc und
|
|
ohne createunit() aufruf schon seit längerem ein NoNo ist.
|
|
|
|
- buffer length
|
|
Namen von attributen, hashcodes für items, usw. sollten kurz sein.
|
|
schliesslich landen sie im Datenfile. Eine Funktion, die sie einlädt,
|
|
sollte mit 32 byte speicherbedarf rechnen.
|
|
|
|
- FL_MARK und FL_DH:
|
|
Der unterschied zwischen diesen beiden Flags ist:
|
|
FL_DH sollte man vor der Benutzung auf einen Wert setzen, den man coraussetzt
|
|
(man kriegt keinen wert garanteirt).
|
|
FL_MARK ist immer 0. jede routine die es setzt, muss es am ende wieder auf 0
|
|
zurücksetzen. code-beispiel ist z.b. die SORTIERE-funktion.
|