Schlagwort-Archive: System

Spacegasm Devlog #1: Networking Entities

Synchronizing entities over the network is easy in the beginning, but harder when there are a ton of different entity types and flavors. Every different type needs an own synchronizer on both sides (client & server), which means that you will have to write tremendous amounts of code for a new object in your game.

The first thought that strikes your mind could be „Then I’ll just create a base class for them and store everything in there!“. Well, that could really be a good solution, when there weren’t that many attributes entities can have you have to worry about. The base-class could have a position, a velocity, a sprite, a rotation, a height, et cetera. These attributes are available in every child-class and are all managed by your single synchronizer. That’s fine, but then you get an entity with additional attributes. You would then have to extend your synchronizer and build it to support these new values and you end up with the same manager-mess you’ve had before with even more traffic because of more useless packets (not every entity has a velocity).

Managing Components instead of Entities

The next step would then be to forget all this object oriented entity hell and build up a new system on top of a component entity system (like Artemis & C++ Port of Artemis). This approach is bundled with a new way to think over the entities: They are only combined components and an ID. Entities can be equipped with new components and the components can be updated using an entity-processing-system. You can request components and just work with them instead of dealing with pointless bundles of variables.

You will eventually need some time to wrap your head around this idea, but it works out quite well once you realize how to use it in a good way.

Sync those Components

For network synchronization you will have a system for each component (eventually combined with sort of a chunk-component describing in which chunk the entity is) to send it over the network to the other side and a system there to create or update the components according to the new updates

You will eventually also have a class like a player manager to manage the players. You could throw a screen size manager into this class which knows exactly what parts of the world is viewable by the players (in chunks) and can send packets to only those players who see the chunk the entity is in. This is not necessary when you have a smaller world of course.

When the component packets arrive at the clients, they check if the entity on their side exists and if it has the received component. If not, the entity will be created, the ID from the server will be assigned to it (= GlobalID) and the component gets attached. Else, the component simply gets updated with the new received data.

Low Traffic

This system keeps traffic relatively low, as long as you keep the sending intervals long. I am using a default interval of 1/20s for physics- and 1/5s for graphics-components (less critical ones). Because you don’t have to synchronize everything, you will not suffer from a too big load of incoming or outgoing packages.

Conclusion

I have worked on my synchronization system for a long time, and, because it is a critical part of the game, it has to work without flaws and with a minimal footprint on the resources of the server. I don’t know if I have completed this goal and I still think there will be some major design changes in the future, but this is definitely a good starting point to build up from ūüôā

I hope you could get some new insights about this topic, Max

Minecraft Casino V2

Es wurde jetzt eine neue Version des Casino Systems (Bekannt aus diesem Video) entwickelt! Bilder dazu verdeutlichen nochmal, wie klein die neue Version dank seiner vertikalen und komprimierten Bauweise geworden ist.

Weiterlesen

Mehrere Schematics frei erhältlich

Wir haben bereits einige Schematics veröffentlicht, und bewahren diese alle im Forum auf (Eigener Schematics Bereich). Wenn ihr lso auf dem aktuellen Schematics-Stand bleiben wollt, schaut dort rein!

Aktuelle Schematics:

Was noch an Schematics kommt

Ich habe in meiner Singleplayer-Bau Map viele Gebilde, die ich noch in eine Schematics Datei geben k√∂nnte. Ich muss aber zuerst sicherstellen, dass diese das auch wirklich wert sind ūüėõ

lg max

Auswahlseite wird √úberarbeitet, in wenigen Tagen neu

Ich bearbeite die Auswahlseite jetzt erstmal selber, bis das Projekt vollkommen gegen die Wand gefahren ist und ich es mit ordentlichem Nachdruck in den Papierkorb stecke, diesen 3 mal hintereinander entleere, und dann die Festplatte formatiere, und alles alte mit Nullen √ľberschreiben lasse (kleiner Witz f√ľr Insider ;))

Jedenfalls wird das neue Design (wahrscheinlich) etwa so aussehen:Das wird jedenfalls die neue Auswahlseite. Der ganze Plan, von dem ihr hier einen Ausschnitt gesehen habt, sieht so aus:

Anmerkung: Da der Plan um ungef√§hr 6 Uhr Morgens nach einer schlaflosen Nacht (eine dumme Laune der Natur, die Nacht darauf war der Schlaf wieder da…) ist der Gro√üteil der Schrift unlesbar und alles ein bisschen chaotisch. Der n√§chste Plan, der das ganze dannetwas ausfeilt, kommt sp√§testens am Donnerstag (4.08.)

Wer den Mut hat, dieses Projekt umzusetzen, der soll sich bitte bei mir melden, ansonsten kaue ich mich selbst durch den Quelltext ūüėõ

lg max

PS: Dieses 960 Grid System wird wahrscheinlich zum Einsatz kommen. Es ist ein System, bei dem die Websit in 12 oder in 16 Berreiche aufgeteilt wird. Das k√∂nnte man zwar selbst machen, aber mit dem System geht es schneller, wenn man es ertsmal komplett durchschaut und „kapiert“ hat.