Difference between revisions of "Writing Submissions"

From The Repurposing Center Game Wiki
Jump to navigation Jump to search
 
(6 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
# '''I reserve the right to reject submissions''' - Whether due to inconsistencies with the world-building, issues of writing quality, problems with the legality of the content involved, or any other reason, I will reserve the right to reject writing submissions. As such, I also suggest if you have any ideas for a writing submission that you send me a quick message over on Discord to make sure it's something that will be allowed into the game.
 
# '''I reserve the right to reject submissions''' - Whether due to inconsistencies with the world-building, issues of writing quality, problems with the legality of the content involved, or any other reason, I will reserve the right to reject writing submissions. As such, I also suggest if you have any ideas for a writing submission that you send me a quick message over on Discord to make sure it's something that will be allowed into the game.
 
# '''I reserve the right to retain the content after submission without dispute''' - Working to fit writing into the game is a big task between the editing and coding process, as such once writing is submitted removing it would be a difficult process that I would like to avoid outside of extreme circumstances (such as plagiarised material). It is also worth noting that I do make a profit from my gave development, therefore if you're not comfortable with that then please do not submit writing to me.
 
# '''I reserve the right to retain the content after submission without dispute''' - Working to fit writing into the game is a big task between the editing and coding process, as such once writing is submitted removing it would be a difficult process that I would like to avoid outside of extreme circumstances (such as plagiarised material). It is also worth noting that I do make a profit from my gave development, therefore if you're not comfortable with that then please do not submit writing to me.
 +
# '''I reserve the right to edit the content after submission without dispute''' - As with any project, editing is often necessary, either for readability purposes, or to maintain consistency within the project as a whole. Therefore, I reserve the right to edit content submitted to me.
 
# '''All writing submissions will be fully credited''' - When people do work for me I always want them to be rewarded for that, and that includes crediting the work they've done. As such, all submitted scenes will feature a note on who submitted them. This submission name does not need to be your real name, it can be your username, or some other pseudonym if the writer would prefer that.
 
# '''All writing submissions will be fully credited''' - When people do work for me I always want them to be rewarded for that, and that includes crediting the work they've done. As such, all submitted scenes will feature a note on who submitted them. This submission name does not need to be your real name, it can be your username, or some other pseudonym if the writer would prefer that.
 
# '''All characters featured within writing submissions should neither be copyrighted or a representation of a real person''' - This is a legal matter, but copyrighted characters or characters that represent real people are trouble, so I'll avoid submissions that include these. If the character is loosely 'based' on a real person, or is an author insert, then that would be okay, but generally I like to avoid any murky ground like this.
 
# '''All characters featured within writing submissions should neither be copyrighted or a representation of a real person''' - This is a legal matter, but copyrighted characters or characters that represent real people are trouble, so I'll avoid submissions that include these. If the character is loosely 'based' on a real person, or is an author insert, then that would be okay, but generally I like to avoid any murky ground like this.
Line 10: Line 11:
 
# '''I am willing to do minor coding additions to submissions but not major ones''' - Inevitably, there will be times when it is necessary for me to do coding work to make writing submissions work. I do not expect the people offering writing submissions to have coding experience, or understand the Twine/Sugarcube engine/format. However, where coding is necessary it is preferable for the coding to be minor (such as linking the scene up, exp additions, minor existing item gains, description calls, etc.) rather than major ones (such as creation of new items, new in-game transformations, mini-games, complex variables to control NPC's, etc.). I'm happy to get a scene functional, but would turn down scenes that require that excessive coding/editing workload.
 
# '''I am willing to do minor coding additions to submissions but not major ones''' - Inevitably, there will be times when it is necessary for me to do coding work to make writing submissions work. I do not expect the people offering writing submissions to have coding experience, or understand the Twine/Sugarcube engine/format. However, where coding is necessary it is preferable for the coding to be minor (such as linking the scene up, exp additions, minor existing item gains, description calls, etc.) rather than major ones (such as creation of new items, new in-game transformations, mini-games, complex variables to control NPC's, etc.). I'm happy to get a scene functional, but would turn down scenes that require that excessive coding/editing workload.
  
If all of that sounds reasonable to you, then good luck with your writing!
+
== Writing Advice ==
 +
While not necessarily mandatory rules that must be followed when writing content submissions for The Repurposing Center, below I'll be covering some basic advice in terms of how to do so. Whilst I would not insist on all the below being followed, I would at least recommend potential writers to quickly look at the points to get an idea on how to proceed. The advice is as follows:
 +
 
 +
# '''Submission formats''' - If possible I would prefer standard Word Documents, or Open Office Word Documents (so .doc or .docx files). I will still be willing to look at other formats, but the before mentioned formats are the best for me as they speed up my editing process.
 +
# '''Look at previous examples''' - As they say, don't reinvent the wheel. Often there will be examples of scenes similar to what you want to write already in the game, as such if you want to get an idea of how to write such a scene you can always look at how I've done it before. In the same way, if you want to write branching scenes, often parts of one branch can be used in the other, as there will be limits to just how far the scenes branch in one decision, so scene re-usability is a factor of the development process.
 +
# '''Try not to copy previous examples too closely''' - Imitation is the sincerest form of flattery, however, heavily copying existing scenes is unlikely to be a productive choice either. Whilst it is harder for me to spot, close copies of existing scenes (in terms of direct copying - not conceptually similar) will likely be sent back to the writer with the request to edit the scene further before it's ready to be added to the game.
  
 
== Basic Coding Syntax ==
 
== Basic Coding Syntax ==
Line 16: Line 22:
  
 
== Specific Description Calls ==
 
== Specific Description Calls ==
//
 
 
=== Test ===
 
 
//
 
//

Latest revision as of 12:33, 3 December 2022

If you're reading this, then perhaps you would like to make a writing submission for The Repurposing Center. Over the past few years I've had a few people offer to do so, so I've decided to both open a submission section over on the game's Discord server for people to send me their writing, along with offering a basic guide here regarding how to place some of the basic coding calls to make scenes fully functional. Before that though, I want to outline some writing submission rules that I will be implementing to make sure that there are no disputes, and so that game additions continue to be of a high and internally-consistent quality. As such, the basic rules I'll be accepting submissions under are:

  1. I reserve the right to reject submissions - Whether due to inconsistencies with the world-building, issues of writing quality, problems with the legality of the content involved, or any other reason, I will reserve the right to reject writing submissions. As such, I also suggest if you have any ideas for a writing submission that you send me a quick message over on Discord to make sure it's something that will be allowed into the game.
  2. I reserve the right to retain the content after submission without dispute - Working to fit writing into the game is a big task between the editing and coding process, as such once writing is submitted removing it would be a difficult process that I would like to avoid outside of extreme circumstances (such as plagiarised material). It is also worth noting that I do make a profit from my gave development, therefore if you're not comfortable with that then please do not submit writing to me.
  3. I reserve the right to edit the content after submission without dispute - As with any project, editing is often necessary, either for readability purposes, or to maintain consistency within the project as a whole. Therefore, I reserve the right to edit content submitted to me.
  4. All writing submissions will be fully credited - When people do work for me I always want them to be rewarded for that, and that includes crediting the work they've done. As such, all submitted scenes will feature a note on who submitted them. This submission name does not need to be your real name, it can be your username, or some other pseudonym if the writer would prefer that.
  5. All characters featured within writing submissions should neither be copyrighted or a representation of a real person - This is a legal matter, but copyrighted characters or characters that represent real people are trouble, so I'll avoid submissions that include these. If the character is loosely 'based' on a real person, or is an author insert, then that would be okay, but generally I like to avoid any murky ground like this.
  6. No gore - I've tried to avoid violence within the game as much as possible, but gore in particular would be an automatic no-go for submissions.
  7. No under-aged characters - Those perceptive among you might have noticed I don't have any under-aged characters in my game (and expressly move babies into a special separated nursery). Again, this is largely due to legal reasons, therefore all characters must be 18+ years of age within writing submissions.
  8. The writing must have a 2nd person point of view - The game's writing style is a 2nd person point of view, as such writing submissions must match that or have a very good reason why they are not (such as writing submissions for C.U.M Box shows).
  9. I am willing to do minor coding additions to submissions but not major ones - Inevitably, there will be times when it is necessary for me to do coding work to make writing submissions work. I do not expect the people offering writing submissions to have coding experience, or understand the Twine/Sugarcube engine/format. However, where coding is necessary it is preferable for the coding to be minor (such as linking the scene up, exp additions, minor existing item gains, description calls, etc.) rather than major ones (such as creation of new items, new in-game transformations, mini-games, complex variables to control NPC's, etc.). I'm happy to get a scene functional, but would turn down scenes that require that excessive coding/editing workload.

Writing Advice

While not necessarily mandatory rules that must be followed when writing content submissions for The Repurposing Center, below I'll be covering some basic advice in terms of how to do so. Whilst I would not insist on all the below being followed, I would at least recommend potential writers to quickly look at the points to get an idea on how to proceed. The advice is as follows:

  1. Submission formats - If possible I would prefer standard Word Documents, or Open Office Word Documents (so .doc or .docx files). I will still be willing to look at other formats, but the before mentioned formats are the best for me as they speed up my editing process.
  2. Look at previous examples - As they say, don't reinvent the wheel. Often there will be examples of scenes similar to what you want to write already in the game, as such if you want to get an idea of how to write such a scene you can always look at how I've done it before. In the same way, if you want to write branching scenes, often parts of one branch can be used in the other, as there will be limits to just how far the scenes branch in one decision, so scene re-usability is a factor of the development process.
  3. Try not to copy previous examples too closely - Imitation is the sincerest form of flattery, however, heavily copying existing scenes is unlikely to be a productive choice either. Whilst it is harder for me to spot, close copies of existing scenes (in terms of direct copying - not conceptually similar) will likely be sent back to the writer with the request to edit the scene further before it's ready to be added to the game.

Basic Coding Syntax

//

Specific Description Calls

//