RC avatars

[bobucles]

There is a big desire to go fast. Players want to move across the map at legendary speeds to do their factorio stuff, rather than spending tons of time sitting in trains or riding a car half way across the map. That's okay. There are many ideas on the topic, such as giving the player a fast flying option or teleporting across the map.

What about robots?

Consider this: The player sits in a remote control center and takes control of a droid. The droid for all intents and purposes is the avatar, with its own equipment and inventory and skills. When the player tires of the droid they simply unlink, go back to themselves at home base, and do something else.

What you get in effect is insantaneous travel. With multiple droids the player can be in many places at once. A droid at base can run defenses during an emergency, or a droid at an outpost can expand operations in a new direction.

Isn't a droid pretty much a source of infinite lives? That's not a real problem. The existing game tech already affords the player nigh invincibility through their suit and weapons. The personal risk is pretty much gone after a certain point. If anything it makes player death a POSSIBILITY that didn't exist before. One life in a 5+ hour campaign is a recipe for disaster.

What if the droid is too good? There can always be some form of limitations such as less inventory, slower speed, limited battery life+charging station, or the like. Perhaps it has to dock at a station before unlinking, or it has some other requirments that make it a bit more clunky to use. Droids don't have to be capable of everything either, allowing the option to distinguish between combat models and homely construction models. There is quite a bit of balancing flexibility here.

[Neotix]

Very interesting idea.
Robot itself don't have to be limited, it can be just like player. Only operate in limited area set by some sort of signal receiver/dock station like roboport (expand area by building more stations).
Also entire technologu could work after sending satellite on orbit and limit amount of robots by amount of satellites.

[Koub]

I actually love that idea. Droids would have to be sent (via train), or brought in inventory - or even buit in situ, and would act as a separate "player", offline most of the time, but remotely controlable when actions would be needed in remote places. With limited autonomy, auto-disconnect when integrated battery would be empty, a recharging station, to which it would automatically go to refill.

[bobucles]

Hmm. Needing a satellite to run droids would make sense. Droids wouldn't be very useful until players stretch into extreme long distance bases, and that's easily after a few sat launches. Of course this means the player has only one life to count on until they beat the game, for better or worse.

One option is to give the player limited control range with droids using ordinary systems. That range might be based on the suit, or work with linked radio towers in some way. Launching the satellite would open up unlimited droid range, without the need to link any kind of network. That way players can play with droids a bit sooner.

Should a droid be leashed to a finite range or have limited energy? That much is debatable. It would make sense for droids to work within range of a radio tower, but that would make expansion much more difficult. The droid would have to expand its network as it explores for new ore deposits. Pocket fusion means that droids could have an unlimited energy source, with no need for batteries. There's no real gameplay reason to leash them twice with radio AND battery range.

I don't think droids should be autonomous in any serious capacity. That's what turrets and logistic bots are for.

[Koub]

Having droids available only after satellite launch would make them unobtainable ... before you "win" the game (with the current endgame), even though I still hope there will be a satisfying endgame some time. I think they could be made available a bit earlier, like with a tech you could obtain after effect transmission (beacon) or just before effect transmission, as a prerequisite : radio communication.

[Neotix]

Remember that launching rocket is goal now, but after space platform expansion it will be only mid-game. Thats why i proposed that satellite idea.
Radio towers would also be good for pre-rocket game. It would bring robots sooner but still operate on huge distances require expand communication grid. In that way satellite would make that easier.

[Koub]

but IF space platform expansion

FTFY . Space platform thing is still not guaranteed to happen. We have no idea in which direction and to what extent endgame content may evolve before game is considered finished.

[bobingabout]

Sparked from this topic, I've just been having a quick think about the viability of a mod that would allow the player to have multiple player entities that they can switch between. They'd each have their own weapons, armor, and inventory and the like, as if they were individual players, but controlled by the one person. They wouldn't even need to be all the same either, you could easily write in new entities, each with their own set of stats, such as a hauler with huge inventory space, a miner with higher mining stats, a crafter, with faster crafting, even ones with new crafting categories, such as smelting, the player entity would be able to hand craft smelt. (If it's an android of some sort, who's to say they don't have a furnace in their belly?)

I suppose the biggest issue is setting a "This is the real player" thing for "Death", because currently, the only way I can think to do it is to make the entity the player, which means as far as the game is concerned, when the currently controlled entity is destroyed (killed), you died, rather than when the original player entity is destroyed (killed).

Granted, my active avoidance of scripting in my mods has left me with limited knowledge on the scripting interface in the game, but from discussions and what I do know, the player is whichever entity is active.

[Ghoulish]

A nice take on the how to get about quickly idea. I do like.

.....would allow the player to have multiple player entities that they can switch between. They'd each have their own weapons, armor, and inventory and the like, as if they were individual players, but controlled by the one person. They wouldn't even need to be all the same either, you could easily write in new entities, each with their own set of stats, such as a hauler with huge inventory space, a miner with higher mining stats, a crafter, with faster crafting, even ones with new crafting categories, such as smelting, the player entity would be able to hand craft smelt.....

Oooooh, now this is a nice evolution of the original idea. And a selection of biter bashing avatars too don't forget! Small fast ones to zip about (scout maybe), slow heavily armored ones to bring armageddon to biters..

The more I think on this the more I like the OPs & bobs evolved idea.

[bobucles]

Power armor takes care of the vast majority of personal attributes a player might desire. Extra speed, extra defense, or extra firepower that may serve as idling defense. It's mostly there.

The only reason to have separate droid types is to address specific developer desires. For example a dev may not like the idea of fighting biters with the safety of a drone. In that case it may not be possible to use weapons or some such. Other than that a simple player clone will address pretty much anything.

[Adil]

I suppose the biggest issue is setting a "This is the real player" thing for "Death", because currently, the only way I can think to do it is to make the entity the player, which means as far as the game is concerned, when the currently controlled entity is destroyed (killed), you died, rather than when the original player entity is destroyed (killed).

Granted, my active avoidance of scripting in my mods has left me with limited knowledge on the scripting interface in the game, but from discussions and what I do know, the player is whichever entity is active.

You can use scripting to prevent gameover and put player in other entity when the tragic event happens. I believe it was first done in that cloning mod, which never made it past .11.
The code implementation would be trivial. Problematic part would be graphics and design which should fit the game style.

btw:
There are mods that already provide you out of the body experience, btw: trains or radars (the latter will have to be manually renamed from source for the latest features (and bugs ).) Also, I might remember seeing RC cars mod somewhere.

[zytukin]

I really like this idea.
I would put an avatar in each outpost to work on it, etc.

But, one would still need to get all the equipment to the location to do whatever you want with the avatar.
So you'd still have to somewhat wait for a train of goods to get there. Only difference is that you wont be riding in the train to the the location.

[bobucles]

At that point you're getting into a whole new kind of logistic problem: How to supply your drones to get the best use out of them. That sounds like a fun thing to figure out.

One possibility is to put the drone in a train, fill the train with goodies, and ship it off. Another is to have special supply stations scattered across the map full of goodies, or at least with easy access to trains. If the drone didn't have enough stuff that means the player goofed and it isn't any real fault of the drone.

[Neotix]

Send drone with standard cargo to build supply station in outpost. Send train with supply. Build outpost. Send back supply train, demolish supply station and go to build another outpost.

[bobingabout]

You can use scripting to prevent gameover and put player in other entity when the tragic event happens. I believe it was first done in that cloning mod, which never made it past .11.
The code implementation would be trivial. Problematic part would be graphics and design which should fit the game style.

I kinda wanna have a go at modding this now. Unfortunately, as pointed out, graphics would be the hard part. At the very least I should be able to make use of the old player entity graphics.

[Adil]

Or one could put the dummy character with a portable roboport into a car and when player exits the car the connection to avatar is closed and dummy character is removed/put back in the car.
This way running costs would be naturally incorporated into avatar, and it's destruction does not cause the need to catch gameover.
Choices, choises, u so many.

[zytukin]

Another is to have special supply stations scattered across the map full of goodies, or at least with easy access to trains.

I like that idea.
Expands on the existing method of having stations scattered around to supply construction bots in roboports to repair/replace walls and turrets

[bobingabout]

After looking through and trying to understand the scripts in the fat controller mod, I couldn't find any game over prevention scripting.

What I found is... well, there is a game over generator, for when your body dies while you're not controlling it, but when the train dies? It just switchs back to your body, so there's no need for prevention (When the train dies, the "Fat controller" entity just gets ejected, this is detected, and you're switched back).

So I'm still unsure how to do it without your remote controlled bodies causing game over x3

[Adil]

Wanna me to spoil your fun?

Y

Code: Select all

game.set_game_state{game_finished=false}

Still I think rc car would be cooler.

[bobucles]

Still I think rc car would be cooler.

The gameplay implications of any RC choice are important from a combat balancing point. A droid is the top tier choice because it duplicates the player and basically gives extra lives. A vehicle will only give you abilities of that vehicle. For example an RC car is only really good for exploring and light harassment.