We’re done with This Game is a Business Card. Looking back, it was even more of a reward journey than I would ever have hoped for.
This Game is a Business Card is made, like most games, of many parts. The user-facing code is written in node, compiled for web-browser JavaScript, but the story is written in Ink. I was very keen on the story being written in Ink, and I was not sure it would happen.
The Tech
Ink
When I arrived, the team really wanted to use Twine but I tried to make the best case I could for Ink. I also explained the basics of the three-act and the five-act structure of storytelling. The team saw that organizing the story around a five-act structure would in fact be easier than not knowing where the story was going to go and they ran with that. None of my individual contributions made it, but the fact that they took my biggest one made me feel hugely included. Then, I really pushed for Ink. I expected them to say know. It is still less known than Twine, but I was absolutely sure it was better. I sent links to videos of its creator, Jon Ingold, and Ink got chosen. Shortly after, the main writer got convinced that was the right decision.
To start with, it’s interactive fiction, my all-time favorite genre. And, not only that, we used Ink, which I still think is the best tool to make IF nowadays. Ink proved itself many times to be invaluable. The two main key ways were:
- Arun who’d never coded before found it easy enough to write a story that was interactive. First, it was only somewhat interactive, but he then managed to use Ink’s more subtle abilities with more and more ease.
- It was blissfully easy to Integrate Ink into JavaScript. At first, there were a few hurdles getting Ink to work with Node, but once that was done, everything was incredible smooth.
- Once we needed some serious strategy, Martin just went into the Ink script and optimized the strategy aspect until it was just right. I never had to adapt the code at all. This is a good thing.
- When the story got long, it was trivial to separate the acts into separate files that easily compiled into a single structured story file. This also came from the fact that we had organized the story properly.
Vue.js
I really wanted to use Vue.js as the framework. It is not a game framework, but I didn’t want this to feel like a classic game. It had to feel like something that was more akin to a web app in the sense that it was more immediate. Games have a media layer in a way. They are more removed. Web apps seem more present. You can tell that the text is ready to be selected. It feels just on the surface of the page. I wanted it to be like that. That the buttons were real web buttons. There was also an advantage with the way Vue allows for data binding. Just changing the value of the data would be enough to update the onscreen display. This is much simpler than most game code, and efficiency is nothing to be laughed at.
With this, we got all of the effects we needed. The game was simple enough that CSS transitions provided us with the fades and pans that fit our requirements and, even better, Vue let us access them easily.
The Game
The Objectives
In the end, the game ended up being about running a game company and having to launch a new title under some pressure. It was, after all a promotional game for Tiny Hydra that showed what our services were about. There were four objectives, some more explicit than other:
- Make a profitable game
- Keep your finances afloat
- Keep the team’s morale high
- Release on time
As it turns out, any one of these objectives is trivial to accomplish. Anyone who plays the game once can easily reach all of them. Reaching all of them, however, is not as easy. And making a profitable game at the cost of ruining people’s lives is not an ending that we would qualify as successful. The opposite, people who had fun making a game that didn’t sell is not a great ending either. Can you hit all of those targets? Which platforms should you launch on? PC or console? How about the brand new console that’s not even out yet?
We had a lot of talks about what the next-gen console should be. We decided on the Syga Exodus, which naturally comes after the Sega Genesis.
The Characters
I gave some guidelines to the text and the characters: no text should be only informative, it must always carry the identity of the game with it. And the characters must all have a strong identity. It took time, but I really think we managed to make characters that had identities of their own. I’m particularly fond of Lele, on the right in the illustrations below. “Lele”, or 樂樂 (traditional), 乐乐 (simplified), is based on a Chinese girl I met when I was a high school and took a trip to China. (This is the best way I could get Google Translate to offer a pronunciation for her name.) The name means “giggle.” The way it turned out, our Lele ended up always being grumpy, sort of like Rosa in Brooklyn Nine-Nine. You did not want to mess with her. I really wanted her to say with her deadpan face when she met a new character later in the game, “Hi. I’m Lele. It means giggle.” But everyone else thought it was too on the nose.
The interface
I did everything I could to make the interface follow the instructions in the Ink story. I think I was pretty successful. Often, when something was needed that was simply not there, it could be implemented very quickly, sometimes in minutes, although not always.
There were two statuses that we decided to show onscreen somewhat directly. One was the budget and one was the morate. The budget would be shown in the corner after the concept was brought up in conversation. It would change an icon at the bottom right of the screen. The morale would change the overall illustration of the office. I must credit our artist Yavanna for what I think are amazing illustrations. For me, I did what I always advise people to do: better than clever code, choose the right framework.
Reflecting status changes in game
I have very little to do to reflect status changes in game. All the statuses were kept somewhere in the ink story. Ink allows variables to be watched. When a variable is watched in Ink, I updated it in JavaScript. Then, when a variable is updated in JavaScript, its bound value is reflected in the HTML. That was it. I never needed to do anything more.
For the budget, for example, there were six levels. I had a map that linked each level to a file name for each of the six illustrations. Each time the budget level changed, the JavaScript value of the budget changed automatically. That meant that the file name for the illustrations was automatically updated based on its corresponding value in the map. The main thing is: none of this required any assignment on my part. It keeps the code short and readable. (But still, as always, fully commented and documented.)
Geographical difficulties
One aspect that got in the way of the making of this web game was that, while most (but not all) of the team was in the Netherlands, I was in Paris. Still, the team was definitely a mix of cultures. In the Netherlands, there were some Dutch people, some Brits and the man who was running the company was an American. We also had some contributions from someone who is currently living in Germany and who I think is British as well. Creating a multicultural world was one of the goals of the game and while our cast of characters was definitely more diverse than we were, the fact that many of us approached many things differently was absolutely an asset. That said, it would have been nice to be geographically located closer together.
Final thoughts
This Game is a Business Card is by no means the most high-tech game ever made, but it’s still something I am truly proud of. I find it ingenious, lighthearted, and colorful. It carries strong meaning through gameplay, which many games struggle to do. It has both good content, good mechanics, and a good interface. I feel like I took part in all of that, but that I am not fully responsible for any of it. That’s a good thing. Good games come from collaboration. If one feels that even one aspect of the game comes from one person alone in their tower making it up on their own, something is probably wrong.
The fact that the tech was lightweight allowed us to keep the development process nimble and to make changes quickly all the way to the end. The founder of the game studio Inkle, Jon Ingold, praises text for that reason. His current games are not presented as graphical, but their contents are still based in text. They can be modified quickly to keep the design flowing. It does not mean that games that require complex and heavy production are the wrong way of doing it. Just that there is true value, I think, in also, sometimes, keeping the methods of production fluid and flexible.
Emmanuel Eytan :: Game Programmer 