The Waiting List

My ideas, concepts and WIPs.

I would like to realize everything on this page. It contains projects that I'd like get to in the future, as well as projects I'm working/have worked on and want to get back to. There is no ETA for these, as I like to jump from project to project.


Tutorials

Tutorials that I'd like to do. The order doesn't matter whatsoever.

For Basics of Ren'Py:

  • persistent data
  • layered images
  • rollback and working with it
  • transitions
  • custom text tags
  • displaying side image of one character when another one is talking
  • attributes in dialogue lines used with images shown with show, and how it can mess side images up

For Screen Language:

  • Coding GUI - Changing the menu screen (Will write this very soon!). This could be a great opportunity to showcase some Python in screens, make the choices appear in two columns rather than in one.
  • Coding GUI - The save/load, preferences, the quick menu and the choice screens (mentioned above) are left at this moment.
  • bar statement, will likely be included in a Coding GUI - Preferences tutorial.
  • Statements like grid, side, key - We still have some remaining.
  • viewport and vpgrid, only after a tut on grid was written. Covering all three of these would be way too much for one tutorial.
  • CUSTOM SCREEN - History.
  • styles, style_prefix and style_suffix.
  • tooltips.

For Python in Ren'Py:

  • functions
  • scopes


Ren'Py Scripts

I want to have a page here called Ren'Py Scripts, where random codes could be found.
For example, today someone in #renpy asked how to hide a choice inside a menu when the choice is unavailable. Or, someone the other day wanted a countdown timer in a screen

Bigger things could also be included, but I'm thinking more smaller ones.

  • Continue screen action
  • And I'm sure I had some more ideas

LezGlossary
Status: On Hold (2/5)

Intended to be a Glossary system for visual novels. Glossary screen in my mind can take two different forms.

  • Text form: A collection of revealed names (like met characters), lore (gained from talking with characters), or places already visited or mentioned.
  • Visual form: Often done for characters only. Characters not met have a portrait with question marks, met ones are revealed.

In both cases, clicking on an "entry" reveals information and details about it.

Notes:
The problem isn't the code, it's the screen. I'm not sure if I can make one screen for both cases? Maybe two screens?


Calendar
Status: Finished in a rough form

Even though the Calendar can be used to only show days and months (just like a regular calendar would), it's intended purpose is to let player pick a date.

This was quickly coded for someone in #renpy, who wanted to let players pick the birthday of their main character, and I barely touched it afterwards, but cleaning it so I'm not ashamed to publicize it.

What makes it amazing is also that this can automatically change the names (of week days and months) to the user's language (based on their PC settings).


Pronoun Manager
Status: Just an idea

Basically a way of handling words that have more than one version.

Perfect example of this are pronouns. In a game where the player can pick their pronouns, you need a way of inputting he/she/they - him/her/them - his/her/theirs accordingly.

I'm just not sure at the way of doing this, mostly how to put it into text. Either interpolation or custom text tag, I'm guessing?


Crafting System
Status: Just an idea

It would be very interesting to have a crafting system. There is one major issue I have with it.

I might/have to/should update LezInventory first, so that the crafting system can use it.
Wait, does that mean that the crafting system can be for both LezInventory as well as different Inventory system?? That could get messy.

It would be really cool to make Minecraft-like crafting, as in, a grid. Wouldn't be too hard. Regular "combine to create new" sounds too simple.

Notes:
Due to working with multiple Inventory systems (ideally), the crafting system should have variables pointing at Inventory functions, like addition, so that the crafting system can insert them itself.


Unveil
Status: Almost Finished  (4.85/5)

Born from my lack of knowledge, Unveil is a displayable that slowly reveals text, just like a regular Ren'Py dialogue does. The reason I did this was mostly because I wasn't aware of the slow_cps property of Ren'Py's Text displayables, and it renders most of Unveil redundant, as it can go at much higher cps than my Unveil can.

That being said, Unveil does have at least some functionality that the Text object does not:

  • Text objects is always treated - when it comes to size, anchors and such - as if it was already entirely revealed. Unveil can change this, and increase it's area as the text shows.
  • Unveil supports custom tags - pause which pauses the reveal, and speed which changes the speed while the reveal is happening.
    Text
    displayables with slow_cps cannot do this (Not checked properly).
  • Unveil supports variable interpolation, which is putting variable's value inside the text.
    Text displayables with slow_cps cannot do this either (Not checked properly).

I'm not sure I want to put in the effort to finish this. It feels as a waste of time, given that the default way of achieving this is faster, easier to set up and is even more efficient.

Maybe just for the hell of it? If I add some comments, the code should be good to go by now.


Horror Assets
Status: On-and-Off (1/5)

I don't know why I am so drawn towards making horror effects, the ideas just seem to randomly pop up in my mind. I doubt I'd gather enough for something like LezHorror, but I do have two already:

  • Text that can be manipulated, which has become the Unveil
  • A blinking "vision" image to simulate not enough light with only a flickering source.

RPG Framework
Status: On Hold (Hard Project)

I've always wanted RPG features in Ren'Py. A map created from tiles, characters walking across it, interacting with objects in the environment, going through doors to enter new map and continue exploring.

I've seen a ton of people interested in this. Some simply want a fancy way for their character to move around. Some want to have the character collect items from the map at certain points in the story. Some want it for creating minigames, and some want to go all the way and create an RPG with visual novel elements.
While Ren'Py is not meant to be an RPG engine, obviously, I think there's a very reasonable base to build on.

I've already tried to code an RPG Framework twice before writing this. I think where code for the first one is, but I had wayyyyyy less experience back then, so no point looking for that.
The second attempt is much more recent, but still, I'd say it's about a year I last touched it. I'm honestly stumped whether I should go back to it once I want to work on the RPG Framework, or just start from scratch for the third time.

We'll see.


DE Project
Status: On Hold (Huge Project)

DE Project is an acronym of a Ren'Py game that I'd like to code one day. It is based on a browser game in my country - one that has been around for over 20 years, and one that still holds a tiny, yet dedicated community.

I thought it would be cool to recreate it with some changes. We're talking different map, different races and units, enough for it to be considered a new game. Change some mechanics, too, based on my experience with it - some features are limited by the simple fact that it's a game coded for browsers.
This is why I used the word recreate, not copy.

Info about the current DE game:

  • It is a turn-based strategy. All players take turns simultaniously, with outcome of everything evaluated at the end of a turn.
  • Every players starts with a race they've selected. Every race has a different passive ability, different starting money and mana and three different units they can train:
    - Defensive with high defense and low attack, usually with low cost.
    - Offensive with high attack and low defense, usually with moderate cost.
    - Magical. Their attack and defense vary across the races, since their main purpose is to produce mana and enhance spells. They're usually the most expensive of the three.
  • It has a map composed of tiles. Each player is given one at the start of the game, with most tiles starting out neutral.
  • Every tile has values for strength, population and houses:
    - Strength is the value that enemy's attack has to exceed in order to capture the tile.
    - Larger population (Represented by villagers) increases strength of the tile, as well as the amount of money you get from the tile per turn.
    - Houses limit the amount of villagers and units alike that can be on a tile at the same time. As long as there are free houses, population will increas every turn.
  • To create a unit, you need one villager and a set amount of money.
    - Units increase strength of the tile they're on.
    - They can be sent onto a different tile, moving one tile per turn.
    - They can capture neutral or enemy tiles if the strength of sent units exceeds the tile's strength.
  • Buildings can be built on each tile. Buildings increase defense, offense, income, mana production, villagers born per turn and more, but some are quite costly.
  • You can cast spells. Spells range can do what buildings can, as well as kill enemy soldiers or villagers, decrease tile's defenses or cleanse a tile from all bad effects.
    - Total amount of player's magical units also increases the effectivity of spells.
  • There is an evil AI with the same name as the game itself, DE. To win the game, you have to capture their starting tile.
    - It is very hard for one player to do alone. As such, victory goes to all players in the winning player's alliance, not just the capturer alone.
    - DE's starting tile can only be attacked once a player (or, more likely, an alliance) has amassed certain amount of tiles. This also marks the point where DE begins to be agressive, since the amount of tiles speaks for the player's overall strength.

The original DE is massive. Not only do I think it's kinda cool, I think it would be nice if it received an update - Albeit not one the creators might imagine.

Notes:
- The first prototype was based on a MongoDB database (collection). Tables inside hold tile informations, player informations, as well as all information what was done current turn (attacks, spells being castm, houses built...). A server program then evaluates all the actions, updates values (for example, new population on tiles, new amount of money of each player...) and sets up a new turn.
I did actually have a working simpler version of this and still have the git on my Gitlab account.


If you have questions, I'll gladly answer them on my Discord server.
There, you can contribute your own tips to include on this page!