N1RV Ann-A Devlog 2: The weight of a text-heavy game

Posted on by Fernando Damas

 

On August 2014 VA-11 Hall-A gave its first baby steps into a full-on release. Prologue, a side story meant to tide people over while we finished the full product, was finally out in the wild. During this release I was on vacation with my family in Margarita, an island north of Venezuela. I took with me the laptop I bought with our first advance payment from Ysbryd and decided to work whenever we were back into the residence we rented.

At this time we just jumped ship from Ren’Py to GameMaker Studio. Tided over by the idea of easier console porting (Vita in particular) and a couple of technical ceilings that we encountered with Ren’Py (Specifically that the pixels didn’t look crisp unless you were in full screen and freezes whenever we tried to use drag-and-drop). At this point we were asked if we could have a playable build in Game Maker, and I complied, confident by how I was able to port over the mixing mechanics from Ren’Py into GameMaker.

Like these stories usually go, my confidence got trampled upon time and time again.

The bane of my existence in particular was the lack of a text framework. I didn’t even know how to begin making one. I found one or two in the GameMaker marketplace and tried desperately to make them work but it just didn’t happen. I was able to port the mixing mechanics because I MADE those, I started with a very rudimentary idea that I built upon and I just had to find equivalences in the new language… but I didn’t have that with making text happen on the screen.

I think that was the first moment in my life where I felt true and undistilled despair. An uncontrollable anxiety attack that only got worse as the titanic task that we set ourselves upon dawned on me. I didn’t know jackshit about programming! I was that kid that just learned how to play Yesterday on the piano trying to play with the philharmonic. Was the rest of development going to be like this?

But I soldiered on and a very crude build came out. We’d improve upon that build without changing the story much and it eventually became VA-11 Hall-A Demo, an event build telling the story of a girl called Anna trying to get drinks in the bar.

Contrary to what you might think from the way I tell things, I actually hold that whole experience in high regard. It gave the perspective I needed to take on the development of the game properly, and my effort to make sure that Anna’s story got out in some really early form made me really attached to her. If you know the words that appear on Anna when she glitches out, this whole story might give you a perspective on what those mean.

A (smug) smile worth protecting.

But personal drama aside, the whole situation is actually symptomatic of a bigger problem for budding game developers. If you wanna make something you either hope to god all your previous knowledge lets you deduce how something works or you buy an asset from a marketplace. But the middle ground of those that don’t have full games under their belts and want to make something specific get constantly neglected.

There’s very few resources on how to make a point and click, how to make an inventory system, an RPG battle system, etc You either get the full asset, a prepackaged engine specialized on that, or scrap by hammering your head for a year figuring out how to make specific stuff.

I, for one, don’t want people to feel like me on that day. Grasping your head in desperation of not knowing what to do and the clock ticking, the light of the laptop on the backyard table taunting you, wanting to scream into a pillow to let off some of the tension but it’s 1 a.m. and everyone’s sleeping in the same room because they tried to fit 9 adults in an apartment of 4.

So today let me share the basic idea we used in making our current text framework. I’ll give you the core ideas, a base that you can build upon and I’ll explain some of the stuff we had to consider and fix in the middle and long term. Hopefully, by following our train of logic you’ll grab lots of much-needed experience and be able to adapt it to your specific projects and engine.

Who knows, we might even share our dialog framework in the future too.

So let’s go from the very core basic: We need to show text. Every prepackaged engine out there (Unity, GameMaker, Unreal, etc) has a built-in way to draw text on the screen.

But we also need to show more than just one line of text. What we do here is:

  • Make a list with all the lines we need to show.
  • Make a variable that has a number starting at 0. We’ll call this curtext.
  • Add the thing that shows text and make it so that the text it shows is an item on the list whose position is equal to curtext. Engines usually let you take text from variables, databases or other stuff and use it.
  • Add something that makes it so whenever you press a button it adds +1 to curtext.

What happens here is that the game will have various lines and cycle through them with the pressing of the button. It starts at 0 (in Lists and other stuff 0 is the first element), with each click it adds up 1 making it go to the next one and so forth.

Let’s explain it with shitty drawings!

You might also need something that tells the text thing to be destroyed once it exceeds its limit (you can check for the size of lists) and something to create that text thing on demand. The solution we applied was to make a script where all the text is housed and another different one where all the text-drawing things are housed. That way we can call the text-drawing thing and feed it text from the other script whenever we need to call it to action.

In the case of Valhalla it has a “controller” that keeps tabs on if the text-drawing thing is still on screen. If it’s not it checks the status of the game at that point, if no special situation is indicated, it creates the text-thing again (we’ll address this specific part shortly); otherwise it might check and find that next comes mixing (the mixing interface pops up, the text thing pops again once you press serve), the jukebox (jukebox pops up and new text is created when you press Done), going to the break, finishing the day, etc.

Going back to the text framework, the next step is adding the “typewriter” effect (making it so the text appears gradually instead of all at the same time). A simple solution to this is a “substring” sort of command. “Substring” in Unity lets you grab a section of a string, usually indicated by two fields (for example 0,5 to indicate that it will show only the first through sixth characters of whatever text you indicated), so you do the same thing as with the text advancing but instead of advancing with clicks it advances with a timer.

At this point you’ll start to find wrinkles to fix. For example you might need to make it so that if the text isn’t fully displayed it skips to the last with the click instead of going to the next line, you might also need a way to add line breaks so the lines don’t overflow… but by that moment you’ll have the bare basics and have a better understanding on how to work things out next.

One of the mottos I repeat a lot is “fix things one at a time”. You can worry about a hundred problems at the same time and despair when you don’t see the number decreasing or focus on one problem and actually see the number steadily decrease. And this translates nicely into programming. Think of your features one element at a time instead of trying to do everything at the same time.

Now, for all the grieving that we had in the end with VA-11 Hall-A’s framework, the process did provide us with a flow we could build upon. But first, let’s talk about branching.

On second thought, let’s not talk about branching, ’tis a silly thing.

Dialog branching comes in two kinds: Active and Passive.

Active is the dialog branching that takes place thanks to player actions, like a choices menu or VA-11 Hall-A’s mixing.

Passive is branching that takes place because of an earlier change in state but without direct actions from the player at that moment. For example, if a character reacts to an earlier choice taking the dialog a whole different route, that’s passive branching.

Understanding this, one of the earlier issues we had with VA-11 Hall-A was that the framework didn’t have a way to process branching, so we had to make up a way by making the framework reappear as indicated by another script. This method however, proved cumbersome in the long run and, if you knew when and where to look, there’s a very slight delay on the text reappearing when it branches outside of regular mixing.

So one of the first fixes was to find a way to avoid this. To summarize the solution, since the game wouldn’t see any changes of state between active branches, we just made it so that the framework would save all the text taking into account branching and such up until the next break in the script (instead of breaking when the branching happens).

The second thing we wanted to improve upon was style. You see, the “typewriting” solution we mentioned earlier has a key limitation: It limits how much you can actually customize the way letters appear. Since it’s just taking the same text but changing how much of it shows up, there isn’t any actual way to spice it up as is, no shaking text like killer seven, no crazy colorful text like Katamari Damacy, no fading in text like Steins;Gate.

The solution to this was making each letter an individual object. For those unaware, an “object” is basically a container that has scripts and such. For example, in VA-11 Hall-A the shaker is an object, so is each character and each button. Anyways, making each letter its own separate object gave us lots of freedom, since we could just make a letter and then customize exactly how we wanted it to appear. Each letter, in addition to everything that would make it a letter would also have a script attached determining how it behaves.

Unity actually helped us with this. In Unity you can determine the… “physical” space of each letter, this let us make a script that determines the position of the next letter based on the size of the font and any changes of size in the middle of the text.

I should also note that this particular function came to be because the dialog system actually started development for NEXT GAME befoe N1RV Ann-A came to be even a concept.

The final element, and the most important one was to make the workflow better. After all…

“If VA-11 Hall-A’s development was fueled by a hot-blooded effort to make a living out of whatever scraps we made with the game, N1RV Ann-A’s development is fueled by a cool-headed effort to not relive the same pain that was VA-11 Hall-A’s development as a whole.“

So a dialog in N1RV Ann-A looks something like this in code

Actually, it’s more like 30% of what just one line of text entails, but bear with me for the sake of demonstration.

But like this in script.

Upon the revelation that we could use tools and that those tools didn’t need to be made inside the same game engine, I devised a syntax that would make it easy to write a LOT of words with relative ease. Make it easy for the user and then pass it through a parser so it’s easy for the machine. This would also simplify the translation process, we can give those tools to translators so they paste the script, pass it through the parser, put it into a game folder and be able to test right then and there. By making translations effectively reworkings of the same tools we’re using it would allow translators the freedom to merge or divide specific lines instead of being limited to just using the same “space” limitations as the original text.

Like I mentioned in the last devlog, our main priority is to work in the most comfortable way we can muster, to churn out content and futureproof the game as much as possible.

We’ll probably share more about the tools we’re using in the future, but hopefully this whole article gives you all a nice point of reference if you ever want to start making narrative games on engines not specialized on them.

Next month we’ll talk about the mixing mechanics, how they came to be and how they have evolved up to N1RV Ann-A.

And in this month’s highlight we keep spotting trailer faces with Wakana!

She’s a Lilim and the second wife of a filthy rich divorced man. What stories does she have? How did she meet her husband? Does she have a stepdaughter? Is she afraid of Chinchillas too? Is Sam afraid of Chinchillas? Why does the caged bird sing? All of these questions and more will be answered in the full game!

Also, let’s continue with more overdue questions.

Humans and human relationships are just really really fascinating, and we love to explore as much of them as we can.

Our best advice is to make sure that you make clear that whatever point you’re exploring is but one of many facets instead of the only one. Think on the idea that in life there’s no “heroes” and “villains”, that every person sets out to do what THEY think is good (even if their idea of good is harmful or dangerous). That said, there’s people out there that will do all the mental gymnastics in their power to make your work fit a convenient narrative to them. So you might’ve made a story where a character happens to be gay and all things don’t go like a dream for them, that’s enough for some to say that the work is homophobic.

Do your best in avoiding making people come off as cartoonishly evil or cartoonishly good… but be aware that it still won’t stop people from deriving some anoyance out of it on principle.

So let us talk about translations, there’s a couple of points to address here:

  • This year has been a busy one for Sukeban Games, on top of going full throttle with the development of N1RV Ann-A at the beginning of the year, we’re currently doing some… reestructuring. I can’t divulge details yet but the important part is that we’ve been working at half of our proper manpower and I currently have no access to the work station where all the translation-related files are stored.
  • We’re aware of the spanish fan translation, and the italian one, and the french one, and so on and so forth, but due to the above situation we can’t really add them to the game just yet.
  • We’re really sorry about the delays. We don’t want the teams’ effort to go to waste and making the game easier to access for a wider crowd is something we’d be all up for.
  • We’re also sorry about not answering this particular point before but a) As mentioned we can’t divulge stuff just yet and b) We can answer this sort of question a thousand times and still get snide remarks and passive-aggressive comments on year-old posts we made to anwer questions about the absence of specific languages.

We actually answered WHY we didn’t release VA-11 Hall-A in spanish too almost a year ago… and it hasn’t stopped people from repeating the question in an increasingly indignant manner or answer to that tweet as if tapping your fingers inpatiently on a table.

So I beg of you all, please have a bit more patience. We’ve come accross quite a few spanish comments treating the lack of our “native tongue” in the game as if we released an incomplete broken experience or something. It doesn’t help that we’re spiteful little shits by nature and I’ve already felt once like saying “that’s it, we’re releasing spanish way after the others” just to spite every single commenter.

And yet I know not everyone’s like that. Cooler heads will prevail and that spiteful statement won’t come to pass.

But by god… some people are pushing it.

8 thoughts on “N1RV Ann-A Devlog 2: The weight of a text-heavy game”

  1. Thanks for the writeup! These are always a joy to read. The way you go into the small details about your process is something I live for in finding my own process in game making. Cheers!

  3. I think charcters in N1RV are more mature(in terms of age) than these in VA11 based on the info released, at least two were married. I can’t wait to play the new game. Plus, thank you for sharing the experiance about game developing!

  4. Reading these things is really interesting. Boy am I excited.
    >Game’s still 2 years away
    life is suffering

Comments are closed.