To avoid overlooking details, I think that this would be a good time to lay out the design for a prototype. This will assume a text-based user interface for now (I've already got a library for it) and will make sure that the framework for the game works properly with other core elements, as well as providing some reason to think that more complicated design elements will work as planned.
This is an excerpt from a larger document, so some of the formatting may not appear correct. Other formatting is likely actually incorrect. I've tried to keep this entry self contained, but there may be phrases or formatting which relies on standards set in the whole design document. Two items that I noticed:
-"Investigator" refers to any character who actively tries to identify major characters and/or solve crimes. Each major character in the game is an Investigator, and there will always be at least one Investigator NPC working for the police.
-"Empowered" refers to a character in the game who has gained access to a supernatural ability. All Empowered characters are automatically Investigators.
I am very interested in any feedback that anyone has. Specifically I'd like to know where my design, documentation, or any other "practical" deficiencies in planning are. This includes awkward systems, unclear writing, overly-ambitions designs, and anything else you may notice. But I'm also interested in observations about gameplay mechanics or anything else as well.
Prototyping considerations:
The key entities that need to be created to establish a functional prototype are as follows:
-Characters
-Locations
-Calendar/Schedule
-At least one power
-Ability system
-Investigation Notebook
-Items
-AI
Even this is beyond what I think I can plan well, so I'll be focusing on a few of these elements to sketch out a bare-bones prototype. They are marked below with a (1).
2.1: Characters (1)
Characters need to have names, locations, core stats, and inventories. Each Action that can occur between characters must be defined. Characters will be in one location per time period, and can move only between time periods.
2.2: Locations (1)
-Locations need to contain a list of characters in each, as well as functionality for searching through and modifying these lists. They will need a similar list for items.
2.3: Calendar/Schedule (1)
The calendar needs to contain dates, a week's worth should be enough for the initial prototype. Each date will contain its own Schedule, which is a list of that day's time periods. Each Schedule should aggregate scheduled activities of each major Character. The schedule will iterate through time periods, resolving the activities contained in each. Once the final time period is processed and resolved, the calendar will advance one day. Schedules should be generated immediately after the Calendar is advanced to the next day.
2.4: At least one power (2)
This will be important in a later iteration, but is not strictly necessary for establishing the more rudimentary elements needed for the prototype. Setting up the Calendar and Schedule and having them interact correctly with Characters and Locations is a more fundamental concern at this time.
2.5: Action system (1)
All of the actions that a character can take will need to be defined, perhaps as an enum, but more likely as a distinct class. The rationale for this is that while an enum can be used to denote a type of action, or a modification to an action, additional information will be needed to fit the action into the overall ability system. This could be managed on-demand by an action parser or something similar, but it might be smoother and easier to have each action supply possible combinations. Certainly each Action should contain information regarding what types of objects can be associated with it.
So an Action will need to contain an enum indicating its type, but also should hold information like what sort of objects it can be used on, what statistics are involved, and so on.
When the user selects "Action" from the menu, a list of possible Actions appears. When the user selects one of these actions, the chosen Action appears at the beginning of a line, followed by several blanks, braces, or other marking showing how many modifiers can be attached to it. When multiple forms are possible, one should be displayed by default. I'm not sure whether this should be the simplest, most "natural", or the most complex action. This list, the Action and its permitted modifications taken together, is the "action-phrase", which determines the specific manner in which an action will resolve.
Most actions may have a direct object (what object the action will operate upon). Some may have an indirect object (to whom or what the action will be done). Actions may also have an adverb (how the action is to be done). Some may have a preposition (where the action will resolve). Some actions may have a duration. The player does not necessarily need to fill all blanks, and actions will be slightly different depending on whether or not some blanks are filled.
For example, if the player selects "Action"->"Drop", the screen will display {Drop}, with a blank immediately to the right. The player will select from a menu (dropdown? subwindow? list of options?) what will be dropped. From the definition of the Drop action, the only things which can be dropped are items currently equipped or in the player's inventory. So the list of options for the second blank will be populated only with such items.
After choosing which item to drop, the player can execute the action to drop the item wherever he happens to be, or can go on filling blanks. The next blank is either an indirect object or a preposition--the player can select another character (placing the item into her inventory) or a place (some objects can fill this list, like tables perhaps? Any object with its own inventory capacity should be fine).The final blank is an adverb, and the player can execute the action discreetly, casually, or obviously. The action then executes according to the options that the player has selected.
Default actions (less than all blanks filled) will need to all be defined, as well as all valid combinations of options. This should be manageable by selecting each action in turn, and deciding what modifications will be permissible.
For action-phrases which involve items, the items themselves may have restrictions on how they can be used. Even if a given action-phrase form would normally allow a duration to indicate how long the action can persist, if an item is listed as the direct object and that item does not allow a duration then the duration blank will not appear.
One possible interface element that might help this system would be to display a sentence which describes the Action-phrase in a more conversational way. So, {Drop} {pencil} might display "Drop pencil where you are", while {Drop} {pencil} {Ronald} {obvious} might parse out to "Give pencil to Ronald", and {Drop} {coin} {Ronald} {discreet} might parse as "Slip coin into Ronald's pocket". I'd like to avoid having players remember arbitrary combinations of words to execute actions, but such a parser might be more complicated or slow to write than I'm currently envisioning. This is probably a secondary issue, to be addressed after the prototype is working. I can remember arbitrary combinations for now.
2.6: Observations (2)
Observations should be very similar to the action-phrases detailed in 2.5; indeed, they should be roughly the same with an "observer" clause tacked on.
If the actor observed executes an action like {Take} {wallet} {table}, that would indicate that the actor took a wallet from a/the table. The observer record should then be {Observer} {[mode of witnessing]} {[actor observed]} {take} {wallet} {table} {succeeded}. This carries the same information as the action-phrase, but has a couple of significant additions:
The observer is listed, which is an important factor in logging the observation in an investigation notebook.
The "mode of witnessing" section describes how the observer made her observation. This can include seeing, hearing, feeling, etc., but can also include things like having heard a rumor.
The actor observed segment is self-explanatory, though it should be noted that it can include the actual identity of the character observed or a description of the character observed, depending on whether or not the observer knows the character.
The action-phrase segments are the same as in the system laid out in 2.5, it carries the same information that is used to resolve the action. In the event that an observer cannot fully perceive or understand an action, these can include placeholders, such as {Take} {something} {table}, and so on.
The final segment carries information regarding the outcome of the action being observed once resolved, presuming that the observer was able to perceive and understand the result. Success indicates the action was resolved successfully, failed indicates failure, and unknown indicates that the observer does not know.
The quality and granularity of observation depends on various statistics of the observer rolled against corresponding statistics of the character being observed. Most events will not be recorded by any character; indeed, only characters above a certain Importance threshold will take actions that can be observed at all. Of these, few may be conspicuous enough to garner the notice of a random character.
Any observation made that a character will "remember" will be logged to a master dictionary made up of a composite data type which will store the observer(s), date, time, and location as well as the observation itself. As long as the character remembers the action, its entry in the master dictionary will persist and the player can gather the information by successfully interacting with that character.
2.7: Investigation Notebook (2)
The investigation notebook is a record of observations made by characters as reported to an Investigator. Each Empowered character will have a notebook, as will the police Investigator. Additional Investigators, should any arise during the game, will also gain investigation notebooks.
The notebook includes an automatic record of things that the character observes directly. If, while observing the park, the Investigator sees another character doing something that arouses suspicion, a note of that will be entered into the notebook to the maximum precision that the Investigator can observe. This will be stored as described in section 2.6.
The record of distinct observations will be comprehensive of all observed events by default, though the player can remove entries manually and possibly set up rules by which some observations will be discarded. This will be nailed down when the implementation for the Investigation system is undertaken.
The record will be sort-able on demand, allowing the player to quickly sort observations by date, observer, action, or any other segment which can make up an observation listing.
The player will also be able to designate certain items to be added to short-lists, sets of potentially related observations that the player currently finds relevant or important to follow up on. This is just another list, but a much smaller and player-determined one so that the player has access to information of interest at-a-glance.
2.8: Items (1)
Items refer to objects that characters and certain other objects can contain. There are different types of items, but all items will have a name, a description, a weight(?), and a size. Other items will have stat modifiers (i.e. Perception +2), lists of objects they can be used on (i.e. characters, equipment, etc.), and possibly other considerations. Some items have an inherent inventory capacity, which is added to the player when the item is worn and serves as excess storage when not.
2.9: AI (3)
AI will govern behaviors for NPCs. This will obviously be a rich and complex section, but it is well beyond primary and secondary planning considerations. Many other components of the game will need to be up and running before AI can be meaningfully planned and implemented.
Now, on to my more task-oriented list for producing a prototype of the primary elements only.
3.1: Characters will need to be defined as outlined in the full design document. They will require:
-Names
-Genders
-Locations (field, requires Locations to be defined)
-Personal schedule (requires Schedule to be defined)
-Core statistics
-Inventory (requires equipment Items to be defined)
-Function updating location (requires Location to be defined)
-Functions for updating personal Schedule (requires Schedule to be defined)
-Functions for constructing action-phrases (requires Action to be defined)
Additional character data can be filled in as the prototype is expanded.
3.2: Locations will need to be defined with a name, description, a list of characters presently within them, and a list of items within them.
-Name
-Description
-List of characters (requires Characters to be defined)
-List of items present (requires Items to be defined)
-Functions updating list of characters
-Functions updating list of items
3.3: Schedules will need to be defined as a container of times, locations, and activities.
-Name (day of the week)
-Date (requires Calendar to be defined)
-Time segments (blocks)
-Location (field, requires Location to be defined)
-Activity (field, requires Action to be defined)
-Functions updating time, advancing to the next block (needs to signal a function in Calendar, to trigger all updates for characters whose Schedules are being checked. Requires Calendar to be defined)
3.4: Calendar will need to be defined as a series of days (Schedules, which will be empty when generated and then filled in)
-Container of dates (day of month, month of year) and Schedules (requires Schedule to be defined)
-Current time (hour and minute)
3.5: Actions will need to be defined, and each action will need to list what forms it can support when extending the action-phrase. The Actions to define are: Go, Talk, Item (Use, Give, Drop), Use, Take, Attack, Observe, Examine, Search, Ability.
-List of allowable forms (i.e. direct object->adverb; direct object->indirect object; direct object->indirect object->adverb; etc.)
-List of object types that can fill each segment of an action-phrase (requires each object type so used to be defined)
-Class definitions for each action will need to be written, inheriting from a base Action class
-A parser or manager will also need to be written to handle action-phrases
3.6: Items will need to be defined, at least for a small set of objects. These are not now "functional" items, in that they cannot be used. They can, however, be picked up, dropped, given, observed, and examined.
-Name
-Description
-Size
That's what I've got for the prototype so far. Clearly there's more work to do before moving on to making the prototype itself: some of the Actions are redundant or awkward, their combinations still need to be laid out, and some major game elements are still on the backburner. I think that a couple of diagrams might also be useful. But I'm hoping that this is an OK start.
Does anyone have any observations, advice, questions, complaints, or anything like that? I look forward to hearing them.
The first couple of times I did this resulted in a lot of refinement to the core game idea.
Well hope sharing my experience with game design documents can help you.