Skip to content
Find file
Fetching contributors…
Cannot retrieve contributors at this time
516 lines (492 sloc) 27.9 KB




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.

growing up
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

Re-evaluate copy

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

Override ‘Enter’?

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


Scene editing

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).

Websocket client

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.

Parser, JS-side

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.

Action completion

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.

(re)design client

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.

Scene headers

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.


When you leave the chat page, the websocket is disconnected. If you press ‘back’, though, the input fields are enabled, as if the websocket connection were still up. Perhaps there’s a javascripty way to reconnect the websocket on back-button? Maybe this could be achieved with disabled=true by default for chat inputs?

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.

Character conversion

Convert – to —.

Do something about the awful OOC area.

Scene recording

Select area to record

Scene naming

Add ability to change the name of the recorded session. NOTE: Perhaps more important than this – descriptions? I’ll do this later.


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

Email system

cl-smtp should be good enough, but it requires a mail server to already be running.

Form builder

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

This one might get a little tricky… but various builder screens will have a similar interface, so it’s important to figure this one out. Eh. It’s probably easy enough. For features, may need a bit of javascript to force the AJAX requests for adjectives.

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

(later) Scenes
(later) view-scene

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.

JS/CSS includes

shouldn’t these just go in templates, instead of requiring the programmer to pass them in?

Automatic form->fields

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-

Test it!

Character encoding

wtf hunchentoot y u iso-8859-1?

Logging system

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.

Fix 404

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”

Memory-cache vocabulary

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!

Fix timer

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

subterfuge system

Limit dialogue/action interactions to same location

Location transitions

Changing locations should have a couple of effects:

Scene transition.

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.

Location building.

Write an interface that can be used to easily build and connect locations.

Persistent scenes

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.

Scene collection

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 ( system for dealing with AI entities.

Game Building

Component manager

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.

Description component

Deal with articles
optional 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
definite articles

It’s not ‘a sky’, it’s ‘the sky’

article exceptions

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?

adjective/feature ordering

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.

legal characters

alphabetic characters, spaces, apostrophes, dashes, and periods should be the only characters allowed in nouns, adjectives, and nicknames.

Base noun

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.

Adjective/feature limits

Only two adjectives/features can be present (2 adjs, 0 features; 1 feature, 1 adj; etc)

base-description preview

The editor should show a preview of what the base-description will be.

Feature creator

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

Vocabulary manager

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.

Room builder

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.

Newchar configurator

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.

Security Has a nice overview of security concerns and mitigations.

Password hashing

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

Secure cookies

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, 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.

Security logging (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’

def-file-package improvements

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.

Entity GC

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 output

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.

complex verbs

“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

Scene headers


Add a scene-header protocol thing for requesting and receiving information required to render a location’s header image and description.

Render it

Make it render right.

New character creation

Organize all the form fields into various pages

Add flavor text to each page design

Implement character creation

Jump to Line
Something went wrong with that request. Please try again.