notes on "Annoy"
Felix Lee
This is what the maze is supposed to look like in "Annoy: Your
Roommate's Annoying Adventure Game". It's a rigged demo; I'll talk
about the problem with it below.
================
The Stupid Maze
You're in "Wispy Strands of Misty Fog".
How original. Starting out in a stupid maze is almost enough to make
you quit right away. But maybe it won't be too hard to find the exit.
> w
The Stupid Maze
You're in "Wispy Strands of Misty Fog".
Same description again. Wait. Are you in "brief" or "verbose" mode?
Is this a new location, or is the game just repeating the description?
> brief
That's not a verb I recognize.
Jerry must have disabled those commands. How annoying. You glance at
him, and he smirks back. This doesn't make you feel any better.
> i
Jerry says, "It's about time you did that". You suppress an urge to
punch him.
You are carrying:
a random object
> x object
A nondescript object, the type you find in adventure games.
Well, it actually does have a description. It's supposed to be a
conch shell, and there's an absurdly long paragraph that tells you how
its "delicate pinkness" is "spinetinglingly beautiful", and how it
reminds you of your loving father, who mysteriously disappeared ten
years ago, when you were only twelve years old, while your family was
visiting the Grand Canyon, etc. (There was a tacky souvenir conch
shell at the shop in Death Valley, and everyone laughed at it.)
This must be Jerry's idea of plot exposition. It's pretty clear that
none of it is relevent to your immediate problem. The conch is
probably just something you drop to help map the maze, unless you're
supposed to do something silly like blow in it to dispel the fog.
> blow in conch
It makes a "mournful moaning", which triggers another page of
exposition that you skim through. There's nothing important in it.
Nothing that helps you leave the maze.
> l
The Stupid Maze
You're in "Misty Strands of Wispy Fog", and you wish you weren't.
> drop conch
Okay.
> w
The Stupid Maze
You're in "Misty Strands of Wispy Fog".
You can see a random conch here.
In the reflection from the computer screen you see Jerry failing to
stifle an evil grin. With a sinking feeling, you realize that Jerry
probably used every nasty trick in the book to make this maze. This
could get beyond annoying. So now you have to consider, is this the
same random conch you dropped or not?
> x conch
Do you really want to read about your lost father again?
> no
I don't blame you. But anyway, as far as you can tell, the
description is exactly the same. Of course, this doesn't mean it has
to be the same conch. Jerry's snickering would suggest that it's not.
Consider... Jerry strapped to a dentist's chair. Take a dentist's
drill in one hand, hold up a conch in the other, and ask him, "Is it
the same?" "The same as what?" he shouts, but nothing he says stops
you from gently performing root canal surgery without anesthetic.
A pleasant moment of fantasy. Well, there's no dentist's chair handy.
Back to the annoying reality of the maze.
> punch jerry
Yes, that might work, but Jerry is your partner for the CS487
project--something else you wish you could have avoided. And you
really need to ace that course. Jerry, of course, doesn't.
================
The idea for this started out much simpler. Just the maze, and no
random object. If the player is mostly limited to moving around, the
narrative can be mapped out as a dag. This is just exponential
complexity, which I can handle. :)
But the random object adds combinatorial complexity, which I can't
handle. The player can fiddle with the object or fiddle with the
maze, in any order, and the narrative has to reflect what the player
did and didn't do. If the player exits the maze without ever looking
at his inventory, then the initial description of the conch should be
pretty different. There are dozens of decision points that affect the
narrative, and I don't know how to keep things under control.
Somewhere, I have scraps of paper with abortive attempts at making a
dag of this. It really didn't work out.
Next attempt, I think I'll write out a couple different narratives and
see if I can find a structure that fits them. I have a vague fear
that this thing won't be doable without solving the AI storyteller
problem, but I'm hoping I can fake it with something simpler.
I can almost see how to do it. In principle, every description can be
implemented as an if-statement based on key conditions, like "has the
player moved?" etc. But I don't know how to map out the structure.
--
The Essential Addition
I hate to say this, but "Annoy" shouldn't be a text adventure. It should
be an exceptionally funny piece of fiction, based on the output from a
script file of the game. You started something extremely amusing, but
what makes it amusing is the development. Someone else could just sit
there and type directions and it would be fairly mundane.
In fact, you've made me want desperately to write it. Care to hand over
the permission? (I respect the unwritten copyright laws of the Internet,
so if you really think you're going to do something with this, my hands
are off)
--
_____________________________________________________
rbryan@ =--> ....... | ............... | ....... |...| ....|
netcom.com | ..... | ...... | ...|..| .... |.... .... | The Essential
|......|..........|.................|......|.....|.. =--> Addition
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Essential Addition
Jacob S. Weinstein <jac...@usnet.us.net> wrote:
>I disagree completely. If he can overcome the technical obstacles he
>mentioned, it has the potential to be a fantastic game. Obviously, if the
>commands and responses he posted are the only interesting ones, it's
>better off as a script file. But that's true of _any_ piece of
>interactive fiction; if there's only one specific set of commands that
>produces an interesting response, it's not very interactive, is it?
>Give the man some credit, and assume that he has more ideas than the
>couple of lines he posted.
It's funny how often people with nothing to do with a subject can become
so uppity about it. I'm sure the author has many good ideas, and could
make an excellent game. All I want is the opportunity to write a piece
of linear fiction based on the same concept. The author gave me that
permission, and I'll probably work on it in the near future.
Felix Lee
>I hate to say this, but "Annoy" shouldn't be a text adventure. It should
>be an exceptionally funny piece of fiction, based on the output from a
>script file of the game.
Well, that would be much easier to implement :). But it's not quite
what I had in mind.
Part of the point is to try to make every sequence of events
interesting to read. The maze isn't really a puzzle. It's supposed
to be an interactive narrative experience.
For now, almost everything about the maze is a red herring. There
isn't really a solution to it other than "exit maze" or "solve maze".
>In fact, you've made me want desperately to write it. Care to hand over
>the permission? (I respect the unwritten copyright laws of the Internet,
>so if you really think you're going to do something with this, my hands
>are off)
I'm not very proprietary about what I post, so feel free to use or
adapt it if you like. But I haven't quite given up on implementing
this in IF form yet. It'll take another dozen man-hours or so without
progress before I let it lapse into just linear fiction.
--
Adam Justin Thornton
Felix Lee <fl...@cse.psu.edu> wrote:
>I guess I should try to aggressively break this down into small pieces
>that function mostly independently.
Right. And if you have a set of flags not specified in your "cute custom
responses" set, yave the game respond (with apologies to Scott Adams):
YOU CAN'T DO THAT...YET!
"You can't do that yet," Jerry smirks smugly. Your urge to throttle him
is becoming irresistable.
Whaddya think?
Adam
--
ad...@io.com | ad...@phoenix.princeton.edu | Viva HEGGA! | Save the choad!
"Double integral is also the shape of lovers curled asleep" : Pynchon
64,928 | TEAM OS/2 | "Ich habe einen Bierbauch!" | Linux | Fnord
You can have my PGP passphrase when you pry it from my cold, dead brain.
Felix Lee
>Give the man some credit, and assume that he has more ideas than the
>couple of lines he posted.
heh. If you want grandiose ideas: if I can successfully abstract the
metafictional aspect of this, I was going to try to allow for a
randomly selected roommate and a randomly selected "random object".
But this is looking very iffy at the moment.
--
Damien P. Neil
>The "It's about time" speech should only be triggered if
>- this is the first time you "i".
>- you've done a few substantial actions beforehand.
How does this sound?
You have a number of threads of action that the player may pursue at
any one time; parallel branches on the plot tree, really. One could
involve the random object, another wandering around in the fog, and
a third interacting with Jerry. (I have a suitemate named Jerry,
incidentally...)
Any action the player performs will either be associated with one
thread, or with no thread in particular. (Or maybe even with multiple
threads, to get complicated. (As if this wasn't getting complicated
already.))
At any one point in time, the player will be in a particular thread.
Performing an action related to a different thread moves the player
out of the current one and into the other, perhaps resulting in a
message of some sort.
At the start of the game, then, trying to move north places the player
into the `wander' thread, at the top node of it's tree. Entry to this
node sparks a response, say...
> n
Ah, well. You may as well try to find a way out of this bloody maze
so you can finish the game and get back to reading Chomsky's latest
book.
You are lost in the mists...
Let's say that the player then decides to look at her inventory. This
action is related to the `object' thread. The player is moved out of
the `wander' thread, producing a response, into the object thread,
producing another, and into the top node of the `object' tree for a
third.
> i
You've never liked mazes, and wandering at random through this one just
doesn't spark your interest. Maybe you have something in your inventory
that will provide an easy way out.
Jerry says, "It's about time you did that". You suppress an urge to
punch him.
You are carrying:
a random object
The first sentance is produced by leaving the `wander' thread. Since
the player is only in the root node of the tree, she gets a message
that reflects her lack of exploration. Had she continued to wander
about, entering a second node, a different message might have been
produced. For example, ``You've never liked mazes, and this one looks
impossible to figure out.''
The second sentance comes from entring the `object' thread. It exists
mainly to smooth the transition in this case. Had the player already
progressed some distance through the `object' thread, a differect
message would be used. The second paragraph is produced for the same
reason.
Incidentally, transition messages like the above two probably could get
very tedious in short order. I'd stop printing them after the first
few times, unless the threads being switched between are highly unrelated.
Entring the root node of the `object' tree prints nothing of note in
this case.
>Another complication: a repeat player might "x object" before doing
>"i", in which case the speech should be suppressed.
>
>As a logical extension of Jerry's character, the speech should also be
>triggered by a late "x object", if it hasn't been triggered already.
Examining the object before taking inventory jumps the player directly
to the second node of the `object' tree. Skipping a node in this
fashion should result in a message of some sorts (``You've played this
game before.'').
>I don't see a way of fitting this into a general plot dag. Well, I
>can build a dag for just this thing. Maybe I should be making a
>forest of dags.
That's essentially my idea.
>This is a curiously large amount of effort for just a small bit of
>atmosphere. I'd be much happier if there were a general, reusable
>technique for handling things like this.
I think that my described technique, while rather non-trivial to implement,
could be made very reusable. Once set up properly, it should hopefully
reduce the effort required to maintain the branching plotlines tremendously.
I disagree about the `small bit of atmosphere', however. In my opinion,
the sample transcript you offered shows more atmosphere than almost
every other text adventure I've seen. To have the player interact with
the game on such a personal leverl would be wonderful.
>I guess I should try to aggressively break this down into small pieces
>that function mostly independently.
That sounds like a good idea.
I love this game idea. I hope you write it.
- Damien
Felix Lee
>Let me understand the problem.
>The Annoy game is written by the roommate.
[...]
No, that isn't quite right. The roommate's game, call it "Tsorque",
isn't a real game. At the moment, The Stupid Maze is being
implemented as just one room, though I may change it to two rooms for
technical reasons.
The boundary between "Annoy" and "Tsorque" is deliberately fuzzy, so I
don't want to provide separate prompts for them.
The task of "Annoy" is to provide an interactive story, and the real
problem is making the narrative smoothly connected. As far as I can
tell, a plot map doesn't quite work for this.
Let me try to work out a small example. Here's one piece of that
transcript:
> i
Jerry says, "It's about time you did that". You suppress an
urge to punch him.
You are carrying:
a random object
The "It's about time" speech should only be triggered if
- this is the first time you "i".
- you've done a few substantial actions beforehand.
"Substantial action" is anything that can be considered a direct
attempt to solve the maze, like any type of movement. It doesn't
include things like "examine fog", but it might include things like
"blow on fog". It does include "brief", but not "verbose".
Another complication: a repeat player might "x object" before doing
"i", in which case the speech should be suppressed.
As a logical extension of Jerry's character, the speech should also be
triggered by a late "x object", if it hasn't been triggered already.
I don't see a way of fitting this into a general plot dag. Well, I
can build a dag for just this thing. Maybe I should be making a
forest of dags.
Actually, this speech should be triggered any time the player is slow
in performing an "obvious" action, but no more than once. The
definition of "slow to act" depends on what the action is...
This is a curiously large amount of effort for just a small bit of
atmosphere. I'd be much happier if there were a general, reusable
technique for handling things like this.
Complications after the speech: the narrative is practically inviting
the player to immediately "punch jerry" or something similar. Later
in that transcript, "punch jerry" evokes the response:
Yes, that might work, but Jerry's your partner for the CS487
project--something else you wish you could have avoided.
which doesn't really make sense in this context. "Yes, that might
work," is misplaced. The right response in this case is something
more like:
It's not really worth it. Besides, Jerry's your partner ...
One way to cope with this is to make the "punch jerry" response more
generic, something that makes sense in any context. But I want "punch
jerry" to actually work and have an effect in some cases. I think one
possible ending for "Annoy" is to kill your roommate.
Hmm, I could probably handle "punch jerry" in a slightly different way
way...
I guess I should try to aggressively break this down into small pieces
that function mostly independently.
--
Jacob S. Weinstein
>
>I hate to say this, but "Annoy" shouldn't be a text adventure. It should
>be an exceptionally funny piece of fiction, based on the output from a
>script file of the game. You started something extremely amusing, but
>what makes it amusing is the development. Someone else could just sit
>there and type directions and it would be fairly mundane.
>
mentioned, it has the potential to be a fantastic game. Obviously, if the
commands and responses he posted are the only interesting ones, it's
better off as a script file. But that's true of _any_ piece of
interactive fiction; if there's only one specific set of commands that
produces an interesting response, it's not very interactive, is it?
couple of lines he posted.
-Jacob
David Whitten
The Annoy game is written by the roommate.
You want to keep track of commands given to the game so that you can
generate a 'commentary' on what you are doing in the game.
You also want to keep track of commands that you haven't given Annoy,
but have given to the game running on your computer
(like the kill roommate command)
It seems you need some way of distinguishing these (to the player of your
game) it makes sense to have a different looking prompt. (I didn't see you
do this) and maybe a single letter command to switch back and forth between
the two games.
Since most of this game stems on 'keeping track of you frame of mind',
(so you give the appropriate running commentary)
maybe the plotmap idea will do what you want. Keep a ghost object in the
game that represents the 'current plot point' and link the rooms that the
ghost object moves in by what you have told the annoy game to do.
ie: the ghost object might start in a room 'Hopeful about Game', and then
telling annoy to go west (or anyother direction) would move you into the
'Tried a Direction Situation'. Doing it again would move you to a 'Convinced
that Direction commands don't work Situation'.
then you have several different plotmap locations so the 'Inventory' command
to the Annoy game can actually follow seperate exit-choice paths to
different Situation rooms.
I hope I have explained this well.
I am willing to elaborate or even start from scratch if this makes little or
no sense.
David (whi...@netcom.com) (214) 437-5255
Greg Ewing
In article <whittenC...@netcom.com>, whi...@netcom.com (David Whitten) writes:
|> Keep a ghost object in the
|> game that represents the 'current plot point' and link the rooms that the
|> ghost object moves in by what you have told the annoy game to do.
What if this "ghost object" is the player himself?
I.e. a "room" in this game isn't really a room, it's
a game-state. This is actually quite an interesting
idea - a game where you're wandering around a plot
dag instead of a dungeon! Bizarre...
|> David (whi...@netcom.com) (214) 437-5255
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.|
gr...@cosc.canterbury.ac.nz +--------------------------------------+
Felix Lee
>You have a number of threads of action that the player may pursue at
>any one time; parallel branches on the plot tree, really. One could
>involve the random object, another wandering around in the fog, and
>a third interacting with Jerry.
hmm. I'll have to think about it, but my instinct is the narrative
can't really be divided into separate strands like that.
my current idea is to write the game out as a number of dags that run
in parallel. well, they're not quite dags. lemme work out two of
them (the "It's about time" speech, and the stuff with brief/verbose).
--
DBlaheta
Anyway, I have pretty much followed the thread so far, and I'd just like
to make a couple points:
First, I've never heard of plot "dag"s. I assume this is shorthand for
"diagram". Anyway, what might be useful is an actual, rigorous,
Finite-State Automaton. Which basically means, *define* each *possible*
state, and what actions can cause transition to another state. Thus, if
start-of-game is the 0 node:
(0)
and there are, say (for simplicity's sake) two choices; type "brief" or
move.
(0)
A/ \B
(1) (2)
"A" is the typing of "brief". Then, state (1) is that of having tried
brief. There is, of course, a transition sequence for each "edge" or
connection between states. Some sequences will be identical, of course.
My guess, based on the transcript posted, is that this is approximately a
twenty-state FSA, with about 30 connections total and maybe a total of
about 20 *different* transition sentences. So, it might be a slight pain
to code, but once established in this manner you can bounce back into a
slightly more linear format except for major decision points.
Also, in a game of this interactivity and complexity, you have to make
sure to bottleneck often. Otherwise, you will double or triple your work.
In a simple binary tree w/o bottlenecks, you have branching as follows:
/
/\
/\/
/\/\
/\/\/
/\/\/\
\/\/\/
\/\/\
\/\/
\/\
\/
\
which, as you can see, by the sixth branch-point, is a hugely-noded tree
which you *don't* want to deal with. By contrast, with a bottleneck:
/\
/\/\/\
\/\/\/
\/
Obviously, my diagrams are simplified. But for each time you bottleneck,
you save yourself that much more work without totally linearizing it.
(Incidentally, you can bottleneck without being totally linear: by
defining areas in which certain states are possible, and careful
definition of states, you can come out with rather more complex
tree-structures without increasing coding complexity significantly.)
Sorry if I slipped into lecture-mode for a moment there, but these were a
whole bunch of applications-based ideas which have been percolating for
quite some time now. :)
Don Blaheta
dbla...@aol.com
bla...@quincy.edu
Felix Lee
Don Blaheta:
>My guess, based on the transcript posted, is that this is approximately a
>twenty-state FSA, with about 30 connections total and maybe a total of
>about 20 *different* transition sentences.
It's a little more complicated than that. For one, there's an
"annoyance" counter for the player and for Jerry. The player's
annoyance counter affects the narrator's interpretation of the
player's actions. Jerry's annoyance counter affects his response to
the player's actions. (Well, this is one of the things I haven't
worked out in detail yet, so I might have to scrap it.)
But even without the annoyance counters, the game has a substantial
amount of state that isn't easily captured by a single FSA.
Part of the point of this exercise is to avoid "tree fiction
syndrome". Yes, there are bottlenecks in the plot--exiting the maze
is a bottleneck. But the actions in the maze have consequences beyond
the bottleneck. Different playing sessions will result in different
game states at that bottleneck. In theory.
--
Greg Ewing
In article <3akh68$b...@newsbf01.news.aol.com>, dbla...@aol.com (DBlaheta) writes:
|>
|> First, I've never heard of plot "dag"s. I assume this is shorthand for
|> "diagram".
Actually it stands for "directed acyclic graph", which
means a structure made up of nodes and links between
the nodes (a graph), where each link has a direction
associated with it (directed), and there are no
loops if you follow the links along their directions
(acyclic).
I'm not sure if a plot graph really needs to be
acyclic - if there were a loop, all it would mean
is that there is some change you can make to the
game state that is undoable, and you can return
the game to an earlier state. Disallowing cycles
could be useful, however, if you want to process
the graph in ways that involve systematically
visiting each node.
|> Anyway, what might be useful is an actual, rigorous,
|> Finite-State Automaton.
This is really the same thing - an FSA is a directed
graph with conditions associated with moving along
the links.
|> Don Blaheta
|> dbla...@aol.com
|> bla...@quincy.edu
Felix Lee
>YOU CAN'T DO THAT...YET!
> "You can't do that yet," Jerry smirks smugly. Your urge to throttle him
> is becoming irresistable.
ah, good idea. I'll keep it in mind, though probably not quite in
this form. It's not quite in character for Jerry. Not unless he gets
really demented. Jerry's game might say it though.
--
Magnus Olsson
Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
>
>In article <3akh68$b...@newsbf01.news.aol.com>, dbla...@aol.com (DBlaheta) writes:
>|>
>|> First, I've never heard of plot "dag"s. I assume this is shorthand for
>|> "diagram".
>
>Actually it stands for "directed acyclic graph", which
>means a structure made up of nodes and links between
>the nodes (a graph), where each link has a direction
>associated with it (directed), and there are no
>loops if you follow the links along their directions
>(acyclic).
>
>I'm not sure if a plot graph really needs to be
>acyclic
An interesting idea. I had the same thought after reading all
this discussion about plot DAG's earlier.
> - if there were a loop, all it would mean
>is that there is some change you can make to the
>game state that is undoable, and you can return
>the game to an earlier state.
I think this depends on what you want your DAG to describe:
does it describe the state of the plot (as the name "plot
DAG would seem to suggest), the state of the game, or the
state of the system of game + player? THis is a difficult
question, since these concepts aren't necessarily
sperable. Felix' description of "Annoy" is an example of a
game where the player's state of mind isn't separable from
the plot.
>Disallowing cycles
>could be useful, however, if you want to process
>the graph in ways that involve systematically
>visiting each node.
I think it's not just a question of what's useful in this sense (i.e.
what limitations should be accepted on the plot to make it amenable to
some analysis technique) but rather a question of finding a model
that's useful in the sense that it *can* describe the actual
situation.
Consider the following situation in a game:
You are in a small room with uniformly grey walls, ceiling
and floor. The only remarkable feature of this room is a big switch
on the wall. The switch is in the "on" position.
> flip switch.
The lights turn off. It's now pitch dark in here.
> flip switch
The lights are now on again
Now, what does this little trivial example imply about the plot DAG?
Do we have a cycle? Well, of course that depends on whether the
player's actions ahve brought the game back to exactly the same state
as before (which isn't necessarily true - there may be other effects
than turning off the lights, effects that aren't reversed by turning on
the lights again. For example, turning off the lights may alert
somebody that you've entered the room). And even if everyting is just
like before, the turn counter has advanced, so the game isn't in
the same state as before.
Perhaps a full "Undo" capability will introduce loops in the DAG? Only
if the player's state of mind isn't included in the plot. My own
opinion is that the plot is advanced by the player's learning the effects
of flipping the switch.
Of course, even though the game itself can keep track of this across
undos, it can't across save-exit-restore cycles. This may be a problem for
games like "Annoy", a problem we might have to live with.
>|> Anyway, what might be useful is an actual, rigorous,
>|> Finite-State Automaton.
With no disrespect to DBlaheta, this shows the danger of jumping into
a discussions with opinions about things one hasn't really understood.
Actually, discussing plot in terms of a DAG is just as rigorous as
discussing it in terms of an FSA - or just a s unrigorous. The last
point is important; we must not confuse the rigour of our models with
the rigour of our entire reasoning. We can be as rigorous as we please
about our DAG's and FSA's; still, as long as we're not quite sure what we're
tyrring to model we can't expect any rigour in the results.
(This is not said to belittle any existing systems for plot modelling;
I'm sure the authors know what they're doing).
>This is really the same thing - an FSA is a directed
>graph with conditions associated with moving along
>the links.
But an FSA is in general not necessarily described by a DAG, but by a
cyclic graph.
Magnus Olsson (m...@df.lth.se) / yacc computer club, Lund, Sweden
Work: Innovativ Vision AB, Linkoping (magnus...@ivab.se)
Old adresses (may still work): mag...@thep.lu.se, the...@selund.bitnet
PGP key available via finger (to df.lth.se) or on request.
Greg Ewing
|> > flip switch.
|>
|> The lights turn off. It's now pitch dark in here.
|>
|> > flip switch
|>
|> The lights are now on again
|>
|> Now, what does this little trivial example imply about the plot DAG?
|> Do we have a cycle?
It depends on what aspect of this is relevant to the
plot. If the relevant thing is "the player has experimented
with the light switch" then there is no cycle, since the
player can't un-experiment with it once he's done it.
I suspect that most of the things a plot graph will be
concerned with are things like that which are inherently
one-way. The plot graph is there to keep track of state
changes that aren't already implicit in the state of the
game. If the only thing you cared about was whether the
switch was on or off, you wouldn't need to have
anything about it in the plot graph.
|> Perhaps a full "Undo" capability will introduce loops in the DAG?
I think "undo" is better regarded as a totally meta-activity
which reverses time, and therefore there are no links in the
plot graph corresponding to "undo" commands.
|> Magnus Olsson (m...@df.lth.se) / yacc computer club, Lund, Sweden
|> Work: Innovativ Vision AB, Linkoping (magnus...@ivab.se)
|> Old adresses (may still work): mag...@thep.lu.se, the...@selund.bitnet
Greg Ewing, Computer Science Dept, +--------------------------------------+