Bring the whole interface back to baseline
Redesign the newchar procedure
Fuck this big long form. Make it an experience, over various pages.
Create handlers for character creation
Each one must validate its parameters, report errors, display everything necessary. After those are done, start working on database persistence. Note: The basics are laid out. Just need to hook it up to forms now.
Dynamically update ‘Character age: ’
Hide careers again
I seem to have broken it somehow :<
friends and romance
name and confirmation
update /newchar to point to /newchar/pronoun
Form state and entity creation
The state of the form should persist, associated with the web session, until the web session ends (if associated with the session instead of the account, we can allow character creation pre-account-creation). Form fields in each of the creation pages should be pre-populated with the stored values. When ‘Create this character’ is clicked, all the form state should be cleared from the session, and an entity with the appropriate component rows should be created. If the current session has an account already, we’ll toss someone to /role. Otherwise… do we toss them at /signup, or do we let them play for a while without having an account? Just /signup for now.
Use the pronoun information from /newchar/pronoun to inform the other creation forms about how to render, instead of using slashes everywhere.
Allow backwards navigation, as well
Add a breadcrumb system
Make it pretty
Drop it on someone’s lap to make the styling not suck balls
The copy feels a bit like a Wall of Text. If the restyling did not help enough, adjust the copy so it’s more concise and actually encourages people to read it.
Oh goodness, what a mess. Please tidy up, if appropriate.
Disable ‘add’ buttons when appropriate
Chee suggested that ‘enter’ take you to the next field, instead of the usual tab-based behavior. Maybe this is better solved by having users confirm? I’m afraid of breaking user expectations about web forms (where pressing enter does, in fact, submit the form).
Need to have this page to manage account information.
Allow changing of display name.
Allow changing passwords.
More involved user bio?
Set up an email-based password recovery system
I like the idea of rendering each ‘sentence’/unit as a targetable DOM element (such as SPANs for sentences in a paragraph), and using jQuery UI to make those units individually draggable. I don’t think I want to allow full editing of scenes (might feel like it defeats the purpose of -playing- the scenes if you can just -write- them), but this might be a really neat feature that allows cleaning up garbage without giving too much freedom (or requiring too much effort to handle formatting, and the like).
opaque method of communicating object ids with client
Don’t leak the internal IDs of objects. Use an external UID or something like that.
Implement a click-menu for assigning and changing nicknames on objects
Stop leaking errors
Only parser errors should be reported through the websocket interface. Other errors should be logged. During dev, just allow them to signal.
See sketch on whiteboard.
Basically, the parser is less text-based and more text-guided. An interactive completion system will ensure that all items are uniquely chosen before the final message is even sent. This will probably involve caching of at least part of the game’s vocabulary client-side, but we’ll take that step when it’s necessary.
With the ‘full’ parser in place, revisit command completion and see if there’s a way to autocomplete large, complex sentences.
Add completion features to dialogue input area
(maybe) In the completion popup, group matches by verb and by adverb
Kinda like an <optgroup>. jquery-ui’s autocomplete supports this. NOTE: Maybe in the future. Whole-sentence is easier for now. :\
Semantic markup for game area
This should probably include changes to the command output functions such that they’re not simple string concatenations. Actual objects/ids should be passed around, which a command rendering engine will then take care of converting into tagged text. Perhaps all that is needed is an sexp/xml tagging system that will ‘mark up’ zones of the output text semantically.
- ’(:e 12345 John Doe) (:verb jumps) to (:e 4322 Jane).’
- ‘<e id=’12345’>John Doe</e> <verb>jumps</verb> to <e id=”4322”>Jane</e>.’
Probably just do the former for now, since it’s nicer to deal with, and handle the xml version later.
The UI is currently all sorts of awful. The currently-necessary components should be gathered, and decent designs should be agreed upon for all of it. Waifu recommends brainstorming sessions followed by user testing. Not sure how much user testing we can do, but even a little bit helps. Maybe pick something not-too-awful and then start doing honest user testing once we have a few early testers?
Give client.js a once-over.
Probably worth revisiting the way things are being ‘exported’ and the like. Some of the stuff in that file might be useful in other pages, as well. Perhaps it should actually be used as a shared library of sorts. Maybe also rename it to sykosomatic.js?
If the current entity’s name changes in the database, tell the client
A nice message through the websocket to update the client’s display.
Add a scene-header server->client message
Should include the url for an image to load and the name of the location.
Get client to render the scene header.
Make sure a user is chatting as a character only once.
No Flash on native-websocket browsers
Things got messed up when I tried to have optional loading of Flash. Give it another shot.
Sticky scene headers
Ideally, scene headers will ‘stick’ to the top of the screen when the entire screen belongs to a particular scene – always leaving clue of where the player currently is. As new scene headers appear, they should scroll up regularly, and ‘bump’ off the older sceneheader as they reach the top of the screen, sticking there until the next header rolls by.
Convert – to —.
Do something about the awful OOC area.
Select area to record
Add ability to change the name of the recorded session. NOTE: Perhaps more important than this – descriptions? I’ll do this later.
FUTURE WAI-ARIA support
The web client should play nice with screen readers.
FUTURE define a language-agnostic command definition protocol (a-la-couchdb)
FUTURE Client customization by users
Misc Webapp work
Chosen/jqueryui across site
For buttons, things with .button class, and selects.
Concurrent session/session history information
Since sessions last a long time, have a screen where a user can log out all other active sessions.
Log out all sessions on username or password change
cl-smtp should be good enough, but it requires a mail server to already be running.
Basic form builder
Need: string-param-binding support, simple definition form, validation support, raw and validated values, error string reporting, form-valid-p.
Test run form builder with signup
Convert validation in account.lisp
How do I deal with packages?
Should field values be package-dependent, or ignore packages altogether? They’re already bound in a package-independent way. Pomo doesn’t bother with packages, either. LOL JUST USE KEYWORDS DUH :D :D :D
Hook it up to handlers/signup.lisp
Update the signup template to use the form object
Repopulate based on form object raw-values
Display errors in-line with form fields
Initial form state
If the form hasn’t received any parameters, it should not display any errors.
Password confirmation needs access to password field
Test run form builder with newchar
list parameter type for deform
array parameter type for deform
Simply use the same method as hunchentoot to collect elements into an array. Let the validators do any integer parsing that we might want to do.
Figure out full repopulation
Use ‘real’ templates
Pull in html-template and give it a whirl
Convert home page to html-template
Include error display in page template
Convert remaining pages to html-template and hook them up to the handlers
Go through all the pages and make sure titles are in.
That should -really- just go in render-page, along with error-list stuff.
Abstract away error-list
All pages will want to render it. Having to remember :error-list (pop-error-list) shitsux.
shouldn’t these just go in templates, instead of requiring the programmer to pass them in?
Start thinking about wrapping form builder with rendering capabilities, so fields don’t have to manually be written up like they are now. Newchar was -awful-
wtf hunchentoot y u iso-8859-1?
Need to add a robust way to log server errors/notices/warnings in a more sysadmin-friendly way. Do this after the config system is in place so it’s easy to configure which log files to use.
404 stuff is currently uncommented due to dependency issues.
Figure out how to put the server behind stud
Figure out how to configure two lisp processes running behind HAProxy
Use a couple of lisps with single-threaded-taskmaster instances
Allow having a period at the end of action input.
Handle objective pronouns
Allow ‘me’ to resolve to actor
Allow chained possessives parsing.
NOTE: this needs game objects that can -have- possessives. Do it later.
Figure out exactly which characters will be allowed in vocabulary words and object names.
And put them in a shared place (sykosomatic.vocabulary?) that all other modules can use when parsing/validating.
present participle support for parenthetical
participle-form actions should be acceptable in dialogue parentheticals. This could probably support the entire action system.
Example: (laughing at X) You sure messed that up!
To support this, a participle column should be added to verbs to store the regular or irregular present participle forms of each verb.
When no participle is present, treat parenthetical as the verb “say”
Start with closed classes: Keep all pronouns and adverbs in-memory.
Figure out how much memory having all verbs and adverbs in-memory would take. If it seems reasonable, write them out to the database for storage, but work off the in-memory version.
That should help speed up the parser, hopefully.
Support compound verbs
“wave off”, “give up”, “give in”, “pick up” “X waves Y off” is possible, although “X waves off Y” is good enough. “pick up” is definitely desirable. “up” is just an adverb, though.
For more ideas on how to deal with these:
FUTURE Command overrides
Instead of putting command associations into verbs, make a command-association table that maps verbs to command names. This table should also include columns for most (if not all) of the action parameters. These can then be used to create ‘multimethods’ of sorts: By querying for specific parameters, default commands can be shadowed. For example, one could write a ‘method’ where a certain combination of actor/direct-object will yield a specific result. In general, this should not be used, but it may become handy when very-special-code is needed.
(maybe) Improve error reporting
For what it’s worth… this may be a waste of time, if all input has to be fully ‘completed’ once we have the full game frontend. If that’s the case, we can just ignore erroneous input because it means the player has bypassed the standard client.
Do something about that ENOPARSE garbage
When an adverb is wrong and a verb is write, report it as such
If someone enters ‘merrly jumps’, it should properly report the error as ‘merrly is not an adverb’, instead of ‘merrly is not a verb’.
Write defcommand social
This command, when attached to a verb, will simply reconstruct the sentence using the dynamic variable parameters for commands.
Write unit tests for defcommand social
…Somehow, but it’ll define the framework for testing other defcommands!
It’s not quite working right now, although there’s a reasonable rate limit. that might be okay for now.
New component that allows putting entities ‘in’ other entities
Cleaner es-thread shutdown
Don’t just murder the thread when we want to murder it. Get it to shut down cleanly.
Add concept of a ‘location’
Once characters exist, we can start adding the concept of a ‘location’ to the game. Locations should have a description, and should be able to ‘contain’ other characters. Characters can only interact with other characters provided they are in the same location.
Put characters in a location
Limit dialogue/action interactions to same location
Changing locations should have a couple of effects:
The actor who is moving from point A to point B should receive a short scene-transition message, which should be properly formatted as a transition.
Slug lines and descriptions
Upon entering the new area, the actor who moved should receive both a new slug line (displayed after the transition message), followed by the new location’s description.
Hi, I’m here!
Once the actor has transitioned into the new location, everyone, including the actor, should receive a “X arrives.” message. This’ll eventually be extended to provide fancier, nicer transitions, but an arrival message is good enough for now.
Write an interface that can be used to easily build and connect locations.
NOTE: This’ll need to be done after characters are implemented. Players should be able to ‘record’ scenes, which will be saved as they see them. These scenes should be viewable in a separate page (for phase 1). Would be nice to also have them formatted as screenplays. Not all user messages must (or should) be saved. Instead, create a ‘recorded session’ document, and then record each line of input that the character is witness to into ‘entry’ documents, which can then be collated with the recorded session as outlined in the CouchDB Joins article.
Revive persistent scenes
Haven’t been tested since pomo switch
Automatically add slug lines.
Even if the user starts recording a while after entering an area, the recorded scene should include the slug line for that area. Will probably have to wait until we have locations. :)
Automatically add location description under slug line.
May need to wait until locations are implemented (although no harm in having some default text for now). Under the slug line for persisted scenes, the description of the location, as seen by the character at that point in time, should be included at the top of the scene.
Users should be able to ‘collect’ others’ stories, much like in DA.
FUTURE “Canon” system.
While people can tell any story they want, how about giving extra weight to stories that fit the game’s canon, and/or are staff approved?
Build a behavior tree (http://aigamedev.com/open/article/behavior-trees-part1/) system for dealing with AI entities.
Parts of the game should be split into components (things like nameable, describable, weight/size, combat stats, contents, all being components). Components can be arbitrarily added/removed through a web interface, and each component should have a custom data editor for configuration. Components can be represented by block areas in a single entity editor screen. Or something like that. Should also have entity searching features. Sounds like a generic component registration system is needed that includes a particular API, built forms, etc.
Deal with articles
Not everything uses articles. You don’t say “a long hair” when referring to a lot of hair. What other kinds of objects would not have articles attached to them?ImplementTest it
It’s not ‘a sky’, it’s ‘the sky’
Since language doesn’t go by -spelling-, there are some corner cases where our basic ‘is it a vowel character?’ test won’t fly. For example: ‘an hourglass’, ‘a European’. These are probably quite rare – perhaps a simple dictionary that they can be looked up in separately?
Should be able to control what order adjectives and features are rendered in base-description.
Configure which adjectives can be in the base-description
Configure which features can be in the base-description
visible feature/adjective limits
Can only have two, counting both.
alphabetic characters, spaces, apostrophes, dashes, and periods should be the only characters allowed in nouns, adjectives, and nicknames.
Allowed characters: #', #., #-, #\,, A-Z, 0-9, #\space
This should be a ± list using the same validation as base nouns. Can only have one, or two.
This should be a ± list of entity IDs. We’ll deal with more user-friendly input later. Maximum of two allowed. Only existing entities can be set as features.
Only two adjectives/features can be present (2 adjs, 0 features; 1 feature, 1 adj; etc)
The editor should show a preview of what the base-description will be.
The feature field, when clicked, should pop up a window that allows you to create a new feature entity right there. Question: A window? What about recursively setting features in features, editing other aspects of the feature, etc?Figure out the desired workflow for object building
A manager for doing CRUD on vocabulary words, configuring what commands verbs are attached to (and possibly viewing the source code for the commands, or at least the documentation for them). The command system should also store the source code for the command, and a docstring, so it can be reviewed while selecting.
A dedicated entity editor meant for linking together various rooms, with a nicer view than just using the raw component manager. You should be able to do all that this screen can do with the component manager, though.
Set up a nice web interface that waifu can use to do basic CRUD on all the different character creation options, or at least configure the ones that exist.
Look into offering my pooling improvements to postmodern
Postmodern already has a pooled connection system. Look at it a little closer and figure out how it might benefit from my own pooling system (and/or if it’s worth using instead of my own pooling system).
Figure out a cleaner way of ‘passing through’ s-sql stuff
Nameable must-refresh-full-name constraint?
Is it possible to put in a constraint that prevents updates of nameable if a new full-name is not provided? Most likely, I’ll need to write a trigger that does this.
More database constraints/indices
Tune the database with FKs and indices.
https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines Has a nice overview of security concerns and mitigations.
Confirm that the current password hashing algorithm is as secure/more secure than the ‘standard’ bcrypt method.
The mozilla guidelines recommend storing the nonce elsewhere in the filesystem. Consider using couchdb to store nonces for user passwords.
x-frame-options to prevent malicious site framing. (see mozilla guidelines)
Content security policy
Since we’ll probably not be doing hunchentoot-level SSL, the session mechanism should be adjusted so that cookies are always secure (but this can’t happen until there’s a working TLS system in place, for development)
May not need/want hunchentoot managing this. Check out http://haproxy.1wt.eu/, which supposedly supports both https and wss.
There should be a specific method of handling all user input, and all redisplaying of server-side data such that XSS is not possible. This should be handled within the infrastructure.
De-XSS-ify server-side generated HTML.
This involves using yaclml’s <:ah
Nothing to defend against this right now. Most likely, the form builder should have something built-in that manages and checks tokens.
This is mostly taken care of by using s-sql. Keep an eye out, though. Looks like (:raw) is mostly protected as well, thanks to the whole (wrapping) thing. :D
Throttle user input.
Length and regularity of user input should be somewhat limited, so players can’t just spam a ton of garbage onto the screen.
Malicious websocket clients
The websocket client should not leak anything the player would not already be able to do through the interface. Object identities should be hidden somehow.
Expire/delete the session cookie upon logout.
https://wiki.mozilla.org/Security/Users_and_Logs (note that newlines should be escaped to prevent log forging)
src/game-objects -> src/components
That directory is more meant for ES components than just ‘game objects’
Ability to disable defaults for def-file-package
Is it possible to extract the package name from the -filename-?
Move persistent sessions out into a separate lisp project
Move timer.lisp into an external project
Merge smug.lisp changes into mainline smug and use that version instead
Actual config file system for local configs
As in, get config values reloaded on startup, instead of whatever their values were when the application was compiled/loaded.
Might be a bit of a pain, but it might be nice to be able to go through the database and clear out any entities that aren’t being used by anything. An offline is GC is more than good enough, and this can probably wait a long time, if it’s ever even necessary.
Thorough tests for accent folding
…are gonna have to wait until Eos gets fixed.
The generated.html Challenge™
The point of this challenge is to have enough of a working system to render the contents of generated.html AS IT LOOKS. That includes the scene header, highlighting objects, parentheticals, complex verbs, and proper styling. Additionally, all bold words should correspond to actual game objects that, when clicked, make a description request to the server (which does not need to return anything useful right now – the client just needs to be able to have enough semantic information about the object to ask the server about it).
All verbs can be purely social for now.
Can safely ignore the inputs area. Don’t worry about completion, better input fields, etc.
Bonus points: Have all objects reside in an actual location, although transitioning between locations is not necessary yet.
Bare-form verb input
Parse verbs in their bare form
Semantic markup from social command
Have social command output a marked-up string that annotates any words of interest in the sentence with their roles. For now mark the verb and individual objects.
Use semantic markup when rendering client-side
Instead of spitting out a markup-filled string, parse the action output and generate appropriate html markup with the right classes. No description links yet.
Add description onclicks
When you click a game object, the client should ask the server for that object’s description and render the description in a popup.
Update parenthetical parsing
There’s TODO items involving parsing parentheticals as special kinds of actions. Get those items wrapped up.
“sits down” must be supported. Whatever it takes.
Play around with using pronouns for multiple consecutive actions by the same actor.
Need support for ‘He munches on his pancakes’.
Make it look right
Update the stylesheets
Spacing between dialogues
Colors/emphasis for objects in actions
Colors/emphasis for stuff in parentheticals
Add a scene-header protocol thing for requesting and receiving information required to render a location’s header image and description.
Make it render right.