Game Development Community

Moving around INSIDE vehicles?

by John Vanderbeck · in Torque Game Engine · 01/13/2004 (3:54 pm) · 67 replies

Ok bear with me as this might be hard to explain. Heck the topic doesn't even probably make sense so thanks for taking a look :p

I've never to my knowledge seen this done. It would be extremely difficult even in my own engine, so doing it in Torque is beyond me as i'm still learning the ins and outs.

What we need to do is have very large vehicles which allow players to move around inside them. As an example, take a submarine. The submarine is a vehicle which moves around the map under the control of one or more players. In the normal sense for torque these players would be mounted into the vehicle. This is traditional for vehicles. Heres where it gets tricky. Instead of mounting players into the vehicle, I need them to be able to move around inside the vehicle (or on top of EG an aircraft carrier) just as if they were moving around on the map. Imagine for example standing on the deck of an aircraft carrier. You are on the vehicle, and the vehicle is moving ikn relation to the map. You are also free to move around on the vehicle though. Fights will take place inside and on these larger vehicles.

Does that make sense? If so this is probably the point where i'm told i'm crazy and its impossible. Unfortunately that word isn't what I want to hear :) I'm not asking anyone to write this for me, but point me in the right direction. The lack of documentation for Torque makes it very difficult to do anything that is outside the scope of "hacking tribes 2".
Page«First 1 2 3 4 Next»
#61
02/21/2008 (6:34 pm)
Or....
www.garagegames.com/mg/forums/result.thread.php?qt=57187

You could modify my psudo resource to attach players to the vehicles. provided they have proper colision meshes setup, it shouldn't be an issue.
#62
02/22/2008 (3:36 am)
Here is an example of Ramen's code I am using for my game.

Edit : Fixed dead link
#63
02/22/2008 (9:39 am)
Thanks, I meant to get that link in there when I mentioned the resource but I'm incredibly lazy. =)
#64
07/25/2008 (2:30 am)
Sorry for the threadomancy... it's only a few months old!

Quote:Whether this effect is worth the trouble is a totally different discussion. There could certainly be synchronization errors in real-world multiplayer (never tested that). A cheaper approach is to simply fake it; put the player into a static model of the ship outside the normal bounds of the level and have them interface by remote with the actual Vehicle object. The disadvantage here is obvious: you can't actually see anything that should be happening outside the vehicle (if it has windows, for example) unless you're controlling it from 3rd person view. This really wouldn't work for anything but a submarine or spaceship, as either one of those can get away with having no windows.

Note that in TGEA you could get away with placing a camera on the actual Vehicle object and rendering its view on a viewscreen, though this is a potential performance sink.
This can be done in TGE. The key would be to understand transform portals, like those used by MirrorSubObjects. If you add a mirror to every window in your staticmodel, the windows will look like mirors. Okay. Then modify the mirror code so that instead of showing a reflected view, they show a view of somewhere else. I believe this can be done; I just don't have sufficient understanding of transform portals to do it.
Then players could look out of the static object - seeing the actual environment of the moving object. You could even add triggers so that if a player collides with one of these portals, he is placed outside the corresponding portal on the real vehicle and vice versa, so players can easily get on and off vehicles in real-time.
#65
07/25/2008 (7:36 am)
I like the mirror/portal option. I wish someone that understands that code better could look into it.

I have made some progress with Ramens code.
Video
#66
07/25/2008 (10:09 am)
I think I have an inkling of what should happen. In mirrorSubObject.cc, the functions transformModelView, transformPosition and computeNewFrustrum are important (as well as getRenderImage, of course). Used in these functions is mReflectionMatrix (this might be good to look into).
I don't really know how it all fits together, but I do know that computeNewFrustrum... um, computes a new frustrum (the area that defines what is rendered).
transformModelView and transformPosition seem fairly straightforward.
I haven't been abole to figure out what things to in getRenderImage. I tried changing the transform portal position, but that just screwed things up, not in a good way. I'm guessing that the real changes will be in computeNewFrustrum. Of course, that is a complete guess :P.

However, this approach is still cheating (though, learning how transform portals work is still a good idea, for other effects). I'd prefer a physical approach, like attachment or surface friction (shameless plug: see my thread in Engine).
#67
02/18/2009 (8:50 pm)
I think your really onto something here Daniel. Thanks for the information.
Page«First 1 2 3 4 Next»