Fate's Developer Journal
From LSWiki
(Difference between revisions)
Revision as of 22:40, 21 January 2014 (edit) Valdemor (Talk | contribs) (fixed up headings) ← Previous diff |
Current revision (01:34, 20 November 2018) (edit) Valdemor (Talk | contribs) |
||
Line 1: | Line 1: | ||
- | Often when I'm playing Lost Souls (and sometimes when I'm not), I'll get hit by bouts of inspiration on projects I'm working on or features/mechanics I'd like to change or implement. Instead of leaving them to stew and eventually be forgotten, I've decided to write these down in a journal so that I will remember them later and hopefully actually work on them. The entries tend to devolve into rants or fantacising on my part. | ||
- | |||
- | The journal is in org-mode format, separated into headings for convenience. Please keep in mind that this is not so much a list of stuff I will actually do as a collection of my thoughts on the game from a developer's perspective. Maybe I will work on the entries some day; hopefully another developer will read some of them and be inspired in turn; and most likely they will sit here to be interesting exercises in wishful thinking and naught else. | ||
- | |||
- | |||
- | == * sensory acuity traits <2014-01-21 Tue> :traits :new: == | ||
- | Add five traits for acuity in the five senses, to use in room | ||
- | description detail / searching / quests, etc. Value should go from 0 | ||
- | (don't have that sense) to 10 (localized omnipotence), with five | ||
- | being the average using humans as a reference. Traits should increase | ||
- | in value with skills/attributes like CF/OF, 1 per 100 awareness and | ||
- | perception. | ||
- | |||
- | == * mounts <2014-01-21 Tue> :mechanics :revamp :rant: == | ||
- | Overhall the mount system to make more sense and be less broken. With | ||
- | low riding skill, directing a mount should be difficult and | ||
- | imprecise. For example, complex go commands should be badly | ||
- | interpreted, directions should mix up. Have mounts keep going in one | ||
- | direction until you issue a stop a command; only implement current | ||
- | system of stopping after go command is fully executed for really high | ||
- | riding skill. Add the chance of mounts throwing you off during | ||
- | movement and combat. Using a mount should train riding/equestrian | ||
- | (props to Agun for this). Give mounts the ability to carry containers | ||
- | (saddlebags, sacks, etc) and to pull stuff (carriages, ploughs, etc); | ||
- | alternately create a separate module for this (mule). Using a mount | ||
- | for too long in too short a time should tire it out and make it less | ||
- | effective (temp negative mods to skills/attribs), dependant on how | ||
- | well the rider understands the animal (animal lore, equestrian, | ||
- | biology, etc) and the mount's own skills (stamina, running, possible | ||
- | new skill specifically for carrying people). Since the game is | ||
- | already a simulationist fantacy, why not set up a system of stable | ||
- | outposts for exchanging tired mounts for fresh ones (I.E roman postal | ||
- | system)? The mule system can be taken further too; have a network of | ||
- | carivans between the major towns to ferry passengers on horse-drawn | ||
- | carriages. These carivans could experience random raids from bandits | ||
- | and the like; this could lead to a new slinger-like association for | ||
- | fighting them off? On the other side of the coin, players could | ||
- | attack and steel from trading caravans for plunder (melange shipments | ||
- | from the desert, magical gems from Liathyr, etc). Maybe Shatterspire | ||
- | could have like huge flying steam ships pulled by drakes and powered | ||
- | by Hellhounds to move their troups! The possibilities that this | ||
- | system would open up are pretty awesome. I can just imagine it now; | ||
- | the whole island of R'lyeh tethered to Cthulhu's back as he flies | ||
- | into combat against the collective forces of Aedaris, who wait on a | ||
- | fragment of the Exoma that has been shifted into the Prime and | ||
- | materially tethered to Puff. | ||
- | |||
- | == * flight <2014-01-21 Tue> :mechanics :revamp: == | ||
- | Our monolithic flight system is actually pretty nonsensical and | ||
- | should be separated out into different functionality. This thought | ||
- | came from another of Agun's complaints (about levitator not granting | ||
- | a boost to flight). The game currently uses one skill to govern all | ||
- | forms of flight. However different flight mechanisms require | ||
- | profficiency in completely different fields. For example, magically | ||
- | directed wingless flight doesn't require knowledge of wind drafts, | ||
- | how to rise with thermals, how to take advantage of slipstreams, | ||
- | etc. On the other hand, even though dragon flight is partially | ||
- | magical, they will use skills involved in muscle manipulation that a | ||
- | bezhuldaar has no need of. So, the flight skill should really be | ||
- | turned into several different skills that affect different forms of | ||
- | flight, or use a wider range of skills (I.E somatesthesia might | ||
- | control how well a faerie can flap hir wings; or willpower might | ||
- | affect a Bezhuldaar's ability to direct its levitory). | ||
- | |||
- | == * Arborlon descriptions <2014-01-21 Tue> :new :areas: == | ||
- | Previously I've been trying to make the room descriptions in the | ||
- | Arborlon revamp really descriptive. Too descriptive, I've decided | ||
- | after some thought and reading some articles on area | ||
- | creation. Instead of trying to be really flowery, room descriptions | ||
- | should have a single sentence for each sense. This should be enough | ||
- | to be fairly descriptive, and make the rooms accessible to | ||
- | blind/deaf/anosmic players. The room summaries should also have | ||
- | different values for different senses, so that you can for example | ||
- | explore while blind while still getting an idea of where you are from | ||
- | your hearing. A system of sensory acuity traits could be used here to | ||
- | determine how much information each sense would contribute. For | ||
- | example, a player with low hearing acuity might be able to only get | ||
- | the auditory room summery but not the auditory description elements; | ||
- | or be able to see the latter but not see the auditory elements of the | ||
- | individual element's description. The idea is to make Arborlon's | ||
- | descriptions offer complex multi-sensory descriptions, rather than | ||
- | just really flowery visual ones which nobody will appreciate while | ||
- | slaughtering everything with brief depiction on anyway. | ||
- | |||
- | == * room generation simplification :new :utility: == | ||
- | Write a python script to make writing rooms less tedious. Currently | ||
- | the bulk of room code is the really lengthy map feature function | ||
- | names and the abstract item nested descriptor structure. Instead of | ||
- | dealing with all that, the room generation script should ask for | ||
- | abstract item identities, long descriptions, summaries, day/night, | ||
- | and flags for the different senses, in a dialogue format. After | ||
- | everything is entered, the script generates the room code with | ||
- | correct descriptor nesting and indentation (because indenting | ||
- | descriptors past the second level becomes a big hassle to deal | ||
- | with). I should probably write this script before I get back to | ||
- | Arborlon, to make it less dull and tedious to work on (the idea here | ||
- | is to focus on the content when creating an area, rather than the | ||
- | code itself). |