Contributing Content

Contributing to Accidental Woman
Contribution is welcome and encouraged! Right now, I don't have a system or process set up for this, but I do have a submission section set up on the forum. Accepting input from the community is a great way to help with development, particularly when it comes to adding content that players want, and making the game better.

Contribution Model:
Accidental Woman uses curated contribution, meaning that new content is submitted to be added to the game. This differs from a model of modding where contributors publish mods to be added to the base game. When the game is finished, I hope to have created an API that will allow players to create and load mods easily. During development, however, I believe that the curated approach works better. It improves the game for everyone, and helps focus development rather than splitting effort. Finally, the curated approach allows for a more unified and integrated game. A mod is generally forced to work within the confines of the base game, or alter the game from the outside. Under the curated model, submitted content is integrated into the game, and the design can accommodate the new material.

Modding?
As a long-time maker of game mods, I don't want to exclude modding. If anything, I'd like to encourage it! However, I have to focus on the core game before thinking about supporting any type of modding system or API. During development, it'd be great if I could include your work in the base game. (All contributors will have their names in the credits and UI bar.) Once the end of development is in sight, I'll re-evaluate adding more support for modding.

I have an idea...
While I certainly encourage new ideas and suggestions, it won't always be possible to implement them, or it may take a long time to do so. If you submit an idea for a car sex scene, for example, I might really like the idea but writing the content and implementing it would take a good deal of time away from other tasks. Other ideas may seem simple but actually be a lot of work thanks to how the game code is structured. Some ideas could seem complex but actually be quite easy to implement. Of course, if I really like an idea, I'll want to work on it sooner rather than later. I may think that an idea would be good to implement, but don't feel that it's worth working on just yet. If you really want to get content into the game, the best way to do so is to do the writing as well.

Doing the writing...
You don't need to be a programmer to contribute content! If you're writing an involved scene though, you do need to write it so that it works for the different character types. Once I get the descriptive parsers finished, I will publish a list of parser calls so that you can use them in your writing. An example of a call would be <<p tits.s>>. You could write your sentence: "he reaches up and squeezes your <<p tits.s>>". This automatically puts one of the possible descriptive words for the player's breast size, and one of several possible words for breasts, and will even throw in some description like being leaky or perky on occasion. (If you think you have a good candidate for a new parser call, let me know and I can add it.)

More detailed differences based on different variables will require some programming logic. You don't need to worry about syntax, but should write plain-language code that is understandable. You should change the color of plain text code to make it easier to read. An example would be "[If player has big boobs and no bra] they bounce ponderously with each step up the forest trail, making the hike more difficult. [Else If big boobs] they jiggle enticingly with each step up the forest trail, but the bra keeps them from slowing your progress. [Else] they jiggle happily with the exercise as you make your way up the forest trail [End If]"

Of course, if you're comfortable with programming and familiar with Twine Sugarcube, you can do your writing as code. If you write it entirely as code, please include appropriate comments so that I can understand your intentions when writing something. This way I can make sure the code will actually do what you're trying to do in the context of the game.

It's also very helpful if you include justifications for why something happens, particularly if your content alters the player character or potentially forces them into a certain course of action.

All content in the game will be from the player's perspective, and should be written in second person form. This means that the player should not read text describing something that the player character would not know. You can have a player secretly observe something, or have an NPC tell them, but never write something like "little did you know, in the next room $activeNPC.name was pouring aphrodisiac into your drink". You can read more about second person form online, but the general idea is that the words "you, your, you're" are used to describe the player character. In first person, the narrator is describing what happened to the narrator. In second person the narrator is describing what happened to you. The exception to second person in this game is when handling internal thoughts or dialogue, which is always in first person (and with a special css tag).

Generally, the writing should be in past or present tense, unless in the context of a hypothetical or internal thoughts. "You realize that you will have to pay your bills tomorrow."

In general, you should avoid putting character-defining thoughts into the player's head. Good: @@.mono;That reminds me... I have to pay the bills when I get home.@@ BAD: @@.mono;What I really need right now is a big stinky Cleveland Steamer.@@

Player dialogue should be formatted as: @@.pc;dialogue blah blah.@@ (this includes internal dialogue/thoughts!)

NPC dialogue should be formatted as: @@.npc;dialogue blah blah.@@

Writing Should:

Be proof read, without excessive typos or grammar and spelling errors.
Appropriately accommodate different player characters and NPCs. For example: don't assume all PCs have wide hips or enjoy anal, or don't assume all NPCs have giant cocks. (the parser calls will help with this)
Should provide alternatives for any gated or fetish content. For example, if you're writing a special NPC who suddenly unleashes a bunch of S&M or water-sports content, you should provide an obvious way for the player to opt out before the content happens. (I am open to including most fetishes/kinks, but do not want to force them on players!)
Provide information on game mechanics for a scene as appropriate. Examples are the amount of time that passes, how pleasurable or arousing an action is, if it makes the player stressed or sad, etc.
Writing should be submitted as a link to a Google Doc. This makes collaboration easier, and provides enough text editing features to make a clear and organized document.
Be submitted with a brief summary of the content at the top, as well as a summary of any new, unusual, or complex game mechanics.
Be organized so that it is obvious how the different parts of the text relate to each other.