Handyversion von Freewar [W1-14]

[Cembon]

Wie wäre es den Lag nur einzubauen, wenn man nochmal das gleiche Item anwenden will?

[Sotrax]

@Cembon: Wie gesagt ich will den ja global haben, eben damit man nicht per Script ne Schutzauflösung, Hautbrand etc etc. alles auf einmal reinknallen kann. Das sorgt auch für mehr Strategie weil man sich durchaus überlegen muss, welche Zauber man anwendet und wieviele. Denn beliebig viele wird man nicht durchkriegen.

[Cembon]

Ich wäre dafür, den Zwangslag auf 0.4 s zu machen und nach dem 3. Item 0.7 s (evtl. 3. Item innerhalb von 3-5 s)

[itgchris]

mhm, die Diskussion war doch interessant, könnt ihr die nicht hier fortsetzen statt per PN :S

Das Problem ist eben dass man bei großen Datenbanken egal wie nicht schneller wird. Vllt. hat man kurzzeitig 50% Einsparung, aber dann nach ein paar Monaten wieder den alten Stand.

Sowieso glaube ich nicht dass es Sinn hat alles nach HipHop oder so zu kompilieren, denn das geht zu Lasten der Flexibilität… Und NoSQL bringt nicht viel mehr als MySQL, wenn ein anständiges DB-Layout existiert…

Das einzige was ich tatsächlich irgendwie vermisse ist ein layout ohne Frames… Was man da umgestalten könnte mit Styles… *träum*

Was ich nicht verstehe, ist dass da ein Problem sein sollte bei den Links?! zumal man ja $().onclick(function(){if($(this).attr("target")) $($(this).attr("target")).load($(this).attr("href"); else { var parents; do { parents = $(this).parent(); } while ($(parents).hasClass("frame")); $(parents).load($(this).attr("href"); }}) und so für die Links machen kann: alle auf einmal, da gibts dann nicht viel Links anzupassen; bei den Formularen kann man ja ähnliches machen. Ist meiner Meinung nach wirklich nicht für mehr als eine Woche Arbeit… Eine Woche nichts anderes ist ja verschmerzbar nehm ich an?

HipHop bringt nicht weniger Flexibilität eher mehr. Man braucht auch keine Zwingenden C++ Kentnisse, auch wenns eigl. immer gut ist welche zu haben.
Naja eine Woche ist relativ. Desweiteren sind die Lösungen 'unschön'. Aber das ist wieder was anderes. am sinnvollsten wäre ja REST oder SOAP. Somit könnte man genau lösen, ob der User nur JSON haben will oder eben STRG+Linksklick ne Art Seite.

@itgchris: Ich muss dir da (leider) widersprechen, in NodeJS läuft alles Javascript single threaded ab, nicht multithreaded. (Die asynchronen externen Calls zur DB etc. sind natürlich multithreded)

(siehe auch http://blog.mixu.net/2011/02/01/underst ... vent-loop/)

NodeJS ist zwar asynchron und z.B. aufrufe zur Datenbank laufen parallel zum Event-Loop ab, aber alles Javascript was in NodeJS ausgeführt wird, ist Single-Threaded und dazu noch atomar, wird also garantiert nicht unterbrochen.

Relativ. NodeJS kann eben geclustert werden was es MultiThreaded macht. Ähnlich wie PHP. Durch Nonblocking I/O auch kein Problem und weniger anfällig wie PHP. fork() ist sowieso eine sehr 'teure' Methode / Operation. Außerdem gibts schon Ideen das zu machen und man will auch NodeJS vollständig Multithreading fähig machen. Ideen gibts ja schon.

Das ist auch derzeit eine der größten Probleme von NodeJS, NodeJS selbst nutzt nur einen Kern der CPU. Wenn du irgendwo in NodeJS z.B. eine for-Schleife einbaust die 10 Sekunden braucht bis sie durchgelaufen ist, dann hängt der gesamte NodeJS Server für diese 10 Sekunden.

Das ist so falsch. wie gesagt Nonblocking I/O. Desweiteren, kommt das eben darauf an wie du programmierst. Klar kannst du das machen, dass dann der NodeJS Server hängt, dass ist dann aber schlechter Code. Wie gesagt ist dir aber eben auch schon der 'Event-Loop' aufgefallen. Bei NodeJS gibts eigl. auch ein sprichwort:

In node, everything runs in parallel, except your code

Deshalb macht man sich den Event-Loop zu nutze:

Hey, probablyExpensiveFunction(), please do your stuff, but I, the single Node.js thread, am not going to wait right here until you are finished, I will continue to execute the lines of code below you, so would you please take this callbackFunction() here and call it when you are finished doing your expensive stuff? Thanks!

Du hast übrigens auf den perfekten Blog hingewiesen um genau das zu lösen.

Außerdem hab ich ja schon geschrieben node.js ist nur ne Idee damit kennst du dich aus. Ich selbst mache eben das meiste mit C/C++ und auch schon Golang, außer wenn mehr als ein Team aus 5 Leuten daran arbeiten müssen, überlegen wir welche Sprache benutzt wird. Im Normalfall ist halt in unserem Anwendungsfall C/C++ und Golang relativ gut und auch Java sieht nicht schlecht aus. Golang macht einiges mit den goroutinen sehr sehr gut, somit kann man relativ guten Code für Websites schreiben, leider ist das eine sehr übersehene Sprache.

Genau dieses Verhalten hat man so in PHP nicht, wenn da ein PHP Script hängt, können die anderen einfach parallel dazu weiterlaufen. Man muss also Berechnungen in NodeJS derzeit möglichst auslagern und schauen, dass das Javascript sowenig Zeit wie nur möglich schluckt.

Dieses Problem kann man auch mit PHP erzeugen, nur ist es schwer. PHP 'erlaubt' dir Fehler. Und unter anderem macht auch genau das die Sprache schlecht, denn viel. ist der Fehler erwünscht. Es gibt da auch sehr gute Beispiele (ich nenne explizit mal eines) warum PHP fraktal schlechtes Design ist:
Der Code

Code: Alles auswählen

@fopen('http://example.com/not-existing-file', 'r');

Beispielsweise... Hat man PHP mit

--disable-url-fopen-wrapper

kompiliert, funktioniert es nicht, aber die Docs sagen nicht, was 'nicht funktionieren' bedeutet (null?, exception?) Naja wurde ja zum Glück nach PHP 5.2 entfernt.
- Wenn man

allow_url_fopen

in der php.ini disabled wird das ganze auch nicht funktionieren (wieso?!)
- Wegen dem

@

wird keine Warnung über eine nicht existierende Datei ausgegeben
- Es wird aber doch gemacht, wenn

scream.enabled

in der php.ini gesetzt ist
- aber wieder nicht wenn

error_reporting

level nicht gesetzt ist
- wohin es ausgegeben regelt

display_errors

in der php.ini oder

ini_set

.

PHP ist inkonsitenz.

Dieses Problem ist in NodeJS aber bekannt und es ist angedacht dass Webworker in Zukunft auch in NodeJS implementiert werden. Damit könnte man dann komplexere Javascript Algorithmen auch parallel in NodeJS durchführen.

Ja und Nein, es ist nicht zwingend ein Problem. Wie schon erwähnt. Es kann bei inkositenz eines werden.

Was die Schönheit der Sprachen anbelangt so kann man sich da sicher streiten. PHP kann extrem hässlich sein, muss es aber nicht. PHP hat durchaus auch bedeutende Sprachvorteile gegenüber Javascript (z.B. Type-Hinting, private Member in Klassen etc.). Klar hat man in PHP auch Konstrukte wie "Goto" aber das sollte man ja eh nicht einsetzen . Auch ist Remote-Profiling und Debugging in PHP derzeit noch leichter als in NodeJS, es gibt einfach viel mehr Tools für PHP.

Wie schon erwähnt, egal wie 'schönen' Code du schreibst, PHP ist und bleibt inkosistent und wenn ich jetzt alle Sachen aufzähle die PHP falsch macht nunja, dann wirds mies. Übrigens Debugging in PHP... Es gibt kein interaktives Debugging. Node.JS hat das.
Private Member gibt es in JavaScript du musst Sie einfach im Constructor angeben. Type-Hinting ist inkositent und vor allem ist PHP dadurch nicht type-safe. Zum Thema Klassen, PHP ist auch nicht streng typisiert somit kannst du auch nicht wirklich von Klassen sprechen, auch wenn es als solche dasteht.

Grundsätzliche Software-Design Pattern lassen sich in PHP genauso umsetzen wie in Java oder NodeJS.

Ja lassen sich, ist aber quatsch und man sollte PHP auch vermeiden. Es ist gut um in die Welt des Webprogrammierens einzusteigen. Und wurde eben eigl. auch genau dafür entwickelt. Ich würde selbst .NET hier hochloben, aber ich bin kein Fan davon, aber trotz allem machts einiges gutes.

Das Grundproblem von PHP ist, dass es enorm viel syntaktischen Zucker bietet und es zig Ansätze gibt, etwas zu lösen. Auch nerven mich Dinge in PHP wie dass die Sprache nicht Case-sensitive ist. Aber mit einem guten Editor ist PHP und Javascript halb so wild (PHPStorm rockt ).

Falsch. PHP ist Case-sensitive bzw. um es besser auszudrücken es ist beides. Variabeln sind Case-Sensitve, Functionen, Klassen und Methoden nicht. Also alles andere als nicht Case-sensitive irgendwo dazwischen halt. Es geht nicht darum ob du PHP gut beherscht oder einen guten Editor hast oder wie gut du als Programmierer bist, wie gesagt das Problem bist nicht du.

PHP wird auch in 5 Jahren noch die dominierende Sprache für dynamische Webseiten sein, prophezeie ich einfach mal. NodeJS ist eher für Spezialfälle gut. PHP bietet aber viel mehr Vorteile gerade für Webhoster aufgrund des Sicherheitsmodells und der großen Bibliothek an Funktionen die mit PHP mitkommt. Ich selbst mag eigentlich beides, muss aber auch zugeben, zum Programmieren ist mir sowas wie C++ eigentlich an sich lieber. (Ich komme ja auch eigentlich aus der C++ Schiene).

So ist PHP die dominierende Sprache? Die dominierende Sprache in kleinen Seiten, etc. Ja! Doch Java ist hier wesentlich dominanter. Auch C, selbst C++. C erfreut sich sogar momentan wieder besonderer Beliebtheit. Versteh mich nicht falsch, PHP wird es immer geben, schon alleine wegen den Zich Webhoster etc. pp. aber es ist und bleibt eine Sprache die zugegeben eben kein gutes Sicherheitsmodell hat. PHP ist eben schlecht by Design. Man kann alles Mögliche geben und auch viel. guten und viel. auch wartbarencode erzeugen, jedoch erlaubt PHP einfach zuvieles um eben genau das zu tun. Bzw. es gibt viele Möglichkeiten den Wartbaren Code sogar wieder auszuhebeln.

Einen großen Nachteil gibt es aber noch, Teile in FW mit NodeJS zu realisieren und andere mit PHP: Man hat dann 2 Server am laufen, einen NodeJS Server und einen Apache-Server. Wenn nur einer davon zusammenbricht, ist bereits die Welt weg. Und so schön NodeJS sein mag, es ist noch nicht 100% so stabil wie PHP (was auch daran liegt, dass es ständig läuft, und in PHP nur das script durchläuft und dann beendet ist). Bei Blockyblocks musste ich schon mehrmals den NodeJS Server neu starten, was da mittlerweile ein Daemon macht. NodeJS entwickelt sich da aber rasant, bis zur 1.0 Version tut sich da sicher noch viel.

Apache... Apache ist auch so ein Ding nunja, Apache ist 'oldschool' sehr modularisiert und auch sehr alt. Ich würde dir sowieso Raten wie auch schon erwähnt mit nginx einen Reverse Proxy schalten. NodeJS ist sehr sehr stabil, stabil genug. PHP nunja ich habe selbst php-fpm, sprich das läuft bei mir auch und ja auch das läuft ständig, jedoch ist mir bei einem Jahr uptime weder ein fcgid Prozess, noch ein nodeJS oder ein php-fpm worker abgestürzt.

Wie auch immer, letztendlich ist das Resultat das wichtige, nicht die Technik. Die Leute sollen Spass in Freewar haben, mit welcher Technik das letztendlich realisiert wird, ist den meisten Leuten egal. Wichtig ist halt, dass es schnell genug läuft und stabil genug.

Ja schnell stabil und konsistent weiterentwickelt wird. Neue Technologien bringen Vorteile und wie schon gesagt du könntest mit Ajax und Konsorten relativ viel bewerkstelligen. Wie schon gesagt du musst nicht von PHP weg gehen. Du kannst auch json, etc. mit PHP machen, wie gesagt ich war früher selbst jemand der viel und gerne etwas mit PHP gemacht hat, aber ich habe einfach gemerkt, PHP ist bad by design, egal was ich mache und ich bin froh wieder nativen Code oder eben ruby/java zu benutzen. Wobei letzteres ich eigl. so gut wie nie benutze und auch node.js in letzter Zeit so gut wie nie benutzt habe.

Beispiel das PVP Kampfsystem finde ich übertrieben schlecht und ein bisschen Schwung und eben neue Ideen, wären hier sicher schön. Da könnte man sich eben solche Ideen überlegen. Außerdem viel. eine PVP Arena ähnlich wie das Kampfsystem, dass ganze aber viel. mal mit einer Qeue, sprich man klickt auf 'Arena Kampf bla' und dann kriegt man nachdem Platz frei ist eben das auf den Screen und kann auf beitreten klicken. Nur mal als Beispiel. Das Inventar wäre noch so ne Sache, da kann man eben viel damit machen. Lass dich doch einfach inspirieren. Gibt eben viele PVPler die sich sicher auch etwas mehr Spannung in der Sache wünschen und sicher die Hammerideen haben. Wie gesagt in all der Zeit die ich jetzt bei Freewar bin und das ist jetzt auch ne Weile, kams mir eben ne lange Zeit so vor als wäre eigl. alles was neues reinkommt irgendwelcher Content der irgendwie ähnlich zu anderen Dingen ist, klar gibts da Ausnahmen wie z.b. die Pflanzen aber das ist jetzt auch nicht ganz mein Ding, aber so neue Gebiete oder so sind eigl. immer ähnlich designt wie auch schon alte. Bei Uniques oder NPCs sieht das ähnlich aus, die Kämpfe laufen, bis auf wenige Ausnahmen, relativ gleich ab. Es gibt eben wenige 'relativ' Innovative Dinge die die letzten Jahre beigesteuert worden sind. Sog. 'Killerfeatures' die einem sagen wow das muss ich sofort testen und sehen und werde mich erstmal mit nem Sponsi eindecken um das zu tun.
Neulinge sehen das viel. ähnlich. Aber die Problematik der Neulinge hab ich dir ja schon mal privat erläutert und will eigl. auf diese garkein Bezug nehmen.

[Sotrax]

@itgchris: Zu NodeJS: naja du weißt was ich meine. Klar löst man in NodeJS komplexere anfragen asynchron und mit Callback. Nichts desto trotz fehlen da immer noch die Worker Threads mit denen das viel simpler möglich wäre.

Das PHP inkonsistent ist stimmt. Das ist aber auch Javascript. Die Sprachen nicht mit mal transitiv im mathematischen Sinne. (Merkt man schnell wenn man mal vergleiche macht ala 0=="0", 0=="", ""!="0", da wirds meist abenteuerlich bei den allermeisten Scriptsprachen).

Auch stimmt es, dass PHP-Scripte je nach Konfig sich ganz verschieden verhalten (siehe Problematik mit magic_quotes etc. Man kann drumrumprogrammieren, schön ist es nicht).

Das bedeutet aber nicht, dass man mit PHP nicht komplexe und auch gute Software entwickeln kann. Und letztendlich kann man in PHP auch sehr schnell kleinere Dinge entwickeln die sofort funktionieren.

Unbestritten ist aber, das PHP derzeit die Sprache im Web ist.
(Wikipedia schreibt dazu "PHP wird auf ca. 75 % aller Websites als serverseitige Programmiersprache eingesetzt[6]" -> http://w3techs.com/technologies/overvie ... nguage/all)

Man muss PHP nicht mögen, aber alle anderen Sprachen für dynamische Webseiten wirken neben PHP und ASP derzeit fast unbedeutend.

NodeJS wird derzeit ordentlich gehyped, aber wird derzeit immer noch in weniger als 1% der Webseiten verwendet.

Diese starke Dominanz von PHP ist dabei bei weitem nicht nur auf kleinen privaten Seiten zu finden sondern zieht sich derzeit durchs gesamte Web. Siehe die größten Foren die derzeit im Web betrieben werden (phpBB ist da derzeit die am meisten verwendete Software, auch wenn sicherlich nicht perfekt). Auch im kommerziellen Einsatz hat sich PHP da mittlerweile voll durchgesetzt, siehe moderne Ecommerce-Software wie Magento (kenne jemand der in Berlin damit arbeitet, da hängen in der Tat tausende Jobs dran). Und Wikipedia ist auch eines der Prestige-Projekte von PHP mehr oder weniger (die in der Tat aber auch richtig viele Server brauchen und enorme Kosten haben). Aber es zeigt, dass PHP durchaus skaliert, auch für riesige Webseiten.

PHP ist derzeit absolut dominierend. Das hat natürlich auch historische Gründe, als ich vor 9 Jahren mit FW begonnen habe, war PHP neben ASP das einzige mit dem man überhaupt halbwegs vernünftig und schnell dynamische Seiten machen konnte, und das eine große Bibliothek geboten hat. (Perl war da schlicht langsamer und unhandlicher, und C++-CGIs hatten nicht die Vorteile von Scriptsprachen).

PHP hätte nicht diesen dominierenden Status, wenn die Sprache richtig schlecht gewesen wäre. (JSP konnte sich bis heute nie wirklich so durchsetzen). PHP hat einige Quirks, die Leute haben sich jedoch an diese gewöhnt und programmieren um diese herum. Aber PHP ist definitiv auch für sehr komplexe Projekte geeignet und hat sich da in der Praxis an vielen Stellen bewiesen.

PHP unterstützt einen nicht darin guten Code zu schreiben, C++ vielleicht schon mehr, aber auch dort kann man absolut grauenhafte Ausdrücke hinschreiben die wirklich niemand mehr versteht. Das wichtige bei guter Softwarearchitektur ist aber (gerade wenn mehrere Leute dran arbeiten), dass die Basis geordnet ist, lokal darf der Code chaotisch sein. Aber er muss global sauber sein und eingeteilt. Auf FW bezogen heißt das, die Engine muss tun, wenn jetzt angenommen der Code für den Heilzauber chaotisch ist, wäre das halb so wild, weil das nur sehr lokaler Code mit lokalem Einflussbereich ist. Aber die Basis muss so strukturiert sein, dass sie überhaupt solche Module erlaubt. Generell ist FW dabei objektorientiert aufgebaut (es gibt Items, die kann man anwenden, Orte die kann man benutzen etc etc.).

Zu Apache muss ich noch sagen, Fork ist natürlich eine teure Operation, aber mit der richtigen Konfiguration kein Problem, man kann Forks einfach vorspawnen lassen und z.B. 50 Forks rumidlen lassen bis sie drankommen. Wenn man nicht auf einen Schlag einen riesigen Andrang hat sondern die last einschätzen kann, ist das alles halb so wild. Apache ist übrigens auch nicht so langsam und so schlecht wie sein Ruf, das Problem beim Apache ist eher der enorme Ramverbrauch. Wenn man davon aber mehr als genug hat ist das reine Ausliefern der Seiten sehr schnell und Apache bietet mehr Module und Konfigurationsmöglichkeiten als fast jeder andere Webserver (gerade auch richtig gute Statistikmodule, sauberes parsen von htaccess optionen etc. Das geht natürlich auf die Zeit, ermöglicht aber auch vieles). Ich habe FW mal mit einem lighthttpd laufen lassen, wir sind jedoch wegen dem besseren expires modul und anderen Dingen wieder auf den Apache umgestiegen. Der Unterschied war bis auf den Ram verbrauch eher gering. Apache erlaubt ansonsten auch die Ausführung von Threads als worker statt schwergewichtiger fork-prozesse. Da aber manche Libs in PHP nicht threadsafe sind (gd z.B.), ist das derzeit keine Option.

Ansonsten stimmt es natürlich, es gibt noch viele Dinge die man in FW verbessern kann, aber erstmal muss man wissen wohin man will. Kampfsystem und Co lassen sich auch mit PHP verbessern. Zumindest sind wir derzeit noch nicht irgendwo drangestoßen wo wir gesagt haben, mit PHP kommen wir hier nicht mehr weiter.

Ajax verwenden wir zur Aktualisierung allerdings eher sporadisch, weil es ohne jquery eher unkomfortabel ist, und nur wegen einem Item will ich derzeit noch kein JQuery includieren, einfach weil es erstaunlich viele Clients gibt die sowas leider nicht cachen (sehe ich an den CSS Includes).

Wie gesagt, ich werde aber mit NodeJS und Websockets weiterexperimentieren und wollte auch blockyblocks.com in der Hinsicht noch deutlich ausbessern. Die ein oder andere Technik kann da durchaus auf FW zurückfallen. Auch sind ja jetzt schon viele Dinge in FW dynamisch gelöst (die Phasenenergie lädt sich automatisch auf etc.). Ich bin ansonsten ein großer Fan von JSON und verwende das intern um Sachen auch zwischen den Server hin und herzuschicken. XML war mir da schon immer irgendwie zu unhandlich für.

Es gibt zugegeben aber auch viele Dinge die ich damals z.B. in DarkFleet eingebaut habe, aber bei denen ich mich in FW nie durchringen konnte, z.B. die scrollende Karte, weil es irgendwie in FW komisch gewirkt hat.

An erster Stelle sollte jedoch immer letztendlich der Spielspass stehen und ich versuche die Dinge möglichst aus der Sicht der Spieler zu sehen. Macht etwas Spass? Wie macht es mehr Sinn? Wie sollte es für die Spieler aussehen und sich anfühlen? Ich muss zugeben die technische Realisierung stand bei mir da schon immer an zweiter Stelle.

Ich denke PHP war für FW aber aus einem ganz anderen Grund die richtige Wahl: Ohne PHP hätten mir niemals soviele Leute Codefetzen geschickt, die ich hätte einbauen können. In FW gab es vom ersten Tag an immer Helfer, und Leute die irgendwie PHP können findet man einfach deutlich leichter als Leute die z.B. Scala können. Sprich wenn ich die Hilfe der Community annehmen will, ist es für mich am einfachsten mit PHP.

[itgchris]

@itgchris: Zu NodeJS: naja du weißt was ich meine. Klar löst man in NodeJS komplexere anfragen asynchron und mit Callback. Nichts desto trotz fehlen da immer noch die Worker Threads mit denen das viel simpler möglich wäre.

Das PHP inkonsistent ist stimmt. Das ist aber auch Javascript. Die Sprachen nicht mit mal transitiv im mathematischen Sinne. (Merkt man schnell wenn man mal vergleiche macht ala 0=="0", 0=="", ""!="0", da wirds meist abenteuerlich bei den allermeisten Scriptsprachen).

Auch stimmt es, dass PHP-Scripte je nach Konfig sich ganz verschieden verhalten (siehe Problematik mit magic_quotes etc. Man kann drumrumprogrammieren, schön ist es nicht).

Das bedeutet aber nicht, dass man mit PHP nicht komplexe und auch gute Software entwickeln kann. Und letztendlich kann man in PHP auch sehr schnell kleinere Dinge entwickeln die sofort funktionieren.

Es macht einfach keinen Sinn PHP zu benutzen. Desweiteren JavaScript ist eine Scriptsprache und ist nur halb so inkosistent wie PHP. PHP macht einfach so ziemlich alles falsch was eine Sprache falsch machen kann.

Unbestritten ist aber, das PHP derzeit die Sprache im Web ist.
(Wikipedia schreibt dazu "PHP wird auf ca. 75 % aller Websites als serverseitige Programmiersprache eingesetzt[6]" -> http://w3techs.com/technologies/overvie ... nguage/all)

Och Statistiken glauben nur die, die Sie auch gefälscht haben. Die Seite stimmt eben sowieso nicht, da eben C/C++ auch mit mind 0.1% einschlagen müsste. PHP ist vielleicht viel vertreten, die Frage ist aber eher, kannst du das in die Statistik mit einberufen? Ich denke nicht. PHP ist beliebt weil jeder 'dummdödel' sich auf wordpress.org oder Diverese CMS / Forensoftware runterladen kann und installieren kann und dann denkt er ist Webseitenbetreiber, ob er dass dann ist, bezweifle ich. Wenn man es realistisch sieht kommt PHP vielleicht auf 30% viel. sogar auf 50%, aber schon garnicht auf 70%. Denn Java ist momentan zu sehr vertreten. Schon alleine wegen J2EE. Hinzu kommen noch Seiten die eben mit HipHop crosscompiliert sind. Reines PHP ist das auch nicht mehr. Sprich Firmen setzten meist auf etwas anderes wie PHP. Wie gesagt die Statistik ist ein 'schön' Reden von dem wie es eigl. aussieht.

Man muss PHP nicht mögen, aber alle anderen Sprachen für dynamische Webseiten wirken neben PHP und ASP derzeit fast unbedeutend.

Das ist so eben nicht Richtig. PHP findet eben da Einklang wofür es entwickelt wird. Für Leute die ne Webseite haben wollen aber nahezu keine Ahnung haben. So Richtige Anwendungen sind selten in PHP oder wandern eben ab, schon alleine weil es relativ problematisch ist PHP Scripte auszuliefern aber einer bestimmten Menge an Req/s auch Facebook hat das ja gemerkt, Sie fanden es halt ganz 'nett' nach C++ zu compilieren. Ist wohl auch eine relativ gute Idee, so können Sie PHP schreiben und kriegen am Ende C++ raus.

NodeJS wird derzeit ordentlich gehyped, aber wird derzeit immer noch in weniger als 1% der Webseiten verwendet.

NodeJS wird gehyped weil es viele JavaScript Entwickler gibt. Trotz das es eben nur eine Scriptsprache ist, sieht man halt das JavaScript sehr mächtig ist.

Diese starke Dominanz von PHP ist dabei bei weitem nicht nur auf kleinen privaten Seiten zu finden sondern zieht sich derzeit durchs gesamte Web. Siehe die größten Foren die derzeit im Web betrieben werden (phpBB ist da derzeit die am meisten verwendete Software, auch wenn sicherlich nicht perfekt). Auch im kommerziellen Einsatz hat sich PHP da mittlerweile voll durchgesetzt, siehe moderne Ecommerce-Software wie Magento (kenne jemand der in Berlin damit arbeitet, da hängen in der Tat tausende Jobs dran). Und Wikipedia ist auch eines der Prestige-Projekte von PHP mehr oder weniger (die in der Tat aber auch richtig viele Server brauchen und enorme Kosten haben). Aber es zeigt, dass PHP durchaus skaliert, auch für riesige Webseiten.

Nicht wirklich wie gesagt meistens wird PHP ausgelagert und das machen auch relativ viele. phpBB ist beliebt ja. Aber Foren die ich als 'groß' empfinde sind eben nicht in PHP. Wenn du das Web von zwei Seiten siehst wird dir das auch klar. Es gibt eben den einen Bereich und den anderen. Klar es gibt PHP Anwendungen die im großen Stil sind, wie gesagt Facebook ist zu 50% PHP. Und es gibt sicher auch andere, aber im Normalfall sieht man bei Großprojekten Recht wenig PHP und wenn doch, wird das nach und nach umgebaut.

PHP ist derzeit absolut dominierend. Das hat natürlich auch historische Gründe, als ich vor 9 Jahren mit FW begonnen habe, war PHP neben ASP das einzige mit dem man überhaupt halbwegs vernünftig und schnell dynamische Seiten machen konnte, und das eine große Bibliothek geboten hat. (Perl war da schlicht langsamer und unhandlicher, und C++-CGIs hatten nicht die Vorteile von Scriptsprachen).

PHP hätte nicht diesen dominierenden Status, wenn die Sprache richtig schlecht gewesen wäre. (JSP konnte sich bis heute nie wirklich so durchsetzen). PHP hat einige Quirks, die Leute haben sich jedoch an diese gewöhnt und programmieren um diese herum. Aber PHP ist definitiv auch für sehr komplexe Projekte geeignet und hat sich da in der Praxis an vielen Stellen bewiesen.

Nunja... dominierend und häufig vertreten ist fast schon zweierelei. Das eine bedeutet es ist einfach und es gibt viel Software dafür und das andere sagt, es gibt viele Firmen die eigene Programme dafür schreiben. Und wenn man eben die ganzen PHP Skripte rausläst dann sieht man ja was bei rumkommt. So gut wie nix.
Warum PHP so beliebt ist, sieht man doch hier: http://www.php.net/manual/phpfi2.php#overload

This doesn't change the overloaded operator nature of the PHP variables, but it does give you some tools to better deal with them. PHP is not not a full-fledged Perl look-alike. It has to be small and fast. Perl deals with the overloaded operator pitfall by forcing something like the '+' operator to only work on numbers. If you want to add strings, you must use the '.' operator. Once you start having separate operators for each type you start making the language much more complex. ie. you can't use '==' for stings, you now would use 'eq'. I don't see the point, especially for something like PHP where most of the scripts will be rather simple and in most cases written by non-programmers who want a language with a basic logical syntax that doesn't have too high a learning curve.

Und das ist eben nunmal ein Fakt. PHP ist nicht designt für einen Einsatz im Unternehmen oder auf bestimmten Websites. Da es sehr sehr schlecht skaliert. Unter anderem liegt es an der Trägheit der Sprache, an der schwachen Typisierung, teilweise sogar an Apache/Mod_PHP. Und was es eben noch so alles gibt. Wie gesagt versteh mich nicht falsch, PHP hat seinen Anwendungsfall, alle Sprachen haben dass, aber es ist und war eben nicht für große Ekosysteme vorgesehen.

PHP unterstützt einen nicht darin guten Code zu schreiben, C++ vielleicht schon mehr, aber auch dort kann man absolut grauenhafte Ausdrücke hinschreiben die wirklich niemand mehr versteht. Das wichtige bei guter Softwarearchitektur ist aber (gerade wenn mehrere Leute dran arbeiten), dass die Basis geordnet ist, lokal darf der Code chaotisch sein. Aber er muss global sauber sein und eingeteilt. Auf FW bezogen heißt das, die Engine muss tun, wenn jetzt angenommen der Code für den Heilzauber chaotisch ist, wäre das halb so wild, weil das nur sehr lokaler Code mit lokalem Einflussbereich ist. Aber die Basis muss so strukturiert sein, dass sie überhaupt solche Module erlaubt. Generell ist FW dabei objektorientiert aufgebaut (es gibt Items, die kann man anwenden, Orte die kann man benutzen etc etc.).

Naja.. Und gerade das Klassen z.b. keine Objekte sind ist schon relativ komisch. PHP ist Metaprogrammierung hoch ^ 10 und nunja Code muss eben wartbar und logisch sein. Nur weils für einen sauber aussieht, bedeutet das nicht das es sauber ist nachdem man es parst / interpretiert.

Zu Apache muss ich noch sagen, Fork ist natürlich eine teure Operation, aber mit der richtigen Konfiguration kein Problem, man kann Forks einfach vorspawnen lassen und z.B. 50 Forks rumidlen lassen bis sie drankommen. Wenn man nicht auf einen Schlag einen riesigen Andrang hat sondern die last einschätzen kann, ist das alles halb so wild. Apache ist übrigens auch nicht so langsam und so schlecht wie sein Ruf, das Problem beim Apache ist eher der enorme Ramverbrauch. Wenn man davon aber mehr als genug hat ist das reine Ausliefern der Seiten sehr schnell und Apache bietet mehr Module und Konfigurationsmöglichkeiten als fast jeder andere Webserver (gerade auch richtig gute Statistikmodule, sauberes parsen von htaccess optionen etc. Das geht natürlich auf die Zeit, ermöglicht aber auch vieles). Ich habe FW mal mit einem lighthttpd laufen lassen, wir sind jedoch wegen dem besseren expires modul und anderen Dingen wieder auf den Apache umgestiegen. Der Unterschied war bis auf den Ram verbrauch eher gering. Apache erlaubt ansonsten auch die Ausführung von Threads als worker statt schwergewichtiger fork-prozesse. Da aber manche Libs in PHP nicht threadsafe sind (gd z.B.), ist das derzeit keine Option.

Naja Apache ist so ziemlich der miesest skallierende Webserver, äußerst träge, etc. Ist aber auch nicht schlimm, immerhin ist er schon ewig alt und kann eben nicht gegen eine neue Codebasis wie die von Lighty / NGiNX und andere Konsorten ankommen (gibt ja noch andere nette Sachen). Das ist aber weniger schlimm. Apache (2) funktioniert und mit dementsprechenden Server (wenn man die hat) ist der 'Mehrverbrauch' auch kein Problem.

Ansonsten stimmt es natürlich, es gibt noch viele Dinge die man in FW verbessern kann, aber erstmal muss man wissen wohin man will. Kampfsystem und Co lassen sich auch mit PHP verbessern. Zumindest sind wir derzeit noch nicht irgendwo drangestoßen wo wir gesagt haben, mit PHP kommen wir hier nicht mehr weiter.

Wie gesagt habe ich nie anders behauptet. Ich wollte nur aufzeigen das PHP eben nicht mehr erste Wahl ist und ich denke auch das du heutzutage dir 2 x überlegen würdest ob du die Codebasis von FW auf PHP ansetzt. Wie gesagt im Web 2.0 macht man die Dinge einfach anders und durch gewachsene Erfahrung weiß heute jeder Programmierer das Dilemma um PHP.

Ajax verwenden wir zur Aktualisierung allerdings eher sporadisch, weil es ohne jquery eher unkomfortabel ist, und nur wegen einem Item will ich derzeit noch kein JQuery includieren, einfach weil es erstaunlich viele Clients gibt die sowas leider nicht cachen (sehe ich an den CSS Includes).

Großer Fehler, btw. du musst nicht auf jquery etc. setzten gibt auch andere. Aber nur weil ein Client das nicht cachet ist das keine gute Idee. Jemand der noch auf Firefox 3.6 setzt, hat bspw. Pech ist aber auch egal, da dieser sowieso den Support verliert. zumindest Firefox ESR 10.0 ist eine Vorraussetzung und den IE 6.0 nunja den solltest du auch endlich mal von Freewar trennen. Einfach aus Sicherheitstechnischer Sicht. Sieh es so, wenn deine User mit IE6 Darstellungsprobleme haben, wechseln Sie vielleicht auch. Was der Welt wieder mehr Sicherheit gibt, klingt doof ist aber so.

Wie gesagt, ich werde aber mit NodeJS und Websockets weiterexperimentieren und wollte auch blockyblocks.com in der Hinsicht noch deutlich ausbessern. Die ein oder andere Technik kann da durchaus auf FW zurückfallen. Auch sind ja jetzt schon viele Dinge in FW dynamisch gelöst (die Phasenenergie lädt sich automatisch auf etc.). Ich bin ansonsten ein großer Fan von JSON und verwende das intern um Sachen auch zwischen den Server hin und herzuschicken. XML war mir da schon immer irgendwie zu unhandlich für.

Versteif dich nicht auf NodeJS und Websockets. Bisher sind Websockets noch nicht mal im Standard ergo... nicht immer ne gute Idee. Du kannst doch C++? Damit kann man sehr sehr viel machen und dann mit Ajax ausliefern. XML ist dafür auch nicht angedacht. XML ist eine Beschreibungssprache und dafür funktioniert es auch einwandfrei. Wenn man mit Ajax XML zurückgibt kannste auch gleich HTML verwenden, hat einen ähnlichen Overhead.

Es gibt zugegeben aber auch viele Dinge die ich damals z.B. in DarkFleet eingebaut habe, aber bei denen ich mich in FW nie durchringen konnte, z.B. die scrollende Karte, weil es irgendwie in FW komisch gewirkt hat.

An erster Stelle sollte jedoch immer letztendlich der Spielspass stehen und ich versuche die Dinge möglichst aus der Sicht der Spieler zu sehen. Macht etwas Spass? Wie macht es mehr Sinn? Wie sollte es für die Spieler aussehen und sich anfühlen? Ich muss zugeben die technische Realisierung stand bei mir da schon immer an zweiter Stelle.

Genau und deshalb, informiere dich was die so für Ideen haben. Technisch ist alles Möglich, du musst es nur wollen.

Ich denke PHP war für FW aber aus einem ganz anderen Grund die richtige Wahl: Ohne PHP hätten mir niemals soviele Leute Codefetzen geschickt, die ich hätte einbauen können. In FW gab es vom ersten Tag an immer Helfer, und Leute die irgendwie PHP können findet man einfach deutlich leichter als Leute die z.B. Scala können. Sprich wenn ich die Hilfe der Community annehmen will, ist es für mich am einfachsten mit PHP.

Naja du bist Closed Source, ergo denke ich wohl kaum das dir das soviel bringt. Klar ist es hilfreich aber ich denke es gibt hier auch Leute die etwas mehr als nur PHP können. Also denke ich das du Hilfe so oder so bekommst.

[bwoebi]

@itgchris: das Problem ist, dass man es schlecht schnell hin kriegt wenn man es schön haben will

Die meisten Programmierer setzen lieber auf Einfachheit als auf Schnelligkeit, denn zumindest bei kleineren Seiten (zu denen ich auch Fw zählen würde) spielt es keine Rolle ob das Skript jetzt 28 oder 23 ms dauert, der idle ist noch immer groß genug...

Es gibt Leute die schätzen schwache Typisierung auch mehr, denn dann ist es egal z.B. ob man ein boolesches false oder einen integer zurück liefert; natürlich ist es ein Problem wenn man die Funktion ändert, dann ist kein Compiler da der meckert wenn irgendwo mit integer verglichen wird obwohl jetzt nun bool statt int zurückgeliefert wird. Aber meiner Meinung nach ändert man eher einzelne Unterabläufe einer Funktion als deren return-Typ. Wenn man sich vertippt meckert Php noch immer schnell genug. Ich empfinde die starke Typisierung von C usw. eher als Nachteil, denn in der Regel kennt man den Typ einer Variable und schränkt zudem ein... Z.B. Wenn ich eine funktion in Java habe die erwartet dass ich ihr einen integer übergebe, aber einen String der eine Zahl enthält übergeben will, habe ich die Wahl zuerst zu casten oder eine extra überladende funktion zu schreiben die string als parameter empfängt und dort castet und nach dann dort die funktion die einen integer erwartet aufzurufen. Solcherart Probleme hat man dann nicht bei Php. Php ist schon deswegen nicht alles falsch machend was es nur kann; ist einfach eine Art von anderer Sprache: es ist nicht gleich mit den alten Sprachen... Oder steht irgendwo geschrieben was eine Skriptsprachen können muss um als richtige Skriptsprache zu gelten? (Manchmal ist mir zwar Php zu langsam, aber das ist nur wenn ich ineffizient progge; C usw. 20% schneller, macht auch nicht mehr viel aus finde ich)

P.s.: ja, PHP ist Metaprogrammierung und wenn man bis daran gewohnt ist, kann man das ganz gut finden

[itgchris]

@itgchris: das Problem ist, dass man es schlecht schnell hin kriegt wenn man es schön haben will

Die meisten Programmierer setzen lieber auf Einfachheit als auf Schnelligkeit, denn zumindest bei kleineren Seiten (zu denen ich auch Fw zählen würde) spielt es keine Rolle ob das Skript jetzt 28 oder 23 ms dauert, der idle ist noch immer groß genug...

Es gibt Leute die schätzen schwache Typisierung auch mehr, denn dann ist es egal z.B. ob man ein boolesches false oder einen integer zurück liefert; natürlich ist es ein Problem wenn man die Funktion ändert, dann ist kein Compiler da der meckert wenn irgendwo mit integer verglichen wird obwohl jetzt nun bool statt int zurückgeliefert wird. Aber meiner Meinung nach ändert man eher einzelne Unterabläufe einer Funktion als deren return-Typ. Wenn man sich vertippt meckert Php noch immer schnell genug. Ich empfinde die starke Typisierung von C usw. eher als Nachteil, denn in der Regel kennt man den Typ einer Variable und schränkt zudem ein... Z.B. Wenn ich eine funktion in Java habe die erwartet dass ich ihr einen integer übergebe, aber einen String der eine Zahl enthält übergeben will, habe ich die Wahl zuerst zu casten oder eine extra überladende funktion zu schreiben die string als parameter empfängt und dort castet und nach dann dort die funktion die einen integer erwartet aufzurufen. Solcherart Probleme hat man dann nicht bei Php. Php ist schon deswegen nicht alles falsch machend was es nur kann; ist einfach eine Art von anderer Sprache: es ist nicht gleich mit den alten Sprachen... Oder steht irgendwo geschrieben was eine Skriptsprachen können muss um als richtige Skriptsprache zu gelten? (Manchmal ist mir zwar Php zu langsam, aber das ist nur wenn ich ineffizient progge; C usw. 20% schneller, macht auch nicht mehr viel aus finde ich)

P.s.: ja, PHP ist Metaprogrammierung und wenn man bis daran gewohnt ist, kann man das ganz gut finden

Du verwechselst dynamische Typisierung bzw. explizite mit schwacher Typisierung. Ich habe nichts gegen explizite, nein im Gegenteil es bringt Vorteile, aber das hat nichts mit schwachter Typisierung zu tun. Schwache Typisierung gibt an, wie stark sich verschiedene Typen bei der Sprache ähneln und was passiert bei einer Umwandlung z.b. Verlust von Werten. Bei PHP kannst du eben nicht einfach ein Int zurückgeben, wenn ein String erwartet wird, du musst eben auch casten, aber die Sprache macht hier eben vieles falsch. Es ist eine Pseudotypisierung die mehreres vermischt. Bei PHP macht man deshalb vieles falsch, weil eben falsch bei PHP richtig ist. Oder richtig auch falsch sein kann. PHP ist durch Ihr extremes wachstum zu einer Sprache geworden die fraktal schlecht designt ist.
PHP ist wesentlich langsamer als 20% und man kann in PHP auch garnicht 'effizient' Programmieren, dafür ist die Sprache aber auch nicht geeignet. Nunja Skriptsprachen haben das so ansich, wobei ich hier sagen kann, dass Ruby langsamer als PHP, Python und Javascript schneller sind, als PHP. Also auch alles nur eine Frage der Implementierung, klar kann man PHP mit php-fpm in eine wahre Speedmaschiene verwandeln, trotz allem schlägt es bspw. nodeJS nicht. Klar native Sprachen wird es nie schlagen, dass ist aber auch garnicht Möglich, mit einer Turing-Maschine kann ich auch jedes Problem lösen, aber klar ist auch das dies nicht so effizient sein wird.
Ja und Nein, es gibt verifizierte und Standarisierte Sprachen und es gibt eben keine, PHP wird nie verifizert werden können, schon allein weil es inkosistent und es sehr, sehr viele Probleme mit PHP gibt.
Der Anwendungsfall ist klar und du hast Ihn auch genannt.. Einfachheit, dass Einfachheit aber nicht gleich gut bedeutet, sollte klar sein.

Ich will da auch eigl. garnicht weiter darauf rumreiten, schon alleine weil jedem denke ich klar ist das PHP eigl. eher als Saustall gillt im Vergleich zu anderen Sprachen, dies ist ja allgemein nicht unbekannt und viele Thematiken dazu gibt es im Internet.
Jede Sprache hat eben sein Manko und jedes auch seinen Anwendungsfall und der von PHP ist halt eben mit wenig Aufwand und Programmiererfahrung schnell zu einem Ziel zu gelangen, der Weg spielt dabei eine eher Minderwertige Rolle.

[bwoebi]

Implizite Typisierung dann eben...

Und implizites casten... Ich meine hiermit insbesondere folgenden Anwendungsfall: man hat userinput, der als string erhalten wird und ruft damit eine Funktion auf, die z.B. Mathematische Operationen macht. Man ruft diese Funktion aber auch gerne mit integerwerten auf (resultate vorangehender berechnungen z.B.) ohne jetzt zu casten. Hier empfinde ich es als Vorteil einfach die Funktionnaufrufrn zu können ohne mir sorgen ums casting zu machen (ja, ich weiß, man kann auch arrays als userinput haben (manipulierte urls), was dann natürlich scheiße ist -> muss man überprüfen, bedenkt aber fast keiner... Aber naja, auch explizit nach int gecastete Arrys sind nicht exzellent^^)

Bzgl. Geschwindigkeit: overhead durch interpreter überflüssige predefiniertes usw verlangsamt alles, aber versuch mal den Php-Anhängern weis zu machen, dass sie am besten php ohne extensions kompilieren und die dann mit dl() oder ähnlichem einbinden sollen^^

[itgchris]

Implizite Typisierung dann eben...

Und implizites casten... Ich meine hiermit insbesondere folgenden Anwendungsfall: man hat userinput, der als string erhalten wird und ruft damit eine Funktion auf, die z.B. Mathematische Operationen macht. Man ruft diese Funktion aber auch gerne mit integerwerten auf (resultate vorangehender berechnungen z.B.) ohne jetzt zu casten. Hier empfinde ich es als Vorteil einfach die Funktionnaufrufrn zu können ohne mir sorgen ums casting zu machen (ja, ich weiß, man kann auch arrays als userinput haben (manipulierte urls), was dann natürlich scheiße ist -> muss man überprüfen, bedenkt aber fast keiner... Aber naja, auch explizit nach int gecastete Arrys sind nicht exzellent^^)

Bzgl. Geschwindigkeit: overhead durch interpreter überflüssige predefiniertes usw verlangsamt alles, aber versuch mal den Php-Anhängern weis zu machen, dass sie am besten php ohne extensions kompilieren und die dann mit dl() oder ähnlichem einbinden sollen^^

Ich verstehe dein Anwendungsfall, jedoch ist das relativ egal, in Java kannst du auch Überladen und in viele anderen Sprachen auch, selbst wenn das nicht gehen würde, kannst du das immer auf eine andere Art machen. Wie gesagt Überladung ist eben nicht das Problem von implizit, explizit. Jedoch mache ich momentan viel mit Golang, die Entwickler sehen Überladung als sinnlos, ich auch, dafür haben Sie den Paramter '...T' (bei Java gibt es eben auch Generics) da kann ich also auch beliebige Werte an eine Funktion geben, ähnlich wie bei PHP. Hat aber eben auch nichts mit schwacher Typisierung zu tun. Golang ist sehr streng und statisch Typisiert. Klar es gibt auch sein Manko bei solchen Geschichte, aber man kann wesentlich bessern Code schreiben als mit PHP, Golang erlaubt keine Fehler.

Du hast gerade noch ein schönes Problem an PHP geschildert. Extensions... Unbenötigte Extensions lädt PHP in jeder Env gleich mit, ob man Sie benötigt oder nicht spielt eben keine Rolle. Klar du sagst gerade, wie mans Richtig macht, aber ist das wirklich der Richtige Weg? Wie sieht es bei Multithreading aus? Wie bei CGI, wie bei FPM? Bei Windows wird, wenn nicht explizit angegeben die Extensions aus einem Verzeichnis geladen. Wie sieht es bei Unixoiden Systemen aus? Naja da sieht man doch gleich, was für Probleme bestehen. Wie sieht es mit case-sensitiv aus bei dl()? Richtig, auf Windows Nein auf Unix Ja. Ehm ja?! Namespace von PHP ist total zerschossen ernsthaft.
Wie gesagt, du kannst PHP nicht schön programmieren, du kannst es schön aussehen lassen, aber schön ist eben was anderes. Eine schöne Programmierung erlaubt solche Dinge nicht.

Wie schon gesagt, viele die damals PHP gemacht haben, haben das auch eingesehen. Einige sind zu Java, einige zurück zu C und einige zu JavaScript oder anderen Sprachen. Viele Entwickler mit denen PHP groß geworden sind, arbeiten eben auch garnicht so direkt, dass am Ende eine Webseite rauskommt, eben es gibt halt noch den Bereich den Firmen für Ihre Anwendungen benutzen. Da ist halt unangefochten Java vorne und das sowohl in Sachen Webservices, als auch auf Fat-Clients. Klar viele haben damals Applets benutzt, aber das ist auch auf dem Rückgang, ne zeitlang war auch ActiveX da ne 'coole' Sache. Java ist eben auch ne tolle Sache, auch wenns im Web ähnlich wie PHP träge werden kann, jedoch hat man fast die größte Entwicklerbasis überhaupt.
Trotzdem nach mehreren Bewerbungen im Softwaresegment sind die nativen Sprachen eigl. das wo momentan sehr viel gesucht wird, nicht nur wegen dem Web sondern allgemein. Immer wenn Firmen 'C' gesehen haben in meiner Bewerbung wurde ich gleich ausgefragt, wo ichs gelernt habe, was ich da alles kann, was ich bereits gemacht habe, etc.. Ob ich Erfahrung mit CGI / FastCGI habe ob ich den andere native Sprachen behersche und vieles mehr. Und ehrlich? Ich mag C für Web oder Systemprogrammierung nichtmal besonders, weil ich immer wieder alte Software auf ein neues Level bringen muss oder auch systemkritische Anwendungen programmieren muss, was manchmal bei schlecht gewartetem Code mich Richtig zum verzweifeln bringt. Und wenn ich bedenke das ich mit C bzw. programmieren angefangen habe auf einem der ersten ATMEL AVR Chips, naja dann kommt mir eben die Panik hoch wenn ich C Code wo einzelne Dateien die 128K Codezeilen übersteigen debuggen und warten muss.
Verstehe auch garnicht warum die Firma die 'light' Variante Ihrer Produkte nicht einfach aufgegeben hat. Naja scheint wohl Marketingmässig zu sein. Diese jedoch zu supporten fällt meistens dem armen Werksstudenten zu, dabei bin ich einer von 5 Mitarbeiter die noch C Kenntnisse haben.. *würg*

[Nelan Nachtbringer]

Ich wäre dafür, den Zwangslag auf 0.4 s zu machen und nach dem 3. Item 0.7 s (evtl. 3. Item innerhalb von 3-5 s)

Schon einmal Gewebe gemacht?!
Gewebewurm,Fernheilzauber und dann noch Gzk?! Wie lange soll ich denn noch brauchen?

EDIT: Gewebewurm anwenden => 1. Wartezeit=> Namen auswählen => 2. Warezeit => Fernheili anwenden => 3. Wartezeit => Namen auswählen => 4. Wartezeit => Gzk anwende => 5. Wartezeit => Punkt auwählen und Noppe drücken.


Wenn du einmal zu schnell drückst hast du gleich eine ewig lange Wartezeit. Da sind Bots einfach im Vorteil. Die können Minisleeps einbauen und ich bin der Depp, der einfach schnell ist und dann noch bestraft wird...

[itgchris]

Ich wäre dafür, den Zwangslag auf 0.4 s zu machen und nach dem 3. Item 0.7 s (evtl. 3. Item innerhalb von 3-5 s)

Schon einmal Gewebe gemacht?!
Gewebewurm,Fernheilzauber und dann noch Gzk?! Wie lange soll ich denn noch brauchen?

EDIT: Gewebewurm anwenden => 1. Wartezeit=> Namen auswählen => 2. Warezeit => Fernheili anwenden => 3. Wartezeit => Namen auswählen => 4. Wartezeit => Gzk anwende => 5. Wartezeit => Punkt auwählen und Noppe drücken.


Wenn du einmal zu schnell drückst hast du gleich eine ewig lange Wartezeit. Da sind Bots einfach im Vorteil. Die können Minisleeps einbauen und ich bin der Depp, der einfach schnell ist und dann noch bestraft wird...

Jemand der ein sleep() in sein Programm einbaut ist ein größerer Depp wie du, glaub mir. Aber wie du schon erkannt hast gibt es eben Möglichkeiten dies sehr gut zu realisieren, jedoch bezweifle ich, dass es gute Bots für Freewar gibt.

[Nelan Nachtbringer]

Es gibt X Möglichkeiten ein "sleep" realtiv unauffällig einzubauen. Und der Depp bin ich trotzdem.

[itgchris]

Es gibt X Möglichkeiten ein "sleep" realtiv unauffällig einzubauen. Und der Depp bin ich trotzdem.

Macht trotzdem wenig Sinn zu sleepen. Reicht wenn man so eine Art wait() hat und einfach auf die Rückmeldung von dem ersten Request wartet. So á la while(Request != 200).

Bezweifle das überhaupt ein Bot für Freewar einen Honeypot bestehen könnte.

[Sotrax]

@itgchris: Wie gesagt, ja ich würde heute auch in manchen Dingen andere Alternativen verwenden (und mache ich für neue Projekte ja auch). Vor 9 Jahren dagegen, war damals PHP eine recht logische Wahl (FW lief erstmal nur auf einem Webspace, ich hatte garkeine andere Möglichkeit damals).

Ich finde jetzt PHP auch keine sonderlich schöne Sprache. Sie hat aber durchaus ihre Vorteile, z.B. die große Standardbibliothek (gut für Leute die nur einen Webspace haben und keine externen Bibs installieren können).

Die Anforderung von Unternehmen ist ja auch völlig anders als z.B. von einem Browsergame. Transaktionssicherheit ist bei FW sicherlich nicht so wichtig wie bei einer Bank.

Übrigens kann man in PHP auch sehr simpel externe Funktionen die komplexer sind in C++ lösen. Das integrieren ist da in der Tat super einfach.

Ein großes Problem des OOPs bei PHP ist meiner Meinung nach eher die kurze Lebenszeit der Objekte (bzw. scripte). Man baut seine Objekte auf und ehe man sich versieht ist das Script zuende und alles wieder tut und so baut man bei jedem Scriptaufruf alles wieder zusammen. Das ist natürlich bei einem Java-Server oder NodeJS Server sehr viel schöner, weil man seine Objekte beliebig lange im Speicher halten kann, und erst dann verwirft wenn man sie wirklich nicht mehr braucht.

Die Einschätzung das PHP aber nur sozusagen für kleine private Frickelseiten eingesetzt wird, ist falsch (wie du ja auch selbst an Facebook oder Wikipedia sagst). Gerade im ECommerce bereich ist PHP nach wie vor irre groß, auch wenn dort Java eigentlich die bessere Lösung ist.

Ein Grund dafür ist z.B. dass manche Unternehmen sagen, ein PHP Entwickler kostet einfach deutlich weniger als ein Scala entwickler. Das ist halt nunmal Fakt. Ob die Kosten dann an der richtigen Stelle gespart wurden, ist natürlich eine ganz andere Frage

Wegen Websockets: Das diese noch nicht richtig im Standard sind, stimmt, was aber auch an den Sicherheitsproblemen von Websockets lag, die mittlerweile in vielen Browsern behoben sind. Aber ich liebe SocketIO, die dynamischen Fallbacks klappen da sehr gut und es unterstützt zur Not nicht nur longpolling sondern Flashsockets.

Übrigens hat PHP einen großen Vorteil zu C++: Es kann dynamisch neuen Code laden und ausführen, für Unique Items in FW durchaus interessant. (Ich weiß, man kann in C++ diesen Nachteil leicht durch LUA ausgleichen um dynamische Scripte reinzuladen, die nicht extra kompiliert werden müssen).

Was mich halt generell immer abschreckt ist auch einfach "Never change a running system". Das ist zwar nicht immer richtig, aber zumindest läuft derzeit FW ziemlich stabil. Und die andere Sache ist halt, wenn ich das Gefühl habe, ein komplettes Coderefactoring ist sehr viel Arbeit, hat aber nur einen geringen Effekt für die Leute, dann stecke ich die Energie lieber gleich in ein neues Projekt, wo ich von Anfang an die Basis wähle, die ich dafür haben will ^^

@all: Wegen Bots: Davon gibt es zum Glück in Freewar viel weniger als in anderen Spielen, weil sie in FW einfach viel schneller auffallen durch den Echtzeitcharakter und den Chat. In einem Strategiespiel ist es für die Spieler viel schwerer einen Bot zu erkennen.