Skip to content

Conversation

@ScarKy0
Copy link
Contributor

@ScarKy0 ScarKy0 commented Feb 28, 2025

Yet another AI proposal document.

This one is based of Aeshus' which is based on Saphire's which is based on Moony's

The general idea is a resource oriented AI that is integrated with the station and silicons.

@github-actions github-actions bot added Design Related to design documentation for Space Station 14. English labels Feb 28, 2025
@Djungelskog2
Copy link

My issue with these "minimax AI" docs is that they often take away from the AI's job of interacting with crew normally and make it even more overwhelming than it already is. I think it also adds unnecessary friction between crew and the AI to the point it would be hated more than "validhunting AI" (it's just following it's laws). The AI shouldn't be all powerful in what it can do directly and if it were, it should do so through the form of a remote control chassis or other hands on means. I don't think the AI should have so much control over it's hardware, mayhaps require most sensitive systems to have hands-on actions (done through your shell, borgs or people)? The AI should be able to do it's job effectively very easily and should have it's core tools such as door control, atmospheric control of individual rooms, turret control and cameras for free (Or essentially free to do even on a wide scale). I think the AI core being a secure area that people shouldn't go into often is a perfectly sound and good design choice. I would much prefer the malf AI be reworked to fit within a crew-sided toolkit and have to work around that (considering that's what it's made for) where it has access to all the tools it needs at it's disposal, and simply has to try harder to remain undercover; if the ai hacking APCs reveals it as malf, get rid of the hacking APCs part, dont make the normal AI hack APCs also. This could be done through a completely alternative task system. As of now the AI is not at all "too powerful" and I don't imagine it would be when it gets full functionality with more machines and interaction with silicons.

@SlimmSlamm

This comment was marked as off-topic.

@Ratonero500
Copy link

I feel that the only limitation to current ai should be that if more than 10-15 bolted electrified doors are active at the same time,then it should consume compute power.

Camera,radio and closing opening doors consumin compute power feels annoying.

@ghost
Copy link

ghost commented May 1, 2025

For some reason, it seems to me that creating a new AI should be more difficult than the usual insertion of a positronic brain into an Intellicard.

@walksanatora
Copy link

on the topic of processing power. I think all Current abilties AI have should remain free. but any more advanced abilties. or bulk applications of current abilitie should be given resource cost. eg: read how paradise station does it. https://www.paradisestation.org/wiki/index.php?title=AI#Programs all advanced abiltites need memory and time or nanites to use.

@Nimfar11
Copy link

It seems to me that AI should not spend a lot of resources to maintain its basic functions. This seems strange, unfair to AI, and a source of constant annoyance. The price should probably be symbolic, just to show that the AI is spending a resource on this, and if necessary, it can sacrifice even such a small thing.
It seems to me that it is worth transferring work with the gateways to temporary ones, blocking is so accurate, because this is essentially 1 team, even a crew member can easily block the gateways with a multitool or remote control. The only exception is electrification, because here you need to increase the voltage to overcome the isolation of the gateway.
Most of the resources should be spent on NEW opportunities for AI, which EXPAND its power and capabilities. This is what the AI should strive for (if it is not completely lazy), and what the crew members can benefit from.
For example:

  • Create atmospheric holopanels through holopads (spends a resource).
  • Power some equipment, even if there is no power supply, let's say from its own core.
  • Or other special features that the author listed, but are not part of the basic features.

@SurrealShibe
Copy link

  • One issue I can see happening with a resource consumption system is that, because the AI is required to follow (almost) all crew orders, they are not really in control of how they use resources. Additionally, the AI's usefulness could be crippled very easily early into the round, where players have no IC reason to believe there will be a threat. The AI could be ordered by antags to bolt dorms or other rooms with little functionality, draining resources that could be used to assist crew later.
  • AI is already a difficult and overwhelming role especially during survival rounds, and I feel this might push more people away from it.
  • Many people I've talked to who enjoy playing AI have found that the role is most fun when you treat the parts of the round without sources of crewharm requiring AI involvement as a chance to roleplay with the crewmembers. Making things like the communication console, radios, cameras, and other means of interacting with the crew cost resources makes roleplay actions harder.
  • Maybe some of these things could be handled by a "core maintenance" system? Instead of having some amount of resources to distribute, maybe instead there could be small upkeep tasks that would need to get done within the ai core to retain full functionality. These could even be tweaked to encouracge interaction with certain departments, or give engi more to do once power is set up. It could be things like:
    • Repair ion shielding to prevent ion law changes (engi)
    • Reboot camera server (sec)
  • I do like the concept of overclocking certain machines. That seems cool.

Some of these concerns might not be valid or I may have misread the doc, but i think making existing features feel worse to use for the ai is detrimental to the role.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Design Related to design documentation for Space Station 14. English

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants