Jump to content

Rules for AIs and Shells?


roch

Recommended Posts

This may be better posted on the SH boards, but there's always more activity here...

 

I was wondering if there are detailed rules for AI characters who own multiple Shells in any of the Star HERO products, or elsewhere (Ultimate Vehicle)?

 

I'm looking for something which supports the themes of GURPS: TS. For example, Joe is an AI with a bag of skills, and has two shells: one with a slow computer but lots of weaponry, and one with a fast computer but feeble weaponry.

 

Any idea how would these be modelled? Multiforms having zero mental characteristics? Limitations to reflect the restrictions on when Joe can change form?

 

Similarly, are there rules which account for the core character (software+data) being instantiated on different levels of hardware, with concimitant performance boosts or penalties?

 

Just wondering what level of detail is available in existing HERO product if I want to run a GURPS TS/Blue Planet melange campaign after I've run my first Fanatasy HERO campaign and after I've converted the new (as yet unreleased) version of Mage to HERO...

 

Thanks,

 

(_8(0)

Link to comment
Share on other sites

Re: Rules for AIs and Shells?

 

The potential for detail in this case is considerable (as with just about everything else in HERO) ;) , but as I'm unfamiliar with the exact construct in GURPS a few more details would help:

 

What exactly is the effect of the AI being in a "slow computer" vs a "fast computer?"

 

How easy is it for the AI to change "shells?" Any restrictions on when, where or how?

 

If a shell is damaged, what if any are the detrimental effects that the AI suffers? Is it damaged in any way that can't be eliminated just by taking on a new shell?

Link to comment
Share on other sites

Re: Rules for AIs and Shells?

 

It's starting to look like there's a good spot for The Ultimate Computer (or The Ultimate Automaton, if Steve wants to put this kind of thing in there).

 

I don't have either of the Hero4 books on hand with the Spirit rules in them, but I think a little borrowing from that subsystem might be in order for this.

 

Short of that, I'd say build the AI as an AI, and build two (or more) bodies as Automata. Then you can use some form of the Merging rules from TUV to represent when the AI inhabits a given body.

 

(Just quick thoughts here, since I also have other things going on at the moment; I may or may not write something out in greater detail at a later time.)

Link to comment
Share on other sites

Re: Rules for AIs and Shells?

 

LL, you've raised some good questions (as usual) :)

 

Personally I think all skills for AI characters are best handled as slots in a framework. This would allow for an AI to run one program at maximum "power", or a bunch simultaneously at reduced "power".

 

There are a few elements here:

a) AIs are taught skills; other programs are merely "written". Of course, an AI can host a stock skill program it hasn't learnt

B) how well written the program is effects the resultant skill level. Thus, an expensive program may run as INT 15 or KS: Bioroid Engineering-18 on a computer of a given Complexity while a cheaper program (or AI) may run as INT 12 or KS: Bioroid Engineering-15 on the same computer

c) the faster the hardware, the "better" software runs (+INT or + to skills programs) or the more of it you can run at once. Possibly AIs can run on slower hardware than their minimum rated "Complexity" but less efficeintly

 

Regarding shells and changing them, that's a little campaign specific. TS declares that xoxing (copying) AIs is illegal, so GMs may declare that there can only be one instance of an AI in memory or storage at once; thus, if the computer hosting the AI is destroyed before the AI can download itself, the character's dead. Or, GMs may allow characters to have access to black market hardware which ignores the copy protection to create a backup for their characters.

 

Normally to change shells just requires the presence of the new shell, a connection (wireless most likely), authentication & authorisation - or hacking - and a small amount of time.

 

I should say that the above is not necessarily how GRUPS/TS does things, more my "version" of how I'm thinking things should be done using ideas from the excellent TS resources as a basis.

 

 

(_8(0)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...