What is the general consensus on how detailed a Sprite command can be? I know Sprite tasks aren't spent until the Technomancer changes the command, but does having conditional modifiers like "if" or "if/else" statements or specific details to objectives count as multiple Tasks? Can stuff like that count as a single Task until you give it other conditions, or would any change in activity count as a spent Task? Also, does a single task limit the sprite to use of a single Complex Form or Power, or can they use as many as they need to continue performing a task?

  • 4
    \$\begingroup\$ The FAQ suggests 140 characters commands for drones, and this works well for Sprites (and Spirits) too. \$\endgroup\$ Jul 25 '13 at 22:26
  • 1
    \$\begingroup\$ @Scrollmaster twitter-style sprite programming? I like it! \$\endgroup\$ Jul 26 '13 at 8:20
  • \$\begingroup\$ From what I understand, doing a specific task or using a specific CF/Power counts as a task; if you tell the Sprite to "Clear that node", and it clears the node using a variety of CF's and Powers, that's a single task nonetheless. \$\endgroup\$ Aug 2 '13 at 2:59
  • \$\begingroup\$ @Kyle: Ok, so how about this: I have a Sleuth sprite. I give it the command "Find the origin of data trails I indicate. Cookie the source if you can". Following this, I give it something to follow, and in following its orders it makes use of Browse, Analyze, Track, Exploit, and Traceroute, until it finds whoever left the data signature I indicated and cookies it. Does that all count as one task? Does telling it to find something else under the same conditions count as another task, or not unless I change the specifics of its original command? \$\endgroup\$
    – Cobalt
    Aug 4 '13 at 21:26
  • \$\begingroup\$ I'd make it two; one for finding the origin, one for placing the cookie. You'd have to give it all its orders in one burst; you change them and you need another task (unless it hasn't started its work yet). Of course, you may be able to get it down to one command if you say "Mark the source of these data trails.", but that'll mean that the sprite will try to mark regardless of concern for likelihood of success or failure. \$\endgroup\$ Aug 5 '13 at 2:38

I need to look in the book (so expect an edit later) but the way I view sprite tasks is sort of a "Do While" loop. It'll execute its task until preset conditions are met. Rather than give it multiple sets of commands, to me it would only make sense to have subsidiary sprites to deal with interfering tasks.

Nested conditionals take a huge toll on the GM, especially if they are not technically minded towards following 4 step pseudocode much less priorities and algorithms.

Edit: Page 241 of the 20th Anniversary Edition book says...

Continuous use of a specific power, whether on a single target or a group, counts as only one task. If the parameters of a task are changed, another task is used. Engaging opponents in a single node in cybercombat only counts as one task, regardless of the number of foes involved.

  • \$\begingroup\$ Additionally, Street Magic has a whole section on Spirits and tasks, that applies quite well to Sprites and tasks \$\endgroup\$ Jul 26 '13 at 13:51
  • 1
    \$\begingroup\$ My GM does have some understanding of logic functions, so I would probably be able to get away with maybe one or two simple "if" statements. I might need to talk to him about it more. Good points though, I'll have to take a look at those spirit command rules. \$\endgroup\$
    – Cobalt
    Jul 27 '13 at 14:46
  • 1
    \$\begingroup\$ When I have sprites I usually do this, with the addendum being that I also allow a "Wait Until" and "If Succeed/Fail" conditional, though the event that follows the succeed/fail conditional may be its own separate command. \$\endgroup\$ Aug 1 '13 at 21:36

Sprites are sentients, not drones. The task you give them can be as complex as you desire, though excessive conditional statements might not only frustrate your GM, but also result in your sprites performing emergent behavior that you did not intend them to preform (but 'coded' them to) and thus frustrate you as well. Any task that is complicated in the wrong ways (though if/then/else should be fine in this sense) also runs the risk of confusing your sprite, which is generally not good for the health of your electronics.

Sprites are nicer than spirits, in general, and much more forgiving of behavior on the part of technomancers that would constitute "abuse" for summoners. Nonetheless, it is possible to piss off your sprites (or sprites in general) and angry sprites, while more likely to harrass you than kill you outright, are still not something you want to deal with. Sprites mildly resent having tasks, and making a massive if/then/else tree so you can keep them indentured for longer than normal is the kind of thing the book seems to indicate will result in them being mad at you.


Sprites are semi-sentient

Technomancers also have the ability to create semi-autonomous entities out of the fabric of the Matrix, digital creatures that answer to the technomancer’s beck and call.

Tasks are continuous

A task is a continuous service the technomancer asks, cajoles, or demands from the sprite.

Spirits struggle against magicians who abuse the system to oppress them

[rules on page 187] This modifier should only be applied when roleplaying calls for it, such as when a magician has been abusive towards her bound spirits or has repeatedly put them at risk or forced them to undertake draining tasks like Spell Binding.

Those rules are also applicable to sprites

Registered sprites may be a drain on the technomancer’s mental resources, if the gamemaster chooses, in the same way that bound spirits might affect a magician (Bound Spirits, p. 187).

But Sprites are for forgiving and less violent than spirits, generally (compare the following passage to what Free Spirits do when they break free from a binding)

Free sprites that have been registered against their will are not usually vindictive or determined to inflict harm on the operator, but will go to any means to counterbalance an “unsatisfied equation.” What this may mean in particular cases depends on the nature and profile of the free sprite and is left to the gamemaster. The sprite can be re-registered through a new registering session, as long as the free sprite source code is not altered. This can be done an unlimited number of times, but if the operator glitches on the re-registering test, the free sprite will get 1 Combat Turn to do anything it wants before it is brought back under control. If the technomancer character scores a critical glitch on the reregistering, he forfeits all remaining owed tasks and the sprite can do anything it wants.

All quotes except the last one (from Unwired) are from the Core Rulebook.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .