Cooking for Fun

As you may have read between the lines of my previous posts, I really enjoy cooking. It doesn’t matter if I’m cooking just for myself, or if I’m preparing dinner for my girlfriend and me, cooking in general fits me pretty well. I think this comes from the very short feedback-cycle in cooking: you know pretty quickly if your combination of ingredients works out and if they don’t, you can still try to save the dish by adding other flavors into the mix.

The meals I enjoy the most are meat with rice, rice with various souces, noodles with different combinations of spices and cream, and especially taiwanese and indian curries. Sadly, I wasn’t able to reproduce the curries my father likes to prepare for dinner, but I’ll be able to cook them on my own one day. Until then, my girlfriend and I are satisfied with our current food, which we now can make pretty fast and without much effort.

I am not really a fan of following a cookbook. Instead, I prefer inventing my own meals and experimenting with combinations of spices I find in the shops in my surroundings. The Hong Kong Shop in Linz for example is a great source for all kinds of ingredients, which mix up the standard taste of austrian food in a good way, and make eating your own meals even more fun.

If you want to share your recipes with me, I am really open for comments and recommendations! I can write down and polish some findings of my own and publish them too, so wen can build up a small library of good combinations on our own 🙂

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.


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