I've had several requests in the past year to re-release the vehicle library I had made. I originally removed it due to bugs that were so imbedded into the core framework that it would require a complete rewrite; something I was not prepared to do. However, with the advent of SwapMaps by LummoxJR, I have found more and more reason to rewrite the lib.
This library is designed to allow designers to make large vehicles with more realism. You can make a cargo ship 3 tiles long and actually represent that from the inside. One of the primary features of the library is the use of internal maps (via swapmaps) to give players the feel of actually being on/in a vehicle. There are two other parts to the current system: a console and a hatch. These two objects are integral to the system. The console is what allows players to pilot the ship and the hatch is the entry/exit point.
Now I would like some input from the BYOND community. What other features would you like to see in a library such as this? I am already working on support for multiple "rooms" within the vehicle. Should I go ahead and add support for "turrets"? Turrets would be places designed to hold weapons for the passengers to use. However, another application of them would be windows/viewports. Just don't add weaponry and all they do is move the player's view to that of the outside. What other things should there be that I haven't mentioned?
ID:153312
 Jun 15 2004, 7:49 am
|
|
|
Jun 15 2004, 8:39 am
|
|
Garthor
 |
Just have veiwports and put in some hooks to allow users to modify them for whatever.
|
I had considered that. However, one thing I've always sucked at is figuring out what hooks to provide and how. Any suggestions?
| |
I imagine you already thought of this, but speed control is always good, and if you are piloting the vehicle, a hud to create the windsheild/dashboard would look great, but I don't know how well the engine could handle that.
| |
Basically, make it so that there are procs that are called on the viewport whenever the player tries to move or presses .center.
| |
In addition to the multiple viewports*, make sure you implement multiple consoles, such that each console can perform different functions when the player presses movement keys. That is, by default, a console would just be mapped to the vehicle controls: player taps Northwest(), console registers Northwest(), default action causes vehicle to sideslip left (or whatever)... but another console could have player taps Northwest(), console registers Northwest(), gunscope targetting reticle moves northwest on the tactical sensors. And so on.
* As Garthor said, just ignore the turrets (or release them in a demo project/optional expansion library), since a savvy developer can make his/her own via viewports. | |
omg. that is a great idea! Umm some things to add, what would the player see when he was in the vehicle. i understand its not like the cars from GTA Online or anythng and that it looks like your inside. Will you see the road moving? Turrets, great idea! Lets say it was a tank, one person drives and the other person could control the turret on top by sitting in the seat. when doin that dont let the player move and just do something kinda like this
client.North() if(usr.canuseturret==1) far(var/a fsdhfsdkj) a.tnorth() else step(NORTH,usr) i bet u already knew that but its just a little demonsrtation. :) XD | |
The multiple consoles you described would be handled through viewports, although I suppose I could restructure the lib so that the normal console is a tailored viewport. That would keep things standardized and show developers how to play around with viewports.
| |
Konamix wrote:
whats a viewport? A concept exclusive to this library. When using a viewport, instead of seeing the interior of the vehicle (i.e. the interior map), the player's camera moves to the exterior of the vehicle (i.e. the game/world/space map). In other words, players actually exist on a little "vehicle map" whenever inside a vehicle. To actually see out, they have to go to a viewport, which moves their camera from the interior (looking at the passengers) to the exterior (looking at the area outside the vehicle). With really simple vehicles -- say, street cars -- it's quite likely that developers would just assign passengers to viewports automatically upon entering the vehicle. | |
Exactly. Thank you Spuzzum, for putting it so well.
The current incarnation uses a Console object to keep track of things such as who's piloting the vehicle, various "permissions", etc. The console was also used to verify vehicle titles and ID cards. A title automatically grants full permissions to the person holding it. An ID card could have multiple permissions set on it. The idea being that a title was required to remove a vehicle from storage, etc, even though I hadn't gotten far enough to consider garages and such. However, by converting to a viewport standard I can leave functionality to the developer. I'll provide basic examples of how to use a viewport to pilot the vehicle and provide basic hooks like Garthor mentioned. Each viewport would have procs that are called from client.North(), client.South(), etc. By default, client.Center() would return you to the vehicle. Additionally, each viewport will have procs that handle the client.eye and other matters of transferring the players' perception to the exterior, allowing a developer to, say, use a HUD to facilitate returns. | |
sapphiremagus wrote:
Each viewport would have procs that are called from client.North(), client.South(), etc. By default, client.Center() would return you to the vehicle. It would be easier and more compact to override client.Move() instead of overriding each direction individually. You can look at http://developer.byond.com/hub/Shadowdarke/ SingleTileMinigameBase for an example. | |
