Nite Team 4 Stinger & Clam Instruction Manuals

Hi! I've created PDF documents containing instructions for the current version of the STINGER terminal and for the CLAM mini-game. Let us know what you think of them and if this is something you'd like as a reference in the client.

 

Writing as I read...

STINGER Terminal Guide:
Formatting, you want a pagebreak before the 'cat' command, because right now the command is on one page and the description on the next.
Page numbers would be nice for reference purposes.
For 'zip', you should list what the prompt for the zip file name looks like.
You might want to list that for 'bounce' and other commands you can also manually type out the IP address (unless you're removing that functionality?)
Again, for htp, showing what the prompt looks like may be useful.
You may want a separate command to list the malware database, because I'm sure Scarlet and Velvet aren't going to be our only malwares. I'd also change 'malware database' to 'malware names', to fit with the syntax you listed.
For beacon, you may want to note that the command only works when you've got a beacon selected on the map, or something along those lines.
Again, put a page break before the 'Global Command List' header.
Not all of the commands are listed in the manual. You're missing npm, version, clear, echo, eval, help, ping, and scan. I understand that they're non-essential, but it feels weird having them listed at the end and not explained previously. Even if you just copy over the text from the client and create a new section, 'miscellaneous commands' or something, it'll feel more complete.

CLAM Manual:
"the ways the machine must be used"? Sounds weird. That whole sentence may be better written as: "This manual will outline the basics of using the CLAM, including proper arrangement of components."
Get rid of 'respectively' when talking about the data. Sounds weird. Try "from the incoming data stack, also labeled A, B, and C."
Packages? I thought you called them packets?
"Data will be packaged *for* four rounds before completing analysis." I know I'm just nit-picking here.
"an unprocessed data package accumulates" what does that mean? Might be better to say "each time a data packet reaches the end of the circuit without being processed".
Speaking of the circuit, you should put some sort of visual 'anatomy of the CLAM interface' near the top of the manual, and simply refer back to it instead of all those pictures at the bottom. Give the players the names of each component (node, packet, circuit, overflow token, data stack) so they know what they're looking at and what you're talking about later in the manual.
I already told you about my table idea, but that little list you have there would be better replaced by a table.
"If a node processes *an incompatible data type*"
The bit about critical errors is confusing. They can handle two critical errors, but on the third it shuts down? It may be easier (and I know it's a simplified way of saying it) to just refer to them as 'strikes'. "Each time a node processes an incompatible data type, it will return a critical error and that node will gain one strike. If a node has three strikes, it will cease to function and will need to be replaced."
The data analysis process may be better represented by, maybe a flow chart? Or a 'step chart', I guess. Removing 1. and 6. from the numbered list and having them sit in standard paragraph form, and having the rest of it look somewhat like this:
"Stage 1: Place your nodes in the circuit and view the incoming data stack. Take into account the qualities of each node and which data types are in the stack.
Stage 2: Press the PLAY button, and observe the data processing round.
Stage 3: Review the outcome of the data processing round, view the new incoming data stack, and replace one node in the circuit. Again, take into account the qualities of each node and which data types are in the stack, but also take note of how many critical errors each node has returned in previous rounds.
Return to Stage 2, repeating until 4 rounds have occurred."
You have to decide if you're going to call it a data STACK or a data FLOW. I prefer stack personally.
Also, screenshots from the game are nice and all, but a black and white lineart of the CLAM interface would look a lot more 'manual' ish, and would make it easier to point out which components are which. Key components that should be labeled: the circuit (you called it the processing grid earlier in the manual for some reason? Haven't seen that terminology before), the data stack/flow, a single data packet/package, the node locations, the node types, the critical error indicators (white box things on the left part of the node locations), the overflow tokens, the node counter (the one that says 'node 4/4' in your screenshot), the round counter, the play button, the help button, and the completion bar (the % at the bottom, that's how complete you are right? or is it more like fidelity, how many of the data packets you manage to process?).

And this turned out a lot longer than I intended. Whoops.

 

Thank you, crux! Very helpful. I don't see any problems with them at all.

 

Oh god, I would have killed for these when I was doing the missions...

I still need to buy more sticky notes.

 

Awesome! Just starting the operation so these should come in handy! Thanks!

 

Very nicely done.

On a side note, what is this CLAM mini-game?

 

where can i use these commands? in the game? in wich missions?? sorry 4 my english..

 

This is for a VERY old version of the game. I'm actually going to lock this thread, to prevent further confusion.