Ein eigenes Projekt | PHP

[mintmaroo]

Hallo liebe Community,

ich suche einen oder zwei Mitstreiter, mit dem ich ein "kleines Browsergame" ins Leben rufen will.

Das Spiel sollte in PHP und Javascript geschrieben sein und weil es für Anfänger ist, nur begrenzte Funktionen haben.

Ich dachte da an folgendes:

Login, Registrieren, Profil, "Kampagne" und ein kleines Shopsystem.

Wer hätte Lust da unentgeldlich mitzumachen? Sende mir bitte eine private PN. 

Der Umfang kann hier diskutiert werden, bei Fragen.

 

 

Grüße.

[Chiyoko]

Eventuell wären etwas mehr Hintergrundinformationen wünschenswert.

Wer bist du? Wie viel Erfahrung hast du mit den verwendeten Technologien? Wie viele solcher Projekte hast du schon gemacht? Ist es eine spontane Idee wie "ach, das wär lustig, das zu programmieren", oder hast du schon ein Konzept ausgearbeitet? Wie weit bist du schon? Was steht? Was soll noch kommen?

Ich denke, mit etwas mehr Infos hättest du größere Chancen auf Erfolg.

 

[sas86ks]

Aufgrund diesem Threads denke ich mal, dass er noch eher in der Anfangsphase ist.

Wenn du jemanden für Code Reviews o.ä. brauchst, kannst du mir gerne eine Nachricht dalassen, wenn du das ganze auch ernsthaft angehen magst.

[Whiz-zarD]

Ich weiß auch nicht, was für ein Spiel das werden soll aber ich bezweifel, dass du nur mit JavaScript und PHP ein Browsergame hinbekommst. Im Hintergrund wird ja auch diverse Logik durchgeführt und die sollen ja nicht erst laufen, wenn der Spieler die Webseite aktualisiert und somit ein PHP-Skript anstößt, sondern die sollen ja von selbst angestoßen werden. 

Beispiel: Du entwickelst ein Aufbau-Strategie-Spiel ala Travian und der Spieler macht ein Upgrade auf eine Holzfällerhütte und die Hütte produziert dann 10 anstatt 5 Tonnen Holz. Das Upgrade dauert eine Stunde. Dann muss auf dem Server ein Programm laufen, was dann nach einer Stunde den Status in der Datenbank ändert, damit die Menge des produzierten Holzes auch korrekt berechnet werden kann. Das PHP-Skript kann jetzt schlecht eine Stunde warten, weil du damit den Webserver überlasten würdest, wenn da plötzlich Tausend PHP-Skripte in der Warteschleife liegen. Schon mal die Standardkonfiguration von PHP ist, dass ein Skript maximal nur ein paar Minuten laufen darf, bevor es abbricht.

[JimTheLion]

Könnte man schon mit PHP und JS machen. + Datenbank oder so noch.. je nachdem was das für ein Shopsystem ist^^ vielleicht ists ja nur eine CSV-Datei mit 5 verschiedenen Schwertern drin

(Schonmal zur Klärung, ich benutz ab jetzt die Wörter

Client -> für die Weboberfläche die der User zu sehen bekommt, von wo die Bauaufträge etc abgeschickt inkl. Datenverarbeitung auf dem Server für den entsprechenden Request

und

Server -> für die Anwendung die nur auf dem Server läuft und von der der User nichts mitbekommen soll, die für die periodischen Statusänderungen der Spielobjekte verantwortlich ist)

 

Das was man als Spieler auf der Seite anklickert wird als Bauauftrag in die Datenbank eingetragen. Dann ist der Client an dieser Stelle fertig.

Auf dem Server könnte man dann per Cron minütlich (glaube das war früher immer so die Tick-Rate fürs Werteupdate) nachsehen ob der Bauauftrag schon fertig ist und entsprechend den Wert für den Ressourcengewinn und den Status des Gebäudes ändern. Genauso kann man mit einem weiteren Aufruf immer die Ressourcen erhöhen die von anderen Gebäuden erwirtschaftet wurden.

So weit ist das kein Hexenwerk und das haben Leute auch schon vor 10 Jahren umgesetzt. (Es könte auch noch einen Cron geben der abfragt ob Angriffe durchgeführt wurden und deren Ergebnis ausrechnen... und keine Ahnung was Aufbau-Browsergames sonst noch so können)

Könnte auch sein, dass ein Nodejs Daemon besser geeignet ist das auszuführen, kA. Müsste man sehen was sich besser macht und ob man ein bisschen node lernen will.

Am Ende gehts ja nur darum in regelmäßigen Abständen Werte zu aktualisieren. Für den Client muss man dann nur den aktuellen Status der Gebäude, der Ressourcen und einkommender + ausgehender Angriffe abfragen und hübsch darstellen. Vielleicht könnte der Server auch regelmäßig einen Cache aktualisieren aus dem der Client dann die Werte bezieht, damit könnte der Client sich das Mapping von Datenbankdaten zu Datenstrukturen sparen (Ich geh jetzt einfach mal von einem rdbms aus).

 

Wie schon angedeutet wären Client und Server bei mir getrennte Anwendungen die auf die gleiche(n) Datenbank(en)/Quelle(n) zugreifen. Das hätte dann ein paar Vorteile

- während man im Frontend hübsche URLs, Templateengines usw. haben will kann man im Backend so minimal wie möglich arbeiten um nicht schon im Bootstrap-Prozess Zeit zu verschwenden indem man erst entscheiden muss ob man Paket xyz initialisieren muss oder nicht.

Z.B könnte man eine Framework-Kombo aus Symfony für den Client und Silex als ballastlosen Server einsetzen

- man kann für beide Anwendungen entsprechend die Einstellung setzen, die Aufrufe des Backends sind aufwendiger, deshalb kann man hier schon die maximale Laufzeit erhöhen und je nachdem auch mehr Speicher freigeben (Die Trennung der Konfiguration ist eh schon gegeben, Konfig für Webserver und Konsole sind in verschiedenen Dateien).

- man kann für beide Anwendungen gezielt Helfer suchen. Du könntest aus dem Client z.B. eine Single Page Webanwendung mit einem der fancy JavaScript Frameworks machen. Damit kannst du vielleicht Helfer anlocken die sich mit einem dieser Frameworks beschäftigen wollen.

- eigentlich generell die Unabhängigkeit von Server und Client voneinander. Vielleicht bekommst du ja so viele User, dass der Server irgendwann in C programmiert sein soll um noch Performance rauszukitzeln (überspitzt, don't hurt me)

 

Joa... das waren so meine Gedanken zum Thema Aufbau-Spiel. Ich glaube die meisten anderen Spiele sind eh einfacher umzusetzen.

Ich arbeite seit 4 Jahren in meiner Freizeit an einem, bei dem die Seite einfach eine Plattform für die Werte, Items usw. ist. Man erstellt seinen Charakter, stellt Training ein. Jeden Tag um Mitternacht läuft ein Update das die Werte entsprechend des Trainings erhöht. Dazu gibts dann noch so Community-Sachen wie Nachrichten verschicken und ähnliches.

Sowas ist ziemlich straight forward und man muss sich nicht ganz so viele Gedanken machen wie man die Daten jetzt am besten updatet. Es ist aber trotzdem ein Haufen Arbeit

Bearbeitet 18. April 2017 von PVoss

[Chiyoko]

vor 1 Stunde schrieb PVoss:

Ich arbeite seit 4 Jahren in meiner Freizeit an einem

Will sehen!  

[Whiz-zarD]

vor 57 Minuten schrieb PVoss:

- eigentlich generell die Unabhängigkeit von Server und Client voneinander. Vielleicht bekommst du ja so viele User, dass der Server irgendwann in C programmiert sein soll um noch Performance rauszukitzeln (überspitzt, don't hurt me)

Bevor ich hier irgendwas mit C anfange, würde ich auf Microservice Architekturen, Message Queues und Event Sourcing setzen, um die Anwendung skalierbar zu machen.  Nichts ist performanter als die parallele Verarbeitung und bei Browsergames kann man sehr gut Logiken parallelisieren.

[mintmaroo]

Über einen Code-Review von einem erfahrenden Programmierer würde ich mich sehr freuen.

Update mal den Eingangsbeitrag.

[mintmaroo]

Wie kann ich hier einen Beitrag editieren?

[Sullidor]

30 min lang nur. Solange gibt es dann unten einen Bearbeiten-Button

Bearbeitet 19. April 2017 von Sullidor
Editieren-Button war ein Bearbeiten-Button ^^