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.
2014-10-06
2014-10-02
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.
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.
2014-09-27
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.
Subscribe to:
Posts (Atom)






