![]() Even if it intersects with the shuttle it’s still not checking collision for any entities on the shuttle’s data structure, because it’s still on the map. As it is on the map it is only checking collisions on the map. Say we have an entity on the map travelling towards a shuttle. However, this gives rise to problems 2 + 3. This means that whenever the shuttle moves we only have to update the shuttle on the map. The solution to this is store all of these entities relative to the shuttle, and then store the shuttle relative to the map. On our small station called Saltern we have over 5,000 entities on it so this was prohibitively expensive and would severely limit any server that wanted to have multiple moving ships. Previously, these were all stored relative to the map, which meant that whenever a shuttle moved every single entity on it also needed to be updated in our data structures. What physics bodies am I colliding with?.We have several internal data structures that store entity positions for fast queries, such as: ![]() When the shuttle moves it needs to apply collision correctly with anything it drives over.Ģ + 3 won’t make sense until we explain the challenge in implementing 1 and how the solution gives rise to problems 2 + 3.We need to make sure that anything that collides with a shuttle correctly does collision.When moving the shuttle we need to make sure that every entity on the shuttle doesn’t need its positions updated.To implement shuttles into SS14 there were 3 main challenges that needed to be overcome: For SS14 you’d typically only have 1 active at a time. These are just discrete planes that stretch to infinity and the only way to go from one to another is via teleportation. Maps - These are what other engines would call “Worlds” or similarly “Z-Levels”.Entities - These are objects in-game such as a crowbar, a wall, a mob, etc.Profit?īefore we explain why shuttles were hard we need to explain some terminology up front: We’d like to try an in-game help system of some form first, but nothing is set in stone yet on that regard. We’re not planning to have a wiki for actual game content yet. We are still in the process of moving articles over and making everything look nice, but so far we’re quite pleased. It’s not the best but it’s the best option we could find. ![]() We evaluated a few options but eventually decided on self-hosted Wiki.js as a platform for our docs. Because of this, we have decided to start moving away from HackMD. HackMD had some nice attributes like live editing and being simple to use, however it lacked in other areas like access management and navigation. ![]() Previously, we used to host all development-related documentation (technical documents, tutorials, vague and questional design dumps) on HackMD. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |