Archiv der Kategorie: Devlog

Erste Schritte mit OpenGL und einer Voxelengine

Da ich leider viel zu wenig über meine Aktivitäten in diesem Blog schreibe habe ich mir gedacht, dass dieses lustige Bild doch vielleicht an guter Anfang wäre wiedermal technische Dinge zu posten.

Erste Versuche mit OpenGL und VoxelenginesDieses Bild sieht nach einem Grafikfehler aus, allerdings stellt es den Anfang einer kleinen Voxel-Engine dar. Die Form, die man rechts sehen kann, ist eine zufällige aneinanderreihung von Vertieces, welche noch absolut nicht genauer geplant wurde. Der erste Schritt war erstmal, durch die relativ komplexe, interne Architektur die ersten Objekte zu erzeugen.

AyonGame ist ein Arbeitstitel für das Projekt (besser als Random Voxel Engine Test) und bedeutet noch nichts bestimmtes. Ich weiß noch nicht wo dieses Projekt hin gehen wird, allerdings werden wir ja sehen was sich daraus machen lässt. Vielleicht kommt daraus ein kleines Rollenspiel oder ein Actiontitel hervor. Wenn sich etwas mehr mit dem Projekt tut, werde ich wieder hier davon schreiben 🙂

lg
Max

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