Behind the Society: The Science of Conversation
It’s a set of files, named something like “.conv.txt”. The decides when the script is run. For example, the file “aunt.conv.txt” says what happens when you start a conversation with the “aunt”, one of the NPCs in the first act of our game. The file may look as simple as this:
aunt: Hello dear.
hero: Hello my dear auntie!
aunt: You're late.
Simple enough, right? If a line starts with “xxx:” then it’s just someone speaking. “xxx” can be the name of an NPC (it can also be empty to indicate this NPC, which is implicitly “aunt” within “aunt.conv.txt” file) or just “hero”.
A central part of the conversation is choices. They look like this: aunt: Go to Edward. -> Why are you so suspicious when it comes to the Vladinsky family? aunt: I'm not sure are they a good influence on our Susan. -> Can I talk with Susan? aunt: She's getting dressed. There's no time for chit-chat now. -> Bye then. aunt: See you soon. -> As you can see, each choice is just a line that starts with “->”. They all must have the same indentation (hi, Python lovers!) and they must end with an empty choice. This way you can have nested choices too. Note that the choices are (right now) always spoken by a hero and this is why, in the text above, we do not clarify who says, “Bye then”.
To enable simple loops within a conversation, one line may start with a label like “label start” and another line can then jump to it, like “go-label start”. This allows the creation of conversations where you can inquire with an NPC about something, like an investigation, and only exit the loop once you are satisfied (or you have exhausted all the options). The label mechanism does seem like the unpopular “goto” mechanism, abolished from most high-level programming languages, yet here it works perfectly. It’s simple (the conversation files are always short and jumps are only within a single conversation, of course) and flexible, as it allows jumps to different locations.
A game logic remembers the state of the storyline. Take for example, “Have you already spoken with aunt?”. This particular information (if you have already visited someone) is actually very often useful. All the conversations (and thus, all the NPCs and all locations) have an automatically remembered state of “visited”. It’s a simple boolean flag (it can be true or false). It is initially false and then automatically changes to true once you have spoken with someone. You use a variable in simple boolean expressions together with the “if” instruction: if not visited aunt: Finally! There you are! hero: Hello my dear auntie! aunt: You're late. endif aunt: Go to Edward. Here we use the automatic variable “visited”. Like in every good programming language, variables are placed in namespaces, with each conversation being a natural namespace. This means that another NPC can say different things depending on whether you have spoken with aunt: if not aunt.visited uncle: Your aunt is waiting for you in front of the church! else uncle: Go on, boy. endif Another automatic variable is “gate”. Some NPCs simply won’t let you through until you have done something. For instance, you cannot talk with Susan too early in the game, as you have seen in the above snippets. Once an NPC decides that you can pass, it can “change” the gate status doing “set gate false”. Finally, every conversation can have it’s own custom variables. This can be used to store any game state. For example, the aunt could have a variable like “is_angry”. You can declare such a variable within a conversation file and use it (read or write) from this or other conversations. For instance, a conversation with aunt could end badly for you: declare is_angry false aunt: Go to Edward. -> Right away! aunt: Attaboy! -> Come on, do I really have to? aunt: Yes, you insolent brat. aunt: I remember when you were young and… hero: OK, OK, I’m going… set is_angry true -> Now, another NPC or the aunt could use this flag: “if aunt.is_angry”. As you can see, all the variables must be declared and the declaration must specify their initial value. In this example, the aunt is initially not angry (but watch out, you insolent brat!) That said, it’s a secure and reliable programming language. Only special “automatic” variables, like “visited” or “gate”, do not need to be declared. Naturally, all the conversation variables are saved to the save-game. This allowed the save-game code to be quite simple: just write all the variables to the save-game.
The conversations can cause a variety of actions. They can teleport the player or an NPC. They can make some NPC or asset appear or disappear. They can play a particular animation. All of this is smartly saved to the save-game, so the game designer does not have to worry about these technical details when designing the game logic. All the scripts are automatically validated (they use existing variables, are connected to the actual data, etc.). This makes modifying these files safe and testing is easier when the computer automatically detects some of your mistakes. Right now the testing is done each time the game loads (it takes a fraction of a second now - less than 1/10 of a second), but it may be moved to our continuous delivery process (using Jenkins) later.
We have designed a conversation system once before, for our not-yet-released game, The Venice. It had some good ideas and we have borrowed some of them. But it was also not comfortable enough to write a large amount of logic… what we have now, The Unholy Conversations, is both simpler and more flexible to use. We have looked at other conversation systems as well. One in particular was from an excellent indie game, Night In The Woods, which is public and documented on https://github.com/thesecretlab/YarnSpinner/ . We have borrowed various ideas from it, e.g. that the “talk” lines should be simple to write, the “visited” state should be tracked automatically and the “if” and choices should be easy. The “Yarn” language was, in turn, inspired by Twine, a simple text format for telling non-linear stories with choices. Twine is also renowned for its simple-to-use graphic editor for stories, although we quickly decided that a graphic editor was not as useful as it sounds for things like our game conversations. Conversations in games need to depend on various variables and they need to be written easily. Wrapping them in a graphic editor felt unnecessarily limiting. We’re programmers, we work fast with a text editor and a clean programming language with simple syntax -- so that was our focus on The Unholy Conversations.
After the development of The Unholy Society and once we catch our breath, we plan to make this system independent from the game and release it as an open-source component. We’re huge fans of open-source here (we use our own open-source Castle Game Engine for the entire game development), so in doing so, we will give back to the community too. If you appreciate our dedication and want to know more about the game, please add The Unholy Society to your wishlist to stay up to date with all further announcements.
[ 2018-03-01 15:35:01 CET ] [ Original post ]
One half of our game, ]The Unholy Society, is an adventure game. You walk around, talk with people, make choices and explore the storyline. We have developed a system, a simple scripting language, to better define adventure games like ours.
Even though our “game designer” is also a programmer, he wanted to separate the game logic from the game’s core source code. This way, the logic, as in, “you cannot enter the church before you speak with aunt” is specified in a different place and a different language, than for example, the logic of how to load Spine models and animate them in the game.
So, we’ve made a script system, designed with "conversations", as a primary use-case. We call it “The Unholy Conversations”.
As the name suggests, the first use-case is for when a player talks with one or more NPCs. However, the system is also useful to define cut-scenes: NPCs can talk (with or without the player) and animations in the environment and the NPCs can be run and so on. The scripts are also run when you enter a location or a particular area of a location. When the player is inside a “sensor” (a simple rectangular box), a script decides whether the player can interact with something and what happens when (s)he does.
How it looks
It’s a set of files, named something like “
A central part of the conversation is choices. They look like this: aunt: Go to Edward. -> Why are you so suspicious when it comes to the Vladinsky family? aunt: I'm not sure are they a good influence on our Susan. -> Can I talk with Susan? aunt: She's getting dressed. There's no time for chit-chat now. -> Bye then. aunt: See you soon. -> As you can see, each choice is just a line that starts with “->”. They all must have the same indentation (hi, Python lovers!) and they must end with an empty choice. This way you can have nested choices too. Note that the choices are (right now) always spoken by a hero and this is why, in the text above, we do not clarify who says, “Bye then”.
To enable simple loops within a conversation, one line may start with a label like “label start” and another line can then jump to it, like “go-label start”. This allows the creation of conversations where you can inquire with an NPC about something, like an investigation, and only exit the loop once you are satisfied (or you have exhausted all the options). The label mechanism does seem like the unpopular “goto” mechanism, abolished from most high-level programming languages, yet here it works perfectly. It’s simple (the conversation files are always short and jumps are only within a single conversation, of course) and flexible, as it allows jumps to different locations.
Variables and tests
A game logic remembers the state of the storyline. Take for example, “Have you already spoken with aunt?”. This particular information (if you have already visited someone) is actually very often useful. All the conversations (and thus, all the NPCs and all locations) have an automatically remembered state of “visited”. It’s a simple boolean flag (it can be true or false). It is initially false and then automatically changes to true once you have spoken with someone. You use a variable in simple boolean expressions together with the “if” instruction: if not visited aunt: Finally! There you are! hero: Hello my dear auntie! aunt: You're late. endif aunt: Go to Edward. Here we use the automatic variable “visited”. Like in every good programming language, variables are placed in namespaces, with each conversation being a natural namespace. This means that another NPC can say different things depending on whether you have spoken with aunt: if not aunt.visited uncle: Your aunt is waiting for you in front of the church! else uncle: Go on, boy. endif Another automatic variable is “gate”. Some NPCs simply won’t let you through until you have done something. For instance, you cannot talk with Susan too early in the game, as you have seen in the above snippets. Once an NPC decides that you can pass, it can “change” the gate status doing “set gate false”. Finally, every conversation can have it’s own custom variables. This can be used to store any game state. For example, the aunt could have a variable like “is_angry”. You can declare such a variable within a conversation file and use it (read or write) from this or other conversations. For instance, a conversation with aunt could end badly for you: declare is_angry false aunt: Go to Edward. -> Right away! aunt: Attaboy! -> Come on, do I really have to? aunt: Yes, you insolent brat. aunt: I remember when you were young and… hero: OK, OK, I’m going… set is_angry true -> Now, another NPC or the aunt could use this flag: “if aunt.is_angry”. As you can see, all the variables must be declared and the declaration must specify their initial value. In this example, the aunt is initially not angry (but watch out, you insolent brat!) That said, it’s a secure and reliable programming language. Only special “automatic” variables, like “visited” or “gate”, do not need to be declared. Naturally, all the conversation variables are saved to the save-game. This allowed the save-game code to be quite simple: just write all the variables to the save-game.
Other cool stuff
The conversations can cause a variety of actions. They can teleport the player or an NPC. They can make some NPC or asset appear or disappear. They can play a particular animation. All of this is smartly saved to the save-game, so the game designer does not have to worry about these technical details when designing the game logic. All the scripts are automatically validated (they use existing variables, are connected to the actual data, etc.). This makes modifying these files safe and testing is easier when the computer automatically detects some of your mistakes. Right now the testing is done each time the game loads (it takes a fraction of a second now - less than 1/10 of a second), but it may be moved to our continuous delivery process (using Jenkins) later.
Inspiration
We have designed a conversation system once before, for our not-yet-released game, The Venice. It had some good ideas and we have borrowed some of them. But it was also not comfortable enough to write a large amount of logic… what we have now, The Unholy Conversations, is both simpler and more flexible to use. We have looked at other conversation systems as well. One in particular was from an excellent indie game, Night In The Woods, which is public and documented on https://github.com/thesecretlab/YarnSpinner/ . We have borrowed various ideas from it, e.g. that the “talk” lines should be simple to write, the “visited” state should be tracked automatically and the “if” and choices should be easy. The “Yarn” language was, in turn, inspired by Twine, a simple text format for telling non-linear stories with choices. Twine is also renowned for its simple-to-use graphic editor for stories, although we quickly decided that a graphic editor was not as useful as it sounds for things like our game conversations. Conversations in games need to depend on various variables and they need to be written easily. Wrapping them in a graphic editor felt unnecessarily limiting. We’re programmers, we work fast with a text editor and a clean programming language with simple syntax -- so that was our focus on The Unholy Conversations.
The Future
After the development of The Unholy Society and once we catch our breath, we plan to make this system independent from the game and release it as an open-source component. We’re huge fans of open-source here (we use our own open-source Castle Game Engine for the entire game development), so in doing so, we will give back to the community too. If you appreciate our dedication and want to know more about the game, please add The Unholy Society to your wishlist to stay up to date with all further announcements.
Behind the Society: The Science of Conversation
Its a set of files, named something like.conv.txt. The decides when the script is run. For example, the file aunt.conv.txt says what happens when you start a conversation with the aunt, one of the NPCs in the first act of our game. The file may look as simple as this:
aunt: Hello dear.
hero: Hello my dear auntie!
aunt: You're late.
Simple enough, right? If a line starts with xxx: then its just someone speaking. xxx can be the name of an NPC (it can also be empty to indicate this NPC, which is implicitly aunt within aunt.conv.txt file) or just hero.
A central part of the conversation is choices. They look like this: aunt: Go to Edward. -> Why are you so suspicious when it comes to the Vladinsky family? aunt: I'm not sure are they a good influence on our Susan. -> Can I talk with Susan? aunt: She's getting dressed. There's no time for chit-chat now. -> Bye then. aunt: See you soon. -> As you can see, each choice is just a line that starts with ->. They all must have the same indentation (hi, Python lovers!) and they must end with an empty choice. This way you can have nested choices too. Note that the choices are (right now) always spoken by a hero and this is why, in the text above, we do not clarify who says, Bye then.
To enable simple loops within a conversation, one line may start with a label like label start and another line can then jump to it, like go-label start. This allows the creation of conversations where you can inquire with an NPC about something, like an investigation, and only exit the loop once you are satisfied (or you have exhausted all the options). The label mechanism does seem like the unpopular goto mechanism, abolished from most high-level programming languages, yet here it works perfectly. Its simple (the conversation files are always short and jumps are only within a single conversation, of course) and flexible, as it allows jumps to different locations.
A game logic remembers the state of the storyline. Take for example, Have you already spoken with aunt?. This particular information (if you have already visited someone) is actually very often useful. All the conversations (and thus, all the NPCs and all locations) have an automatically remembered state of visited. Its a simple boolean flag (it can be true or false). It is initially false and then automatically changes to true once you have spoken with someone. You use a variable in simple boolean expressions together with the if instruction: if not visited aunt: Finally! There you are! hero: Hello my dear auntie! aunt: You're late. endif aunt: Go to Edward. Here we use the automatic variable visited. Like in every good programming language, variables are placed in namespaces, with each conversation being a natural namespace. This means that another NPC can say different things depending on whether you have spoken with aunt: if not aunt.visited uncle: Your aunt is waiting for you in front of the church! else uncle: Go on, boy. endif Another automatic variable is gate. Some NPCs simply wont let you through until you have done something. For instance, you cannot talk with Susan too early in the game, as you have seen in the above snippets. Once an NPC decides that you can pass, it can change the gate status doing set gate false. Finally, every conversation can have its own custom variables. This can be used to store any game state. For example, the aunt could have a variable like is_angry. You can declare such a variable within a conversation file and use it (read or write) from this or other conversations. For instance, a conversation with aunt could end badly for you: declare is_angry false aunt: Go to Edward. -> Right away! aunt: Attaboy! -> Come on, do I really have to? aunt: Yes, you insolent brat. aunt: I remember when you were young and hero: OK, OK, Im going set is_angry true -> Now, another NPC or the aunt could use this flag: if aunt.is_angry. As you can see, all the variables must be declared and the declaration must specify their initial value. In this example, the aunt is initially not angry (but watch out, you insolent brat!) That said, its a secure and reliable programming language. Only special automatic variables, like visited or gate, do not need to be declared. Naturally, all the conversation variables are saved to the save-game. This allowed the save-game code to be quite simple: just write all the variables to the save-game.
The conversations can cause a variety of actions. They can teleport the player or an NPC. They can make some NPC or asset appear or disappear. They can play a particular animation. All of this is smartly saved to the save-game, so the game designer does not have to worry about these technical details when designing the game logic. All the scripts are automatically validated (they use existing variables, are connected to the actual data, etc.). This makes modifying these files safe and testing is easier when the computer automatically detects some of your mistakes. Right now the testing is done each time the game loads (it takes a fraction of a second now - less than 1/10 of a second), but it may be moved to our continuous delivery process (using Jenkins) later.
We have designed a conversation system once before, for our not-yet-released game, The Venice. It had some good ideas and we have borrowed some of them. But it was also not comfortable enough to write a large amount of logic what we have now, The Unholy Conversations, is both simpler and more flexible to use. We have looked at other conversation systems as well. One in particular was from an excellent indie game, Night In The Woods, which is public and documented on https://github.com/thesecretlab/YarnSpinner/ . We have borrowed various ideas from it, e.g. that the talk lines should be simple to write, the visited state should be tracked automatically and the if and choices should be easy. The Yarn language was, in turn, inspired by Twine, a simple text format for telling non-linear stories with choices. Twine is also renowned for its simple-to-use graphic editor for stories, although we quickly decided that a graphic editor was not as useful as it sounds for things like our game conversations. Conversations in games need to depend on various variables and they need to be written easily. Wrapping them in a graphic editor felt unnecessarily limiting. Were programmers, we work fast with a text editor and a clean programming language with simple syntax -- so that was our focus on The Unholy Conversations.
After the development of The Unholy Society and once we catch our breath, we plan to make this system independent from the game and release it as an open-source component. Were huge fans of open-source here (we use our own open-source Castle Game Engine for the entire game development), so in doing so, we will give back to the community too. If you appreciate our dedication and want to know more about the game, please add The Unholy Society to your wishlist to stay up to date with all further announcements.
[ 2018-03-01 15:35:01 CET ] [ Original post ]
One half of our game, ]The Unholy Society, is an adventure game. You walk around, talk with people, make choices and explore the storyline. We have developed a system, a simple scripting language, to better define adventure games like ours.
Even though our game designer is also a programmer, he wanted to separate the game logic from the games core source code. This way, the logic, as in, you cannot enter the church before you speak with aunt is specified in a different place and a different language, than for example, the logic of how to load Spine models and animate them in the game.
So, weve made a script system, designed with "conversations", as a primary use-case. We call it The Unholy Conversations.
As the name suggests, the first use-case is for when a player talks with one or more NPCs. However, the system is also useful to define cut-scenes: NPCs can talk (with or without the player) and animations in the environment and the NPCs can be run and so on. The scripts are also run when you enter a location or a particular area of a location. When the player is inside a sensor (a simple rectangular box), a script decides whether the player can interact with something and what happens when (s)he does.
How it looks
Its a set of files, named something like
A central part of the conversation is choices. They look like this: aunt: Go to Edward. -> Why are you so suspicious when it comes to the Vladinsky family? aunt: I'm not sure are they a good influence on our Susan. -> Can I talk with Susan? aunt: She's getting dressed. There's no time for chit-chat now. -> Bye then. aunt: See you soon. -> As you can see, each choice is just a line that starts with ->. They all must have the same indentation (hi, Python lovers!) and they must end with an empty choice. This way you can have nested choices too. Note that the choices are (right now) always spoken by a hero and this is why, in the text above, we do not clarify who says, Bye then.
To enable simple loops within a conversation, one line may start with a label like label start and another line can then jump to it, like go-label start. This allows the creation of conversations where you can inquire with an NPC about something, like an investigation, and only exit the loop once you are satisfied (or you have exhausted all the options). The label mechanism does seem like the unpopular goto mechanism, abolished from most high-level programming languages, yet here it works perfectly. Its simple (the conversation files are always short and jumps are only within a single conversation, of course) and flexible, as it allows jumps to different locations.
Variables and tests
A game logic remembers the state of the storyline. Take for example, Have you already spoken with aunt?. This particular information (if you have already visited someone) is actually very often useful. All the conversations (and thus, all the NPCs and all locations) have an automatically remembered state of visited. Its a simple boolean flag (it can be true or false). It is initially false and then automatically changes to true once you have spoken with someone. You use a variable in simple boolean expressions together with the if instruction: if not visited aunt: Finally! There you are! hero: Hello my dear auntie! aunt: You're late. endif aunt: Go to Edward. Here we use the automatic variable visited. Like in every good programming language, variables are placed in namespaces, with each conversation being a natural namespace. This means that another NPC can say different things depending on whether you have spoken with aunt: if not aunt.visited uncle: Your aunt is waiting for you in front of the church! else uncle: Go on, boy. endif Another automatic variable is gate. Some NPCs simply wont let you through until you have done something. For instance, you cannot talk with Susan too early in the game, as you have seen in the above snippets. Once an NPC decides that you can pass, it can change the gate status doing set gate false. Finally, every conversation can have its own custom variables. This can be used to store any game state. For example, the aunt could have a variable like is_angry. You can declare such a variable within a conversation file and use it (read or write) from this or other conversations. For instance, a conversation with aunt could end badly for you: declare is_angry false aunt: Go to Edward. -> Right away! aunt: Attaboy! -> Come on, do I really have to? aunt: Yes, you insolent brat. aunt: I remember when you were young and hero: OK, OK, Im going set is_angry true -> Now, another NPC or the aunt could use this flag: if aunt.is_angry. As you can see, all the variables must be declared and the declaration must specify their initial value. In this example, the aunt is initially not angry (but watch out, you insolent brat!) That said, its a secure and reliable programming language. Only special automatic variables, like visited or gate, do not need to be declared. Naturally, all the conversation variables are saved to the save-game. This allowed the save-game code to be quite simple: just write all the variables to the save-game.
Other cool stuff
The conversations can cause a variety of actions. They can teleport the player or an NPC. They can make some NPC or asset appear or disappear. They can play a particular animation. All of this is smartly saved to the save-game, so the game designer does not have to worry about these technical details when designing the game logic. All the scripts are automatically validated (they use existing variables, are connected to the actual data, etc.). This makes modifying these files safe and testing is easier when the computer automatically detects some of your mistakes. Right now the testing is done each time the game loads (it takes a fraction of a second now - less than 1/10 of a second), but it may be moved to our continuous delivery process (using Jenkins) later.
Inspiration
We have designed a conversation system once before, for our not-yet-released game, The Venice. It had some good ideas and we have borrowed some of them. But it was also not comfortable enough to write a large amount of logic what we have now, The Unholy Conversations, is both simpler and more flexible to use. We have looked at other conversation systems as well. One in particular was from an excellent indie game, Night In The Woods, which is public and documented on https://github.com/thesecretlab/YarnSpinner/ . We have borrowed various ideas from it, e.g. that the talk lines should be simple to write, the visited state should be tracked automatically and the if and choices should be easy. The Yarn language was, in turn, inspired by Twine, a simple text format for telling non-linear stories with choices. Twine is also renowned for its simple-to-use graphic editor for stories, although we quickly decided that a graphic editor was not as useful as it sounds for things like our game conversations. Conversations in games need to depend on various variables and they need to be written easily. Wrapping them in a graphic editor felt unnecessarily limiting. Were programmers, we work fast with a text editor and a clean programming language with simple syntax -- so that was our focus on The Unholy Conversations.
The Future
After the development of The Unholy Society and once we catch our breath, we plan to make this system independent from the game and release it as an open-source component. Were huge fans of open-source here (we use our own open-source Castle Game Engine for the entire game development), so in doing so, we will give back to the community too. If you appreciate our dedication and want to know more about the game, please add The Unholy Society to your wishlist to stay up to date with all further announcements.
the Unholy Society
Cat-astrophe Games
Fat Dog Games
Q2 2018
Indie Singleplayer
Game News Posts 15
🎹🖱️Keyboard + Mouse
Mixed
(23 reviews)
https://unholy-society.com/
https://store.steampowered.com/app/746750
The Game includes VR Support
The Unholy Society depot - Linux (64-bit) [1.35 G]
ABOUT GAME
the Unholy Society is a game inspired by 80s and 90s action movies as well as comic book series such as Preacher and Constantine. It presents a world captured by the united forces of demons and monsters. The Werewolf King, the Great Old One, Satan, the Great Voodoo Shaman and Dracula join forces to eradicate love and bring eternal darkness to the world, and perhaps to also drink lots of tea and discuss art. The only one with a chance of stopping them is our amnesiac exorcist. At the request of the Pope himself he sets off on the quest to fight for good and justice, leaving behind a trail of cigarette butts and empty whiskey bottles.
STORY
A retired exorcist is forced to don his cassock one last time to save the world. Lying on a bed in a dingy hotel, the exorcist was unaware that his one night stand beauty would become a threat… Just after midnight she revealed her demonic face and perfectly sharp, though very unwomanly, claws. As it turned out later, this case wasn’t the last. A sect of the most powerful and the most iconic bad guys of pop culture threatens the world. Only our hero can stop them with the help of his lackluster faith. Will his dusty Bible, revolver and a wooden stake be enough? Will the exorcist recover his lost memories and regain his abilities?
MINIMAL SETUP
- OS: Ubuntu 16.04 LTS
- Processor: 1.5 GHzMemory: 2 GB RAM
- Memory: 2 GB RAM
- Graphics: any GPU card with 3D acceleration and latest drivers
- Storage: 1500 MB available space
- OS: Ubuntu 16.04 LTS
- Processor: 1.5 GHzMemory: 4 GB RAM
- Memory: 4 GB RAM
- Graphics: NVidia or AMD GPU with 1 GB VRAM
- Storage: 1500 MB available space
GAMEBILLET
[ 5951 ]
GAMERSGATE
[ 3154 ]
FANATICAL BUNDLES
Time left:
3 days, 5 hours, 44 minutes
Time left:
26 days, 5 hours, 44 minutes
Time left:
8 days, 5 hours, 44 minutes
Time left:
39 days, 5 hours, 44 minutes
Time left:
45 days, 5 hours, 44 minutes
HUMBLE BUNDLES
Time left:
5 days, 23 hours, 44 minutes
Time left:
5 days, 23 hours, 44 minutes
Time left:
14 days, 23 hours, 44 minutes
by buying games/dlcs from affiliate links you are supporting tuxDB
