What are the documents of Tabat? In an early version of the book, I had a number of interstitial pieces, each a document produced by the city: playbills, advertisements, guide book entries. They had to be cut but I kept them for web-use. I hope you enjoy this installment, but you’ll have to read Beasts of Tabat to get the full significance. -Cat
An Instructive Listing of the Street Foods of Tabat, being Pamphlet #5 of the first series of “A Visitor’s Guide to Tabat,” Spinner Press, author unknown.
The visitor to Tabat will find themselves faced with a multitude of new things, and the food of the city is no exception. Carts and food stalls in particular supply many of the daily food needs of the populace.
No matter where you go in the city, you will find the bakery carts. Most belong to the Figgis Bakery, but you will also see some from smaller and independent bakeries. They sell a multitude of breadstuffs, including several pastries unique to the city: two and twos, large flatbreads which are half one color, half another; hyacinth cookies with their distinctive purple icing; and jelly cups.
Close to the docks, particularly around the Fish Market, vendors sell all varieties of sea food, cooked on the spot and fresh from the boats that have just brought it in. Many of these use the seaweed spices Tabat is famous for: ironbite with its metallic peppery taste; summer salt; and the mix of dried fish and seaweed that forms the basis of chal. Look for kerik, the sweet purple nodules of seaweed that are harvested in late summer, for a particularly exotic treat.
Sweets are usually flavored with honey from bees or Honey-mothers, or a touch of Fairy honey for those with more expensive tastes. Of late, though, the Southern Isles have been sending sugar to Tabat, expensive and rare, and a dusting of such atop a pastry or cake is considered to render it the height of culinary sophistication.
***
Love the world of Tabat and want to spend longer in it? Check out Hearts of Tabat, the latest Tabat novel! Or get sneak peeks, behind the scenes looks, snippets of work in progres, and more via Cat’s Patreon.
Want access to a lively community of writers and readers, free writing classes, co-working sessions, special speakers, weekly writing games, random pictures and MORE for as little as $2? Check out Cat’s Patreon campaign.
Want to get some new fiction? Support my Patreon campaign.
"(On the writing F&SF workshop) Wanted to crow and say thanks: the first story I wrote after taking your class was my very first sale. Coincidence? nah….thanks so much."
~K. Richardson
You may also like...
On The Treatment of Coders
Coders can seem like odd creatures sometimes. Under that ladybug costume, though, they're as human as you or I.This article originally appeared in the now-defunct online magazine Imaginary Realities. It talks about MUD administration, and draws on my experience working with Armageddon MUD, the world of Zalanthas. For those who don’t know what a MUD is, it’s a text-based roleplaying game. Here’s the wikipedia article on MUDs.
One of the sad truths of the mud world is that there are never enough coders. Builders aplenty, brimming with fresh idealism and plans for entire zones, appear (and sometimes disappear) at the drop of a hat. But coders are the unicorns of the mudding world, seldom glimpsed and ardently pursued. We are lucky enough to have three dedicated coders on Armageddon MUD: Morgenes, Tenebrius and Tiernan, as well as a few other staff members willing and able to wade through the bugs file and tinker with things upon occasion. How, then, does an administrator keep these rare beasts happy? The following four steps may help.
1) Communicate: When asking for new code, try to let the coders know exactly what is desired. For example, instead of ‘Let’s make archery more complicated,” a staff member might propose “Let’s put a range on archery, so the farther away the target is, the harder it is to shoot it.” A full description of the the idea, perhaps including examples, such as fake logs showing what the idea will look like when being used, helps make sure the originator of the idea and the coder are on the same track as far as things like syntax and usage are concerned.
The same holds true for bugs. Describing how it’s supposed to work as well to how it’s working right now helps clarify ideas. Coders want to know if the bug is REALLY a bug, or something being reported because it doesn’t work as the reporter feels it should.
With bugs, give the coders as much information as possible, including how to reproduce the bug. Examples by way of logs are great, and if they include some form of error message (or message that they’re getting that shows it’s an error), it often allows the coder to track down what section of the code needs to be worked on.
Make sure people aren’t bumping into each other. On Armageddon, we’ve got a coder’s board, where people post changes as they make them. This alerts fellow team members to what they’re doing and is also helpful if unexpected bugs crop up, enabling people to track exactly what got changed and when. Two people should not be working on the same idea at once unless they know it, and can divvy up the work accordingly.
2) Have a purpose: Will it get used? Is it something players are asking for? This one is a matter of ego, but we’re all human and we all do have egos. Seeing their work getting used, regularly and as envisioned, is a reward beyond any thanks or congratulations other staff members can give a coder. Track player requests, through entries in the bugs/ideas/typos files as well as emails to the account and posts on the general discussion board in order to convince a coder that the players want, and will use, something.
Generally, with new ideas figure out how they are moving towards some goal. A piece of code like a new skill is going to sound more interesting if it fits into some overall purpose, such as a master plan of non-combat related skills for the economy than it would if it is just a random idea. You are also going to end up getting more out of the idea if it is part of a greater whole.
Make it innovative. Some coders like to be trail breakers, to feel that they’re not just playing catch-up with another mud, but are creating ideas and concepts new to the mud community. Some ideas get requested to ‘balance’ things out between groups: guilds, or races, or mount speed. When a coder starts to feel like the code they’re doing that day only works to nullify a change made last week, then they’re going to start wondering what they will be asked to implement tomorrow.
3) Share the work: Do as much of the grunt work as you can for the coders, including helping thoroughly test, providing help files and documentation, and fleshing things out. In testing, give coders information about what is not working and how to recreate the result. Be precise about what needs to be changed: not ‘the plague of locusts spell needs to do more damage’, but ‘it needs to do about twice the damage it is now.’ When something requires a new help file or modification of an existing help file, do not expect the coder to do it, but supply it yourself. If it is something that requires building, provide the items. Teamwork of this kind, when it is working well, is terrific, and will often produce amazingly cool results.
4) Appreciate: Good coders can never be praised sufficiently. We try to make sure that players know who is responsible for new and interesting changes, by posting information about them in the news as well as in our weekly update, which is a mailing our players can subscribe to, which provides information about changes, staff and world news, upcoming recommended playing times, etc. When players write in with compliments or feedback on a code change, make sure that the note gets passed along to the person , as well as that the coder knows how cool or slick you think the ideas they have implemented are as well.
There is a tendency sometimes to regard coders as resources that spit out code at request. But the fact of the matter is that treating coders in that way will frustrate both sides, leading coders to become discouraged and unmotivated to implement new ideas and builders to feel that their coding needs are not being met. These four points may help avoid such frustration.
Image #1 appears on both the title page of Far and the story “Five Ways to Fall in Love On Planet Porcelain.” Christmas tree, one-eyed triffid, and rocket ship all in one.
Image #2 accompanies the flash piece, “Space Elevator Music”. I picked it for its upward line, which made me think of a rising elevator.
Image #3 is a favorite of mine because it always makes me think of the submarine in Yellow Submarine. I picked it to go with a story that’s light and funny and silly accordingly, “Zeppelin Follies.”
Image #4 is a lovely piece that, if I look long enough, becomes a woman wearing an elaborate headdress. As always, your mileage may vary there. It goes with the story, “A Querulous Flute of Bone,” which appeared in the anthology TALES FROM THE FATHOMLESS ABYSS and features the philosopher-king Nackle.
Image #5 actually doesn’t seem to appear in my copy of the book, but it’s a proof, so things may have changed somewhere along the line. Bonus!
2 Responses
Cat Rambo: Documents of Tabat: Street Foods of Tabat http://t.co/aU4T1xdIh7
RT @SFWAauthors: Cat Rambo: Documents of Tabat: Street Foods of Tabat http://t.co/aU4T1xdIh7