(Lengthy) entire outline of abandoned futuristic RL attempt
eyenot
Tossing out a bunch of notes on a RL I've given up on. I've taken out
some things that I feel are too unique for me to give away, but there
are still some various problems and solutions as well as new and
interesting ideas that I've left intact. The outline system is fairly
easy: headings are indent-free and delimited with a colon, followed by
a basic summary of a feature or implementation, and indentations of
numbers of dashes create sub-topics, split-lines, and references to
other features. There are several references to sheets of paper which
in some cases were never transcribed, but I left those gaps in for the
sake of illustrating points worth continuing in development.
Sorry if anybody feels that it's useless information, but I can find
several ideas inside that I would salvage for the sake of a futuristic
RL if I felt like making one right now (I'm in depth into something
more ancient right now). I'm also sorry if the lengthy post upsets
anybody but I felt like posting it here instead of posting a URL to
someplace it might not be found in the future is more useful and
purposeful.
Notice there's no copyright; if you like, dig in free. The overall
world is designed around a system that creates that same worldmap
every time but the play is intended to be more or less randomly
generated. Some lootable feature-ideas of the futuristic play include:
"bullet-time"; virtual office; travel agency; collection and cryogenic
protection for delivery of unique genetic "proofs" to complete kill
contracts; family vs. family contracts; point driven contract
negotiation system; faulty natural memory (susceptible to memgrams) or
augmented memory; Memenetics(r) for memgram therapy; income-class
based economic system.
Please, for the love of binary, this document is not meant to be an
illustration of grace in coding. It's just an outline. I've tried to
spare the reader binary tables and other technical details.
Notes on why I gave up:
1. Didn't want to create the complex, randomly-generated lookup table
needed to keep the 65,535 location names contiguous and the location
types varied within those contiguancies. Also didn't want to create a
static map.
2. Never solved the problem of implementing viruses as textual
information in the user's personal office terminal (the suggested
implementation would have to be contradictory and logically could
never work, and yet I wanted it to work that way and didn't want to
ditch the feature).
3. The economic and crime-rate-vs.-enforcement problems that I
designed to regulate how much money the player can make doing repeated
actions would have worked but I lost the notes, which is why you don't
find it included here. Basically the player's activities begin to
create higher crime rates and those crime rates tend to create
increasingly difficult police presences and beefed-up computer
security in the affected regions, so that the player has to quickly
move on to other locations or pursuits in order to earn money.
4. This is one of several RLs I worked on where after much rich
outlining of design I gave up because I simply didn't like the look of
screens using a two-character tile format. It works for some genres
like RTS but I don't think it's fitting for most square-tile RLs, or
at least I can't implement it in a way that I would enjoy playing.
5. The outline below for bullet time was tweaked eventually to work.
It does not work now. :) The tweak involved using the average bullet-
time of every bullet-timer in the room as a multiplier for the purpose
of interjecting the chance for slower characters to make their
occasional moves in the middle of prolonged periods of bullet-time at
realistic intervals. It's basically the outline below to start with. I
know I didn't even like the solved version so if you don't like the
unsolved version below, believe me you are not alone!! :)
6. Started working on something else. :/
* * * * * cut here * * * * *
time/turn relation implementation:
most situations and actions ingame occur in terms of seconds
some things are faster than seconds:
- explosions: these occur instantly even in bullet time
- bullets / missiles
- subway trains
- the bullet-time enabled character (known as 'bullet-timers') being
fired at
- augmented interfacing
- very fast chars or NPCs
- moving cars and other vehicles
some things are slower than seconds:
- slow or encumbered action-taking
- things that are slowed are delayed by a reaction variable
-- the reaction variable ticks down every second
-- when it is reaction variable is 0, the character/thing can take its
action
-- (the slow character gets a chance to do something)
things that are fast either occur instantly:
- bullets/missile in normal time
- explosions any time
... or occur several times a second:
- actions of bullet-timers when being fired upon
-- bullet-timers can take a certain number of actions during bullet-
time
-- this is their normal bullet-time speed...
-- ...outside of the presence of other bullet-timers
- a bullet-timer's bullet-time speed is directly related to overall
speed
+ bullet-time is a special case seperate from normal time:
- bullet-time is started when a bullet or missile target is a bullet-
timer
-- a bullet-time ticker is placed to the right of the seconds-place by
timer
-- the bullet-time ticker is equal to the bullet-time speed...
-- ...of the fastest bullet-timer in the room...
-- ...modified down to be no more than the distance from bullet to
target
-- the bullet-time ticker says how many turns the bullet-time is going
to last
-- bullet-timers whose values are less than bullet-time ticker...
-- ...can choose to act or to wait each or any of those turns...
-- ...but they can only take as many turns as their bullet-time speed
allows
+ outline of a normal turn:
- fastest character first (determined by overall speed)
- ...next fastest, etc. ...
- slowest character who can act
- decrement any character slow-counters (reaction timers)
- tick one second on the clock
- repeat turn
+ how bullet-time is interjected:
- when any missiles appear, target is checked for bullet-time
-- if there aren't a bullet-timer, bullet-time is not interjected...
-- ...and the missile gets to take all turns it needs to reach its
target
- however, if they are a bullet-timer:
-- the characters in the room are checked for bullet-time attribute
-- the fastest bullet-time value in the room is used to set the ticker
-- the distance between missile and target is checked
--- (this is performed using the line function and returns a turn-
value)
-- if the ticker is more than that distance, the distance is used
instead
-- if the player is a bullet-timer, their bullet-time speed is shown
by it
-- example: 10/03 (10 turns of bullet-time, three available to the
player)
-- turns commence for all bullet-time enabled until their turns run
out
--- the fastest bullet-time gets to move first each turn
--- ...then the next fastest, so on to the slowest bullet-timer...
--- and the bullet moves last each turn, inching towards its target
--- if the fastest player uses up their bullet-time speed...
--- ...before the bullet reaches any target...
--- ...normal time ensues and the bullet is sent towards its original
target
some characters cannot expend bullet-time endlessly, some can
light rays/lasers do not count as missiles and do not trigger bullet-
time
+ bullet-trains:
- bullet trains do have bullet-time
- normally they just suddenly pass through the area
- you shouldn't be on the rails anyway!
example time-line:
....::::....::::....::::....::::
yr:2048 day:281 am12:45:17 10/03
year day hr mn sc bt pb
bt=turns left this bullet-time
pb=how many turns player can spend this bullet-time
time-consuming actions (and encumbrances):
-
- this is on the other side of the bullet-time idea sheet
-
locations:
+ virtual office:
- virtual office is not represented by a map, just menus
- virtual office is accessible from any plugged-in location
-- orbiter is plugged-in but not all other locations are
+ orbiter:
- *drastic change of original game design:*
-- it has come about that orbiter is probably the most difficult
location
-- and is probably reached fairly late in play due to inhibitive costs
--- this also makes the orbiter tantalizing and gives the player work
to do
- "NO PETS ALLOWED!"
- orbiter is the "extreme case" of location limits
- orbiter is also the only 'truly random' location
- the orbiter is a reconfigurable space station with 20 floors
-- (the denizens are always reconfiguring it for personal reasons)
-- floors 1-14 are used as public space
-- floor 15 is a storage and utility floor
-- floors 16-20 are for private quarters and other purposes
-- there is one hospital floor and one armory floor (both are
variable)
--- the hospital floor appears somewhere between floors 1-14
--- the armory floor appears somewhere between floors 16-19
- the orbiter is randomly generated each new game
-- (the player can manipulate some of this by way of contacts)
- the player will enter on the lowest (earthward-facing) floor
- there are multiple exits, but player is not always capable of using
all
-- there is the public transportation to and from the first floor
-- there are numerous spacelocks that will suck the player into space
-- there are several docks with docked re-entry vehicles
-- if the player piloted up their own vehicle, it should still be
docked
-- there are several emergency pods on /5th and /10th floors (except
20th)
--- emergency pods require state of emergency to board and tend to
disappear
--- emergency pods drop the player off at a random location
-- there is always a ship available for piloting from the top floor
-- the ship can be very difficult to obtain entry to
-- the ship can be navigated to any specific location
+ other locations:
- other locs are cities, highways, fissures, buildings,
- discos, cafes, etc.
- each location is psuedo-randomly generated so it will always be the
same
- (if ever arrived at one or more times)
- location names:
-- locations each have a unique name
-- the location value is 16 bits long
-- names inform the player of certain location attributes
-- these attributes include typical dimensions, floor types, and
entrances
--- fissures and dams are between 1 and 3 rooms 'wide' along one
dimension
---- fissures and dams have a very high number of floors
---- location entrances for fissures are at the top, dams either end
---- fissure and dam floor types are usually 'experimental'
---- dams have a cityspace floor type near the bottom
----- beneath this is a subway level
---- fissures have a 'cityspace' floor type at the top...
---- ...and a 'commercial' floor type beneath that...
---- ...followed by a subway level...
---- ...the rest are 'experimental' until nearing the bottom...
---- ...at which point there is an 'armory' and the rest are
'corporate'
--- valleys are between 3 and 6 rooms 'wide' along one dimension
---- valley location entrances are near both top and bottom
----
floor types:
every floor has a type that is used to determine its overall
attributes
+ 'experimental':
+ 'hospital':
+ 'armory':
+ 'diner':
+ 'residential':
+ 'cityspace':
+ 'utility':
+ 'public lobby':
+ 'subway level':
- a neat idea would be if subway tubes were navigable
- and player could walk subway tubes between locations
- in any case subway levels have trains waiting
- player uses a credstick (jacks not allowed)
- credstick fits into train door and train opens
+ 'commercial':
+ 'corporate':
+ 'spaceport':
- spaceport is usually at the top of a needle
- spaceport is also at the top of the orbiter location
+ 13
+ 14
+ 15
+ 16
travel:
travel agencies charge fees to various locations
- player can choose fmo a menu of potentially millions
travel destinations name generation is always the same
+ location names are generated from a library of fragments:
- "new ", "st. ", "little ", "villa ";
- "peter", "york", "mexico";
- " city", "burg", "ston"; etc.
- example: "new mexico city"
exits are always generated to the same locations
without travel expenses, player has to walk to locations
-- camping isn't allowed w/o a tent or with inroom NPCs
costs of private jets are in the billions of dollars
-
-
-
orbiter:
16x16 tiles per room
10 x 10 rooms in horizontal plane per floor
20 floors
floor 1 (public entrance) is type 'commercial'
floors 2-14 are type 'experimental'
- with one hospital, one armory, one diner... ... ...
*all rooms are 16 x 16 tiles*
tiles are 1 char tall, 2 char wide
player/npc movement 'skips' spaces
empty space is used to display attributes / items
16x16 x10x10 = 25,600 tiles per floor
16x16 x10x10 x20 = 512,000 tiles in orbiter
floor data:
floor data sets the atmosphere of a given floor:
- hospital, armory, diner, residential, cityspace, utility...
- experimental, public lobby, subway level, commercial, corporate...
- 100 rooms per floor is the maximum in any generation
-- possible: 3x20 (60), 2x40 (fissure, hway), 4x16 (64)
- 2000 rooms per location is the maximum in any generation
-- possible: 10x10x20 (2000), 2x40x25 (2000), 4x16x31 (1984)
-
bodies:
+ instring, body header is followed by data for:
- identity (w/genes), posessions,
+ body string format:
- "B", [two-byte identity], small-object posession codes, "-"
identity:
identities space contains identities of NPCs present
identities space is randomly generated
identities space is generated based on contract details
identities are terminated with a pipecode
+ identities begin with names, terminated with a comma
- first names are randomly generated from an incode library of neat
names
- sometimes identities have family names (before first name)
- names are sometimes followed by a roman numeral (terminated with a
space)
- roman numerals typically denote importance or wealth
- roman numerals are usually used to reserve contract personalities or
treats
+ after name and comma, identity continues with personal value
- *personal value *always* reflects relevancy to contract*
- (depending, personal value may be deducted from contract if NPC is
killed)
- (personal value is not the same as a credstick)
- personal value is stored as a signed, 32-bit short integer
-- ( -2,147,483,647 - 0 - +2,147,483,647 )
-- (personal value may be added to contract if NPC is killed)
kill-list:
the kill-list only stores the names of NPCs killed
it is a long string of names seperated by commas ending in a
terminator
- (DNA of kills is not stored in the kill list, just identities)
the player character has to remember the names of NPCs killed
- (unaugmented memory may fail the character)
player may have to check the identity of NPCs killed to retrieve this
info
- (augmented player may be able to retrieve the identity of living
NPCs)
*identities alone typically do not suffice to fulfill contracts*
genetic sample collection containers:
various sample containers can collect various sources of DNA
some can preserve samples, the rest eventually decay (bits are
destroyed)
+ various sources/sizes of DNA (4) include:
- (S=sample) i. blood, or tissue sample (severed finger)
- (O=object) ii. personal property (brush, bloody rag), or a rolled-up
face
- (H=head) iii. somebody's head (or just the face)
- (B=body) iv. some body (or fourteen heads)
-- (letters denote different major types/sizes of containers)
-- (letters appear below next to different prefixed container types)
damage to containers destroys the sample
+ example kits:
- (S) blood testing kit:
-- carbon vial with blood-drawing tiny glass tube
-- DNA sample has no added lifetime (chance of decay each new game)
-- requires collection of blood for sample
-- vial withstands all physical damage
-- sample does not necessarily survive much heat or fire
- (SO) cryo-tube:
-- carbon cylinder with cryo stasis units
-- tube withstands all physical damage (though cryo units may be
damaged)
-- sample survives heat and fire as long as there are any cryo units
-- one, two, and three cryo-unit design
- (S) DNA lab-rary(tm) (w- or w/o-cryo):
-- a metal discus with rotating sample tray and (1) interior cryo bulb
-- takes up only one inventory space but can carry multiple samples
-- cryo option only holds one cryo unit (it's for fridge-to-fridge)
-- "treat happy: lab-rary(tm) design is good to use
[cryo-]clinically!"
-- lab-rary is fairly sensitive to damage
-- w/o or zero cryo, lab-rary is fairly susceptible to much heat and
fire
-- enough damage to lab-rary will destroy all samples contained within
-- damage to lab-rary can destroy cryo unit
- (SO) Gene-Star(tm):
-- a carbon courier container outfitted for orbiting DNA preservation
-- good for one sample
-- container withstands all physical damage
-- cryos withstand all heat and fire, and most physical damage
-- samples withstand all heat and fire while cryos are intact
-- two or four cryo-unit design
- (S) DefenseNA(tm):
-- a carbon platter with rotating sample tray and (3) interior cryo
bulbs
--- military field hospital design
-- takes up only one inventory space but can carry multiple samples
-- container, samples and cryos withstand all physical damage
- (SOH) cryo-cranial container
-- a metal box with cryo units
--- "for keeping heads light yet cool", good for one sample
-- container is not made to withstand physical damage, but single cryo
unit is
- (SOHB) Morsicle(tm):
-- a hyperbaric chamber with full cryogenic stasis
-- "for commercial transport of intact bodies under normal conditions"
-- or it can be used to store fourteen heads
+ about cryo:
- cryo is by no means cheap to purchase or to refill or restock
- DNA sample decay is not checked if there are cryo units
- DNA sample decays as normal (percent chance) if there are zero cryo
units
- cryo units can be refilled by various means:
-- cryo refill or restock at medical laboratory
- cryo unit is deducted periodically:
-- ???? number of ingame turns, whether in new city or orbiter
- cryo unit may not withstand all physical damage (depends on model)
-- any damaged cryo unit is deducted immediately (refill still
possible)
- typical ingame kits have pre-set peculiarities
- new city medical services can provide whatever combination you need
- in data, kits are followed by their contents
--
--
+ about medical sciences:
- very expensive services in new city can custom-make special kits for
player
- expect to pay more than ten times usual cost for each peculiarity
-
+ about genetic samples:
- genetic samples are used for verifying identities and other purposes
- verifying identities can be done for money or to fulfill a contract
- gene laboratories will buy samples if they meet certain demands
-- gene laboratories do not always want the samples that you have
-- gene laboratories do not usually pay so much
-- gene laboratories desire tissues, faces, heads, and bodies the most
-- selling a lot of body parts depreciates your reputation quickly
- police will pay for verification of missing or wanted persons
-- selling to police may depreciate your reputation, at random
--- your reputation will either experience no change...
--- or your reputation will drop roughly as in selling an entire body
forms of proof (8):
+ proof can be in the form of DNA:
- p0001 i. DNA sample (any of the following marked with * count:)
[UNUSED]
- p0011 *ii. blood proof (some of the blood in vial or on a rag)
- p0100 *iii. kill proof (severed finger i.e. "tissue sample")
+ proof can be in the form of identity:
- p0000 iv. credstick
- p0010 *v. special personal posession
- p0101 *vi. the actual face
- p0110 *vii. the whole head
+ proof can be in the form of the body:
- p0111 *viii. the entire body
-- more bits turned on means more resistence to decay or heat/fire
damage
-- stipulations in the contract may call for a certain level of DNA
present
--- if the DNA present is lower, there is a chance of not meeting
stipulation
-
- all DNAs are in forms of proof?
- or are forms of proof contained in contracts?
- still a rough-edged spot
-
contracts:
* Latin phrase pacta sunt servanda (pacts must be kept).
contracts are brought to the player by hopeful clientele
contracts are randomly generated in new city
contracts determine to some extent the contents of the identity space
there are various types of contracts
+ family elimination contract:
- someone wants members of a particular family killed
- usually the family's identities are generated with negative personal
values
- richer contractors usually have families onboard the orbiter
-- the contractor's family typically are given positive personal
values
-- contractor's family values might not always outweigh value of
contract
- typically there is a bonus if all family members are proven killed
- proof of kill must be solid for full payment without haggling
- lack of proof of kill may warrant no payment
+ punishment contract:
- someone wants someone to be punished but not killed
- could be anybody
- typical stipulations are:
-- DNA retrieval
-- tissue sample
- client will include requirement not to kill target
-- not-to-kill requirements and stipulations are backed
-- the client can use a contact to confirm live status
+ message delivery and/or retrieval:
- certain phrases may trigger certain NPCs to scripted responses
- the client has a secret string for comparison against scrollback
-- this comparison is done automatically upon contract closure
-- (or several close variations, each one just as good)
-- client may or may not tolerate much mistaken data
reputation:
players with higher reputation can negotiate their contracts better
players with lower reputation have to take what they can get
contract negotiation: (negotiations:)
negotiation points are allocated when perusing a contract, based on
reputation
negotiations are only possible if the player has negotiation points
+ players can spend negotiation points to change certain elements of
contract:
- (negotiations proceed in the following numbered stages, first
through last)
- 1. remove stipulations (there tend to be many of these per
requirement)
-- removing stipulations will decrease the pay offered on the
requirement
- 2. remove requirements (these make up the contract)
-- requirements cannot be removed without removing all stipulations
first
-- removing a requirement removes all pay offered for that requirement
- 3. increase the pay offered on standing requirements
-- pay can only be increased per number of stipulations on requirement
-- example: a requirement with two stipulations offers pay of 20,000
--- you negotiate one increase for 3,000...
--- you negotiate another inrease for 1,000...
--- now the pay offer on the requirement is worth 24,000, however,
--- you cannot attempt to negotiate another increase,
--- (because the requirement is not complicated enough to haggle
over).
-- another example: a requirement with no stipulations
--- (you won't be able to negotiate for a higher pay offer)
-- pay increases are somewhat random, higher if you have more points
left
- 4. increase the up-front offer
-- increasing the up-front offer is harder if stipulations are removed
-- the up-front percentile is subtracted equally across all
requirements
-- example: two requirements, one for 20,000 and one for 40,000...
--- the up-front is %5 but you spend points to negotiate %10 up-
front...
--- now the two requirements offer 18,000 and 36,000...
--- and the up-front offer is 6,000.
-- the up-front percentile is higher when there are more overall
stipulations
-- the up-front percentile is higher when you have more points left
-- the up-front percentile raises less if there is already an up-front
offer
-- the up-front cannot be negotiated if it will not increase by at
least %1
-- example: the same contract, you negotiate two more up-front
increases...
--- the up-front offer increases to %17, then to %18...
--- then you cannot manage to increase the up-front any further.
- 5. (finalise and sign the contract)
- once the contract is finalised, all the details are locked-in
- once the contract is signed, you cannot back-out of it
- you can spend the up-front funds in new-city before leaving for the
orbiter
- quitting game without transferring to orbiter and with contract
pending...
-- ...destroys the contract,
-- ...which decreases the player's reputation,
-- ...especially so if there was an up-front offer! (no cheating!)
if the player has negative reputation, the situation is much
different:
+ the general gist is that the player owes somebody in the underworld
- (or has upset somebody in the underworld and needs to regain their
favor)
- instead of negotiating, the player has to deal with contractual
hazards
-- contractual hazards can include the player's paying a sum on
completion
-- (player will have to crawl for credsticks in the orbiter)
--- conversely, the orbiter will be set-up with at least minimal
requirements
- the pay can be very low or non-existent
- however, the contract offers a grand-sum of reputation score
redemption
-- however, failure to fulfill the contract lowers reputation by that
amount
orbiter contacts:
before embarking, the player can try to make conditions favorable
this requires a substantial reputation to start with
also, as opposed to spending detached "points", the player spends
reputation
- (this is because the orbital denizens prefer their isolation)
+ contacts allow the player to change the make-up and contents of the
orbiter:
- this can only affect floors 1-14
- a small cache of various things may be placed on a specified level
-- it will not include credsticks
- the hospital level (wherever it appears) may be left open by mistake
-- it may be left open by several entrances (more expensive)
- a terminal can be planted right at the entrance (expensive)
-- it can be left unsecured (more expensive)
- the armory (wherever it appears) may be left open
-- but not by both entrances (part of the security system)
-- and the entrance will be guarded by space marines (official arms
shipment)
- an elevator shaft may allow clear access to several floors
-- the first five, ten, or fifteen floors (more and more expensive)
-- in both directions (double the cost)
- any particular floor 1-14 can be set-up for navigation and access
-- two, three, or four exits open in "some", "most", or "all" rooms on
floor
-- expense increases for more rooms and is multiplied by exits
-- rooms that were going to generate with same or more exits are left
as-is
if the player has negative reputation, the situation is again much
different:
+ the general gist is that the orbiter denizens would rather not have
you
- credsticks above a certain value may not appear but once per visit
-- the lower your reputation is, the lower this 'ceiling' value is
-- credsticks in general will appear less often
- there will be more police about, more of them the lower your
reputation
- there will be a higher chance of warlords, assassins, and androids
- the orbiter will be more difficult to navigate
-- navigable difficulty may include harder maze-density
-- difficulty may also include many one-way turbolifts
-- difficulty may also include numerous security doors
-- difficulty may also include absence of light sources
clientele:
clients use descriptive language and explanatory narrative
- narrative shown while perusing contract before final
- pre-generated elements fit into typical slang variants
clients may sometimes have a desire to take revenge on player
- this may take the form of an attempted assassination
- this would occur independently of reputation score
character data:
- wounds, injuries, illnesses, abilities and disabilities,
augmentations
- inventory, traits, attributes,
- wealth, reputation, and number of contracts fulfilled
-- wealth is stored as an unsigned "long long int" (64 bits)
-- (1 billion begins at 40 bits, and no debt is allowed except by
reputation)
-- reputation is stored as a signed "int" (16 bits)
-- ( -32,767 - +32,767 ) 32,000 would make a good cap
-- number of contracts fulfilled is stored as one byte (0-256)
-- (it's a fairly unimportant number by that time, even as a trophy)
character display:
character is usually "O" symbol
crouching character is "o" symbol
stealth or invisible character is "@" symbol
room obstacles:
walls are displayed with a full char that takes up both char spaces of
tile
tables are "t" and block visibility of anything small or crouching
- tables and other inroom objects can be represented by a bit field
-- seperate bitfield for seperate object
-- collisions are checked against all bitfields attached to room
NPC display:
NPCs display differently depending on visibility and other situations
+ NPCs out of sight manifest as either:
- "!!" (you hear shouting/screaming, which appears in the dialogue
scrollback)
- "?!" (you hear talking, which appears in the dialogue scrollback)
- ",'" (you hear footsteps) [this is a comma and apostrophe]
- "* " (you hear a noise created by an otherwise stealthy character)
+ NPCs in sight manifest as their character on a tile:
- kids, dogs, cats, rats
- "H" (handservant)
- "L" (lady)
- "G" (gent)
- "P" (orbiter police)
- "M" (space marine)
- "W" (space warlord)
- "N" (obvious ninja assassin, otherwise appearing in disguise)
- "A" (android)
- "X" (alien)
- "@" (ghost)
- "I" (imaginary)
- "V" (demon)
imaginaries (I):
these characters appear more often if the player is having mental
problems
they can also be produced by holograph projectors
they could be produced by various means
interfaces:
there is just one generic terminal object
the data attached to the object determines what the terminal can do or
offer
several situations and interactions in the game work by way of
interfaces
interfaces are displays or menus that obscure normal view
- player does not see what's going on in the room when interfacing
- the rest of the game proceeds as normal:
-- NPCs still take their turns and inter-room situations are still
calculated
-- the player is still at the location they interfaced from
-- attacks against the player may or may not suddenly end the
interface
--- (players with higher armor or other resiliences remain interfaced)
-- implemented by redirecting to the interface before normal in/output
routine
-- (this way, when it's the player's turn their control is in the
interface)
+ manual interfacing versus datajacking:
- manual interfacing requires use of fingers
-- finger dexterity determines how many keypresses you can make in a
second
--- this is determined by speed with other affecting factors
--- finger dexterity affects all manual interfacing the same way
--- (SEE: more on finger dexterity in section on datacorders, under
memory)
- datajacking interface requires use of the mind and implants
-- data moves much more quickly than concrete reality
-- speed is a major factor in datajacking
--- normal speed increases (fast values) are a minor benefit
--- real speed in datajacking requires mastering bullet-time
some interfaces include:
+ orbiter terminals:
- use of terminals opens up various menu options
- each selected option from the menu does something then returns to
play
- each use of the terminal takes up some amount of time
- sometimes terminals malfunction
- there is usually one regular terminal on each floor
- there are also sub-master (5th floor) and master (15th) terminals
-- the regular terminal offers a variety of services:
--- regular terminal offers security
---- secured terminals require a passcode from one of the rooms on the
floor
---- (general-use passcode available to denizens from sub-master
terminal)
----- passcodes can be found in dialogue scrollback, which may be
unreliable
----- memory-augmented players can just retrieve passcodes perfectly
--- regular terminal allows the player to access a map of the floor
---- the terminal constructs the entire map
--- regular terminal allows the player to access a view of any given
room
---- the player has to have the passcode that was obtained in that
room
---- the entire room is shown from a ceiling camera
---- it's only a snapshot, no time-lapse, motion, or dialogue
-- sub-master terminal offers all the same services and more:
--- sub-master terminal offers enhanced security
---- no general-use passcode
---- instantly available general-use passcodes for terminals on floors
1-14
---- notification of status vehicle (if any) attached to the passcode
in use
----- whether or not it is docked securely (not where it is located)
---- instigation of emergency alert for any floor 1-14
----- this is just an emergency testing drill measure
----- this will not order evacuations: those require actual
emergencies
---- instigation of security alert for all floors 1-14
--- sub-master terminal offers enhanced mapping
---- menu of floormaps for floors 1-14
--- sub-master terminal offers limited orbital engineering controls
---- turning on/off turbolift directions (U/D) where available for
floors 1-14
----- turbolifts cannot be made to go up or down to turboliftless
floors
-- master terminal offers only the following engineering-selected
services:
--- master terminal offers extended orbital engineering controls
---- setting of passcode for any room on floors 1-14
---- de-activation of emergency alert for all floors 1-14
---- de-activation of security alert for all floors 1-14
---- installation and de-installation of turbolift in any room on
floors 1-14
----- this is only useful if lifts are installed at source and
destination
---- scheduled
+ electronic security:
- there are various methods to security
- electronic security has varying levels of difficulty
-- (more difficult security takes longer and is more difficult to
break)
-- security difficulty is first determined based on what it is
protecting
-- security difficulty is thereafter tweaked by floor type and height/
depth
+ travel options:
- low travel options are determined randomly by location and are very
limited
- highest travel option is to choose from any possible location
+ player's virtual office interface:
- player's virtual office can be reached from any terminal with a
comlink
-- not all dataterms have comlinks, but most of them do
-- comlinks are usually right near the entrance when inside the
dataterm
- player's virtual office gives access to the player's inbox
-- the inbox appears as two rows of sixteen characters each
--- this is implemented by a single string, the inbox string
--- the inbox string is 512 bytes long
--- each element in the inbox is written to the string starting at the
bar
--- each element is marked and delimited by special characters:
---- ^ -
---- > - right-angle bracket: this starts each individual element
---- (>)$ - dollar sign: this signifies a contract file
---- (>)@ - at-sign: this signifies a contact
---- (>)M - uppercase letter m: this signifies a message
---- after the special character comes the actual content
----- contents are special for each type but all must cease upon the >
char
----- *!!right-angle bracket must not appear in any other string or
data!!*
---- example of inbox string data:
---- [start of string:]me later.>$[contract info]>$MWhat's up?
--- all string data in the inbox wraps around from end to beginning of
string
--- everything to the right of the bar is older, to the left is more
recent
--- (newly arriving elements over-write oldest elements first)
--- the bar is placed after writing is completed for an element
--- after any element is opened, it is over-written with spaces
---
-- each character represents the type of element
-- the player moves a cursor over each element and chooses to open or
delete
-- elements in the inbox have to be opened to be of any use to the
player
-- once opened, contacts are added automatically to the addressbook
-- once opened, contracts are added automatically to the contract file
-- once opened, viruses perform their routines
--- *[QUESTIONABLE TO IMPLEMENT VIRUSES OR RAW DATA]*
--- viruses damage addressbook, contacts, contracts, and inbox
---- this is implemented by randomly obliterating some whole data
element
--- viruses can be checked for by a player who opens the inbox raw
data
---- inbox raw data appears as sixteen characters in a row beneath
inbox
---- player uses keys to scroll it left or right looking at the actual
string
---- (the trick: viruse messages contain the dollar-sign character)
-- once opened, messages are recorded to the player's dialogue
scrollback
---
- player's virtual office gives access to the contact addressbook
-- this is implemented by a menu of contacts kept in the addressbook
--- then a contact interface is called from within the office routine
- player's virtual office gives access to the contract files
+ contract interface:
- contract interface is always accessed by way of the contact
interface
--
+ dataterms (jacking-in):
- jacking-in requires a deck and a jack-implant
-- without a deck, player cannot jack-in but dataterms have a manual
interface
-- without a deck, the manual interface is only useful for comlink
-- manual interfacing a comlink just opens up the virtual office
interface
- being jacked-in resembles a location in some ways:
-- the player moves an avatar through many small 'rooms' (memory
addresses)
--- rooms are 2x2 spaces which display data about the address:
--- @ - player in address
--- & - intruder countermeasure in address
--- $ - bank account access codes
---- player's deck records all looted bank codes as a string of digits
----- each digit represents the bank code's value class
------ value class should be higher if it was harder to obtain the
bank code
------ value class is not actually visible to the player
------ value class is depreciated over time
---- these digits are used to construct a dollar amount
----- dollar amount is not visible to player until transfer
---- value classes carried in the deck are not readily accessible
---- funds are transferred on the next visit to player's virtual
office
----- this visit must be performed through datajack and internal
comlink
----- player must be using that deck in order to transfers those funds
----- individual codes are destroyed when deck is damaged
---- every hour on the hour, funds in the accounts change slightly
----- a given value class in the deck may be depreciated by one
------ this is implemented by randomly choosing one of the deck's
values
------ the higher the value class, the less likely it will be
depreciated
---- every new day, funds in the accounts change more drastically
----- a given value class in the deck is depreciated by one
------ this is implemented by randomly choosing one of the deck's
values
------ the value class is decremented by one and replaced with the new
value
------ a new value of the lowest possible class is added to the deck
--- ! - dialogue file
--- exits: each address has four exits and each exit has four types
--- # - open/free exit to another memory address
--- % - secured exit to another memory address
--- o - exit back to terminal
--- * - comlink
+ engineering interface:
- in cities, multiple buildings may exist seperately and distinctly
-- (these are usually generated from the ground floor up...
-- ...in terms of greater-room/floor-plan resolution)
- player may use engineering terminals to change lifts, exits, etc.
- engineering terminals needs their effects restrained to certain
places
- each engineering terminal has:
-- x-axis boundaries (east and west)
-- y-axis boundaries (north and south)
-- floor boundaries (up and down)
-- on or off for various abilities
--- such as whether lifts can be changed, removed, installed, etc.
--- or whether door securities can be changed or exits removed,
installed etc.
scrollback:
the scrollback is several lines along the right margin that contains
dialogue
it can have varying capacities from one to sixteen columns
only one column is visible at a time
memory:
+ "natural memory" is the unaugmented section of the memory:
- natural memory begins with the first two columns but can be expanded
-- this is implemented by an attribute variable for mental ability
--- (this variable is never shown to the player)
-- when this variable passes certain values, natural memory increases
--- the value of the variable itself be decrimented by various things
---- decrementing the variable does not reduced natural memory,
---- but it does make it harder to reach the next point of natural
expansion
---- this value is higher the more natural expansion player has earned
---- losing a segment of natural memory to implantation sets back this
value
---- (again, though, decrementing value does not imply losing
expansions)
- natural memory is expanded through certain means:
-- spending time without any implants (raises variable slowly over
time)
-- eating 'brain-food': ginko; sushi... ... ...
--- (player is never told explicitly that these are "brain-foods")
--- these give larger increments to the variable (inhibitively
expensive)
- natural memory can be reduced by the installation of implants
-- natural memory cannot be reduced to less than one column
-- that would be tantamount to having your brain completely replaced
-- natural memory is only reduced by whole columns at a time
-- when natural memory is reduced, the value is set back
formulaically...
--- ...to reflect having just passed earning the highest remaining
expansion
+ players who do not wish to use memory augmentation have an option:
- players may rely on datacorders
- datacorders use the windowspace usually occupied by inventory
-- an active datacorder can be switched quickly with inventory list
--- (unlike inventory, active datacorder takes two keypresses to
interface)
-- because this windowspace is visible during all other interfaces...
-- ...datacorder (and inventory) can be referenced while in other
interfaces
--- however, like inventory, datacorder interfacing must be allowed to
stay...
--- ...visible while user is not directly interfacing with it.
--- for this purpose, datacorder interface routine nesting must be
fairly...
--- ...complicated and carry some requirements...
--- ...these requirements luckily meet realistic simulation of action.
---- 1. datacorder must be in a player's either hand to be operated at
all
---- 2. 'use' of datacorder toggles datacorder on/off
('active'/'inactive')
----- removing datacorder from hand turns datacorder off automatically
---- 3. with datacorder on/'active', datacorder interface is available
---- 4. player uses a normal keypress to open inventory ("i")
----- (unlike datacorder, inventory immediately interfaces upon being
opened)
---- 5. player also uses a normal keypress to open datacorder ("[i
dunno]")
----- pressing datacorder key once brings datacorder to visibility
----- pressing datacorder key while datacorder is visible opens
interface
------ datacorder interface reprints all datacorder contents in bold
------ datacorder interface shows currently highlighted line in
reverse
------ datacorder interface is closed with enter key
------- upon closing, datacorder returns to 'visible mode'
------ datacorder visible mode reprints all datacorder contents in
normal
------ datacorder visible mode shows last highlighted line in bold
---- 6. whichever was most recently used is still visible in
windowspace...
---- ...after the action is completed
- finger dexterity in datacording:
-- datacorder interface is manually operated, therefore speed comes
into play
--- all manual interfaces are regulated by the same speed/time process
---- normal typematic rate is three keypresses per second
---- player's typematic rate can be increased or decreased, depending
on speed
- different types of datacorders:
-- different datacorders have different capacities, strengths, and
weaknesses
--
--
--
+ psis are able to ruin natural memory by use of various mental
tricks:
- the only psis are androids, aliens, demons, space warlords, and
imaginaries
- memgrams:
-- memgrams only affect the 'natural memory' (unaugmented scrollback
segments)
--- this is implemented by placement of an memgram in player's -
scrollback
--- the memgram is the "@" character
--- the memgram only comes by way of dialogue spoken by the psi
---- (so the best defense against psi is to shut your ears with
something)
-- the memgram can't be overwritten because the natural mind resists
it!
-- memgrams can only be removed through the use of Memenetics(r):
--- buying Memenetics(r) literature attempts to convert each @ in
scrollback
---- likelihood of this working depends on how good you are at
Memenetics(r)
---- reading lit will remove @ starting at 10% per read up to 50%
----- this is implemented by reading the book from your inventory
----- 10%: "You read the book some but then give up and throw it
away."
----- 20%: "You read more, realizing you were wrong as the book falls
apart."
----- 30%: "You read the book cover to cover and tear the book into
pieces!"
----- 40%: "after completing the book you realise reading alone isn't
enough!"
----- 50%: "You pull a few more insights from the Memenetics(R)
handbook."
----- (the percentage is higher for higher levels of Memenetics(r) in
player)
----- at which point the game attempts to remove your memgrams
----- each memgram has that percentile chance of being removed
---- but only actual Memenetic(r) therapy can clear all memgrams!
--- undergoing Memenetic(r) therapy removes all current @ from
scrollback
--- Memenetic(r) therapy also increases your level of Memenetics(r)
---- this level measures how good you are at Memenetics(r)
---- levels are reached immediately upon therapy sessions
---- there is a small chance of reaching levels by reading lit
---- Memenetics(r) can help the character achieve other skills and
abilities
---- there are ten levels of Memenetics(r):
----- 1: stinking moron (everybody on Earth is at this level)
------ the stinking moron has no psi resistance and lit level of 10%
------ chance of passing to the next level by reading lit is 10%
----- 2: crises-informed
------ after your first therapy session you are at this level
------ your first therapy session also costs a bundle:
------ the crises-informed have 10% psi resistance and lit level of
20%
------ chance of passing to the next level by reading lit is 5%
----- 3:
------ after your second therapy session you are at this level
------ cost of therapy:
------ 20% psi resistance and lit level of 30%
------ chance of passing to the next level by reading lit is 1%
----- 4:
------ after your third therapy session you are at this level
------ cost of therapy:
------ 30% psi resistance and lit level of 40%
----- 5:
------ after your fourth therapy session you are at this level
------ cost of therapy:
------ 40% psi resistance and lit level of 50%
------ player action of resting removes one memgram with 10% success
------ natural expansion variable incrementation is increased:
----- 6:
------ after your fifth therapy session you are at this level
------ cost of therapy:
------ 50% psi resistance
------ player action of resting removes one memgram with 20% success
------ other player actions remove one memgram with 10% success
------ natural expansion variable incrementation is increased:
----- 7:
------ after your sixth therapy session you are at this level
------ cost of therapy:
------ 60% psi resistance
------ player action of resting removes one memgram with 50% success
------ other player actions remove one memgram with 50% success
------ natural expansion variable incrementation is increased:
----- 8:
------ after your seventh therapy session you are at this level
------ cost of therapy:
------ 70% psi resistance
------ player action of resting removes one memgram with 100% success
------ other player actions remove one memgram with 50% success
------ natural expansion variable incrementation is increased:
--- there are no intermediate therapy sessions and no repeating a
level
--- character must rely on lit to deal with memgrams in between
sessions
-
-
-
dialogue scrollback:
sometimes stealth doesn't work out perfectly
the character encounters a great deal of information in any location
+ the dialogue scrollback contains several types of this information:
- discovered passcodes (numerals)
- anything else which is read by the player character (except the
terminal)
- spoken dialogue (including the name of the speaker if identified)
- in-room intercom system announcements (including numerals)
- orbiter-wide intercom system announcements (including numerals)
-- the occurance of any numerals in the scrollback tends to degrade
over time
--- this forgetfulness can be changed by various factors
scrollback contains data (including delimiters and headers)
scrollback also contains the scrollbar, bad sectors, and 'memgrams'
+ talking to oneself is useful for retaining important scrollback
memory:
- this is infinitely useful in message delivery contracts
- there is a small chance of re-storing data incorrectly
-- individual characters may be wrong
-- whole words may be replaced in some situations
--- this would be implemented by substitution library
-- ex: "the dog is dead" becomes...
-- "the smurf is dear" (dog/smurf, d/r) (example of very low mental
ability)
- *all dialogue entered by the character (to self or others) has
limitations*
-- special characters: @
--- at-sign: this is a memgram. it is not overwritten by anything.
---- at-signs are used by psis to ruin memory.
---- whenever they appear, they are written to natural memory
----- this is despite wherever the databar is currently located in
memory
----- ("natural memory" is the first section of memory without
augmentation)
---- the space where they were in dialogue is replaced by a question-
mark (?)
-
-
-
augmentations:
augmentations increase the abilities of the player character
mind implant malfunction may cause permanent corruption loss of
recorded data
some malfunctions are also permanent, while others are intermittent
+ there are several augmentations for the mind or
memory:
- the player's memory does not suffer timed degradation with the
following
- datadisk implant:
-- the player's memory is not expanded
-- however, damage to the player may cause bad sectors
--- bad sectors are implemented by randomly placed obliterating
characters
---- these are special dialogue character: "*" (asterisk)
---- asterisks are not overwritten by anything, even the scrollback
databar!
--- bad sectors appear in dialogue scrollback
--- bad sector count is stored in one byte
-- disks that are damaged need to be surgically replaced
--- this requires purchasing an entirely new implant (no cheap
replacement)
- mindflash implant:
-- the player's memory is expanded
-- much heat or fire can cause glitches but not bad sectors
--- glitches are implemented by randomly changed letters or numerals
--- the glitching only appears in the presence of much heat and fire
- karonano implant:
-- nanobots that pass the blood-brain barrier
-- the player's memory is expanded to fullest amount
-- much heat or fire can cause glitches but not bad sectors (a la
mindflash)
-- physical damage can cause loss of memory expansions
- neuro
-
-
credsticks:
credsticks contain various sums of money that can be used ingame
credsticks don't just add to the player's lump wealth
player may wish to keep a personal credstick with some value on it
credstick transfer to/from personal wealth is done through virtual
office
in manual entry, while in virtual office, player chooses 'swipe
credstick'
then the inventory is opened for the player to choose the credstick
then the credstick transfer interface is opened inside the virtual
office
in datajacking, while in virtual office, player chooses 'transfer
funds'
the invisible deck wealth variable is transferred to player's wealth
the correlation between credsticks and deck is via a 'swipe' as well
player simply 'use's the credstick with the deck
the value on the credstick is given a class
if there is an account of equal class in the deck, it is increased by
one
if there are no accounts of equal class in the deck...
...the credstick's class is added to the deck
once they are looted, these bank codes are invisible to the player
anyway
* * * * * (end) * * * * *
Krice
> Notes on why I gave up:
0. You did not start small.
Ido Yehieli
Kettle, pot, black, etc..
Krice
> Kettle, pot, black, etc..
I have abandoned only one roguelike project out
of six (PacRL). Kaduria might be seen as a result of
not starting small, but it's not an abandoned
project, far from it.
Ido Yehieli
No problem, I thought you've made a pretty good point.
eyenot
I can deeply understand that point of view. If you start with your
basics, then you can expand on that later.
However, that's the perfect forumula for running into "problems". If
you plan out every feature you'd like in the game first, then you'll
have a clear view of what needs to be done from the very beginning to
accomodate all the features you'll be adding later on. In that sense
even a thoroughly-planned, very "big" game would have to "start
small", considering you can't possible code the entire thing straight
through.
Nahjor
> However, that's the perfect forumula for running into "problems". If
> you plan out every feature you'd like in the game first, then you'll
> have a clear view of what needs to be done from the very beginning to
> accomodate all the features you'll be adding later on.
If you can do this accurately, you deserve a big, shiny medal, because
I've never met anyone (myself included) who can predict every feature
that they'll eventually want in a project of roguelike complexity.
Krice
> very "big" game would have to "start small"
It doesn't start small.
Martin Read
>However, that's the perfect forumula for running into "problems". If
>you plan out every feature you'd like in the game first,
... your design will be wrong.
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"
eyenot
I know several coders who can, at the very least, accomodate all
future features of a given program by relegating the needs of the
program into a simple expandable scheme such as an internal scripting
language. But I think this sort of modularity of design is lost to
today's "object oriented" programmers.
eyenot
I take it that's some humor meant to suggest that a game you don't
plan to expand is somehow wrong inherently. Good one.
I really don't feel like hosting a forum on the yins and yangs of
programming in this topic. If you don't like anything you see in the
litter box, don't pick through it.
zai...@zaimoni.com
> I know several coders who can, at the very least, accomodate all
> future features of a given program by relegating the needs of the
> program into a simple expandable scheme such as an internal scripting
> language. But I think this sort of modularity of design is lost to
> today's "object oriented" programmers.
What do you expect from procedural programmers who have been conned
(by their coursework) into thinking that using an object-oriented
language automatically means they're object-oriented programmers?
Also, I don't see what's more "expandable" about a scripting language
than a typically compiled language (C or C++); the key thing is
actually being able to design for change in the first place.
Martin Read
>On Jul 30, 2:04=A0pm, Martin Read <mpr...@chiark.greenend.org.uk> wrote:
>> ... your design will be wrong.
>
>plan to expand is somehow wrong inherently. Good one.
Not at all. It was mean as a stark statement of the practicalities of
software design.
Paul Donnelly
So now it's necessary to maintain code in two languages, one
ill-suited for game programming (otherwise the *whole* game would be
it), and the other ad-hoc, quirky, and unsuitable for writing large
programs (otherwise the *whole* game would be in it). I'm kind of
leaning towards the objects at this point.
eyenot
> Also, I don't see what's more "expandable" about a scripting language
> than a typically compiled language (C or C++); the key thing is
> actually being able to design for change in the first place.
Good point, which means my argument is already made for itself, and we
go all the way back behind script, behind feature, behind language, to
what? The planning before diving into the coding. And if the planning
is insufficient, then what? You're going to have to widen, untangle,
redefine, and recode later in a fit of work that increases
exponentially with how much "work" you've done so far. It's not "work"
if it doesn't *fit* with these hypothetical "later additions", now is
it? It's "mistakes", because it's getting gutted and rewritten to
"fit" with what's "new". Well if you sit down and *plan* your program
first, to the point of being satisfied with what it seems to be, and
*then* you go and code it, now you have something that what? "Works".
The code you punched out for those many hours was what? "Work". Now,
you could say, "yeah, you should ditch the idea of a script, that's
why you have the language is what programmed for in the first place,
har har har!" But let's note two things: 1. the language is capable of
defining a set of things much larger than what need be involved in
your program; 2. the script however can be made to expand indefinitely
upon your program using the few definable elements that makes up the
bits and pieces of what the program is meant to perform, and not need
all the additional functionality of an entire language, furthermore;
3. now your end-users can expand on their own. If I'm not mistaken
this is why people design engines, is it not? You could argue all day
about the ineffectiveness of engines-to-date and all that says is that
maybe, if you don't like it, you should get out there and make a more
effective engine.
Look, this is why I said "this isn't an entry for the yin and yang of
programming" and yet look, here I am. I'm not going any further with
you in this, if you don't want the bits, don't pick at it.
eyenot
>
> - Show quoted text -
Hey, say what you want, but when you find something works and is
effective, you go with it. You don't praddle about trying to reduce
what you're doing to philosophical end-all-be-all terms, or what? Your
entire *life* "would be in it", which means your success of redefining
'it' falls to 0%.
I really don't like this one-up-nerdism and if you'd read above you'd
find I'm not really feeling up to hosting any kind of "debate" about
the merits of this or that programming. If you've ever been through
enough debate (which I already know you have) then you realise than
anything can be successfully arbitrated more ways from sunday than
need be done. And what do we know works better than being a runamok
troll in the newsgroups? Just doing what works, period.
Scripts work for numerous reasons, in numerous applications. Their
ability to do so depends first on the designer's ability to reduce the
tasks, traits and attributes of the program to several elements that
are repeated and combined. Granted, this steps up out of programming
and more into analysis and perhaps even philosophy, especially when
we're talking about something as intangible and aesthetically measured
as entertainment, but you can take what you've figured from those
concepts and bring it back down into code. The focus, by the way, of
any dedicated language or machine is on its certain, specific task.
Granted, you might even have to cram a little bit of additional
information into your already enormous cranium, but the trade-off is
that you have a faster and easier way to implement design changes *for
that task*. But, perhaps you're the sort of person who'd rather re-
program their own entire CAD rather than have to learn the format that
the design is expected to be in. I dunno, maybe you don't understand
anything about dedication. This really isn't the sort of argument I
really feel like I should be having, if it's this particular subject
matter, with anybody worth having it with.
Derek Ray
> On Aug 6, 10:32 pm, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>> So now it's necessary to maintain code in two languages, one
>> ill-suited for game programming (otherwise the *whole* game would be
>> it), and the other ad-hoc, quirky, and unsuitable for writing large
>> programs (otherwise the *whole* game would be in it). I'm kind of
>> leaning towards the objects at this point.
>
Can you show me something you've made this way that works?
I mean something that can be played? A finished product?
(as for the rest, tl;dr, learn to make your points simply and clearly;
nobody has or should make time to read deranged ramblings these days)
--
Derek
Game info and change log: http://sporkhack.com
Beta Server: telnet://sporkhack.com
IRC: irc.freenode.net, #sporkhack
Paul Donnelly
Let's not have it then. Why don't I modify my previous post to say
that ad-hoc scripting languages (and config formats, for that matter)
leave a bad taste in my mouth, and sadly ad-hoc seems to be the rule
rather than the exception. You want to embed Lua, or Python, or
Scheme, and I'm right with you. You want to make up your own, and I'd
rather skip the whole thing and hack the source directly (assuming
it's reasonably easy to extend (it won't be)). Because given the
wimpiness of the average (purported) *general-purpose* language, the
odds that a one-off scripting language won't be even worse are poor. I
feel that scripting too often sticks you between trying to use a
language inadequate for your needs or trying to modify a codebase
that's too much a mess to touch--because you were supposed to add
features with scripts. Compare Vim and its Vimscript to window
managers like Xmonad (Haskell), StumpWM (Lisp), or wmii (everything
under the sun), or to its old nemesis, Emacs (elisp), and you'll catch
my point. I dont' think anyone could disagree in principle, though
maybe you're more optimistic than I about recieving a good scripting
language rather than a bad one.
zai...@zaimoni.com
> Let's not have it then. Why don't I modify my previous post to say
> that ad-hoc scripting languages (and config formats, for that matter)
V's (and by inheritance, Zaiband's) configuration files come to mind.
I really have no idea why tab-separated spreadsheets weren't good
enough for V2.5.x -- perhaps they weren't idiosyncratic enough to get
away with the Koeneke license? (The only nontrivial implementation
issue with tab-separated spreadsheets is representing the bitflags in
a human-readable form.)
> leave a bad taste in my mouth, and sadly ad-hoc seems to be the rule
> rather than the exception.
While a domain-specific language must necessarily be ad-hoc, typically
they are for *well-defined* domains, and as such don't really need
extension and continual maintenance.
(Roguelike) game programming isn't well-defined enough to get away
with this.
> .....
> Because given the
> wimpiness of the average (purported) *general-purpose* language,
An inferior programmer-time/execution time tradeoff; Oz comes to
mind. The backend power for directly coding nondeterministic
algorithms really impairs the normal use cases.
(I haven't used PL/I or ALGOL at all; it would be interesting to see
how a good modern implementation of either stacks up against the more
conventional programming languages.)
eyenot
> I mean something that can be played? A finished product?
>
> (as for the rest, tl;dr, learn to make your points simply and clearly;
> nobody has or should make time to read deranged ramblings these days)
>
That's the great thing about arguments like this. Not only do they not
lead anywhere, but they result in slews of insults that come from as
much of nowhere as the reason for the argument in the first place.
Now let me put you back into your appropriate place: are you seriously
asking me
-- in comments to a post re: an abandoned project, i.e. a failure to
produce code --
to produce some code for you? Are you just out of your head to just
vent at somebody to be that far out on a limb? Is that it for you and
others here, for RGRL to be a place to get pompous and to ignore
simple requests such as "let's not turn this into a discussion of
coding"? Do you see now why I had to make those sort of pre-emptive
requests in the first place? I have a long experience in coding, and I
don't need to defend *that*, that's absolutely for sure. What I need
to defend is my right to happily use a newsgroup that -- sorry to
interrupt whatever you felt you had going on here, but -- I find
entertaining. Not a showcase for debate but for creativity. "Happily",
as in, without harassment. This is it, I'm not responding to any more
discussions under this parent, any potential for creative community
has been ruined by people who weren't even interested.
As for your tl/dr, go back (if you aren't doing so already to verify
that you indeed seem to have missed some drastically original points)
and read the subject and first line. Ironically I have it all outlined
in asterisks a la "spoiler".
eyenot
> that ad-hoc scripting languages (and config formats, for that matter)
> leave a bad taste in my mouth, and sadly ad-hoc seems to be the rule
> rather than the exception. You want to embed Lua, or Python, or
> Scheme, and I'm right with you. You want to make up your own, and I'd
> rather skip the whole thing and hack the source directly (assuming
> it's reasonably easy to extend (it won't be)). Because given the
> wimpiness of the average (purported) *general-purpose* language, the
> odds that a one-off scripting language won't be even worse are poor. I
> feel that scripting too often sticks you between trying to use a
> language inadequate for your needs or trying to modify a codebase
> that's too much a mess to touch--because you were supposed to add
> features with scripts. Compare Vim and its Vimscript to window
> managers like Xmonad (Haskell), StumpWM (Lisp), or wmii (everything
> under the sun), or to its old nemesis, Emacs (elisp), and you'll catch
> my point. I dont' think anyone could disagree in principle, though
> maybe you're more optimistic than I about recieving a good scripting
>
I said to a reply just a moment ago that I wouldn't have any more
discussion under this parent, but I just had to break that self-
promise to respond here, since you bring up numerous great points
altogether in a way that begs for further discussion. I think what I'd
rather do is try to get a parent entry going regarding the possible
merits versus drawbacks of metacoding, scripting, and so on. You're
absolutely right, there has been numerous well-known and for the most
part very usable and scriptable programs that I've approached for
scripting purposes and have been thrown back by the level of study
needed to get a simple task done. I think it could be an entertaining
discussion, too, because of a certain trait of roguelikes to be very
much a case of study as well. For instance I just can't stand to try
to get through netHack or Adom these days because of the encyclopedic
knowledge needed to do it "right". And I like to beat games! I've
beaten so many games it's not funny, I love mastering gameplay. But in
the case of most roguelikes -- and I mean, all random influences upon
individual sessions aside -- there's just too much dedication required
of the player. So the discussion could bring up at least two
definitions of "dedication" in two directly related contexts. I'd love
to get around to discussing the potential expediency versus the
potential uselessness of a "really really good roguelike engine" (I
place quotes because admittedly it seems almost grail-like). I guess
we could even discuss whether libraries are a good idea or bad (I say
bad), but I'm really mostly interested in exploring post-product
metacoding, like scripts, "roguewads" might be a good term for some
things to discuss, and so on.
And I apologise, I don't mean to come off so harsh, it's just that I'm
a fairly controlling and cranky person and I forget that online
discussions can be dynamic even if they aren't going the way you'd
like. I forgot for instance to just think like I did above and maybe
start another parent, instead of trying to rail against the tide here
and keep the discussion here the way I'd like to see it. And, having
not used newsgroups since the early nineties, I forget how they really
go and was sort of letting the influence of forums and blogs dictate
my ability. And, too, I have to remember that considering I'm the
person who posted a failure to complete even the working outline to
begin to code off of (which I'm afraid is a habit nobody would be able
to argue me out of, I just like to know exactly how I'm going to code
pretty much every single line before I start in coding) I should be
perhaps the last one to say that I'm not going to change my ideals
concerning proper use of code. To your credit, I did come up with a
rebuttle to myself yesterday, basically that in an environment where a
person would tend to keep sources instead of binaries and prefers to
compile and build rather than execute, there is no reason to support
any ideas of metacoding or pseudolanguages.
If you want to start the parent off, be my guest, I'm delaying my
camping trip until maybe Thursday, so I'll have a couple of days to
join in before Monday.
Krice
> I have a long experience in coding
Now I know. You don't take this as a failure. You are not
a kind of guy who can accept a failure. You just
abandoned the project for some minor reasons.
Ido Yehieli
> As for your tl/dr, go back (if you aren't doing so already to verify
> that you indeed seem to have missed some drastically original points)
> and read the subject and first line.
Although I don't like the way he did it, Derek actually has a valid
point hidden in his comment - if you want people here to read your
posts you have to make them short and to the point.
-Ido.
Martin Read
Agreed; I find eyenot's 200+ word paragraphs take so much effort to read
that I *tend* to just skip them entirely.
David Damerell
>>Can you show me something you've made this way that works?
>>I mean something that can be played? A finished product?
>asking me
>-- in comments to a post re: an abandoned project, i.e. a failure to
>produce code --
>to produce some code for you?
No; he's asking you to produce some code after you started lecturing on
how wonderful your preferred approach to writing code is.
>vent at somebody to be that far out on a limb? Is that it for you and
>others here, for RGRL to be a place to get pompous and to ignore
>simple requests such as "let's not turn this into a discussion of
>coding"?
It is always correct to ignore any request of the form "let's not discuss
[any on-topic thing]". If you aren't interested in some subthreads, don't
post in them.
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is Gouday, July.
Derek Ray
>> Can you show me something you've made this way that works?
>> I mean something that can be played? A finished product?
>>
> asking me
>
> -- in comments to a post re: an abandoned project, i.e. a failure to
> produce code --
>
> to produce some code for you?
It was a rhetorical question, really. Now let me put YOU back in
YOUR place. You said, in the message I responded to:
> Hey, say what you want, but when you find something works and is
> effective, you go with it
And I'm asking what basis you have for assuming that something works,
especially when you admitted that you failed to produce any code at the
end of it. That sounds a lot more to me like "it doesn't work", and
other posters have posted some cogent objections that you've blithely
whizzed on by -- the effort of maintaining a custom internal scripting
code in addition to writing in the native code, for example, being far
more than it's worth in practice.
I think your statement "something works and is effective" is, in other
words, something completely made up on the spot and directly
contradicted by your own results.
>> (as for the rest, tl;dr, learn to make your points simply and clearly;
>> nobody has or should make time to read deranged ramblings these days)
> As for your tl/dr, go back (if you aren't doing so already to verify
> that you indeed seem to have missed some drastically original points)
> and read the subject and first line. Ironically I have it all outlined
> in asterisks a la "spoiler".
Again, learn to make your points simply and clearly; nobody has or
should need to make time to read deranged, stream-of-consciousness
rambling anymore.
eyenot
Exactly!
eyenot
> post in them.
Exactly!