Difference between revisions of "Writing Submissions"

From The Repurposing Center Game Wiki
Jump to navigation Jump to search
Line 16: Line 16:
  
 
== Specific Description Calls ==
 
== Specific Description Calls ==
 +
//
 +
 +
== Test ==
 
//
 
//

Revision as of 12:27, 3 October 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. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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).
  8. 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!

Basic Coding Syntax

//

Specific Description Calls

//

Test

//