Feedback requested for some game mechanics

As one or two of you might know, I'm working on a Star Trek-like teleporters addon I'll be calling "Beam Me Up!". I'm at the phase where I've got a lot of the core mechanics decided, but there's still room for a little tweaking and I'm not sure which people would like to play more. So I'm asking you guys to give me your thoughts on the matter, hopefully giving me a clear direction.

Before the questions, though, let me explain the core mechanics already in place:

• Firstly, we have the transporters themselves, which can lock onto a set of coordinates and transport any blocks or entities from those coordinates to themselves, or the other way around. Each transporter operates on a frequency, which will become important in a moment.
• Secondly, we have ways of reducing a transporter's effective signal in an area, using either (powered) interdictor blocks (which can be configured to allow one frequency un-dampened) or interdictor grenades, which temporarily dampen all transporter signals in an area.
• Thirdly, we can boost the transporter signal by reducing the required signal to lock onto an area, using beacons which are charged with EUs in an MFE or MFSU and will consume that charge when placed on the ground. The beacons only affect the one block they're standing in and its immediate neighbours, and cannot be teleported while powered. On the other hand, they don't completely occupy the block they're in (they're like torches) so you can stand inside them. Beacons on the ground can be recharged using an energy crystal or lapotron crystal, and their charge lasts about five minutes.

These are the absolute core mechanics that are unlikely to change. Building onto these, we have these derived mechanics and design decisions:

• Two or more transporters on the same frequency will interfere with each other, making it difficult to acquire locks on any given coordinates. The interference is relative to their proximity to each other, so a transporter far enough away won't interfere at all. But wait, there's more:
• Two transporters on the same frequency will boost each other when transporting to each other by halving the effective distance between them. One can assume what's happening is one transporter sends to a halfway point, then the other transporter receives from that halfway point, all of this happening too fast to see. To do this, both transporters use power both for maintaining the target lock and for the actual teleport (Obvious corollary: if one transporter runs out of power, they're not working in tandem anymore).
• Interdictors' effectiveness stacks the more of them are covering an area -- the first interdictor halves the effective signal for any teleport, the second reduces the resulting signal to 2/5ths, the third to 3/8ths of the previous result, and the last to 1/3rd of the result of the other three reductions. An area covered by four interdictors is completely immune to teleporting (possibly barring two teleporters working in tandem, but that isn't a worry).
• However, this increased effectiveness comes at the cost of more EU/t consumed when more than one interdictor is dampening a target lock. The cost, however, does not increase beyond the fourth interdictor, given that the interdiction effectiveness also does not.
• Interdictors also consume EU/t while idling -- presumably, they're scanning frequencies within their range for transport locking attempts. This is a constant consumption that can be turned off only by disabling the interdictor itself (by applying a redstone signal, or using ComputerCraft).
• Beacons have a purely portable version that can be carried in your inventory (on your hotbar, specifically) which is a less effective signal booster than a placed beacon, but allows a transporter on the same frequency to lock onto your coordinates without needing to have them passed in. This is designed to work with wireless redstone to allow a remote teleporter that you wish to have retrieve you to do so.

I'm currently considering the configuration aspect of the mod, and ideally I want to have all the base values be configurable by anyone who understands the inner mechanics. So let's discuss the finely-detailed mechanics of how transporters work:

• Acquiring a lock on a remote set of coordinates requires some "signal" based on the 3-dimensional Manhattan distance to that block (abs(targetX - xCoord) + abs(targetY - yCoord) + abs(targetZ - zCoord)). Currently, this is set to be 1 signal required for every block of distance. A beacon can reduce this by a configurable percentage (currently 20%), but only if the lock is being acquired on the beacon block or its six neighbours.
• Transporters have a base signal value (currently 500) that can be boosted by a percentage of the required signal for a given locking attempt (currently set to 20% of that value), using up to a configurable amount of EU/t (currently 500) to provide the boost. Boosting works on a logarithmic scale, so the more EU/t you're using to boost, the less the next EU/t you invest will be worth. Interdictors reduce this value by the previously-detailed method.
• Transporter base signal, reduced by (distance * signal required per block), is also used to decide the strength of the interference between multiple transporters on the same frequency. This currently translates to transporters more than 500 blocks away from each other having no interference at all.
• When a transport lock is acquired, it has a signal strength which is the ratio of effective signal / required signal, modified by interdictors, beacons, etc.. The signal strength determines the effect of the teleport on the item being teleported (all of the thresholds being configurable):
  
  • A signal between 90% and 100% means a guaranteed perfect teleport.
  • Between 50% and 90%, teleporting a player or mob has a chance of giving them a bad potion effect, like nausea or blindness; teleporting a block with inventory has a chance of losing items from that inventory as they "never rematerialize".
  • Between 10% and 50%, there is a chance of the teleport target shifting by up to 16 blocks in each of the six directions, and (this is very important) teleporting does not ensure that the destination is survivable! It's perfectly possible to get teleported into stone if your target lock was less than 50%; blocks trying to teleport into other blocks will just be bounced back, though, as an anti-griefing measure.
  • Under 10%, there is a chance of the teleport failing completely and never rematerializing you, if this happens you will have been killed by "a transporter malfunction". You can also lose blocks this way, so if the signal strength is that low, you *really* don't want to teleport anything.

  
  

• A lock under 10% signal strength held for one second will be lost, sending its transporter into a cooldown lasting 10 seconds (again, configurable), during which the transporter cannot acquire new locks. If the lock is broken before the one second timeout, the cooldown is proportionally reduced. If the signal strength rises above 10%, the cooldown is completely mitigated.
• Transport lock signal strength can naturally vary by up to 20% (yes... configurable) of its normal value (e.g. a 10% lock can vary between 8% and 12%). This uses a Gaussian distribution, so it's more likely to remain near the real value, but can spike up or down reasonably far.
• One final bit of internal mechanics is the range at which the interdictor can affect a teleport lock, which is a cube with an odd number of blocks per side, configurable by setting how far away from the interdictor it is still effective (currently 8 blocks, giving a 17x17x17 cube).

Wow, that's a lot of information. I didn't really realize how much of it there is, as I just built it up over the last couple of days. If you got this far, thank you.

So now the feedback requests: I will carefully consider requests to change any of the mechanics involved, within reason. I had one specific question, but in writing this post I went over some of my calculations again and came to a conclusion, so it's basically a free-for-all. What do you like? What don't you like? Most importantly, what do you think will make for a better experience, and what do you think will make for a terrible experience?

Quote from MatLaPatate

I hadn't been brave enough to read the whole thing but ... why not using [Euclidean straight-line distance]?

Because I want to. Literally, that's the only reason ^^. I know how to calculate the distance, but I prefer this one, it makes for an interesting change. Plus, this is Minecraft, blocks are kind of our thing, aren't they?

Quote from Pantheis

This sounds like a really neat addon! The only feedback I have is that it would be really awesome if you could manage to make some sort of particle effect happen around things being transported instead of it just instantly teleporting the entity/block to the destination. A "transport time" as you would see in the actual Star Trek universe.

Yes, and I *really really* want to do that, but I have no idea what would be involved in that yet (also, I'll need graphics, but yeah). Also, particularly for teleporting players around, do you know if it's possible to freeze a player in place? It would make things a lot cleaner if I didn't have to worry about the player moving while being teleported -- and that includes them not falling while they're being transported.

Quote from Pantheis

I think it must be possible to freeze the player in place, including preventing falling, given that if you pick up a player with the gravigun or portal gun, they don't fall and can't technically move. You can move them around, but they can't move themselves. As to how to do it, I have absolutely no idea.[...]

It's a fairly heavy-handed method, from what I've seen: GraviGun, at least, declares a tick handler and then iterates held players and does stuff to them. It's not the easiest thing to translate, especially out of deobfuscated, decompiled code. Luckily, I don't have to -- I figured out the silliest hack ever: have the player ride an invisible entity, as if they were riding a minecart or boat.

There was an interesting moment when I found out that returning false from shouldRiderSit() doesn't actually do anything because it gets overridden by idiotic code (see Entity.isRiding() and understand that getFlag(2) will always return true if this.ridingEntity != null... yeah)... and I was forced to reflect my way into it to make a protected function (Entity.setFlag(int, boolean) if you're curious) accessible so I could call it. Ah, well.

Quote from Pantheis

For the particle effects, you should be able to have the TileEntity spawn particles at a specific x,y,z, I think. For something more elaborate, I haven't a clue. I haven't worked with particle effects or much of anything rendering wise in any of my addons.

I'll figure something out -- I've been doing that basically since I started modding Minecraft.

Quote from Thutmose

Blocks may be the thing for some things, but others do use the actual distance, such as lighting, loaded chunk radius, arrow range, liquid spread distance, view distance, etc. for a transporter, it should probably be based on the actual distance, rather than the sum of the coords.

Really, that's what you're going to pick on? Everything else must be totally awesome, then.

Just for fun, I'll have to inform you that lighting and liquid spread are governed by Manhattan distance rules (the diamond pattern makes it pretty damn obvious), and loaded chunks are actually a square (no, really, the Y dimension doesn't exist for chunks), not any kind of distance at all. Arrow range and view distance are the only ones that actually do have Euclidean distance rules, but they are terrible examples.

Considering the actual calculation is completely irrelevant to the player, who only gets to see a signal strength readout, I think I'm in good shape.

Quote from Pantheis

Forge is pretty accommodating to pull requests if something needs to be fixed / added / made protected/public. I would encourage you to check on how to do that and submit the code. It sounds like the change could benefit others.

Mhm, I think I know what the patch needs to be, too. I'll look into it when I haven't got like fifteen different things being done all at once ^^.

Quote from Pantheis

I have to admit, I am very excited about this mod. Tallinu and I had been discussing creating a transportation mod modeled after the turbolifts in Star Trek, but then started getting all sorts of elaborate and interesting ideas. In the end we shelved it for now to work on other things, but I may just have to dust that idea off. After all, how better to get to your cool transporter room than in a turbo lift?

How entirely true! I'll be keeping an eye out for the turbolift mod!

Quote from HobbyCraft

Cool Are you used to modding, or is it kind of a fun thing/hobby?

Kind of both and neither at the same time, if that makes any kind of sense? I only started modding a month ago, with great help from FunnyMan3595, and most of the time I've spent doing it so far has been learning both Java and the Minecraft innards I've had to deal with. However, I came into it with the experience of someone who's been programming, off and on, for something like 14 years (most of that time actually spent working with Web applications, of all things). I will definitely admit it's fun to work on something and see the results of my work fairly quickly, and it's even more fun to read about people reacting to my work. Is that more or less what you were asking?

Progress report, since people are interested:

I just teleported a number of things with great success: cobblestone with a torch on it, a pair of logs out of a tree, a door, a chest, a liquidUU accelerator, a crystal chest, a buildcraft tank with liquidUU inside, a turtle, and a seed library.

I have also successfully teleported myself several times, but not using the current method.

I also have a trio of beautiful teleport sounds from freesound.org, namely the three related to this one: http://www.freesound.org/people/zimbot/sounds/122979/. They sound bloody brilliant.

Still need to: teleport entities (including players), make some visual effects, both for other players and for the one being teleported, implement transporter locks (half of it is in there at the moment, but untested), implement beacons properly... yeah, still a bit to go. That's not even an exhaustive list. But, I'm super-hyped with what I've managed so far. I hope you guys enjoy the progress report.

Quote from Khalamov

Will the teleporter sound files be accessible outside the mod as in the style of IC2NuclearControl? I'd like to be able to swap out the sounds, perhaps using a TARDIS like sound.

Um, I have no idea how NuclearControl does it, but BMU plays its sounds out of .minecraft/resources/bmu (extracting them from the mod, if necessary), so if you feel like replacing them that should work, I think. As a note on timing, the transporting process itself takes about 5 seconds (100 ticks), and the actual teleport happens at 2.5 seconds in (50 ticks).

Glad you're enjoying the mod

^ Good sir, you may be extremely interested in this thread, where I've already begun the implementation process.

Unfortunately, as I recently mentioned in my other addon's thread, I'm currently somewhat busy at work and therefore development is going fairly slowly (and I'm currently prioritizing LiquidUU, as well), but BeamMeUp is definitely not forgotten!

As for your specific requests, the first one is absolutely designed in from the start. My current list of configurables looks like this:

interdictorRange = 8; // blocks in every direction, so 17x17x17
    positionImprecision = 16; // (blocks, calculated independently for all six directions)




    lockDuration = 600; // (ticks)
    lockCooldown = 20; // (ticks after releasing a lock)
    lockLossCooldown = 200; // (ticks after losing a lock below lockThresholds[2], cumulative)
    badLockDuration = 20; // (ticks)




    transporterBaseSignal = 500;
    signalPerBlock = 1.0;
    transporterBoostMultiplier = 0.1; // (bonus signal when boosting with MaxBoostEU/t)
    beaconMultiplier = 0.8; // (reduce by 20% of effective distance)
    interdictorSignalRatios = { 0.5, 0.4, 0.375, 0.33 }; // (for each additional interdictor)
    lockThresholds = { 0.9, 0.5, 0.1 };
    lockVariance = 0.1; // (standard deviation from the base value)




    interdictorBaseConsumption = 4; // (EU/t when enabled)
    interdictorDampeningConsumption = { 1, 2, 3, 4 };
    transporterLockEU = 512; //(EU/t)
    transporterBadLockEU = 1024; //(EU/t)
    transporterBoostEU = 512; //(EU/t)
    transportCostPerBlock = 100; //(EU)
    transportCostPerItem = 1000; //(EU)

Logically, setting any of the costs (available in the configuration file) to 0 will cancel out that part of the calculation equations.

As for the component costs, this is really fully up in the air at the moment -- I haven't yet given any thought to crafting recipes, and would more than welcome thoughts on the subject. Feel free to give me a nice, complex set of components (make sure to include a Heisenberg compensator in the transporter recipe!) and perhaps suggest where steps along the way could be simplified for easy-mode recipes... or don't, I may end up having only hard-mode recipes. I rather do think a transporter like this should be pretty damn expensive.

Teleporting to other dimensions was actually discussed a bit in the BMU main thread, so I hope you won't mind if I quote myself:

Quote from narc

It's definitely possible, and it's something I'd like to do, but I'm not sure how to balance it with the intra-dimensional teleport mechanics.

It feels like an inter-dimensional teleport should be quite expensive, and very range-limited -- perhaps even a forced 1:1 mapping of coordinates (and then what about the Nether's native 1:16 mapping?) -- because you're using the transporter in a way it's "not designed" to be used.

Though, to be fair, I'm also not sure if I want to build this into the regular transporter or make the inter-dimensional one a special machine of its own -- if the inter-dimensional transporter is its own machine, it can have different freedoms and limitations so it's theoretically easier to balance.

For now, I'm saving thoughts of inter-dimensional teleporting for after I have the basics ready and working, but feel free to suggest restrictions/freedoms that might make it balance well.

Display More

I appreciate all thoughts and suggestions and promise to always give them full consideration -- note this does not necessarily mean I'll accept every suggestion, but if I refuse one, I will tell you my reasoning. Thank you very much for your interest!

Quote from RicardoRedstone

[There] should be transport pads, that will be [just a] machine with a [simple] gui [where] you could set a transporter frequency and a pad id. [If] one or more pads with right frequenc are within certain range from an transporter, there could be a command to lock onto them [using their pad id]. [That would] automatically adn no fail get lock on whathever is over it, consuming a bit of extra energy(from the pad). if the pad has no energy or if its out of transporter's range, lock is inpossible in it. what you think?

Purely personally, and don't take this the wrong way, but the lack of capitalization really threw me off yesterday when I was tired. Don't worry too much about it, though -- I (think I) understood what you were saying when I re-read this just now (though please tell me if I misunderstood).

So, these transporter pads are a fairly interesting idea -- they read to me like a combo of linked transporters and beacons. The problem is, I've already designed for and written a bunch of code for linked transporters and beacons, and the pads aren't adding anything (or are they? Let me know if I missed something).

With that said, I do see a different potential idea here: separating the transporter machine (the one that takes commands from a controlling computer, or eventually from the transporter console) and the transporter pad (the block that things have to stand on to be teleported). In brief, I could see using a transporter command block that connects to ComputerCraft, which further connects to transporter pads nearby (~7-block cube) on the same frequency and uses them as the source/destination for the requested transmission/retrieval.

This slightly complicates the simple case of single-pad transporters (target lock coordinates would be relative to the command block, but transport coordinates would be relative to the pad), but allows the fairly Star Trekkish activity of transporting a six-member "away team" at the same time, as long as each one stands on a different transporter pad. Also make for some neat transporter rooms. It would even make the transporter officially a multiblock structure, and we all know how everyone loves those!

Quote from RicardoRedstone

and i'm thinking about some crafting recipes too.

Sounds good, I could really use some thoughts on that, particularly intermediary crafting components.

Thank you for the idea, and the interest, and if you have any other thoughts on the matter, please don't hesitate to share them!

I understood fully, and your feedback is appreciated. I have to think, though, that you're talking about making an entirely different mod -- the mechanics for BeamMeUp have been settled to my satisfaction so far, and they are (as intended) reminiscent of Star Trek. Making the pads work as I outlined in my previous post is something that can be done without changing the (already partially implemented) mechanics terribly much. Making them as you would like would require a complete redesign and rebalancing of the mechanics already decided on, as well as make them behave unlike the prototype.

As for the textures, I'm extremely happy with the ones I have right now, thank you very much. This mod integrates with IC2's energy system, it is not intended to be a part of IC2 -- therefore, it should not look as if it were.