Scenes, too many of them

I should really know better than to start writing new scenes without finishing old ones. I just come up with ideas and start writing without thinking about all the work that it takes to get them done. I've gotten to a point where I have 20 scenes that are incomplete in different ways. There is no realistic way I can get them done by the end of the month. For now I've at least recognized the problem and stopped writing before it's too late. I'm in the process of testing the game to figure out what scenes are necessary to have for the demo.

A few other things. In the spirit of 'borrowing' I've decided to implement fair math from ChoiceScript to help handle stats. So far I'm liking it, but I worry that I might have problems managing the numbers later on. Also, I've added keyboard shortcuts for undo, redo, save, etc. My goal was always to be able to scrub through history super smooth like with Ren'Py. I think I'm getting there.

And last but not least a little info about the game. I'm calling it Ever Forward. You play as a 28 yr old guy celebrating his birthday. Yeah I could be more specific, but I don't like spoiling things.

sample of stuff

Working on a few small fixes with the system. Here is a gif of the settings available and my poor attempt at responsive design.

I'm trying not to get bogged down with working on the system since I have a crap load of stuff to do for the demo. I'm working on a pretty crazy scene with a room full of androids. Onwards and upwards... or whatever.

Sat on a stapler

Just finished writing my first DP scene. Today was a good day. The move to revive this project was a good one. I have a lot of work to do, but if I can keep up my current pace I expect to have a decent demo available by new year. The structure of the game encourages a lot of diversion in plot, so I can really go crazy with ideas (hopefully not too crazy). The downside is that I probably won't include any meaningful endings for quite some time. I have a few ideas for endings, but I want to push more content into the game before wrapping things up.

Yeah, reading this post back, it sounds like a vague description wrapped in a brief update wrapped in a questionable deadline. Basically yes, I'm having fun writing this one, and I think it's going to be real good like. I've decided to make a new town next to Bunkville called Cloverfield, where I can dump sci-fi stories. Why do I need to create fictional towns that border fictional towns you ask. Well, I have already explained this via clues hidden in everal previous posts. (hint: that last sentence is a lie (or is it? (it is)))

Substance-less update

So yeah, my nanowrimo attempt failed. I got to a point where I just disliked where my story was going and didn't have the time to back up and rewrite. Maybe next year...

Instead I focused on Fate. I made a few porting attempts and long story short, decided to stick with Unity. Along the way I made a bunch of changes to the system, some of which broke the entire visual editor code. I also bit the bullet and redid the interface using Unity's new UI system. There are a few important things that I need to figure out how to approach, like embedded links and noun/verb display. For the most part it works.

More than anything I would really like to release one game this year. Just one. Something is far from ready, so instead of trying to rush that, I am dusting off one of my many abandoned projects. I gave up on the game I have in mind due to the heavy amounts of state involved. It was a pain to work with all the conditional statements needed in Twine. My hope is that the syntax Fate uses for branching will allow me to build a decent demo of the game while maintaining my sanity (or what's left of it).

Sigh

8951 words right now. I fell behind working on code instead of writing the last few days. I'm committed to catching back up though.

I've been stressed out about the limitations with using Unity for text based games. I knew the problems before I started all this, but I hoped that I could figure out workarounds. My biggest concern is with the user interface and accessibility.

Ideally I could hook up games in the system to accessibility features provided on each platform. I believe this is possible with Unity on mac, win, ios and android by making plugins. Unity has nothing built in to access these features. Actually Unity's stance on accessibility as far as I can tell is basically good luck. The problem for me making these plugins is that desktop native plugins require Unity Pro and my current project budget is nil.

That brings me to search for alternative multi platform game systems where I can port the system.

Xamarin would be the easiest switch since the core of Fate is already in C# without dependencies on Unity. The downside there is that it costs to develop for mobile and I would still have to write accessibility plugins for each platform's accessibility apis anyway.

Cocos2dx looks promising as a cross platform/open source engine, but I would need to convert Fate to C++ (no small task). I also haven't dug up any clear answers about how or if Cocos2dx interacts with the various platform's accessibility apis.

I've looked into Haxe as a potential solution, but couldn't find anything about accessibility with OpenFL, haxepunk etc.

There is of course Java or cpp with qt/whatever or c and gtk? or javascript/html5/css. I just hate/haven't used those. Yeah, my current outlook on all of this is kind of negative. I'll figure it out eventually (I hope).

Stupid bugs

First, a little nanowrimo progress update. I am at 6387 words. I've been thinking about posting my wip as I go, but I'm not sure if it is worth it with what little I have so far. The story is my first attempt with survival horror (zombie apocalypse). It has some extra sprinkles of things like drama, supernatural phenomena, romance, mystery and a pinch of comedy.

As for my fate system, I finally squashed the bug I've been hunting down the past week. The issue started when I added the ability to give nouns in the world system a unique displayed name. I ran into a problem with needing to create unique names for things that didn't really need them. For example I had to give elevator buttons in the game a bunch of unique names like Floor 1 Button, Floor 2 Button, etc. when all I really needed was Elevator Button on all of them. Implementing that feature meant setting up a clean way to add it to the source code. After some thought, I ended up with a noun declaration like this:

:: Elevator Button|Floor 2 Button [noun(Floor 2)]

It feels pretty natural with the way links can have a displayed text value on the left that is different from the passage or whatever they point to on the right. Adding new features means writing unit tests first, but my downfall was not adding the right tests. I tested the feature with the importer but forgot to add tests in the world system. The end result is I spent a week adding all kinds of new tests trying to pinpoint what was going wrong in the importer. Debugging in Unity is a painful process, but I tried and failed to find the issue. Finally I went over a higher level step through of the system and found that the import process was fine. The issue was with the world system silently discarding nouns with similar displayed names during initialization. The lack of any warning or throwing an error about it really messed things up in finding the problem.

Anyway, with that fixed I can sleep a little easier. But I know what you're thinking, 'Why should I care?'. Well, I don't know, you're the one reading this. >_>

Sidetracked

I've been aware of nanowrimo the last few years, but I always found/made reasons not to do it. I'm giving it a try this time around, with a game story thing. I should probably look up the rules and such, but it's a lot easier to just start writing. I'm at roughly 4199 words including various link syntax. I want to keep the thing simple enough to import it to Twine if Fate isn't up to snuff by month's end. I've been struggling with a nightmarish bug with Fate that I can't track down the source of.

This makes the fourth project that I've started this year, and I'm at 0/4 for finishing anything, but, well... I'm working on it.

System in action

This is a little preview of the current working state of my system Fate.

I'm starting with some source code put together from the last example. I use Sublime Text for writing since it allows for syntax highlights and code snippets and other nice things.



The source is saved inside a resource folder in a Unity project. I can open the visual editor to make sure that everything compiles, then I'm ready to build an executable.



Unity does its thing and then the game is ready to play.



When the game starts up the first thing that the system does is copy the source code from the project into a folder on the local drive. This copy contains the exact same source text files, and it is what will be read into the game in place of the original. In other words this makes the source of the game available to be modded if the player wants.



Next the system reads the files from this directory and compiles the source code into a game. If this process fails there will be an ugly error like this.



As you can see, these warning messages aren't always very specific, so I have a lot of work to do to make debugging reasonable. Generally though, the default game source *should* be bug free. One challenge here is that a lot of the source is compiled up front, but some things can obviously only be evaluated during the game, so run time issues may pop up with the same error.

If all goes well we are taken to the game's title screen. All of the values here (author, title, brief description) are exposed in the source code via content functions. This makes the system pretty flexible and generic, but right now it's a little too generic visually.



I can exit out of the game and modify the source code with this line:
content("sensitiveContent", "true")
This marks the game as containing restricted material. Now when we start the game we will get a disclaimer with a rating and content details that we set.



Back on the title page we can navigate to the about page that shows other data we can specify about the game. One cool thing that I'm not showing here is that the number of contributions by a contributor are counted, and under the credits contributors are sorted by most contributions to least.



Anyway onto the game itself. Once we press New Game from the main menu, we enter the first passage, Start.



There are a good amount of options available to adjust the text for readability.



A game could be entirely choice based, world based or a mixture of the two. When mixing the two (which is pretty much what I'm doing) you make choices until you reach end points where you are then free to explore the world. World exploration/interaction is done with a horizontal infinitely scrollable list of nouns and then actions on those nouns.



Once items are picked up they get held in a separate list just for inventory. This was an important addition I made during the rewrite since it helps to keep the main list of nouns less crowded while playing.



We can save our progress and the save goes into a saves directory beside the source folder. I currently don't have undo/redo exposed in the interface, but the history system is able to go from wherever you are all the way to back Start. All choices are included in game saves.



If we quit and reload, we automatically return to where we left off by loading the most recent save. Otherwise saves are accessible via a simple menu from within the game.



And finally once we reach an end point specified with control("end") our game is auto-saved and we can return to the home screen when ready. (ignore that bit about the world menu still being displayed >_>)



So there you have a quick run down of the system. I can't even really measure all the work that has gone into this, but I really think it was worth it. I still have some important things to do before I can release a playable demo for desktop platforms. Android is quite a headache due to resolution issues and iOS is a pie in the sky. My current focus is on writing Something, so I guess my next post will be about that.

story map

Last time I talked about the syntax I'm using to write stuff. In this post I'll show some micro examples along with images of the story map representation.

Lets start with a basic example using the following source.

I guess you could say I was kinda *inspired* by Twine again. I couldn't think of a better way to represent the basic information of going between passages, so, what more can I say.


Moving on, here is an example using a display() passage. It works a lot like <<display>> would, basically adding one passage in it's place when evaluated at run time.

I use display() a lot, so I decided to highlight those passages in the map for faster recognition.


In this next example I use some implicit links and display()s.

They also got unique colors to help them stand out. I don't use them all of the time, but when I need them they are super helpful to have.


Now onto the world portion of things. This source code sets up a basic world structure with five different nouns and a couple verbs. Notice that a Start passage is still required since it is always the entry point of a game.

The nouns act kind of like a layer beneath passages. Each parent noun draws a white line to it's children. The green lines connect the actions on nouns to the passage responses of those actions. These links get pretty crowded, so I'm still not entirely happy with the way this is setup. For now though, it works.


Now an example with more stuff going on.

This time in Start I use control() to make the captain the player. With that set, the icon for the captain changes along with many of the other nouns. The treasure chest is taken by the captain at some point, so it gets represented as a pickup. All of the places where the captain moves get a container icon, since these locations could be rooms, vehicles or anything really. The Isle is still the default static icon because it never moves and never holds the player directly. Static objects are mostly useful for grouping nouns together, but don't need to serve any purpose in game. Finally the demon has the red dynamic icon since it does move around.

All of the little icons help add useful information that otherwise aren't represented in the source code.

Since this is all in the Scene view of the Unity editor I decided to add another perspective of the world to help understand what is going on.

From a top view we get a floor plan of the world at it's default state. It's much easier to see which object is inside of another this way. I've found that I don't need to make diagrams of this stuff anymore since it is easily represented here. The connecting lines are in the way in this image, but they can be toggled off.

And so that's the story map.

syntax

The way I'd like to write games is simple. Write some text, then view it in a node map and repeat. The rewrite of Fate was mostly so that I could do just that.

The first thing I needed to do was formalize a syntax for writing that could handle the type of games I'd like to make. I started with tweecode as a base. Passages mark collections of text, and they look like they would with Twine.


Links between passages are done with familiar double brackets:


I didn't want to keep the Macro syntax: <<set $thing = 8>> , so I slimmed it down like this: set($thing = 8) but I kept the $ character prefix on variables as an act of habit.

One interesting feature I had to figure out how to represent are implicit links:


The query() part sets the value of 'passage' to 8 before executing a query to find the best passage to display. So to define passages that are queried:


Basically the criteria() function binds the passage to it's arguments. To save a little writing I setup the ability to stack multiple passage responses under a single passage declaration.


Then there is the world system (although it's not really that amazing of a system). I opted for familiarity in the declaration of passages, nouns and verbs.


The noun() call is done where tags would be in tweecode. Notice that the noun() function for 'Room' has 'House' as an argument. It basically sets up the default hierarchy of the two objects; the room is a child of the house. The body of these declarations are automatically mapped as descriptions that respond to an examine action.

Actions are declared in a similar way.


Verbs that shouldn't always be available can use a require() function.


require() was necessary in addition to criteria() since responses to verbs may need to be tied to criteria since they are essentially passages.


Moving objects around is done with a move() function


I skipped a lot of functionality (print, display, if/else etc), but that is a quick look at the basics of how I'm writing Something in Fate.

something

I've been meaning to get back into blogging, so here is a quick image I put together to keep myself motivated.

Since my last post I decided to both start from scratch with my game system Fate and greatly expand something. I found myself needing to include more back story in the game, so I increased the number of in game days and it's lead to needing much more content. Fate was letting me down in a bunch of areas, so I painfully started from scratch taking into account the types of things I need to do rather than every feature I'd like to have. I think the end result of all of this will be pretty good, after all this time it better be.  My current goal is to release something winter this year.

Status update: Find & Replace 'cock'

I meant to keep up frequent posts, but I've been in a crazy state of prototyping things and writing. I had a spark of inspiration to make a wacky little game about a journalist, but then scrapped the idea (at least for now). Then I tried something different with science experiments but scrapped that too. Last week I switched everything around again and came up with something brilliant (in my own mind anyway).

I was inspired by the Shuffle comp idea, except I didn't want to participate in that directly for a few reasons. Instead I just chose a song that I like and I've turned it into a game, twisting it in horrible, horrible ways. A play through should come in around 25k words so I guess it's more or less a short game. I'm at the point where I would have randomly posted it here if it were a year ago, but instead I'm going to take some more time and give it some lurv.

bug findin' & fixin'

I decided to do some work on the quality of the code and discovered a bunch of random little problems. First I setup some unit tests... a year into the project, but hey better late than never. The majority of things seemed to work as I expected as I was writing tests, but I found myself refactoring quite a few classes along the way. I made some changes to a few storage classes to pass tests, then ran into a critical issue with json importing/exporting. The library I'm using to handle json isn't unit tested (by me anyway) and I was lost with a silent error that I couldn't for the life of me find. I resisted the urge to throw my computer out the window and found the issue by randomly reverting all my changes so all in all, good progress.

I also worked on the tools for designing games. Here is Next Door Girl April imported into Unity.

That is something like 300 passages in total. The conversion makes 300 rules and 300 responses, then each response has a text piece along with options and context so around 1000 game objects all together give or take a hundred. The editor runs a little sluggish with everything labeled but without labels it speeds back to normal.

Here you can see how options (magenta boxes) point to rules. 

I would like to write some kind of code to automatically sort passages in a pretty way on import, but I have more important things to do right now. My hacky Twine code doesn't parse nicely, so all of these passages need to be cleaned up a lot. Still without changing anything after an import it at least tries to run.

 Testing this out to see how far I could get lead me to another issue that I hadn't thought of.

I want to have all the text in the game be viewable in a big ass scrollable list ©. So far I had no reason to believe that this wasn't working, but after playing through NDGA I ran into an issue with the vertex count within the main panel view. I'm using NGUI to do the interface and the way it handles text is to create meshes. Normally this isn't a problem and it's actually an optimization over the built in OnGUI system (I think). Thing is once you get to like 60k vertices on a single mesh you have a big ass problem ©.

label

label under x ray vision

I'm hoping that the solution will be to just break apart the big ass scrollable list © into separate labels per passage and per command. Then just have them clipped when off screen. If that solution doesn't work, then I guess I'll have only one passage displayed at a time or some kind of limited amount of text. The good news is that this is the last major bug that I know of and now I have pretty much everything I need to make stuff.

Interface rebuild, check.

I'm not 100% happy with the look, but it works. I have a few more important tasks left for the world editor and then I'll finally be able to put together a game with this system (I hope).

It's been almost a year since I first downloaded Twine started working on Next Door Girl April. Looking back on the year I'm generally happy with what I've been able to do. I've learned a bunch about making games by building a text system in Unity. Aside from technical knowledge, I picked up a lot of good experience with writing and design from Next Door Girl April and Midnight Room. I remember being really miserable about life when I wrote NDGA, but I definitely feel happier as a person right now.  Maybe there is something beneficial about writing absurd text based games. I hope that by this time next year I'll have done something really amazing.

Where did March go?

So much for Plan G. After 10 months of working on this as a side side project, I think it's time to elevate it to full side project status to get it done. First step is to pin down a name for the system. I'm thinking 'Naught' could be pretty decent. Runners up are 'Rue' and 'Darkness'. 'Regret' might work too, since that matches the result of most of my decisions. Before I go getting overly positive, here is a feature list for the system along with my progress.

• Works with Win, Mac, Android, iOS (pretty much implemented in that order)

Unity does the heavy lifting for this one. Unity also has Linux export which I'll try out. There are some platform issues on mobile that I have to figure out so as of now I'd say I'm 50% on this one.

• Games from this system should look a lot like the stuff I was doing in Twine

This is not that difficult because I wasn't exactly doing all that much unique stuff in Twine. I recently decided to take a saw to the interface code that I had working, so now I'm at 30% on this one. It is my primary focus right now out of all the features in this list.

• Non-parser world exploration along side of choose your own adventure options

I'd like to create games that are like bastard children of parsers and cyoa. I have no idea how well this will work, but that hasn't stopped me before. After experimenting with environment exploring in chapters 2 and 4 of Midnight Room, I found that it was fun but difficult to implement. I ran into issues with something I wanted to do in chapter 4 and that was around the point that I lost hope in using Twine. Anyway, I'm ignoring adding a parser in this system for now so instead the world is explorable via buttons. I know what is lost without a parser but I'm not entirely convinced that it is worth it to me to have one.

Part of the interface redesign I'm working on is to see how an infinitely scrollable list of nouns and another for verbs works for exploration. This is currently around 60% given the interface construction.

• Easily handles lots of text and variables without needing hacky source code

This is a super important thing and it's working very well. I've spent the majority of development time getting this part of the system running so it's at 90%. This feature just means that I can store variables for anything and change them based on what happens in the game.

• System allows state driven responses based on rules with criteria

This is tied to the previous feature and is also at 90%. What this basically means is that there are potentially lots of responses to a given command, but only the response that most closely matches the state of the world will be displayed.

• Requires no coding to build games aside from any special functionality

Currently building a game means setting up a scene in Unity by dragging in prefabs that represent the different objects of the world and the various responses that result from selecting actions on those objects. After giving up the horrible editor script route I was on, this has become much simpler to implement and making games is actually very fun this way. There are some more ease of use things to do like creating context menus in the scene view that create preloaded prefab sets for objects. Those types of things aren't needed to just get the system working, so I'd put my progress at about 80% on this one.

• Designing games is done in the Unity editor and using one or many txt files for writing

This is tied to the previous feature and is also at 80% Once the world is setup you click bake then get back a text file that you can use to write stuff. Then you import the text back in and repeat as needed.

• Games support Undo/Redo/Saving/Loading

This one is a requirement because people like to change their minds during games and of course save and load progress. The functionality is mostly there, but the interface for saving and loading is up in the air during the interface overhaul, so I'd put this at 60%. I'm really also interested in being able to load saves across games so that for example something that you did in one game could matter in another. Another neat thing is that saves are shareable files.

• Games can be modded by me or others (who are brave)

This is the last feature I'll list and it's probably the most important. I think that games should be changeable by players if they really want. I envisioned it would be cool to have the ability to write entirely new branches to stories, add new characters and add new environments without needing Unity at all. The nature of Unity games makes it difficult for modding without planning for it, but for a text based game I figured the barriers should be a lot easier to overcome. To make this possible in my system the text that makes up the story and the world structure of the game are both loaded from txt files at runtime. I plan on having a directory set out for where these files could be placed and then loaded in along with the default game when it's run.

The biggest problem here is that the structure of these files is very specific and any typos would just crash the whole thing. Also a lot of things in the system are represented numerically so it would be a mess to edit by hand. I'll have to write out a lot of guides to make the world system and dialogue systems make sense. This entire thing is still in heavy development so I haven't even begun any documentation for this kind of stuff. This is all assuming that there is any interest in modding anything I make in the first place, so I'll see about it later on. As it stands I'll put this at 80% because it does work, but is undocumented.


And there you have it. Without checking the percentages above, I'd optimistically say I'm around 95% done. I'm reluctant to set another monthly deadline even for just a small game test because this is turning into a huge endeavor. I have no shortage of games I'd like to build, but until this system is ready I can't do a thing. Well not entirely true, I've been writing a bunch of random stuff for 3 different games because focusing on one thing at a time is for squares.

Different approach

Here are some images from my new setup. I'm still working on making things as simple as possible to go from these visual objects to a usable output.

The nouns come in a variety of shapes and sizes depending on what they might be sized like in relation to each other. The spheres are all verbs for each particular noun. Its a little crowded but there are various ways to filter out game objects in the scene view. Layer filters can hide entire groups of things pretty easily. Also there is a useful search field that can drill down on names, tags, types etc. within the scene. Here is a zoomed out view of this level.

I've wasted my week, how about you?

I've been torturing myself with making thousands of lines of Unity Editor GUI code for this past week and I just realized how much of a waste it was. I don't even feel like describing how horrible it's been writing this stuff, so I'll skip that part and get to the solution that I've been ignoring. I was brainstorming about solving one of the random problems when I had this epiphany to just delete all the code! I can use the editor as is to create a hierarchy of the objects that I need for a game. Using placeholder objects, I can create an entire visual structure of both the game world and the text. Then once I'm ready I can use a build function to analyze the scene, convert GameObjects into data and write that data to txt files for run time. I should be up an running with this solution by Monday if I'm right.

Unity users might be thinking 'well duh', but hear me out. I'm using Unity for text based games so I had no reason to consider the scene view/hierarchy for design time work. Unity users might then wonder why use Unity for text based games anyway. Uhh... I don't know, stop pestering me hypothetical Unity User!

Plan G

Just a small update.

A few days back I stopped writing to work on building the world for Burn and I realized that it was really hard to do. Everything in the world has a displayed name and a unique identifier that is used for all kinds of stuff within the system. There are some simple checks done in the code to make sure that these identifiers don't intersect, but the corrective code also liked to change the identifiers while the displayed names were being edited. The end result was corruption of the data so I started to just manually edit identifiers in json. Managing hundreds of these identifiers for each person, place and verb becomes impossible after a while. So I've taken a step back to think about what the hell I'm doing.

The identifier doesn't need to be known by the player, but it also doesn't need to be known by the developer. The corrective code was there to prevent data issues, but it was a solution to a problem that shouldn't exist anyway. I was certain that other systems don't require any kind of management of identifiers like this but I hadn't really looked into any of them. I've been kind of stubborn about trying different game engines and I've even passed on working on projects that don't use Unity. Since I am basically trying to do things that have been done before I decided to look into how rooms are made in Inform, Adrift and Tads.

Plan E, possibly F

As it turns out I've decided to push all my focus into a single delivery to be the game rather than several deliveries. There is more than enough good stuff within this delivery I'm working on to serve as a demo of the system that I'm building. It's probably better to keep things as simple as possible any way. If I can get this first part right then I'll be in a better place to expand into the events before and after the delivery later on.

One thing that I have to figure out is how to work around the choices that could have been made that influence the main character's state during this delivery. I don't think I can avoid talking about how the player's day has gone, but I also don't want to rely on specific past events to drive the story. If I can't make this work in a good way, I'll have to stick to my old plan but extend my deadline for sure.

[spoilers ahoy]

Plot

Do you like development updates? Interested in spoilers? Than do I have a blog post for you...

Burn

I've been working on bug fixes recently, one with the interface and another with system performance under taxing conditions. Aside from tech stuff I spent more time planning the game itself. 'Untitled' and 'Project 4' are a little vague so I'm calling the game 'Burn' unless some better name comes to mind. It's going to be a very simple story about a pizza delivery guy (pretty original huh). I'm fighting the urge to implement stats but I know I have more than enough to handle considering this kind of game format is new to me. So far I have a good feeling about this project.

Post

I'm getting closer to actually writing (for better or worse), but I am always finding game system improvements to make that take up time. That and I am trying to put more stuff in place to automate some of the tedious parts of working on the game. For example I'm auto generating basic stub responses for actions as displayed here:

The stubs aren't usable in the final game, but having placeholders made from the world data helps skip a few steps in development.

That image also shows the undo system which is working really well so far, which is great news. The not so great news is that adding the undo history to save data breaks saving. So that's the next thing to fix.

[Edit: Fixed] I made a few hacks and saves work again with history included. Currently 32 steps are saved in your history, so 32 choices are packed in with a game save. 32 is just a number I chose but it may change depending on issues that might arise with the amount of data stored. I still have to make an interface into managing game saves but currently they are just stored as a text file in a temporary directory.

Adding features

Here are few that are pretty nice and implemented for the most part. Starting with support for screen resizing/resolution changes, for mobile and desktop.

Some images ... of text

I thought I'd share a look at the Unity project.

I have text passages being displayed with links to other passages that open up when the link is clicked. Links can also be embedded within a passage and variables can be used to determine what text is displayed. I know, nothing new right? Well then there is this:

January Update

This month I've been working on tools for my next project. I've put together a pretty good system for displaying text inside of Unity. The system outputs a blob of text and lists links at the end visually just like Twine. It even imports Twine files because I had hoped that I could just import old projects into the system, but it won't be so simple. The issue is that my Twine files are riddled with macros for all sorts of things. In the long term a parser for all the macros is a good idea, but in the short term I have enough to work with to build a game already.

Since it is Unity, I could also do a lot more than what I've been doing in Twine but I don't plan on adding lots of features at first. I'm going to put the system through it's paces with a small test game and see where I go from there.

Why

I've been thinking about what the point of all of this is. There are lots of useful ways to spend time, but making text based games is a strange thing to do. Adult text based games are a niche in a niche and it seems like the audience for them is super small. Why should I work on these projects anyway? The only reason I can think of is that I want to expand the boundaries of what games are. More specifically, I believe games can be much more than what they are perceived to be right now.


One of the estimations of computing in the future is that it will mostly be done via mobile devices. People are using phones and tablets over desktop computers at a rising rate. So this means mobile devices are becoming increasingly important places to discover and consume content via default marketplaces like Google play or Apple's App Store. It's important that these marketplaces create an environment where consumers can discover content, but also that content creators can deliver their products to these stores.

Trojan Horse on Hiatus!

After much thought, I've decided to put Midnight Room on hiatus for now. For those who were interested in the story/game I do apologize, but please know that this is a tough choice to make. My reasons are many and all over the place, but at the end of the day if I were going to work on the game I would be working on it right now and not thinking about working on it. Midnight Room has crossed the line from 'fun to work on' to 'work to work on’. Working without fun or pay is kind of volunteering, but in this case it's volunteering without the satisfaction of helping anyone.