Difference between revisions of "Internet (Programming)"

From Hellmoo Wiki Archive
Jump to navigation Jump to search
imported>Spunky
imported>Chinaski
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
[ This article is still under construction ]
The HellMOO internet (aka The Matrix, Cyberspace) allows you to build hacking-oriented puzzles and provide content that could not otherwise exist in the 'real world'.  The internet uses different room types, exits, and areas that the normal HellMOO world as behaves differently in many ways.  The key thing to know about cyberspace is that nothing works properly there for players (or admins) unless they have jacked in through a cyberdeck, and hence their .cyberdeck property points to a valid object descended from $cyberdeck.


==Using Blueprints to Create Hosts==
==Matrix Objects==


If you need to build a host that will be associated with some piece of hardware that players can buy (as is the case with [[Cyberdeck|cyberdecks]]) you will need to make that host a blueprint.  This is done because each instance of the hardware needs its own host.  Full documentation for blueprints can be found in the [[Blueprints (Programming)]] entry.  What follows is a mini-tutorial on using them to create a host type.
The following objects are very important to the HellMOO intarwebs:


Before you begin, you'll need a cyberdeck and a place to jack in. This is necessary because the matrix doesn't really work properly (even in a blueprint) unless you're connected to a cyberdeck. So, get one and jack in before you start making the blueprint.
{| border=1 cellspacing=0 style="wikitable"
|- bgcolor="#cccccc"
! Object Number !! Name !! Description
|-
| $matrix_hardware || Generic Matrix Hardware || The parent object for all cyberdecks and servers. Anything that can be booted up to create a host is one of these.
|-
| #1834 || [[Cyberdeck (Programming)|Generic Cyberdeck]] || The parent object for all cyberdecks.
|-
| #1411752 || Server || The parent object for all servers (players cannot directly jack into these).
|-
| #1267977 || NPC Server || The parent objects for all NPC servers (reset themselves on area_reset, can't be picked up or configured by players).
|-
| #3815 || Cyberdeck Control Feature || This object holds all the verbs players can use to manipulate their cyberdecks when they are jacked in.
|-
| #1837 || Generic Matrix Area || The type of $area that must be used to contain rooms in cyberspace.
|-
| #2089 || [[Hosts (Programming)|Generic Host]] || A type of matrix area designed to hold a particular system (aka host).
|-
| #2178 || Generic Matrix Exit || The parent of all exits used in the internet.  Direct descendants are generally only used within a single area.
|-
| #548263 || Generic Matrix Firewalled Exit || An exit that must be hacked to proceed.  Can be protected by ICE.
|-
| #2124 || Generic Network Hop || A type of matrix exit used to transition between areas in the internet.
|-
| #1835 || Generic Matrix Room || The parent types for rooms you can visit in the internet.
|-
| #1829 || Generic Network Interface || A device that allows cyberdecks to connect to the internet.
|-
| #579237 || Generic Matrix Targetted ICE || ICE that targets a single player at a time.
|-
| #473624 || Generic Matrix Pulsing ICE || ICE that deals damage to all players in the room.
|-
| #459036 || Generic Matrix Corp Controllable Orb || A control box to allow corporations to take over things.
|-
| #199551 || Generic Matrix Datacache || A datacache that gives money to whoever hacked it.
|}


Construction begins when you create blueprint.  BluePrints are another topic of their own, so for now we'll focus exclusively on what you'll need for creating matrix area blueprints.  Anyway, the first thing you'll need to do is create your blueprint:
The arrangement of networks & hosts is very important for maximum player clarity - the absence of a map makes intuitive navigation in the matrix extremely important!


  @create #27727 named "My System"
Players explore the matrix by jacking into a cyberneck & connecting to other systems (HOSTS & host nodes) through a linked NETWORK, comprised of network nodes. Hosts should generally be set up to connect exclusively to networks, unless there is a strong gameplay justification to have a direct connection to another system (hidden hops to represent backports or remote access for service systems, as examples).


Once you've created the blueprint object, you'll want to store it someplace safe while you work on it. It's not a $thing, so it doesn't really belong in the real world, but it also can't be on your person while you work with it, since editing it actually puts you inside the blueprint.  It's okay to just leave it in your cyberdeck, as long as you don't lose your cyberdeck, but keep in mind that if your deck is online anyone can look at or edit your blueprint if they find it.
Ideally, networks work as a hub and spoke system, with all relevant hosts connecting to a single network node that represents either a geographical area or a connection service. For the Freedom City Metro Net, this is represented by the TLDs - we have one for commerce, one for residential connections, one for non-commercial organizations, etc. For smaller networks this can represent floors of a building or departments of an organization. Finding unique and fun ways to limit or allow access based on the player's physical connection point is the main design principle for matrix areas until more challenge mechanics are implemented in the matrix.


Now that you've stored your blueprint somewhere you can edit it:
Servers should be used for almost all non-player owned hardware - cyberdecks are intended to gradually gain heat & lose charge when used, and essentially function as a decker's "body" while they're in the matrix. Harm to their gear should be an implicit risk any time they dive a system. Servers, on the other hand, are designed to run indefinitely and should generally be set up with better stats than an equivalent cyberdeck.
 
  edit <object number of the blueprint>
 
Now you'll be inside the blueprint.  If you need to get out, you can always type 'commit' and be returned to where you were when you began editing it.
 
The first thing you'll probably want to do is rename the node you're in.  The first node is usually the login node, you you may want to include that in the title.
 
  > focus here
  You focus on the generic matrix node.
  > rename FCPD Login Node
  Changed the aliases from generic host node to FCPD Login Node.
 
Notice that we begin by focusing on the room that we're in ('focus here').  In order to work with objects in the blueprint (including rooms themselves) you must focus on them.  The blueprint commands will only work on an object you've focused on.
 
The next thing you'll want to do is set up the login node for your system.  The login node is where your host interfaces with the rest of the matrix.  That is, it's the place players will first appear when they connect to your system.  You can change the type of node you're in using the 'type' command when you're in a blueprint node:
 
  > type
  Available types for FCPD Login Node:
  1. generic matrix room
  2. generic network node
  3. generic host node
  4. generic cyberdeck control center
  5. generic security node
  6. generic login node
  7. generic datavault
  > type 6
  Changing FCPD Login Node from generic matrix node to generic login node.
 
We use the 'type' command with no arguments to list the available types for the node you're focusing on.  Once you've decided on a type, you can select it by giving its number following the type command ('type 6').  This is the command that actually changes the parent type of the node you're focused on.  Note that all node types are not created equal, they each have verbs that relate to particular bit sof matrix functionality. For instance, a Datavault will allow users to store programs, a login node will control access to other nodes, etc.
 
You should also describe the node with the 'desc' command:
 
  > desc A cool blue node with a rotating yellow star on the far wall.
  Description set for FCPD Login Node.
 
Now that you've set up the login node, you'll want to create an exit into the more protected parts of the system.  You can create an exit and a new node using the 'dig' command:
 
  > dig "portal to main bus"|"portal to login node" to "Main Bus"
  Creating destination room 'Main Bus'.
  Created 'Main Bus' destination room.
  Created 'portal to main bus'as an exit.
  Created 'portal to login node' as an exit.
  Exit fully linked!
 
Note that cardinal directions mean nothing in cyberspace, but there's nothing stopping you from using them if you really want to.  There may be some matrix areas that are designed to look like areas in the real world, but you won't be able to get around the fact that getting around in the net is just fundamentally different than it is in the real world.  Anyway, I recommend naming your exists something themely to the net in general or to the type of system you're creating.
 
Now that you've got a link out of the node that you're in, you should see it when you 'look':
 
  > look
  FCPD Login Node (blueprint for FCPD Systems)
  A cool blue node with a rotating yellow star on the far wall.
  L I N K S
  [1] [bpt] portal to main bus
 
The way one gets around in the net is by choosing a link to follow.  These links are accessed via number, as listed in the LINKS list when you look at the node you're in.  Also notice that links have an 'icon', which in this example is still [bpt], which your system is inheriting from the generic host.  To change the icon for your system, you merely need to set its 'icon' property.  If you're inside the blueprint, you'd do it like this:
 
  > ; here.location.icon = "XXX"
  => "XXX"
 
Feel free to use ANSI color to jazz things up a little bit in your icon.
 
Now that you've made another node, you can travel to it by selecting the link number, which in this case will be 1, since there are no other links yet.  Typing the number of the link should move you into the node it's connected to.
 
The nodes you'll want to create really depend on the type of system you're creating, but there are some specialized nodes for cyberdeck hosts, so be careful when you're choosing the node type that you don't take one that's inappropriate for the system you're creating.
 
[ more coming soon ]


[[Category:Programming]]
[[Category:Programming]]

Latest revision as of 09:25, 29 October 2019

The HellMOO internet (aka The Matrix, Cyberspace) allows you to build hacking-oriented puzzles and provide content that could not otherwise exist in the 'real world'. The internet uses different room types, exits, and areas that the normal HellMOO world as behaves differently in many ways. The key thing to know about cyberspace is that nothing works properly there for players (or admins) unless they have jacked in through a cyberdeck, and hence their .cyberdeck property points to a valid object descended from $cyberdeck.

Matrix Objects

The following objects are very important to the HellMOO intarwebs:

Object Number Name Description
$matrix_hardware Generic Matrix Hardware The parent object for all cyberdecks and servers. Anything that can be booted up to create a host is one of these.
#1834 Generic Cyberdeck The parent object for all cyberdecks.
#1411752 Server The parent object for all servers (players cannot directly jack into these).
#1267977 NPC Server The parent objects for all NPC servers (reset themselves on area_reset, can't be picked up or configured by players).
#3815 Cyberdeck Control Feature This object holds all the verbs players can use to manipulate their cyberdecks when they are jacked in.
#1837 Generic Matrix Area The type of $area that must be used to contain rooms in cyberspace.
#2089 Generic Host A type of matrix area designed to hold a particular system (aka host).
#2178 Generic Matrix Exit The parent of all exits used in the internet. Direct descendants are generally only used within a single area.
#548263 Generic Matrix Firewalled Exit An exit that must be hacked to proceed. Can be protected by ICE.
#2124 Generic Network Hop A type of matrix exit used to transition between areas in the internet.
#1835 Generic Matrix Room The parent types for rooms you can visit in the internet.
#1829 Generic Network Interface A device that allows cyberdecks to connect to the internet.
#579237 Generic Matrix Targetted ICE ICE that targets a single player at a time.
#473624 Generic Matrix Pulsing ICE ICE that deals damage to all players in the room.
#459036 Generic Matrix Corp Controllable Orb A control box to allow corporations to take over things.
#199551 Generic Matrix Datacache A datacache that gives money to whoever hacked it.

The arrangement of networks & hosts is very important for maximum player clarity - the absence of a map makes intuitive navigation in the matrix extremely important!

Players explore the matrix by jacking into a cyberneck & connecting to other systems (HOSTS & host nodes) through a linked NETWORK, comprised of network nodes. Hosts should generally be set up to connect exclusively to networks, unless there is a strong gameplay justification to have a direct connection to another system (hidden hops to represent backports or remote access for service systems, as examples).

Ideally, networks work as a hub and spoke system, with all relevant hosts connecting to a single network node that represents either a geographical area or a connection service. For the Freedom City Metro Net, this is represented by the TLDs - we have one for commerce, one for residential connections, one for non-commercial organizations, etc. For smaller networks this can represent floors of a building or departments of an organization. Finding unique and fun ways to limit or allow access based on the player's physical connection point is the main design principle for matrix areas until more challenge mechanics are implemented in the matrix.

Servers should be used for almost all non-player owned hardware - cyberdecks are intended to gradually gain heat & lose charge when used, and essentially function as a decker's "body" while they're in the matrix. Harm to their gear should be an implicit risk any time they dive a system. Servers, on the other hand, are designed to run indefinitely and should generally be set up with better stats than an equivalent cyberdeck.

Retrieved from "https://hell-wiki.stuffie.club/index.php?title=Internet_(Programming)&oldid=9746"