[GO VOTE FOR IT]

Big updates! Sorry if this post gets too many exclamation points, but in all my years making games, I’ve never been this excited to announce one!

The game is now called A Case of Distrust. It has its own website. And, in order for it to be successful, I need to get it onto Steam, so please, if you have a valid Steam account, GO VOTE FOR IT! (here if you want it in browser, or here if you want to open the Steam client)

What’s changed since I last updated you? Quite a lot! I’ll get to most of that in future posts. But the biggest change: you’re no longer solving multiple mysteries — it is A (single) Case of Distrust. That sounds like content has been cut, but that’s not true. The game is still the same length, and very similar, but with various characters and plot points shifted around. I just realized the story itself was lacking any significant punch because no characters took long enough to develop — you’d solve a case, then mostly move on. Instead, all the characters and writing have been woven into the same mystery, giving more time for intrigue, a heightened climax, and greater satisfaction. The story is more tightly tied to my main character and the themes surrounding her. I can’t wait for you to play it!

I’ll post future, more lengthy updates soon. But for now, please vote on Greenlight if you’d like to see this game!


Also, some new media:

Trailer:




Promo:


Screenshots:

PLEASE VOTE ON GREENLIGHT!

Neat idea! Posting to follow. Good luck! 

My response got too big so I posted it in my own log so as not to confuse people. 

https://forums.tigsource.com/index.php?topic=49046.msg1328034#msg1328034

Nice man! Great details. I reread some of your older posts and realized you'd outlined the key-to-language system earlier as well. A good separation of writing, script, and code.

Your set up is fairly ideal for visual novelas, like The Whisperer in Darkness. If you stick with that style of game, you're probably best served by continuing to use the engine you have now. I'd only change if you wanted to do something with more obtuse logic, like decisions in the game that percolate (Twine is great at this!), or inventories of items with various uses (Twine is terrible at this!).

[love]

I love the technical info!  Anything you can share about the Twine/Unity integration and MVC stuff is great. I'm interested in being able to quickly write and release more little visual novels at this point, so I should probably be exploring all the options aside from sticking with my custom engine from the last one.

Cool! What did you use for writing your script (was it imported from something, or syntax completely written from scratch)? I'd love to know more solutions -- as I said, mine isn't perfect, but works for what I'm doing now.

I've been using an approach where commands are executed sequentially and previous commands apply until explicitly undone... I would love to hear if you have any thoughts on which way is better! Thanks for sharing your thoughts on the development and I would love to read more about your implementation!

Great job summarizing the approach I described! I actually simplified it a little bit in the post. In reality, I use multiple tags per passage in certain scenarios. For example, I'll have the first tag be "Conversation" so Unity knows to load the Conversation screen, and the second tag be "Butler" so Unity knows to load the Butler images/sounds.

You nailed the problem with it -- it's tedious and can be prone to error. The good news is that I can catch those errors with tests in Unity -- for any node with a Conversation tag, check that it also has a second tag, and that the second tag matches the name of a character in the game.

Although I've created a specific syntax, it's still useful in Twine itself. Twine assigns a random colour to a passage for each tag combination (e.g.: all my "Conversation Butler" passages look green and all my "Conversation Mobster" passages tags look red). So I can easily see where conversations start, change to a new character (interruptions), or transition to something completely different. I can also see if I've misspelled any tags, or if I accidentally missed tagging a passage (though I do run a check to see that all my passages have a valid tag, which takes care of most problems).

EDIT: Note that I'm using Twine 1.4. When I started this project, Twine 1.4 still had many features not yet present in Twine 2. I haven't looked into Twine 2 since, so maybe it's caught up. For sure the new UI is much nicer!

Ben, I am utterly impressed!

You're putting so much thought into this, and it's really showing.

There's plenty of success ahead for you

Hey I missed this earlier! Thanks for reading, Tony

Big updates soon™!

[MAKING AN ENTRANCE (PART 4: THE IMPLEMENTATION)]

MAKING AN ENTRANCE (PART 4: THE IMPLEMENTATION)

Unlike other elements of my introduction, the implementation doesn’t care about hooking players into the game, or layering future themes, or even being pretty. It just needs to work. When I say “implementation”, I’m referring to what drives how players interact with the game — what runs the game in the background? I could use the word “code” instead of “implementation”, but that would be over-simplifying. Writing the story in Twine has as much to do with how everything comes together as my C# code does.

As much as this post is part of my Making an Entrance series, its content isn’t specific to the introduction. Instead what I’m about to detail is entirely how my game works, from start to finish. Be warned, this gets a bit technical. But feel free to ask any lingering questions you may have after reading this!

A Tale in Twine

Twine is a computer program used to write branching narratives. It uses chunks of text (“Passages”) linked together by player choices. For example, if I have one Passage that asks the player “Do you want to kill him?”, I can give the player a “Yes” choice and a “No” choice. The “Yes” choice leads to a new Passage, and the “No” choice leads to another, completely different, new Passage. It’s a visual, graph-based system, so it might be easier to understand if you look at the first image below.

I’ve written the whole of my game’s story in Twine. That means you can play the game, in its entirety, with Twine’s “Test Play” feature. (For you engineers out there, this amounts to Twine being the Model in Model-View-Controller lingo.) I then export that Twine story to an easy-to-read format (called “Twee”) and use a plugin called UnityTwine to finally get it into Unity — which is where my C# code controls all the images, animations, and music that add to the overall experience.

Since Twine is just a graph of Passage nodes, my C# code simply looks at which Passage of the graph the player should be seeing, then displays its associated text. I use Twine’s Tags feature to determine what images (characters, locations, etc) my game should be showing. For example, if we’re in a Passage that is marked with the “Butler” Tag, my code will show the butler image. If we’re in a Passage that’s marked with the “Malone’s Apartment” Tag, my code will show Malone’s apartment. Collecting evidence, opening the notebook, and contradicting suspects are a bit more complicated — but essentially they use the same idea: everything is controlled in Twine, and my code in Unity just decides what to display.

Lovely Things

This comes with implicit rewards. As with any properly-divided MVC system, it means my story is entirely independent of my visuals and my interface. I can change the art style, the type of interaction (touch screen?), or even change from Unity to Unreal to any other engine, and the story still works — I wouldn’t have to alter a thing in Twine.

It also means I can test the story while writing it in Twine. I can iterate much more quickly since I don’t need to export everything into Unity and run the game. Does this passage sound awkward when coming from this other passage? I don’t know, let’s try it! This makes any Save/Load system easier to write, as I can just save what passages my player has seen, and run through them one-by-one when they load a game.

It also means I can write tests that look only at the Twine output. I don’t have to rely on Unity, just run though the Twine story and let me know if there are errors. Wonderful!

Terrifying Messes

Of course there are downsides. And in this case, unfortunately many. They’re all related to the fact that Twine was created for web-based choose-your-own-adventure narratives.

Thus, Twine knows nothing about important game state — i.e.: where is the player? which character is talking? etc. Essentially, I’ve had to create my own scripting language inside Twine — (ab)using its Tags, Links, and Display systems — for my code to understand what screen to show or what music should be playing. But this is bad, because Twine then can’t check for errors — if I misspell a Tag, or try to Display a Passage that doesn’t exist, Twine has no idea that I’m doing anything wrong. I have to write a lot of unit tests to cover these cases or else find many bugs inside the story.

Twine also doesn’t understand complex concepts like “always show the notebook button when the player is engaged in conversation”. In order to get the benefits of playing the entire game in Twine, I need to manually check that there is a “notebook” link inside every Passage where the player is conversing. Of course, this is dangerous for the same reason mentioned above: if I miss one notebook link inside a conversation passage, Twine gives me no warning — the game is just quietly broken.

And while Twine does offer support for returning to passages multiple times (including conditional statements and times-visited counters), it’s really not meant for a game where a player searches for evidence in a room. Or, even worse, where a player tries to contradict a suspect with the evidence she’s collected in that room. This all leads to an insane amount of graph spaghetti, as demonstrated above. Again, annoying, and easy to make mistakes with.

A Review

With these downsides (and more) would I use Twine again for this type of story? First I’d take a closer look at renpy and see if I could port that into Unity. And inkle has made ink, their internal writing tool, completely open source — so I’d give that a go too. But, in the end, my game is fairly specific. With the amount of evidence, the number of contradictions, the variety of locations and characters, it quickly gets complicated for any system to handle. Twine isn’t ideal, but I’m sure I’d find challenges with every piece of software. While Twine can be dangerous, it’s also flexible enough for me to implement this entire game, so I’m still happy with it!


This marks the end of my Making an Entrance series. I’ve compiled all the posts onto this page. It’s been fun for me to write the series and I’m sure it will be useful in a post-mortem capacity. I hope you’ve enjoyed it too! If you have any questions, about this post or any of the others, please don’t hesitate to ask.

The game is coming together quickly now. I’m excited to share much more with you in the coming weeks!

Hey thanks!

For the past ~2 years I've been working part time on the game and presenting at various conventions.
Across this time period, I've vastly revised and iterated the game's design based off of player feedback, and festival criticism.
However, now I'm at a point where I am satisfied with the core of the game! Which is great. So now I'm moving into a purely content creation stage of development.

Overall, presenting at conventions can be invaluable for initial exposure, networking, and most importantly getting playtesting feedback.
Festivals can also be a (relatively) objective way to judge the quality of your game, and give you outside critical perspective.

In terms of general advice, it depends what you're looking to get out of the convention.
Why are you attending? Do you want playtesting feedback? Press? Networking? Exposure?
What are the costs for presenting (beyond just financial)? How much time will it take you to recuperate afterwards?
Before you present you should evaluate what your expenses are, and especially what you're seeking to achieve.

If you want more info in regards to the presentation process, it might be useful if you check out my PAX East 2016 Retrospective.

Here's a list of other convention retrospectives I've done:
-MAGFest 2016
-BFIG 2016
-BFIG 2015
-IndieCade 2015

If you have any specific questions, feel free to reach out!

That PAX East retrospective was great, especially the advice about a catchy title screen. Thanks for sharing!

Arrived at this devlog from your comment on a random reddit gamedev post. This game looks mechanically novel and visually gorgeous! Posting here to track future progress. Good luck! 

You say you'd have preferred a more finished project to display at The MIX, but I'm wondering: how did you find showing off this type of game in a public space? Though our games are significantly different, I'm also making a single-player experience that requires some thought on the player's part to progress. Any advice for showcasing? I'm thinking of applying to The MIX @ E3.

And you're wrong, that Yerba Buena statue is fantastic!

Just seeing this now. I love mystery games -- excited to see more!

Posting to follow, best of luck 

Working on some Roy Lichtenstein-inspired shaders for my augmented reality puzzler!

I love the inspiration from a unique source! Already looks great, I hope you release something with that (or at least share it for the rest of us ).

Been tracking this as a lurker, but I wanted to congratulate you on release. I'm sure it comes with great satisfaction and relief. Fantastic work! 

That 3D galaxy is the bees knees! Great work!

[MAKING AN ENTRANCE (PART 3: THE VISUALS)]

MAKING AN ENTRANCE (PART 3: THE VISUALS)

Much like the other elements of the introduction, the visual style has to grab players. Sure, they’re coming to the game after being exposed to screenshots or trailers, but that doesn’t mean they’ll stick around if they don’t get hooked. The art needs to have a spark that previews the best parts of rest of the game.

Inspiration

For The Ben Wander Murder Collection, that starts with Saul Bass. When researching my introduction, his Art of the Title page is a fantastic resource, giving me insights to the kinematics of his work. But I’m drawing as much from his static pieces as I am from his credit sequences — posters, logos, etc. And I think its important to get inside his head — what was he thinking, and can I recreate that in my own work?

Saul Bass: A Life in Film and Design is an invaluable asset — a special gift from two generous and supportive people. The book not only collects his well-known work, but also dissects his process, showing in-progress pieces — how he thought of them, and why he eventually chose another direction. It even has rejected concepts — perhaps marketers or directors couldn’t see value, but he did. Poring over his life’s story has been a worthwhile exercise, and has undoubtedly improved the art in the whole game.

Bass is a huge inspiration for my style, but not the only one. Olly Moss’ silhouettes are also important, as are Paul Rand’s colours. I’d love all three to make an appearance in the introduction.

Requirements

All of this has to be tied back to the story and the design. I don’t want to change my script, and the gameplay is finally understandable without an obvious tutorial. I have to play within the constraints those bring: the sequence must be interactive; it needs to build suspense and mystery before alleviating those feelings; and it must end with a cat.

The best way to surprise my players is to start abstract. If I only draw a simple shape, players can’t understand its meaning until I explain it. The story can imply one representation, only to change its stance and pull the rug from under the player.

Thankfully, Saul Bass loved mischievous, abstract animations. They fit perfectly with my overall art style, and with the writing and the design of the introduction.

Implementation

A lot of the transitions in my game are actually rendered polygonally in Blender. I’m certain I could achieve similar goals using a purely 2D solution, but I’m familiar with the animation workflow in 3D programs (thanks to messing with bootleg versions of Maya in my teenage years — who knew that would pay off now?!). This implementation also allows for easy changes to basic animation elements (length, frame rate, etc).

As an example, take the Roll Down Dots animation that starts my intro. Keeping with the abstract theme, I wanted the dots to graciously slide into place. I make them “roll down” by attaching a simple subdivided rectangular model to a spiral curve, carefully texturing the model with small dots, key-framing an animation of the model rolling over the spiral, rendering that animation as a series of images, and then adding those images on my GUI layer in Unity. That was a jargon-heavy sentence, so please ask if you have any detailed implementation questions, but here are some key steps of the process to help you understand:

I just drew simple circles for the cat’s eyes — still in the Bass style — which keeps them mysterious: they could be human eyes, you won’t know. A knife also makes an appearance, and showing just the knife makes the situation more tense while giving room to wiggle a playful ending to the exchange.

And, of course, the final shot is the cat silhouette fading in.

When Can I See It?

There are still a few edits I want to make to the visuals in the introduction, so I’d rather not show it to you right now. Instead, I’ll let you play it upon release, and you can refer back to this post and see if it hits all of my goals!

[two months]

Woah, it's been a month two months since my last update here! I'm still lurking around, posting on only a few of the games that I'm tracking. And, of course, work's still progressing. I actually posted Part 2 - The Design in my Making an Entrance series a couple of weeks ago on my website, but its content was geared to non-developers, going over basics of tutorialization and the importance of flow.

For posterity, I'll post it now, and then I'll post Part 3 - The Visuals, which I just wrote.

This week's going to be big for my game's promotion. Expect more updates soon, and more frequent posting moving forward!

MAKING AN ENTRANCE (PART 2: THE DESIGN)

Creating an intro sequence needs writing, design, art, and code. A few weeks ago I outlined the importance of setting mood, foreshadowing themes, and hooking players with the writing. I brushed over the game design, but that’s equally vital to a good player experience.

Teach Me!

There are similarities between introductions in books, plays, films, and games — but games have an additional hurdle: interaction. Other media requires simple, everyday skills: a level of reading literacy, or basic sight and sound senses. There are exceptions to this, of course, and many advances have been made in accessibility across the media spectrum, but for an independent playwright, thinking about audience cognizance isn’t her first priority.

I want players to get lost in my game — to think of actions and choices rather than controls. This eventually leads to players conflating the main character’s actions with their own — i.e.: “I need to jump here!”, rather than “I need to press A to have Mario jump here!” This mental shift is what makes games unique. It’s that responsibility placed on your own actions — timing a jump in Super Mario Bros., or choosing which character to save in The Walking Dead. It’s never a permanent state (no player walks away from the game thinking they’re actually Mario) but even that temporary projection can lead to heightened emotions, like anger or joy, and even emotional states impossible for other media, like guilt or remorse.

If I want my players in that state as soon as possible, I need to teach the controls quickly — in the introduction.

But Get Out of My Way!

Some games have complex interactions — evolving an empire across centuries, or creating and maintaining a city and its infrastructure. These games require more explanation of their controls, and usually those explanations are large pop-ups full of text. While I understand the necessity of this approach, I don’t like it. Taking players away from the experience breaks any sense of flow. It reminds them they’re playing a game. It pulls them further from the state we want them in.

There have been many analyses of the introduction to Super Mario Bros. — how it teaches players to jump, attack, collect coins, and use power-ups, without any direct communication from the designer to the player. Similarly, the original Halo is praised for actually changing its controls based on how players interact with its introduction. These games succeed because they start the immersion immediately and don’t break it. Players learn while in the world.

My game has fairly simple interactions. I bet I can do the same.

How Are You Doing It?

Players in my game read a passage of story, then click options to progress. These options have three types:

• Continue, where players have no choice, but must click a button to see a new passage
• Descriptive, which simply add detail but don’t continue the story
• Choice, where players need to make a decision that might branch the story

Players quickly understand the Continue option, but the difference between Descriptive and Choice options has been more difficult to communicate. Players had always recognized the visual distinction, but they remained unsure of the gameplay difference (“Oh I didn’t pick [the Descriptive Option] because I thought it would advance the story”). I was worried I might need a pop-up to explain the difference, but, with testing, a more elegant solution emerged: if players first encounter options in a certain order, they understand the difference for the remainder of the game.

I needed to tweak the script for my introduction, but not by much. Now, the first three passages of my game progress like so:

• A passage with only a Continue option
• A passage with two Descriptive options and a Continue option
• A passage with two Choice options

The first passage is simple. It has only a Continue option that players find and click without difficulty.

On the second passage, players recognize the Continue button, but are intrigued by the Descriptive options. They select one of them, which shows them a bit more text. But then they see that the second Descriptive option is still available, and they select that as well. They understand that choosing the first option still allowed them to select the second option. Then they click the Continue option to progress the story.

Upon seeing the third passage, they don’t see a Continue option, but two new options that look different and are at odds with one another (“Do Action” or “Don’t Do Action”). They select one option and the other option disappears. Players understand that they’ve just made a choice.

Though the lesson was subtle, it sticks around for the rest of the game: Descriptive options have no consequence, but Choice options are permanent decisions. It perfectly captures my interactions without explicit communication through pop-ups. It took some iteration, but it works well now, teaching the players while immersing them inside the world.

Posting to follow -- the art style looks great, and it's in a genre I love! Good luck guys 

I've been silent for a while on here, but I'm loving all the updates. Great seeing the progress of Whale Animation and Island Navigation continue from post to post. Good stuff 

>thread is called SCREENSHOTS
>mostly GIFs and videos
 

did I skim past a memo or something

This might just be a matter of preference, but I have a hard time understanding a lot of static screenshots without context. I know they're antithetical to the title of the thread, but I actually prefer animated GIFs or short clips of the game. Just my two cents.

Are symmetrical solutions in puzzle games good or bad idea? What do You think?

I love good looking solutions to puzzles -- be they symmetrical, or just visually pleasing in some other way. The Witness has some fantastic symmetrical puzzle solutions. Even though they're simple, I love their style!



Of course, it's all subjective. But I like your top solution (the symmetrical one) more than the bottom solution. It's a nice, small reward for success.

Amazing attention to detail. Following!

"Personally I'm kind of tired of all the games that don't really have anything to say. They're often sanitised so they don't offend anyone. I'm not even that old yet, but as a 27 year old I'm tired of shooting people for no reason other than not getting killed. I think that demonstrates how far big budget games are estranged from the real world."

This quote (including the age!) is exactly how I feel. Excellent piece guys!

http://www.gamesindustry.biz/articles/2017-01-16-im-tired-of-shooting-people-for-no-reason-other-than-not-getting-killed