A spaceship made of dif objects

#1 ???

Do you mean you want the interior to translate? That could cause a lot of problems. What I would do is make the interior/ship stationary, and have dts objects around it, such as ships, asteroids, planets, whatever... be in motion as if the ship was moving. It will give the appearance that your ships is moving.

#2 And the first step would be to start constructor ;)

#3 Well, i would probably say that you are going to need a DTS if youplan to make a ship, as far as players walking around inside it, thats a whole different can of worms, there are several project in the works, such as a monorail(but thats a pathed interior i believe) there is also the submerine project but i believe thats just a mounted player in a vehicle, and doesnt address the players inside issue. though, im assuming if its big enough, there shouldnt be too much of a issue with some code changes (of which off hand i dont what that would be)

but as far as creating large ships out of difs, thats easy enough
Note that all these ships are madein constructor, but dont fly (at least not yet)

#4 I've been working on this issue for some time (players riding inside vehicles while able to move), and I've basically solved it, though there are some remaining issues. If you follow through with these notes, you'll have the same implementation I do; an 80% functional system for Players moving about inside starships.

Before I start, I'd like to point out that Cory is right on the money here. What you want to do is a lot of trouble. It can be done, but if you're making a singleplayer game, consider his suggestion. The illusion is perfect for singleplayer, or when all players are onboard the same ship (IOW, co-op only scenarios). The only issue here is that you'll need to create a "relative motion" simulation, by having every object in the mission move in the exact opposite manner you move your ship, in addition to their own AI-controlled motions.

I'll outline the key points, their solutions, and the remaining issues below:

1) There is a resource available which enables the linking of Players to Path Shapes. This resource, with the help of the original author, has been modified to allow Players to attach to Vehicles (or any other object, for that matter). The result is that Players can, for example, walk around on top of a moving Car without falling off. Note that the Vehicle must be set to ignore collision vs. the attached Player, so that it does not see the Player as something keeping it from moving. Collision of the Player vs. the Vehicle must remain active.

2) The Player object, by default, can only rotate on the Z-axis. This is fine when we're talking about a wheeled or hover vehicle, which should really never be upside-down, and won't likely be at an angle greater than 50 degrees. It also works well for submarines and other naval vessels which only change orientation in the Z-axis (for the most part). You can even use it effectively with Flying Vehicles which are unlikely to be inverted by the pilot (see: BF 2142's Titans).

The problem arises in space sims, or when a smaller, more agile flying vehicle is the subject. Since the Players inside only rotate on Z, they will very quickly find themselves standing on the ceiling. Modifying their gravity to sync with the Vehicle's orientation won't help, since you'll now be standing on your head on the floor.

I haven't gotten around to solving this yet, mostly because it's not a serious concern in my game; generally, in space environments, I force players to stay seated, and only the larger ships can actually be moved about inside. These larger ships shouldn't be upside-down when they're in-atmosphere unless they're about to crash, so it's not a concern. That said, it *can* be solved, however GG devs have pointed at that removing the Z-only limits on Player might be harder than creating a new type of Player class which has full rotation from scratch. My limited attempts to remove the X/Y clamps failed, but I only spent a couple hours on it total.

3) In stock TGE, I don't believe that Interiors (DIFs) have any netcode for movement. So, you could attach a DIF to a Vehicle (I've already done this as a test -- note that this won't work with stock at all), and it will actually work on a local server, but it should completely fail over a network. If you want to use DIFs as your ships, you'll have to make a new Vehicle sub-class which itself has an interiorinstance, or something along those lines. I'm not going to include details because I didn't pick this option in the end.

4) Ben Garney recently (well, a few months ago) released a Polysoup implementation which is absolutely perfect for DTS-based interior-collide-able starships. The catch? Here:

-You'll have to implement this resource yourself, it's not plug-and-play (but if you're thinking about getting this all working in the first place, you're already getting into some heavy code-slogging).

-You'll have to make sure that Polysoup is only used for the stuff going on inside the ship. What I mean is, you'll want the Vehicle's collision detection to use its actual Collision Mesh, like it always has, and you'll probably want to use that when raycasting for weapons/projectiles as well. Using Polysoup for either of these would likely be a massive performance hit.

-To simplify: Polysoup should *only* be used in Player vs. Vehicle collision scenarios, and *only* in regards to the Vehicle's mesh (the Player should still be treated as its bounding box).


Okay, there you go. Follow 1 and 3/4 (I prefer 4), ignore 2, and you've got a pretty solid system that works unless your ship turns on its end. Solve issue #2 and I'll be happy to trade code with you. :P

I'd be happy to discuss this whole situation with anyone else who's working on it. Feel free to respond here or email me.

I'll be back later when I have more time to add some links to the appropriate resources.

#5 The first thing you want to do is get movement working with interiors, as Henry said above.
If we assume that the ship will never change rotation, it'll be a lot easier. If you want rotation you're in for some serious math that I couldn't handle myself. I failed math back in school so don't let that discourage you.

When you got the basic movement in, you need to take a look at Player::updateMove () and Player::updatePos (). You need to know if the player is inside a ship, so either cast a ray below the player or keep checking what zone he's in. If he's on the outside zone, you're either not in the ship or ontop of it.

When that's done, process movement as usual from the player but with the addition that you add the interior's speed to the player's before you return from updatePos (). That's AFTER we process collisions, not before or you'll get into problems with jittering if you run into a wall inside the interior. You only want the collisions to affect your movement speed, not the speed you inherited from the interior.

Rotation is a whole lot worse since when the ship rotates you have to account for that when positioning the player and you'll have to change the interpolation code for it to look smooth. It was something we tried but gave up on (because of lacking knowledge on how to accomplish it) and instead changed our design to not let the ship rotate.

Hope that helps someone.

#6 I got lost in Bioshock for a day, but here's the link to the resource which will get your players attached to, and moving relative to, your vehicles.

http://www.garagegames.com/mg/forums/result.thread.php?qt=57187

You'll want to download the 'riding on moving platforms' resource from the links in the original post, then you'll want to read the discussion there. Note that the resource creator only posted his full source files, not the changes, so you'll have to either have unedited copies of those files in your project, or go to WinMerge (or your preferred merge app). Should only take a few minutes.

Don't blind-merge; the changes aren't especially complicated, and you should probably read some of it. You'll want to know how to attach objects to other objects and how the resource accomplishes the automatic attaching of a Player to an object it's standing on.

If you go down to the part where I start posting about getting this to work with vehicles, you'll see that Ramen-sama, the resource creator, posts a vehicle.cc file which includes this functionality. Merge this, and you're almost done. You'll then need to alter the mods made to player.cc so that VehicleObjectType can be used in addition to (or in place of, if you won't be using elevators) PathShapes. Finally, you'll need to modify the collision for vehicles to ignore Player objects which are currently attached to the Vehicle. This prevents the vehicle from "crashing" into something that's riding in/on it, which causes the vehicle to be unable to move upwards.

If you want vehicles to move around on other vehicles, like being able to land a jet on an aircraft carrier, that takes slightly more work, but it's not too hard. Just look at how it's accomplished with Player while you're merging and reproduce that.

I have this all working 100% for Z-rotation-only scenarios in my build. It does work in vehicles that rotate on X/Y as well, but if the angle becomes too extreme, you'll find yourself standing on the walls/ceiling inside the Vehicle (which may actually be somewhat realistic if you're in an environment with gravity).

Overall, this implementation is very solid for things like aircraft carriers, and large spaceships so long as you're not talking about being in space, where the rotation issues would be a major annoyance. I've tried it over a LAN and the results are pretty decent, though the more layers of complexity you add, the more likely you are to encounter issues in real-life multi-player scenariors.

For this to work with interiors of vehicles, you'll have to either get network-movable InteriorInstances (there's a PathedInterior class.. does that actually work?), or implement a customized version of the Polysoup resource.

#7 I've played around with the same thing for a while in TGE, and have failed to come up with a workable solution...

i've gotten stuff like this to work in 3DRAD and Blitz3D, where a player can move around inside a submarine that was in motion... and the player could also control the subs movements... but in TGE, the only success i've had was to use animated mount points, which really linits the movement to predetermined paths...

also, i needed to lock the view reference so that the subs movement would be noticeable as it pitched and rolled...

the methodology i used in the other game environments was to use an offset value for the x,y,z positions of the rider, and to make the rider a child, whose relative position was determined by the offset values...

overall though, i think that in a space sim, the easiest approach for TGE would be to have the spaceship at the center of the world, and not move at all, and everything else move relative to the ship... this way you would only have to write the centered world simulation, and everything else in TGE could be used (mentioned above i believe)...

anyways... good luck... keep posting your progress...

--Mike

#8 Presumably, your player will be a creature that is capable of sitting at a particular station in the starship and able to walk around the starship and look out the window to see what is going on. Here is what I would do...

I would use a DTS and a DIF for each starship...

Just use a stationary DIF starship and put it somewhere where noone will ever see it, like under the terrain, or in a position way way out in space, or even inside a planet, i.e. just not visible to players. Let your players walk around inside the DIF starship as if it were a regular building on the ground.

Provide special StaticShape objects inside the DIF starship for each station you want them to be able to sit at and let them mount them. When they mount a station, you can do things. For example, you could bring up station related huds and UI's. Another more specific example would be that someone sits down at the navigator's station and can actually take control of the ship and move it around. More on this later...

Provide the players with a DTS starship, a flyingvehicle, for example. Presumably, one of the players who is inside the starship will be controlling the DTS starship using the navigator's huds and UI's. This player is the navigator. You could also switch their control object to the DTS starship while they are mounted in the navigator station.

Use the "Mirror" resource to provide players who are inside the DIF starship a view of what's happening outside of their starship. For example, you could use the mirror as the main screen on the bridge, or you could use mirror objects for windows. Modify the mirror object to take the camera position of a node inside the DTS starship.

Now you are capable of having several kinds of experiences.

1. First person: Your players can look through portals in the starship, the mirror objects, at what is going on outside the ship while they walk around or are mounted at a station inside the DIF starship.

2. Third person: Your players can have the normal third person view of their avatar.

3. A Second, Third person view: Your players can view the DTS starship from the outiside.

If the DTS starship is struck by enemy fire, then shake the camera unless it is #3.

You'll just be using smoke and mirrors (literally) but I think this is the best way to approach what appears at first as a hard problem to solve.

I hope this helps.

Robert

#9 @Robert

That's really pretty good. I've been making gameplay compromises to get around this problem, but the method you describe could actually get a lot closer to what I'm looking for. I'm going to play around with that Idea for awhile.

#10 This is so interesting in that people get hung up on the idea that it needs to "work like the real thing". The entire simulation is an illusion, there is no reality to it. So you basically create smoke and mirrors to get the effect you want. This is a great example. Make it look like you are in the ship and have two different representations. Internal and external. It also allows the internals to be bigger than the externals. Not accurate, but who cares? This is not an engineering project, it is a game! Think "Galaxy Quest", nobody is EVER going to actually build this so just fake it.

I fall into the "it is not real enough" trap all the time BTW.

#11 I think that it's not so much about getting hung up on the "work like the real thing" idea... most devs have gone through, and passed that phase... especially in a case like this...

the whole concept of separate interior/exterior representations can pretty well be accepted as a viable game plan...

the problems, as i see it are when you need to merge the two representations...

in this case, looking out the spaceship windows and seeing other ojects in proximity... in short, modelling a simulation for these objects so that their movements are relative to you being the center of the universe...

and in my case...

rolling and pitching of a deck as the ship i am 'inside' rolls and pitches with the water... i'd like the view to remain stabilized as the deck pitches down, and the player character to not fall through the floor of the dif representing the interior...

the simple route of placing mount points about the interior, and jumping from one to another just seems to defeat the whole idea of immersiveness... inside a submarine, i'd like the player to be able to move from compartment to compartment... just like in the real thing...

ooops, there i go... i said it again :)

--Mike

#12 Didn't somebody create a dynamic mounting scheme? It allowed for a ships deck on the ocean and dials that actually work. That may be what you want.

www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9093

#13 THANKS for the link Frank... i definitely missed this one...

--Mike