Hey, thanks a lot for the kind words!
1) yes, we have our own level editor, but I wanted to save some time on the map editing tool, so we decided to use Tiled, which has an open format. So we build the tile maps in Tiled, then drop them into our own editor, and add enemies, lights, scripts, etc.
2) that’s a tricky question. I think it really depends on what you want to achieve: if you are interested in making games first and foremost, and see coding as the means to achieve that goal, then Unity will definitely get you there faster.
If on the other hand you are interested in *how* games and engines actually work, writing your own code will be a priceless learning experience. It will definitely take you longer to get there, but in the end you will have a much better understanding of what your engine is actually doing, why it works or doesn’t, how to make it work better / faster, etc. than you could ever acquire from using a closed WYSWYG engine.
I know people who have jumped into game development starting with Unity, and a couple of years down the line are able to make prototypes and small games, but have no real understanding of what is going on behind the scenes, why their game is performing poorly, what a profiler is, etc.
So think it really depends on what your goal is, whether you want to get there faster or with a more solid base, and as always it all depends on what you are willing to invest into it
(also even if you are making your own engine, it doesn’t mean you should write *everything* from scratch, most engines use middleware to some extent - for example physics, networking, etc. - which is integrated in the engine so that the other parts of the engine can use it seamlessly)
3) As Cyangmou already mentioned, it’s a mixture of both: small particles can re-use the same sprite, with some squashing and re-coloring. However most debris in the game actually have a shadow-sprite, because it just looks so much better ^_^
4) For online play I’m currently relying on a library called RakNet, which manages connections, NAT punch trough, lobbies, replication, etc. for you. The engine adds a layer on top, which manages the replication of game entities across all clients.
I’m going to grossly simplify here, but it essentially works like this: when an entity is created in the game - a player, an item, a piece of debris, a bullet, etc. - the engine makes sure that this entity is registered with the “replication manager”.
In turn the replication manager ensures that all entities registered with it are present on all connected clients (and automates creating and removing local copies when the entity dies for example).
As you play the game, the replication manager also ensures that all copies of an entity are synchronised, so if for example the position of the entity changes, the change will be replicated across all clients.
Of course this doesn’t take place fully in real time, so you need to use things like interpolation, input prediction, etc. to avoid entities jumping around rather than moving smoothly, but essentially that’s the gist of it: if something exists on one side, it is replicated on all sides so all players see more or less the same thing at any given time.
There’s a lot more to it obviously (who should have the final say on what happens to an entity? what if you need to generate something “randomly”, how do you make sure the random value is the same on both sides? what if somebody joins in mid-game, how do you sync the current game state efficiently? etc.) but thankfully there are also a lot of resources and tutorials online
If you have a c++ environment set-up, you can also just download RakNet for free and look at their code samples, that should help answer some of your questions (and will probably give you a lot of ideas of cool stuff you could do with it
).
Thank you again for the kind words of encouragement! I hope you will enjoy the upcoming updates even more, we got some cool stuff brewing
Community
