Please, Please, God/Schema - AI behavior and Fleet Commands as Python(Mining Fleet Woes Continue...)

[_ArkAngel_]

[EDIT: I meant Lua, not Python!!!! :P Ooops! ]

Mining with drones has been... A lot of work. At this point, I'm certain I'd have done better putting those salvage beams on AI turrets than on standalone mining drones.

But I'm far more interested in exploring exactly how drones and fleets are *supposed* to function at this stage.

Spoiler: Not well, LOL. :p

I'm trying to use the stop beam on the asteroid. That one of my ships insists on ramming repeatedly.

The rest of the drones are freaked out, too. They often do this whether the asteroid has been rammed or not:

I gave the order to idle and they stopped glitching out. Yay! Gave the order to mine again.... Eh..

Once or twice a beam was fired at the asteroid, but 20 minutes later and it's still there. Other times, the drones eat them right up.


My Request:
Please, Schema, please, implement AI, NPC, and fleet behaviors as python scripts that can be edited by server admins. The scripts should be able to take the current target as a parameter.

Things users could implement:

1. Mine my target
2. Attack my target
3. Keep distance from asteroids and ships at least current ship AABB + other entity AABB.
4. Alternate "Mine this sector" command: Target rocks with fertikeen first. Or however the user has customized it.
5. Follow my current target (so you can have your defensive fleet follow your mining fleet automatically)
6. Make all navigation keep a minimum distance from stars, known pirate bases, hostile factions, and hostiles that appear on nav.
7. Supply Shields/power/heals/whatever to my current target. Or fleet of current target. Etc.

P.S.: PLEASE
[DOUBLEPOST=1464352630,1464351714][/DOUBLEPOST]I can see the downsides of being able to create an AI fleet that strip mines the galaxy, but it would be in the control of server operators what is possible. Certain commands and behaviors could only be possible if the commanding player is online. Or they could incur a cost of faction points or credits or require that a percentage of gathered resources are automatically donated to the closest shop.

I would also really like to see a Fleet Computer block and a Personnel Computer block. That way you can use faction access levels.

1. Fleet Flagships would require at least one Fleet Computer
2. Ships cannot be promoted to flagship without one
3. Anyone with access to that fleet computer can command the fleet
4. Requiring a player to use a fleet computer to issue commands might be a fun mechanic
5. Fleet computer could be accessed from the gun config menu and hotbar instead of pressing "K".
6. You could dock fleet control rooms to a mothership that have fleet modules assigned to various fleets that can be controlled from one or more command ships (would not require allowing fleet computers on a ship being assigned to potentially multiple fleets and creating a new mechanic for somehow linking them)

[DOUBLEPOST=1464355165][/DOUBLEPOST]Further Research:

I decided maybe the drones were glitching in part because their thrust to mass ratio was so low (0.2). I grabbed onto one to add thrusters, and found that all of them were at the moment I took control over the drone, going *FAST*. It took me 30 seconds to bring the drone to a stop.


So, eventually, I selected the asteroid and /destroy_entity. The drones were sad for a moment. I gave the order to mine again, and they all went after this asteroid and ate it in about a minute.


I'm going to try a more powerful stop laser, perhaps?

 

[lupoCani]

Firstly, those drones are not very well designed. The AI is quick enough to use one, powerful beam, re-aiming it the instant it's no longer pointing at a block.

Secondly, there are plans for some form of scripting, but that would be in Lua. Python does have an advantage in popularity, but customizable scripting for games is more or less Lua's domain. The specifics aren't to clear, whether it's something we'll be able to do in-game or just server-side, whether it'll be NPCs or computers or both, etc.

Third, I really thinks this goes in the suggestions forum.

 

[nightrune]

Its also a problem of performance, a server of 100s of different scripts does not sound like a great set of gameplay. While I would enjoy scripting, I don't think it should be an everyday part of the world for a user. It hands unfair advantages in a game that should be based on your skill as a builder not as a programmer.

 

[_ArkAngel_]

Firstly, those drones are not very well designed. The AI is quick enough to use one, powerful beam, re-aiming it the instant it's no longer pointing at a block.

Secondly, there are plans for some form of scripting, but that would be in Lua. Python does have an advantage in popularity, but customizable scripting for games is more or less Lua's domain. The specifics aren't to clear, whether it's something we'll be able to do in-game or just server-side, whether it'll be NPCs or computers or both, etc.

Third, I really thinks this goes in the suggestions forum.

Lua!!! Yes, I meant Lua. The game already has Lua script. There is no reason to go to Python. Any scripting language will do. I just blanked on which scripting language was being used.

Second,
I actually read the fantastic write up in the game news section which has lots of information on the intended AI features yesterday. I love the quarters idea, because it gives a real reason to build ship interiors other than creativity and RP. Great source of info here:
StarMade Development Direction

Third,
Maybe? It's not really a serious suggestion. It would be great, but I'm more looking for feedback on how to make the current system work. I think that the game designers and developers are already pretty set on what/how they are going to do fleet/crew AI and there isn't much I'll do to change it. I'm not getting the vibe that they are really into handing the reigns to the community to drastically change game balance and economy issues. I don't suspect any pleading on my part will get a developer to put a very core part of the gameplay in a script language that anyone can easily edit. So, I'm just preying and venting.

First,
That's the feedback I was hoping for. Like... what's wrong with my drones? Why don't my pickup points work half the time? etc. I've tried the drones with one beam and they don't glitch any less and they don't collect resources any faster.

The drones are using an array of 9 salvage + 9 damage beam. Each beam does 200 salvage damage each tick, ensuring that each hit collects a block and there is no waste of beam power. Most of the time, most of the beams are hitting rock. The beams are arrayed in a tight 2x5 package.

I'm not sure the drones are poorly designed. If going down to one beam made them glitch less it would be a big improvement. It would also make tiny drones that I wouldn't really care to maintain. These ones clear asteroids fast and have high capacity. *When* they actually shoot at asteroids.

I thought the thrust/weight ratio might be influencing the glitchiness, but I don't have evidence of that at this time. Increasing it to 1.0 at least makes it easier for me to redirect them when I need to.

On that note, seeing the drones collect the next rock well until it got bumped, I decided to up the size and number of my stop beam turrets on my "flag ship"

Currently, it appears if I tell the drones to idle, target the rock, let it get stopped, and give the order to mine, the droids are performing at peak efficiency again.

Note: the beams from the upper right, which are more spread out, are not coming from one of my drones. Those are from my mining scout/personal yacht, which I assign to the drone fleet when I'm tending to other business nearby.

 

[lupoCani]

Its also a problem of performance, a server of 100s of different scripts does not sound like a great set of gameplay. While I would enjoy scripting, I don't think it should be an everyday part of the world for a user. It hands unfair advantages in a game that should be based on your skill as a builder not as a programmer.

Here we go again....

This game is projecting complex shapes in a three-dimensional space, analyzing them for contact points and applying forces in accordance to simulate a physical interaction, dozens of times a second. The power set aside to run a few Lua scripts won't be significant. I should also mention that they won't be "taking" processing power from the game, so much as the game will be "giving" processing power to the scripts as it sees fit. If player scripting does somehow threaten to infringe on performance, why, or scripts will be running slower, that's all.

Also, this game should not be "based on your skill as a builder". Building is a skill, as is piloting, or strategizing, or negotiating, all of which have their place in the game. Similarly, programming isn't witchcraft, it's the skill of formulating automation. Besides, it's not like that advantage is going to stay reserved. Before long, you'll have the basic uses (auto-mining, proper fleet controls, autopilot and taxis, etc) written, automated, packaged in a neat UI and released with user-friendly installation instructions for the use of noob and veteran alike.

 

[_ArkAngel_]

Its also a problem of performance, a server of 100s of different scripts does not sound like a great set of gameplay. While I would enjoy scripting, I don't think it should be an everyday part of the world for a user. It hands unfair advantages in a game that should be based on your skill as a builder not as a programmer.

Scripting would not be part of the world of the typical user and there would be no reason for it to be. In minecraft, redstone logic isn't even part of the world of most players. In games like Starmade and Scrap Mechanic, they are... and that's probably OK. But scripts would be under the control of server admins, or an option for curious players to look into.

But popular and useful scripts would be shared between server admins and other users, and a small handful of enthusiasts would actually edit them.

Just like now, pretty much, but with improvements to gameplay.

Also, if there were scripts that hurt performance badly, that would be in the hands of server admins to control. If the stock fleet/crew AI system adversely effects performance, there won't be much server admins can do, except maybe disable the features.

As a long time Minecraft player and occasional modder, I can say that core vanilla gameplay gets exhausted before long, and the online community thrived mainly because of the modding community that brought incredible amounts of useful gameplay mechanics to multiplayer servers.

Minecraft not having factions or the ability to own territory was... a baffling oversight. Incomprehensible to me, actually. Thankfully, Starmade has those out of the box.

Mojang (developers of Minecraft) opted not to build a modding API until they had the core gameplay features down. Well... They still don't have them down and are continuing developing "Version 1" of Minecraft. There is no Minecraft 2 on the horizon. They are working on Minecraft 1.10. And not even close to the modding API.


The moment Starmade attracts the number of players that Minecraft had in 2010, the mod community will explode and determined individuals will make the game better for the community - for free. Regardless of the creator's and designer's intent. Most especially because Java was chosen as the game's language, and it's easily decompiled, obfuscated or not.

I'm very new to StarMade and I could be wrong about a bunch of stuff. That said, I wish Schine would follow in the footsteps of Kerbal Space Program and embrace modding much earlier on and create a much better ecosystem of custom content from the getgo.

For Starmade to get big, servers will be running custom software.

Putting in a mod API is a big deal. Moving AI logic to Lua scripts could accomplish so much, though.
[DOUBLEPOST=1464361822,1464361564][/DOUBLEPOST]

The power set aside to run a few Lua scripts won't be significant.
...
If player scripting does somehow threaten to infringe on performance, why, or scripts will be running slower, that's all.
...
Also, this game should not be "based on your skill as a builder". Building is a skill, as is piloting, or strategizing, or negotiating, all of which have their place in the game.

Could not agree more. I meant to add a few of those points! Specifically that "Building" is not intended to be the point of the game as laid out by Schine. They want to support users who want to live in a game universe and interact with it by buying prebuilt ships and then salvaging, trading, and completing missions for money to upgrade their ship/base/holdings/whatevs.

And also users that can build. Or pilot, or fight, or whatever.

 

[nightrune]

Here we go again....

This game is projecting complex shapes in a three-dimensional space, analyzing them for contact points and applying forces in accordance to simulate a physical interaction, dozens of times a second. The power set aside to run a few Lua scripts won't be significant. I should also mention that they won't be "taking" processing power from the game, so much as the game will be "giving" processing power to the scripts as it sees fit. If player scripting does somehow threaten to infringe on performance, why, or scripts will be running slower, that's all.

If/when schine reads would be good to see their comments.

Here's my opinion, and people love to get up in arms over the performance question. It seems to be fun to argue over. The point I'm going to make is, There is no free lunch. You must pay in some way shape or form. There are many ways around many problems but generally as a development team you don't have time to touch all of them.

I'm not advocating or saying scripts are bad, but its far too easy to write bad software then it is to write good software. Which means the more you expose to external parties the less control you have over the games experience. A single bad script is not a horrible thing, but one bad script being invoked by 100 entities is something entirely different. Every area needs to be carefully balanced where it needs to live in java or lua.

So specifically lets talk about collision avoidance, and pathing. Pathing should not be in lua. The amount of shared state you would need and processing to get great pathfinding does not suit itself to doing that in a scripting language. Let along a scripting language running in a vm in an operating system, Talk about lost cycles.

The current algorithm is pretty bad. It'll get better.

Also you don't really set aside processing power for lua, Doing QoS like that is an ever changing artform, and its fraught with perils that just take time. Not something a small dev team is likely interested in tackling. You'll still have to do some, but it'll likely be in the form of odd timeouts.

So the OPs suggestion in my, opinion, would be nice to have but should not be priority.

Things I want scripts for, encounters, quest and rich interaction with ships and stations.

So I would love to have buttons that launch my drones from a station or recall a fleet in an emergency, but those are small scripts. Select Fleet, Move/Jump To, Current location.

Not Grab current scene from scene graph, calculcate where every ship is. Raycast and check for collisions between them.

Sorry for the wall of text. Its a nuanced view that is hard to sum up, at least for me.

 

[_ArkAngel_]

When it comes to pathfinding, it's not something that has to be done every tick. An event based system like Minecraft's Skript would be fantastic. Skript - Bukkit

You don't grab the scene from the scene graph. You grab the entities withing x meters of entity z. And you definitely don't need to raycast. You can work by bounding boxes or spheres or AABB for general case ship pathfinding. - Unless you're talking about navigating one ship inside the corridor of another ship. Crewmember pathfinding should absolutely not be in script. I can agree with that. I like that they said are going to offer us ways to designate waypoints for crew members.


Regarding the efficiency of my AI mining beams - I'm OK with it:



As suggested elsewhere, a stop beam on your drone carrier is essential equipment.

 

[lupoCani]

A single bad script is not a horrible thing, but one bad script being invoked by 100 entities is something entirely different.

This is, perhaps, the core of what I wish to address.

Basically, as far as I'm aware, there's no need for this to be at all true. Lua and Java won't be separate entities, the former will be a simulation by latter. Every instruction that's written in Lua will be individually considered and interpreted by Java. Java could do this at whatever speed it likes- one instruction per second, a thousand instructions per second, fifty instructions per second, etc. Thus, I'm not sure there's even such a thing as a "bad" script from a performance perspective. A script that needs ten thousand instructions to do something will take ten times as long as a script that's needs a thousand, but the game itself will only be doing n instructions per second anyway, so that's only a problem for whoever is using the script.

Essentially, there's no such thing as a free lunch, but not only are there very cheap lunches, there's no need to eat more than you decide is worth spending.

 

[_ArkAngel_]

Basically, as far as I'm aware, there's no need for this to be at all true. Lua and Java won't be separate entities, the former will be a simulation by latter. Every instruction that's written in Lua will be individually considered and interpreted by Java.

I don't think it's nearly as simple as you put it.
There are some suggestions here https://www.reddit.com/r/lua/comments/g497m/lua_watchdogthrottlinglimiting_question/

Scripts that don't run in a set period of time could be disabled or disallowed, is probably the easiest.

It seems like you're suggesting something like every tick giving a few hundred bytecode operations to the LUA vm or something... it's an interesting idea, but far outside of any typical approach to the problem.