Well in my opinion it is way to much devtime (resources) for little to no use. Either real walking in a ship or we have to cope with no walking in moving ships as the devtime is better spend elsewhere. Real world examples don't work, because in real world you can not separate the physics outside the plane from what is happening inside the plane. In a game you can. And if you separte the variables it has the same effect as eliminating most of them. Since players moving within a static grid (coordinates) which moves on its own grid the server only hast to predict where the ship is going, and where every player is going in the ship separatly and not every player in relation to the vessel on the same coordinates grid. Games are not bound to how realworld works. That is a huge plus. You don't need to know how physics work, you just need to have an idea how physics should work in certain cases. And that is also a huge difference. I am still on board. Problems are not shortcomings. A shortcoming to me would be to have a very limited mechanic with little to no use. But maybe i am wrong and you can enlighten me: where is the use of getting out of a seat only: - if the ship holds it velocity - holds it direction - the player can only do certain things - the mechanic prevents reacting on sudden events Because you either have to get everyone to get back to their seats in order to react to sudden events (changing course to fly to or away from something, fight off or attack something) or they get teleported to their last "freezing position", which will also require that the same person putting the vessel in cruisemode has to be the one to end it, otherwise you either have two people sitting in the same seat, or one gets left behind in space. So where is the advantage of your method? Gameplay wise and system wise (preventing callculation failures)? And we are not talking about getting out of the seats just to walk around and look through the windows. The most basic thing, jumping out of a seat while the ship is going to autostop soon, just to get to the door quicker is not possible with your method. Or dropships where you fly close to the ground and your freinds go to the open shutters in the back, jetpack jumping out above a target neither. With my proposal both is possible. If you define the vessels coordination system to on block further out as the last one of the outer layer of the ship, you could even do wing walks, and walking across the ship on foot midflight to clean the windshields. As long as you don't jump, because than you change from the vessels coordination system to the playfields coordination system. You could even do that in a SV moving in an CV. Because the machine only needs to know that the player is in the SV (yes/no), and the ship is in the CV (yes/no) but they are not moving all in one and the same coordination system all at once in direct relation to each other, because movement of each entity on each of the grids is separated from each other. I can imagine that gets rid of 99% of the sync problems and prevents glitching out pretty good.
Thats possible to realize in a CUSTOM game engine, with a custom physics engine. If such a feature is planned from the beginning, its not that hard to implement. But in Unity there is no (or no trivial) way to have two separate physics system running at the same time. - one for the ship, and ne for the players within the ships coordinates. So you have to either live with the glitches that will occur when running everything in the same physics-world. Or create a custom movement controller when in a moving ship. (wich is either very complex to create, or limiting the players to a few predictable actions)
It is not a question about wanting such a feature, but if it can be implemented without too much issues. In theory you can code whatever, just that there is a limitation to performance AND time to code (into existing code) and test. Add that this is not for 1 vessel and 1 player character, but might be 100 at the same time on a server, in a PVP battle, calculating movements, damage, weapons, and so on. To have a proper character/vessel movement system on a moving vessel, there are many issues. Like now if a HV is within a CV "box" and not docked, the CV refuses to move. Then some want to have multiple docking options between all the vessel types, add that too. Then maybe add cargo mass calculations. Then "physical" conveyor system issues. Then wheels you have to put on all of it, so can drive on other vessels and asteroids and planets and moons and ...
Well than we are stuck with this system because of the chosen game engine. But i must say this movement controller you mentioned seems to either exclude player models from certain physics calculation, or how should i think about that? With that said, i am pretty certain that it is not "limited actions better than no actions" to me. What are actions, as limited as they are, use if if you have no actual gameplay reason or use out of it? So you can get up, following a certain path. But that is only useful for changing stations mid flight. No on the fly dropship action, and not even a move like the simple "get out of the seat while the ship stops slowly automatically while you are on the way to the door".
Well you cant (should not be able to) jump around then, but be restricted to the floor of the marked walking area. Any fully simulated movement requires not only collision detection (that could be implemented in this system) but also collision reaction (wich requires the physics engine, wich cant give useful results in this scenario - using the standard Unity implementation). In multiplayer, the players could run around while waiting to arrive, look at the outside, look at each other, look at a plant, operate the devices. If the whole thing is adding enough gameplay value to warrant the additional development (and testing) costs is another question. In singleplayer there would need to be an autopilot. The player enters the destination, and can go about his business (crafting, looking at plants). The whole "walking on ships" and autopilot can offer the ability for the game to have longer travel times, without boring out the player. If the player is stuck to the cockpit or seat, the game should limit those to acceptable levels. Crafting in Empyrion is not very exciting on the other hand. Its very automized compared to other survival games. Not much manual work, and thus not much of a time-sink. Building/altering the ship while travelling is somewhat possible, but could lead to a number of edge cases ... Overall, the priority of development should be on other things than walking around in ships. There are many other potential features that could offer a lot more gameplay value given the development costs.
Fair enough, in my opinion having a "downgraded" version of walking on moving ships is still better than nothing and well worth the effort. The whole point of freezing players is to not have to get back to their seat, they stay where they are and can't move until the ships enters cruise mode again. Preventing callculation failures because if you put conditions for walking on ships than the system doesn't have to worry about variables like rotation acceleration pitch yaw roll ... and if those variables change the system doesn't have to calculate anything, it just needs to freeze the player in its last position. And why couldn't you ? if you know that the ships will stop soon you just have to move before it starts decelerating, and I don't know why you're saying jumping out of a seat because with this proposition you don't have to be in a seat at all. You absolutely can if you time it right, you just have to be in cruise mode when you fly by the target, and you can already do it right now if you stop the ship to let them out, so I don't know where you're going with this. What proposition ? can you point me to it ?
I'd guess that heavy-lift coding went to other features in the meantime. Personally, I think I'd rather see things like sensors, shields, and research added before the devs tackle this issue.
We found a possibility to potentially make this work, but this resulted (or will result) in a really major rework we cannot handle at the moment (it is not only walking, it relates to nearly any collider in the game might need to be rewritten). No worries, the feature is not forgotten
Good news indeed! Any idea if the collider rework would be expected to have performance implications?
If it does have any value and helps....I used to try tutorials for educational purposes with Unity. So in theory... 1. If Capsule Colliders are used, there is not much impact in performance, but those coliders are not precise for the shooting part of games like Empyrion. Imagine this type of collider as an invisible tube the player, the enemies etc are always inside. Same goes for building blocks. 2. If Mesh Colliders are used, then a low poly version of the mesh needs to be used on prefabs (models). This might have impact in performance depending on the number of polys of the mesh. The precision is better. The bullet is meant to hit i.e. the head and it hits the head if the player aims the head and not the space between the shoulders and next to the ear. Imagine this type of collider as an invisible suit that the player or the enemy is always wearing. Same goes for building blocks etc. Surface collider is different. Of course EGS is using colliders already. What are write here are for educational purposes. Sources : Space shooter in Unity. Colliders in Unity
So, someone has to say it: "Passengers, please take your seats, fasten your seatbelts and place your tray tables in their upright positions. We are about to enter the atmosphere and cannot do this until everyone is seated."
Sure, but if you have watched Star Trek you know they don't stay seated in their places while travelling many times speed of light
Yeah, but they don't travel at the speed of light when entering atmosphere either. All of that aside, I just don't think the physics of the current game engine can handle the transition into atmosphere (different playfield) while players are standing/walking in the ship without causing a huge drain on the CPU (client or server, either one) without major, MAJOR game optimization which should come in the BETA stages. We can all dream that it will happen someday. But, I just don't think that it's going to happen any time soon, given this is a small development team who are working on ALPHA bugs first. They're not ready for BETA.
Well it's on their list. This is something we all on this forum talked about years ago and I believe it was on one of the surveys. . So it's expected in my opinion. Whether it happens in Alpha or Beta is another thing but it's a must have for a Space game in 2019. . Anything short of that would kind of make the game outdated.
I'm not sure why you would think it does, we discussed this through earlier in the thread i think. There is no extra work involved moving player along ship, in fact the game already does that by keeping player in place inside cockpit block. It's just the side-effects this system would cause that need solving too. Like what if you exit a ship moving in cruise mode, it's going to go on and on and on, leaving you behind? Or if you go spacewalking on the roof, can you use jetpack to float, and how far of it? Do we want an invisible bubble that you can't escape, but then, when can you? Only when it's completely stopped?
