Suchergebnisse

Da wirst du wohl ein Lichtobjekt machen müssen, das im create-Event das Licht erstellt, so wie's im Beispiel auch passiert.

Wie henrik1235 es schon gesagt hat, du kannst ein collision_rectangle nicht drehen. Es reicht allerdings, wenn du dir die point_direction vom Zombie zum Spieler ausrechnest und sie mit der Blickrichtung des Zombies vergleichst. Zieh dafür einfach den einen Winkel vom anderen ab und nimm den Betrag davon. Dann hast du den Winkelunterschied. Ist dieser größer als ein bestimmter Wert, z.B. 45° (in beide Richtungen, d.h. insgesamt hätte der Zombie ein Sichtfeld von 90°), kann der zombie den Spieler …

Wurde hier ja schon vorgeschlagen: GML-Quellcode (2 Zeilen) Wobei du dir bei der zweiten Methode womöglich leichter tust, da du hier nur hue ändern musst, um eine andere Farbe zu bekommen. Lässt zu zum Beispiel eine Variable durchlaufen, die in jedem Step um eins erhöht wird und auf 0 zurückgesetzt wird sobald sie 255 überschritten hast, kannst du diese für den hue-Wert einsetzen. Falls du's genau wissen willst.

Also so wie du das beschrieben hast, kannst du es ja auch umsetzen. Wenn der Spieler mit einem Teleporter kollidiert und E drückt: GML-Quellcode (15 Zeilen)

Zitat von DragonGamer: „Nett nett, das System ist solide! Allerdings geht das bei dynamischen "Castern" (also wenn sie per _position Funktion jeden Step deplaziert werden) ziemlich schnell in die Knie da alle Lichter dann in jedem Step geupdatet werden müssen.. :/“ Teilweise schon wahr, das Bewegen von Castern ist performancelastiger, betrifft aber auch nicht alle Lichter, sondern nur die, in deren Radius der Caster liegt.

Lichtengine "lsys" Hallo liebe Leute! Nachdem ich heute ein wenig an meiner alte Lichtengine gebastelt habe und sowohl Performance als auch Bedienung verbessert habe, möchte ich sie euch hier vorstellen. Auf Youtube habe ich sie schon seit längerem präsentiert und zum Download angeboten, aber nun ist sie denke ich optimiert genug. Es handelt sich hierbei um eine gewöhnliche Lichtengine, die mehrere farbige Lichter unterstützt sowie Strukturen, die Schatten werfen, sogenannte Caster. Hier mal ein…

Der (freie) Grafikspeicher lässt sich durch das erstellen von Surfaces berechnen. 4 * breite * höhe pro Surface.

Zitat von Tice: „Ja und die ist auch obsolete.“ Ja um Gottes Willen, dann lässt du halt das working_direktory offen und startest daraus. Im fertigen Spiel wirst du die Funktion ohnehin nicht brauchen und wieder ausbauen. Das ist ja jetzt auch nicht so ein Mehraufwand, einen Ordner geöffnet zu haben und von dort aus ein Programm zu starten.

Das geht mit verschiedenen Funktionen. GML-Quellcode (4 Zeilen)

Zitat von Tice: „Zitat von DragonGamer: „Ich kann im Studio problemlos mit einem Mausklick das Projekt starten und ausführen.“ Ja und das nur 1 mal, lern lesen verdammt. Man muss 2 anwendungen offen haben um multiplayer basierende spiele auch ordentlich zu testen, und das funktioniert im Studio nicht... (ausser natürlich die exe irgendwo zu extern zu speichern und dann 2 mal ausführen was totaler quatsch ist)“ Wow Tice, nen schlechten Tag erwischt? Ich denke die meisten Personen, die ine Multipl…

Grundsätzlich ist es einfacher wenn du einfach nur sagst, dass der Spieler links gedrückt hast. Im Spielerobjekt des anderen Spieler fragst du dann, so wie du für deinen Spieler abfragst nur ab, ob die Taste gedrückt ist. Ab besten legst du dir im Create-Event Variablen an: GML-Quellcode (4 Zeilen) Bei deinem eigenen Spieler, den du mit der Tastatur steuerst, setzt du diese Variablen im step Event: GML-Quellcode (2 Zeilen) Bei den anderen Spielern setzt du diese Variablen, sobald der Spieler sen…

Zitat von funky-destroy: „Das mit den x und y im Stept ist in Ordnung, solange man dafür UDP verwendet :)“ Ja, allerdings muss das auch nicht sein. Bei Spielerbewegungen kann man zum Beispiel nur Übertragen, dass der Spieler eine Taste drückt/loslässt. So kann man die Spielerobjekte auch leichter verwalten indem man z.B. Variablen für die gedrückten Knöpfe benutzt, die eben entweder durch richtiges Drücken gesetzt werden (das entspricht dann dem echten Spieler) oder durch das empfangen der Drück…

Also größere Sachen wie das Entdecken eines Spielers würde ich beim Server belassen, bzw. beim Master. Den Bewegungsablauf kannst du in den Clients lassen, der Master muss nur allen clients sagen, dass Zombie1 Spieler4 gesehen hat. Mit dieser Information können die Clients schon genug anfangen, um daraus den Zombie zur Aktion zu bewegen. Es ist nur eine Art der Umsetzung und wenn man es gut macht, braucht man wirklich fast keine Daten übertragen. Aber falls dir das zu kompliziert ist, machs so w…

Ein kleiner Hinweis: Wieso im Sekundentakt die Position übertragen. Sag den Clients doch, welchen Spieler der Zombie verfolgen soll, bzw sende die Koordinaten nur wenn sie sich ändern. Die Bewegung zu diesen Koordinaten kann dann jeder Client selbst übernehmen. Eventuell zwischndurch mal die x und y Koordinaten zum Ausgleichen senden. In meinem aktuellsten Spiel hab ich es ähnlich gelöst: Die KI bewegt sich anhand eines Grids, über welches Pfade berechnet werden. Die KI sucht sich nun serverseit…

Wo ist das Problem? Im Create oder Initialize: GML-Quellcode (2 Zeilen) Dann erhöhst du immer nur global.punkte. Im Step: GML-Quellcode (5 Zeilen)

Funktionieren tut es, so werden vemrutlich 99% der GM User ihre (zumindest am Anfang) Leveleditoren programmieren. Ob das ganze sinnvoll ist, kann man grundsätzlich nicht sagen, das kommt aufs Spiel drauf an. Grundsätzlich ist die beste und performanteste Lösung wahrscheinlich das Speichern als Binärdatei und eben ein entsprechendes Speicher/Ladescript zu schreiben. Vorteile: Code ist nicht aus der Datei ersichtlich, Datei ist um ein vielfaches kleiner, Ladezeiten werden vermutlich geringer sein…

Wenn man es ganz genau nimmt, ließe sich sowwas schon machen, man müsste das System natürlich ein bisschen erweitern. Das ganze ist sehr umständlich, aber hier ein Denkansatz: Für jeden Raum muss es die Information geben, welche Räume an ihn grenzen. Dann muss zu Beginn des Spiels einmal in jeden Raum gegangen werden und dort ein Screenshot auf ein Surface von diesem Raum gemacht werden. Im Spiel selbst müssen jetzt die passenden Surfaces an die Ränder der Räume gezeichnet werden und sobald der …

Zitat von DragonGamer: „Übrigens, wenn du die 39 Dll benutzst, könntest du mit etwas mühe durch aus einen Server in C++ zusammen bekommen. Je nach dem was er machen muss. Aber da die 39 Dll in C++ geschrieben ist, hat man zumidnest schon mal die selben dazugehörigen Funktionen wie im GM.“ Die 39dll benutzt aber winsock, das kann wine zwar "emulieren", wär dann aber erst nicht nativ auf linux zum laufen zu bringen.

Ich wüsste jetzt nichts davon, dass die Firewall eine DLL anhält bzw. pausiert. Die Log sieht auch normal aus, dafür, dass eben die UPnP Unterstützung nicht funktioniert.

Zitat von DragonGamer: „Wäre aber schön wenn die DLL nicht von der Firewall verwirrt werden würde.“ Ich bin mir nicht sicher, ob das lösbar ist. Grundsätzlich werden alle resourcen in der DLL vor dem Barbeiten/Freigeben überprüft, möglicherweise hat die Firewall da irgendwie eingegriffen. Falls du im Debugging Modus getestet hast, kannst du ja mal die Log anhängen.