![[Guide] Privat-Server: Aufbau & Etablierung | Private-Server: Set-Up & Establishment](https://www.elitepvpers.com/forum/iconimages/metin2-pserver-guides-strategies/guide-privat-server-aufbau-etablierung-private-server-set-up-establishment_ltr.gif){kind=small}
Willkommen,
bei diesem Thread handelt es sich um ein Guide, welches Strukturen,
Routinen und Pläne zum erfolgreichen Servermanagement und der
Vermarktung eures Projektes behandelt. Es werden nicht selten
psychologische Grundprinzipien und Grundkenntnisse im Bereich des
Projektmanagements aufgegriffen um euch einige Ansichten und
Meinungen zu erläutern. Ich möchte jeden Leser bitten in die Diskussion
miteinzusteigen, unabhängig davon, ob ihr mir zustimmt oder nicht. Viel
Spaß und viel Erfolg mit den Tipps und Tricks, die ich euch mit auf den
Weg gebe!
Inhalt dieses Threads
Vorwort - Wer bin ich und wieso solltest du auf mich hören?
Hallo,
mein Name ist Justice, Community Manager eines momentan entstehenden
Servers und heute geht es um ein Thema der etwas anderen Art.
Ich sitze hier heute und denke genau wie Gl0bal über Dinge nach, über die
sich manch anderer wahrscheinlich keine Gedanken macht, geschweige denn
die Zeit hat sich darüber Gedanken zu machen. Ihr mögt euch fragen, wer ich
bin oder für wen ich mich halte um hier einen Text zur "Lage der Nation" zu
schreiben.. nun diese Frage kann ich euch direkt beantworten, ohne meinen
auf meinen Namen und meine Vergangenheit hinzuweisen.. Ich bin in der
Metin2 Sektion seit nunmehr 4 Jahren aktiv. Das Adjektiv "aktiv" passt in
diesem Zusammenhang jedoch weniger zu mir als zu jedem anderen in dieser
Community, denn ich stehe weder im Rampenlicht, noch habe ich mich in
irgendeiner Form jemals in den Vordergrund gedrängt. Ich habe mit einer
Vielzahl angesehener oder bekannter Personen in der Sektion gearbeitet und
war bereits in jungen Jahren an vielen Serverprojekten beteiligt.
Da ich nun indirekt dazu verpflichtet bin, meine Projekte möglichst adequat
aufzulisten, werde ich das im Folgenden tun. Ich hoffe jeder Leser versteht,
dass ich die Projekte hier nicht beim Namen nennen möchte. Ich war bei
keinem der Projekte unter meinem jetzigen Pseudonym bekannt. Jeder, der
eine Auflistung meiner Projekten mit Jahreszahlen haben möchte, kann mich
gerne per privater Nachricht benachrichtigen.
Meine Projekte waren durchschnittlich 6-10 Monate online. Ich war an
insgesamt 9 Projekten beteiligt, 6 davon waren hinsichtlich den oberen
Plätzen der Topliste relevant. Ich habe die letzten 4 Jahre Revue passieren
lassen und mich im Zuge dessen an dieses Guide gesetzt, welches meine
Erfahrungen innerhalb einiger TOP Projekte beinhaltet. Zwei der Projekte
sind innerhalb der Topliste langfristig auf Platz 1 gewesen (zu einer Zeit,
zu der Votes nochnicht gepusht wurden), ein weiteres Projekt auf Platz 3.
Ich denke daher, dass meine Qualifikation gemessen an den Projekten an
denen ich beteiligt war mehr als ausreichend ist, um ein solches Guide
verfassen zu können.
Weniger zu mir, mehr zum Inhalt dieses Beitrages.
1. Community (miss-)Management in der Metin2 Szene
In unserer Diskussion geht es ja um technische Fortschritte.. jedoch ist diese
Wortwahl mit Bedacht gewählt, denn mit technischem Fortschritt ist in erster
Linie die methodische Progression und Prozessoptimierung im Bezug auf die
Szene gemeint, mit der wir euch einen Denkanstoß geben wollen und euch die Möglichkeit geben gewisse interne Abläufe oder Problemlösungen zu
übernehmen und in euer eigenes Projekt zu integrieren und/oder mit uns
daran weiterzuarbeiten um unsere "gemeinsamen" Methoden zu
optimieren. In diesem Sinne geht es nicht nur um die mechanische Technik
sondern auch um oben genannte Abläufe und unsere generelle Einstellung
dazu bzw. unsere Herangehensweise.
Ich möchte mich zu allererst einem verbreiteten Fehler widmen, der meines
Erachtens nach immer wieder begangen wird: die ineffiziente Zuweisung der
Kompetenzen innerhalb eines jeden Teams.
Ihr habt das sicher oft miterlebt, ihr besucht aus irgendeinem Grund den
Webauftritt eines Servers, im Speziellen das Forum und betretet dort die
News Sektion. Im folgenden Arbeitet ihr euch durch Threads mit mehr oder
minder nützlichen Informationen, und ärgert euch im Anschluss sogar
meistens darüber, besagten Thread zu Ende gelesen zu haben. Was ich
damit ausdrücken möchte ist die Inkonsequenz und daraus resultierende
"Kindergarten-Professionalität" die eine Fülle der Metin2 Server an den Tag
legen. Würde man einen User fragen ob ihm diese Herangehensweise Seitens
des Teams aufgefallen ist, würde er wahrscheinlich sagen "Nein, wieso? Das
ist doch ganz normal."
Ich sage genau das ist es NICHT. Dieses Beispiel bestätigt nur die alltägliche
Farce in der Metin2 Sektion. Die Spieler haben sich mittlerweile an den
unterirdischen Standard im Bereich des Community Managements gewöhnt
und machen sich deshalb nicht einmal mehr Gedanken in diese Richtung. Um
diese Verhaltensweise psychologisch zu erklären greife ich gerne zur
Metapher eines Fisches im Aquarium. Der Fisch schwimmt Tag für Tag im
Aquarium herum, denn das ist seine Welt, er kennt nichts anderes und das
reicht ihm, denn er ist ein Gewohnheitstier, er stirbt in diesem Aquarium nicht,
er kennt seine Möglichkeiten innerhalb dieser Umgebung. Der Punkt den ich
hier versuche zu erläutern ist die Denkweise des Fisches.. er hinterfragt nicht
ob es noch etwas anderes gibt als dieses Aquarium und nimmt das was er
hat. Das ist auch absolut in Ordnung aber so sollten wir Menschen nicht
agieren, wir sollten das Maximum aus dem herausholen was uns gegeben
wurde. Im Bezug auf das Community Management behaupte ich daher das
KEINER der aktuell "angesehenen" Server seine Benutzer respektiert und sie
mit Anstand behandelt (zumindest in dem meiner Meinung nach angebrachten
Maße). Jetzt werden einige dazu geneigt sein, dieses Problem direkt aggressiv
angehen zu wollen und auf mich wütend zu werden, dafür das ich
Behauptungen Aufstelle.. solltest du meinen Punkt nicht verstehen hast du
meine Analogie mit dem Fisch im Aquarium noch nicht verinnerlicht. Ich
schreibe das hier nicht um Vorwürfe zu verteilen, sondern um meinen
Gedankengang zu erläutern. Das der Server X seine Community nicht mit dem
nötigen Standard an qualifiziertem Community Management "verwöhnt" liegt
nicht am Server oder am Team, nein es liegt vielmehr an der Messlatte der
Szene und den damit verbundenen Erwartungen hinsichtlich dem Umgang mit
der Community.
Es ist mittlerweile nicht einmal mehr eine Seltenheit wenn ein Server gar kein
Forum, oder eines mit wenigen aktiven Benutzern hat. Da frage ich mich doch
welchen Grund das hat... der Grund ist simpel, der Besuch des jeweiligen
Webauftritts bietet einen zu geringen Mehrwert um vom Benutzer für voll
genommen zu werden. Die Messlatte ist mittlerweile soweit in den Keller
gerutscht, das die Spieler WILLENTLICH komplett auf die Verwendung ALLER
Ressourcen verzichten.
Da habe ich eine ganze Reihe von Dingen relativ offensiv angesprochen und
das noch mit einem gewissen Unterton des Vorwurfs. Wie löst man also ein
Problem, welches vor wenigen Minuten noch nicht einmal existiert hat?
Um auf diese Frage eine Antwort zu finden sollte man sich zuerst die Frage
stellen, ob man mit seinem Server und der damit verbundenen Marke (dem
Brand) das Optimum erreichen will.. damit meine ich SOWOHL die maximale
Anzahl an Spielern als auch den maximalen Umsatz. Man könnte diesen
Sachverhalt auch als "das Potential komplett ausschöpfen" bezeichnen. Hier
liegt nämlich der Hund begraben. Wie soll Professionalität entstehen wenn
noch nicht einmal der Grundgedanke stimmt? Richtig, gar nicht. Das ist jedoch
ein Thema für einen anderen Tag. Wir haben uns mit diesem
"Missmanagement" auseinandergesetzt und eine Lösung gefunden die
einfacher nicht sein könnte.
Um auf das Beispiel von Vorhin zurückzukommen.. weshalb sollte ein Spieler in
einem Thread, in dem es um ein Event geht den Beitrag eines Game-Masters
lesen müssen, um relevante Informationen zu erhalten? Eine Antwort darauf
findet sich nicht, und genau das ist der Punkt an dem wir ansetzen, denn das
ist der Grundgedanke der wir in unserem Team verfolgen, eine klare
Aufgabenstrukturierung. Es gibt keinen ersichtlichen Grund um JEMALS die
Kommentar Funktion innerhalb der News Sektion des Forums für allgemeine
Teamler zu aktivieren.
Denken wir diesen Gedanken doch einmal zu Ende, wenn ein Game-Master
einen Event Thread kommentiert bedeutet das, er verwendet Zeit, die er zum
Supporten (In-Game oder in anderen Bereichen des Forums) benutzen
konnte, um dem Spieler eine Information zu vermitteln. Viel besser ist es,
wenn man klare Linien zieht und klare Ansprechpartner einsetzt. Die einzige
Person, die ein Event anzukündigen und im Anschluss darüber zu berichten
hat, ist der Community Manager.
Die einzige Person, die den Spieler über Wartungsarbeiten informieren sollte
ist ein Techniker und die einzige Person, die allgemeine Änderungen am Server
ankündigen sollte (Patches etc.) ist der Server Administrator.
2. Beta-Phasen: Hört auf euch selbst zu belügen!
In Anbetracht der bereits genannten Probleme in der Strukturierung des
Teams, welches im Idealfall noch vor der Konzeption des Servers entsteht
kommen wir nun zur eigentlichen Entwicklung und den hier stattfinden
absoluten Tiefpunkten der Serverkonzeption. Schauen wir uns in diesem
Beispiel Szenario Y an (Y ist in diesem Beispiel eine Variable und kann durch
einen beliebigen anderen Buchstaben ersetzt werden).
Der Admin von Server Y hat nun sein Team zusammengestellt und ihnen sein
Serverkonzept anvertraut. Wir gehen im Folgenden davon aus das besagtes
Team die technische Finesse besitzt um das Konzept Y umzusetzen und einen
Vollwertigen Server auf die Beine zu stellen. In dieser Phase der Entwicklung
gibt es nunmehr etliche Stadien des Fortschritts, welche von "nicht Existent"
bis "Beta-Reif" reichen. Ich werde mich nun mit diesem "Beta" Status
beschäftigen, denn hier findet sich meiner Meinung nach das größte
Verständnisproblem. Wie oft sehen wir Server (die sogar eine
akzeptable/neue Idee in die Sektion bringen) die in eine Beta-Phase gehen, in
der wir vor einem nicht ansatzweise fertigen Server stehen? Schlichtweg
nach dem Gedanken "Hau raus die Schei**" wird releast und dann wird
gemolken und gemolken und gemolken, unter dem Vorwand der "Testphase"
werden Angebote im Itemshop erwerblich und plötzlich wird aus der Beta die
eigentliche Version 1.0, denn die Führungsebene merkt, das sich der Server ja
jetzt schon lohnt und vergessen in ihrer Gier und in ihrem Geldrausch das
eigentlich wichtige, das Serverkonzept. Nehmen wir in diesem Fall wieder
Server Y: Server Y ist in einer "Beta" und innerhalb der ersten Tage erhält der
Server Administrator Einnahmen im Wert von 1500€ (kann durch eine
beliebige, nicht zu hoch angesetzte Zahl ausgetauscht werden). Nun denkt
sich dieser Administrator natürlich nichts böses und gibt dem User immer mehr
Möglichkeiten sein Geld "gewinnbringend anzulegen". Hierbei suggeriert er
wahlweise Rabatte, die der Spieler UNBEDINGT nutzen sollte oder Events die
NUR FÜR KURZE ZEIT eine kleine aber feine Ersparnis bieten. Ich möchte an
diesem Punkt erneut anmerken, das wir uns immer noch in der Beta befinden,
daran denkt jedoch mittlerweile kaum einer mehr. Nach kurzer Zeit ist die Kuh
gemolken und die Einnahmen nehmen von Tag zu Tag ab, woran das liegt
weiß der Server Admin in dieser Situation aber auch nicht, denn egal wie sehr
er sich den Kopf zerbricht, er versteht einfach nicht, das er sein Konzept 1.
nicht vervollständigt oder 2. zum Erbrechen gemolken hat und selbst WENN
der Server der "Beta" Phase alle Ehre macht, das Serverkonzept mittlerweile
mehrfach kopiert oder komplett ausgelutscht ist. Wie geht man dagegen vor,
wäre jetzt die logische Frage.. meine Antwort darauf:
Hört auf euch selbst zu belügen!
Solltet ihr wirklich euer Serverkonzept testen wollen, dann TESTET es. Wir
haben hier das Problem das die "Beta-Phase" zu einem solch inflationären
Wort mutiert ist, das jeder IDIOT auf die Idee kommt eine "Beta-Phase" zu
starten. Wo liegt hier das Problem fragt ihr euch.. ganz einfach, es wird sich
während der Beta-Phase kaum noch auf das beheben von Problemen fixiert
sondern der Großteil der Zeit auf die erfolgreiche Vermarktung des Servers
verwendet. Es gibt auch hier wieder mehrere Möglichkeiten der
Fehlerbehebung.. ihr könnt euch entweder die Beta-Phase Sparen oder den
Itemshop, sowie alle Gewinnbringenden Angebote einstellen. Das mag hart
klingen, geradezu unfair, doch das ist es nicht. Weshalb ist es das nicht? Es
ist nicht unfair oder hart weil DU dich dazu entschieden hast den Server auf
eine Belastungsprobe zu stellen und NICHT der Spieler. Der Spieler hilft DIR
nicht du dem Spieler. Bist du ein Mensch der sofort an den Markt gehen will,
dann überspringe bitte die sogenannte "Beta" denn wenn du sie durchführst
handelt es sich um keine solche und du bist so schnell bei einem Spieler unten
durch wie du nicht einmal mehr "Einnahmen" sagen kannst, denn der weitere
nützliche Nebeneffekt ist die Ersparung eines hard-resets. KEIN Spieler wird
sich über einen hard-reset beschweren, wenn der Itemshop in der Beta
kostenlos ist.
3. Vorbereitung auf den Start: Einen Hype generieren
Der Serverstart, eines der wohl wichtigsten Unterfangen, die einem jeden
Server bevorsteht. Wir alle kennen Server die ungemein gehyped werden und
im Endeffekt an Punkt 1 oder 2 meiner Analyse scheitern und daher nicht in
der Lage sind sich langfristig zu etablieren. Wieso solltet ihr euch an solchen
Servern orientieren? Ihr solltet euch an solchen Servern orientieren, weil sie
etwas richtig gemacht haben, das ihr nicht getan habt. Sie haben einen Hype
generiert und das Erfolgreich. Das hat dein Server entweder nicht gleich gut
oder in unzureichendem Ausmaß "geschafft". Nun, wie generiert man einen
Hype? Wir nehmen uns hier wieder als Beispiel den Server Y welcher nun auf
die Beta-Phase verzichtet hat und direkt an den Start geht.
An diesem direkt Start ist absolut nichts auszusetzen, doch auch hier
erfordert die gesamte Aktion ein gewisses Fingerspitzengefühl, welches nur
von den wenigsten in dieser Sektion WILLENTLICH vorgewiesen wird. Es
handelt sich hierbei um dasselbe Prinzip, welches sich auch im Bereich der
Werbung im Fernsehen oder auf Werbeplakaten findet:
Erst investieren - dann abkassieren
Ihr bezahlt im Voraus für das Image das euer Server erzeugen soll und dabei
solltet ihr euch nicht lumpen lassen. Wie oft haben wir Vorstellungen
gesehen, die in vielleicht 2 Stunden Arbeit hingeschmiert und danach auf
etlichen Foren veröffentlicht wurden? Zu oft! Es gibt viele fähige Designer in
der Metin2 Sektion.. Wieso also nicht 50-100€ in eine vernünftige Vorstellung
investieren? Es ist schwierig sich zu einer risikobehafteten Ausgabe
durchzuringen, das weiß ich, doch so läuft das Business. Ich garantiere euch,
euer Geld ist hier gut angelegt und ihr werdet (mindestens) das doppelte oder
Dreifache eures normalen Erlöses einnehmen. Nun haben wir bei Server Y eine
vernünftige Vorstellung für (sagen wir) 75€ erstanden. Weiter geht's mit
einem Trailer.. Ein ansehnlicher Trailer kann für 50€ in Auftrag gegeben
werden. 125€ haben wir also bisher Ausgegeben. Das ist sozusagen das
Grundbudget, wenn ihr ein Public Homepage Script und einem nulled Forum.
Das reicht jedoch bei weitem nicht um einen Hype zu generieren. Ihr könnt
euren Server im aktuellen Stadium releasen, vielleicht wäre er erfolgreich
doch die Wahrscheinlichkeit hier einen lucky-punch zu landen ist nicht sehr
groß. Daher wollen wir nun auf Server Y einen Hype generieren. Hierbei
machen wir uns ein sehr leicht verständliches Prinzip zugute: proportionales
Wachstum. Das schöne an der Metin2 Sektion im Bezug auf publicity ist die
totale Berechenbarkeit des Hypes. Je mehr Geld du bereit bist in Testvideos,
Publishing des Trailers bei unterschiedlichen Youtubern oder Werbung in Foren
zu bezahlen, desto mehr Spieler werden deine Arbeit unter die Lupe nehmen
und sich eine Meinung bilden. Ist dein Serverkonzept gut und du kannst die
Spieler an deine Idee binden, wird dein Server so GARANTIERT erfolgreich
sein.
4. Der Serverstart: Darauf musst du achten
Der Serverstart steht nun vor der Tür. Du hast dich gut vorbereitet, eine
erfolgreiche Beta durchgeführt und alle gravierenden Bugs behoben? Dann
ist es jetzt Zeit, deinen Server für die Öffentlichkeit zugänglich zu machen.
Nachdem du einen Hype generiert hast, indem du eine (mindestens wöchige)
Promotionphase durchgeführt hast, warten mehrere dutzend Spieler auf den
Release. Du solltest beim Release darauf achten, dass du den angekündigten
Termin einhalten kannst. Zum Release-Termin ist es ideal, wenn sich ALLE
Teamler im Teamspeak befinden. Das hat 2 Vorteile,
- stärkt den Zusammenhalt des Teams.
- sorgt für einen soliden Auftritt nach außen.
Diese 2 sehr simplen Regeln führen bei Einhaltung zu einer AUTOMATISCH
höheren Akzeotanz der Community und ermöglichen dir den Erhalt des ersten
positiven Feedbacks. Der Hype des Servers wird somit ein kleines Stück
gesteigert oder bleibt zumindest konstant. Es geht nun darum
Arbeitstechniken zu etablieren, Prozessabläufe zu optimieren und
Problembehandlungen zu automatisieren. Es geht nichtmehr darum, dass du
dir ein Bein ausreißt, du muss die Früchte deiner Arbeit jetzt lediglich ernten,
doch dabei scheitern leider die meisten Server. Es ist absolut in Ordnung
einen Server online zu bringen, der dasselbe 0815 Konzept wie jeder andere
hat. Solange du dein Team besser unter Kontrolle hast und einen besseren
Eindruck nach außen machst als alle anderen Server mit einem ähnlichen
Konzept werden die Spieler sich für dein Projekt entscheiden. Nach dem
Serverstart werden vor Allem dein In-Game und Foren Team unter extremer
Belastung stehen, achte deshalb darauf, deine Supportmöglichkeiten richtig
einzurichten und ihnen somit das Supporting deiner Spieler so gut wie möglich
zu erleichtern. In den ersten Minuten nach dem Serverstart ist es
desweiteren wichtig, Struktur zu demonstrieren. Die Benutzer werden nach
einem oder mehreren Events betteln, diese solltest du ihnen allerdings nicht
auf dem Silbertablett vorsetzen. Damit möchte ich nicht sagen, dass du keine
Events ausrichten sollst, im Gegenteil, allerdings sollte es in deinem Interesse
liegen Professionalität vorzuweisen. Verwende also Eventkonzepte, welche du
vor dem Start des Servers aufgestellt hast. Kündige mehrere Events im Forum
an, hierbei gilt allerdings die Faustregel : "Jedes Event sollte mindestens eine
Woche vorher in einem gesonderten Forenpost angekündigt werden". Du
magst dir jetzt die Frage stellen wieso die User somit eine Woche auf ihr
Event warten müssen. Diese Frage ist auch völlig gerechtfertigt, deshalb
solltest du dieses Event wenige Tage vor dem Server Release ankündigen. So
gibst du den Spielern vor dem Serverstart bereits die Vorstellung auf ein
Großereignis, auf das sie sich freuen dürfen und hältst die "7 Tage Regel" ein,
welche sich bei weiteren Events als sehr nützlich erweisen wird (die
Organisation, Vorbereitung und Durchführung eines Events werden von mir
ggf. in einem gesonderten Punkt angesprochen). Ein weiterer, sehr
verbreiteter Gedanke besteht in dem Umgang mit gemeldeten Bugs. Deinem
Team werden in den ersten Stunden/Tagen viele Bugs gemeldet werden,
diese wirst du jedoch NICHT ALLE sofort fixen. Der Grund dafür besteht erneut
in der Struktur und der Aufrechterhaltung des passiv generierten Bildes
deines Teams nach außen hin. Da du in der Beta ja bereits alle
spielentscheidenden Bugs gefixt hast, wird es sich bei den kommenden Bugs
nur noch um Kleinigkeiten gehen. Sollte die Community deines Servers weitere
Spielentscheidende Bugs finden, solltest du schnell handeln und diese von
deinem Technik Team sofort fixen lassen.Bei allen anderen Bugs liegt es in
deinem eigenen Interesse, geregelte Wartungsarbeiten zu angekündigten
Zeiten anzusetzen. Hierbei gilt ebenfalls die "7 Tage Regel". In einer
Wartungsarbeit werden also alle kleineren Bugs gefixt, Rechtschreibfehler
behoben oder Preise innerhalb der Shops angepasst. Zu jeder Wartungsarbeit
sind dann Patchnotes in einem jeweils GESONDERTEN Thread zu
veröffentlichen. Die Differenzierung der Wartungsarbeiten und Events
innerhalb ihrer jeweiligen Forenkategorie sind essenziell, sicherlich gibt es die
Möglichkeit einen gemeinsamen Thread zu benutzen, doch diese
Vorgehensweise zeugt von Unprofessionalität. Du solltest dem Benutzer soviel
Arbeit wie möglich abnehmen, selbst wenn das bedeutet, dass du dir mehr
Arbeit machen musst als bisher. Es ist daher wesentlich besser, wenn du
jedes Event mit einem einzelnen Thread beschreibst, da du somit
die Transparenz gegenüber dem Informationssuchenden maximierst und ihm
die gesuchten Informationen so übersichtlich wie möglich zur Verfügung
stellst.
5. Etablierung: So bleibt dein Server Im Trend
Einige Server versuchen "langanhaltenden Spielspaß" mit einem erhöhten
Maximallevel gleichzusetzen, "Weisheiten" wie diesen möchte ich den Kampf
ansagen. Es geht bei der Etablierung innerhalb der Top-Server darum, die
Community bei Laune zu halten und dazu gibt es erneut einige Grundprinzipien
und Gedanken mit denen man sich Auseinandersetzen sollte. Ich möchte dir
heute eine sehr effektive Methode mit auf deinen Weg geben:
Game-Updates. Nein, damit meine ich nicht die wöchentlichen Patches, damit
meine ich UPDATES. Als Updates definiere ich in diesem Kontext zusätzliche
Spielinhalte, welche dem Spieler ab einem bestimmten Spielzeitpunkt zur
Verfügung gestellt werden können. Ein Beispiel hierfür wären 2 zusätzliche
End-Game Runs, welche zusätzlich die Storyline (falls vorhanden) erweitern
und dem Spieler die Möglichkeit einen Run-Exklusiven Gegenstand zu erhalten.
Ob es sich bei dem Gegenstand um ein Pet, eine Rüstung, ein Reittier oder
eine Waffe handelt ist irrelevant, die Langzeitmotivation steigt somit
ungemein. Hierbei handelt es sich natürlich nur um eine sehr einfach
umzusetzende und mit (Verhältnismäßig) wenig Arbeitsaufwand verbundene
Methode. Es geht mir bei diesem Beispiel vielmehr um das Prinzip der
Implementation zu einem festen Zeitpunkt. Spiel Updates sind also
unverzichtbar, wenn es darum geht, einen Server lange aktuell zu halten. Ein
Update sollte neue Features und Spielentscheidende Anpassungen beinhalten
(wie z.B. Klassenbalancing, wenn es im PvP zu Problemen kommen sollte). Ein
Spielupdate sollte im einmonatigen Rythmus durchgeführt werden.
Um deinen Server auch nach außen hin zu repräsentieren, solltest du gezielte
Promotionsaktionen für deine Game-Updates starten. Hierbei gilt erneut:
"Planung ist alles". Du solltest bereits VOR dem Serverstart mit der Planung
und Umsetzung des ersten Spielupdates beginnen. Du kannst die neuen
Features somit von einem Youtuber deiner Wahl aufnehmen und anspielen
lassen, bevor diese für die Öffentlichkeit zugänglich sind. Jeder Spieler wird
darauf warten, die monatlichen Änderungen eine Woche vor dem Release
anschauen zu dürfen und sich umso mehr darauf freuen. Du solltest es aber
nicht dabei belassen, kümmere dich darum, dass dein Designer entsprechende
Grafiken zum Release deines Updates bereitstellt. Du kannst das Spielupdate
so optimal bewerben und den Hype um deinen Server sowohl innerhalb als
auch außerhalb deiner Community erneut entfachen. Deine Spieler werden sich
mithilfe dieser kleinen aber feinen Routinen gut orientieren können und deinem
Server noch mehr Aufmerksamkeit schenken.
6. Previews: Strukturiert von Anfang an
Du kannst dich als aufstrebender Serveradmin bzw. zukünftiger Serveradmin
für oder gegen eine Serverpreview entscheiden. Ich möchte dir nun bei deiner
Entscheidung helfen und dir ebenfalls die Rahmenbedingungen des (in meinen
Augen) gekonnten und strategisch klugen Previews erläutern.
Ein Preview ist offengesagt IMMER eine gute Sache. Du gibst dem Publikum
schon vor deinem Serverstart bzw. während der Entwicklungsphase die
Möglichkeit dir direktes und konstruktives Feedback zu geben. Hierbei solltest
du doch darauf achten, dass du dein Preview erst im Rahmen deiner
Promotion (vgl. Punkt 3.) in Angriff nimmst. Ein Preview sollte als Einleitung
der Promotion-Phase gewählt werden und den Spielern möglichst früh einen
bildlichen und schriftlichen Eindruck deines Projektes vermitteln. Du solltest
deinen Preview-Thread auf epvp daher als kleines Entwicklertagebuch sehen.
Hierbei solltest du jedoch darauf achten, dass du ausschließlich die positiven
Ereignisse in der Entwicklung publizierst und diese auch nur für den Leser
bereitstellst, wenn du das "Feature" vollendet hast. Du magst dich nun
vielleicht fragen, wieso du nur die positiven Ereignisse der Entwicklung
auflisten sollst. Der Grund hierfür klingt hart, liegt aber dennoch auf der Hand:
negative Ereignisse interessieren niemanden. Es ist vielleicht nicht sehr
elegant ausgedrückt, allerdings möchte ich dir versichern, dass die Publikation
von "Rückschlägen" einem Server der sich in der Entwicklung befindet
zwangsläufig mit großer Wahrscheinlichkeit schadet. Ich möchte dir
desweiteren empfehlen für deine Preview einen festen "Releaseplan" bzw. ein
"Releasemanifest" anzulegen, welches du mit den Releases deiner Features
ausfüllst und diese im Anschluss daran mit einem ungefähren Releasetermin
versiehst. Transparenz kannst du somit vom Anfang an erzeugen. Zu guter
letzt möchte ich dich noch darauf hinweisen, dass du deinen Preview-Thread
erst releasen solltest, wenn du deinen Server KOMPLETT fertiggestellt hast.
Du solltest nicht Planlos ein Preview eröffnen, das du nach und nach füllst,
sondern mithilfe der bereits fertiggestellten Features deinen strukturierten
Releaseplan einhalten, denn eine Preview dient im Optimalfall immer zur
Einleitung deiner Promotionsphase.
Wir haben nun die Notwendigkeit bzw. Option deiner Preview offengelegt und
geklärt wann und unter welchen Umständen du sie in Angriff nehmen solltest.
Danach haben wir die Grundstruktur der Preview festgelegt, nun geht es an
den Inhalt.
In deiner Preview solltest du zuerst einmal dein Konzept vorstellen, nein damit
meine ich nicht nur die klassische Einstufung in "Old-, Middle-, Newschool"
sondern eine detaillierte Konzeption. Schreibe ruhig einen längeren Text, der
den Lesern deine bzw. eure Gedanken zu eurem Projekt offenlegt. Wieso habt
ihr Genre X, Y oder Z gewählt? Weshalb habt ihr nur eine Anzahl von X Runs /
Maps implementiert? Was habt ihr euch bei eurem Uppsystem gedacht? usw. .
Siehst du wo das hinführt? Ja richtig, in die Transparenz.. du gibst dem
Spieler das Gefühl, dass du alles durchdacht hast, dass du nichts dem Zufall
überlässt und du mit jedem Gedanken eine Idee umsetzen willst. Als nächstes
beschreibst du die Features und widmest dich im Anschluss der Vorstellung
der neuen Features und wenn ich sage neue Features, meine ich neue
Features und nicht "neue" Features. Ich sehe so oft Server die ihre "neuen"
Features anpreisen und im Endeffekt anstatt dem Shining-System mit 5
Shinings plötzlich UNGLAUBLICHE 8 Shinings implementiert haben. Da denkt
man sich doch "WOW, die Revolution hat begonnen!" - nicht, denn anhand
dieses Beispiels möchte ich erleutern, wieso dieser Denkweise ein Mangel an
Intelligenz zugrunde liegt. Das Feature ist in diesem Fall das Shining-System,
völlig egal wieviele Shinings der Server einfügt, es ist keine Kunst etwas zu
nehmen das "Open-Source" ist, es zu implementieren und auszubauen. Das
eigentliche Feature ist das "Shining-System", dieses Feature sollte in der
Kategorie "Features" vorgestellt werden und nicht in der Kategorie "neue
Features" bzw. sollte es nicht als "neu" betitelt werden, außer der Server ist
wirklich der EINZIGE, der dieses System in dieser Form verwendet. Sollte
jemand allerdings ein veröffentlichtes Feature nutzen welches er selbst von
Grund auf neu geschrieben hat bzw. mindestens 50% des Codes verändert
wurde, darf man es getrost als "neu" bezeichnen, auch wenn der Spieler das
im Endeffekt nicht prüfen kann.
Zusammengefasst:
Jeder hat die Möglichkeit sich entweder für oder gegen eine Preview zu
entscheiden. Eine Preview sollte vor der Promotionsphase stehen und wie ein
Entwicklertagebuch behandelt werden, in dem allerdings nur das fertige
Produkt dargestellt und beschrieben wird. Eine Preview sollte erst dann
eröffnet werden, wenn das Projekt fertig ist und vor der Beta/dem Release
steht. Die Preview sollte einen "Releaseplan" beinhalten, der alle Features
ankündigt und dahinter der Preview-Zeitpunkt als Datum festgelegt ist. Im
Preview sollten folgende Dinge enthalten sein: Konzeption (FAQ bzw.
Gedanken, wieso?, weshalb?, warum?), Einordnung in ein Genre (Old-,
Middle-, Newschool), Feature List, New-Feature List und wenn ich sage neue
Features, meine ich neue Features und nicht "neue" Features.
7. Events: Chaos war gestern!
Bereits bevor dein Server startet solltest du dir einen Plan für den Umgang
mit jeglicher Art von Events zugelegt haben. Ich werde dir nun einmal
erklären, wie du Events optimal planst, vorbereitest und durchführst. Vergiss
bitte nicht, dass ich hier eine Struktur etablieren möchte, wie in allen meinen
Punkten. Die Funktion dieser Struktur hängt von der Herangehensweise des
Serveradmins ab. Einem seriösen Server, der langfristigen und ernsthaften
Erfolg haben möchte rate ich dazu, die folgenden Strukturen einfach zu
übernehmen.
Events sind ein jeher Quell der Freude für alle Beteiligten, die einzige
Voraussetzung hierfür ist eine Struktur, die einem jeden Event die Möglichkeit
gibt, sich in den wirklich entscheidenden Aspekten (nämlich der Eventidee
selbst) von den anderen Serverevents abzuheben. Es ist daher umso besser,
dem Spieler eine Struktur zu vermitteln, an die er sich gewöhnen kann.
Strukturen erzeugen generell Sicherheit und Routine, somit auch ein gutes
Gefühl beim User, da er in einer alten Vorgehensweise mit neuen Ideen bzw.
Spielinhalten konfrontiert wird und sich somit komplett auf diese konzentrieren
kann. Die Strukturierung aller Events ist daher essenziell. Bei der Planung
eines Events ist es wichtig die "Eventidee" in einer geordneten Form
aufzunehmen. Hierzu empfiehlt sich ein vorgefertigtes Formular, welches jeder
Server individuell festlegen kann. Ich würde in mein Formular den Namen des
Events, den Durchführungstermin, die Eventdauer, den Bezug zur Storyline
(falls vorhanden), die Anzahl der benötigten Teamler zur Durchführung und
die benötigten Belohnungen aufführen. Hierbei gehe ich davon aus, das die
Belohnungen nicht von Game-Mastern ausgegeben werden können, ansonsten
entfällt der letzte Punkt. Diese Formulare sind bei der Eventidee eines
Teamlers auszufüllen und werden bei der jeweils nächsten Teambesprechung
vorgelegt und von einem hochrangigen Teamler (CoMa, SA) begutachtet und
angenommen oder abgelehnt (sollte es einen Event Manager im Team geben,
entscheidet dieser innerhalb von X Tagen über die Zulässigkeit des Events).
Das Event wird nun bei der Zulassung vom Event Manager (falls vorhanden)
oder Community Manager angekündigt, hierzu wird im Forum ein NEUER
Thread eröffnet, in dem alle wichtigen Informationen aus dem "Formular"
aufgeführt werden. Die Ankündigung sollte mindestens eine Woche vor der
Durchführung veröffentlicht werden. Die Vorbereitung für das Event wird
Infolge dessen vom beantragenden Teamler (falls kein Event Manager
vorhanden ist) ausgeführt. Hierbei geht es darum sicherzustellen, dass alle
notwendigen Ressourcen vorhanden sind und alle zugewiesenen Teamler über
das Event informiert und zugesagt haben. Alle beteiligten Teamler bekommen
das bereits beschriebene Formular zugesendet, auf denen ihnen alle nötigen
Informationen zur Verfügung stehen. Nun kann das Event durchgeführt
werden. Alle beteiligten Teamler sollten sich 30 Minuten vor dem Start im
Teamspeak/Skype einfinden und während der Progression des Events jeglicher
irrelevanter Konversation entsagen. Sollten alle beteiligten Teamler
rechtzeitig anwesend sein startet das Event. Sollte ein Teamler fehlen ist
dieser Vorfall bei der nächsten Teambesprechung den höherrangigen Teamlern
zu melden. Sofern der Platz des abwesenden Teammitglieds nicht gefüllt
werden kann wird das Event nicht stattfinden. Findet das Event statt,
werden nach Ablauf der Eventdauer die Belohnungen verteilt. Im Anschluss an
das Event besteht die Aufgabe des veranstaltenden Teamlers (bzw. Event
Managers, falls vorhanden) in der Nachbereitung des Events. Er verfasst eine
private Nachricht an den Community Manager in der er folgende Daten
erfasst: Eventname, beteiligte Teamler, Anzahl der Teilnehmer (falls
erfassbar) und siegreiche Spieler mit ihren jeweiligen Belohnungen. Der
Community Manager hat nun die Aufgabe einen (wahlweise illustrierten)
Bericht zum Event zu verfassen und die genannten Informationen in diesem
Bericht unterzubringen.
Zusammengefasst:
Events sollten stets strukturiert werden. Man sollte ein Event mithilfe eines
Formulars planen. Das Formular sollte den Namen des Events, den
Durchführungstermin, die Eventdauer, den Bezug zur Storyline (falls
vorhanden), die Anzahl der benötigten Teamler zur Durchführung und die
benötigten Belohnungen enthalten. Es ist dem CoMa, SA oder Event Manager
vorzulegen. Sollte das Event "bewilligt" werden, ist der Ideenhaber (falls kein
Event Manager vorhanden ist) für die Organisation zuständig. Das Event
sollte vom CoMa mindestens eine Woche vor der Durchführung im Forum
angekündigt werden, hierzu sollte ein extra Thread eröffnet werden. Alle
Teamler müssen 30 Minuten vor Eventbeginn anwesend sein. Nach Abschluss
des Events wird ein Formular mit Eventname, beteiligte Teamler, Anzahl der
Teilnehmer (falls erfassbar) und siegreiche Spieler mit ihren jeweiligen
Belohnungen an den Community Manager gesendet. Der Community Manager
verfasst in der Nachbereitung des Events einen (wahlweise) illustrierten
Bericht und erwähnt diese Informationen darin.
8. Teamlersuche: Repräsentanten deines Projektes
Die Suche geeigneter Teamler ist eine meistens sehr zeitaufwändige Aufgabe.
Es bietet sich an, eine Stellenbeschreibung in Elitepvpers zu publizieren, um
möglichst schnell geeignete Kandidaten zu finden. Ihr solltet bei eurer
Stellenbeschreibung zuerst einen allgemeinen Einblick in euren Server geben,
hierbei sprecht ihr eure Motivation und eure Ziele an. Im Folgenden solltest
du die Haupttätigkeiten des Jobs innerhalb eures Projekts voraussagen. Im
Anschluss daran sprichst du die Qualifikationen, die ein Bewerber mitbringen
muss an, um in einem kleinen Ausblick und einer Kontaktmöglichkeit zu enden.
Infolge dieser Ausschreibung sollten sich einige Bewerber bei dir melden, nun
liegt es an dir bei jedem einzelnen ein Bewerbungsgespräch zu führen. Hierbei
ist es ratsam, auf die Aussprache und Referenzenliste besonderen Wert zu
legen. Die Artikulation eines Teamlers ist ein großer Faktor bei der
Zusammenstellung eines qualifizierten Teams. Die Referenzen eines neuen
Teammitglieds sollten im Idealfall für sich selbst sprechen, sollte das nicht der
Fall sein, hast du die Möglichkeit in geringem Maße Hilfestellung zu leisten und
deinen Teamler um die Ausführung seiner Referenzenliste (falls nötig) zu
bitten. Ein Teamler, der "auf den Mund gefallen" ist hilft in den meisten Fällen
nicht weiter, denn in unserer aktuellen Welt ist es notwendig zumindest über
ein Chatprogramm qualitativ hochwertigen Support bieten zu können. Solltest
du nach dem Bewerbungsgespräch zufrieden mit dem Bewerber sein, kannst
du ihn über deinen eigenen Werdegang und vor allem den Werdegang deines
Projekts aufklären, wenn danach der Wissensdurst beider Parteien gestillt ist,
kann dein Team ein neues Mitglied willkommen heißen.
Die Rechteverwaltung innerhalb eines Servers wirft bei einigen Servern
kritische Fragen auf. Es ist nahezu an der Tagesordnung, dass Vorwürfe
gegenüber dem Team laut werden, da der Teamler X gepusht haben soll.
Sollte sich dieser Vorwurf bestätigen stellt sich die Frage, wieso der
Serveradmin keine zukunftsorientierte bzw. vorausschauende Rechteverteilung
etabliert hat. Es ist absolut ineffizient, seinen Game-Master Itemrechte
zuzusprechen, hierfür gibt es keinen einzigen logischen Grund, welcher bei
ausführlicher Überlegung und seriöser Grundeinstellung als standfest
bezeichnet werden kann. Ich möchte darauf hinweisen, dass die Realisierung
aller Arten von Events mithilfe dieses Guides ohne die Vergabe von
Itemrechten an IRGENDEINE Instanz innerhalb des Teams möglich ist. Die
offensichtliche Frage "Wieso tut das denn keiner, wenn es so einfach ist?"
lässt sich mit der Faulheit bzw. dem mangelnden Interesse der Serverführung
in einer essenziellen Kategorie des Servermanagements begründen. Ich
möchte daher darauf hinweisen, dass Itemrechte ausschließlich an
hochrangige Teamler bzw. das Head-Team zu vergeben sind. Um extra sicher
zu gehen kann man die Erstellung von Items (für Events, Erstattungen o.ä.)
per Datenbank regeln.
Ein weiteres Defizit besteht meiner Meinung nach in der Rechteverteilung
innerhalb des Forums eines jeden Servers. Es ist absolut nicht angebracht,
dass Techniker oder Game-Master bspw. Events ankündigen. Diese Aufgabe
sollte dem Community Manager, Board Admin oder Event Manager zukommen.
Es sollten ebenfalls keine Teamler außerhalb des Head-Teams die Möglichkeit
haben, einen Post innerhalb der "offiziellen" Sektion des Forums zu verfassen.
Generell sollten alle Ankündigungen im Bezug auf die Community, sowie
Berichte / Patchnotes vom Community Manager verfasst werden, generelle
Informationen welche als serverübergreifend angesehen werden können fallen
in die Zuständigkeit des Serveradmins, Wartungsarbeiten in die eines
Technikers.
Die Entlohnung der Teamler hängt in jedem Fall von dem beigesteuerten
Aufwand an das Projekt ab. Es ist ratsam Techniker mit einem Prozentsatz an
den Servereinnahmen zu beteiligen. Die Game und Foren Teams sollten
hingegen einen Fixbetrag als Entlohnung erhalten. Diese Aufteilung ist mithilfe
einer logischen Betrachtung eines Projektes zu rechtfertigen. Die Arbeit eines
Technikers ist dauerhaft am Erfolg des Servers beteiligt, daher steht ihm ein
prozentualer Anteil am Servergewinn und Servererfolg zu. Es liegt am Admin,
diesen Anteil zu bemessen und dementsprechend die prozentuale Auszahlung
vorzunehmen. Bei einem Teamler des Foren- oder Game-Teams ist der
Aufwand inform eines Fixbetrages auszuzahlen. Man kann den Support in
Bezug zu einem Beruf im Einzelhandel setzen, solange die Teamler arbeiten,
werden sie mit einem fixen Lohn ausgezahlt, da sie jedoch keinen
gravierenden Anteil am Erfolg des Servers haben und anhand ihrer Arbeit
bemessen werden, sollte die Leistung von Bonuszahlungen hier keine
Seltenheit sein.
Zusammengefasst:
Achte bei deiner Stellenbeschreibung auf eine gute Strukturierung, bei der
sich ein Bewerber besonders angesprochen fühlt. Bei einem
Bewerbungsgespräch ist es wichtig, dass der Bewerber Eigeninitiative ergreift.
Es sollte sich desweiteren von selbst verstehen, dass ein Teamler versiert im
Umgang mit der deutschen Sprache sein sollte und sich in der Materie zu
beweisen weiß.
Zieht klare Linien, wenn es um die Rechteverteilung innerhalb eures Projektes
geht. Itemrechte sind Ingame nicht nötig, sie sollten maximal an
Head-Teamler vergeben werden. Im Forum sollten Teammitglieder außerhalb
des Head-Teams keine Beiträge innerhalb der "offiziellen" Sektion schreiben.
Generell sollten alle Ankündigungen im Bezug auf die Community, sowie
Berichte / Patchnotes vom Community Manager verfasst werden, generelle
Informationen welche als serverübergreifend angesehen werden können fallen
in die Zuständigkeit des Serveradmins, Wartungsarbeiten in die eines
Technikers.
Die Entlohnung der Teamler sollte anhand ihrer Leistungen am Gesamtwerk
bemessen werden. Techniker und andere wichtige Teamler sollten prozentual
am Gewinn beteiligt sein, Foren- und Game-Teamler mit einem Fixbetrag
ausgezahlt werden.
9. Networks: "homemade Networks" at its finest
Ein Network aufzubauen, davon träumt wahrscheinlich ein jeder Serveradmin.
Zuerst einmal möchte ich darauf hinweisen, dass der Begriff "Network" in
unserem Milieu den Zusammenschluss mehrerer Server bezeichnet, welche
sich dabei (meistens) mindestens eine Enterpage teilen, meistens auch ihre
Votes "in einen Topf werfen" um dabei größtmöglichen Erfolg für alle
beteiligten Projekte gewährleisten zu können.
Ein Network bzw. ein Zusammenschluss mehrerer Server unter einem Banner /
Brand ist nicht immer einfach und sollte vorher gut durchdacht werden. Es
gibt einige Voraussetzungen die von allen beteiligten Projekten mitgebracht
werden müssen. Als eine der zahlreichen Möglichkeiten möchte ich zuerst den
gemeinsamen Grundgedanken anführen, bzw. dieselbe Herangehensweise. Ein
weiterer Grund kann in der Harmonie der einzelnen Teamler bestehen,
ergänzen sich die Teamstrukturen der beteiligten Projekte optimal, ist eine
Zusammenarbeit allein deswegen schon sehr vorteilhaft. Es kann allerdings
auch zu einem Zusammenschluss aufgrund reiner "Profitgier" kommen, dabei
geht es hauptsächlich um den Zusammenschluss der beiden
"Servervotetöpfe" und damit das erreichen einer höheren Position innerhalb
der Topliste. Bei solchen Zusammenschlüssen haben die einzelnen Server
meist keine Überschneidungen in ihren Teamstrukturen oder im
Grundgedanken bzw. ihrer Herangehensweise. Die seltenste Form eines
Networks besteht in dem eigentlichen Ausbau eines eigenen Projektes in
einen multi-nationalen Server oder ein internationales Brand, welches sich mit
mehreren unterschiedlichen Serverkonzepten innerhalb der Szene etabliert
und eine eigene Marke kreiert. Das "homemade Network" ist hierbei das
profitabelste und anspruchsvollste zugleich. Ich werde mich in meinem
weiteren Beitrag auf das "homemade Network" beziehen, da ich gewisse
Grundstrukturen anhand dieser Netzwerkstruktur und dieses Umfeldes
erläutern möchte.
Innerhalb eines "homemade Networks" müssen alle innerhalb dieses Guides
angewandten Techniken in Perfektion ausgeübt werden. Der Schritt von
einem eigenen Server zu einem eigenen Network bringt viel Stress mit sich
und sollte nur bei der nahezu vollständigen Optimierung/Fertigstellung vom
Server 1 in Angriff genommen werden. Es ist hierbei besonders wichtig, dass
ein eingespieltes Team für die Serverleitung, die Technik und den Support auf
dem ersten Server eingesetzt ist und diesen Server durch mögliche
Schwierigkeiten zu navigieren. Erreicht ein Projekt den "Network Status", wird
der Serveradmin meist in den Rang des Network Admins erhoben, es gibt
jedoch auch hier Ausnahmen, welche bspw. in Serveradmins besteht, welche
weiterhin ihren Server managen wollen und sich daher nicht so "weit" von
ihrer komfortablen Zone entfernen möchten. In solchen seltenen Fällen wird
der Posten des Network Admins meistens an den Community Manager oder
den leitenden Techniker übertragen. Sollte der Serveradmin jedoch den
Status des Network Admins erreichen wollen, wird an seiner Stelle der
Head-Techniker den Server leiten. Das Foren- und Technik- Team werden für
beide Server übernommen, hierbei werden Teamler nicht selten befördert und
neue Teammitglieder eingestellt. Der Community Manager erweitert seinen
Aufgabenbereich innerhalb dieses Stadiums um die Verwaltung des Teams und
die Teamleitung. Er sollte gemeinsam mit dem Network Admin den Ton
angeben und das Team auswählen und auf die neuen Aufgabenbereiche
vorbereiten, sowie "einschwören". Sollten diese Grundsteine gelegt sein, kann
sich die Teamleitung auf die Verteilung der neuen und vorhandenen Ressourcen
konzentrieren. Der 2. Server des Brands kann nun in die Entwicklungsphase
eintreten und wird bis zu seiner Vollendung nicht der Öffentlichkeit
vorgestellt. Bei erfolgreicher Fertigstellung des 2. Servers können empfehle
ich, einige der hier vorgestellten Unterpunkte erneut zu beachten und eine
Promotionsphase (mit oder ohne Preview) einzuleiten.
Die Integration des 2. Servers ins Konzept des 1. sollte möglichst
unterschwellig ablaufen. Der Server muss nicht zwangsläufig ein eigenes
Homepage-Design haben, allerdings bietet sich eine Art "Style selection"
innerhalb des CMS an, welches dem Spieler je nach präferiertem Server die
Möglichkeit gibt, zwischen mehreren Homepage-Designs zu wechseln. Eine
ähnliche Vorgehensweise kann innerhalb des Clienten angegangen werden,
dabei könnte sich das Client-Design serverspezifisch ändern um klare
Kontraste zu setzen. Die Foren der beiden Server müssen ebenfalls nicht
zwangsläufig getrennt werden. Generell sind in allen Design-Fragen sehr viele
Entscheidungen zu treffen, wobei die Kunst darin besteht, die Gunst des
Benutzers nicht zu überstrapazieren. Je reibungsloser die Integration in den
Regelbetrieb läuft, desto besser wird sich der neue Server bei den Benutzern
etablieren und langfristigen Erfolg garantieren können.
Zusammengefasst:
Der Begriff "Network" beschreibt in unserem Milieu den Zusammenschluss
mehrerer Server, welche sich dabei (meistens) mindestens eine Enterpage
teilen und/oder auch ihre Votes "in einen Topf werfen" um dabei
größtmöglichen Erfolg für alle beteiligten Projekte gewährleisten zu können.
Networks können aus unterschiedlichen Gründen entstehen, dabei möchte ich
vorallem Harmonie, Profitgier und Branding anführen.
Ein "homemade Network" definiert sich durch strikte Teamstrukturen und
trainierte Abläufe. Der Selbsterhalt des 1. Servers sollte gesichert sein, bevor
ein 2. Server in die Entwicklungsphase eintritt.
Es gibt viele Design-Fragen, die bei einem solchen
Zusammenschluss beantwortet werden müssen. Je reibungsloser die
Integration des 2 Servers in den Regelbetrieb läuft, desto besser wird er
aufgenommen werden.
English version
Welcome,
this thread is supposed to be a guide that is going to tell you everything
about structures, routines and plans to correctly manage your server. I
will also talk about public relations and the marketing aspects of running
a metin2 private server which forces me to use some simple psychological
principles and basics which I will be using to explain why I am suggesting
the things I do and ensure that you're able to understand my point of view
as good as possible. I would love everyone of you to comment my guide
and discuss the points I am bringing up by telling me your own opinion
about those topics even if you don't agree with me on my own views. I
hope you will enjoy reading my guide and would love to see you using my
tips and tricks in the future.
Content of this guide
Introduction - Who I am and why you should listen to me
Hello,
my name is Justice, Community Manager of a server that will be released
in several months and today I will be writing about a topic that is a little bit
different compared to the ones who are frequently posted on this forum. I
am thinking about things that most other people might not think about
because they have neither got the possibility nor the time to do that. You
might ask yourself who I am and what enables me to talk about the current
state of our community. For several reasons I am only able to answer your
question indirectly without telling my Name and hinting my past. I am part
of the Metin2 section for 5 years now. The description "part of" is actually
not fitting my case in this regard because I willingly decided to not be in the
spotlight at any given time in the past. I worked with many known
personalities of this section and was already part of many projects while
being a teenager.
Since many people asked me about the projects I worked on I have to
adress this question as good as possible. I will not name the projects I
worked on because I find those names irrelevant for the content of this
thread. I was never known as Justice in those past projects. Everyone
who wants to know about my projects might just take a look at my signature.
The servers I worked for were online for an average of six to ten months.
In the past years I took part in 9 projects, six of them were relevant in
regard to their placement on the toplist. I thought about the past four years
and decided to write this guide which includes my experiences while working
on many TOP projects. Two of those projects have been rank one on the
toplist in the long term (in a time where there was not vote pushing), another
project maintained the 3rd spot. Therefore I think I am more than qualified to write a guide like this. Less about me, more about the content of this
guide.
1st The correct mindset: community (miss-)management inside of the m2 section
Our general discussion consists of technical progress, I will only write about
methods and optimizing processes to give you a better idea how to think
about certain problems and solving them as fast and as good as possible.
In this sense we will not be talking about the mechanical techniques because I
want to focus on the general mindset who is essential in regards to properly
managing your server. First of all I want to talk about a very common mistake:
the inefficient distribution of workspaces inside of the team. Surely you witnessed
it yourself many times.. you are visiting the website of a server (in this case the
forum) and enter the news section. Afterwards you try to find certain information
while you get angrier and angrier. What I want to address here is the
"Kindergarden-Professionality" that many metin2 servers seem to maintain. If you
would ask a User whether or not they have noticed the teams behavior they
would most likely say "No, why are you asking that question? Everything is just
as usual." I am telling you that is NOT the case. This example only verifies the
daily farce of the section. In the meantime users accepted the unexceptional
standards in terms of Community Management and therefore never thought
about it that way. To explain the users behavior psychologically I would like to
continue with a metaphor of a fish inside of an aquarium. The fish swims inside
of the aquarium day after day because that is the world he knows and that's
enough for him as long as he survives. What I want to point out here is that the
fish is not even considering the possibility of another environment outside of the
aquarium. That is totally fine because humans should maximize their benefit of
any situation that is thrown at them. In terms of Community Management I am
telling you that NOBODY of the currently "well known" Server respects its users
and behaves properly. Some people might tend to address my statement with
an agressive answer and get angry at the very same moment. If you are one of
those people you have not understood the analogy I just made which contained
the fish in his aquarium. I am not telling you something to judge you or anyone
else, I am trying to explain my train of thought. The reason for server x not
responding to their community in a proper fashion is not the servers or its teams
fault, it is the fault of the very low level pole we of this section and very low
expectations in regard to the community management of any server. Nowadays
it is not something extraordinary if you see a server not having his very own
board or a board with a small amount of active users. I am asking myself what
the reason for that might be. The reason is pretty simple, the visit of the servers
board is simply not rewarding enough to be considered necessary by most of the
actual user base. The level pole has fallen so drastically that users are simply not
willing to use every resource of information available.
The question you should be asking yourself right now might be "how to solve a
problem which has not existed a couple of minutes ago?"
To find an answer to your question you should ask yourself whether your server
and the brand it represents tries to be as good as it possibly can. By saying
"being as good as it possibly can" I am thinking of the maximum user count AND
volume of sales. You could also call it "reaching your full potential". To reach the
maximum potential you can start by structure your team properly (e.g. by not
forcing your Game-Masters to do the job of your moderators). There is also no
reason to activate the comment-function of your Server-News forum for
"normal" team-members. Let us take this thought a little further. If a Game-
Master comments an event-thread he effectively wastes time he could be
spending in-game or inside of another thread supporting a player. It's way better
to draw a line from the very beginning by avoiding this behaviour. The only
person who should be announcing an event and report about its outcome is the
community manager. The only person who should inform players about
maintenance operations is a technician. The only person who should be
announcing general changes (e.g. patches) is the administrator.
2nd Beta-Phases: stop lying to yourselves!
Let us analyze the typical scenario which is pretty common nowadays. The
admin of server X has build-up a team and told his mates about the concept of
his project. We assume the team is capable of actualizing the administrators
ideas. In this timeframe there are different stages of progress starting with "non
existing" and ending with "beta-ready". I will talk about this "beta" status in this
paragraph. We have seen so many servers (who have had acceptable and new
ideas) starting their beta while not having finished even the simplest of things.
By thinking "okay let's just get this over with" people are going public with their
projects to gain more and more money while telling themselves it is only a
"testing-phase". All of a sudden offers become available in the item-shop and
as time passes the beta becomes the version 1.0 because the administration
realizes how much money the server already bucks off while forgetting about
the actual concept of their server. Let us get back to our scenario in which
server X has managed to maintain an income of 1500€(can be replaced by a
value of your choice that you consider large) after the first few days of their
"beta". Now the administrator thinks about many more ways to give his users
the ability to spend their money (e.g. "lucrative" limited time offers, payment
events with bonus coins). At this point I want to mention that the server still
has "beta" status but nobody thinks about that anymore. After a short period
of time the desired amount of momey is collected and the earnings are
starting to die away. Ironically the server administrator does not know why
that happens no matter how much he thinks about a solution to his problem.
What he totally forgot is his concept and the vision he had while creating his
server and what it has finally become. Even if the server had a good beta most
of the time someone has already copied its concept and managed to set a new
standard. How to avoid this scenario might be your question now. Well, my
answer is the following:
Stop lying to yourselves!
If you really want to test the concept of your server TEST IT. The problem
consists of the word "beta" being used inflationary which means every IDIOT
thinks about starting a so called "beta". Many people forget about fixing bugs
or dealing with any other meaningful problem because they are busy selling
their project to its users. There are many possibilities to avoid this scenario for
example you could skip the beta or you disable the item-shop and every other
profit-making aspect while testing. It probably sounds hard, almost unfair but
it is not. The essential thing is YOU want the server to be tested NOT the user.
Your user base helps you voluntarily, you should not take advantage of their
very kind behavior!
3rd Preparation: generating a hype
The official launch of your server is probably one of the most important parts.
Everyone has experienced hyped-up projects failing by not being able to survive
both parts I mentioned before. You should try to think about what they did well.
They generated a hype which caused many users to give their project a try. The
question you should be asking yourself now is "How to generate a hype?". To
explain how that works I will be going back to our example in which server X has
skipped the beta and directly launched. It's important to think about the outside
world to understand what I will be suggesting now. You have to advertise your
project to sell it properly. There is a basic principle which tells you what you
have to do:
Invest first - cash up later
You are paying up-front to create a professional and lucrative image. You should
not compromise at any given point because your users are going to feel
whether or not you've spent money or not. How often have we seen server
presentations looking as if they have been created in about 2 hours tops? Way
to often! There are so many capable designers in our section. Why not spend
50-100€ for a proper presentation? I know it's hard to invest money up-front
but that's how this business works. I can guarantee that you can't spend your
money at a better place and you will be earning two or three times as much
money as if you wouldn't spend it on a good presentation. Now we got a proper
presentation in our scenario. Server X has spent let us say 75€ on that. They
are also buying a trailer for 50€. They have spent 125€ so far. I would call the
amount of money I just mentioned the budget for a server of the upper standard
caliber but that's not enough to create a hype. You could release your server at
this stage. Maybe it would succeed but the possibikity of landing a lucky-punch is
not as high. That is why we want to generate a hype by using proportional
growth. The funny thing about metin2 private servers is the more money you
are willing to pay for publicity (videos, trailers, toplists) the more users will find
their way to you to have a look at what you managed create. If your concept
is good your server will most likely be VERY successful.
4th The serverstart: that is what you should watch out for
The server is about to start. If you have had a good beta and found many bugs
it's time to give the community the opportunity to play your server aswell.
After generating a hype via promoting your server(for at least one week) many
players are waiting to play and invest their money. You should try to release at
the release date you announced in your board (and of course every other
important forum). It's in your interest to make sure EVERYONE of your team-
members is online and grouped on your servers teamspeak server because,
- it strengthens your team spirit
- it looks like a solid image to the outside world
These two very simple rules automatically make sure the acceptance of your
community is as high as it can be which will force them to give you your very
first positive feedback. The hype is going to be extended a little (or might at
least stay at its current level). Now it is all about establishing working routines,
optimizing process flows and automating trouble-shooting. It is not about you
trying to do as much or even more than before. You just have to find a
constant work-flow and you will be rewarded directly by the players from now
on, but that is where most projects fail. It is totally fine to start a server with a
standard concept as long as your team is better than the team of the other
"standard" servers. Players will automatically choose the server with a solid
team spirit over the many servers who fail at creating a healthy staff
environment because you feel the difference even as a User. After starting the
server, its in-game and forum team will be constantly under pressure. Please
make sure your working environment is set-up correctly and simplifies fulfilling
your teams duties. In the first couple of minutes it is also extremely important
to emanate a structured mindset. Users will be begging for an event but you
shall not fall for that bait as easily. I don't want to tell you events are a no-go
(actually the opposite) but it is in your interest to be professional. Use event
concepts whom you have created pre-start. Announce multiple events in your
forums but be careful: "every event should be announced AT LEAST one week
before its start." You might ask yourself why the user has to wait for his event
an entire week. The answer to your question is announcing an event pre-start
to make sure the event starts when your server launches and still be able to
maintain the 7-days-rule. A well organized event is very useful but I will be
discussing the best way to make an event happen in a different paragraph.
Another very popular thought is the process of fixing bugs. Your team will be
receiving many bug reports in the first few hours. It is very important that you
DO NOT try to fix them all immediately to make sure you can focus on the
most important ones first and "clean-up" the messy ones at a later point in
time. You should have fixed every game-breaking bug in your beta which allows
you to hold on to your structure and work through those small bugs one at a
time. If the community should be finding any game-breaking bug it is your and
your technicians priority to fix those as fast as possible. It is also important to
announce maintenance as soon as possible. You should also try to maintain the
7-days-rule here. A maintenance is needed to implement small bug fixes,
spelling mistakes and adapt shop prices (for example). Every maintenance
should be having its very own patch-notes in an EXTRA thread. The separation
of events and maintenance is essential of course. It is possible to use one
thread as an archive but your should be trying to act as user-friendly as possible
by making it very clear where to gather crutial information even if that means
you have to do a little bit more in exchange.
5th Establishment: how your server is going to stay trendy
Some projects try to equalize long-term entertainment and a high maximum
level, I am trying to ban these "pieces of wisdom" out of our vocabulary. It is all
about making sure the your community stays entertained to maintain a good
user-rating. I want to share a very effective method with you to ensure that you
keep your users ratings up high: Game-Updates. No I am not talking about your
weekly patches. I am defining updates as additional content which will be
unlocked by the user at a certain point in time. As an example I would take 2 new
End-Game Runs which will be expanding the storyline (if existent) and are going to
give your users the opportunity to unlock a run-exclusive item. Whether this item
is a pet, an armor or a mount is irrelevant. The long-term entertainment is way
higher than before. Of course this method is pretty easy to implement and does
not enforce such a great effort. The important thing about this method is the fixed
date of implementation. Game-Updates are necessary if you want to stay at the
top. An update should be all about new features, game-breaking. A game-update
should be released within a month. To represent your server to the outside world
it is important to make sure you promote your game-updates properly. You
should be starting to plan your first game-update even before you launch to make
sure everyone knows how to use their spare-time. You can record the new
features with a YouTuber of your choice and let a small amount of users and your
team test the new content before publishing it. Every player will be destined to
test the new systems and runs before everyone else. You should be promoting
the update in your forums as well and ask your designer to create some new
images to hype up your server again. Your players will be thanksful for those
mechanics and support you and your project even more.
6. Previews: Structure from the very beginning
As an up and coming server administrator you can decide whether you want to
start a server preview or not. I want to help you with your decision making
process while explaining the ground rules for a well-done and strategically smart
preview.
To be honest a preview is ALWAYS a good thing. You enable your audience to
give you constructive and worthy feedback while developing your project. You
should take into account that your preview is best seated when properly released
as an element of your promotion-phase. The place that suits your preview best is
at the very beginning of your promotion-phase to enable every potential player to
take a first look at your work therefore your preview could also be described as a
development-diary. Even though it is supposed to be your development diary you
have to remember to only include the milestone accomplishments when you have
finished working on them. The reasoning behind this very basic principle is pretty
simple: nobody cares about the negative stuff that is happening inside and around
your team-environment. It might be harsh to say but I can assure you that negativity
will most likely damage the customer's view on your project in the long-term. I want
to recommend a release-plan which is going to incorporate the dates on which you
will release new information about every single feature you want to share with your
community. This way transparency can be established from the very beginning and
you can make sure your customers are able to fully trust you and your team from
the start. Last but not least I want to mention that you should release your preview-
thread only if you have finished working on it and if it includes every detail about your
server that you want to give away. Double-check your words!
At the start of your preview you are supposed to promote your concept. I do not
speak of "old-,middle-,newschool". I am talking about a detailed conceptional plan
which can also be a large text explaining your thoughts, goals and plans behind the
things you built in for your community. Do you see where this is going? Yes, that's
right - transparency. You allow the player to fully trust your work and assure him
that you have planned and thought about the stuff that you are doing and leave
nothing to chance. The next step contains your description of your features and
afterwards the preview of your new and never seen features. You have to be honest
to yourself at this point because unless a features really is new and has never been
seen on any other server to this day you should not describe it as such a feature.
You should only describe features as new and as unique if idea really has been your,
otherwise well-established players are going to spot your betrayal and punish you
for your naivity.
Tl;dr:
A preview should be placed before you start promoting your project. You should
look at it as a development-diary which differs in the fact that you should have
finished your work on everything you share with your community. You should publish
your preview as soon as you have finished working on your server (right before the
beta/server start). The Preview excels when containing a release-plan which
announces every feature and it's preview-date. Previews should also contain :
conceptional work (FAQ, thoughts, why?, what for?), genre-classification (old-,
middle-, newschool), feature-list, new-feature-list.
Server, die diesen Guide als Leitfaden benutzen | Servers using this guide as a baseline
Vielen Dank für's Lesen! | Thanks for the read!
Justice
