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.

Plot

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

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:

Progress Update

Hello.

The current transition into Unity is taking a while. The major task is getting all of the dialogue into a form Unity can use. I haven't been able to find a way to do this without writing some sort of new code. I am currently working on it, but can't say when I will have something ready for sure. The project is not dead ... just nothing to see this week. Thanks for checking in though.

Version 27 of Next Door Girl: April

Updated things: DOWNLOAD

So the poll results are pretty clear, art is the winner. Most of the feedback that I have gotten is about making art so I guess that will be my next step. Part two of the story along with other tasks are going on hold for quite a while.

I am likely going to use a lot of freely available resources from various places online. I welcome any artists that would like to contribute to the project, but I don't anticipate lots of interest. There is a lot to be done and I don't want to talk about how long the process will take.

I'll just go step by step. First, the environment. Here is a quick look at what I have mocked up so far. NOTE: you will need the Unity web player to view this demo. I am only posting this because ... well ... not sure, but here it is. As a side note if anyone knows of a place to host the game online, I'd appreciate a tip.

[experimental thing removed]

Thanks!