An
You must be registered to see the links
build defined as an INTERNAL not feature complete build, being tested by testers who are part of the development team.
But then, isn't it better to only test a given scene ?
At work, we have a strong testing policy, but obviously we all start with basic unitary tests that only target the function we are working on. It's only when all the functions past their tests, that we test the unit/feature/whatever they are wrote for. And only when the unit/feature/whatever all pass the tests, that we test the software itself.
We could use placeholder-like functions that proceed only the basis with a frozen context, and directly test the unit/feature/whatever. But then, is the error due to one finished function, or to one of the placeholder ones that is too generic ? And if we waited to have all the functions, then the error could come from whatever function involved ; is it this one that return a wrong value, or this one that wrongly process the value it get ? We would fallback to a late unitary testing at a time where we don't have their specification in mind, and don't necessarily remember immediately why we wrote it this way, and not that way. Bonus points if both functions have been wrote by two different persons.
We loose time doing those unitary tests, but then gain more time when we pass to the unit/feature/whatever tests, because we know for sure that it's either an integration error or a bad interaction between two functions.
Of course, in a Ren'py game with placeholder, the impact is limited, but still the time gain stay.
You'll judge the scene accordingly to the leading or trailing placeholder, and it's possible that you find that they don't link right together. Therefore you'll return it to the dev, that will change a dialog line or redo a render to correct this. But then, the effective scene will be different that the placeholder ; it's always the case, because it always feel different in your script and when it become something real. And once again the two scenes don't like well, again the dev have to make changes ; and the first ones was minutes (for dialog) to hours (for renders) lost uselessly.
Alpha version:
"[Placeholder: The MC peek his mother under the shower. He's not fast enough, she caught him when taking a towel before exiting the shower] Scene effectively done, the MC go to the mother's bedroom to apologize, the first CG is the mother fully clothed."
Return: Hmmm... The mother dress really fast, shouldn't she be at most in underwear ?
Beta version:
"The MC peek his mother [...] towel before exiting the shower. The MC feel bad and go to his room, sit on his bed and decide to apologize. The MC go to the mother's bedroom to apologize, the first CG is the mother with only her panty, putting her bra on."
Return: Hmmm... The mother dress really slowly, shouldn't she have more clothes ?
Of course, the part where the MC pass through his room wasn't in the placeholder ; with the transition effect used in the game, it didn't mattered this much. But when making the scene, the author felt that something was missing ; the player don't feel enough MC's guilt. Therefore he added this small interlude, a scene where MC's guilt is clearly shown.
It can be just one CG, the MC sat on his bed, and one single dialog line, "What the fuck have I done ? I'm really a bad son". But it totally change the pace of the game, and so what the player expect to find when entering the mother's bedroom.
What a test include totally depend of the question it have to answer to.
We focus first on the function individually because the question is, "is this function following all its specifications". At this time we don't care how it interact with the rest, if it follow its specifications, then it's the right code for this function, dot. As I said above, any error after this point will come from the integration, a bad interaction or something forgot in the specification. It limit the place where the error can be.
Applied for a game, the question when you test a scene should be, "is this scene understandable, and did it carry the expected feelings". With possibly a, "are the decision made during this scene correctly handled". It's only later that you wonder if the scenes links correctly together.
Doing it this way also make the testing more efficient, because at each step the tester(s) have only one thing to focus on. The scene itself during the Alpha test, then only the transition between scenes during the Beta test. This way you risk less to miss something.
This said, it doesn't mean that placeholders can't play a role during tests...
Enabling full playthrough testing
...for this reason, a pre-Alpha test. A test where there's nothing more than placeholders describing all the scenes, in order to validate that their order feel right. Because, once again, what you have on the paper (your script) will never feel the same once you see it working.
And when you write a sandbox-like game, I would say that this pre-Alpha phase is fundamental. It don't need much time to be wrote, nor much time to be proceeded. But by doing it again and again, going through as much variation as you can think, you'll catch that, "oh fuck ! With this order, the mother accept to give a handjob to the MC, and in the scene right after she go full tantrum because the MC see her in her underwear. It's totally weird, I have to correct this".
You can obviously do the same thing during the Beta test, but either you've to pass through all the scenes, so it will be way too long to do all the tests, or you'll use Ren'py's skip feature, and then probably miss the significant details.
Therefore, yes, placeholders have an utility. A pre-Alpha (or code Alpha) test version full of placeholders and where you use colors to describe the level of each important points in the scene. Something that would looks like :
Code:
Mother reaction: tantrum [red]
Mother reaction: Not happy [orange]
Mother reaction: neutral [Deep Blue]
Mother reaction: happy [sky Blue]
Mother reaction: lusty [green]
If during your test you pass from "deep blue" to "red" for the mother reaction, like in my example above, you'll immediately see it. And you'll need what ? 5 minutes to perform a full test with a given configuration, against at least 1 hour (for a small update) if you do it with the Beta.
If you do this with the definitive structure for the code, when you'll works on the scenes you'll just have to fill the said labels. You know that they'll link in the right order, that the variable changes are now correct, and that the choice are correctly handled. All you need now is the CG and dialog lines.
If the community is used for testing and the community is also it's intended audience showing sub par work will lead to a bad judgment by that community as you stated before. The community forgives a lot, but we can't help being human.
But if you use the community for that, it fallback to the "bad feeling about the game", "lost in interested because there's no more surprise in the story", and "the 'I'll replay it later' that never happen", that I listed in my previous comment. It can only be done with people that agreed to be spoiled and really want to help.
Consider this video "
You must be registered to see the links
" of a publisher where one of his dislikes is "12. I can't tell what's placeholder and what's not." 11:40
Therefore, better not have placeholders at all
It obviously wouldn't works if you're in search for a publisher, because the pitch will not feel right ; but like you said, there's no real need for a publisher in this scene, at least for indies devs. But, if you're releasing your game, the absence of placeholders will not lower the quality and interest of the game. This while their presence can do it because, like said in the video you linked, the player can't always tell if it's a bad scene or a too good placeholder.
When I was at a multimedia company 20 years ago they used "
You must be registered to see the links
", "
You must be registered to see the links
" and "
You must be registered to see the links
" images as placeholders. Those hurt my eyes and where so ugly I was really motivated to get them out off sight.
I have kind of the same habit when I code. Because yes, reader my friend, even when codding you can have to rely on placeholder ; by example when you want to try a new approach, or works on a part you don't have the habit to code. In order to see if you understood correctly, it's generally preferable to proceed step by step (unless the compilation times is effectively too high) because each step depend of the previous one. So, better validate that "this" works before starting to write the code that will totally depend of this answer. But sometime you need at least a basic version of what follow for the code to do something.
So, authors my friends, don't hesitate to do the same when working on your game ; especially if you don't have much experience in coding.
Personally I put this placeholder code at 0 level of indentation (except in Ren'py/Python of course), what totally mess with code folding, and make me want to get rid of it as soon as possible. What is similar to the ugly colors you talk about.
When you've no other choice than using placeholder, do something that will annoy you. This way you'll never forget it, and you'll replace by real content as soon as possible.
The process not being iterative has impact
Not being able to use an iterative process combined with it's intended results also being highly uncertain, an impact on the development process of a game.
If you thought the code, and planed the development, correctly at first, it shouldn't be a problem. You've securities for content that still have to come, and you add the scene in such way that they'll be no hole, even in an alternate path or in the story of another character.
By example,
Super Powered use a modular base for its code. Each character have a label for each action, and the labels having all the same format (generally "[name of the character]_[action]") they are dynamically built by the core. You can add a character easily, creating the right labels being all you need to do. Therefore, the only thing needed is to validate that the label exist before offering the possibility to perform an action.
And it's how he do it, implementing the character piece by piece. The greyed buttons replacing the need for a placeholder for every interaction none implemented yet. This permit him to have all the girls present right from the starts years ago, while still having nowadays some that need to be effectively implemented. This while having placeholders only for the scenes related to the main generic actions (like acquiring a new power or training) what is a really bad thing.
Like I said initially, if you need to rely on placeholder in what you release, then it mean that you haven't past enough time thinking your project. For a linear or almost linear game, it's half a problem, but for a pure sandbox one like Super Powered, soon or later it will lead to bugs in your game ; at least because of the lack of security tests.
Agile feature development not valid
Being in software development I'm used to
You must be registered to see the links
methods like
You must be registered to see the links
and
You must be registered to see the links
, with emphasize releasing features early, so they can be used earlier and thus create or safe money sooner.
Agile is bad, agile is evil
More seriously, I'll obviously not start the eternal debate, mostly because I don't care, it's not how development should works ; with "how" meaning "thinking that there's a paradigm that can apply to every project and context".
This lead to a question I don't have a definitive answer to : Can this be applied to this kind of game development ?
In one hand I would tend to answer "yes", because well, it's what devs do. Releasing their game piece by piece, adding not only scene, but also features, updates after updates.
But in the same time, like few of them have effectively knowledge in development, they have a really hard time to implement them retroactively ; they don't know how to build their code to anticipate the new feature, and tend to break everything when they do it. In top of that, too many lack of initial planing, and when the game will be finished, half of the features will still not be implemented.
But it doesn't mean that Agile paradigm can't benefit to the scene, in a way Super Powered is the proof that a similar approach is efficient. It's more the authors that aren't ready, than the paradigm that can't works.
But once again, you don't need placeholders for that. Build your code to react to both the absence, then presence, of the feature/content.
It's, more or less, what I do with my mods. As much as possible I validate that the original code haven't changed ; what technically is limited to the presence of a screen, label, variable and function. And if at least one entity isn't found, the whole part of the mod depending of it is automatically disabled, without possibility to manually enable it. This way the mod works without breaking the game.
More classic Project management is not valid either
A
You must be registered to see the links
processes like
You must be registered to see the links
will not work if there is a lot of learning to be done and the outcome of the project is highly uncertain, although the budgeted time and resources may have some buffers and flexibility to them.
I stop you there, the time and resources can't be budgeted ; at least not with a Patreon business model.
Let's say that I start my first game today. With my actual knowledge of Daz3D and my actual configuration, I can probably do 10 renders/day.
My game is a hit, after only two months I get $1000/month. I've enough to add some RAM and change the GPU, I pass to 15 renders/day. Six months on, I now have $4000 to spend on a secondary computer, that I'll dedicate for the renders, and my scene building skills have greatly improved, I need less time to find the right lighting, the right expression, pose and all. I reach 50 renders/day. And with the money left, I can buy the assets I need for the future of the game.
At the opposite, my game pass totally under everyone's radar. One year that I release updates, and I haven't even earned $1000 at all. My Daz3D skills have improved, but I'm still stuck because my computer isn't powerful enough to let me works on the game, do what I usually do, and do more than 10 renders/day. Plus those $1000 are too short, I still miss few assets that I'll need really soon.
Which lead to, yes, classical project management isn't for this scene.
When I talk about planing the making process of your game, it's a fluctuating planing. This scene after that one, between X and Y days to do a scene, this part have to be codded before I can advance this story arc, and things like that. But you've no effective timing behind this, because it depend of a context that will change regularly.
Plus, like most devs do everything by themselves, giving a strict process order isn't a good idea. Write the dialog first, then do the render, then integrate, then pass to the next scene. Ideally it's how it should be done. But, by example, sometimes you aren't in the right mood to build some scenes, so better works on the dialog for another one, than forcing yourself and poison your passion.
But, once again, do you really need to use placeholders because of that ?
Yes, you've one scene more that have its dialog done. But you also are the only one to know it, you've no obligation to add it to your release.
Profit to this advance to reward yourself ; you've done more than you expected, you're on the right track keep going dude, you can really do it. It's better for your moral than the, "what the fuck is this scene with just dialog", that would inevitably appear in the game thread if you release it as placeholder.
The stories here would probably fit more in the
You must be registered to see the links
genre as they share some stylistic and thematic similarities to the soap opera, like the
You must be registered to see the links
.
Not necessarily just soap operas. I don't really know for US comics, and it don't really apply to Japaneses manga, but in Europe, comics historically have the habit to put a cliffhanger-like at the end of the page. Not necessarily something that lead to a suspense, it's generally more on the side of "the page let you mid action". It's also a good way to see if the story was firstly released in episode on whatever publication (and to know what content was released), or directly released as book.
If it's directly a book, then it will happen at the end of every odd page. You'll not stop here, you'll turn this page to see the end of the action ; and like you've started to read the page, you'll continue, and also read the page at its side. And now repeat, you're again left mid action. And if it was a periodical publication, then this cliffhanger will happen at the end of each published part.
It's something that
Midlife Crisis started to do lately. No suspense in the story, no antagonist, but each update now tend to let you in the middle of a scene. Well, I'll play the next update, I obviously want to know what will happen.
Personally I found this method more effective than a cliffhanger that imply an effective suspense ; unless it's like in
Love and Submission, where we were left once with an emotional cliffhanger. It was a fucking great move that grown a massive emotional bound with the story. Side note, I really hope that
veqvil will one day achieve to deal with his problems, and then also be able to come back to effective development, he's a fucking great writer.
I'm just mention what logically seems to work for the VN genre, but everybody should do whatever they like.
Same here. I give a lot of advice, but the most important one is what I implied when talking about Agile : There isn't one method that works for everything, everyone, or every time ; and there's even less that apply for the three together.
Reader, my friend, pick what you want, it's how it should works. Whatever if what you do isn't "the right way". As long as it effectively works, then it's how you should do it, dot.
The
You must be registered to see the links
opening crawl is actually a form of
You must be registered to see the links
and it's origin is in the
You must be registered to see the links
.
It doesn't match to the NVL-mode as in that mode the text doesn't move.
Oh, but it can move
But honestly it would probably feel wrong.
The Intertitle is common for Silent Film, but also used for Medieval, Wild West and Fantasy movies, so it seems to used as a style element indicating Old or Other world then contemporary.
It's more used as an indication of "older time", but for the movie more than for the story.
Take someone that can travel in time, and goes to the future to film what happen there. Then he come back and edit what he filmed to make a movie, by obviously using the technology and methods of his time. Intertitle were initially used to give the same kind of retroactive indication ; whatever what you see, whatever if it represent, or looks like, the present or the future, know that it come from the past.
All this precisely because they were common in Silent Movies, therefore for the older, they refer to this time. Now it's a self fed bias for everyone who don't really know about Silent Movies ; you see it as having this meaning, because it had this meaning every time you saw it.
Then its meaning changed a little, making it be used as alteration of the reality.
By example, as used in
Blade Runner, it permit to establish an alternate universe that, whatever how evolved it can looks, have either regressed, or faced an evolution that wasn't consistent ; generally better tech without social improvement. Here, it carry a feeling near to, "what the fuck ? They have flying cars and still use those static texts on black screen, where they can have come to text incrustation ?" This being due to the anachronism between the world depicted, and the technology, already out dated, used for the narration effects.
But when it come to
Grimm, personally I think that they messed it. The font they used clearly show that they wanted to make it looks like if we weren't in reality, but the characters of one of the Grimm brothers tales ; looks, they're even writing the story right now. But the feeling isn't there, at least for me. It would probably have been better to show the text over a parchment ; even if historically it don't fit, it would have led to a better understanding.
The contemporary use is actually for conveying
You must be registered to see the links
and postal letters to the audience.
They aren't effectively intertitle ; there's still the "title", but not anymore the "inter".
They are full part of the action, even in Sherlock when they don't show a SMS, but the key frame of Sherlock thinking. They don't replace something (dialog for Silent Movies), don't establish a difference (
Blade Runner/
Grimm), nor effectively narrate something. In place, they extend the scene, giving it a new dimension, by providing us what should have been "unseen information".
Still, once again they have to be done right. In Sherlock, they install the simultaneity of the actions. When it's Sherlock thinking (it happened just once or twice if I remember correctly), it clearly express his multi-tasking ; he's doing something totally unrelated, and in the same time already searching for the answer to the problem. Same when Watson (in your example) receive a SMS, what establish clearly that times don't freeze for the characters that aren't on the screen.
But this works only because it don't stop the action, at the opposite of the first screenshot where the action is relatively frozen the time for the exchange to happen.
This said, I totally recognize that it's fucking hard to do, especially in a movie. In a game at least it all depend of the player, but in the movie you've to take count of the possibility to translate the text, and to let it on screen enough for anyone to read it, but not enough for it to become boring.
Yet, ideally it should always be done like in Sherlock. You start an insignificant action involving a secondary character on foreground, then insert the SMS exchange, focusing on the involved character, while the said action apparently continue to play on what is now the background.
That seems hard for the NVL-Mode.
It's hard for games in general. This for the opposite reason that make it hard for movies ; you don't know how many time the player will stay on it. Therefore you can't do the foreground action that continue on the background trick. Either the action advance automatically, and so risk to end before the player finished reading, or it advance manually, and the player will probably not notice that something happen in background.
If in top of that you decide to give dialogs to the said action, for it to be more noticeable, it's dead. In a movie, the spectator can decide to focus on reading the text, and the dialog will just be a sound that he hear but don't listen to. But in a game, there will be only reading and it will be :
- Read the received SMS
- Read a dialog line
- Read the answer to the SMS
- Read the new dialog line
- Repeat
More than one question/answer and the player will be totally lost, understanding neither the SMS exchange, nor the dialog.
In the end, in game freezing the story is, so far, the only way to go. But it don't feel too weird because, even in third person view, the player tend to fusion with the main character. Therefore, that the action stop when he read a SMS feel more natural, because for us also, when we read a SMS we stop what we where doing.
Although lots of game engines used to use Python as a scripting language, these times not so much.
Not just game engines, a lot of software including a scripting possibility tend to use Python. But I would say that it's a fad before everything else.
From, globally, mid 90's to the end of 10's Perl was THE language to know for scripting. Nowadays almost none of the persons who start their career know a single thing about it, preferring Python. The language is still usable, faster than Python, better than it for most administration task, object ready, and way more flexible, what is both a curse and an advantage ; it's only default is its Unicode support. But nowadays the fame aura past to Python.
Python started, and clearly achieved, to replace Pascal as teaching language. Since a little more than a decade, every student having learned coding at school is expected to know Python. This while on the compiled languages side, you can possibly learn C++, or in place C#, without having a single course regarding C. Python also have for him its rigid structure, what make it easier, not to write code, but to deal with the "hey, my code don't works, can you help me".
Put the two together, and it's the ideal language to add a script capability to any software. Professional know it already, while amateurs talk so much about it that finding help will be easy.
Honestly, except some variation of Basic, but it would then be way to limited, I don't think that Ren'py would have had such success without how easy Python can be to use. Compare it with RPG Maker, that don't use a too complicated language since it's JavaScript, and have, proportionally, way less authors that tried to do their own things.
Maybe this will change when
You must be registered to see the links
goes
You must be registered to see the links
and Renpy updates it's dependancies, as Renpy seems to be build on PyGame and PyPy should make that significantly faster.
They're still probably
You must be registered to see the links
to an effective transition. As for Ren'py, it have to switch to Python 3.x before switching to PyPy.
Yet, I'm not sure that it would be the right move. By itself Ren'py is probably too versatile and erratic, to effectively benefit from PyPy's JIT, and it would probably be the same for PyGame as used by Ren'py.
Take the Character clas by example. In practice it's
__call__ method is used a lot, but when you look at the code of the core, it's almost never used. And globally it's the same for the whole class. Therefore not only it can only benefit from an optimization at runtime, but also this optimization would be useless ; the process stop right after it, waiting for an input from the player.
At the opposite, even counting the prediction and the refresh, the code (inline Python block) present into a screen could be proceeded only time to time ; not enough to looks like an optimization is needed. Yet, it's what need the most to be optimized and what slowdown some games.
This said, my knowledge regarding PyPy's JIT are limited, so perhaps that it can still works.
But anyway, is this port really needed ? As I said, that you also implied yourself, for advanced use Unity or Unreal would always be better anyway. Except on Android, Ren'py is strong enough and fast enough for what he do. As far as I saw, when there's a slowness it's almost always the fault of the dev.
The only bottleneck I found so far due to Ren'py itself is the way its
viewport works ; it process the events for every entries, even when they aren't shown, not even partly, on the screen. Yet, on the 10 years old computer (1.25Ghz CPU), I used at this time, it was a problem only when you had an action when the entries are hovered, on only when you've more than 400 entries.
When you think about it, it's already impressive. Used correctly, Ren'py can check 400 events every single time it's notified that the mouse have move. It can goes to what ? 400 events 50 times by seconds, something like that. For an engine that lack of optimization, and is an interpreted language on top of one of the slowest interpreted language, it's good performances. Especially when you take in count that, if a game have a reason to ask this much to it, then it should anyway have been done with an engine less dedicated to VN.
