Why no text spaces in games?

[e-disfunction]

It's not at all difficult - you don't need a mod! Even if you don;t change the base image, the size can also be altered in the code itself. Like Faerie Dust I regularly hide it (just type 'hide window')

The problem isn't the shape of the textbox - but how that would negatively affect gameplay.

EXAMPLE TEXTBOXES FROM MY GAMES:
View attachment 533547 From SpaceCorps XXX
View attachment 533548 From Project Gemini

Also, does Ren'py force the text onto the screen at a certain height (above the lower window edge), or is it easy to make the text start closer to the bottom?

e-d

(P.S.: I appreciated your various text boxes when playing your games. )

 

[Faerie Dust]

As RanliLabz explained, you need to replace the appropriate png image to a transparent or less intrusive one and possibly change the settings in the code for it to display properly. There are very few things hardcoded in Ren'Py. With some research, almost anything is customizable!

 

[moskyx]

Also, does Ren'py force the text onto the screen at a certain height (above the lower window edge), or is it easy to make the text start closer to the bottom?

e-d

(P.S.: I appreciated your various text boxes when playing your games. )

You can place the text wherever you want, you can adjust the dimensions of the textbox (being transparent or solid), you can change fonts, alignment, textsizes... everything is customizable. It just take a bit of researching and testing work. But Ren'py gives you a default UI and many developers just stick to it.

 

[Saki_Sliz]

I don't use renpy myself, so I don't know what limitations or functions users can use to personalize the User interface, I prefer to code everything raw. I am actually trying to implement

You must be registered to see the links

, for all my future projects (not sure if moving back to unity or sticking with monogame).

 

[e-disfunction]

(Saki_Sliz, moskyx, Faerie Dust, RanliLabz: Thank you everyone! )

Okay! Let's see if I've been paying attention. (Please offer corrections, additions, deletions, & etc.)

Short version:

The end result of creative communication--in this case the inconvenient/annoying text boxes that cover well-created pics/vids yet remain absolutely necessary--is a ultimately a result of compromises between varying strengths and weaknesses inherent in: The primary medium; all secondary supporting media; the creator and creator's ideas; the tools and tech available to both the creator and audience; the desires and disposition of the audience.

So, although the *&^%$#! text boxes are problematic to creators and audiences, as long as they are sufficient to contain what the artist communicates and are what the audience needs to allow understanding of the creation then the boxes don't need any general "solution" or "fix". But when needed, it is possible (and even easy) for most creators to alter those boxes.

(Did I pass?)

_____

Long version of the Generalities, in no particular order:

a) Yes, game creators are aware *when* text, buttons (game info, character status, etc.), and tools (game saving, help screens, computer resolution, etc.) obscure the art in games.

b) End-users (players) wish to (and do) consume and use all of the arts and tools of the games regardless of awareness. They appreciate being able to play and explore in and of games. (Whether players *appreciate* the actual arts involved is for a different discussion. )

c) The overriding medium--computer hardware, OSs, and their I/O methods--*forces* many constraints on creators *and* users of games (and both creators and users have little or no power to change the overriding medium).
Example: *every* picture needs to be created according to particular aspect ratios, with certain pixel resolutions, in a container (jpg, webm, png, etc.) understandable by many computer programs and game formats and OSs, across as many human languages as possible. (Getting that picture actually *delivered* to users is for a different discussion. )

d) There are many tools available to creators (game engines/platforms, art softwares, programming languages, etc.). However, those tools are *not* necessarily compatible with: each other, various hardwares, or even the users!
Example: "Simply" compress a game *programmed* in Cyrillic with WinRAR (which is UTF aware) and let users decompress it with 7-Zip (not UTF aware) and there will be problems! Factor in varying OSs (on both ends of the compression) and *their* programmed and translated states and the volume of problems can quickly escalate.

e) Furthermore, artists each have unique strengths, areas of knowledge, and time and resource constraints. No individual can know of all tools, in all languages, of every art, and in every technology (to make or program their own tools!). [Note: if an individual *could* do all these things, they would 1) quickly make a lot of money; 2) instantly become obsolete; and 3) might not be defined as an artist any more because of 1) and 2) ... ]
Examples: Not all writers are capable or willing to code Ren'py to display text different from default layouts; not all programmers may care if a Unity 'Quick Save' button is labelled in Georgia or Trebuchet; and not all visual artists will care if end-users "see" a picture's invisible layers on a black, white, or rainbow-coloured background because of users' computers OS specs and capabilities.

f) Creators have a need to produce and communicate their ideas. If some (all) of the available tools are deficient this will not necessarily stop a work from being made--the result just might differ from original conception. Artists usually try to truly create and communicate what they imagine but are limited by skills, cultural languages, availability of technolgy, patron economics, and the like.
Example: A professional artist in one medium can be a complete amateur (or hack!) in another medium; any person might create just because it feels good; and any amateur can be gifted in field where they have little interest but they can help others who have interest to do better.

g) Players have a desire consume and understand those ideas, and eventually feed back his/her understanding--and maybe new ideas (or even art!). Usually consumers want things they are somewhat comfortable with and artists can use these comforts (and even discomforts) to increase comprehension of their creations.
Example: All artists start somewhere as and with not-artists; and not everyone likes the same art or in the same way as others do--some object to the fan dancer and others object to the fan. [I can think of certain books that are incedibly popular but "need a stake driven through them and then let stand in direct sunlight to burn them away to dust"; and also I know other books that are "campy" or "trashy" that are just fun to read even if no one else likes them. ]

Therefore in computer games & VNs, we get those *&^%$#! text boxes that are useful, obnoxious, worthwhile, and generally unsightly.

So, have I, an unwashed outsider, understood the situation as you all have presented it?

e-d

 

[moskyx]

(Saki_Sliz, moskyx, Faerie Dust, RanliLabz: Thank you everyone! )

Okay! Let's see if I've been paying attention. (Please offer corrections, additions, deletions, & etc.)

Short version:

The end result of creative communication--in this case the inconvenient/annoying text boxes that cover well-created pics/vids yet remain absolutely necessary--is a ultimately a result of compromises between varying strengths and weaknesses inherent in: The primary medium; all secondary supporting media; the creator and creator's ideas; the tools and tech available to both the creator and audience; the desires and disposition of the audience.

So, although the *&^%$#! text boxes are problematic to creators and audiences, as long as they are sufficient to contain what the artist communicates and are what the audience needs to allow understanding of the creation then the boxes don't need any general "solution" or "fix". But when needed, it is possible (and even easy) for most creators to alter those boxes.

(Did I pass?)

_____

Long version of the Generalities, in no particular order:

a) Yes, game creators are aware *when* text, buttons (game info, character status, etc.), and tools (game saving, help screens, computer resolution, etc.) obscure the art in games.

b) End-users (players) wish to (and do) consume and use all of the arts and tools of the games regardless of awareness. They appreciate being able to play and explore in and of games. (Whether players *appreciate* the actual arts involved is for a different discussion. )

c) The overriding medium--computer hardware, OSs, and their I/O methods--*forces* many constraints on creators *and* users of games (and both creators and users have little or no power to change the overriding medium).
Example: *every* picture needs to be created according to particular aspect ratios, with certain pixel resolutions, in a container (jpg, webm, png, etc.) understandable by many computer programs and game formats and OSs, across as many human languages as possible. (Getting that picture actually *delivered* to users is for a different discussion. )

d) There are many tools available to creators (game engines/platforms, art softwares, programming languages, etc.). However, those tools are *not* necessarily compatible with: each other, various hardwares, or even the users!
Example: "Simply" compress a game *programmed* in Cyrillic with WinRAR (which is UTF aware) and let users decompress it with 7-Zip (not UTF aware) and there will be problems! Factor in varying OSs (on both ends of the compression) and *their* programmed and translated states and the volume of problems can quickly escalate.

e) Furthermore, artists each have unique strengths, areas of knowledge, and time and resource constraints. No individual can know of all tools, in all languages, of every art, and in every technology (to make or program their own tools!). [Note: if an individual *could* do all these things, they would 1) quickly make a lot of money; 2) instantly become obsolete; and 3) might not be defined as an artist any more because of 1) and 2) ... ]
Examples: Not all writers are capable or willing to code Ren'py to display text different from default layouts; not all programmers may care if a Unity 'Quick Save' button is labelled in Georgia or Trebuchet; and not all visual artists will care if end-users "see" a picture's invisible layers on a black, white, or rainbow-coloured background because of users' computers OS specs and capabilities.

f) Creators have a need to produce and communicate their ideas. If some (all) of the available tools are deficient this will not necessarily stop a work from being made--the result just might differ from original conception. Artists usually try to truly create and communicate what they imagine but are limited by skills, cultural languages, availability of technolgy, patron economics, and the like.
Example: A professional artist in one medium can be a complete amateur (or hack!) in another medium; any person might create just because it feels good; and any amateur can be gifted in field where they have little interest but they can help others who have interest to do better.

g) Players have a desire consume and understand those ideas, and eventually feed back his/her understanding--and maybe new ideas (or even art!). Usually consumers want things they are somewhat comfortable with and artists can use these comforts (and even discomforts) to increase comprehension of their creations.
Example: All artists start somewhere as and with not-artists; and not everyone likes the same art or in the same way as others do--some object to the fan dancer and others object to the fan. [I can think of certain books that are incedibly popular but "need a stake driven through them and then let stand in direct sunlight to burn them away to dust"; and also I know other books that are "campy" or "trashy" that are just fun to read even if no one else likes them. ]

Therefore in computer games & VNs, we get those *&^%$#! text boxes that are useful, obnoxious, worthwhile, and generally unsightly.

So, have I, an unwashed outsider, understood the situation as you all have presented it?

e-d

I don't think we said that much
Basically, most people here are amateur developers. They have an idea and/or certain skills they want to show to an audience. Ren'py is just a broadly-accepted and relatively-easy-to-use tool both for creators and players, so it has become a standard in this 'industry' and that have its own pros and cons. Then is all about how creators manage their resources (time, money, coding and art skills) and the level of interest they show to maximize player's experience.

When we as players open a Ren'py game, we already know what to expect, it's a known environment and black textboxes are just part of it. If a developer is kind enough to remove them, improving our visual enjoyment, that's great. If not, well, we know we can press H. So it's not a big deal for a vast majority of players.

 

[e-disfunction]

I don't think we said that much

Yes but no?

I was trying to understand what I thought was an annoying and easy-to-solve issue. All of you eventually suggested a number of reasons why things were as they are, and how the might be changed or worked-around, and who was doing the creating and why, and who was doing the playing and how, and etc.

Directly, you all did not say those things but they were indirectly in the words and contexts and examples cited. To understand the situation and all of your answers properly, I could not disregard those parts of your message that were not explicit.

Just because something isn't explicit doesn't mean it's not there. But that's just me, I guess.

(You need to do things exactly like this in many games ... why not in real life, too?)

Is it okay that I tried make to make sure that I understood?

 

[moskyx]

Yes but no?

I was trying to understand what I thought was an annoying and easy-to-solve issue. All of you eventually suggested a number of reasons why things were as they are, and how the might be changed or worked-around, and who was doing the creating and why, and who was doing the playing and how, and etc.

Directly, you all did not say those things but they were indirectly in the words and contexts and examples cited. To understand the situation and all of your answers properly, I could not disregard those parts of your message that were not explicit.

Just because something isn't explicit doesn't mean it's not there. But that's just me, I guess.

(You need to do things exactly like this in many games ... why not in real life, too?)

Is it okay that I tried make to make sure that I understood?

I know what you did, that's why I used that gif. Maybe I don't really get what it means here (that funny guy is from my country, my only intention was to show my comment was sarcasm).

 

[e-disfunction]

I know what you did, that's why I used that gif. Maybe I don't really get what it means here (that funny guy is from my country, my only intention was to show my comment was sarcasm).

I didn't realize it was sarcasm and thank you for explaining. No worries!

(I actually have no idea who that gif is--I stopped trying to follow every meme soon after "All your are belong to us".)

 

[79flavors]

Why is that box there at all?!?

Other have covered it... but simple put, it's a visual novel. The "novel" part is the box... the text.
By default, RenPy (by far the most common VN engine for complete beginners) has a default box and a default style. A lot of developers just leave it alone and focus on the story they want to tell and the images they want to create to go along side.
Personally, I find the box not transparent enough - but changing the transparency creates issues when the text color closely matches the color of the image behind it. Again, leaving it the feck alone generally means people don't need to worry about that sort of shit.
There's also the "familiarity" factor. I would venture a guess a lot of people play RenPy games because each game shares a lot of common traits. In short... they know what to expect... with that comes the text box.

Why do creators constantly cover their art & pictures & text in their games & VNs like this?

A guess... but a semi informed one. Most developers would say something like "well, you can press [H] if you want to see the full image". And honestly, most images are fine. Occasionally you might run into one where the text box suddenly feels "in the way", but they are very much in the minority.
But to expand on that... I think the reality is that most developers tend to create images that are 1080p or 720p (though 4K images are becoming more common). They do so in packages like Daz3D which are intended to create images of that size and aspect ratio. When they're framing up a shot... most won't consider the text box. When their editor of choice defaults to 1920x1080 or 1280x720 or similar... those are the sizes they'll use.

Why don't creators include a black box at the bottom of their pics so we can see entire pictures, text, and tools while interacting with them?

To reuse the same answer... because once they've done 2 or 3 hundred renders in 1080p... chopping bits off the bottom feels like losing something they spent a lot of time creating. Especially since that space might actually be visually needed (where people who want to see it can press [H] and those who barely notice the background images don't). They could resize the whole image to fit in the space about the text box... but that would lead to some gnarly black bars on either side.

In short reminding users they can press [H] is a whole lot easier than thinking about it ahead of time and framing all the images slightly differently. Plus there would be a lot more complaints of "Why is there a black area behind the text box?" than there are ever likely to be about not being able to see the whole image by default... because simply put... that's what people are used to.

 

[e-disfunction]

To reuse the same answer... because once they've done 2 or 3 hundred renders in 1080p... chopping bits off the bottom feels like losing something they spent a lot of time creating. Especially since that space might actually be visually needed (where people who want to see it can press [H] and those who barely notice the background images don't). They could resize the whole image to fit in the space about the text box... but that would lead to some gnarly black bars on either side.

(As mentioned earlier) If you put the blank space(r) in the pics before rendering there is no need for any chopping or resizing. And the entire render (space included) will automatically resize with the picture from that point on.

FWIW, nowhere did I mention anything about changing anything that was already made--I only asked why things were made that way when they did not need to be.

In short reminding users they can press [H] is a whole lot easier than thinking about it ahead of time and framing all the images slightly differently. Plus there would be a lot more complaints of "Why is there a black area behind the text box?" than there are ever likely to be about not being able to see the whole image by default... because simply put... that's what people are used to.

Yeah, I know (and agree with you) .

(Separate memory/thought) I remember the complaints about windows and mice and GUIs when they happened, too, but we seem to have survived the worst of those newfangled ideas and ways of thinking . Who needed them things anyway?

 

[Saki_Sliz]

So, although the *&^%$#! text boxes are problematic to creators and audiences, as long as they are sufficient to contain what the artist communicates and are what the audience needs to allow understanding of the creation then the boxes don't need any general "solution" or "fix". But when needed, it is possible (and even easy) for most creators to alter those boxes.

sounds pretty comprehensive to me

 

[Ashenthorn]

(As mentioned earlier) If you put the blank space(r) in the pics before rendering there is no need for any chopping or resizing. And the entire render (space included) will automatically resize with the picture from that point on.

FWIW, nowhere did I mention anything about changing anything that was already made--I only asked why things were made that way when they did not need to be.


Yeah, I know (and agree with you) .

(Separate memory/thought) I remember the complaints about windows and mice and GUIs when they happened, too, but we seem to have survived the worst of those newfangled ideas and ways of thinking . Who needed them things anyway?

I think you are WAY overthinking this....

Let's say most current monitors are 16:9 aspect ratio.

This is the available screen space for image + text.

You keep saying "Why not just include a black bar in the image?"

The answer is "Because that REDUCES the area (height) left over for the image to display on the screen"

If you include the black bar (or blank space) in the image, you have LESS area for the image without any way to utilize that space for the actual render/image.

Why would you want that constant dead space instead of just pushing the H key?

In Ren'Py, it's trivial to make the text box at the bottom even a single line high -- but it would certainly be painful to read a VN that way.

Here's a visual:

An image I created and composed for 16:9, and how it would look in a VN:



Remember, in a VN, you can hide the text with H to see the full image.



Here's the same image with your "solution" of including the black bar in the image:



Yes, you can now see the full image, but in my opinion, the composition is visually much worse - dead space on the sides (even if I had rendered it wider, if I want the focal point of the image to be the 3 ladies, the sides would still be just the backdrop and dead space), and you also lose image detail because the image is smaller, and you obviously can't zoom in.

It's fine if you prefer the second one... but for me, bigger is better.

That being said, I do think some other aspect ratios are great and have their place... for example, 2001: A space Odyssey should ONLY be watched in Super Panavision. I certainly don't mind the black bars on the top and bottom when I watch Panavision movies on my TV.

But they haven't really caught on in the VN world.

 

[79flavors]

IMO: The solution isn't a black background at the bottom (irrespective of black bars on the side or not)... The solution is for renders to be done with a slightly higher camera position and with the camera slightly further back. In effect, widening the field of view so that there would still be a section of the picture displayed behind the text box - but nothing relevant to composition would be there. But that sort of thinking needs to be there when the developer is creating their images in whatever drawing/rendering package they choose. But doing so for artist familiar with composition will be working against a lifetime of muscle memory of framing images in a certain way. I personally would use a different style of image with less opaque areas for the background too (in fact, I did exactly that when rewrote a game into RenPy and so couldn't change the existing renders).

I offered a couple of solutions already as alternatives. Not because I think they are viable or even the focus of the question, but to point out that those sort of solutions aren't even being considered by the average RenPy VN developer - who lets face it, are hobbyists who have more basic problems to contend with. My point wasn't "here's some solutions", my point was "developers aren't giving it a second thought". Even highly experienced developers won't care, because the vast majority of their paying customers won't care either. Because, let's face it, if people had ever been upset about it in sufficient numbers in the past enough to draw attention to it... the practice would have changed. It hasn't, therefore majority of the target audience don't care.

 

[Ashenthorn]

The solution isn't a black background at the bottom (irrespective of black bars on the side or not)... The solution is for renders to be done with a slightly higher camera position and with the camera slightly further back. In effect, widening the field of view so that there would still be a section of the picture displayed behind the text box - but nothing relevant to composition would be there. But that sort of thinking needs to be there when the developer is creating their images in whatever drawing/rendering package they choose. But doing so for artist familiar with composition will be working against a lifetime of muscle memory of framing images in a certain way. I personally would use a different style of image with less opaque areas for the background too (in fact, I did exactly that when rewrote a game into RenPy and so couldn't change the existing renders).

Yes, I agree with most of this.
... but really, I think that a great number of developers/artists are pretty good about not hiding relevant areas behind the box. There are some exceptions of course, but overall, I really don't find myself hitting the H key all that much. And some considerate devs do hide the box for important scenes. After all, if you're making a porn game you probly want to show as much as you can "above the fold".