Been working on the prologue for Tinselfly. Here’s what it looks like right now:

The idea is, it’s the sort of world-introducing stuff you might get in a start-of-game text crawl or cutscene, but playable (if only in a walking-simulator sort of ‘playable’ way).

Filling out details in each of these scenes has been a bit of a slog lately. I’m having the hardest time figuring out how to move this forward, and I feel like I don’t know how to evaluate the worth of what I’m making.

I think I’ve figured out why that is: I haven’t defined my goals properly, so progress towards my stated goals doesn’t really feel like progress. If you asked me a few days ago, I’d have said the goals of this opening were:

To present a quick, whirlwind history of the Iris, a ship which features in the game’s story;

To make it abundantly clear to the player that the story of Tinselfly will be presented in a unique, stylized, theatrical way, which includes things like playable crossfades and montage sequences.

These statements are true, but as a stated goals, they’re not really my goals for the opening. They also don’t help me come up with specific environmental details, player actions, dialogue or voiceover text. The goals as stated above feel more well suited to a tech demo than a story opening, and Tinselfly does indeed feel like a tech demo right now.

My real goals are more like this:

To quickly and memorably introduce the player to the Iris, showing different people’s relationship to it during different periods of its life.

To make the player feel a sense of wonder and joy at the Iris’ construction and service, and a sense of loss at its destruction.

The history is still there. The bits about a stylish presentation have been removed; that’s the strategy for being memorable, not the goal itself.

Most importantly, these goals are about people and story. If making decisions with the old goals in mind were producing something tech demo-like, then my hope is that making decisions with the new goals in mind will help me add details that make this feel like a story opening — which, of course, is the whole point here.

* * *

So what are the next steps here?

Generally, I think ‘quick and memorable’ are already taken care of; the montage format is pretty unique to games, and the whole sequence, even with more details, shouldn’t take long for the player to complete.

So I need to concentrate on:

• Showing how people in each of the scenes relate to the Iris, rather than just showing what they’re doing.
• Then, taking the Iris away from the people — and the player — that they might feel a sense of loss.

Specifically, here are some ideas:

• Construction scene. I’m not sure a lot needs to change here, just more details, more workers in the background, some chatter about the work.
• Launch party. Needs more people, excitedly watching the ship launch. A friend brought this up a while ago — the ship is very static, and may not even register as a ship since it’s such an odd design. It needs to move, and the launch needs to be mesmerizing. Extras need to stare in slack-jawed wonder at the ship, and the player has to believe they feel awestruck by this.
• Mushrooms. Once the ship is high in the air, fade to it landing on the mushroom world. Excited travelers exit the ship immediately after it lands. And the person flying off into the distance?… I like the transition from that to them flying through the oppressively lonely hangar; maybe the area the player is in is a jetpack rental place? Something… maybe… sorta… like that. I dunno.
• Mothball. During the mushroom bit, the player follows the person in the jetpack. Then after the crossfade there needs to be a depressing gate blocking the player’s path. The player needs to think they might follow the person in the jetpack, and get stopped abruptly.
• Taking it away. This part hasn’t been done yet, and I probably won’t do it for a while — in this section, it flashes to a scene the player will play for real later on. So I need the details of that scene to be nailed down before I do the prologue version. But broadly speaking, it might be something like this:
  • The player suddenly finds themselves in the middle of a spaceship battle happening around the floating city.
  • Robin (the lead playable character) rushes out of the Iris to try to rescue you.
  • You run towards the Iris.
  • Something bad happens and Robin is thrown clear of the ship. At this point, the camera switches from first person to over Robin’s shoulder.
  • In the distance, you see the Iris get pummled.
  • Fade to the charred remains of the Iris at the beginning of the story proper.

Still a lot of details to fill in here but I think I’m on the right track. Just have to start adding details in-game now and see where they take me.

So now that GDEX is over, it’s time to turn my attention to a Mini Maker Fair right here in Cleveland, next month.

As before, I have no desire to rush out features just for a demo–my goal is still to work on the transport-whirlwind that is the beginning of my game. Thankfully, I do have a variety of things to work on in the next four weeks, all related to that goal:

Add even more transportation links.

The sequence of events in the beginning of the game is supposed to be as follows:

1. Start in the ruins of a city.
2. Find a handheld VR-like game, and play it for a couple minutes.
3. Take off the headset, and find yourself in a farmhouse instead of the ruins.
4. Take a gondola from the farmhouse to a balloon.
5. Take the balloon to an outer-space city.
6. Take a wormhole from the city to another planet, collecting an inventory item there.
7. Return to the outer-space city through the same wormhole.
8. Watch a spaceship land on the docks at the outer-space city, and board it.
9. Watch the floating city recede into the distance as the ship flies off with you on it.

All of this involves insanely complicated behind-the-scenes level and camera juggling to make the transitions seamless, like you’re really traveling, but 1, 2, 3, and 5 are basically done (though 1 clearly needs some cleanup, having watched people play it at GDEX, and 5 has a couple visual hiccups that irk me).

I might be able to knock out 4 or 6 in the next four and a half weeks. 6 would be especially satisfying for me since I love the idea of walking through a wormhole, and it would probably be memorable for players. And I’m pretty sure I can implement it quickly. However, that would require me to model your destination, and have it be of a similar level of quality as my existing environments… I would need a very clear, specific idea of what that area will look like in the next couple days to knock that out in time.

Even if I can’t make that area in this time frame, it still makes sense for me to quickly come up with a design so I’m not wasting too much of my time on it.

2 would, surprisingly, be harder to implement… though it doesn’t add that much to the overall ‘feel’ of the demo: you’ll just spend an extra 10 seconds riding on a swinging car. And, again, I need to do lots of modeling: the gondola, cables holding it up, and the station it goes to.

Fix bugs.

I should, of course, start fixing all the bugs I found at GDEX. Having better gamepad support is probably the best, quickest thing I can do towards making the beginning more playable. Fixing the swordfighting would ease the awkwardness of having to tell everybody, well, this part is a bit wonky but I’ll guide you through it.

Make it feel right.

I can also focus on the storytelling aspects of Tinselfly. Specifically, I can:

1. Continue cementing details in my whole-game story outline.
2. Make my first few minutes feel more like the beginning of a story and less like a tech demo.

Like the bugs, I’ll probably be doing 1 no matter what. But 2… 2 is interesting.

See, I don’t know what my game feels like yet. I can talk about how I want it to feel, how I want the puzzles and environment traversal to do all the storytelling, I can talk about my approach… but it’s not something I’ve experienced myself, and it’s not something I’ve ever tested with others. If I can start on 2, it will greatly ease future work, as I’ll have a more concrete sense of how other scenes might play out and need to be designed.

I’m kind of leaning towards concentrating on this, with little bits of everything else: the more varied my work plans are, the more efficiently I’ll work, so it behooves me to try to look at everything I’ve listed here, if only for a short time.

And hopefully by the Mini Maker Fair I’ll have a better sense of what this project is all about–which is great for me and my audience.

…or, How I Learned to Stop Worrying and Love My Buggy Demo.

I was really reluctant to go to GDEX and demo Tinselfly this year.

My swordfighting demo–which I’d been showing basically unaltered for the last couple years–was in significantly worse shape than it was at last year’s GDEX, the last time I’d demoed my game. I’ve been busy rebuilding big pieces of Tinselfly to be more maintainable and efficient, and the demo broke because I completely ditched a couple different third-party tools it was running on… and I never fixed it.

I bailed on MatsuriCon because I had no demo.

I bailed on IngenuityFest because I had no demo.

I seriously considered bailing on GDEX.

See, my demo wasn’t really part of my game proper. It was a standalone thing I threw together for some expo years ago just to show my sword fighting mechanic. And the more I worked on it, the more I wasn’t working on finishing real game levels that would be in my final product. It pained me to miss out on MatsuriCon and Ingenuty, but I just couldn’t justify fixing the demo. I needed to move the project forward.

So about a week before GDEX, I decided I’d just have a gameplay-light demo and show what I’ve got so far with the beginning of my game.

Transportation is a big part of the world and story of Tinselfly. You work in a shipbuilding town. The plot revolves around the decline of the shipbuilding industry due to new transportation technologies. Your character loves spaceships and the idea of space travel.

So the beginning of my game is all about transport: you’re supposed to start playing a game-in-the-game, stop playing and wander your childhood home, take a gondola to a balloon, take the balloon to a floating city, walk through a wormhole to a bazaar on another planet, jump back through the wormhole, board a big spaceship and fly off–with no loading screens, all in the first 10 minutes of play. A veritable whirlwind of transport.

The opening scene as designed would really be the perfect demo for showing off the environments I’ve built for my game — and I was much of the way there. I figured I could get just one more of those transitions working in time for GDEX — and I did, the morning of.

There was very little traditional gameplay. You could wander, you could pick up a few objects and hear your character comment on a few others, but the gameplay was limited to a rather old, rather buggy first pass at rewriting my old sword fighting stuff.

And this was a good thing.

* * *

From a logistics standpoint, things went great this year. This was the first year I brought an external monitor and gamepad, so that visitors wouldn’t see my laptop–it was more inviting than just having a laptop sitting on a table.

This also allowed me, behind my table, to see what the player was seeing, as the external monitor and laptop screen were showing the same thing.

Sadly, my gamepad support was terrible; the game is really designed for keyboard and mouse. But I was able to walk everybody through the most unintuitive bits of my interface.

* * *

I wandered around the expo floor a lot more than I did in expos past. Sure, that meant abandoning my demo for long stretches of time, but I’m really glad I did it. Seeing the creativity of other people’s works, feeling their enthusiasm, learning from them… that’s in many ways more important than showing off my own stuff.

I probably wouldn’t have tried wandering so much at the beginning of the expo if I thought my own demo was any good to begin with.

* * *

Tinselfly was never supposed to be about the unique visual sword fighting mechanic. I only concentrated on it first because, well, it was easy to talk about and demo and point at and say hey! this is what makes my game unique.

But Tinselfly is really about telling a story in a fun, unique way that relies neither on cutscenes nor static environmental details. And my level designs are supposed to be a big part of that. The transitions from location to location are a big part of that. This is what makes me excited about Tinselfly.

So in not having a particularly robust sword fighting demo, I was free to talk to players about what really excited me about the project. And I think my excitement showed. Players at this year’s GDEX seemed a lot more engaged, asked a lot more questions, and stayed longer at my demo than they have in the past.

On Sunday morning a highschooler was trying to tell me he thought my game felt like it could be ‘more’ than other games when it was done: more than the sum of its parts, perhaps.

I think that was the best compliment I’ve ever gotten at a demo.

This weekend, I demoed Tinselfly at IndieCade East. It was only a two hour slot, but wow did I get a lot of feedback — I got way more traffic there than I got at other, all-day type events I’ve done before.

It’s… a lot to process.

And it needs to be processed; I should neither follow every suggestion everyone made, nor forget what was said and done in those two hours. And, in fact, if I’m thinking in terms of following-or-not-following suggestions, I’m probably thinking about it wrong.

the audience

I’ve demoed Tinselfly maybe four or five times now, but this event was new to me in that it seemed entirely populated by, well, people who were really into video games. Most of the events I’ve been at before were not specifically game related: they were more family-oriented fair type things where each exhibitor table was showing very different things that might broadly appeal to random people walking around a fair.

So at first the crowd at IndieCade threw me off; they were giving helpful comments, but they were different sorts of comments than I was used to. In the future, I should try to get to know the individuals playing my game just a little. If a person who’s, for example  into highly competitive games gives me a comment, that context is important. In  many ways, the comments people give are less important that the unfulfilled expectations the player had, that prompted the comment — like, the expectation that there might be different weapons in my game, or leveling up. Which there won’t be.

I can’t (and shouldn’t try to) meet everyone’s expectations, but at the very least, continuing this example, I should make it clear from the beginning of the game that there are no weapon or skill upgrades; that character advancement, such as it is, happens in a fundamentally different way than most games. That’s something I need to communicate very clearly.

bugs

Thankfully, there weren’t any outright bugs anybody discovered that I didn’t know about already. However, it was still interesting and useful to see how the bugs manifested themselves — if at all — during the demo.

For example, in the very first scene there’s this staircase where you can walk through railings in the middle of the staircase, and you could walk off the edge of the staircase, which had no railings on the edge at all. And nobody walked through those railings or off the stairs, not even this one guy who was specifically trying to break things. I was kind of surprised.

So seeing which bugs came up and how often gave me some clues as to how to prioritize fixes for everything.

attention grabbing

There’s a part in the beginning of the demo where the player loses control of the camera briefly. One player really didn’t like that, and to be honest, I don’t like it any more than he did. It’s a brute-force solution to the problem of figuring out how to draw attention to things you want the player to notice.

In general, it looked like I really, really need to work on directing the player’s attention. The most egregious failure was that when starting a sword fighting duel, players frequently looked away from the area where their opponent would appear, before their opponent showed up. And then it wasn’t clear what to do because the opponent wasn’t visible on screen.

I… don’t have any specific thoughts on that right now. Just something to think about.

style changes

As you’re walking down those railing-less stairs, the point of view changes from third person to first. Many players stopped immediately when that happened, thinking that they’d accidentally pushed some pov-switching key.

I want the presentation to change based on the needs of the current scene; I think that’s an important storytelling tool. And I want the player reminded as often as possible that they’re playing a character with her own personality and goals and body. Among other things, that means being third person in open spaces and first person in confined ones.

But if players are getting confused by the switching, that’s a problem. I need to make it clear what’s happening, and more importantly, why.

I’ve started implementing a dialogue system for Tinselfly, based in large part on the keyword-based dialogue in Ultima V.

The basic idea is, when you engage an NPC in conversation, you’ll type in single words and, if the NPC you’re talking to recognizes your word, they’ll respond with a single sentence, or maybe two, of dialogue. It’s not really a tree; nor is it a text parser; it’s more just a list of stimuli and responses… though certain words could lead to short trees a couple levels deep. You’ll learn new keywords to try by paying attention to the exact words your conversation partner is using.

(You can see every scrap of dialogue for Ultima V at the Ultima Codex. Most characters… don’t have very much dialogue at all.)

Yeah, it may seem a bit weird and archaic, using mechanics from a game made in 1988, but I think it has potential.

* * *

Dialogue makes me nervous. I’m not, you know, a very talkative person. I only get like three quarters of the dialogue in movies. My understanding of dialogue and dialogue writing is kinda limited. But, I’ve ordered a book on dialogue writing for written stories, and my wife, awesome published author that she is, will be helping. So I’m feeling a bit more comfortable now.

I’ve had to take a break many times during this project to learn new technical skills that I have to have, to complete this project. Dialogue is no different. I don’t have the skills I need here, and I either need to learn them or find people who can help.

* * *

It may seem backwards, but now that I’m building this, I’m getting a clearer picture of what I want. So here are my goals, and how I think this system might work.

• Conversations should be short. In addition to the shortness of the rapid-fire stimulus -> response structure, I’d like a mechanic where your character tires of conversation quickly; she’s not a very social person. So the more you talk, the more energy you lose.
• The player must not be encouraged to exhaust all possible options during conversation; I want them to think about what is worth saying and what isn’t. This could also be solved by the conversation fatigue mechanic — and the emotional weighting thing below.
• The player should be encouraged to internalize the idea that specific words and concepts are pretty important to the story. By making the player remember the keywords and manually type them in, I think I can do that here.
• The player should develop a sense that some words carry emotional weight for their character. Certain words you hear should cause your character to gain a positive or negative status effect. Certain words you type — whether or not you press enter — will cause you to gain a status effect. And the same should go for the NPCs. You should learn that there are certain words you just shouldn’t say around certain people.
• The player should feel that her character’s close friends are just easier to talk to than other people. I could have less of a conversation fatigue penalty with certain people. I could also have a mechanic where close friends can essentially read your mind — they can react to your typing words before you press Enter on them. Could get annoying if done wrong, but I think it’s worth exploring.
• NPCs should be able to strike up conversations with your character, of their own volition. I’m not quite sure how this would work, unless they’re asking simple questions where it’s obvious what exact words to use for answers you might want to give.
• If you hear two NPCs talking to each other, it should feel like the NPCs are using the same dialogue system you are. Which I think I can do by, well, using the same code, with NPCs picking sorta-random keywords to use on each other.