First promotional material - feedback welcome. - ReBirth [Development Thread]

[BanksyBoyz]

Hey, all. Been a lurker on these forums for a while now but, with my game's prologue nearing a playable state, I thought it might be time to finally start posting some stuff myself.

As the title suggests, this thread will primarily be about my experience trying to code Ren'Py's features into Unreal Engine for use in my own visual novel. The first obvious question is why? Why would I spend the time to build features into Unreal that already exist in another game engine expressly built for this purpose?

Fair question - my answer is a bit long so if you're curious about my rationale it's in the spoiler box below. I won't claim it's a good rationale, but here it is:

Spoiler: Why would you build Ren'Py inside Unreal Engine when Ren'Py already exists?

You don't have permission to view the spoiler content. Log in or register now.

So, that out of the way, what does this actually look like? Obviously, the first thing I needed to do was make sure there was a functioning dialogue system. I first scoured the Epic Marketplace to make sure nothing like this was already available (which would certainly have made my life easier), and while there were some basic VN-style systems, none of them were nearly robust enough for my liking - so I began the long process of making my own. Following various tutorials on YouTube and mashing some different free plugins together I was able to implement a system that I think works quite well. The groundwork was a bit labor-intensive, but as you'll see in the screenshots below, now that the system is built it's quite easy to customize with branching paths and complex interactions.

The underlying concept of the dialogue system, like the visual scripting language of Unreal's blueprint interface, is that each line of dialogue or description is represented by one node. This node can then be used to fire off an unlimited number of events (called by the dialogue widget) that can influence any other part of the system. So say you want to add an item when a particular dialogue node is triggered, you can do that. Want to change a character expression, start an animation, trigger a flag or variable check, you get the idea - anything that you can think of can be triggered and accessed via specific nodes within each scene - you can also access the dialogue nodes within other blueprints, meaning the communication works both directions.

Spoiler: Code Example - Dialogue System

You don't have permission to view the spoiler content. Log in or register now.

Another advantage of this node-based dialogue system is that it's super easy to create branching paths. In the example below, you can see that the choice text is generated by a single item in the node that tells the GUI "choice text" widget to create a new button automatically. Choosing one option or the other will then trigger that line of dialogue in the tree. You can also have these branches loop back on themselves if you want to allow players to choose options multiple times (something like a traditional "exposition tree" seen in most RPGs). If you want to add a third option, simply create a new node and connect it to the tree.

Spoiler: Decision Tree - Code Example

You don't have permission to view the spoiler content. Log in or register now.

The last thing I'll talk about in this initial post (it's getting a bit long already) is the UX. I know from reading these forums and playing a lot of Ren'Py games, that this is one of the major challenges using that engine - every GUI tends to look about the same and employ the same handful of identical features. Unreal has a pretty sizable advantage here since the UMG system is very easy to customize. You can see in the series of images that the move from design to implementation to actual in-game functionality is pretty much 1:1.

Spoiler: UX Example - CODEX

You don't have permission to view the spoiler content. Log in or register now.

So that's it for now. I'd definitely be interested to hear people's thoughts who have been doing this a while or who might be interested in following a similar path.

I am planning to release all my project files to the community once I have them cleaned up and in a state that would make sense to anyone that isn't me - definitely let me know if this is something you'd be interested in as it will take quite a bit of additional work to get all the documentation made for using my systems and knowing that people are interested would help motivate me.

As far as the game itself, I am happy to answer any questions about this process or challenges I've faced/am facing - I will be tracking this thread and am happy to answer any of your questions about this, the game, or my experience trying to undertake this project without much prior experience in the space (I am certainly no artist).

You can track the game's progress on my

You must be registered to see the links

(which I just set up yesterday, so it's lacking content at the moment), and I expect the prologue to be available on here in the next few weeks.

Cheers!

BBZ

 

[probably_dave]

Good luck with the project! Creating an new VN engine from scratch must be a tough job, even using the tools available in the Unreal Engine. From the looks of it, you've obviously put a lot of effort into the UX design which, for me, is key to any successful game.

I'd also like to commend your attitude, especially around opening up the engine code to the community. Doing this type of thing allows the industry to grow with new ideas and as you mentioned, provides more variety than your usual 'cut-and-paste' VNs.

Good luck with your PHD too, I'm sure it must be difficult during these times. However, I'm going to be a little paranoid next time I put my VR kit on that I've accidently stumbled into one of your psychological experiments

 

[BanksyBoyz]

Good luck with the project! Creating an new VN engine from scratch must be a tough job, even using the tools available in the Unreal Engine. From the looks of it, you've obviously put a lot of effort into the UX design which, for me, is key to any successful game.

I'd also like to commend your attitude, especially around opening up the engine code to the community. Doing this type of thing allows the industry to grow with new ideas and as you mentioned, provides more variety than your usual 'cut-and-paste' VNs.

Good luck with your PHD too, I'm sure it must be difficult during these times. However, I'm going to be a little paranoid next time I put my VR kit on that I've accidently stumbled into one of your psychological experiments

Appreciate it (I checked out your development thread, btw, looks pretty awesome - I see we share a tendency toward the ambitious). I agree that a good UX is one of the most important elements in making a VN stand out, and I will admit that making all the pieces work was an undertaking, but I'm reasonably pleased with how it's coming together.



I've honestly been surprised by how supportive and collaborative the community on this forum is given how toxic the internet can generally be, so it's been refreshing to see a community that seems to genuinely help each other and provide monetary support for games they can play totally for free, just because they value the developer's effort and talent. I do strongly believe in open collaboration, and if I can create something that someone else can use or improve on to make something that I in turn have the potential to enjoy or benefit from? Well, that's just a virtuous cycle right there, everybody wins.

It's not been the best year to be trying to finish a PhD, I will admit, but since I only run my experiments in a laboratory you shouldn't need to worry. That said, I can't speak to the companies that make your headset, I'm guessing Facebook is doing quite a bit of experimentation on you, but that's just par for the course.

I do appreciate your feedback, and I will be keeping an eye on your project as well!

 

[BanksyBoyz]

Worked a lot the past couple of weeks on finalizing all the game systems I'll need to expand the feature set of the game beyond the prologue. Free roam, dialogue flags, gallery system, player/dialogue variables, and sound effects are all now added to the game.

Implementing free roam elements in Unreal is surprisingly easy - just a matter of taking a render, chopping up the bits you want to use as buttons, throwing them into the UMG system, and adding functionality to the buttons (script triggers, events/decisions, etc.).

Spoiler: Free roam system

You don't have permission to view the spoiler content. Log in or register now.

Creating a gallery system from scratch was a bit more challenging, but ultimately pretty straightforward once I figured out how to make the unlock system work (images are placeholder of course). Simply included a line of code that adds the render to an array and tells the gallery widget to flip the image to unlock it - this state is then updated in the persistent save data so it remains unlocked when the game is closed or the player starts a new game. I then trigger a notification through the dialogue system to tell the player that they've unlocked a new image - the node is gated so it will not be shown after the render has already been unlocked.

Selecting the image in the gallery will expand it into a full-screen viewing widget that allows you to navigate through the images freely. I know this is probably a pretty basic feature of Ren'Py, but it was a fun challenge in Unreal - I do think this system improves on most of the gallery navigation I've come across in Ren'Py games.

Spoiler: Gallery System

You don't have permission to view the spoiler content. Log in or register now.

Now that nearly all of the systems I need for the game to work correctly are implemented, I'm turning my full attention back to the script and rendering out the scenes that will go into this initial release. My script currently stands at about 80 pages for the prologue, but I will be going through and cutting fat / streamlining it, so hopefully, it will be a quick, engaging opening to the game that helps set the scene for what's to come.

I have big plans for the scope of the world-building and though I'm sure this all seems overly ambitious for a solo-developer taking their first crack at a visual novel, the foundational work should allow me to focus entirely on the story and animations for the game without needing to worry about coding as I go.

Really excited to get this in the hands of the players and get some initial feedback. I'll probably post some tomorrow about the Codex system and maybe a bit about the story.

Cheers,

BBZ

 

[anne O'nymous]

I don't want to discourage you, such framework for Unreal could really be interesting, but there's a big misunderstanding here.

Firstly, in your motivation :

One of the most common complaints with Ren'Py games seems to be the difficulty of fully customizing the GUI (graphical user interface), leading to a lot of Ren'Py games looking very similar to each other and having very basic user experiences (sometimes referred to as "click next simulators" in these forums).

The GUI of Ren'py can perfectly be fully customized, and even the "click next" part isn't at all mandatory. All Ren'py games looks similar because devs don't care to works on this part, not because they can't, or because it's too difficult.


Secondly, the list of the features you're working on, in addition to the dialog system and UX, that are a free roaming system and gallery system. Those aren't the features of Ren'py, but things that can be coded using Ren'py.

What one expect when reading "creating Ren'py inside Unreal engine", is to find a frameworks that will :

• Have a rollback system that permit to the player to revert back the game to a previous step, including all the variables ;
• Skip feature that permit to the player to quickly pass through parts previously seen, when and only when, those parts are strictly identical to what he already saw ;
• An auto-forward feature that, facing a menu and if asked to, would automatically repeat your previous choice if it's a rollbacked part ;
• An unlimited amount of save slots ;
• And obviously the console.

I would add that, as developer, people would expect a really easy to use translation system, and, for people with a little more knowledge regarding Ren'py, to have its dynamical flexibility.
Creating the dialogs through a tree is great, but what make Ren'py superior here, is that part of your dialog can be the content of a variable that will change depending of the context. And the same apply for the shown images and shown menu. The real force of Ren'py is in this flexibility, in this possibility to write one, and only one, piece of code and having a potentially infinite number of different result, without the need to write a single if.

Take this really small Ren'py code, by example :

label whatever:
    scene expression "sc01_{}_{}".format( loveInterestSex, loveInterestColor )
   mc "Hi [loveInterestCivility], sorry I'm a little late."
   loveInterest "For the wait, honey, be a good [mcSex] and pay for the diner."

Those four lines will show you either a girl, a man, a catgirl, an alien, or whatever, depending of what the dev have planed. And this girl/man/catgirl/alien/whatever, can be African, Asian, Caucasian, or whatever. One line, an infinity of image that can be displayed.

As for the dialog, just those two lines offer you four different combinations:

• Male MC, female love interest ;
• Female MC, female love interest ;
• Male MC, male love interest ;
• Female MC, male love interest.

But "loveInterestCivility" can also be something "mistress" or "slave", while "mcSex" can be something like "pet" or "master", what imply that here again there's a really high number of possibilities.

And all one need to write, for the player to face a infinity of possibilities for this scene, is those four lines and really just those four lines. This while, so far, your framework would need that he create a variation of the scene for every single possibilities he planed.
So just for a love interest that can be a girl or a man, the master or the slave, and black or white, in Ren'py, four lines are enough, while with your frameworks the dev would have to duplicate the scene 8 times. And if later the author want to add a Asian variation for the love interest, he'll just have to create the CG and add this option in the game configuration, while with your frameworks, so far he'll have to duplicate the scene four more times.

Oh, and as modder, I would add that what I expect is its astounding number of callbacks and possibilities to hook into almost everything :

• Changing a dialog line in the fly ;
• Knowing precisely what is the content of the exact line proceeded at this moment ;
• Hijacking screens or labels ;
• Inserting content into a screen or a label ;
• Changing a dialog line into a notification that automatically disappear after some times ;
• Many other things that don't cross my mind right now.

And all this without having to edit a single line of the original code. This is really something marvelous when you mod a game, it offer you the possibility to let your mind go as wild as you want, and it's what Ren'py permit.



This being said, and like I said as introduction, your project is really interesting, and it could bring more Unreal games on the scene. So I hope that you'll finish it one day.
But what you are doing is not "creating Ren'py inside unreal engine", it's creating an Unreal frameworks for visual novels. And it's totally fine, it's something that is missing but, so far and in regard of everything you said about it, it will be something totally different to Ren'py in its behavior, and perhaps not more complex to use, but that will need way more works. Therefore it will never replace Ren'py, just add more options when choosing the engine to use for a game.

 

[BanksyBoyz]

I don't want to discourage you, such framework for Unreal could really be interesting, but there's a big misunderstanding here.

Firstly, in your motivation :


The GUI of Ren'py can perfectly be fully customized, and even the "click next" part isn't at all mandatory. All Ren'py games looks similar because devs don't care to works on this part, not because they can't, or because it's too difficult.


Secondly, the list of the features you're working on, in addition to the dialog system and UX, that are a free roaming system and gallery system. Those aren't the features of Ren'py, but things that can be coded using Ren'py.

What one expect when reading "creating Ren'py inside Unreal engine", is to find a frameworks that will :

• Have a rollback system that permit to the player to revert back the game to a previous step, including all the variables ;
• Skip feature that permit to the player to quickly pass through parts previously seen, when and only when, those parts are strictly identical to what he already saw ;
• An auto-forward feature that, facing a menu and if asked to, would automatically repeat your previous choice if it's a rollbacked part ;
• An unlimited amount of save slots ;
• And obviously the console.

I would add that, as developer, people would expect a really easy to use translation system, and, for people with a little more knowledge regarding Ren'py, to have its dynamical flexibility.
Creating the dialogs through a tree is great, but what make Ren'py superior here, is that part of your dialog can be the content of a variable that will change depending of the context. And the same apply for the shown images and shown menu. The real force of Ren'py is in this flexibility, in this possibility to write one, and only one, piece of code and having a potentially infinite number of different result, without the need to write a single if.

Take this really small Ren'py code, by example :

label whatever:
    scene expression "sc01_{}_{}".format( loveInterestSex, loveInterestColor )
   mc "Hi [loveInterestCivility], sorry I'm a little late."
   loveInterest "For the wait, honey, be a good [mcSex] and pay for the diner."

Those four lines will show you either a girl, a man, a catgirl, an alien, or whatever, depending of what the dev have planed. And this girl/man/catgirl/alien/whatever, can be African, Asian, Caucasian, or whatever. One line, an infinity of image that can be displayed.

As for the dialog, just those two lines offer you four different combinations:

• Male MC, female love interest ;
• Female MC, female love interest ;
• Male MC, male love interest ;
• Female MC, male love interest.

But "loveInterestCivility" can also be something "mistress" or "slave", while "mcSex" can be something like "pet" or "master", what imply that here again there's a really high number of possibilities.

And all one need to write, for the player to face a infinity of possibilities for this scene, is those four lines and really just those four lines. This while, so far, your framework would need that he create a variation of the scene for every single possibilities he planed.
So just for a love interest that can be a girl or a man, the master or the slave, and black or white, in Ren'py, four lines are enough, while with your frameworks the dev would have to duplicate the scene 8 times. And if later the author want to add a Asian variation for the love interest, he'll just have to create the CG and add this option in the game configuration, while with your frameworks, so far he'll have to duplicate the scene four more times.

Oh, and as modder, I would add that what I expect is its astounding number of callbacks and possibilities to hook into almost everything :

• Changing a dialog line in the fly ;
• Knowing precisely what is the content of the exact line proceeded at this moment ;
• Hijacking screens or labels ;
• Inserting content into a screen or a label ;
• Changing a dialog line into a notification that automatically disappear after some times ;
• Many other things that don't cross my mind right now.

And all this without having to edit a single line of the original code. This is really something marvelous when you mod a game, it offer you the possibility to let your mind go as wild as you want, and it's what Ren'py permit.



This being said, and like I said as introduction, your project is really interesting, and it could bring more Unreal games on the scene. So I hope that you'll finish it one day.
But what you are doing is not "creating Ren'py inside unreal engine", it's creating an Unreal frameworks for visual novels. And it's totally fine, it's something that is missing but, so far and in regard of everything you said about it, it will be something totally different to Ren'py in its behavior, and perhaps not more complex to use, but that will need way more works. Therefore it will never replace Ren'py, just add more options when choosing the engine to use for a game.

I'd be lying if I said I hadn't thought, "why am I doing this, this is a massive waste of time, just use Ren'Py instead" many times to myself when I hit a major stumbling block or encountered some bug I couldn't seem to fix (I still have panicked moments where I feel this way - reading your initial comments brought them up, tbh - there is admittedly very much I do not know about VNs... I'm trying to learn quickly but it's a lot), but ultimately I kept at it so for better or worse I'm stuck with it now. And just to clarify, my goal with this thread was/is to relay my experience doing this thing, not denigrate or misrepresent what Ren'Py is or why people would prefer to use it over Unreal Engine (it's obviously the most robust, most documented, and most specific VN architecture out there - I am not so arrogant as to think I could come close to replicating or replacing it).

I probably used a poor title (was trying to be pithy) - more accurately stated would be "my experience trying to recreate the most commonly used implementations of Ren'Py (as I understand them and experience them in other VNs) inside of Unreal Engine because I want access to both these features and Unreal Engine features for purposes of future proofing as well as my own personal goals" but that's a bit long ... I fully admit this is a very bespoke setup I've devised, it does what I need it to do - when I think of a new thing I'd like to do I can build that feature into it, but its purpose is not to be Ren'Py (I'd love to see developers take an interest in expanding the feature set of an Unreal Engine visual novel system, but that's definitely a project that's too big for just me - I will provide my project files to anyone who wants them). I do think that anyone who knows how to code C++ or use Unreal blueprinting should be able to expand on it to do what they need it to do, but like you said, that does require work.

I'm not familiar with modding, though I'm sure modding Ren'Py code is far simpler than modding anything made in Unreal - it wasn't really something I've thought much about (this project has been a large undertaking, not even including all the writing for the script, learning DAZ and rendering, and doing the graphic design work as a non-artist - I'm sure there are many things I've overlooked or am simply too ignorant about to even know I should be looking, but trying to account for everything would have paralyzed me so I just soldiered on the best way I could with what I did know).

Maybe my understanding of Ren'Py is too limited, but the difficulty of creating complex UX seemed to be a common complaint I came across when trying to decide how to approach this project (and the lack of compelling mini-games and even basic alterations to the GUI suggested to me this was true - but perhaps it is just low priority as you say, even if I'd argue it shouldn't be). Like I said in the outset, Ren'Py is foreign territory to me, so I hope I have not come off as trying to claim a level of expertise on the subject that I do not possess.

Building the system certainly required a lot of work, but actually using it is relatively straightforward. I have no doubt there are many things an experienced Ren'Py developer would hate about it, but for what I want to do it works (at least until I release my version 1 and everyone tells me it's terrible - which would be a sad day, to be sure, but I'm optimistic for now).

I appreciate you taking the time to offer feedback. My ultimate goal here is really just to make a great visual novel and maybe help other people do the same if I can (especially non-coders who would benefit from a visual system with easy, quick iteration) - perhaps this will prove months of wasted effort, but at the very least I learned a lot in the attempt.

 

[anne O'nymous]

[...] but ultimately I kept at it so for better or worse I'm stuck with it now.

And it's the thing to do. I said/implied it twice in my initial comment, and it's not our of politeness, what you are doing can effectively add something to the scene, and it's a good thing that you are doing it.

[...] not denigrate or misrepresent what Ren'Py is or why people would prefer to use it over Unreal Engine (it's obviously the most robust, most documented, and most specific VN architecture out there - I am not so arrogant as to think I could come close to replicating or replacing it).

And my intent wasn't to present you that way. I try more to make you forget about Ren'py and just do the framework you want to make.
It's a fact, you'll never be able to make "Ren'py on Unreal". Not because you aren't good enough, but because Ren'py it's near to 20 years of constant development. What imply that yourself would need two or three years of development to implement everything that make Ren'py a great engine when one know how to use it.
Therefore, as long as somewhere in your head there's this idea to make a "Ren'py like thing", you'll struggle and continue to wonder why you're doing this to yourself. You'll be looking at a Ren'py game you're playing, looking at what you did, and only see the amount of works that you'll still have to do. And this is obviously discouraging.
It's like cycling/walking on a very long straight road. You see the end of the road, far far away, and it never feel nearer than one minute ago. You've the impression to stagnate, that you'll never reach the end.

But if you focus on a Visual Novel framework, then it's something different. What you see is that you have already made something like this, oh, and that also you've made it. It's more encouraging, and you'll be less prone to stop all this.
Then, once it will be done, you can, if you want, start to add some of the specificity of Ren'py. Whatever if you finally find that you can't, you already have finished your framework, so it's not something that will be missing, but an addition that will not happen.

I probably used a poor title (was trying to be pithy) - more accurately stated would be "my experience trying to recreate the most commonly used implementations of Ren'Py (as I understand them and experience them in other VNs) inside of Unreal Engine because I want access to both these features and Unreal Engine features for purposes of future proofing as well as my own personal goals" but that's a bit long ...

"Creating a Visual Novel framework for Unreal" is shorter, while saying the same and being accurate to your project.

Spoiler: It's a side problem, but I wouldn't be me if I wouldn't address it

You don't have permission to view the spoiler content. Log in or register now.

My ultimate goal here is really just to make a great visual novel and maybe help other people do the same if I can (especially non-coders who would benefit from a visual system with easy, quick iteration) - perhaps this will prove months of wasted effort, but at the very least I learned a lot in the attempt.

And I sincerely hope that you'll achieve it.

 

[BanksyBoyz]

"Creating a Visual Novel framework for Unreal" is shorter, while saying the same and being accurate to your project.

Fair enough, the title was really just meant to relay my actual mindset approaching the project (using Ren'Py and the visual novels made with it as a reference for creating similar - at least to the end-user, if not to the developer - systems within Unreal Engine). The feature set you mentioned (skipping, auto, rollback, etc.) were the explicit goals of the project when I started, it was very much Ren'Py "inspired," and I did implement those systems, but the goal has definitely changed a bit as I decided what direction to take it. I probably should have been more aware of the way that such a title would play to a community of Ren'Py developers when I know very little about the actual nuts and bolts of the program but rather am trying to recreate the end-user experience of it.

But if you focus on a Visual Novel framework, then it's something different. What you see is that you have already made something like this, oh, and that also you've made it. It's more encouraging, and you'll be less prone to stop all this.

Yes, this is true. I will admit it can be difficult to sustain motivation on a project with no feedback and no way of knowing if it well ever even work (I've worked on this project almost daily since early October - and only in the last couple of weeks is it in a fully playable state). I'm in the fortunate position of having a window of time to work on this as a full-time project, so I've had extra motivation to make the most of it, but obviously one only need look at the graveyard of abandoned projects in this forum to know how difficult a sustained effort of this size can be (especially when you're doing it for free on your own time). I certainly understand the wisdom in limiting scope and not trying to do everything at once (even if I don't follow that advice often enough).

I do sometimes fire up a VN and try to dissect how this or that thing was accomplished, and then try to create the same thing myself in Unreal - it's just kind of a fun exercise - but you're right that just trying to make every possible Ren'Py game feature into Unreal Engine is a project with no end. As my prologue reaches a state that I'm ready to show, I'm definitely far more focused now on simply making sure the features that I personally need to execute my vision will work and worrying less about what features people will expect my game to have because of their experience with Ren'Py (a losing effort, no doubt, even if I'm sure I will get those complaints).

 

[BanksyBoyz]

With the framework built and working, I've completely shifted my focus now to cleaning up the story elements for the prologue (I had written a rather long script before the game was even in production, but my ideas have evolved quite a bit since that initial phase and significant rewrites are required). Since I'm not quite ready to share more on that just yet, I figured I'd do a post a bit about my thought process on the art direction for the game.

As many of us have discovered when solo-developing a game, even a relatively straightforward project like a choice-driven visual novel requires one to wear a lot of hats, learn a lot of new skills/software, and really push yourself to do things you've never done before and/or know very little about. I knew I wanted to make a game with a cohesive style, but executing that is easier said than done. I won't claim I have nailed it by any stretch, but this has been my thought process trying to tackle the presentation for the game.

-----------------

Art direction for a non-artist like myself is a bit difficult to approach with any degree of confidence. I could watch all the YouTube talks and explainer videos on design principles that my little brain could handle, but there's a large difference between understanding something intellectually and having the creative capacity to execute an original concept yourself. For me, knowing that I lacked the experience, intuition, and artistic skill to make something truly unique, I did what I thought was the next best thing - played a lot of games with great art design and tried to distill what made them great into some basic ideas I was capable of executing.

I decided relatively early on that I was going to go for something like a storybook aesthetic, I wanted to give the impression that you're playing a digital artbook. This led me to the idea of using canvas and watercolors for the menu art, and using tear effects on the menus. I have no actual artistic skill, so I used Photoshop brushes and various basic filters/actions to turn renders that I created in DAZ into something resembling watercolor paint on a canvas (I hope it does anyway). I was reasonably happy with the result. I then, after some more minor tweaking, took that concept into Adobe Xd where I layered on the UX elements and then put that into Unreal.

Spoiler: Watercolor aesthetic

You don't have permission to view the spoiler content. Log in or register now.

For the menus, I created a simple tear animation, again using Photoshop brushes (with the help of some YouTube tutorials) and Adobe Xd (as well as After Effects in this case for the tear animation) to create a "torn page" look. I knew I wanted the actual game interface to be very clean with minimal clutter, and so I used this concept to place the main in-game menu out of sight, the menu "tearing" from the bottom of the screen when hovered (time of day and game system icons - inventory, codex, history - appear from the top of the screen).

I'm not sure that this is the best way to do this, it has drawbacks, but it does produce the result I desired. The main menu and options again tear through the screen when selected. I also created simple tear "cutins" for dynamic movement during gameplay, but I'm not sure how well this works and will have to experiment with it a bit (maybe get some player feedback on it).

Spoiler: Game menus

You don't have permission to view the spoiler content. Log in or register now.

One area I'm still going back and forth on a lot with myself is in the dialogue presentation. Obviously, dialogue makes up a large part of VNs (though my game has more exposition than most, the dialogue is still a major part of the experience), and how this is presented seems pretty important. Very popular games approach this problem differently and with, I think, good reasons and good results. I have tried several different approaches myself, including the full-body against a background style of 2D VNs, the "talking heads" style, and the "full-screen player POV" style.

The conclusion I've come to, at least for now, is that I will probably employ some combination of these in the end product. I think they all serve a purpose and can be used effectively in combination so long as it's done with a specific goal (full-body dialogue allows you to see the characters interacting, talking-head dialogue is better at showing faces and emotions, while direct POV renders give a feeling of "being there" and more direct agency for the player - at least that's how I feel about it).

This is probably the area that will change the most in the coming days leading up to this v1 release of the Prologue, I am definitely still experimenting with it (static images vs animation is a big question for me, I've tried both and there are definite pros and cons - the big con obviously being time, and while I think it would add polish to the experience, people tend to click through dialogue quickly making it potentially wasted effort).

Spoiler: Dialogue stuff

You don't have permission to view the spoiler content. Log in or register now.

A final quick note on fonts. I think fonts are pretty important. Obviously, if you're going to be reading tens of thousands of words for many hours, the font better be easy to read. That practical consideration aside, I also think fonts do quite a lot of work in selling the "feel" of the game through its menus and interaction systems. For story reasons, I'm using a mixture of contemporary sans-serif fonts and storybook style adventure fonts, but I've tried to keep a very consistent feel, limiting the number of fonts and employing them in very deliberate ways to achieve a specific feel for the game.

I'm not sure I've succeeded, but that will be for the player to tell me.

Spoiler: Fonts

You don't have permission to view the spoiler content. Log in or register now.

 

[BanksyBoyz]

My writing process for this project is still a bit of a work in progress, but I thought some of you might be interested to see how I've gone about it and what I've learned attempting to keep track of a pretty complicated story (I think the advice to start small on a first project is good, but I admittedly did not follow it for this one - so here's what you can probably expect if you decide to chart a similar course).

Again, I do not claim this is the most optimal way of doing things, I'm inexperienced at this so I've been stumbling my way through it by reading how others have done it and trying different things to see what works best for me.

Spoiler: My writing 'method'

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: What programs I use - my workflow

You don't have permission to view the spoiler content. Log in or register now.

I'll be showing the story in more detail this week hopefully, introduce some of the characters, and give a quick overview of what you can expect from the experience going forward. In the meantime, if anyone has questions about my process or maybe some tips on what I could be doing better/things you've done to manage the complexity of writing a story like this please don't hesitate to jump in.

Cheers,

BBZ

 

[LaymanBot]

This is very interesting, another dev using other engine than Ren'Py. I'm doing a VN with Unreal too.

Is your codex based in Assassin's Creed Valhalla codex UI? It's very similar.

 

[BanksyBoyz]

This is very interesting, another dev using other engine than Ren'Py. I'm doing a VN with Unreal too.

Very cool. Out of curiosity, why did you choose to use Unreal? I see in your game thread that it's a common complaint (people prefer what they know - which I definitely understand, and I agree it seems an odd fit at first glance). As two of the only people on this site using Unreal as a visual novel engine, I'm just curious. I played your demo and think it looks really promising. I have a similar idea to include a decision graph in my game, but it's on the back burner for now (certainly a feature I think branching VNs should have standard).

I used this same dialog plugin to make RPGs in the past, it's good. Have you ever heard of

You must be registered to see the links

?

I had not heard of it, no. It looks cool. I'm way too far along to switch now but definitely seems like it would be great if you come from a Ren'Py background (I do not).

Is your codex based in Assassin's Creed Valhalla codex UI? It's very similar.

I like the visual style of the newer AC game UI systems, not sure if that codex was from Odyssey or Valhalla, but I'm sure I did use one of those for inspiration.

 

[LaymanBot]

Very cool. Out of curiosity, why did you choose to use Unreal? I see in your game thread that it's a common complaint (people prefer what they know - which I definitely understand, and I agree it seems an odd fit at first glance). As two of the only people on this site using Unreal as a visual novel engine, I'm just curious. I played your demo and think it looks really promising. I have a similar idea to include a decision graph in my game, but it's on the back burner for now (certainly a feature I think branching VNs should have standard).

I'm using UE because I'm implementing some features that are just too much work to develop and maintain using Ren'Py, like the story graph, event system and UI (blur, quality, animated transitions, etc.).

I was aware of the complaints it was going to cause when I decided to go for it, actually, I thought it were going to be worse . My idea is to convince them with high quality.

It's good to have more people doing things with UE, so players get more used to it.

PS: Version 1 is out, if you have played the demo, I recommend it.

 

[BanksyBoyz]

I'm using UE because I'm implementing some features that are just too much work to develop and maintain using Ren'Py, like the story graph, event system and UI (blur, quality, animated transitions, etc.).

I was aware of the complaints it was going to cause when I decided to go for it, actually, I thought it were going to be worse . My idea is to convince them with high quality.

It's good to have more people doing things with UE, so players get more used to it.

PS: Version 1 is out, if you have played the demo, I recommend it.

I definitely respect it. I made the decision before I really had much experience in the VN development space, so it surprised me a bit how much resistance there is to any game not made in Ren'Py, but I understand it more now having spent so much time in this community (I underestimated how much modding seems to matter and being able to access the backend of a game). I feel like people should probably understand though that "make this in Ren'Py" isn't exactly helpful feedback when you've spent months building out these systems and you can't simply port over C++ to Python, but I get why they may prefer the experience and feature set they are already deeply familiar with.

It gives me a bit of anxiety as I approach my own release after putting so much effort into this project that people will dismiss it simply because it's made in Unreal Engine, but I am trying to also overcome that barrier with (hopefully) a high quality experience.

 

[LaymanBot]

[...] but I get why they may prefer the experience and feature set they are already deeply familiar with.

Yes. What I have observed is that players like Ren'Py features, like rolling back, saving anywhere, etc. Also, Ren'Py games tend to have less bugs them Unity and UE games, what bothers them a lot.

It gives me a bit of anxiety as I approach my own release after putting so much effort into this project that people will dismiss it simply because it's made in Unreal Engine, but I am trying to also overcome that barrier with (hopefully) a high-quality experience.

A lot of people will not even open your game’s page because it's UE. We have to accept this as an inherited condition to use UE for VNs here. As you said, the best way to handle is with higher quality.

 

[Deleted member 1536527]

A lot of people will not even open your game’s page because it's UE.

Yup, that's me. Personally its because I think using a full-blown game engine for a visual novel is a massive overkill. But also my laptop can barely handle those games, a lot of em are poorly optimized, and making my computer have a stroke for a bunch of stills doesn't seem worth it.

 

[BanksyBoyz]

Yup, that's me. Personally its because I think using a full-blown game engine for a visual novel is a massive overkill. But also my laptop can barely handle those games, a lot of em are poorly optimized, and making my computer have a stroke for a bunch of stills doesn't seem worth it.

As far as it being overkill - it's true that the game engine does a lot of things you don't need for "a bunch of stills" as you say (though that's true of Ren'Py as well, which has features that almost no VN uses - and really that's a burden on the developer, not the player), but there's really no reason you can't use it for that purpose (the UMG system is quite robust and allows you simple, visual, quick iteration on the exact sorts of animations, transitions, and UX elements that are critical to a good VN experience). It's designed to run (and does run) everything from mobile games to AAA blockbusters (no single game uses all the features of the engine), so there also should be no real reason that it would run heavy if the game is properly packaged (I will do my best to ensure that it is). It's also an underrated rendering tool with the DAZ to Unreal pipeline, and of course if you want to include actual game elements in your VN it's got a lot of features designed to handle that sort of thing.

Ultimately, my goal is to provide a very similar user experience to what you'd expect in Ren'Py so that the player doesn't really need to think about how the game was built when they're playing it. I hope you'll consider giving it a try at least when it comes out and let me know if you still feel the same (if you do, I'll continue working on it until I can achieve something you can feel good about - I'm confident that this is possible).

 

[BanksyBoyz]

I've made the first promotional images for my game, thought I'd try to elicit some feedback. The game takes place in two semi-split timelines (at least initially), the mechanics of which are explained early on in the prologue, but the general question the game asks is: if you could live a second life, knowing everything you know now, what would you do differently? Layered onto that central question is this larger plot revolving around what that experience would actually be like (being born a second time - hence the name of the game) and of course the characters you meet and scenarios that you must navigate as part of that experience. There's a lot more going on, but that's at the heart of what drives the action.

For these promotional images, I wanted to capture that dichotomy of former and current self by having the character literally split in half - the paper rip is a central design element in the game's interface so I thought it would be cool to incorporate that into the game's promotion as well. Anyway, that's my thought process, I am not an artist by any means (definitely a lot of work to do in that department, but I'm putting the effort in), so I am for sure open to some constructive criticism.

Cheers,

BBZ

Spoiler: Promotional image

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: Social media banner

You don't have permission to view the spoiler content. Log in or register now.

 

[Meushi]

thought I'd try to elicit some feedback.

The title choice for your game is unfortunate, given there's an existing Ren'Py game with the same name.

Seems likely to lead to some confusion, despite having nothing in common other than the name (odd capitalization aside).

 

[BanksyBoyz]

The title choice fot your name is unfortunate, given there's an existing Ren'Py game with the same name.

Seems likely to lead to some confusion, despite having nothing in common other than the name (odd capitalization aside).

It's really just a working title. I appreciate the heads up though.