tfg13 / spacebatz Goto Github PK

Nach ca. 5 min rumfahren und rumschießen kommen folgende Fehlermeldungen in endlosschleife:
ERROR: CNET: Paket output overflow!!!
ERROR: NET: Paket output overflow!!!

Das Spiel verhält sich aber normal, alle Funktionen gehen weiterhin.

Die Liste der Entities wir zur Zeit in einer ConcurrentHashmap gespeichert. Entities werden einfach aus der Liste gelöscht wenn sie sterben. Teilweise werden Entities gelöschr wärend durch die HashMap iteriert wird.
Es muss untersucht werden ob das zu Problemen führen kann, bevor später unerklärliche Sachen passieren.
Ausserdem sollte man eventuell über einen einheitlichen Löschmechanismus nachdenken.
z.B. wird bei Entities, die entfernt werden sollen eine Flag gesetzt, und der Entitymanager löscht jeden Gametick alle Entities die diese Flag haben.

Die Kommandos in Server- und Client- Message-Sender und -Interpreter mit dem neuen System übermitteln.
Es fehlen noch Kommandos, die mit der Spielinitialisierung zu tun haben. Die werden portiert sobald der neue pre-Mainloop fertig ist.

Ansonsten dürfte alles gemacht sein

Die Positions- und Bewegungssynchronisierung die das alte Netzwerksystem gemacht auf das neue Netzwerksystem übertragen werden.

java.lang.NullPointerException
at de._13ducks.spacebatz.server.network.UDPConnection.sendData(UDPConnection.java:302)
at de._13ducks.spacebatz.server.network.UDPConnection.send(UDPConnection.java:122)
at de._13ducks.spacebatz.server.gamelogic.MainLoop$1.run(MainLoop.java:62)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
java.lang.NullPointerException

Tritt nach ca. 5 min Spielzeit einfach so sporadisch auf. Nicht direkt reproduzierbar, trat jedoch schon etwa 10 mal auf.

Ich will farbigen Text rendern können.

Dazu muss man nur die Buchstaben-Tilemaps von Schwarz auf weiß ändern, und dann das normale einfärben verwenden.

Das ist was schönes für zwischendurch (aka ich brauche das schnell) :)

Die Gegnerverhalten die in Spacebatz.txt dokumentiert sind implementieren.

Der Lerp sollte per Konsolenbefehl eingestellt werden können.
Man muss das testen, eventuell kann man um Ruckler zu vermeiden den Lerp danach nicht in einem Schlag anpassen sonder innerhalb von X Sekunden verschieben

Gegner, die sich nicht bewegen, sind auf dem Clients nicht sichtbar.

Der lokale Mehrspielermodus geht nicht und der normale Mehrspielermodus wurde noch nicht getestet, seit der Umstellung auf das neue System.

Die Grafikengine mus refaktorisiert werden, so dass nicht der ganze GUI-Code in einer Klasse steht.

Wrapper-Klassen die sich um die größe kümmern bei Commands mit statischer Größe.

Das neue Netzwerksystem soll zukünftig selber die Ping-Messungen machen und den NetGraph mit Inhalten füllen. Die Informationen über das alte System sind nicht mehr so interessant.

java.lang.NullPointerException
at de._13ducks.spacebatz.shared.network.messages.STC.STC_EQUIP_ITEM.execute(STC_EQUIP_ITEM.java:30)
at de._13ducks.spacebatz.client.network.STCPacket.runCommand(STCPacket.java:49)
at de._13ducks.spacebatz.shared.network.NetPacket.internalCompute(NetPacket.java:134)
at de._13ducks.spacebatz.shared.network.NetPacket.compute(NetPacket.java:95)
at de._13ducks.spacebatz.client.network.ClientNetwork2.inTick(ClientNetwork2.java:426)
at de._13ducks.spacebatz.client.graphics.Engine.start(Engine.java:173)
at de._13ducks.spacebatz.shared.network.messages.STC.STC_START_ENGINE$1.run(STC_START_ENGINE.java:28)
at java.lang.Thread.run(Thread.java:722)

Interne wie ACK auf >= 0x80 ändern

Meine Damen und Herren, die Arbeit am Level-Generator wurden offiziell aufgenommen!

Schritt 1: Ein gescheites Map-Anzeigeprogramm, das unabhängig vom Spiel läuft.

Das Netzwerksystem muss bei Bedarf deutlich mehr Daten schicken können. Dazu müssen mit unter mehr als ein Paket pro Tick rausgehauen werden.

Die neuen Mobs, die Timo hochgeladen hat, einbauen.

Das Level zu Serialisieren und Deserialisieren dauert zu lange und braucht wegen der Größe zu lange zum Komprimieren/Dekomprimieren. Wenn man das Level selber externalisiert sollte man da viel Zeit sparen können.
Da man das Spiel zum Testen schnell starten sollte ist das relativ wichtig.

Das neue Netzwerksystem funktioniert, jetzt müssen alle Kommandos darauf übertragen werden.
Weiter brauchen wir einen pre-Mainloop der Netzwerkpackete empfängt solange die Engine auf dem Client nicht gestartet ist.

Hüte können gerade einen Schadensbonus geben und selber Schaden haben, der aber sinnlos ist da Hüte keine waffen sind.

Gegner sollen Fähigkeiten benutzen.

Derzeit ändern alle sich bewegenden Einheiten bei jedem Tick ihre Richtung, weil sie und das Ziel sich in der Regel bewegen und der Vektor dazwischen dann eben jedes mal anders ist.

Dadurch werden unnötig viele Infos übers Netzwerk übertragen.
Das Verhalten jeder einzelnen Einheit muss nicht bei jeden Tick neu berechnet werden.
Bitte massiv reduzieren.

Das alte Netzwerksystem fand das schon nicht gut, das neue zickt damit etwas mehr rum, da noch keine Flusskontrolle da ist.

Dieses Issue blockt die Fertigstellung von #18

Entities, die in diesem Bewegungsmodus sind verfolgen eine ZielEntity indem sie Luftlinie darauf zulaufen.

128 Byte sind zu wenig.
Soll ich eine Utility-Klasse schreiben die größere Arrays splittet und wieder zusammenfügt?
Oder wird das noch im Netzwerkmodul implementiert (wäre schöner) ?

Serverseitig eine Wegfindung implementieren.
Die Wegfindung darf pro Tick nur begrenzt Rechenzeit verwenden.
Die Wegfindung bekommt Anforderungen, die sie berechnet. Wenn eine Anforderung fertig ist schickt sie das Ergebnis an den Anforderer zurück.

Das sei hiermit mal zur Debatte gestellt. Ich hab schon oft drüber nachgedacht, ich denke wir können die Server-Tickrate zumindest mal auf etwa 30 runter setzen, wenn nicht noch tiefer.
Nicht, dass wir Lastprobleme hätten, aber mir fällt nix ein, was so schnelle Reaktionszeiten wirklich brauchen würde...

Loot wird an alle Spieler verteilt die am Kampf beteiligt (d.h. in der Nähe) sind. Wenn ein Spieler keinen Platz hat wird das Loot auf den Boden geworfen.

Ich halte das FastFindGrid nach wie vor für dubios. Gründe:

1. Ist SECTORSIZE = 1 wirklich eine vernünftige default-Einstellung?
2. Kann es sein, dass getEntitiesInArea() überhaupt nicht funktionieren, wenn SECTORSIZE nicht 1 ist? Irgendwie vermiss ich da ne Umrechnung von angegebenen Koordinaten in Sektoren.
3. Man sieht deutlich, dass die Klasse mal "EntityMap" hieß. Tipp: Javadoc
4. calulcateEnitiyPositions geht jedes Mal alle Einheiten durch. Das ist heute noch ok, irgendwann (bald) sollte das aber mal anders geregelt werden, Entities sollen Bewegungs/Positionsänderungen direkt da selber anmelden oder so.
   Aber warte damit noch, ich pfusch grad wegen Bewegunssystem an Entity rum, nicht dass es da Konflikte gibt...

Fähigkeiten sollen durch einben kiltree erworben werden.

1. Punkte zufällig verteilen:
2. Voronoi-Diagramm bauen
3. Lloyd-Relaxation drauf werfen, um zu hässliche Formen zu vermeiden.
4. If (noch zu eckig goto 2)

Kann das Netzwerk sich bitte selber um die Nachrichtengrößen kümmern? Es sollte vor jeder Nachricht, die verschickt wird, deren Größe verschicken, diese beim Empfänger dann auslesen und der NetCommand.execute() als Parameter übergeben.