Space Pod Design and Balance

[IK3I]

 

So, as several of you have probably noticed, I've been working on bringing pods back as a source of things to do on the station. The first step of that was adding locks which is currently pending approval on github. The next steps are fixing some balance issues with pod interactions. This is where I need input as what I think is balanced, is not necessarily going to be what other people think is balanced. We could also use this thread as a place to suggest any systems or features that people may want as I continue to work on these changes.

 

Now then, the current issue at hand is this:

How do we fix the issue of someone stealing a pod and sitting inside it?

My current thoughts are this:

 

• Mechanic spawns with skeleton key that works on all pod locks other than the sec pod

  Make Keys stackable so mechanic can have a keychain for thier pods

  Security [and the CE] gets a lock buster that will remove/destroy a lock system after a given period of time

  Make the Ion Rifle act as a pod disabler that will temporarily EMP any pod with civ armor for a few seconds

  Make grab intent or mouse dropping the pod on yourself when unlocked pull the occupant out

 

 

Additionally, known bugs and issues that need to be patched will be listed here. If I miss anything, please let me know.

 

• Occupant code needs cleaning/refactoring

  Items dropped in a pod are forever lost to the void that is the space under the seat

 

 

I'd like to get as much input on these and alternatives as possible. My goal is to make pods both fun to use and balanced so the more people I can get on board with suggestions and assistance, the sooner it can become a reality.

 

I'm gonna link to each PR devoted to this as they are made so anyone who wants to take a more active role in development can comment as it's happening.

 

PR #4301 - Adds Pod Locks

 

 

Edited April 30, 2016 by Guest

[Keroman]

 

More interactions with spacepods are a big ol' thumbs up from me.

 

Mechanic spawns with skeleton key that works on all pod locks other than the sec pod

Kind of iffy on this one. Didn't your PR with the pod locks include a way for a player to create (or at least assign) a key for a given spacepod? I can imagine having an unassigned key, using it on an unlocked pod, and the key now functions only with that pod. Maybe add key blanks to the spacepod fabricator for, say, a cost of 5000 metal (the Mechanic will have more than enough leftover metal from creating their spacepod to make at least one spare key.)

 

Security gets a lock buster that will remove/destroy a lock system after a given period of time

I'm all for there being a way to override locks, especially if the Mechanic or Pod Pilot lose their key and need to retrieve their pod. While it makes sense for Security to have one maybe have one in the CE's office at roundstart as well?

 

Make the Ion Rifle act as a pod disabler that will temporarily EMP any pod with civ armor for a few seconds

The ion rifle already drains the pod's power cell within a few hits, effectively making it a sitting duck. This works on the sec pod too.

 

And make grab intent or mouse dropping the pod on yourself when unlocked pull the occupant out

Sounds good to me. While it would be nice for there to be some way for the person inside the pod to resist being pulled out all that would mean is that they're forcing security or whoever else to blow up the pod with them in it. A completely depowered spacepod is defenseless and so, too, would be anyone inside of it until they're pulled out.

 

[IK3I]

 

Kind of iffy on this one. Didn't your PR with the pod locks include a way for a player to create (or at least assign) a key for a given spacepod? I can imagine having an unassigned key, using it on an unlocked pod, and the key now functions only with that pod. Maybe add key blanks to the spacepod fabricator for, say, a cost of 5000 metal (the Mechanic will have more than enough leftover metal from creating their spacepod to make at least one spare key.)

 

That's actually exactly how it currently works in my code. The difference is that you have to remove the lock system to grind a new key for it otherwise anyone could just break in to the mechanic's shop, get a blank and have a one time all access key for stealing a pod. As for the skeleton key thing, that was something I was kind of questioning myself for obvious reasons. Perhaps I'll add a keychain item (made by stacking keys) to make the mechanic's key collection manageable so they can make their skeleton key by collecting a key for each pod they make. Also, because keys are tiny and designed to have extras easily available, they are currently quite cheap with the lock itself being the primary cost of the system as a whole.

 

While it makes sense for Security to have one maybe have one in the CE's office at roundstart as well?

 

This is actually a good idea, though I'm still not sure as to how long it should take to crack a lock. Considering it breaks it, 10 seconds seems fair to me as an active pod would easily escape in a window that large.

 

Speaking of timing, 5 seconds to open an unlocked door and rip someone out seem fair?

 

[Keroman]

 

As far as key blanks I was thinking a blank would only work on a pod that's unlocked. If you forget to lock your pod and someone runs up and makes a new key from a blank (especially considering they could only get blanks from the Mechanic's spacepod fabricator) then that's on you.

 

10 seconds for removing a lock and 5 seconds for pulling someone out of a disabled or powerless pod sounds fair to me.

 

[IK3I]

 

As far as key blanks I was thinking a blank would only work on a pod that's unlocked. If you forget to lock your pod and someone runs up and makes a new key from a blank (especially considering they could only get blanks from the Mechanic's spacepod fabricator) then that's on you.

 

The reason the keys work the way they do in my code where you have to pop the lock out to make a new key is not only because it's a step that any mechanic can do in 5 seconds, it's also so that the code can stay modular and uncluttered. It also ensures that you're intentionally grinding the key so you can't accidentally do it because there's no way to revert it short of var editing the key's id back to 0.

 

[Keroman]

That's actually pretty well thought out, then. I'm all for it.