Manual for creating
random events
What are random events?
Each activity in the game can have an additional list of random events that might happen after
player finishes the activity. For example – if player goes for a run in the park, he might randomly
encounter sexy female runner and start talking with her. Or if he masturbates in his room, he
might be interrupted by Daphne or Alexa. These are all random events.
Additionally, locations themselves can also have random events, that might trigger when player
enters this location. But this type of random events shouldn’t be used often, because it might be
annoying for the player that when he enters a location to do something, he is interrupted by
unwanted random event. Or he might be trying to force the event by going in and out of location
couple times. Location events should be reserved for events that have additional conditions that
are rarely met, or one-off events, like quest triggers.
Event formatting
List of events
Because there can be multiple events on one list of events, we need a structure of tags to
maintain order on the list. It looks like this:
• <<events>> - this tag is the start of the list of events
• <<event>> - this tag starts each event on the list. The event doesn’t have an end tag – it
ends when another event starts or the list reaches the end.
• /* ============ */ - this long series of equal signs separates events. It’s there to
make it easier to scroll a long list of events.
• <</events>> - this is the end of the list of events
Chunks
Each event is separated into chunks. These are basically parts of the event that are displayed one
at a time. When player clicks a button at the end of chunk, the currently displayed chunk gets
greyed out, and a new chunk is loaded at the bottom.
• <<event>> - start of the event
• <<chunks>> - marks beginning of the content for this event, and also starts a first chunk
of the event
• <<chunk>> - start of another chunk
• <</chunks>> - this marks the end of chunks for this event
An example event looks like this:
When player displays this event he will see only the first chunk:
And after the player will click the button, first chunk will get grayed out, and the second chunk will
load on the bottom. And this behaviour is repeated until the end of event is reached.
Formatting the content
The content of each chunk is a mix of HTML and some custom tags.
Text formatting
These are the most often used text tags in Become Alpha.
• <big>….</big> - this is a header text, used for emphasizing something important, or for
narrator snappy comments towards the player.
• <p>…</p> - this is a normal text for narrator.
• <small>….</small> - this is a header text, used for emphasizing something important, or
for narrator snappy comments towards the player.
• ’’…’’ – the text between double apostrophes will be bold.
• //…// - the text between double slashes will display as italic.
Character name formatting
Because names of characters are editable, you cannot just write the character name in the text.
Instead – use a name variable of this particular character. To do this – start with “$” which marks the
variable. Than write an ID of the character (for example Daphne has an ID “daphne”, so even if player
changes the name of Daphne to Mary, the ID still remains “daphne”). Finally, add “.name” to define
you want to load the name of this character. So for Daphne the name variable is “$daphne.name”.
Example:
And even if the player changes Daphne’s name to Mary, it would still work:
Media formatting
The game can display JPG, PNG and MP4 files. The max file size for MP4 is around 2mb, but I
strongly recommend not using files bigger than 1mb. In case of JPG or PNG files – it should be not
more than 50kb.
The game can also display GIFs, but please don’t use them as the filesizes are way too big. Instead
convert GIF to MP4 using: https://ezgif.com/gif-to-mp4 . I can also provide you with a script that can
mass convert multiple GIFs to MP4.
To display the image/video you need a <<media “…”>> tag. You just need to provide a path (the
default path is the “media” folder, so if you put your file there, all you need is write its name). It
looks like this:
Dialog formatting
Dialog formatting is pretty straight forward – you just need to provide an id of the character, and the
dialog that you want this character to say. The game will automatically load avatar of the character
and differentiate dialog color to show whether it’s the player talking, or other character.
Example dialog looks like this: <<dial “daphne” “Hi! What’s up?!”>>
You need to provide:
• ID of the character speaking (eg. “player” or “alexa”)
• Dialog that the character says. If the dialog will be wrapped with <tht>…</tht> it will be
formatted as the inner thoughts of the player.
Example:
Buttons formatting
Basic button usage
Buttons are very important elements of the game, as they move the story forward, set yields that
player gets, have a lot of custom conditions, and many other features.
A basic button’s code looks like this:
And it renders to this:
Clicking this button will automatically move player to the next chunk, or, if there’s no next chunk,
it will end the event and move player back to the location.
If there’s a need for changing the text on the button, it’s easily done like that:
If you want to make a button that after clicking will give player some yields, it should be added
like on the examples below. The first example will give player (and only player) 2 points of
domination experience (before going through multiplier). Second example has a name of
character added, so it will give player 2 love experience and also 2 points of desire to Daphne
(before going through multipliers for both player and character).
More information on how to use buttons in the Advanced button usage section of the manual.
Menu
When you have more than one button next to each other, it’s good to add a nice menu label there
too. You do that by writing <<menu>>, like that:
Advanced button usage
The buttons have a lot of additional features, that I’ll try to describe in this section. Basically,
there are 4 fields that serve different purpose:
<<btn $curLoc “End this event” “dom+3; cash=50” “action”>>
Those 4 fields are:
• A link, where the buttons should lead to. Possible settings:
o null – it will lead to the next chunk, or (if it’s the last chunk) it will end the event
and lead to the current location.
o $curLoc – it will end the event and lead to the current location.
o $curLocParent – it will end the event and lead to a parent of the current location
(this is used to situations, in which player for example was searching a room of
other character, and he got caught and was thrown out. In this case – he should
be moved to a parent of current location).
o Name of the passage (in quotes – eg. “park”) – if you write down the name of the
passage as a link, it will take the player there.
o Label of a chunk (in quotes and with # – eg. “#sex”) – more on the labels in the
section that refers to using buttons with chunks.
• Text on the button – this can be whatever you want. If you leave it empty or put “null” it
will display “Next”.
• Yields – in this field you need to provide yields that player gets after clicking this button. If
you want more than one, separate them with semicolon. Possible settings (the numbers
are just examples):
o dom+1 – player gets 1 domination experience
o daphne.love+2 – player gets 2 love experience, and Daphne gets equivalent of it
in desire.
o alexa.dom-1 – player loses 1 domination experience, and Alexa loses equivalent
of it in desire.
o time+2 – two periods pass after clicking this button.
o cash+50 – player gets 50 bucks after clicking this button.
o high+ - player gets an effect “Reefer madness” which ID is “high”
o weed+ - player gets an item “Weed” which ID is “weed”
• Conditions - what requirements have to be met for this button to display (depending on
condition, if it’s not met, the button might not display at all, or display as disabled). You
provide the requirements in the same field as yields, separating each with semicolon. The
main difference between yields and conditions is that yields have “+” or “-”, and
conditions usually have “=” (but there’s couple exceptions). Below I will write down some
simple examples, but the topic of conditions is huge and it touches couple different
elements, so I will expand it further in a separate section of this tutorial.
o null – no yields and no conditions (only one “null” for both yields and conditions).
o cash=50 – player needs to have 50 bucks for this button to display.
o player.lvl=3 – player total level needs to be 3 or more.
o period=Morning – the period needs to be Morning.
o daphne.status=3 – status of friendship between Daphne and player needs to be
at least 3.
o daphne – writing just an id of the character means that this button will display if
this character is present in the location.
o $daphne.met – it will display the button if the player has met Daphne in the game
(remember about “$” in front, because in this case we’re checking an actual in-
game variable).
• Classes – classes help format the button design in a specific way. Some simple examples:
Every field from the ones described above is optional, but remember that the fields are recognized
only by their order, so if you decide you don’t want to provide any link, but want to provide a text,
you need to write “null” instead of the link. Similarly with any other field. But if you don’t want to
provide neither of the fields, you don’t have to write anything at all (even “null”).
Some more complicated examples:
Branches
What are branches?
Imagine an event where player is on the crossroads. He has two routes to choose between, one
that leads him left, and one that leads him right. He cannot go both ways, so it means he has to
choose. These split in the storyline creates branches.
Starting branch
Starting branch is created the moment when you add <<chunks>> to your event. If the button
add the end of the chunk has no link, it will automatically continue current branch to the next
<<chunk>>, unless there’s no new chunk it can take the player to, in which case – it will end the
event and revert back to the location.
Using buttons with chunks for branching storylines
Chunks and buttons can work together to move player between branches. It’s done by adding
labels to chunks, and then using those labels as links for buttons. Labels in chunks looks like this:
<<chunk null “#something”>>
<<chunk null “#something_else”>>
And links in buttons look like that:
<<btn “#something”>>
<<btn “#something_else”>>
Live example of the above would look like this:
And it will render into this:
The above is #starting_branch. The button in that branch has no link, so clicking it will
automatically continue current branch to the next chunk:
The above is a continuation of #starting_branch. However you can see there are two buttons
there, one with no link, and the other with a link to the #new_branch. Clicking the first one will
end the event, as the #starting_branch has no more chunks in it. Clicking the second one will
redirect player to the new branch.
The above is a #new_branch. The button in it also has no link, so it will continue to the next chunk
(which automatically becomes a continuation of the new branch).
Finally we reach the last chunk of #new_branch. The button here has no link, and nowhere to go,
so it will end the event.
Advanced conditions
Using conditions for different game tags
Conditions, which were already partially described in Advanced button usage, are deeply rooted in
the game engine, and can be used to define whether to display many different game tags. It’s
important however to know where to include them. Here’s couple examples:
<<btn null null “player.lvl=3”>> - in buttons condition takes 3rd spot in the list of fields.
<<chunk “player.lvl=3”>> - in chunk tag condition take 1st spot in the list of fields.
<<event “player.lvl=3”>> - in event tag conditions take 1st spot in the list of fields.
<<wrapper “player.lvl=3”>> - in wrapper tag conditions take 1st spot in the list of fields.
Using wrapper to define the content to display
Sometimes you want a part of the chunk to display depending on some condition. For example – you
want a different player dialog if he’s a Meager Beta, compared to when he’s The Alpha. You can do
that using <<wrapper>>, like that:
Which will render into this (if player is below level 3):
Or this (if he’s above level 3):
You can use more complicated version of <<wrapper>> by adding second statement <<wrapelse>>.
What it does it will display something else, if the first condition check fails. Like that:
Or you can make it even more complicated, and add another condition to <<wrapelse>>, and even
combine it with another <<wrapelse>> to make things fun:
Or if you’re a dev and don’t want to waste your time in my custom tags, you can simply use <<if>>
and everything else that way smarter people that created Twine/Sugarcube prepared for you, read
more about it here: https://www.motoslave.net/sugarcube/2/docs/#macros-control
Negative condition
You can also add “!” to the condition statement, if you actually want condition to NOT be true. Like
that (notice the “!” in front of the condition):
Using conditions for events and chunks
Using conditions you can make the event appear only over the weekend, or only on Mondays, or
appear only if a particular character is in location. Example:
The above event will only start during dayhours and for players who turned on gay content.
You can do the same for chunks, but remember that if the conditions for the chunk are not met, it
will simply not render at all, and it might create some problems in the flow of the story (it’s usually
better to direct player to a separate branch using buttons, or use wrapper to display slightly
altered content within a chunk).
List of possible conditions to use
This is a list of some conditions that I often use:
• player.lvl=XXX - this condition check how experienced the player is. Possible
settings are: 0 (new player), 1, 2, 3, 4, or 5 (alpha)
• daphne - you basically just write an id of the character that needs to be present in
the location, for the condition to be true.
• $daphne.met – checks whether player knows a character (just replace daphne
with any character ID).
• daphne.status=XXX - this condition checks if the relation between player and a
particular character is at a required level. Possible settings are: 0 (player did not
met the character), 1, 2, 3 (this usually means character would consider sex, but
unlikely to go for it), 4, 5 (character is in love with player).
• period=XXX - this condition checks if the current period is what you want it to be.
Possible settings are: Morning, Late morning, Noon, Afternoon, Sunset, Evening,
Night, dayhours (any period before the sunset), nighthours (any period during or
after the sunset).
• day=XXX - this condition checks if the current day is what you want it to be.
Possible settings are: Monday, Tuesday, Wednesday, Thursday, Friday, Saturday,
Sunday, workdays (Monday to Tuesday), weekend (Saturday or Sunday).
Additionally you can also set it to a number of the current day in game, like day
135.
• $gayContent=1 - checks if the player has a gay content turned on (required for
any gay event). Possible settings 0 or 1.
• $transContent=1 - checks if the player has a trans content turned on (required for
any trans event). Possible settings 0 or 1.
• $pissContent=1 - checks if the player has a piss content turned on (required for
any piss event). Possible settings 0 or 1.
• cash=XXX – player needs a specified amount of cash.
• quest:XXX=DONE – it’s true if the specified quest was finished by the player
(replace XXX with quest ID). Other possible settings are 0 (checks whether the
quest is not started yet) or the number of task within the quest (for example
quest:daphneIntro=3 would check whether daphneIntro quest is at task 3).
