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. >_>
2014-11-03
2014-11-02
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.
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.
2014-10-17
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.
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.
Subscribe to:
Posts (Atom)