UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO

CENTRO DE CINCIAS EXATAS E TECNOLOGIA

PROGRAMA DE PS-GRADUAO EM INFORMTICA

CONCILIANDO COERNCIA E RESPONSIVIDADE EM STORYTELLING

INTERATIVO PARA TV DIGITAL

Marcelo de Mello Camanho

Orientador
Prof. Dr. Angelo Ernani Maia Ciarlini
RIO DE JANEIRO, RJ BRASIL
ABRIL DE 2009

CONCILIANDO COERNCIA E RESPONSIVIDADE EM STORYTELLING

INTERATIVO PARA TV DIGITAL
Marcelo de Mello Camanho
DISSERTAO SUBMETIDA AO CORPO DOCENTE DO PROGRAMA DE PSGRADUAO EM INFORMTICA DA UNIVERSIDADE FEDERAL DO ESTADO
DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSRIOS PARA A
OBTENO DO GRAU DE MESTRE EM INFORMTICA.
Aprovada por:

RIO DE JANEIRO, RJ - BRASIL

ABRIL DE 2009

C172

Camanho, Marcelo de Mello.

Conciliando coerncia e responsividade em storytelling interativo
para TV digital / Marcelo de Mello Camanho, 2009.
xi, 113f.
Orientador: Angelo Ernani Maia Ciarlini.
Dissertao (Mestrado em Informtica) Universidade Federal do
Estado do Rio de Janeiro, Rio de Janeiro, 2009.
1. Sistemas multimdia. 2. Storytelling interativo. 3. Inteligncia
artificial. 4. Televiso digital. 5 Sistemas de informao. 6. Execuo,
gerao e formao de planos. I. Ciarlini, Angelo Ernani Maia. II. Universidade Federal do Estado do Rio de Janeiro (2003-). Centro de
Cincias Exatas e Tecnologia. Curso de Mestrado em Informtica.
III. Ttulo.
CDD 006.7

iii

Agradecimentos

Agradeo minha famlia; meus pais; minha namorada; meus amigos e meus
professores, em especial a meu orientador, por toda a ajuda que me deram ao longo
destes anos. Para evitar esquecer algum, no citarei nomes. Tambm agradeo
CAPES pela ajuda financeira.

iv

Resumo da Dissertao apresentada ao PPGI/UNIRIO como parte dos requisitos

necessrios para a obteno do grau de Mestre em Cincias (M.Sc.)

CONCILIANDO COERNCIA E RESPONSIVIDADE EM STORYTELLING

INTERATIVO PARA TV DIGITAL

Marcelo de Mello Camanho

Abril/2009

Orientador: Angelo Ernani Maia Ciarlini

A televiso interativa um novo meio onde muitas formas de entretenimento

sero possveis, juntando interatividade e contedo multimdia digital. Uma
possibilidade de entretenimento digital promissora para este novo meio o uso de
sistemas de storytelling interativo, que permitem a gerao, visualizao e controle de
histrias interativas. O principal desafio para esses sistemas gerar histrias coerentes
enquanto os usurios as assistem e interferem no que est acontecendo. Em um
ambiente de TV, a manuteno da responsividade tambm essencial, porque o pblico
est acostumado a ter suas expectativas atendidas com rapidez, sem que isso
comprometa a qualidade do servio. Neste trabalho apresentado um modelo de
storytelling interativo para atender estas demandas, usando como base o sistema Logtell.
O Logtell um sistema j existente que focado na simulao baseada em lgica das
histrias. A extenso do modelo original tem por intuito atender aos requisitos
adicionais de um ambiente de TV interativa.

Abstract of Dissertation presented to PPGI/UNIRIO as a partial fulfillment of the

requirements for the degree of Master of Science (M.Sc.)

CONCILIATING COHERENCE AND RESPONSIVENESS IN INTERACTIVE

STORYTELLING FOR DIGITAL TV

Marcelo de Mello Camanho

April/2009

Advisor: Angelo Ernani Maia Ciarlini

Interactive television is a new medium in which many new forms of

entertainment will be possible, bringing together interactivity and digital multimedia
content. One of the promising alternatives for digital entertainment for this new medium
is the use of interactive storytelling systems, which allow generation, visualization and
control of interactive stories. The main challenge to these systems is the generation of
coherent stories while users are watching and interfering with what is happening. In a
TV environment, keeping the responsiveness is also essential, because the audience is
used to have their expectations fulfilled without compromising the quality of service. In
this work, an interactive storytelling model is presented to meet those demands, based
on the Logtell system. Logtell is an already implemented system which is focused on the
logic-based simulation of stories. The extension of the original model was intended to
cope with the additional requirements of an interactive TV environment.

vi

Sumrio
1. Introduo......................................................................................................................1
1.1 Motivao................................................................................................................1
1.2 Proposta...................................................................................................................2
1.3 Prottipo..................................................................................................................3
1.4 Estrutura...................................................................................................................4
2. Storytelling Interativo....................................................................................................5
2.1 Modelos de Gerao de Histrias............................................................................7
2.1.1 Abordagens Centradas em Personagens (Character Based)..................................8
2.1.2 Abordagens Centradas na Trama (Plot Based)......................................................9
2.1.3 Abordagens Hbridas e Outras Abordagens .......................................................12
2.2 Interactive Storytelling e Planejamento Automatizado..........................................16
2.3 Concluses.............................................................................................................18
3. Televiso Interativa .....................................................................................................21
3.1 Interatividade e Televiso......................................................................................23
3.2 Aplicaes e Servios na Televiso Interativa ......................................................24
3.3 TV Digital Interativa..............................................................................................27
3.3.1 Transmisso de Dados........................................................................................27
3.3.2 Middleware.........................................................................................................28
3.4 Outros Ambientes e Abordagens para TV Interativa.............................................29
3.5 Concluso..............................................................................................................31
4. Logtell..........................................................................................................................33
4.1 Gerao de histrias...............................................................................................34
4.2 Interao com o Usurio........................................................................................40
4.3 Dramatizao.........................................................................................................41
4.4 Demais Aspectos....................................................................................................44
4.5 Concluses.............................................................................................................45
5. Modelo de Storytelling Interativo para TV..................................................................47
5.1 Requisitos..............................................................................................................47
5.1.2 Fluxo Contnuo...................................................................................................47
5.1.3 Diversidade de Enredos......................................................................................49
5.1.4 Coexistncia com Modo Passo-a-passo..............................................................50
5.1.5 Facilidade de Interao e Possibilidades de Interao em Diversos Nveis.......51
5.1.6 Escalabilidade.....................................................................................................52
5.2 Arquitetura Cliente-Servidor.................................................................................52
5.3 Interao Contnua.................................................................................................56
5.3.1 Intervenes Fracas: Rewind e Another.............................................................57
5.3.2 Intervenes Fortes.............................................................................................58
5.4 Interao com Mltiplos Usurios.........................................................................59
5.5 Estratgias para Manuteno do Fluxo..................................................................60
5.6 Mecanismos Avanados de Interao....................................................................61
5.7 Concluses.............................................................................................................62
6. Implementao.............................................................................................................63
6.1 Ambiente da Aplicao..........................................................................................63
6.2 Simulation Controller............................................................................................67
vii

6.3 User Interface.........................................................................................................72

6.4 Interface Controller................................................................................................76
6.5. Concluses............................................................................................................77
7. Aplicao do Prottipo................................................................................................79
7.1 Continuidade do Fluxo..........................................................................................80
7.2 Diversidade e Coerncia das Histrias..................................................................84
7.3 Facilidade e Comodidade da Utilizao................................................................88
7.4 Escalabilidade........................................................................................................89
8. Concluses e Trabalhos Futuros..................................................................................91
8.1 Consideraes Gerais.............................................................................................91
8.2 Principais Contribuies........................................................................................91
8.3 Trabalhos Futuros..................................................................................................93
Referncias Bibliogrficas...............................................................................................96
Apndice A Arquiteturas e Padres Para a TV Digital Interativa...............................105

viii

Lista de Figuras
Figura 2.1: Dramatizao de algumas histrias de (CAVAZZA et al., 2002)...................9
Figura 2.2: Teatrix em ao.............................................................................................10
Figura 2.3: Arquitetura de (GRASBON e BRAUN, 2001).............................................11
Figura 2.4: Arquitetura de (SPIERLING et al., 2002)....................................................12
Figura 2.5: Faade e seus dois atores na viso 3D do usurio.........................................14
Figura 2.6: Arquitetura proposta por (SZILAS, 2003).....................................................14
Figura 2.7: Prottipo de (SZILAS, 2008), modo texto....................................................15
Figura 2.8: Uma HTN do protagonista de CAVAZZA et al., 2002..................................16
Figura 2.9: Framework de (SI et al., 2008)......................................................................17
Figura 4.1: Arquitetura inicial do Logtell........................................................................34
Figura 4.2: Interao passo a passo..................................................................................41
Figura 4.3: Histria sendo dramatizada no Logtell..........................................................42
Figura 5.1: Nova arquitetura do Logtell no modelo proposto.........................................53
Figura 5.2: Interao contnua.........................................................................................57
Figura 6.1: Beans J2EE do prottipo...............................................................................67
Figura 6.2: Mtodos principais implementados no SimulationControllerBean..............68
Figura 6.3: Submdulos do Simulation Controller..........................................................71
Figura 6.4: Interface inicial do Logtell............................................................................72
Figura 6.5: Escolha de contexto.......................................................................................72
Figura 6.6: Novas classes para a interface com o usurio...............................................73
Figura 6.7: Interface do modo passo-a-passo..................................................................74
Figura 6.8: Interface do modo contnuo...........................................................................75
Figura 6.9: InterfaceControllerBean................................................................................76
Figura 7.1 Modo multiusurio com dois clientes assistindo mesma histria...............90

ix

Lista de Tabelas
Tabela 4.1: Predicados usados no contexto exemplo do Logtell e suas descries.........37
Tabela 4.2: Lista de Eventos possveis no contexto exemplo do Logtell........................38
Tabela 4.3: Lista de regras no exemplo do Logtell..........................................................39
Tabela 7.1: Exemplo de narrativa sem interferncias......................................................81
Tabela 7.2: Alguns tempos para o Rewind......................................................................82
Tabela 7.3: Alguns tempos para o Another......................................................................82

Lista de Abreviaturas
API

Application Programming Interface

ATSC

Advanced Television Systems Committee

DAO

Data Access Object

DLL

Dynamic-link library

DTV

Digital Television

DVB

Digital Video Broadcasting

EJB

Enterprise Java Bean

HDTV

High Definition TV

HTN

Hierarchical Task Network

IPG

Interactive Plot Generator

ISDB

Integrated Service Digital Broadcasting

ISDB-TB

Integrated Services Digital Broadcasting Terrestrial (do Brasil)

ITV

Interactive Television

JDBC

Java Database Connectivity

JDK

Java Development Kit

JMS

Java Messaging Service

JNDI

Java Naming and Directory Interface

JSP

Java Server Page

MPEG

Moving Picture Experts Group

NPC

Non Player Character

POJO

Plain Old Java Object

RPG

Role Playing Game

SBTVD

Sistema Brasileiro de Televiso Digital

SDTV

Standard Definition TV

UHDV

Ultra High Definition Vdeo

URD

Unidades Receptora-decodificadora

xi

1. Introduo
1.1 Motivao
Sistemas de storytelling interativo so, resumidamente, aplicaes que contam
histrias, que, com base no uso mecanismos automatizados, procuram adaptar as
histrias de acordo com as interaes que tm com os usurios. So diferentes de jogos
porque se focam nas histrias e no seu contedo dramtico, em vez de em desafios
pontuais intercalados com trechos de histrias pr-escritas.
Sistemas de storytelling interativo tm sido pesquisados para diferentes
aplicaes e implementados de diferentes modos. Podem ser aplicados a jogos, auxlio
autoria de histrias e a entretenimento em geral. Uma das dificuldades mais comuns ao
se criar um sistema de storytelling interativo fornecer um bom nvel de interatividade
e cativar o usurio, enquanto se mantm a coerncia da histria que gerada.
O advento da TV interativa, seja por meio da TV digital aberta ou de outros
ambientes, cria uma oportunidade interessante para a aplicao de tcnicas de
storytelling interativo, pois, se a TV j era um meio clssico para a veiculao de
histrias, de se esperar que, ao se adicionarem mecanismos de interao, consigam-se
produzir bons produtos. Nesse ambiente, alguns requisitos, tais como qualidade,
coerncia e diversidade das histrias, e facilidade e comodidade da interao, tendem a
se tornar ainda mais fortes.
O prazer do usurio, ao assistir uma histria na TV, est ligado qualidade da
histria. Como a coerncia do enredo fundamental para essa qualidade, torna-se ainda
essencial que as oportunidades de interao no a comprometam. Alm disso, as
histrias precisam ser variadas e capazes de surpreender para que o usurio no se canse
de assistir a elas.
Para o usurio interagir com as histrias, preciso encontrar uma forma hbrida
de apresentao de contedo multimdia, misturando caractersticas de jogos e televiso
normal. necessrio manter o apelo para o espectador comum, e, ao mesmo tempo,
permitir que o usurio seja capaz de interagir de diferentes maneiras com o contedo
que lhe apresentado.
Deve-se, inclusive, considerar o fato de que o usurio pode nem mesmo querer
interagir de modo algum. A sensao de conforto na interao fundamental,
especialmente quando se considera que as histrias, em geral, sero assistidas por
espectadores que podem no ser vidos usurios de jogos eletrnicos.
1

Mdias como a TV demandam alta responsividade, ou seja, a satisfao rpida

das expectativas dos usurios sem que isso comprometa a qualidade do servio. Quando
se assiste TV, espera-se que o contedo apresentado no sofra interrupes ao longo
do tempo. Alm disso, programas de TV tendem a ser acompanhados por uma grande
quantidade de espectadores. Dessa forma, requisitos de responsividade adicionais
relacionados continuidade do fluxo de apresentao e escalabilidade precisam ser
conciliados com os demais requisitos.
Para garantir a coerncia, a qualidade e a diversidade das histrias em conjunto
com boas oportunidades de interao, no se pode depender apenas de um esforo
autoral capaz de delinear todas as possibilidades de enredo, pois os custos tendem a se
tornar facilmente proibitivos. Alm disso, as opes de interveno do usurio ficam
mais restritas nesse caso. Uma alternativa prover mecanismos automticos de criao
de enredos, dando maior liberdade para o usurio interagir e adaptando-se
automaticamente os enredos s intervenes que ocorrem. No entanto, esse
processamento pode ser custoso e, se no houver uma boa estratgia de coordenao, o
fluxo de apresentao do contedo pode ter que ser interrompido, o que certamente
compromete a responsividade esperada em um ambiente de TV.
A motivao deste trabalho a proposio de um modelo de storytelling
interativo para TV onde seja possvel conciliar coerncia e responsividade e que, ao
mesmo tempo, facilite a obteno automtica de histrias variadas, com as quais o
usurio pode interagir de forma cmoda.
1.2 Proposta
O modelo de storytelling interativo para TV proposto nesta dissertao tem
como base o modelo adotado no sistema Logtell, o qual foi estendido para atender aos
requisitos de um ambiente de TV interativa.
O Logtell (CIARLINI et al. 2005; POZZER 2005) um sistema de storytelling
interativo que vem sendo desenvolvido j h algum tempo. A sua abordagem parece ser
boa para TV, pois se centra em manter as histrias coerentes enquanto permite que o
usurio possa interferir na histria em diferentes nveis. Para garantir a coerncia das
histrias, a interao no Logtell sempre indireta. O usurio pode escolher no interferir
na histria, solicitar alternativas ou ter uma participao mais forte, estabelecendo, por
exemplo, que certos eventos ou situaes ocorram, desde que sejam logicamente
coerentes com o modelo especificado para o gnero de histria adotado. A dramatizao
2

da histria no ocorre em tempo real em relao gerao do enredo, podendo ser

ativada aps parte da enredo j ter sido criado, ou quando j estiver completo. A
dramatizao feita com atores tridimensionais, usando um motor grfico prprio
(POZZER 2005), que foi criado para garantir a consistncia do modelo lgico dos
enredos com a dramatizao.
Uma das principais caractersticas da primeira verso do Logtell, que no
apropriada para a televiso interativa, que, nele, a gerao e a dramatizao da histria
so separadas, concentrando-se a interatividade na fase de gerao. Parece pouco
razovel que o usurio de TV aceite aguardar o fim de uma fase de simulao para
assistir dramatizao. Alm disso, deve-se ressaltar que, embora possibilite ao usurio
a interveno em graus variados de intensidade, os meios de interao no Logtell no
tm o nvel de comodidade que se espera de uma aplicao para TV interativa.
A adaptao de um modelo de storytelling interativo como o do Logtell a um
ambiente de TV interativa demanda que se encontrem meios para que a gerao do
enredo, a interao com o usurio e a dramatizao ocorram em paralelo. Nesse
contexto, as oportunidades de interao viveis devem ser cuidadosamente estudadas,
de modo a permitir interaes em diferentes nveis na evoluo da histria, mas de
forma confortvel para o usurio. Alm disso, a coordenao desses processos deve
levar em conta os requisitos de responsividade, que so prprios do ambiente, como a
continuidade do fluxo e a escalabilidade. O novo modelo proposto procura levar em
conta todas essas questes, dando nfase conciliao da coerncia das histrias com a
responsividade.
1.3 Prottipo
Para a validao das principais idias do novo modelo, um novo prottipo do
Logtell foi implementado. As modificaes no sistema foram feitas na parte do sistema
correspondente ao mdulo Plot Manager que coordenava a interao com o usurio e a
ativao dos mdulos de gerao de enredos e de dramatizao. O Plot Manager foi
desmembrado em mdulos em arquitetura distribuda, com o controle e a gerao das
histrias ocorrendo no servidor e a interface com o usurio e a dramatizao sendo
executados nos clientes.
No prottipo que foi desenvolvido foram mantidas as funcionalidades prexistentes do Logtell, e a ela adicionaram-se duas novas maneiras de gerar histrias: o
modo contnuo em multiusurio e tambm no modo de apenas um usurio. Desta forma,
3

o prottipo capaz de mostrar novas maneiras de se ter uma experincia de storytelling

interativo, usando uma arquitetura, como ser mostrado nos captulos adiante, que
distribuda, para dar suporte ao modelo proposto.
Mais detalhes sobre a implementao do prottipo esto presentes nos Captulos
6 e 7.
1.4 Estrutura
No captulo 2, apresenta-se uma viso de geral da pesquisa em storytelling
interativo descrevendo-se as principais questes envolvidas e os enfoques que vm
sendo adotados em diferentes sistemas.
No captulo 3, feito um levantamento das principais questes relacionadas
TV interativa. Inicialmente, so descritas as possibilidades de interao na TV. Em
seguida, so descritos ambientes alternativos para a implementao da TV interativa,
com arquiteturas e padres, dando destaque para a TV digital interativa.
No captulo 4, o modelo original de storytelling interativo do Logtell
apresentado, de modo a dar a base necessria para a compreenso do novo modelo
proposto no captulo seguinte.
No captulo 5, o novo modelo de storytelling interativo para atender aos
requisitos de ambientes de TV interativa descrito.
No Captulo 6, explicam-se os principais pontos da implementao do prottipo
que foi feita para validar as principais idias do modelo proposto no captulo 5.
No captulo 7, feita uma anlise dos testes realizados no prottipo no que tange
ao atendimento aos requisitos do modelo, procurando identificar os pontos
implementados e os pontos ainda no resolvidos.
O captulo 8 contm as concluses da pesquisa com a descrio de suas
principais contribuies e dos trabalhos futuros potenciais, os quais foram identificados
ao longo da elaborao do modelo e dos testes realizados com o prottipo.

2. Storytelling Interativo
Com o advento das novas tecnologias digitais e tambm de suas respectivas
inovaes a respeito de novas interfaces com o usurio, cada vez mais expandem-se as
possibilidades de interao. Sistemas interativos so de grande apelo para muitos:
grande prova disso so os jogos eletrnicos, cada vez mais presentes na sociedade, e em
diversos meios e formatos, que vo desde o telefone celular e o computador at a
televiso digital.
Em relao ao que se pode se chamar de uma das mais antigas artes, a de contar
histrias, existe a recente rea de pequisa do Interactive Storytelling. Trabalhos
fundamentais como (GLASSNER, 2004) discutem as possibilidades e dificuldades do
casamento entre interao e storytelling, histrias no-lineares, e fico interativa.
Histrias so representaes de seqncias de eventos que formam padres
reconhecveis mente humana, que evocam nossos arqutipos culturais intrnsecos e
nos ensinam lies na medida em que so contadas. Tais efeitos so pesquisados
principalmente na rea da psicanlise e afins, como em (FRANZ, 1980), livro da
discpula de Carl Jung, este por sua vez, ensinado por Freud, o pai da Psicanlise. No
entanto, o prprio advento da interatividade quase que antittico ao objetivo de contar
histrias, j que permitir que um usurio tome decises que afetem uma histria parece
ser quase que uma garantia de se poder desestabilizar o difcil equilbrio exigido pelo
autor da narrativa.
Chris Crawford em (CRAWFORD, 2005) define interatividade como um
processo cclico entre dois ou mais gentes ativos no qual cada agente alternadamente
escuta, pensa e age. Partindo desta definio, deve-se esperar de um sistema de
storytelling interativo que este escute os desejos do usurio, e, na medida do possvel,
tente pensar sobre eles, e que ento aja para contar sua histria de maneira
compatvel com os anseios do usurio. Nessa viso, tanto o usurio como o sistema que
conta a histria so agentes que se relacionam. O usurio tambm ter, do seu lado, a
oportunidade de escutar a histria narrada, pensar sobre ela e seus significados, e
ento agir de forma a repetir o ciclo de interao enquanto for desejado (ou possvel).
Um ambiente onde se encontra algo anlogo ao que se deseja para o storytelling
interativo digital, o dos Role Playing Games, ou RPGs. Nos RPGs, os jogadores
participam de uma histria que feita em parte pelo Mestre do Jogo, que geralmente j
tem um certo roteiro escrito de coisas que devem ou podem acontecer, em linhas
5

gerais; e parte pelas vontades e aes dos jogadores, estas sempre submetidas regras
do Jogo e probabilidades, atravs de dados, por exemplo. Os RPGs, porm, quando na
forma eletrnica, comportam-se, em sua maioria, como os jogos eletrnicos comuns.
Tm uma srie de eventos roteirizados ou ento alguns ramos de sries de eventos,
alternados por momentos de controle dos protagonistas pelo usurio, com um certo grau
de influncia sobre a histria, mas nunca com o potencial fornecido pela sua verso no
digital, que tem um autor pronto para adaptar a histria que se desenrola.
Em storytelling interativo, o motor gerador da histria deve ser capaz de gerar
histrias on-the-fly, ou seja, em tempo real, baseado no feedback do usurio, sem utilizar
apenas seqncias de aes previamente escritas ou sries de eventos amarradas, como
vemos em geral nos demais produtos multimdia existentes, tais como jogos eletrnicos,
filmes, etc. Para conseguir isso, necessria uma profunda abstrao do processo de
contar histrias. A melhor maneira de alcanar isto pensando no em um roteiro, mas
sim em um storyworld (CRAWFORD, 2005).
Em um storyworld, um usurio

deve ser capaz de fazer escolhas que

determinem os eventos futuros deste mundo. As escolhas devem ser interessantes

dramaticamente, variadas e balanceadas ou seja, a histria deve ser capaz de ir em
vrias direes de acordo com as decises do usurio.
Este conceito de pensar nas histrias como um mundo com suas prprias regras,
em vez de apenas em uma seqncia predeterminada, no inconsistente com o
processo de autoria de uma histria normal. Muitos autores de literatura e dramaturgia,
dependendo do seu mtodo criativo, j fazem isso internamente ao escrever uma
histria, como por exemplo sugere Robert McKee, roteirista, em (MCKEE, 2006),
quando diz "Uma estria deve obedecer a suas prprias leis internas de probabilidade.
A escolha de eventos do escritor, portanto, limitada s probabilidades e
possibilidades contidas no mundo que criou". Ou seja, toda histria deve obedecer a
suas prprias regras e lgica interna, se bem escrita. Caso contrrio, mesmo um
espectador comum, leigo na escrita literria e nas artes dramticas, ao ver um filme com
furos, ou inconsistncias no roteiro, fica com uma estranha sensao de que algo est
errado (Isso no faz sentido, Fulano nunca agiria assim!), mesmo quando no
consegue explicitar exatamente o que h de inconsistente na histria que lhe foi narrada.
Existem trs focos principais nas pesquisas de storytelling interativo: gerao,
visualizao e interao. De certo modo, pode-se fazer uma analogia ao cinema: a
gerao faz o roteiro; a visualizao produz as imagens dos atores; e a interao
6

corresponde a um diretor que, atento aos anseios do espectador, coordena a realizao

do processo como um todo. Em maior detalhe:

Gerao Lida com a questo dos rumos para a onde a histria converge, seus
personagens, aes e relacionamentos.

Visualizao Lida com a representao grfica dos elementos da histria, de

forma coerente com seu roteiro subjacente.

Interao/Direo Lidam com a dificuldade de se conciliar a interao entre os

agentes da histria, levando-se em conta seu nvel de autonomia. A interao
entre o usurio e a histria bem como entre os personagens esto intimamente
ligados manuteno da coerncia da histria, demandando a compatibilizao
com o processo de gerao da histria.
Para que seja possvel o uso de sistemas de storytelling interativo em mdias

novas como a Televiso Digital, alm da dificuldade de se equilibrar coerncia e

interatividade, deve-se considerar que se precisa encontrar uma forma hbrida de
apresentao de contedo multimdia, misturando caractersticas de jogos e televiso
normal. necessrio manter o apelo para o espectador comum, e, ao mesmo tempo,
permitir que o usurio seja capaz de interagir de diferentes maneiras com o contedo
que lhe apresentado.
Um sistema de storytelling interativo, quando aplicado a este caso, deve
inclusive considerar o fato de que o usurio pode nem mesmo querer interagir de modo
algum. O sistema precisa ter tanta responsividade quanto possvel e a histria deve ser
fluente, sempre mantendo a simplicidade e a sensao de conforto na interao,
especialmente quando se considera que as histrias em geral sero assistidas por
espectadores que podem no ser vidos usurios de jogos eletrnicos.
Em jogos, a coerncia tem sua importncia, mas de forma limitada, pois,
usualmente, o prazer de jogar est mais ligado a vencer desafios, mesmo que
entremeado com pedaos previamente escritos de histrias. Em storytelling interativo o
prazer est em assistir a uma histria com a possibilidade de intervir no processo, o que
demanda um nvel de coerncia comparvel ao de textos literrios ou filmes.
2.1 Modelos de Gerao de Histrias
Os Sistemas de storytelling interativo tm sido pesquisados para diferentes
aplicaes e implementados de diferentes modos. Podem ser aplicados a jogos
7

(YOUNG, 2001), auxlio autoria de histrias, entretenimento em geral e at a

aplicaes comerciais (SPIERLING et al., 2002). Dentre as coisas que distinguem um
sistema de storytelling interativo do outro, destacam-se a perspectiva pela qual a histria
contada e o foco da gerao dos enredos, que pode ser nos personagens ou na trama.
Descrevemos a seguir as principais abordagens que vm sendo propostas e
implementadas em sistemas de storytelling interativo. Uma das dificuldades mais
comuns ao se criar um sistema de storytelling interativo fornecer um bom nvel de
interatividade e cativar o usurio, enquanto se mantm a coerncia da histria que
gerada. Cada uma das abordagens tende a favorecer aspectos diferentes, ora
privilegiando a interao, ora privilegiando a coerncia, ora privilegiando o poder
dramtico. A abordagem particular que adotamos para um ambiente de TV interativa
baseada em uma modificao do sistema Logtell (CIARLINI et al. 2005) que descrito
em maiores detalhes no captulo 4.
2.1.1 Abordagens Centradas em Personagens (Character Based)
Alguns sistemas de storytelling se focam mais em personagens (characterbased), como em (CAVAZZA et al., 2002; CHARLES et al., 2001; YOUNG, 2001)
onde a histria emerge da interao em tempo real de agentes autnomos, cada qual com
seus objetivos e seu comportamento. Isto facilita a interveno do usurio, pois
geralmente as aes de qualquer personagem da histria podem ser mudadas. Esta
abordagem tende, no entanto, a tornar mais difcil garantir que as situaes emergentes
permaneam coerentes com o gnero e sejam suficientemente interessantes.
No trabalho do grupo de Cavazza, os usurios so espectadores que podem
interagir com objetos da histria e tambm dar sugestes a personagens, de modo a
afetar suas decises e histrias resultantes. Desta maneira, pode-se reduzir o impacto do
dilema interao versus coerncia, pois limita-se o envolvimento do usurio na histria,
mas permite-se que ocorram interaes a todo momento. A maior questo contra o uso
de abordagens puramente focadas em personagens at que ponto podem emergir
situaes dramticas e cativantes. No toa, este tipo de abordagem foi justamente
utilizado por Cavazza em um tipo de histria sitcom, ou seja, comdia de situaes,
onde o clmax de uma histria no to facilmente distinguvel.

Figura 2.1: Dramatizao de algumas histrias de (CAVAZZA et al., 2002)

2.1.2 Abordagens Centradas na Trama (Plot Based)
Outros trabalhos se focam mais na trama (plot-based), como em (GRASBON e
BRAUN, 2001; PAIVA, 2001), que se baseiam em regras estruturais mais rgidas e prestabelecidas na trama para guiar a histria. Isso normalmente facilita a coerncia e a
autoria de histrias com boa carga dramtica, mas acaba restringindo o potencial de
interveno do usurio. Geralmente, nesta abordagem a trama possui diversos pontos de
ramificao predefinidos, um incio e um fim, e exigido um grande esforo do
construtor da histria para permitir um nmero mnimo de variaes, pois elas precisam
ser consideradas previamente. Uma das principais fontes de inspirao para este modelo
o trabalho literrio de Vladimir Propp (PROPP, 1968) no comeo do sculo XX. Propp
analisou um conjunto grande de contos de fadas Russos e mostrou que todos podiam
ser descritos por especializaes de 31 funes tpicas, como vilania, partida do heri,
recompensa, etc. Nas abordagens puramente plot-based, a interveno do usurio mais
limitada porm garante-se com mais facilidade a coerncia.
Neste tipo de abordagem, ao usurio geralmente s permitido fazer sutis
interferncias, de modo que a histria no se afaste da estrutura predefinida. Nesta
forma de abordagem, a autonomia dos agentes , ao contrrio da abordagem characterbased, um risco, pois seu comportamento reativo e as aes locais podem entrar em
conflito com aspectos fundamentais da trama da histria (MATEAS e STERN, 2000).

Figura 2.2: Teatrix em ao Criando uma histria. Na parte central da figura, v-se o
personagem controlado e tambm os outros personagens no local.
Na pesquisa de (PAIVA, 2001; PRADA, 2000), foi criado o ambiente Teatrix,
que usa as funes de Propp para modelar personagens artificiais, ou NPCs (non player
characters) que interagem com outros personagens, criados por crianas, num mundo
virtual. Cada criana controla um personagem e os NPCs so autnomos. Cada
personagem tem um papel na histria, especificando as funes de que fazem parte. Os
NPCs tm objetivos que se adaptam s situaes, planejando e tentando executar
aes/funes de acordo com seus papis, que so baseados no trabalho de Propp,
dentro de um conjunto que inclui um vilo, uma princesa, um ajudante, etc. uma
abordagem interessante principalmente para educao, mas o controle da consistncia
das aes e objetivos e a gerao das situaes dramticas no so garantidas. Para
melhorar as chances de coerncia, h um agente Diretor, que tem privilgios
adicionais, podendo controlar outros agentes em prol da coerncia, e quem determina
o fim da histria. Este agente diretor tambm pode ser controlado pelos usurios (as
crianas).

10

Figura 2.3: Arquitetura de (GRASBON e BRAUN, 2001)

Na pesquisa de (GRASBON e BRAUN, 2001), tambm baseada em Propp, tem
como fundamento que o autor defina cenas e as associe a funes narrativas. Sua
pesquisa questiona a forma de gerao da configurao inicial das histrias, visto que os
autores no acreditam na gerao automtica de todos os detalhes das histrias. Como
apresentado na figura, a plataforma, proposta nesse trabalho, baseia-se fortemente no
processo autoral, ao definir um modelo global para a histria, e gerenciar a trama em
alto nvel - no nvel das funes morfolgicas definidas por Propp. Nessa plataforma, o
usurio no autor, ele apenas interage sobre os dados definidos pelo autor. O prottipo
funciona com uma interface em modo texto, mas prevendo-se a sua utilizao em um
sistema de realidade aumentada.
Em trabalho posterior do mesmo grupo (SPIERLING et al., 2002), tenta-se
explorar storytelling interativo em diferentes nveis em um palco experimental, com o
intuito de equilibrar flexibilidade e pr-determinao. Seu trabalho sugere a criao de
camadas que permitam aos autores trabalharem com a direo em nveis de detalhe que
vo desde as situaes dramticas em alto nvel at a direo de atores animados. O
trabalho argumenta que somente a forma de narrar a histria deve ser interativa, e seus
mdulos operam sobre histrias pr-definidas, com tramas definindo os eventos e fatos,
deixando apenas ao autor o poder modificar aspectos mais gerais da histria. Nesse
esquema, obviamente necessrio um grande esforo autoral para construir os modelos
das histrias. Na Figura 2.4, mostra-se a arquitetura do sistema. Cada camada usa os
dados da camada acima de si. O Story Engine controla o fluxo da narrativa, ou seja, a
ordem dos eventos, baseados nas funes proppianas, em um nvel abstrato. As funes
11

so especficas para seus gneros. O Scene Action responsvel pela escolha das cenas,
que incluem controles de cmera e aes dos personagens, descritos em scripts. No
nvel seguinte, tratam-se as relaes, dilogos e interaes entre os agentes. No nvel
inferior, Presentation, esto recursos adicionais para sons e animaes. Em cada estgio,
o autor pode definir o nvel de autonomia que cada motor pode exercer, podendo ser
totalmente autnomo, manual, ou uma combinao.

Figura 2.4: Arquitetura de (SPIERLING et al., 2002).

2.1.3 Abordagens Hbridas e Outras Abordagens

No sistema DEFACTO (SGOUROS, 1999) utilizada uma abordagem onde so
usadas sucessivas avaliaes de regras para controlar a gerao de uma histria
interativa onde o usurio o protagonista. A interao entre os objetivos dos
personagens representada explicitamente e uma concepo Aristotlica de trama
usada para levar a histria a um clmax e resolv-lo. O encadeamento de eventos,
contudo, no explicado por pr- e ps-condies, tornando o controle do que pode ou
no acontecer mais complexo. Alm disso, no se permite o uso de algoritmos de
planejamento para explorar seqncias de eventos, ao invs de eventos nicos, para
alcanar objetivos. A necessidade de interveno do usurio parece ser alta, para a
12

criao de uma histria completa. Objetivos so inferidos atravs de regras que analisam
a situao atual, mas as escolhas de aes para alcanar objetivos parecem ser mais
reativas do que deliberativas.
Existem tambm alternativas que integram caractersticas tanto plot-based
quanto character-based. O sistema interativo Faade (MATEAS e STERN, 2000), por
exemplo, tem um gerenciador de dramas que permite que os personagens sejam
autnomos a maior parte do tempo, mas que muda seus comportamentos para adiantar a
trama, conciliando objetivos de nvel maior, que so essenciais histria, com objetivos
menores, especficos dos personagens autnomos. J no Erasmatron (CRAWFORD,
1999), usa-se a noo de verbos e sentenas. Aes so representadas por verbos com
papis atribudos aos personagens de modo a formar sentenas.
A implementao do Erasmatron (CRAWFORD, 2005) trabalha em cima do
conceito de verbos e frases, tentando balancear os aspectos da trama e de personagens
da narrativa. As aes so representadas por verbos, com listas de papis que podem ser
atribudos aos personagens para formar frases. Funes so implementadas como
operadores lgicos, com parmetros e pr- e ps-condies.
No Faade, lanado em 2005 (MATEAS e STERN, 2005) o usurio um
convidado para tomar drinks na casa de um casal de personagens (Trip e Grace).
Atravs de interaes num ambiente 3D, que permitem manipular alguns objetos e
conversar com os personagens atravs de linguagem natural, o usurio pode influenciar
o rumo da trama: o casal pode vir a brigar, pode vir a se entender, ou pode acontecer
ainda de o usurio ser simplesmente expulso da casa deles. O sistema faz o uso de um
gerenciador de drama (drama manager) para manter o estado da histria, conciliando
aspectos character-based e plot-based. Os personagens so autnomos a maior parte do
tempo, mas seus objetivos e comportamento podem ser modificados pelo drama
manager, de modo a mover a trama adiante. O usurio o protagonista da histria, e o
drama manager seleciona as cenas a serem apresentadas. As cenas so compostas de
beats, unidade usualmente utilizada no cinema (porm nesse caso os beats duram em
torno de um minuto, um pouco menos que em filmes). Os beats definem a granularidade
da interao entre os personagens e a trama. O usurio pode interferir na execuo de
um beat, determinando como o resto da cena ser interpretada pelos dois atores, Trip e
Grace. Esta abordagem separa objetivos de alto nvel, importantes para o enredo da
histria, de objetivos menos importantes, mais especficos dos comportamentos dos
personagens. Para modelar esse comportamento dos personagens, foi criada uma
13

linguagem prpria, ABL A Behaviour Language (MATEAS e STERN, 2004), capaz de

definir os objetivos compartilhados e seqncias de aes para alcanar os objetivos.
Note-se que o Faade adota a estratgia de trabalhar com uma situao dramtica
contida e bem delineada, que leva algo em torno de 20 minutos para ser resolvida,
dependendo do usurio. Mesmo assim, a sua implementao exigiu um grande esforo
autoral, de mais de 4 anos e mais de 100 mil linhas de cdigo escritas. Apesar disso, o
Faade um dos trabalhos mais conhecidos no ramo do storytelling interativo, estando
disponvel na Internet e de fcil instalao e uso.

Figura 2.5: Faade e seus dois atores na viso 3D do usurio.

No IDTension de Nicholas Szilas (SZILAS, 2003; 2008), uma arquitetura
proposta, a qual se concentra no apenas na gerao de seqncias de eventos ou aes,
mas tambm na simulao de leis da narrativa que guiam o processo de storytelling.

Figura 2.6: Arquitetura proposta por (SZILAS, 2003)

Na arquitetura de Szilas, existem vrios mdulos. O mdulo World of the Story
14

contm entidades bsicas (personagens, objetivos, tarefas, sub-tarefas, segmentos e

obstculos), estados dos personagens (definidos por predicados) e fatos sobre a situao
material do mundo da histria. O mdulo lgica narrativa (Narrative Logic) determina,
a partir dos dados no mundo da histria, o conjunto das aes possveis para cada
personagem. O mdulo Narrative Sequencer decide que aes executar com base em
quesitos de consistncia, conflito, surpresa, etc., buscando criar tenses dramticas. Para
a criao dos conflitos, usado um modelo de valores morais e ento promovem-se
situaes para obrigar personagens a realizarem aes que vo contra seus valores para
alcanar os objetivos. O mdulo User Model contm o estado de um usurio em
determinado momento na narrativa e identifica seus valores mais importantes. Prov,
dessa forma, ao Narrative Sequence, uma estimativa do impacto sobre o usurio de cada
possvel ao. O mdulo Theatre cuida da exibio das aes e gerencia a interao com
o usurio.

Figura 2.7: Prottipo de (SZILAS, 2008), modo texto: um drama interativo aonde o
jogador deve fazer um motim num navio.
Em SI et al. (2008) descrita uma abordagem que tem como foco a autoria e
controle de personagens virtuais em dramas interativos. Processos centrados na trama
so integrados com processos centrados nos personagens atravs da criao de um
framework para a autoria/criao de dramas interativos. Esse framework integra um
planejador de ordem parcial (POP), normalmente usado em abordagens centradas na
trama, com o sistema Thespian (SI et al., 2005) que usa principalmente a abordagem
centrada em personagens. O Thespian garante a consistncia das motivaes dos
personagens durante a interao e usa agentes autnomos orientados a objetivos para
15

controlar personagens virtuais. As motivaes dos personagens so codificadas como

objetivos dos agentes. O Thespian fornece um procedimento automatizado para regular
as motivaes dos personagens virtuais com um conjunto de caminhos da histria
(seqncias de aes dos personagens). O ponto inicial para o processo da autoria da
histria um conjunto de scripts padro. Um algoritmo ento facilita o processo da
autoria ajustando automaticamente os objetivos dos agentes de forma que os agentes
executem seus papis de acordo com os scripts. Isto tambm garante que os agentes vo
agir de forma compatvel com suas motivaes quando o drama interativo foge dos
scripts.
2.2 Interactive Storytelling e Planejamento Automatizado
O uso de tcnicas de planejamento automatizado parte importante de alguns
sistemas de storytelling interativo, pois so algoritmos feitos justamente para criar
seqncias lgicas de eventos.

Figura 2.8: Uma HTN do protagonista. Reproduzida de CAVAZZA, 2002 pg 19.

Em (CAVAZZA et al., 2002), planejamento com redes hierrquicas de tarefas
(HTN) usado para controlar a forma como personagens alcanam seus objetivos em
concordncia com as intervenes do usurio. Planejamento com HTN costuma ser
eficiente, mas menos geral, pois fortemente preso ao conhecimento do domnio,
exigindo um esforo alto na construo de mtodos para realizar cada tarefa na histria.
Algoritmos de planejamento mais flexveis foram adotados no desenvolvimento
de outros sistemas. Tais algoritmos no se limitam a solues previamente pensadas. Em
vez disso, combinam eventos conciliando objetivos diferentes com pr-condies de
cada evento. Isso aumenta ainda mais o esforo computacional dada natureza
complexa de planejamento automatizado, mas torna o sistema mais flexvel e, portanto,
capaz de gerar maior variedade de histrias. Na maioria das abordagens que fazem uso
16

desta tcnica de planejamento, so usados algoritmos de planejamento de ordem parcial,

onde s estabelecido que um evento deve ocorrer antes de outro se isso for
estritamente necessrio para o alcance dos objetivos. Em ambientes de storytelling
interativo, o uso de ordem parcial uma alternativa interessante porque d mais
flexibilidade para interagir com o usurio.

Figura 2.9: Framework de SI et al. (2008) que usa planejamento.

No trabalho de SI et al. (2008), o framework proposto usa planejadores
parcialmente ordenados para configurar os agentes baseados em objetivos do Thespian.
Esse framework permite o uso de um planejador que modela a histria em um nvel
maior de abstrao do que o Thespian, que controla os agentes. Esta abordagem poupa o
autor de ter que construir um modelo completo no nvel de detalhe demandado pelo
Thespian, o que permite que o autor rapidamente esboe a experincia interativa.
Em (RIEDL e YOUNG, 2004) descrito o uso de um planejador parcialmente
ordenado para storytelling interativo, que incorpora informaes correspondentes s
intenes dos personagens, sob a forma de relaes causais entre os efeitos de um
evento e as pr-condies de outro. Com base na anlise de relaes causais em tempo
de execuo, possvel verificar quando uma ao de um usurio pode afetar a histria
que est sendo contada. Dessa forma, mecanismos de mediao, como os do Mimesis
(YOUNG, 2001) (YOUNG et al., 2004) podem ser adotados. O Mimesis um sistema
para controlar ambientes virtuais em jogos que usa storytelling com planejamento. Nele,
as narrativas so geradas por um algoritmo de planejamento, a princpio sem considerar
17

os objetivos dos personagens. , ento, feito o uso de mecanismos para a deteco de

excees e mediao. Excees so as aes que podem comprometer as seqncias
causais no plano da histria; e mediao a forma usada para tratar estas excees. Para
a mediao h duas alternativas bsicas. A primeira a acomodao, onde o plano
modificado de modo no atrapalhar a histria previamente planejada. A segunda a
interveno, onde o personagem controlado pelo usurio impedido de executar uma
ao que comprometeria demais a histria.
Em (RIEDL e YOUNG, 2006) descrito mecanismo onde, para cada ponto onde
pode ocorrer uma exceo, usa-se o planejador para obter uma histria alternativa
comeando naquele ponto. Esse mecanismo de antecipao cria uma rvore onde os
caminhos correspondem s narrativas que podem ocorrer. Para a rvore no crescer
demais, utiliza-se interveno em certos pontos. Com a gerao prvia da rvore de
narrativas, evita-se a necessidade de planejamento em tempo real. No entanto, o
direcionamento da narrativa tende a ser mais rgido do que quando se opta pelo
planejamento em tempo real. Em (RIEDL et al., 2008), apresentado um framework
para criar narrativas em um mundo virtual para entretenimento, educao e treinamento.
O framework usa essas tcnicas de antecipao de excees para controlar a experincia
do usurio de modo a que os objetivos da aplicao sejam atingidos.
2.3 Concluses
Neste captulo, procurou-se dar uma viso geral da pesquisa em storytelling
interativo descrevendo-se as principais questes envolvidas e os enfoques que vm
sendo adotados em diferentes sistemas.
H um consenso dentre os pesquisadores de que no h condies de existir um
processo completamente automtico: sempre necessrio usar estratgias que
combinem um esforo autoral com a criao de frameworks que formalizem de algum
modo as regras necessrias para a criao de narrativas minimamente interessantes para
seres humanos. Grande prova disso o prprio Faade, que tido como a mais bem
sucedida experincia de Interactive Storytelling at ento, mas que precisou, como
mencionado anteriormente, de mais de 4 anos de desenvolvimento e um grande esforo
autoral. Soma-se a isso o fato de que, no Faade, todo o esforo autoral foi feito pelo
prprios pesquisadores que fizeram os algoritmos que gerenciam a narrativa e a
interao com o usurio. Isto ilustra o fato que a autoria das histrias interativas ainda
envolve grande conhecimento das tecnologia criadas. Para a criao de histrias
18

interessantes, a experincia de autores mais focados nas histrias do que nos aspectos da
implementao fundamental de modo a se obter uma produo em boa quantidade de
novas obras de storytelling interativo.
Tambm importante demonstrar as diferenas que h nas abordagens quanto
gerao das histrias e forma como elas lidam com as interferncias do usurio. Parece
haver um consenso de que preciso tentar balancear os objetivos dos personagens com
os da trama em geral, e diferentes abordagens lidam com essa dificuldade de maneiras
diferentes.
H uma tendncia em sistemas de storytelling de se usar algoritmos de
planejamento automatizado, em especial algoritmos de planejamento de ordem parcial
ou com redes hierrquicas de tarefas. Algoritmos de ordem parcial parecem ser uma
escolha lgica, dada a sua natureza, pois so capazes de retornar ordens parciais de
eventos que devem ocorrer para alcanar objetivos, de forma bem semelhante ao que
ocorre na prpria estrutura e lgica interna das narrativas convencionais. Redes
hierrquicas de tarefas tambm mostram-se compatveis, pois so capazes de criar
seqncias de eventos mais abstratos que se decompem em outros mais especficos, o
que se mostra compatvel com a lgica das narrativas, ao se pensar que uma histria
pode ser decomposta em conceitos abstratos que podem ser realizados por diferentes
mtodos.
Existe uma gama de diferentes opes de implementao no que concerne
maneira como as narrativas so apresentadas, e tambm maneira como o usurio pode
interagir sobre elas. Em algumas pesquisas, como no Faade e no IDTension, a
perspectiva da narrativa em primeira pessoa; j no sistema de Cavazza e no Teatrix,
na terceira pessoa. Alm disso, varia-se muito a forma de apresentao. Boa parte dos
sistemas descritos apresenta narrativas atravs de animaes 3D, mas alguns esto
orientados gerao de texto, como no IDTension. Esses aspectos tambm esto ligados
forma de interao que pode ser direta, atravs de dilogos ou da manipulao direta
do cenrio e de avatares, ou indireta, atravs de diferentes mtodos. Em enfoques
character-based, sente-se a inspirao direta de jogos, o que leva a narrativas com
intervenes diretas que podem acontecer a qualquer momento. Em enfoques plotbased, prevalece a inspirao de textos literrios e do cinema, havendo predominncia
de narrativas em terceira pessoa com intervenes indiretas.
O sistema usado nessa pesquisa foi o Logtell. Este sistema de storytelling tem
semelhanas com as pesquisas de Grasbon e Spierling (SPIERLING et al., 2002;
19

GRASBON e BRAUN, 2001), por ser primeiramente plot-based e inspirado

inicialmente na teoria de Propp. Por outro lado, fortemente pautado na formalizao
lgica do contexto, de modo a utilizar planejamento automatizado para explorar
virtualmente todas as possibilidades logicamente coerentes para esse contexto. O uso de
planejamento para garantir a gerao de seqncias coerentes de eventos se assemelha
ao adotado em (YOUNG et al, 2004), mas se baseia tambm na formalizao, em lgica
temporal, das situaes que levam ao surgimento de objetivos. O processo de gerao
feito atravs de mltiplos estgios que incluem fases de inferncia de objetivos,
planejamento e interao com o usurio. A formalizao dos objetivos de personagens e
da histria aproxima o Logtell de sistemas que tentam conciliar aspectos character-base
e plot-based, como no Faade. No aspecto da visualizao, o Logtell se assemelha ao
sistema de Cavazza, usando visualizao 3D e uma perspectiva em terceira pessoa.
Para a utilizao de storytelling interativo em um ambiente de TV interativa, a
diversidade e coerncia dos enredos, bem como a possibilidade de interaes com o
usurio em variados nveis de intensidade importante. No Logtell, possvel gerar
uma boa diversidade de histrias coerentes, desde que haja um esforo autoral para
definir as regras do contexto, dificuldade compartilhada por todas as pesquisas em
storytelling interativo. Interaes com o usurio podem ocorrer em nveis diferentes,
mantendo a consistncia desejada. Dessa forma, a arquitetura do Logtell parece fornecer
uma boa base para os propsitos de utilizao de storytelling interativo na TV. O
captulo 4 fornece maiores detalhes sobre a verso inicial do Logtell, explicando suas
potencialidades e as limitaes para a sua aplicao na TV interativa, as quais
motivaram o desenvolvimento desta pesquisa para a sua extenso.
O captulo seguinte expe uma viso geral sobre as tecnologias utilizadas na
televiso interativa e suas perspectivas, de forma a demonstrar sua compatibilidade com
o trabalho proposto.

20

3. Televiso Interativa
Nos ltimos anos, a TV analgica tradicional vem caminhando para ser
substituda por uma TV digital aberta com qualidade de som e imagem bastante superior
e possibilidades de interao. Alm disso, temos visto uma ampla disseminao do uso
de novos meios de comunicao, tais como a internet banda larga e celulares 3G, que
servem tambm como alternativas interessantes para a veiculao de programas em
princpio televisivos. Esses fenmenos resultam de grandes avanos nas tecnologias
digitais e da convergncia digital, que permite juntar diversas melhorias e inovaes em
diferentes frentes, tais como na infra-estrutura das redes de comunicao, no software e
no hardware para compresso e transmisso de dados e nos servios de broadcasting
(FURHT, 1996). Como resultado, abre-se, um leque de novas tecnologias prontas a
revolucionar a forma como as pessoas vem e interagem com os aparelhos de TV. As
mudanas dizem respeito no apenas qualidade de imagem e som (DRISCOLL, 2000),
mas tambm ao contedo disponvel e relao com o espectador.
Dentro desse cenrio, uma questo central a capacidade de interatividade, o
que levou ao surgimento da TV interativa ("interactive TV", "enhanced TV" ou
simplesmente iTV) (SWEDLOW, 2000) como uma rea de interesse importante tanto
para a pesquisa quanto para a indstria.
A prpria televiso analgica convencional apresenta cada vez mais programas
em que os espectadores so convidados a participar, reality shows, etc., o que demonstra
a

existncia de um potencial a ser explorado no que tange s possibilidades de

interao. A iTV no seria nada mais do que a evoluo natural do meio analgico,
agregando interatividade ao prprio vdeo e trazendo a oportunidade de um feedback
imediato do espectador s distribuidoras de contedo que, muitas vezes, costumam ser
as prprias produtoras. Possibilidades de interao incluem:

uma interatividade mais fraca correspondente simples possibilidade de se rever

programas na hora desejada, pular comerciais, executar comandos de VCR,
etc.;a obteno de mais informaes sobre o que apresentado, sejam filmes,
notcias, esportes, etc.;

a veiculao de propaganda direcionada e individualizada (em conjunto com

mecanismos de vendas);

a interferncia efetiva no contedo apresentado, mudando por exemplo o final de

uma histria que se est assistindo;
21

a interao conjunta de um grupo de usurios com um contedo compartilhado.

Esses dois ltimos itens tm forte apelo para o desenvolvimento de aplicaes

voltadas tanto ao entretenimento quanto educao e so de particular interesse neste

trabalho, onde se estuda o uso de storytelling interativo dentro de uma perspectiva de
TV interativa.
Em se tratando de aplicaes para TV, necessrio estudar modelos que
permitam garantir a responsividade dos sistemas, ou seja, o atendimento aos anseios
dos usurios de forma rpida e sem alteraes no nvel de qualidade. O usurio de TV
est habituado a assistir um fluxo contnuo de apresentao dos programas sem quebra
na qualidade de som, do vdeo e da diversidade e coerncia do contedo. Por outro lado,
a interao com a TV tende a ser diferente da interao com computadores pessoais,
pois, usualmente, no tolervel que se demande do usurio um grade esforo de
ateno.
A TV digital aberta naturalmente um dos principais meios de comunicao
onde a pesquisa em TV interativa dever ser aplicada. No contexto brasileiro, em
particular, a ampla penetrao da TV em todas as camadas sociais, se comparada por
exemplo penetrao da internet, faz com que seja de interesse estratgico, tanto para o
governo quanto para a indstria, a pesquisa e o desenvolvimento nessa rea (CPqD,
2005). preciso explorar potencialidades e oportunidade que se abrem (TOME et al.,
2001), tanto para fins de entretenimento quanto de educao (SANTOS et al., 2005)
(SANCRINI, 2005). Deve-se notar, no entanto que a convergncia digital faz com que
aplicaes desenvolvidas com foco na TV digital possam ser adaptadas para outros
meios, tais como TV via Internet e TV via celular, e vice-versa.
Este captulo aborda diversos aspectos relacionados TV interativa.
Inicialmente, so tratadas as possibilidades de interao e de desenvolvimento de
aplicaes e servios, levando em conta os requisitos de facilidade de interao e
responsividade. Em seguida, so investigados ambientes e abordagens para a TV
Interativa, dando destaque ao ambiente de TV digital aberta. Por fim, so apresentadas
as concluses no que diz respeito adequao de modelos de storytelling a ambientes
de TV interativa.

22

3.1 Interatividade e Televiso

Uma das principais mudanas que surgem com a iTV justamente a forma como
utilizada a televiso. Agora, o usurio vai alm de um espectador no sentido mais puro
da palavra, surgindo a possibilidade de se interagir com o que se assiste.
importante ressaltar que a interatividade com programas de televiso j existe
h um certo tempo, embora de forma mais improvisada e bem menos dinmica. Um
primeiro exemplo corresponde a programas de televiso onde o espectador pode ligar
para tomar decises, como em reality shows.

Game shows, onde o telespectador

responde a perguntas e pode ganhar prmios so exemplos ainda mais antigos. Telejogos como "Hugo" que chegou a ser exibido no Brasil por um tempo, onde o
espectadores participavam via telefone dando comandos atravs do tom das teclas, so
exemplos tambm interessantes. Por fim, outro tipo de programa que serve de analogia
para o produto desta pesquisa foi o Voc Decide, onde o espectador podia, atravs de
votao por telefone, escolher uma alternativa de deciso a ser tomada pelo protagonista
de uma histria, assistindo a seguir s conseqncias da alternativa mais votada. A
caracterstica interessante nesse caso era que no havia pausa: o espectador via a histria
e isto o ajudava a tomar a deciso.
De todo modo, a demanda por essa interatividade improvisada serve pra
mostrar que h um potencial de atratividade em programas onde os telespectadores
podem interagir, em vez de permanecerem apenas como espectadores passivos. Com o
advento de tecnologias cada vez mais potentes e ao alcance de cada vez mais pessoas,
novas funes interativas so disponibilizadas nas diversas mdias e os usurios tornamse mais habituados com a interao atravs de gadgets, internet, videogames, telefones
celulares com mltiplas funes, etc. Cria-se dessa forma um cenrio onde a
interatividade na TV surge como evoluo natural.
No h consenso sobre como se dar a incorporao de mecanismos de interao
na TV nem sobre qual ser o impacto disso na vida dos usurios. H enfoques que
defendem uma maior interatividade, outros que advogam uma capacidade de interao
menor.

A capacidade de interao vai depender do poder computacional dos

dispositivos que recebem o sinal de TV e o processam (normalmente chamados de settop boxes). Por um lado h a chamada interatividade preguiosa (lazy interactivity), na
qual a capacidade de interao seria mais limitada, exigindo dispositivos receptores de
sinal menos poderosos e no demandando muita ateno do usurio, o que tenderia a ser
mais natural para os telespectadores, mais acostumados, em princpio, a uma postura
23

passiva. Por outro lado, h outra vertente, que sustenta o uso de um maior poder de
processamento nos dispositivos receptores para dar suporte a uma interao mais
potente. Em vez de uma interatividade preguiosa, o foco das aplicaes seria em
interfaces intuitivas e fceis, de modo a no atrapalhar a diverso e o entendimento do
espectador. A maior capacidade de processamento, ao aproximar os dispositivos
receptores e PCs, traz naturalmente vantagens, mas aumentam tambm as chances de
erros de programao e falhas, o que que pode comprometer a responsividade. De
qualquer modo, provvel que as duas vertentes coexistam, pelo menos por algum
tempo. Eventualmente, o mercado poder fazer com que uma prevalea sobre a outra ou
que, devido segmentao da economia e dos hbitos da sociedade, continue havendo
espao para ambas.
Independente do tipo de abordagem para TV Interativa, o termo telespectador
tende a perder o sentido, pois o usurio deixar de ser apenas um indivduo que assiste
programao distancia. O usurio passa, da mesma forma que quando utiliza PCs, a
ser um agente ativo no processo, o que torna evidente o anacronismo do termo. A
diferena entre as abordagens corresponde ao nvel de atividade que pode demandar
maior ou menor ateno e pode levar a mudanas mais ou menos significativas no
contedo que apresentado.
De acordo com uma evoluo natural, o que se espera, que a interatividade v
crescendo com o tempo, por questes logsticas, que incluem o desenvolvimento de
novos modelos de negcio, e de recursos de infra-estrutura. O prprio poder
computacional dos set-top boxes tende a ser um gargalo para o desenvolvimento de
aplicaes mais complexas. A rede de comunicao disponvel precisa estar
adequadamente dimensionada para responder e processar a tempo os desejos e
demandas dos usurios, pois no se estar mais lidando com um nico contedo esttico
transmitido unidirecionalmente.
3.2 Aplicaes e Servios na Televiso Interativa
Alm das questes de infra-estrutura, so necessrios esforos para a criao de
contedo apropriado para o novo meio criado. A gerao de contedo para esse novo
ambiente exige todo um trabalho de projeto e programao, alm de envolver a criao
de novas reas de pesquisa e a integrao de conhecimentos multidisciplinares, de forma
a adaptar os conhecimentos para o ambiente que surge.
Surgem ainda questes a respeito dos fins comerciais que podem ser afetados
24

pela televiso interativa. A veiculao de propaganda na TV aberta, por exemplo,

precisa ser reestudada. Novos modelos de negcio com certeza precisaro ser
elaborados e testados.
As aplicaes para a TV interativa podem ser dos mais variados tipos. A seguir
so apresentados exemplos dos tipos de interao que podem ocorrer nessas aplicaes.
Interao para Escolha de Contedo
Uma das principais formas de aplicao da iTV na forma dos guias de
programao (BECKER E MONTEZ 2004), que exibem, atravs de interfaces grficas,
informaes variadas sobre a programao e guias de auxlio ao espectador/usurio. Tais
informaes possibilitam ao usurio escolher programas e horrios, comprar contedo
atravs de pay-per-view, solicitar vdeo sob demanda (Video on Demand, ou VoD) e
outros contedos como horscopo e programao de rdio de vrios estilos. Esses guias
tambm so conhecidos pela sigla EPG - Eletronic Program Guide e um exemplo deles
a MSN TV2 (MSN TV2, 2008).
Como as informaes esto num meio digital, surge a possibilidade do uso de
personal video recorders, aproveitando-se que os dados sobre os programas de TV e
filmes estaro disponveis tambm na forma digital. Esses metadados podero ser
usados como parmetros para busca, fazendo com que um usurio possa buscar e
assistir filmes de algum determinado diretor, ator, tema, etc. O VoD (video on demand),
uma forma de servio que permite que o usurio possa comprar e/ou assistir a
contedo, e ento assistir quando quiser. muito usado em novas funcionalidades de
pay-per-view, com venda de filmes, por exemplo.
Mecanismos mais avanados de interao permitiro o surgimento de uma
televiso mais individualizada. Nos noticirios, poder-se- escolher quais categorias de
notcias se quer assistir, documentrios interativos podero funcionar como
enciclopdias digitais, e outras formas similares de acesso a contedos informativos
sobre o que se assiste podero ser implementadas. Alm disso, ser possvel
individualizar a forma como um mesmo contedo apresentado. Usurios podero
assistir a jogos esportivos por ngulos diferentes de cmera e fazer o replay de
momentos importantes no instante que desejarem.
Servios de Internet e Portais de Televiso Interativa
Com a presena de um canal de retorno, tambm surge a possibilidade de se
25

disponibilizarem outros servios como internet para navegao e email e tambm

servios de mensagem instantneas (instant messaging), alm de bate-papo e redes
sociais.
Como forma de servios interativos, tambm surge a opo dos portais, tambm
conhecidos como walled garden, que funcionam como os portais de internet, provendo
uma srie de servios agregados. Dentro desses portais, o usurio poder acessar
aplicaes interativas que provm uma miscelnea de servios, jogos, compras pela
televiso, anncios do governo, notcias, etc.
Jogos
Outra forma de aplicao que pode ser disponibilizada na TV interativa na
forma de jogos interativos. Os jogos podem ser usados para entreter, educar, ou mesmo
como forma de divulgao de filmes e produtos. Com a sua disponibilizao atravs da
TV interativa, pode-se atingir um grande potencial de pblico.
Uma primeira possibilidade a transmisso dos jogos para serem jogados
individualmente nas set-top boxes. Outra possibilidade, que demanda um canal de
retorno, a de jogos onde mltiplos usurios interagem, de forma anloga ao que ocorre
na Web.
Elementos Mesclados ao Contedo da Programao
Uma forma de servio tambm disponvel o uso de elementos interativos
mesclados ao contedo, ou seja, elemento interativos que aparecem durante a exibio
de filmes e programas de televiso, em paralelo ao vdeo exibido. Para fazer uso desses
elementos, geralmente prefervel utilizar grficos semi-transparentes, que aparecem
em momentos especficos nos cantos do televisor. possvel, por exemplo, durante a
apresentao programa, oferecer ao usurio a possibilidade de comprar um produto que
aparece no programa ou de pedir uma pizza quando algum aparece comendo em um
filme. Essas oportunidades para anncios e comrcio pela TV recebem nome de tcommerce. Alm de servirem para t-commerce, os elementos grficos tambm podem
ser usados para mostrar estatsticas, ou simplesmente qualquer outro recurso onde mais
informaes estejam disponveis, caso o usurio realmente as deseje, como funes de
histrico em jogos esportivos.
Interao com o Contedo da Programao
26

A perspectiva mais revolucionria para TV interativa a interao com o

contedo que assistido. Essa possibilidade, no entanto, a mais desafiadora e a mais
ligada ao trabalho apresentado nesta dissertao. Procuram-se prover meios para que,
por exemplo, o fim de uma histria que est sendo assistida sofra a interferncia do
usurio.
Para a implementao de mecanismos de interao avanada na TV como esses,
h, no entanto, dificuldades relacionadas arquitetura dos sistemas e ao modelo
comercial. Por um lado, set-top boxes precisam ter algum tipo de padronizao e precisa
haver um canal de retorno ao provedor do contedo. Por outro lado, em ambientes onde
a TV gratuita e financiada por anncios comerciais, o modelo de negcio atual precisa
ser reestudado, pois passa a haver muito mais opes de contedo e o contedo passa a
ser muito mais controlado pelo usurio.
3.3 TV Digital Interativa
A televiso tradicional analgica est com os dias contados no Brasil. O decreto
presidencial nmero 5820, em 29/06/2006, estabelece a data limite de 10 anos at que se
encerre a transmisso analgica, que dever ser substituda totalmente pela transmisso
digital. Um aspecto muito importante para a implantao deste sistema justamente a
grande disseminao do meio atual, analgico, no Brasil. Conforme demonstrado por
pesquisa do IBGE (IBGE, 2007), a televiso encontra-se em 94,5% dos domiclios
particulares permanentes, sendo importante ressaltar que, em contrapartida, apenas
20,2% possuem computador com acesso Internet. Dessa forma, a TV digital aberta
ganha uma importncia maior e cabe investigar o potencial de interatividade desse
ambiente em particular.
3.3.1 Transmisso de Dados
Uma das principais mudanas dentro do novo meio digital da iTV o prprio
canal de transmisso, fundamental para a construo da DTV, ou Digital Television. O
modelo de referncia para a DTV na maioria dos sistemas, se faz atravs do uso de
algoritmos de compresso, em especial o MPEG-2 para imagem e MP3 pra udio,
reduzindo o uso da banda enquanto se preserva a qualidade.
Para existir interatividade em uma ambiente de TV Digital, no estritamente
necessria a aquisio de novos televisores digitais. At televises analgicas podem ser
utilizadas

em conjunto com

set-top boxes ou URDs - Unidades Receptoras27

decodificadoras que contenham conversores de sinais digitais para sinais analgicos.

Set-top boxes (SCHWALB, 2003) tm a capacidade de processamento de sinais de vdeo
e udio, alm de poderem executar programas. So capazes de recepo, demodulao,
decodificao e remodulao do sinal digital, gerando sinal de udio e vdeo compatvel
com televisores analgicos, alm de dar suporte s formas de interao denominadas
"Pseudo" e "Real".
Na "pseudo" interatividade, o set-top box se comunica com a central de
produes do canal desejado e processa os fluxos de dados multiplexados, sendo capaz
de exibir na televiso uma interface para o usurio, que pode ento interagir com o
programa de TV atravs do controle remoto, ou teclado. A interatividade "real"
viabilizada atravs de uma conexo com um canal de retorno, geralmente por internet ou
no caso de TV a cabo por exemplo, transmitindo pelo prprio meio por onde recebe o
sinal de TV; e possibilita uma maior gama de oportunidades de interao. possvel a
instalao dinmica no set-top box de uma cpia de um sistema de arquivos produzido
no estdio de dados. No set-top box podem ento ser exibidos textos transmitidos e
recebidas aplicaes para serem executadas.
O sistema final definido para Brasil foi o ISDB-TB (ISDB-T do Brasil), tambm
denominado SBTVD (Sistema Brasileiro de Televiso Digital) (CPqD, 2006). Ele
incorporou atualizaes ao modelo japons nas partes de udio, vdeo e interatividade e
traz uma srie de vantagens para a realidade brasileira, como, por exemplo, a reduo no
pagamento de royalties e o preo do set-top box mais acessvel, o que possibilita uma
maior incluso digital. Ao utilizar set-top boxes para a converso do sinal digital para
analgico, o parque instalado aproveitado, permitindo uma implantao gradual, que
leve em conta as diferentes condies scio-econmicas do Brasil. Com o uso do settop box ligado internet, possvel ainda utilizar a televiso como um browser
(contudo, ainda que normalmente mais limitado que o de um PC).
3.3.2 Middleware
Para implementar aplicativos para televiso digital existem duas abordagens
principais: o uso de aplicaes declarativas ou de aplicaes procedurais. Define-se por
aplicao declarativa aquela cujo contedo projetado de forma declarativa, enquanto
que, nas aplicaes procedurais, seu contedo projetado de maneira procedural. Esta
diferena de padres define a prpria filosofia e utilidade para cada aplicao feita.
No Brasil, atravs de uma pesquisa conjunta de diversas instituies foi criado o
28

middleware Ginga, para a implementao de aplicativos interativos para a TV Digital.

Em concordncia e com a filosofia do Java, o Ginga busca o desenvolvimento
independente da plataforma de hardware dos diferentes set-top boxes. O Ginga
aplicvel aos receptores para sistemas de transmisso terrestre, e busca cumprir
completamente uma srie de especificaes para serem usadas em aparelhos de TV
Digital integrados, computadores multimdia e clusters locais de aparelhos em redes
domsticas (HAN). O ncleo do Ginga, a Ginga-Core composta por diversos
decodificadores de contedos comuns, como imagens JPG, PNG, etc. e procedimentos
para obter contedos transportados em canais (Streams) de transporte do MPEG-2 e
atravs do canal de retorno.
O Ginga-NCL (SOARES et al., 2007) a poro declarativa do Ginga. Ele prov
uma estrutura para a apresentao de aplicaes declarativas escritas na linguagem
NCL. Atravs de um decodificador, tambm conhecido como NCL formatter, o
contedo pode ser processado. Outros mdulos importantes do Ginga-NCL incluem o
agente de usurio, baseado em XHTML, que inclui folhas de estilo (CSS) e um
interpretador ECMAScript, alm da engine LUA, capaz de interpretar scripts LUA,
muito utilizados em jogos e outros produtos interativos. Alm disso, possvel o uso de
outros padres declarativos atravs de implementaes diferentes baseadas em XHTML.
O aspecto procedural do Ginga implementado atravs do Ginga-J (SOUZA et
al., 2007), o qual inclui diferentes APIs baseadas em padres JavaTV. O Ginga-J
projetado para ser capaz de suprir as funcionalidades necessrias para a criao de
aplicaes para a TV Digital, com funcionalidades para protocolos de acesso, interao,
manipulao de objetos multimdia, etc. O Ginga-J utiliza aplicativos procedurais,
tambm conhecidos como Xlets Java. Como toda implementao Java, utiliza uma
maquina virtual Java (JVM), que estabelece uma camada de abstrao sobre o sistema
operacional subjacente, o que facilita a compatibilidade e portabilidade das diferentes
implementaes em diferentes hardwares, dado que se siga corretamente a sua
especificao. Uma aplicao Ginga-J deve-se basear nas definies GEM 1.1 (ETSI,
2005) (Globally Executable MHP), que so especificaes unificadas para a criao de
niddlewares para TV Digital. Uma aplicao compatvel com este padro ser, em
princpio, compatvel com o Ginga-J.
3.4 Outros Ambientes e Abordagens para TV Interativa
Existem outras formas para a transmisso de contedo de televiso. Exemplos
29

desses ambientes so a Internet TV e a IPTV, que se definem como sistemas onde um

servio de televiso digital transmitido atravs do protocolo IP (Internet Protocol)
atravs de uma infra-estrutura de rede, geralmente sendo entregue atravs de uma
conexo de banda larga, com a diferena que na IPTV a transmisso numa rede
prpria, j a Internet TV usa a Internet convencional. Em linhas gerais, a diferena
que, em vez de ser transmitida atravs dos formatos tradicionais como broadcast e TV
cabo, seu contedo recebido atravs de tecnologias usadas para redes de
computadores. Nas plataformas baseadas em IP, surgem diversas oportunidades de
interatividade, da mesma forma que nos padres de televiso digital interativo descritos,
como guias de programao, recursos interativos dando informaes sobre os programas
exibidos, etc.
Um exemplo de implementao de IPTV o AppleTV (APPLE, 2009). O
AppleTV um aparelho que funciona em rede e que permite que usurios usem um
televisor HD para ver fotos, tocar msica, e assistir a vdeos de fontes da Internet ou de
rede local. Dentre essas fontes, incluem-se a loja iTunes, Youtube, Flickr e MobileMe,
por exemplo. Ao se conectar na loja da Apple, a iTunes, os usurios podem comprar e
alugar filmes, programas de televiso, msicas, videoclipes, grande parte do contedo
na qualidade HD.
Projetos como o ShapeShifting Media (URSU et al, 2008), questionam as
formas de interatividade que vm sendo criadas no ambiente de televiso interativa
digital, como t-commerce, e-mail, browsers de internet, etc., dado que so servios que,
embora aumentem as possibilidades de experincias dos espectadores, so meras
adaptaes de servios provenientes de outras plataformas, como a Web. O projeto
ento busca, atravs de pesquisa colaborativa, a produo de novas formas de mdia
interativas criadas especificamente para a IPTV, em especial usando novas formas de
storytelling que se adequem s preferncias do espectador. O ShapeShifting Media
trabalha em cima de modelos de narrativas onde autores definem: uma narrativa global
representando o mundo da histria; estruturas e regras usadas para transmitir narrativas
personalizadas; os objetos narrativos; grafos estruturados que especificam que caminhos
a narrativa pode tomar para usurios individuais; pontos de deciso na narrativa global;
grupos de objetos narrativos escolhidos segundo regras; e uma estrutura de camadas que
estabelece os objetos narrativos que so transmitidos em paralelo.
Dentro da Shapeshifting TV, foram criadas algumas aplicaes interessantes:

Em Gormenghast Explore, que baseada em livro de mesmo nome, ocorre uma

30

visita interativa a um castelo 3D. Os usurios podem acessar as histrias de

diferentes personagens, que so reconfiguradas a cada visita.

Na aplicao My News & Sports My Way, implementado um arquivo digital

interativo que permite a descoberta, seleo e recombinao de notcias. Tenta-se
criar um programa de notcias com uma narrao contnua, em vez de histrias
isoladas, e que d aos espectadores a habilidade de explorar questes em maiores
detalhes quando desejado.

Em Accidental Lovers, foi criada uma comdia romntica de humor negro, que
foi transmitida por Internet, telefone celular e televiso. Os usurios
acompanhavam em tempo real o desenrolar da relao de um casal, enviando
mensagens incentivando ou no a relao dos dois. Depois de moderadas, essas
mensagens influenciavam o andar da trama e/ou apareciam na tela durante a
exibio do programa.
O projeto ShapeShifting Media tem uma srie de semelhanas com a pesquisa

desta dissertao, inclusive nas preocupaes com a manuteno da continuidade da

recepo de contedo que gerado dinamicamente. Para tal, o projeto apresenta como
uma opo o uso de pequenos fragmentos de vdeo que so criados no servidor e ento
enviados em partes, as quais vo sendo apresentadas em seqncia.
3.5 Concluso
Neste captulo foi feito um levantamento do cenrio atual da TV interativa. Fica
bem evidente o fato de que se trata de uma rea ainda nova, com muitas pesquisas e
padres diferentes. No mundo todo, as potencialidades das diversas alternativas ainda
no esto completamente claras.
Os modelos de programas e as respectivas aplicaes em TV interativa ainda
precisam ser implementados e testados de modo se verificar a sua atratividade e a
capacidade de garantir um grau de responsividade mnimo para programas de TV. O
poder de interao precisa ser devidamente balanceado com a facilidade de interao. O
fluxo de apresentao dos programas, por outro lado, precisa ser compatvel com a
produo e a veiculao dinmica de contedo. Por fim, a coerncia e diversidade do
contedo so fatores obviamente importantes, pois, ao contrrio do que ocorre em jogos
eletrnicos onde o prazer est em vencer desafios e as histrias tm funo secundria, o
31

prazer ao se assistir TV est em acompanhar as histrias. Se essas no tiverem coerncia

ou se tornarem repetitivas, o interesse do usurio tende a ser facilmente perdido.
No que tange TV digital interativa, deve-se destacar que a implementao de
programao interativa no SBTVD tender a ser facilitada com a utilizao do Ginga.
H, contudo, desafios a serem vencidos no que tange comercializao de set-top
boxes, criao de modelos de negcio e, finalmente, ao desenvolvimento de aplicaes
fora da esfera acadmica pela indstria.
Este trabalho visa utilizar a televiso digital interativa como mote, propondo a
criao de um modelo distribudo de storytelling interativo compatvel com requisitos
de responsividade e escalabilidade tpicos da TV, com variados nveis de interao
(inclusive entre mltiplos usurios) e que garanta a coerncia e diversidade das
histrias. Para tal, um alto custo de processamento para a criao de enredos e sua
dramatizao atravs de animaes grficas 3D demandado. Tendo em vista o poder
computacional limitado das set-top boxes e as limitaes de banda para transmisso de
dados, arquiteturas para a distribuio do processamento e a interao com o contedo
precisam ser estudadas, como ser melhor explicado nos prximos captulos.
De todo modo, importante ressaltar que, embora inspirado no contexto de TV
digital interativa, o trabalho no est atrelado ao uso de middleware especfico de TV
digital. A adequao do prottipo para a TV digital interativa uma das possibilidades
mais atraentes, mas no a nica, pois os conceitos de TV interativa tambm podem ser
aplicados, por exemplo, TV via internet e via celular.
No captulo 4 ser apresentado o Logtell, o sistema de storytelling interativo
usado como base para a implementao das idias apresentadas nesta dissertao.

32

4. Logtell
Dentre os sistemas para storytelling interativo existentes, foi escolhido como
base para esta pesquisa o Logtell. Ele apresenta algumas semelhanas e diferenas com
os outros sistemas de storytelling, porm contm uma srie de caractersticas que so
compatveis o objetivo deste trabalho: demonstrar a viabilidade de um modelo de
storytelling interativo que concilie os requisitos demandados por um ambiente de TV
interativa. Neste modelo, preciso que a coerncia e a diversidade dos enredos sejam
garantidas, pois a importncia dos enredos tende a ser maior nesse ambiente do que em
jogos, por exemplo. Por outro lado, mecanismos de interao adequados precisam ser
oferecidos de modo a no demandar grande esforo de ateno. Os processos de
gerao, interao e apresentao das histrias precisam ocorrer em paralelo, em tempo
real e atendendo a requisitos de responsividade prprios do meio de comunicao. Por
fim, o modelo deve prever uma arquitetura distribuda e escalvel.
O Logtell (POZZER 2005) (CIARLINI et al. 2005) um sistema de storytelling
interativo que vem sendo desenvolvido j h algum tempo. A sua abordagem parece ser
boa para TV interativa, pois tem o foco na manuteno de histrias coerentes, mas
permitindo que o usurio possa interferir na histria em diferentes nveis. O usurio
pode escolher no interferir na histria ou ter uma participao mais forte,
estabelecendo, por exemplo, que certos eventos ou situaes ocorram, desde que sejam
logicamente coerentes com o modelo especificado para o gnero de histria que est
sendo usado. Uma das principais caractersticas do Logtell atual que no apropriada
para a televiso interativa que, nele, a gerao e a dramatizao da histria so
separadas, concentrando-se a interatividade na fase de gerao. Para levar o Logtell para
um ambiente de TV interativa, preciso realizar essas atividades em paralelo,
encontrando mecanismos confortveis para a interao.

33

Figura 4.1: Arquitetura inicial do Logtell

Na arquitetura inicial do Logtell, as responsabilidades so divididas entre
diferentes mdulos, responsveis pela gerao, interao e visualizao de histrias,
como demonstrado na Figura 4.1. A seguir so apresentados esses processos indicando o
papel de cada mdulo.
4.1 Gerao de histrias
A abordagem utilizada pelo Logtell procura gerar e dramatizar histrias variadas
de um determinado gnero, tomando como base a especificao deste por meio de
lgica formal. A idia principal permitir que o usurio possa interferir na histria
desde que se mantenha a coerncia das histrias.
O Logtell, ao privilegiar a coerncia lgica na sua estratgia de gerao de
narrativas, tem um aspecto predominantemente plot-based, mas que conciliado com
caractersticas character-based. O Logtell inspirou-se inicialmente nas idias de Propp,
estendendo, porm, a sua noo um tanto informal de funes, adotada em sua pesquisa.
Os eventos tpicos so descritos atravs de operaes parametrizadas com pr-condies
e ps-condies, de forma a serem aplicveis por algoritmos de planejamento. A faceta
character-based definida atravs de regras de inferncia de objetivos que fornecem os
objetivos a serem alcanados pelos personagens quando determinadas situaes so
observadas.
As funes proppianas so base para a gerao de enredos em diversas pesquisas
de storytelling interativo, conforme mencionado no captulo 2. No trabalho de Propp,
um conjunto grande enredos de contos de fadas russos foi analisado e da foram
extradas as funes que correspondem a eventos tpicos que tendem a se combinar
34

segundo certos padres. De forma anloga, outros gneros literrios podem ser
analisados de modo a se extrarem os eventos tpicos e os padres de combinao.
Em histrias convencionais, os eventos que acontecem geralmente no ocorrem
de forma catica e aleatria. Na maioria das histrias convencionais interessantes, h
sempre uma lgica por trs dos eventos, que em geral tcita, mas compreensvel.
Espectadores/leitores j acostumados com histrias de um determinado gnero podem
facilmente determinar se certa histria est de acordo com os padres de lgica
implcitos no gnero. Eventos ocorrem para que objetivos (dos personagens ou da
histria como um todo) sejam atingidos ou para produzir as condies que permitam o
acontecimento de outros eventos. Os eventos, por sua vez, acabam modificando o
mundo, o que pode propiciar o aparecimento de novos objetivos que fazem com que a
histria se desenvolva. Dessa forma, se um modelo para a gerao automtica de
enredos deseja garantir a coerncia das narrativas, esse modelo precisa, de algum modo,
capturar a lgica embutida no gnero com que trabalha.
O contexto das histrias no Logtell contm as seguintes informaes sobre a
lgica dos enredos a serem gerados:

um conjunto de operaes parametrizadas com pr- e ps-condies,

especificando logicamente quais eventos podem ocorrer

um conjunto de regras de inferncias de objetivos especificadas com uma lgica

temporal modal, declarando situaes que levam os personagens a buscarem
objetivos; e

um conjunto de fatos que definem a configurao inicial das histrias a serem

geradas.
A experincia de storytelling interativo no Logtell possui uma diferena de

paradigma ntida tanto em relao a jogos quanto experincia de se ler um livro ou

assistir a um filme. Em jogos, o usurio interage constantemente, mas o contedo da
histria tem importncia secundria. Na experincia de se assistir a um filme ou ler um
livro, o contedo das histrias fundamental, mas no h interao. No Logtell, o
usurio passa a ser tambm um pouco autor, na medida em que as possveis seqncias
de eventos no so estabelecidas previamente e podem ser decisivamente influenciadas
por suas intervenes. Para que histrias interessantes surjam dinamicamente, contudo,
necessrio um esforo autoral prvio para definir um bom conjunto de regras e
35

eventos.
Os enredos no Logtell so gerados por um mdulo implementado em Prolog,
chamado IPG (Interactive Plot Generator) (CIARLINI 1999). O IPG gera enredos em
mltiplos estgios que alternam fases de inferncia de objetivos, planejamento e
interao com o usurio.
O IPG possui dois submdulos: um para inferncia de objetivos e um para
planejamento. O seu planejador uma extenso do Abtweak (YANG et al., 1996), que
um planejador hierrquico e no-linear. O planejador permite a definio de uma
hierarquia de pr-condies, de modo que haja uma priorizao na busca de solues.
Por outro lado, por ser um planejador no-linear (ou planejador que planeja no espao
de planos) trabalha com ordens parciais de eventos. No planejamento no espao de
planos, adota-se uma abordagem de comprometimento mnimo, segundo a qual relaes
de ordem entre os eventos e restries sobre os valores de variveis so estabelecidos
apenas quando estritamente necessrias. A abordagem adotada facilita, em especial, a
conciliao de mltiplos objetivos, a gerao de alternativas e a flexibilidade para a
dramatizao dos enredos. O planejador do IPG estendeu o Abtweak com a
incorporao de Constraint Logic Programming (MARRIOT e STUCKEY, 1998), que
facilita o tratamento de pr-condies envolvendo expresses numricas, e conceitos
que permitem o abandono de objetivos.
A gerao de uma histria comea com a inferncia de objetivos dos
personagens ou da histria a partir da configurao inicial. O sistema ento usa o
planejador que, respeitando as pr-condies e ps-condies, insere eventos no enredo
para permitir o alcance dos objetivos. Quando o planejador percebe que todos os
objetivos foram alcanados ou abandonados, o primeiro estgio do processo termina. O
enredo parcial ento apresentado atravs do Plot Manager e pode, se o usurio assim
desejar, ser dramatizado. Quando o usurio no gosta do enredo parcial, pode solicitar
ao IPG a gerao uma alternativa. Se o usurio aceita o enredo gerado at ento, o
processo continua, inferindo novos objetivos, decorrentes de situaes criadas pelos
eventos inseridos na etapa anterior. Se novos objetivos so inferidos, o planejador
utilizado novamente, e assim sucessivamente a histria vai sendo gerada. O processo
continua at o momento em que o usurio decide parar ou nenhum objetivo novo
inferido. Nas fases de interao, o usurio pode tambm tentar inserir forosamente
eventos ou situaes. Se essas inseres respeitam a lgica do gnero, o enredo
adaptado para acomod-las, caso contrrio so rejeitadas.
36

Note que, nesse processo de gerao das histrias, so usados tanto forward
quanto backward reasoning. Na fase de inferncia de objetivos, usado o forward
reasoning: as situaes do passado geram objetivos a serem alcanados no futuro. Na
fase de planejamento, um evento inserido no enredo, para realizar algum objetivo, pode
ter pr-condies no satisfeitas, tratadas atravs de backward reasoning. Para
estabelec-las, o planejador pode inserir eventos anteriores com suas prprias prcondies no satisfeitas e assim sucessivamente.
A arquitetura do Logtell prev que as informaes de contexto sejam
armazenadas em um banco de dados acessado atravs do Context Control Module
(CCM). O CCM prov facilidades de interface e de armazenamento para a autoria de
contextos, mas no chegou a ser plenamente integrado ao Logtell. Esse mdulo capaz
de gerar um arquivo de contexto em Prolog com as informaes necessrias para o IPG.
Em futuras verses, o CCM dever ser plenamente integrado na arquitetura,
armazenando tambm informaes relativas dramatizao dos enredos.
As configuraes iniciais e os demais estados das histrias so compostos por
conjuntos de fatos que descrevem a situao de personagens e lugares e os seus
relacionamentos. No Prolog, um fato expressando, por exemplo, que o lugar atual de
Brian

Gray

Castle

seria

denotado

pela

clusula

de

predicado

current_place('Brian','Gray_Castle'), aonde Brian um personagem e Gray Castle um

local (usados no contexto testado usado na pesquisa). Os fatos da configurao inicial
podem ser modificados pelos eventos gerados (que so as execues dos operadores do
planejador), conforme a histria se desenrola. Na tabela 4.1, h uma lista dos predicados
Prolog usados para representar situaes no contexto exemplo de contos de fadas
(subgnero espadas e drages) usado no Logtell.

Predicado

Descrio

knight

Indica que um personagem um cavaleiro

princess

Indica que um personagem uma princesa

magician

Indica que um personagem um mago

dragon

Indica que um personagem um drago

nature

Indica a natureza de um personagem (se

bom, mau, ou neutro)

strength

Indica a fora de um personagem

alive

Indica se um personagem est vivo

37

place

Indica a existncia de um local

protection

Indica o nvel de proteo de um local

home

Indica o local inicial de um personagem

current_place

Indica o local atual de um personagem

affection

Indica o nvel de afeio de um

personagem por outro

hero

Indica que um personagem um heri

victim

Indica que um personagem uma vtima

villain

Indica que um personagem um vilo

donor

Indica que um personagem um doador

(de fora)
Tabela 4.1: Predicados usados no contexto exemplo do Logtell e suas descries
Os eventos inseridos na histria so instncias das operaes definidas no
contexto. Uma operao um padro de evento tpico do gnero (contendo variveis).
Pr-condies e ps-condies so especificadas usando os predicados de descrio de
situaes do contexto. Na tabela 4.2 temos uma lista dos possveis eventos que podem
ocorrer no contexto exemplo.

Evento

Descrio

go

Indica que um personagem vai a algum

local

reduce_protection

Indica que um personagem reduz a

proteo de um local (ex: dispensa os
guardas)

kidnap

Indica que um personagem seqestra o

outro

attack

Indica que um personagem ataca as defesas

de um local

fight

Indica que um personagem ataca outro

kill

Indica que um personagem mata outro

free

Indica que um personagem liberta outro

marry

Indica que um personagem casa-se com

outro

donate

Indica que um personagem aumenta a fora

de outro

bewitch
Indica que personagem enfeitia o outro
Tabela 4.2: Lista de Eventos possveis no contexto exemplo do Logtell
38

As regras de inferncia de objetivos usadas pelo IPG, especificadas num

formalismo de lgica temporal modal (CIARLINI et al., 2000), definem os objetivos
que os personagens de determinadas classes (heri, vilo, vtima) passam a perseguir
quando certas situaes se observam. Essas regras usam meta-predicados para falar
sobre a ocorrncia de um evento em um determinado tempo ou sobre a veracidade de
um fato (ou sua negao) em determinado momento. O formalismo incorpora o
tratamento das ordens parciais de eventos, uma vez que a veracidade de um fato pode
depender ou no da ordem dos eventos.
Uma regra de inferncia de objetivos tirada do contexto exemplo diz que se
uma vtima fica desprotegida e h um vilo, este vai querer rapt-la. Outra regra, quase
que complementar, diz que se uma vtima raptada e h um heri que gosta dela, este
vai querer resgat-la. importante ressaltar que as regras no ditam diretamente as
reaes dos personagens. As regras apenas indicam objetivos a serem perseguidos. Os
eventos que vo conseguir realizar os objetivos so preenchidos pelo algoritmo de
planejamento.
A tabela 4.3 a seguir apresenta uma lista com as regras que foram modeladas
para o contexto exemplo.

Regra

Descrio

The strongest hero wants to become

stronger than the villain

Quando existir um heri e um vilo em um

determinado momento, e a fora do vilo
for maior do que a do heri, este tentar
ficar mais forte

Victim spontaneously reduces the

protection at her current location

Uma vtima, quando em local da mesma

natureza que a sua (boa, m, etc), por
algum motivo tolo acaba ficando em uma
situao desprotegida, ou seja, se pe em
perigo

If victim's protection is reduced, villain

will want to kidnap her

Se uma vtima estiver num local

suficientemente desprotegido, um vilo
tentar seqestr-la

If victim is kidnapped, hero will want to

rescue her

Se uma vtima for seqestrada, um heri

tentar libert-la

If victim is killed, hero will want to avenge

her

Se uma vtima for morta, o heri tentar

ving-la

If the affection between two persons is

high they will want to get married

Se a afeio entre 2 personagens for grande

eles vo querer se casar
39

Tabela 4.3: Lista de regras no exemplo do Logtell

4.2 Interao com o Usurio
O foco principal do sistema no quesito interatividade dar os meios para o
usurio explorar qualquer alternativa de histria coerente com o contexto especificado
logicamente. Para garantir a coerncia das histrias, a interao sempre indireta. O
usurio no intervm na histria como um personagem nem manipula os objetos do
cenrio diretamente. Por outro lado, ele pode selecionar alternativas e interagir de forma
mais ativa com intervenes fortes, sujeitas validao pelo IPG.
Na verso inicial do Logtell, a interao com o usurio ocorre atravs do Plot
Manager que um mdulo implementado em Java. O Plot Manager tambm
responsvel pelo controle geral da experincia de storytelling interativo, acionando o
IPG para gerar enredos e o Drama Manager para dramatiz-los. A experincia de
interao nessa verso ocorre apenas atravs de um processo de simulao passo-apasso, pois a dramatizao da histria no ocorre em paralelo com a gerao do enredo.
Partes do enredo so geradas e apresentadas ao usurio, que tem a oportunidade de
interagir e de solicitar a dramatizao do enredo gerado at ento, podendo retomar o
processo de gerao em seguida.
O Plot Manager possui uma interface grfica, mostrada na Figura 4.2. Os
eventos e objetivos do enredo parcialmente gerado so informados pelo IPG ao Plot
Manager que os apresenta sob a forma de um grafo onde as restries de ordem
temporal entre os eventos so explicitadas.
Para acomodar mais facilmente a busca por objetivos diferentes, o IPG trabalha
com ordens parciais dos eventos, onde estabelecido que um evento deve preceder
outro apenas quando necessrio. Para que a dramatizao seja possvel, no entanto,
preciso que os eventos estejam totalmente ordenados, de forma compatvel com as
restries de ordem j impostas pelo IPG. Para determinar a seqncia, o usurio traa
arestas conectando os eventos em uma ordem de seu gosto. A seqncia encadeada,
corresponda ela a um enredo parcial ou total, pode ser dramatizada usando o comando
render.
A interao utiliza dois comandos principais da interface: o comando another e o
comando continue. O comando another pede ao Logtell que faa um retrocesso e
fornea outra alternativa para o passo de simulao recentemente terminado, mas que
ainda no foi confirmado. O comando continue confirma o enredo at o ponto
40

apresentado e solicita a continuidade do processo de simulao passo-a-passo, com nova

inferncia de objetivos e planejamento subseqente.

Figura 4.2: Interao Passo a Passo

As intervenes do usurio podem ser classificadas como fracas ou fortes. Na
interveno fraca, o usurio aciona apenas os dois comandos citados anteriormente e,
para permitir a dramatizao, adiciona restries de precedncia entre os eventos. A
definio de restries de ordens encarada como uma interveno (no caso fraca)
porque, alm de indicar a ordem de dramatizao, pode levar a mudanas na inferncia
futura de objetivos, se o processo de gerao for continuado. Os enredos obtidos apenas
com intervenes fracas tendem a no se afastar muito das histrias tpicas do gnero.
Intervenes fortes podem ocorrer de duas maneiras. Uma delas com o
comando insert situation, que permite a especificao de objetivos a serem alcanados,
ficando a forma como sero alcanados a cargo do IPG. Note que a situao inserida
pode falhar caso no se ache nenhum plano possvel ou se o esforo computacional
exceder a configurao inicial do planejador. Outro modo de se fazer interaes fortes
a insero explcita de eventos, usando o comando insert event. Assim como no caso
anterior, o comando continue deve ser usado para validar as interaes desejadas. O
usurio pode tambm desfazer a interveno, removendo os eventos ainda no
incorporados e/ou rejeitados.
4.3 Dramatizao
A dramatizao feita pelo Drama Manager usando um motor grfico prprio
(POZZER, 2005), implementado em C++. O motor grfico usa a API OpenGL para
suportar a renderizao em tempo real dos elementos 3D. Os personagens de um enredo
gerado so interpretados por atores virtuais. Cada ator implementado como um agente
reativo 3D virtual. A dramatizao no realiza nenhum processamento inteligente no que
diz respeito ao enredo, pois segue a seqncia ordenada de eventos gerados previamente
41

pelo processo de simulao. O Drama Manager traduz eventos simblicos em

animaes visuais, garantindo a sincronia e a coerncia entre o contexto lgico e a sua
representao grfica. Cada evento renderizado, em tempo real, sincronizando as
aes dos personagens e controlando a interao deles com o cenrio. Outros aspectos
da representao grfica, como a renderizao de legendas, enviadas pelo Plot Manager,
tambm so de responsabilidade do Drama Manager.

Figura 4.3: Histria sendo dramatizada no Logtell

Durante a gerao dos enredos, a durao de cada evento no considerada. A
mudana no mundo da histria causada por um evento considerada como instantnea
para fins de planejamento e inferncia de objetivos. Para propsitos de dramatizao, o
conceito de tempo um pouco diferente. Eventos precisam ter uma durao de modo
que possam ser compreendidos pelo usurio. Atributos variveis mudam conforme um
evento representado. Para fazer com que as representaes lgica e grfica sejam
compatveis, os valores dos atributos antes da dramatizao de cada evento devem ser
vlidos em relao s pr-condies do evento e os valores ao final de sua dramatizao,
compatveis com suas ps-condies. O Drama Manager se encarrega de garantir essa
compatibilidade. Ao inicializar o motor grfico, o Drama Manager consulta o IPG sobre
o estado dos atores, locais e outros atributos necessrios. Feito isto, o sistema capaz de
manter-se consistente com o contexto lgico.
O processo de dramatizao inicia com a seleo de um evento pelo usurio e o
acionamento do comando render na interface do Plot Manager. A partir do ponto
selecionado, a histria ser exibida, respeitando-se a ordem dada aos eventos pelo
usurio, a menos que o usurio a interrompa. Para a renderizao, preciso definir os
valores corretos dos atributos grficos. No caso da renderizao a partir do primeiro
42

evento da histria, os valores so definidos atravs de consulta ao IPG como j foi

explicado. Renderizaes a partir de pontos intermedirios tambm so possveis, mas o
evento correspondente a esse ponto precisa j ter sido previamente renderizado. Isso
possvel porque, quando cada evento comea a ser apresentado, o motor guarda, em um
banco de dados local, todos os atributos de todos os atores e objetos em cena. usada,
como chave primria para a recuperao dos valores, o momento do evento
(representado por seu timestamp, na terminologia mais usual de bancos de dados).
O usurio pode sempre alternar entre a gerao do enredo e sua dramatizao.
Nesse caso, depois da dramatizao, novos eventos e restries temporais de ordem
entre os eventos podem ser adicionadas pelo usurio ou pelo prprio IPG. Se a
dramatizao for reativada, ela pode somente iniciar em eventos que ocorrem antes das
modificaes.
O Drama Manager converte todos os eventos em aes de menor granularidade,
que so delegadas aos atores especficos. Quando um evento termina, o Drama
Manager pergunta ao Plot Manager qual ser o prximo evento a ser apresentado.
Nesse momento, tambm enviada ao Drama Manager a legenda que descreve o
prximo evento. Se no houver mais eventos a serem apresentados, a dramatizao
termina. A dramatizao de um evento termina quando os atores envolvidos representam
as animaes associadas sua execuo. Nos testes realizados com o contexto exemplo,
a dramatizao de cada evento pode levar de alguns segundos a alguns minutos,
dependendo da complexidade do evento.
O motor grfico utiliza cenrios especficos para a representao grfica das
histrias. Esses cenrio so representados por modelos 3D em um ambiente apropriado
para os eventos e personagens que a histria pode conter, de acordo com as convenes
do gnero, como castelos e florestas em contos de fada.
Como a maioria dos eventos tem relao direta com os locais onde acontecem,
os atores devem ser controlados restritamente conforme se movem durante os eventos,
garantindo a coerncia com o enredo enquanto o interpretam. As construes, tais como
castelos e igrejas, servem no apenas para embelezar o cenrio. Elas so fundamentais
para a orientao das posies dos personagens, o tratamento de colises, e o
condicionamento da forma como os atores se movimentam. O motor grfico usa um
planejamento de baixo nvel baseado em waypoints (POZZER et al., 2004) e a tcnica
de terrain reasoning, para controlar a movimentao dos atores.
Durante a representao grfica, o Drama Manager atua como um diretor,
43

coordenando as seqncias de aes lineares ou paralelas, realizadas pelo elenco de

atores. O Drama Manager monitora o processo da dramatizao, ativando novas tarefas
na ordem em que as anteriores terminam. Tambm se inclui nas suas responsabilidades,
o controle de cmera, que o Logtell tambm permite que seja exercido pelo usurio.
Alm dos atores que representam os personagens da histria, o Drama Manager
tambm inclui figurantes em suas representaes. Esses figurantes ajudam a enriquecer
a experincia de visualizao da histria e possuem um certo grau de autonomia, porm
restrito a seus papis. No contexto exemplo de espadas e drages, esses figurantes so
os soldados, que servem como forma de representao do nvel de proteo de
determinados locais, como guardas de um castelo, por exemplo. Dessa forma, podem
ajudar a complementar a histria sem causarem grandes mudanas na sua estrutura
dramtica. Por no serem de fato personagens, reduzem o esforo computacional na
criao do enredo, pois, para o IPG, eles no existem. Alm disso, trata-se de um
recurso largamente utilizado em outras mdias narrativas como filmes e sries de
televiso, em momentos em que se precisa contextualizar o enredo com figuras humanas
realizando determinadas aes, mas sem um papel dramtico de fato.
4.4 Demais Aspectos
Diversas outras pesquisas na rea de storytelling interativo foram e vm sendo
desenvolvidas utilizando o Logtell e o IPG, das quais podero resultar mecanismos a
serem incorporados ao sistema no futuro.
Na seqncia da implementao do IPG, foi feito um trabalho inicial em
(FURTADO e CIARLINI, 2000) para a narrao dos enredos na forma de textos. As
narrativas geradas tinham uma boa dose de redundncia, mas o trabalho mostrou a
viabilidade da utilizao das informaes lgicas contidas no enredo para a obteno de
textos que contam as histrias.
O IPG contm um mecanismo de reconhecimento de planos tpicos com base na
observao de eventos. Planos tpicos podem ser incorporados, adaptados e estendidos
nos enredos. Foi feito inicialmente um estudo sobre a criao automtica de bibliotecas
de planos tpicos (FURTADO e CIARLINI, 2001). Melhorias para a interface atual do
Logtell baseadas tambm no uso de planos tpicos e no seu reconhecimento pelo IPG
(KARLSSON et al., 2006) tambm vm sendo estudadas. Elas permitiro que, durante o
processo de criao, novos comandos interativos incorporem ao enredo estruturas
recorrentes nos gneros narrativos (motivos).
44

Em (RODRIGUES et al., 2006) descrita a criao de uma narradora virtual em

3D, capaz de expressar determinadas emoes conforme a histria representada, o que
uma alternativa interessante, particularmente no que tange ao uso de storytelling
interativo com intuitos educacionais ou para crianas. Esse trabalho abre tambm
possibilidades de investigao interessantes no que se refere ao uso e representao
lgica de emoes em storytelling interativo.
Em (DORIA et al., 2008), um novo modelo para controlar o processo de
dramatizao de histrias interativas proposto e aplicado no Logtell. Esse modelo se
baseia na associao de cada evento a um autmato no-determinstico que descreve
aes mais bsicas. Atravs disso, procura-se obter maior variedade na dramatizao e
maior flexibilidade para o controle do tempo de cada evento. Abre-se tambm a
possibilidade de algum tipo de interao tambm no nvel de dramatizao, mantendo,
porm, a coerncia com o enredo.
Ainda restam muitos outros aspectos a serem pesquisados, como, por exemplo,
um melhor uso das cmeras, o uso de msicas e trilhas sonoras, dilogos e todos os
outros aspectos que fazem parte da experincia multimdia j presente em outros meios
como em filmes, jogos e programas de televiso. Grande parte desses aspectos passa
pela dificuldade de se modelar e tratar adequadamente emoes tanto na gerao de
enredos quanto na sua dramatizao.
Por fim, um grande desafio a questo autoral: o contexto exemplo de Espadas
e Drages tem servido para testar conceitos e avaliar questes fundamentais. No
entanto, a produo em larga escala de enredos interativos demanda a implementao de
ferramentas que facilitem a especificao do contexto das histrias.
4.5 Concluses
Este captulo demonstrou como funciona o Logtell, explicando o seu modelo de
gerao e dramatizao de histrias interativas. O Logtell um sistema de storytelling
interativo que apresenta algumas caractersticas interessantes para a utilizao em um
ambiente de TV interativa.
Em primeiro lugar, ao gerar variados enredos logicamente consistentes por
construo, possibilita um melhor atendimento ao requisito de coerncia da
apresentao de narrativas na TV. Em segundo lugar, ao contar histrias interativas em
terceira pessoa, facilita o compartilhamento de uma mesma histria por vrios usurios.
Para se poder usar sistemas de storytelling interativo em mdias como a TV
45

interativa, alm da dificuldade de se equilibrar coerncia e interatividade, deve-se

considerar que se precisa encontrar uma forma hbrida de apresentao de contedo
multimdia, misturando caractersticas de jogos e televiso normal. necessrio manter
o apelo para o espectador comum, e, ao mesmo tempo, permitir que o usurio seja capaz
de interagir de diferentes maneiras com o contedo que lhe apresentado. Um sistema
de storytelling interativo, quando aplicado a este caso, deve inclusive considerar o fato
de que o usurio pode nem mesmo querer interagir de modo algum. O sistema precisa
ter tanta responsividade quanto possvel e a histria deve ser fluente, sempre mantendo
a simplicidade e a sensao de conforto na interao, especialmente considerando-se
que as histrias em geral sero assistidas por espectadores que podem no ser vidos
usurios de jogos eletrnicos. Ao usurio deve ser permitido interagir de acordo com seu
gosto. Dessa forma, o Logtell, ao possibilitar variados nveis de interao, d uma boa
base para se tentar obter mecanismos de interao adequados para diferentes tipos de
usurios.
Uma das caractersticas do Logtell atual que no apropriada para a TV
interativa que a gerao e a dramatizao da histria so separadas, concentrando-se a
interatividade na fase de gerao. Para levar o Logtell para um ambiente de TV
interativa, preciso realizar essas atividades em paralelo, encontrando mecanismos
confortveis para a interao.
Para isso, no prximo captulo, apresentado um novo modelo de sistema de
storytelling interativo adequado para a TV, onde o usurio pode assistir e interagir com a
histria em paralelo com a gerao do enredo, mantendo um fluxo contnuo de
apresentao. Alm disso, o modelo procura ser escalvel para um nmero grande de
usurios.

46

5. Modelo de Storytelling Interativo para TV

Neste captulo, apresentada uma nova proposta de modelo de storytelling
interativo que procura ser compatvel com um ambiente de TV interativa (CAMANHO
et al., 2008). Para tal, esse modelo de storytelling deve:

possibilitar a gerao de histrias variadas, coerentes e que resultem da interao

com o usurio;

permitir um fluxo contnuo, onde a criao de histrias ocorra em paralelo com a

sua apresentao e a interao com o usurio;

possuir uma arquitetura escalvel;

apresentar novas maneiras de interatividade, adequadas a diferentes modelos de

espectador e formas de apresentao, tendo em mente especialmente modelos
que sejam apropriados para a televiso interativa.

Como ponto de partida para a definio do modelo, usou-se a abordagem

adotada na primeira verso do Logtell. O Logtell, com sua nfase em uma simulao
baseada em lgica para a gerao dos enredos, tem um bom potencial para atender ao
requisito de coerncia. Por outro lado, ao oferecer tipos de interveno em variados
nveis, fornece flexibilidade para que o usurio possa interagir tanto de forma mais ativa
quanto mais passiva. Por outro lado, o modelo do Logtell precisa ser devidamente
modificado para se obter um resultado compatvel com requisitos de responsividade,
como a continuidade do fluxo e a comodidade durante a interao.
No restante deste captulo, discorremos sobre os requisitos do modelo e ento
apresentamos uma nova arquitetura projetada para atender a esses requisitos. Em
seguida, detalhamos mecanismos bsicos para a interao no novo modelo, a
coordenao da interao com mltiplos usurios e possveis estratgias para a
manuteno de um fluxo contnuo de apresentao. Por fim, abordamos outros
mecanismos avanados de interao que podem ser viabilizados.
5.1 Requisitos
5.1.2 Fluxo Contnuo
No intuito de proporcionar ao usurio final, que assiste TV interativa, uma
47

experincia agradvel, necessrio que o contedo seja apresentado de forma contnua,

sem interrupes, e que o usurio possa interagir a qualquer momento. Para tal, so
necessrias estratgias de coordenao, de modo que o contedo da histria seja gerado
em partes e que, enquanto uma parte do enredo dramatizada, novas partes sejam
produzidas. Na primeira verso do Logtell, o enredo gerado em separado da
dramatizao. Entre uma etapa e outra da gerao, o usurio pode interagir e at acionar
a dramatizao, para depois voltar ao processo de gerao. O autor do contexto pode
definir regras e explorar a coerncia lgica dessas regras verificando apenas o enredo,
descrito sob a forma de um grafo, sem ter que acionar a dramatizao. Para o usurio
comum, que normalmente no seria o autor do contexto, esse processo, com o fluxo
interrompido, ainda mais em um ambiente onde est acostumado a assistir s
histrias, parece ser pouco usual. O usurio se sente mais autor do que espectador, por
ter que preparar o enredo e somente ento assistir sua dramatizao.
Com a implementao de um fluxo contnuo no processo de gerao e
dramatizao da histria, obtm-se experincias potencialmente mais interessantes para
o usurio final da TV interativa, pois expandem-se as possibilidades de interatividade.
O usurio passa a de fato assistir a uma histria, e, segundo seus desejos,
modific-la, se assim for do seu interesse. O usurio pode ser um espectador passivo na
maior parte do tempo, se assim o desejar, aderindo-se dessa forma ao conceito de
interatividade preguiosa, citado anteriormente, e que tem sido adotado em algumas
outras aplicaes para a TV interativa. Por outro lado, intervenes fortes, no estilo do
Logtell, podem ser feitas com pouco esforo, levando o enredo para caminhos
completamente distintos. Alm disso, intervenes podem acontecer diversas vezes e a
qualquer momento, possibilitando que usurio assuma uma postura mais ativa.
Para que a idia de fluxo contnuo fosse vivel, introduziu-se no novo modelo o
conceito de captulos. Esse conceito, prprio da estrutura de narrativas, j existia de
certa forma no modo passo-a-passo do Logtell, pois uma fase de gerao era composta
pela interao com o usurio, seguida da inferncia de objetivos e do planejamento,
vindo depois uma nova fase de gerao. Um captulo, no fluxo contnuo, corresponde a
uma fase de gerao seguida de uma ordenao automtica dos eventos, ou seja um
conjunto de eventos ordenados que se traduziram em cenas (uma por evento). A
ordenao dos eventos precisa ser automtica, dado que o usurio no tem tempo para
fazer isso, como acontece no modo passo-a-passo. Como a histria apresentada em
paralelo, assume-se que qualquer interao s pode mudar captulos posteriores, pois
48

no faz sentido mudar a parte da histria que j se assistiu (exceto se o usurio desejar
repetir todo o processo de gerao). Um captulo delimita ento um pedao da histria
onde um ou mais objetivos foram inferidos ou decorreram de intervenes do usurio, e,
por meio de planejamento, eventos foram inseridos para alcanar esses objetivos, os
quais receberam automaticamente uma ordenao total, compatvel com a ordem parcial
produzida pelo planejador.
Uma das maiores preocupaes no que tange continuidade do fluxo evitar
interrupes durante o processo de gerao e dramatizao das histrias. Como ser
explicado em maiores detalhes adiante, estratgias especficas precisam ser adotadas
para escrever a histria que est por vir com pelo menos um captulo de folga frente
do captulo que o usurio esteja assistindo. Mesmo assim, h tambm a possibilidade de
que, devido ao excesso de carga, e tambm devido ao fato de que o processo de gerao
do enredo ser custoso em termos de processamento, existam breves interrupes. Para
lidar com esse problema, possvel pensar em mecanismos que alonguem o captulo
corrente atravs de uma dramatizao mais flexvel, que receba comandos para acelerar
ou retardar os eventos conforme a necessidade. Outras opes correspondem
introduo de propagandas, num contexto comercial, ou ainda introduo de fillers, ou
seja, momentos em que nada de significativamente importante acontece, mas imagens e
sons so exibidos, no mesmo estilo do que feito em filmes, novelas, etc., quando se
mostram paisagens, cenrios etc.
5.1.3 Diversidade de Enredos
Para que o modelo proposto proporcione uma experincia interessante na TV
interativa, tambm importante que o sistema utilizado para a gerao das histrias
tenha um mnimo de diversidade nos enredos gerados. O usurio facilmente se cansar
de assistir s histrias interativas, se no houver a oportunidade de interagir com
diferentes histrias.
Aplicaes como o Faade, citado no captulo 2, por exemplo, so capazes de
prover uma experincia interessante de aproximadamente 20 minutos, porm o seu grau
de variao um tanto limitado, por conter basicamente apenas uma situao dramtica.
A sua estrutura no muito generalista e, para a criao de novas histrias, imagina-se
que existir um grande esforo, dado que na histria atual houve um forte trabalho
autoral e muitas linhas de cdigo tiveram que ser escritas para suportar toda a estrutura
dramtica da situao modelada.
49

Somado a isso, deve-se ter a garantia, em um ambiente como o da TV, onde a

qualidade da histria tem importncia maior do que em jogos eletrnicos, por exemplo,
de que as histrias no perdero a coerncia com os pressupostos do gnero. H uma
intrnseca impossibilidade de se manter a interatividade e a coerncia em plenitude,
dada a natureza um tanto contraditria desses dois atributos. , portanto, admissvel que
se restrinjam as interaes do usurio quando elas no forem possveis ou no fizerem
sentido.
Nesta pesquisa, ao se adotar o Logtell como base, usufrui-se da vantagem de seu
motor gerador de enredos, o IPG, trabalhar com uma simulao baseada em lgica
formal que concilia abordagens plot-based e character-based. Ao combinar regras de
inferncia de objetivos (dos personagens e da histria) e planejamento, consegue-se uma
boa variedade de enredos em um nico contexto, todos eles coerentes por construo.
Praticamente qualquer enredo coerente com o gnero pode ser obtido. A conciliao da
interatividade com a coerncia feita simplesmente rejeitando intervenes que o
usurio tente fazer que no sejam lgicas. Continua sendo necessrio, no entanto, um
forte esforo autoral (como, de fato, exigido em qualquer histria, seja ela interativa
ou no). A diferena que, ao se modelar um contexto logicamente, os variados enredos
que podem ser obtidos no precisam necessariamente ter sido considerados previamente
pelo autor.
5.1.4 Coexistncia com Modo Passo-a-passo
O modelo de storytelling da primeira verso do Logtell previa a gerao dos
enredos alternando fases de simulao e interao.
Nas fases de interao, era possvel assistir, se desejado, dramatizao do
enredo gerado at o momento, mas sem interao enquanto a histria era apresentada.
Atravs desse processo, o usurio pode, com calma, definir exatamente o que quer, de
acordo com o enredo que obtido atravs do sistema. Pode tambm investigar a razo
pela qual as regras lgicas em conjunto com a interao guiam a histria em um certo
rumo.
Tal forma de interao justificada por seus diferentes usos possveis,
especialmente se aplicado num contexto no necessariamente de entretenimento. Por
exemplo, o prprio IPG j foi pensado tambm como uma ferramenta para sistemas de
apoio simulao em geral (como ambientes corporativos) e como ferramenta para
educao e a tomada de deciso (CIARLINI e FURTADO, 2002).
50

Em um contexto de TV interativa, um modo contnuo onde gerao dos enredos,

dramatizao e interao ocorrem continuamente tende a ser o modo principal de
utilizao do sistema. No entanto, um modo passo-a-passo, onde se pode examinar a
gerao dos enredos de forma anloga ao processo de depurao de programas, ainda
mantm sua utilidade.
O novo modelo proposto dever, portanto, manter a funcionalidade de gerao
de histrias em modo passo-a-passo, alternando passos de interao e criao das
narrativas, o que no comum em outros sistemas de storytelling interativo, e que por
aproximar mais ainda o espectador do autor, abre possibilidades de uso que no devem
ser desperdiadas, caso fosse totalmente substituda pela gerao em fluxo contnuo.
fundamental ressaltar, porm, que so estratgias completamente opostas, e que,
portanto, embora o modelo deva suportar as duas, razovel assumir que somente uma
seja usada em uma determinada histria de cada vez.
5.1.5 Facilidade de Interao e Possibilidades de Interao em Diversos Nveis
Em um ambiente de TV interativa, deve-se permitir que o usurio interaja com
facilidade, ou seja, que no lhe seja exigido um grande esforo, dado que,
diferentemente do que ocorre em jogos eletrnicos, o usurio de TV tende a estar com o
foco da ateno voltado para a histria e no para a sua agilidade na interao.
Por outro lado, preciso buscar atender aos anseios de diferentes estilos de
usurios. Usurios podem querer assumir uma postura bsica de espectador, interferindo
muito pouco no rumo da histria ou querer assumir uma postura mais ativa, onde as
suas intervenes acontecem continuamente e determinam o desencadeamento do
enredo.
necessrio, portanto, que exista suporte para variadas maneiras de interao,
com graus diferentes, no que concerne intensidade da interveno do usurio. A viso
do Logtell de interaes fracas e fortes compatvel com essa flexibilidade demandada
pelo ambiente. O usurio deve em um modo de interao contnuo, do mesmo jeito que
no modo passo-a-passo, ser capaz de fazer interferncias na histria que tm menos
fora, pedindo, por exemplo, ao gerador de enredos que fornea uma nova verso para
uma parte da histria recentemente apresentada. Alternativamente, o usurio deve ser
capaz de inserir eventos ou situaes especficas, desde que vlidos e coerentes com o
contexto. O desafio que todas essas alternativas de interao sejam possveis em um
modo de interao contnuo, sem demandar ateno exagerada do usurio.
51

O ambiente de TV interativa ainda um ambiente novo, que herda caractersticas

da TV tradicional e de sistemas computacionais em rede. Para se testar a viabilidade do
novo modelo de storytelling interativo preciso fornecer um conjunto de mecanismos
bsicos de interao que dem um mnimo de comodidade aos usurios para a interao.
Novos mecanismos de interao direta e indireta com as histrias podem ser mais
eficientes ou complementar bem o conjunto de mecanismos inicialmente definidos.
Deseja-se, portanto, que o novo modelo seja aberto, na medida do possvel,
incorporao de novos mtodos, de modo que sua eficcia e aceitabilidade por parte dos
usurios possam ser testadas.
5.1.6 Escalabilidade
Em um ambiente de storytelling interativo para TV, espera-se que haja muitos
usurios utilizando o mesmo sistema, compartilhando os mesmos contextos e at
mesmo interagindo em conjunto sobre uma mesma histria. fundamental, portanto,
prover um suporte robusto e escalvel que atenda s demandas de processamento.
O processo de gerao de histrias, por ser baseado em planejamento
automtico, tende a consumir uma boa quantidade de recursos de tempo e memria.
Como o nmero de usurios do sistema pode variar de um usurio nico a milhes de
usurios, necessrio que o sistema seja implementado segundo uma arquitetura
escalvel, onde, pela simples incorporao de novos recursos computacionais, consigase garantir a responsividade do sistema.
Na verso atual do Logtell, e tambm nos demais sistemas de storytelling
interativo estudados, as solues so, em geral, no escalveis e utilizam um modelo
convencional de uma nica mquina. Nesses casos, h uma limitao evidente ao
atendimento de maiores demandas ou a diversos usurios simultneos. O novo modelo,
portanto, ao ser proposto para a TV interativa, precisa levar em conta a questo da
escalabilidade.
5.2 Arquitetura Cliente-Servidor
O novo modelo prope uma arquitetura cliente-servidor. Tal arquitetura procura
atender tanto a requisitos funcionais como a requisitos no funcionais, como a
continuidade do fluxo, a confiabilidade, a escalabilidade, e a possibilidade de
incorporao de novas alternativas de interao e de diferentes usos da estrutura do
sistema de storytelling.
52

Em uma arquitetura cliente-servidor (TANENBAUM, 2003) trabalha-se com um

cenrio onde h um ou mais computadores controlando e disponibilizando o acesso a
recursos computacionais, os servidores, e outros que requisitam esses recursos, os
clientes. Nos sistemas que trabalham com esse tipo de arquitetura, o processamento fica
dividido entre os servidores e os clientes. As formas de distribuio do processamento e
de alocao dos recursos podem ser variadas e dependem dos objetivos que se deseja
atingir. Uma das maiores vantagens, para o caso do storytelling interativo na TV, que
diferentes clientes podem ser implementados para acessar os mesmos servidores,
permitindo a coexistncia de clientes para celular, TV digital e outras opes. Mais
detalhes sobre o servidor de aplicao utilizado no prottipo resultante dessa pesquisa
so dados no captulo 6.
A nova arquitetura proposta, usada para implementar uma nova verso do
Logtell (2.0), apresentada na Figura 5.1 Verifica-se que h vrios mdulos novos, com
diferentes responsabilidades. O processamento no Logtell 2.0, de modo diferente da
primeira verso, passa a distribuir o processamento entre um lado cliente e um lado
servidor. O lado do cliente responsvel pela interao e dramatizao das histrias. O
lado do servidor responsvel pela simulao que gera os enredos das histrias. Os
processos agora ocorrem em paralelo e devem ser coordenados entre si. Para cada
histria que est sendo apresentada, h uma aplicao em execuo no servidor,
enquanto que uma ou vrias aplicaes esto sendo utilizadas em diferentes clientes.
Isso lida com o caso onde vrios usurios esto assistindo mesma histria.

Figura 5.1: Nova Arquitetura do Logtell no Modelo Proposto

Pensando no caso da TV interativa digital, os set-top boxes certamente tero
53

recursos

computacionais

limitados,

que

tornaria

difcil

realizar

tarefas

computacionalmente intensas, como planejamento automatizado. Ao concentrar a

simulao em servidores de aplicaes, mais fcil alcanar uma melhor escalabilidade.
Alm disso, mais fcil exercer controle quando uma nica histria compartilhada por
vrios usurios.
Na verso anterior do Logtell (Figura 4.1), a interface principal do sistema
concentrava o controle geral da histria, atravs do Plot Manager, ativando uma nica
instncia do IPG e acionando o Drama Manager conforme necessrio. Alm disso,
mantinha-se sempre uma conexo com a instncia do IPG enquanto a histria era
narrada. Na nova arquitetura, esta interface se decomps em 3 mdulos de controle: o
Simulation Controller, o Interface Controller e a User Interface. O Simulation
Controller e o Interface Controller so executados no servidor e a User Interface
(interface grfica do usurio) no cliente.
A User Interface corresponde, na nova arquitetura, parte do Plot Manager, que,
na primeira verso do Logtell, era responsvel pela interao direta com o usurio. A
User Inteface implementa dois modos de interao diferentes: o modo a passo-a-passo,
com as mesmas funcionalidades disponibilizadas na primeira verso do Logtell; e o
modo contnuo, explicado em mais detalhes no item 5.3 adiante.
No lado do cliente, para utilizar as novas funcionalidades do modo contnuo, o
usurio interage com o sistema atravs da User Interface, que informa as interaes
desejadas ao Interface Controller localizado no servidor. No modo passo-a-passo, a
interface aciona diretamente o Simulation Controller. O Drama Manager requisita os
eventos a serem dramatizados ao Simulation Controller e controla os atores 3D que
representam cada personagem na dramatizao grfica 3D das histrias.
No lado do servidor, o Interface Controller recebe as sugestes s histrias
fornecidas por vrios clientes. Quando mltiplos usurios compartilham a mesma
histria, as interaes so selecionadas de acordo com o nmero de clientes que as
pediram. Em trabalhos futuros tambm podero ser usados outros critrios para esta
escolha, escolhendo no s as opes mais votadas, mas tambm fazendo um balano
com o quanto a sugesto escolhida ajuda a histria a continuar, por exemplo. As
sugestes so ento enviadas ao Simulation Controller, que responsvel por:

informar ao Drama Manager, no lado do cliente, os prximos eventos a serem

dramatizados, quando requisitado;
54

receber pedidos de interao e incorpor-los histria, utilizando instncias do

IPG;

contabilizar sugestes quando no modo multi-usurio, e ento us-las, se

possvel;

selecionar interaes viveis e possivelmente interessantes (de acordo com o seu

potencial de gerar eventos na histria), para serem disponibilizadas aos usurios;

controlar um nmero de instncias do Interactive Plot Generator para obter os

prximos eventos da histria; e

controlar o tempo gasto na simulao e na dramatizao.

As instncias do IPG realizam simulaes atravs da inferncia de objetivos e

usando planejamento automatizado para a realizao desses objetivos. Para conseguir
fazer isso, o contexto das histrias consultado.
Para manter a responsividade, o fluxo de apresentao precisa ser contnuo.
Desse modo, a simulao precisa estar sempre pelo menos um captulo frente da
dramatizao. Quando no h interveno do usurio, os objetivos so inferidos, e os
eventos so planejados de forma contnua. Quando os usurios intervm na histria, eles
interagem de acordo com os eventos que esto sendo dramatizados. O Simulation
Controller guarda retratos dos estados de cada simulao aps cada ciclo, de forma
que a simulao possa ser retomada a partir de um ponto anterior, possivelmente com
outras alternativas de desencadeamento da trama, se isso for solicitado pelo usurio. A
coerncia lgica de uma interveno requisitada sempre checada antes de ser
incorporada, e descartada se inconsistente. Quando uma interveno incorporada, a
simulao tem que descartar ciclos de simulao que tenham sido previamente
planejados e que no tenham levado a interveno em conta. Para estar preparado para
as intervenes, o sistema cria outras instncias do IPG, simulando a incorporao
dessas intervenes a serem sugeridas como opes aos usurios. As intervenes s so
sugeridas se a instncia do IPG confirmar sua consistncia. Se aceitas, os prximos
eventos j tero sido planejados e haver pouco risco de interrupo no fluxo da
narrao.
O tempo gasto para a simulao constantemente monitorado pelo Simulation
Controller. Quando h risco de interrupo na dramatizao devido falta de eventos j
55

planejados, uma mensagem pode ser enviada ao Drama Manager, de forma que polticas
para estender a dramatizao dos eventos correspondentes possam ser aplicadas. Se, em
uma dada circunstncia, um captulo for requisitado e ainda no tiver sido escrito, o
Drama Manager, no cliente, pode dar um tratamento adequado para tentar evitar a
interrupo do fluxo. Como possvel que, eventualmente, mais de um tipo de cliente
seja implementado (por exemplo um para TV digital, outro para celular e outro para
acesso via Internet), cada cliente poder tratar atrasos de diferentes formas.
No modelo proposto, o Drama Manager, em princpio, executado no cliente.
Isso faz com que o trfego de dados corresponda essencialmente carga do contexto e
s comunicaes entre o cliente e o servidor, evitando-se a transmisso de vdeo.
razovel, porm, admitir que, em um contexto de TV digital, os set-top boxes no
tenham capacidade computacional para cuidar da dramatizao. Nesse caso, como
arquitetura alternativa, o Drama Manager poderia ser deslocado para o servidor,
transmitindo-se o vdeo resultante da dramatizao para os clientes. Tal soluo parece
ser vivel para o caso de compartilhamento das histrias por um nmero muito grande
de usurios, no qual o vdeo poderia ser transmitido em broadcast. No caso de histrias
individualizadas ou compartilhadas por pequenos grupos, os servidores teriam que
produzir grande quantidade de vdeos diferentes em paralelo e transmiti-los para os
respectivos clientes. Essa transmisso de vdeo on demand na TV digital, por exemplo,
pode se tornar invivel, devido s limitaes da largura de banda.
5.3 Interao Contnua
Com o objetivo de dar suporte a storytelling interativo em ambientes que
demandam alta responsividade, como na TV digital, o novo modelo do Logtell prov
um modo contnuo de interao, no qual a histria gerada em tempo real conforme o
usurio a assiste e interage com ela. Nesse modo de interao, os passos de simulao
(combinados a intervenes do usurio) passam a ser captulos gerados e apresentados
continuamente.
Para funcionar bem nesse ambiente, sem atrapalhar a experincia de se assistir
dramatizao, a interao no pode exigir muita ateno do usurio e os mtodos de
interao no modo contnuo precisam levar isso em conta. A interao no modo passo-apasso foi mantida para se possibilitar tambm a criao e anlise dos enredos de forma
cuidadosa. No entanto, para fins de entretenimento, o uso do modo passo-a-passo tende
a ser a exceo.
56

O Simulation Controller tem um papel importante na implementao de novas

formas de interao no modo contnuo. Uma das suas tarefas mais importantes criar os
meios para a interao enquanto a gerao dos enredos feita e a sua dramatizao
ocorre no lado do cliente. Tambm no modo contnuo, as interaes podem ser tanto
fracas quanto fortes.

Figura 5.2: Interao Contnua

A Figura 5.2 demonstra a interface de interao no modo contnuo. Eventos e
situaes, descritos em linguagem natural, so sugeridos atravs de uma lista
continuamente atualizada e sensvel ao contexto que est sendo dramatizado. Sugestes
podem ser escolhidas pelo usurio para que o Logtell tente inseri-las no prximo
captulo. Os captulos tambm so listados e h uma janela onde os eventos do captulo
selecionado aparecem de forma resumida. Os comandos Rewind e Another permitem o
retorno do processo de gerao (e de dramatizao) ao captulo selecionado, diferindo
apenas na forma como o processo retomado, conforme descrito a seguir.
5.3.1 Intervenes Fracas: Rewind e Another
Interaes Fracas no modo contnuo basicamente circundam o fluxo normal da
histria, como em geral se obtm com o uso dos comandos Continue e Another do modo
passo-a-passo. O Simulation Controller direciona o fluxo da histria escolhendo,
automaticamente e de forma aleatria, alternativas de captulos e a prpria ordenao
total dos eventos a serem dramatizados em cada captulo (sendo essa ltima compatvel
57

com a ordem parcial definida pelo IPG). Dessa forma, o usurio pode assistir histria
sem ter que interferir. Alm disso, em execues diferentes, mesmo que mantida a
configurao inicial, podem-se obter histrias diferentes.
No modo passo-a-passo, ao fim de uma fase de simulao, o usurio pode
examinar os eventos ainda no incorporados. Pode tambm solicitar a dramatizao
repetidas vezes a partir de um certo ponto. No modo contnuo, como a histria
apresentada sem interrupes, preciso disponibilizar mecanismos para que o usurio
possa voltar a pontos anteriores da histria, seja para rev-los (comando Rewind), seja
para solicitar a gerao de alternativas diferentes, como seria feito com o comando
Another no modo passo-a-passo (que gera verso diferente do captulo). Para esse
objetivo, diferentes retratos do processo de simulao ao fim de cada captulo so
guardados pelo Simulation Controller. De forma diferente do que ocorria na primeira
verso do Logtell, pode-se agora retornar a um captulo anterior para modific-lo,
mesmo que ele j tenha sido dramatizado. D-se ao usurio ento a possibilidade de
mudar o passado da histria e verificar os resultados dessa mudana.
5.3.2 Intervenes Fortes
As Intervenes Fortes, como no modo passo-a-passo, correspondem tanto
insero de eventos especficos no enredo quanto a diretivas de que certas situaes
devem ocorrer. Como o usurio est assistindo histria em paralelo, a descrio dos
eventos ou situaes atravs da digitao de texto ou com o auxlio de menus, como no
modo passo-a-passo, demanda mais ateno do que o tolervel para quem precisa
prestar ateno histria.
Para permitir intervenes fortes no modo contnuo, o Simulation Controller
gera automaticamente sugestes de eventos e situaes a serem inseridas na histria se o
usurio assim desejar. Essas sugestes devem, na medida do possvel, ser coerentes e
levar a desencadeamentos diferentes do enredo. Para garantir a coerncia, o IPG pode
ser acionado previamente, sugerindo-se ento apenas o que j se sabe que pode ser
incorporado ao enredo. Para obter sugestes coerentes com o captulo que est sendo
visualizado, alguns mtodo foram pensados.
O primeiro mtodo para obter uma sugesto seria usando uma biblioteca de
planos tpicos, organizados como uma hierarquia de eventos bsicos e complexos.
Planos tpicos geralmente consistem de certas combinaes de eventos onde os vrios
personagens perseguem seus objetivos, mas tambm podem corresponder aos motivos
58

(AARNE 1964) que so estruturas recorrentes compiladas atravs de estudos crticos

sobre o gnero. O IPG contm um algoritmo para o reconhecimento de planos, baseado
em um algoritmo especificado por Kautz (KAUTZ 1991). O procedimento capaz de
descobrir que alguns eventos so compatveis com um motivo para o qual se tem um
plano tpico, deixando ento que o Simulation Controller sugira a incluso de eventos
adicionais contidos nesse plano.
O segundo mtodo seria atravs da anlise das regras de inferncia de objetivos
em conjunto com a situao atual da narrativa. Atravs da anlise, possvel detectar
fatos a serem sugeridos que, uma vez que se configurem, podem levar ativao de
regras que provocam novos desencadeamentos para a histria nos prximos captulos.
A terceira maneira imaginada para a gerao de sugestes para a histria, seria
atravs das regras de inferncia de sugestes, que, de forma semelhante s regras de
inferncias de objetivos, fazem uma anlise do estado do mundo atual e fornecem
sugestes de eventos ou sugestes de situaes a serem inseridas no prximo captulo.
Este mtodo foi o nico a ter sido implementado no prottipo, apresentado adiante.
5.4 Interao com Mltiplos Usurios
Tendo em mente o aspecto massivo da televiso interativa, proveitoso analisar
modos de permitir que mais de um usurio possa ter influncia na evoluo de uma
histria compartilhada. Em histrias compartilhadas, comandos como Rewind e Another
tendem a no fazer muito sentido. A interao fica concentrada, portanto, nas
intervenes fortes.
Para coordenar intervenes fortes de vrios usurios, mecanismos de votao
precisam ser implementados, de modo que as mais votadas sejam inseridas. preciso
tambm coordenar a apresentao simultnea da histria nos diversos clientes, a
atualizao das listas de sugesto e o tempo para a recepo das escolhas dos usurios.
No novo modelo, o Interface Controller organiza a interao entre usurios e
interage com o Simulation Controller como se houvesse apenas um usurio. Como
regra, todas as sugestes devem ser enviadas pelo Interface Controller ao Simulation
Controller quando alcanam um nvel mnimo de aceitao configurado.
Apesar de o novo modelo prever inicialmente apenas os mecanismos de votao,
outros mecanismos de interao com mltiplos usurios que compartilham a mesma
histria compensam ser analisados. Usurios poderiam, por exemplo, ser divididos em
grupos com possibilidades de interveno diferentes. Alternativamente, poderiam
59

tambm assumir o controle de personagens, mas isso implicaria em gerar enredos mais
flexveis, dando maior liberdade para a dramatizao. De todo modo, o novo modelo
cria uma plataforma til para experimentos de interao entre mltiplos usurios.
5.5 Estratgias para Manuteno do Fluxo
Para que o novo modelo seja bem sucedido, uma das principais questes que,
no modo contnuo, se evite a interrupo do fluxo de apresentao mesmo quando
intervenes fortes ocorrem.
Para evitar a interrupo, a gerao dos enredos precisa estar sempre frente da
dramatizao. Com recursos computacionais de sobra, vrios captulos frente
poderiam ser gerados no servidor enquanto o captulo corrente apresentado. Se
alternativas que prevem intervenes fortes forem geradas em paralelo, diminui-se
consideravelmente o risco de interrupo. No entanto, como os recursos dos servidores
no so infinitos, um certo equilbrio precisa ser achado. Uma alternativa bsica ter
sempre um captulo frente gerado e tentar incorporar sugestes apenas se der tempo.
Caso no haja, o captulo sem incorporar as sugestes usado.
A eficincia do processo de simulao tambm pode ser melhorada. Uma das
idias para alcanar performance maior no planejamento o uso de hierarchical task
networks (HTNs) (EROL et al. 1994; NAU et al. 2003). Esses algoritmos tendem a ser
mais eficientes pois reduzem o espao de busca, mas ao preo de restringir as solues a
padres previamente estabelecidos. No entanto, deseja-se manter a flexibilidade na
gerao dos enredos. O uso de um planejador hbrido que d preferncia a solues
compatveis com uma hierarquia de tarefas, mas que tambm possibilite a busca de
solues fora de padres previamente pensados, pode levar a melhoria considervel na
performance.
Adicionalmente, algumas pesquisas recentes com planejadores neoclssicos, que
fazem buscas no espao de estados, mostram que bons resultados em termos de
eficincia tambm podem ser obtidos, como, por exemplo, no planejamento baseado em
grafos (BLUM AND FURST 1997; GEVERINI & SERINA 2002). O uso de heursticas
e estratgias de controle (DOHERTY 2001; HOFFMAN 2001) tambm so
promissores. A incorporao dessas tcnicas tambm merece ser levada em
considerao.
Por fim, interessante a incorporao ao novo modelo de estratgias para
controle do tempo de dramatizao dos eventos. Em (DORIA et al., 2008) apresentada
60

uma proposta de flexibilizao da dramatizao no Logtell, dando variedade tanto s

formas de dramatizar cada evento quanto ao seu tempo de durao. Atravs de
comandos para acelerar ou encurtar o evento corrente, possvel atrasar a dramatizao
de um captulo at que se tenha o prximo captulo disponvel.
5.6 Mecanismos Avanados de Interao
Alm dos modos de interao bsicos previamente citados, outros mecanismos
podero vir a ser incorporados:
Uso de conceitos abstratos A biblioteca de planos tpicos com que o IPG
trabalha admite dois tipos de relacionamentos entre eventos. Eventos podem ser
parte de outros eventos ou especializaes de eventos mais abstratos. O usurio
poderia, por exemplo, indicar que a princesa, que faz o papel de vtima no
contexto corrente, deve sofrer uma vilania, mas deixar a escolha do tipo de
vilania a cargo do processo de simulao. De forma anloga, se uma hierarquia
de predicados definida, o usurio pode estabelecer que a princesa deva estar
em perigo em certo momento mas sem especificar como. Um nvel adequado de
abstrao encorajaria o usurio a intervir na histria sem ter que se preocupar
com detalhes.
Controle das tenses narrativas Escalas numricas referindo-se a nveis de
violncia, romance, assim como velocidade da narrativa poderiam ser
manipulados pelo usurio enquanto assiste dramatizao. Essas configuraes
ajudariam a guiar o processo de simulao e a inferncia de novos objetivos
durante o processo de simulao. Isso requer, no entanto, um investimento maior
na hora de se modelar o gnero (POLTI 1945).
Sugestes em Linguagem Natural interessante que o usurio possa
comunicar-se com o sistema atravs de frases num subconjunto restrito da
linguagem natural. Depois de decodificadas, essas ordens seriam tratadas como
as outras formas de interao j existentes, ou seja, seriam validadas de modo a
verificar logicamente sua consistncia. Num modelo multiusurio, sugestes
expressas em linguagem natural podem ser mais facilmente entendidas e
discutidas entre os usurios.
61

5.7 Concluses
Neste capitulo, foi apresentado um novo modelo para storytelling interativo em
ambiente de TV interativa. O modelo procura conciliar o foco na coerncia com novos
mecanismos capazes de prover a responsividade demandada por esse ambiente.
O modelo apresentado levou em considerao uma srie de requisitos que
incluem, alm da diversidade e coerncia dos enredos, o fluxo contnuo na apresentao
das histrias, a facilidade e comodidade na interao, intervenes dos usurios nas
histrias em diversos nveis e o compartilhamento de histrias entre mltiplos usurios.
Optou-se por utilizar e modificar o modelo do Logtell, por esse j ter foco na
coerncia dos enredos e j possibilitar tanto intervenes fracas quanto fortes por parte
dos usurios. Para permitir que enredos continuassem podendo ser gerados e
examinados com cuidado, decidiu-se manter o modo de interao passo-a-passo. O
foco, no entanto, passou a ser um novo modo contnuo de interao, onde a gerao de
enredos ocorre em paralelo com a dramatizao. Para o modo contnuo, procurou-se
definir mecanismos de interao que dessem o mesmo poder de interveno do modo
passo-a-passo, mas provendo a comodidade necessria.
No novo modelo, uma nova arquitetura cliente-servidor proposta, a qual
contrasta com boa parte das arquiteturas adotadas nas pesquisas de storytelling
interativo, onde o processamento tende a ficar concentrado em uma nica mquina. A
nova arquitetura apresenta uma srie de vantagens funcionais e no funcionais, tais
como uma maior escalabilidade e confiabilidade na disponibilizao dos recursos
computacionais necessrios ao processo de simulao das histrias. Alm disso, permite
a coexistncia de diferentes clientes em diferentes plataformas onde a TV interativa
pode ser veiculada, tais como a TV digital e a telefonia mvel.
No captulo 6 a seguir, descrita a implementao de um prottipo que busca
validar parte das idias do modelo apresentado.

62

6. Implementao
Neste captulo, so abordadas as principais questes relativas implementao
do prottipo para a validao do modelo de storytelling interativo apresentado no
captulo 5.
O prottipo foi feito sobre a implementao atual do Logtell e buscou atender
aos requisitos bsicos do novo modelo proposto, de forma a validar suas principais
idias.
6.1 Ambiente da Aplicao
Para a implementao do prottipo, um dos principais requisitos a necessidade
de um ambiente cliente-servidor que provenha, dentre outras facilidades, um meio onde
existam confiabilidade e escalabilidade. Por isso, a arquitetura implementada faz uso de
um servidor de aplicao.
Na primeira verso do Logtell, o Plot Manager, implementado em Java, faz o
controle dos demais mdulos, como o IPG e o Drama Manager. O IPG, por sua vez,
embora seja implementado em Prolog, acessado atravs de uma biblioteca Java que
faz a interface com o processador de Prolog SICStus. Essa biblioteca utiliza uma DLL
interna do SICStus, no sendo implementada em Java puro. O mesmo ocorre com o
Drama Manager, que, embora se comunique com o Plot Manager via Java,
implementado em C++ atravs de uma DLL e de chamadas nativas.
Pelo fato do controle principal da execuo do Logtell ser implementado em
Java e para se ter uma maior independncia de plataforma, foi escolhido um servidor de
aplicaes Java, o JBoss (MARRS e DAVIS, 2005). O JBoss foi construdo usando uma
srie de ferramentas e bibliotecas de cdigo aberto que j alcanaram um considervel
grau de maturidade e que fornecem a um ambiente corporativo o ncleo necessrio para
sua infra-estrutura. Dentre outras tecnologias, o JBoss d suporte, por exemplo, a JSPs,
Servlets, EJBs, JMS, JNDI, Web Services, JavaMail, JDBC e Hibernate. Ao
disponibilizar servios distribudos e facilidades de segurana, arquitetura para
mensagens assncronas, proxies remotos, acesso a bancos de dados, criao de Web
Services e at servidores HTTP para Web, torna-se facilitada a construo de aplicaes
distribudas entre vrios servidores, as quais podem atender a uma grande quantidade de
clientes simultneos. Tal caracterstica bastante atraente para implementao do
modelo de TV interativa proposto nesta dissertao.
63

Para a implementao, foi escolhida a verso 4.2.3.GA do JBoss. O novo

prottipo do Logtell tem como plataforma Java alvo a verso 6 do JDK da Sun, fazendo
uso de novos recursos da linguagem, como Generics, e usufruindo tambm das
melhorias de performance das ltimas verses da mquina virtual Java.
Uma das grandes vantagens de usar um servidor de aplicaes como o JBoss
que, com a sua arquitetura, pode-se disponibilizar servios de maneira mais
independente da plataforma tecnolgica, atravs do uso de Web Services. Para isso, basta
que sejam feitas pequenas alteraes nos servios que foram codificados. No prottipo
construdo, essas alteraes no foram feitas, porm sua implementao totalmente
compatvel, dado que os servios so disponibilizados atravs de Stateless Session
Beans, ou seja, no guardado um contexto de comunicao com cada cliente que faz
chamadas remotas. Alm disso, os servios foram construdos como EJBs (Enterprise
Java Beans) e seguindo o padro EJB3. Com isso, s necessria a adio de algumas
anotaes (annotations) no cdigo para que um servio do sistema se torne um Web
Service. A possibilidade do uso de Web Services, que um padro de integrao para
sistemas heterogneos, facilitar a extenso futura do sistema de storytelling interativo,
permitindo o seu uso atravs de diversos tipos de clientes diferentes, como PCs,
Televiso Digital, celulares, etc.
Na implementao foi utilizada uma srie de padres de projeto, os quais so
bastante estudados na bibliografia e usados no ambiente de programao J2EE, ou seja,
ambientes Enterprise de aplicaes distribudas feitas em Java. O acesso base de
dados feito por classes que implementam o padro Data Access Object (DAO) (ALUR
et al., 2001), que encapsula todo o acesso ao banco de dados e permite modificar a
maneira de persistir as classes do modelo sem que sejam necessrias modificaes no
cdigo do cliente. importante notar que, por questes de tempo, o prottipo no usa de
fato um banco de dados (os dados so guardados em memria), porm a sua arquitetura
j est preparada para isso, dado que o acesso a banco de dados foi isolado, e poucas
questes referentes ao banco de dados especfico a ser escolhido devem surgir na hora
de sua incorporao nova arquitetura.
importante tambm ressaltar que, na implementao da lgica dos servios
disponibilizados, foi adotada, como orientao geral, a utilizao da arquitetura de
POJOs (Plain Old Java Objects) descrita por (JOHNSON 2004). Os POJOs nada mais
so do que classes Java que buscam uma simplicidade no seu cdigo, sem seguir
padres arquiteturais como o EJB. Neste caso, como recomendado por (JOHNSON
64

2004), eles so utilizados para conter a lgica necessria para controlar o processo de
escrever as histrias. Dessa forma, embora se utilizem EJBs, isto se deve principalmente
por suas questes de arquitetura dos servidores de aplicao, que provm o acesso a
estes servios e as questes funcionais e no funcionais que so fornecidas pela
plataforma J2EE, porm estando a lgica principal dos servios escrita nos POJOs, que
so utilizados dentro da implementao dos EJBs. Desta forma, esta lgica pode ser
facilmente reutilizada em diversos pontos do sistema, no tendo que ser sempre
acessadas atravs do EJB, reduzindo o acoplamento do sistema estrutura usada para
estes servios disponibilizados, ou seja, facilitando alm do reuso potencial da lgica do
sistema, futuras mudanas caso sejam necessrias novas modificaes na arquitetura do
sistema.
Para fazer a integrao com o IPG na nova verso, alguns desafios foram
encontrados. A estrutura da biblioteca Jasper, utilizada pelo Logtell para falar com o
SICstus Prolog, onde o IPG executado, criou dificuldades de alocao de memria e
limitaes no acesso simultneo ao Prolog.
Um dos principais problemas o fato de o Jasper utilizar um espao de memria
baixo (os primeiros 256 de MB do sistema), e falhar na sua inicializao caso outras
aplicaes ocupem este espao de memria antes dele. Infelizmente, ao implementar a
nova arquitetura, com o processo do Jasper dentro do ambiente JBoss, aconteceu
exatamente a situao descrita e no era possvel instanciar a conexo com o Prolog. O
problema pde ser remediado atravs de orientaes descritas no site do fabricante do
SICstus (SICSTUS, 2008), que recomendam o uso da ferramenta Rebase da Microsoft,
em conjunto com a customizao de um arquivo DLL da JVM a ser usada com o JBoss.
Essa alterao no to intrusiva quanto parece, dado que ela apenas cria uma nova
configurao de memria para a mquina virtual Java (semelhante s configuraes para
cliente ou servidor usadas no Java), que pode ento ser usada.
Na implementao do novo prottipo, pretendia-se utilizar uma srie de
instncias do IPG para atender a diversas demandas paralelas, da simulao de uma
mesma histria ou de histrias distintas. Entretanto, utilizando a biblioteca Jasper, no
era possvel instanciar a conexo com o Prolog mais de uma vez numa mesma mquina
e, alm disso, o Jasper exige o acesso ao Prolog atravs de uma nica thread.
Na arquitetura anterior do Logtell, era sempre utilizada uma nica instncia do
processo de conexo com o Prolog, que era mantido sempre aberto, de modo similar ao
uso de um console Prolog que recebe comandos de um usurio. Essa instncia do Prolog
65

recebia as requisies do Plot Manager com consultas Prolog e as atendia. A exigncia

de que o Prolog no seja acessado atravs de mais de uma thread impedia o envio direto
de comandos da interface para o objeto Java que representa a instncia. As chamadas
resultantes do clique de um boto, por exemplo, viriam de uma thread separada, usada
pelo Java para atender aos eventos que vm de componentes visuais de interface. Para
contornar essa limitao, era utilizado um mecanismo onde uma srie de flags eram
constantemente alterados e verificados por uma thread, que, sendo executada em
paralelo com a interface, repassava os comandos necessrios e resultados das consultas
Prolog.
No novo ambiente cliente-servidor, no seria mais possvel manter aberta apenas
uma instncia do Jasper, dado que o suporte a mltiplas requisies exatamente uma
das principais caractersticas do modelo proposto. Como as requisies que chegam ao
servidor de aplicao podem vir de diversos clientes, o IPG pode ter que ser acionado
para tratar diferentes contextos de histrias a cada momento. Surge a a mesma
limitao do modelo de thread nica enfrentada j na implementao da primeira verso
do Logtell: como atender as requisies vindas de diferentes threads e chamadas
remotas?
Para atacar esse problema, a soluo foi utilizar uma estratgia anloga que foi
utilizada na primeira verso do Logtell. Foi utilizado o padro MBean, disponvel pela
arquitetura J2EE e suportado pelo JBoss. Com um MBean, possvel que se tenha uma
instncia de um objeto que nica por cada servidor de aplicao dentro do ambiente
implantado. Dessa forma, foi criado o MBean chamado PlannerMBean, que, de maneira
semelhante arquitetura anterior, fornece o acesso ao IPG atravs de uma thread que
centraliza o acesso instncia Prolog. Alm disso, como s h uma instncia Prolog por
servidor, a cada chamada remota onde necessrio o uso do IPG, deve-se primeiro
restaurar o snapshot que armazena o contexto da simulao referente chamada. Os
snapshots do contexto de cada histria ao fim de cada fase de simulao so guardados
e recuperados quando necessrio.
Embora, por um lado, possa parecer uma limitao grande o fato de apenas uma
instncia de acesso ao IPG poder existir por servidor de aplicao, deve-se considerar
que, na nova arquitetura criada, diversos servidores de aplicao podem ser ligados em
um cluster com o JBoss. Dessa forma, diversas instncias do IPG podem ser usadas em
paralelo para atender s necessidades dos clientes conectados ao sistema. No prottipo,
isso ainda no foi feito, e, antes que isso acontea, deve-se primeiro integrar um banco
66

de dados verdadeiro, substituindo a implementao de persistncia dos snapshots

atravs dos DAOs. Isso necessrio porque no ser suficiente manter os dados
somente em memria, pois o contexto de simulao de uma histria gerado em um
servidor de aplicao pode ter que vir a ser estendido em outro servidor.
importante ressaltar que algumas das limitaes apresentadas podem
eventualmente ser eliminadas utilizando novos mtodos de acesso disponibilizados na
verso mais atual do SICstus. No entanto, mudanas no cdigo de acesso e no IPG
seriam necessrias. Como h planos de migrao do IPG para o SWI Prolog, o esforo
necessrio para essas mudanas no se justificava. No novo ambiente, os mtodos de
acesso devero ser adaptados tendo em vista o aumento da performance. Como forma de
dar suporte a melhorias futuras no acesso a outras implementaes do IPG, o
PlannerMBean acessa o IPG atravs da classe PlannerFacade que foi criada no novo
prottipo, abstraindo de uma maneira mais modular, o acesso ao Prolog. Assim, a
integrao com o Prolog atravs do SICstus poder ser facilmente substituda no futuro,
sem fazer muitas mudanas estruturais na arquitetura implementada.

Figura 6.1: Beans J2EE do prottipo

A Figura 6.1 apresenta os mdulos implementados no servidor sob a forma de
beans. As sees a seguir detalham a forma como esses beans trabalham em conjunto
com o cdigo executado nos clientes.
6.2 Simulation Controller
O Simulation Controller tem a responsabilidade principal de controlar a gerao
67

das histrias. Para isso, foi criado como um Stateless Session Bean, chamado
SimulationControllerBean, cujos mtodos principais so apresentados na Figura 6.2.

Figura 6.2: Mtodos principais implementados no SimulationControllerBean

O Simulation Controller capaz de fornecer aos clientes uma srie de funes, a
saber: o acesso aos contextos de histrias, a criao de novas histrias; a continuidade
de uma simulao com novas fases de simulao; o fornecimento de novas alternativas
para uma fase de simulao (atravs do comando Another); consultas sobre as histrias
em execuo; consultas sobre as histrias multiusurio agendadas; e o fornecimento de
listas de sugestes de inseres de eventos e situaes para interao forte em modo
contnuo.
Como se pode observar, o bean criado busca atender s demandas de gerao e
simulao das narrativas, dando suporte tanto ao modo de gerao de histria passo-apasso, que j existia, quanto ao novo modo contnuo multiusurio ou no. Entretanto,
este bean remoto, em vez de concentrar toda a lgica em um nico bloco monoltico de
cdigo, implementado, como j foi descrito na seo 6.1, atravs de POJOs,
facilitando o reuso e modularizao da lgica dos servios criados.
A

lgica

de

controle

da

criao

de

histrias

contida

no

SimulationControllerBean se divide em alguns submdulos: servios gerais para

manipular a histria ficam a cargo do StoryManagerService enquanto que a gerao do
enredo da histria controlada por subclasses da classe AbstractStoryWriter.
Atravs do uso de chamadas remotas ao SimulationControllerBean, pode-se
requisitar a criao e gerao iterativa das histrias. O modo de gerao passo-a-passo
funciona dessa maneira. Sempre que um novo ciclo de simulao requisitado, o
68

servio restaura o snapshot anterior e ento requisita um novo ciclo de simulao.

A principal diferena entre o modo passo-a-passo e o modo contnuo, no que se
refere gerao das histrias, ocorre principalmente nas subclasses da classe abstrata
AbstractStoryWriter. O cdigo que, na verso anterior do Logtell, manipulava o IPG, e
que antes fazia parte do PlotManager foi completamente refatorado e distribudo.
As principais funes que eram utilizadas para solicitar ao Prolog consultas e
que resultavam em novos eventos e suas dependncias, agora se concentram na classe
PlannerFacade, que invocada pelo PlannerMBean, j descrito antes. O cdigo que
manipula essas chamadas no modo contnuo, porm, agora deve sempre ser capaz de
organizar os ciclos de gerao das narrativas em captulos, onde a ordem total dos
eventos estabelecida automaticamente. Para suportar esse processo de gerao da
narrativa, existem duas subclasses: o ContinuousStoryWriter e o StepByStepStoryWriter.
O StoryManagerService um grande POJO que concentra a lgica para a
manipulao das histrias, dos snapshots da mesma e de seus captulos. Essa classe
manipula os DAOs necessrios para acessar e armazenar os dados desejados,
encapsulando dessa forma esse cdigo e ajudando a abstrair essas questes de forma
modular.
O StepByStepStoryWriter encarregado basicamente de acionar o IPG,
funcionando de forma similar verso anterior do Logtell. Alm do acionamento do
IPG, contm mtodo para ordenar os eventos usando uma ordenao topolgica. Essa
ordenao feita no modo passo-a-passo apenas para facilitar a interao do usurio,
no acrescentando restries de ordem entre os eventos (ou seja, o usurio no modo
passo-a-passo ainda deve determinar a ordem total dos eventos, fazendo a ligao entre
eles na interface).
No modo contnuo, utiliza-se estratgia completamente diferente. H uma
instncia do ContinuousStoryWriter para cada histria apresentada. Existe um processo,
denominado SimulationControllerMessageDrivenBean, que executado continuamente
no servidor, o qual responsvel por iniciar instncias do ContinuousStoryWriter para
cada histria contnua com que se est trabalhando. O ContinuousStoryWriter, atua
como um roteirista ao vivo. Para isso, manipula um StepByStepStoryWriter, mantendo
seu prprio controle sobre a histria que vai sendo gerada. O ContinuousStoryWriter
implementa a estratgia do modelo: deve sempre estar frente do que contedo a que o
usurio assiste. Por isso, ao iniciar a histria, o primeiro captulo da histria logo
escrito, mesmo antes de o usurio pedir o incio da sua dramatizao, aproveitando-se o
69

tempo de inicializao do ambiente grfico. Quando, no modo contnuo, um captulo

requisitado pelo cliente, verificado, no lado servidor, se esse captulo da histria o
ltimo disponvel. Nesse caso, para evitar futura interrupo no fluxo, o
SimulationControllerBean

envia

uma

mensagem

assncrona

(JMS)

para

ContinuousStoryWriter responsvel pela histria, de modo que novo captulo seja

gerado.
O gerador de narrativas contnuas tambm responsvel por repassar as novas
formas de interao com base em sugestes ao IPG. Sugestes inseridas pelo usurio s
so incorporadas se o IPG verificar que elas so coerentes. Alm disso, a incorporao
das sugestes s ocorre se o captulo a ser modificado j no est sendo assistido por
algum cliente. Esse controle feito tanto no modo contnuo em modo de nico usurio
quanto com as histrias compartilhadas.
O processo de gerao de histrias multiusurio muito semelhante ao das
histrias contnuas com um nico usurio. As principais diferenas esto no seu
processo de incio e nas interaes. No modo multiusurio, quando um usurio faz uma
interao forte (isto , quando insere uma sugesto), esta na verdade apenas um voto.
A sugesto somente ser escolhida para a histria, se for a mais votada (em caso de
empate, uma das mais votadas escolhida randomicamente). No prottipo, apenas uma
sugesto pode ser dada por captulo, por interao.
H uma questo que, no futuro, poder ser melhorada e que relativa
contagem de votos e ao critrio para a utilizao das sugestes dos usurios. Na
implementao atual do modo multiusurio, ao ser requisitado o ltimo captulo escrito
de uma histria, o seguinte escrito pelo gerador, da mesma forma que no modo
contnuo de nico usurio. Porm, no que se refere ao uso das sugestes inseridas no
modo multiusurio, h um threshold configurado no cdigo que define o quanto o
processo aguarda at que faa a contagem das sugestes inseridas pelos usurios
enquanto que no modo contnuo de nico usurio, as sugestes sero incorporadas (se
possvel) em qualquer momento que o usurio desejar (salvo a exceo do caso aonde
algum j requisitou o captulo futuro sendo modificado, aonde neste caso se descarta o
captulo modificado).
Outra diferena que tambm h no modo contnuo compartilhado, que, nele, as
histrias so agendadas pelos usurios, e ento outros usurios podem selecionar as
mesmas e aguardar o seu incio. Alm disso, os novos modos de interao fraca, atravs
dos comandos Rewind e Another do modo contnuo no esto habilitados.
70

Na Figura 6.3, a seguir, pode-se ver, em um diagrama de classes simplificado, a

relao entre os diversos componentes do Simulation Controller e suas dependncias.

71

Figura 6.3: Submdulos do Simulation Controller.

6.3 User Interface

Na implementao do prottipo, o cdigo da interface com o usurio teve que
ser reescrito. O que antes era parte do Plot Manager, agora se divide em diferentes
classes.

Figura 6.4: Interface Inicial do Logtell

Na nova interface do Logtell, agora existem mltiplas opes de uso, dada a
natureza ambivalente do modelo e do prottipo. Agora no s possvel ao usurio o
uso do modo passo-a-passo, mas tambm o modo contnuo, seja ele na modalidade de
usurio nico ou multiusurio. A Figura 6.4: apresenta a interface inicial atravs da qual
o usurio escolhe a opo de utilizao do sistema.
Outra diferena do novo prottipo que, agora, tambm possvel escolher o
gnero das histrias a serem geradas. As informaes do gnero esto contidas em
arquivo com o contexto inicial a ser utilizado. No futuro, dever ser feita a juno do
Logtell com o CCM, o mdulo citado no captulo 4, que gerencia os contextos
modelados em objetos. Nesse caso, o contexto, em vez de ser carregado de um arquivo,
ser recuperado do banco de dados do sistema. A Figura 6.5 mostra a janela de escolha
do gnero de histria, que na verdade so os contextos disponveis.

72

Figura 6.5: Escolha de Contexto

A classe principal do Plot Manager anteriormente era a classe Plot, que ainda
existe na nova implementao, porm ela contm agora apenas as pores de cdigo que
so comuns a todos os modos de interao e foi transformada em uma classe abstrata.

Figura 6.6: Novas classes para a interface com o usurio

73

Como se pode ver na Figura 6.6, a classe Prog, que era o ncleo do Plot
Manager,

agora

estendida

pelas

classes

ContinuousPlotManager

StepByStepPlotManager. Seu cdigo foi refatorado, reorganizado e em alguns trechos,

reescrito, de forma a permitir essa nova arquitetura.
O StepByStepPlotManager implementa a interface passo-a-passo do Logtell, da
mesma forma que a verso anterior do sistema, porm com a principal diferena de que,
nessa nova implementao, ele no conversa diretamente com o IPG agora o cdigo
faz chamadas remotas ao SimulationControllerBean, que executado nos servidores de
aplicao. O cdigo do modo passo-a-passo utiliza somente este bean e tem como
diferena com o modo contnuo, componentes grficos para ordenar os eventos, alm de
opes para a insero manual de eventos e situaes, alm dos botes para pedir novos
ciclos de simulao, ou alternativas, como j demonstrado no captulo 4. H apenas uma
pequena diferena visual, dado que foi aplicado um estilo de interface mais semelhante
ao do Windows. Foi adicionada a opo Reset, dentro das opes, para que o usurio
possa reiniciar sua histria facilmente. A Figura 6.7 apresenta a interface no modo
passo-a-passo (mantendo tambm os comandos para fazer perguntas sobre o estado da
histria, um boto auxiliar pra ordenar os eventos, alm dos controles que
aceleram/param a visualizao da histria).

Figura 6.7: Interface do modo passo-a-passo.

O ContinousPlotManager implementa o novo modo contnuo, tanto para o modo
multiusurio

quando

para

de

usurio

nico.

Alm

de

utilizar

SimulationControllerBean para solicitar os prximos captulos a serem exibidos, ele

tambm utiliza o Interface Controller, descrito na seo 6.4.
74

Figura 6.8: Interface do modo contnuo

A estratgia do modo contnuo difere bastante da estratgia do modo passo-apasso. Em vez de se gerar trechos da histria quando o usurio pede explicitamente, o
incio da histria solicitado automaticamente e, sempre que o motor grfico 3D
solicita novos captulos para serem dramatizados, essa solicitao repassada ao
servidor. Dessa forma, o usurio est sempre assistindo histria que se desenrola, e
pode interagir com a mesma, se assim o desejar.
A interao com o Drama Manager tambm difere um pouco, j que, em vez de
se enviar uma seqncia total de eventos para serem dramatizados, os eventos so
enviados aos poucos. Ao se iniciar a histria, o primeiro captulo requisitado ao
servidor que fornece o contedo desse captulo. De posse do contedo do captulo, o
ContinuousPlotManager envia para o Drama Manager o primeiro evento a ser
dramatizado. Conforme cada evento acaba, o prximo evento requisitado pelo Drama
Manager. Nesse momento, o ContinuousPlotManager busca, na sua cpia do captulo
atual, o prximo evento. Caso o captulo tenha terminado, feita uma chamada remota
para receber o prximo captulo do servidor, o qual j dever estar pronto.
Atualmente, as cenas dramatizveis pelo mdulo 3D so simples e no demoram
muito tempo. Por outro lado, os ciclos de gerao, ao usarem a inferncia de objetivos
combinada com planejamento automtico, podem demandar um tempo razovel, que
depende da complexidade do contexto. Alm disso, dependendo da carga a que o
servidor esteja atendendo ou por problemas na rede, sempre possvel que existam
atrasos da gerao do enredo em relao sua dramatizao. Por isso, o modelo prev o
75

uso de mecanismos para estender a dramatizao de eventos correntes ou usar fillers,

como, por exemplo, comerciais. No prottipo, esse mecanismo ainda no est
implementado. Optou-se por simplesmente repetir requisies um certo nmero de
vezes, desistindo-se da apresentao da histria se o novo captulo no for fornecido.
6.4 Interface Controller
Para lidar com os novos mecanismos de interao no modo contnuo propostos
no captulo 5, agora existe o Interface Controller. A Figura 6.9 mostra os seus mtodos.

Figura 6.9: InterfaceControllerBean

As responsabilidades do Interface Controller incluem receber e tratar os
comandos enviados pelos clientes no modo contnuo, incluindo os comandos Rewind e
Another, e as solicitaes de incluso de sugestes enviadas pelos usurios. O comando
Rewind, conforme descrito anteriormente, faz com que gerao da histria retroceda at
um captulo anterior j recebido no cliente. A execuo do comando Another tambm
faz um retrocesso, mas fornece, se possvel, uma verso alternativa para o captulo
indicado. Alm de tratar esses comandos, o Interface Controller tambm tem a
responsabilidade de buscar para o cliente a lista das sugestes de intervenes fortes a
serem disponibilizadas a cada momento.
Quando o usurio faz uma sugesto, o InterfaceControllerBean publica uma
mensagem com essa sugesto, que ser interceptada pelo processo que cuida da gerao
da narrativa com que se deseja interagir.
Para descobrir a lista de sugestes disponveis, o InterfaceControllerBean faz
uma chamada ao SimulationControllerBean, que ento consulta o estado atual da
histria no captulo que est sendo apresentado. Usando as estratgias disponveis,
descritas no captulo 5, gerada uma lista de sugestes de interferncias a serem
disponibilizadas para o(s) usurio(s).
Os novos mecanismos de interao fraca do modo contnuo, correspondentes aos
comandos Rewind e Another, tambm funcionam de maneira similar insero de
76

sugestes. Uma mensagem enviada para o processo da histria em questo, para que o
ContinuousStoryWriter prepare-se para reescrever os captulos futuros, conforme
necessrio, e s ento o captulo desejado retornado. A execuo de um comando
Rewind praticamente instantnea, pois demanda apenas o tempo de recuperar o
snapshot do captulo para o qual se deseja voltar no banco de dados. No caso do
comando Another de se esperar que exista algum atraso, dado que necessria uma
consulta ao IPG para obter a alternativa ao captulo que havia sido apresentado. Deve-se
ressaltar que tanto em um caso quanto em outro, a gerao do enredo trazida para um
ponto anterior e, dependendo de novas interaes, histrias completamente diferentes
podem ser obtidas.
6.5. Concluses
Neste captulo foi apresentada uma viso geral do prottipo que foi
implementado com base modelo apresentado no captulo 5. Essa implementao serviu
para demonstrar a aplicabilidade de parte das idias propostas.
No novo prottipo, uma srie de melhorias foram feitas na prpria estrutura e
organizao do Logtell. O cdigo, no que tange ao controle da dramatizao, foi
praticamente todo refatorado de modo a atender aos requisitos do novo modelo. Alm
disso, o ambiente de storytelling interativo funciona agora em uma arquitetura clienteservidor, utilizando frameworks que so usados e aceitos no mercado, com forte grau de
maturidade tecnolgica. Uma das principais qualidades do prottipo exatamente a
conformidade com essas estratgias que so atualmente utilizadas em aplicaes
comerciais e empresariais.
O uso de um ambiente Enterprise, implementado em um servidor de aplicao
como o JBoss, facilitou a adequao do sistema de storytelling interativo a novos
requisitos funcionais e no funcionais. Dentre os requisitos funcionais que puderam ser
mais facilmente implementados, podem ser destacados a criao de histrias em
ambiente cliente-servidor e a possibilidade de interoperabilidade com diferentes
clientes. Ao se implementar o sistema em uma plataforma onde podem ser conectados
diferentes servidores, tornou-se bem mais fcil atender ao importante requisito no
funcional de escalabilidade.
No foi feita ainda a integrao com um banco de dados para armazenar os
snapshots das histrias. Os snapshots, por enquanto, so guardados em memria
principal, mas o armazenamento em banco de dados poder ser facilmente realizado,
77

dado que o cdigo foi escrito de forma organizada, usando padres como DAOs. Esses
padres isolam o acesso aos snapshots das demais partes do sistema, sendo necessrias
poucas mudanas no cdigo para alterar a forma de armazenamento.
Os mecanismos de criao de sugestes para os usurios, por enquanto, esto
limitados a regras de inferncia de sugestes a serem oferecidas aos usurios. Esse
mecanismo depende bastante de um esforo autoral. Para gerar sugestes com menor
esforo, outros mecanismos, tambm propostos no captulo 5, os quais so baseados no
reconhecimento de planos tpicos e na anlise de regras de inferncia de objetivos
podero ser bastante teis.
Os mecanismos de votao e insero das sugestes tambm podem ser
aperfeioados. Aceita-se, por enquanto, uma nica sugesto por captulo. A conciliao
de duas intervenes fortes em um mesmo captulo poder levar a resultados
interessantes, mas o mecanismo de controle precisar balancear a complexidade das
interaes permitidas com a demanda de manuteno de um fluxo contnuo na
apresentao.
Existem ainda aperfeioamentos a serem feitos na forma como os clientes tratam
atrasos dos servidores no fornecimento de novos captulos. Procurou-se desenvolver
mecanismos para evitar os atrasos, mas, dependendo da demanda, eles podem ser
inevitveis. Nesse caso, a incorporao ao prottipo de mecanismos de alongamento do
captulo corrente ou de insero de fillers tornam-se necessrios.
Outras melhorias futuras incluem a incorporao dos mecanismos avanados de
interao previstos no captulo 5. Tais mecanismos incluem o uso de linguagem natural
e de conceitos abstratos para a insero de sugestes nas histrias e a manipulao, por
parte dos usurios, de escalas numricas correspondentes a tenses narrativas que
influenciam a evoluo das histrias.
Apesar da existncia de aperfeioamentos a serem feitos, procurou-se atender, na
verso atual do prottipo, aos requisitos bsicos do modelo proposto no captulo 5, de
modo a permitir a sua validao. No captulo 7, apresentada a aplicao do prottipo
em um contexto exemplo com a anlise dos resultados obtidos.

78

7. Aplicao do Prottipo
Para fins de avaliao do modelo proposto no captulo 5, optou-se por utilizar o
prottipo descrito no captulo 6 com o mesmo contexto exemplo do gnero Espadas e
Drages, descrito no captulo 4, o qual serviu de base para a validao da primeira
verso do Logtell. Como o objetivo principal do trabalho propor um modelo vivel de
storytelling interativo para o ambiente de TV interativa e no a obteno de um produto
pronto para uso com entretenimento, o contexto exemplo foi modificado apenas nos
pontos necessrios para testar o atendimento aos requisitos do modelo.
No captulo 4, pode-se encontrar a descrio do contexto exemplo, com os
predicados que descrevem os personagens, lugares e as relaes entre eles nas histrias,
as operaes que especificam os eventos que podem ocorrer e tambm as regras de
inferncia de objetivos.
Para os testes apresentados neste captulo, foi definida uma configurao inicial
a partir da qual as histrias so desenvolvidas. Nessa configurao Brian e Hoel so
cavaleiros, enquanto Marian uma Princesa, Turjan um Feiticeiro e Draco um Drago.
Brian, Hoel e Marian so de natureza boa, enquanto que Turjan neutro e Draco mau.
Todos estes personagens esto vivos no comeo da histria. Brian e Hoel so mais
fracos do que o Drago, Marian mais fraca ainda, e Turjan to forte quanto Draco.
Brian e Hoel tm forte afeto por Marian, mas esta no retribui. Alm disso, cada um dos
personagens tem um papel, informao que utilizada na gerao das histrias: Brian e
Hoel so heris, Draco um vilo, Marian uma vtima e Turjan um doador. O
doador um papel especial que, neste gnero, algum capaz de doar poder ou ento de
enfeitiar este outro personagem, trocando sua natureza.
Alm dos personagens e seus papis e relaes, tambm so definidas
localidades. Cada localidade pode ser de natureza boa, m ou neutra e pode estar
protegida ou desprotegida. Locais protegidos contm guardas que protegem personagens
que so da mesma natureza do local. Existem 5 localidades: os castelos Branco (White
Palace), Cinza (Gray Palace) e Vermelho (Red Palace), alm da Floresta Verde (Green
Forest) e da Igreja (Church). O Castelo Cinza de natureza boa e desprotegido. Alm
disso, a residncia de Brian e Hoel. O Castelo Branco a residncia de Marian. um
local de natureza boa e est fortemente protegido. Turjan vive na Floresta Verde, que
neutra como ele e tem um certo nvel de proteo. Draco vive em sua fortaleza, o
Castelo Vermelho, tambm com certo nvel de proteo. Finalmente, a Igreja um local
79

de natureza boa, mas que est desprotegido. O nvel de proteo de um local uma
informao fundamental na hora da construo da histria, dado que um personagem s
poder, por exemplo, seqestrar outro personagem ou lutar com ele, se esse outro
personagem estiver em um local suficientemente desprotegido.
As operaes que especificam os eventos possveis e as regras de inferncia de
objetivos esto listadas nas tabelas do captulo 4.
Para fazer os testes, foi utilizado um servidor Athlon 64 3000+ (2 Ghz) com 1.5
GB de RAM e Windows XP SP3. De forma ideal, mais testes deveriam ter sido
realizados com mais clientes e um servidor, mas os testes aqui relatados foram feitos
utilizando apenas o computador citado. Para os testes das sees 7.1 a 7.3, foi utilizada
somente esta mquina como principal ambiente de testes, e servidor e cliente eram
executados em conjunto. Mesmo assim, foram feitos outros testes no monitorados com
o ambiente em rede com outros computadores mais potentes e o sistema tambm
funcionou, usando uma mquina cliente e outra como servidor.
Nas sees seguintes, so descritos testes realizados e resultados obtidos que
visaram avaliar a adequao do modelo e do prottipo aos principais requisitos para a
utilizao de storytelling interativo em um ambiente de TV interativa.
7.1 Continuidade do Fluxo
Um dos principais requisitos do modelo proposto a capacidade de se manter
uma continuidade do fluxo da histria, sempre que possvel. Isto , deve ser possvel
assistir histria conforme ela est sendo gerada, evitando-se, tanto quanto possvel, as
interrupes.
Foi feita, inicialmente, a verificao de interrupes quando a histria gerada e
dramatizada sem interferncia do usurio. Nesse caso, verificou-se que no houve
nenhuma interrupo perceptvel. Captulos eram gerados e apresentados no modo
contnuo sem que se ocorressem interrupes perceptveis entre um captulo e outro. Os
tempos de gerao de um novo captulo e de seu envio aos clientes mostraram-se
compatveis com o tempo de dramatizao do captulo corrente. Em situaes onde
pode haver problemas na rede, isso poderia no ser verdade, dado que problemas na
velocidade da conexo poderiam influenciar o resultado final e a performance do
sistema. Nos testes realizados em ambiente de rede local, isso no ocorreu. Por outro
lado, apesar de os testes terem sido feitos em ambiente local, verificou-se que, mesmo
com o servidor de aplicaes sendo executado no mesmo computador do cliente, o que
80

poderia provocar uma sobrecarga, no ocorreram interrupes. A Tabela 7.1 lista os

tempos medidos para a recepo dos captulos em uma utilizao do sistema sem
interferncia do usurio. Pelo fato de os intervalos serem mnimos, demonstrou-se que a
continuidade no foi comprometida nesse caso mais simples.

Captulo

Descrio dos eventos

Tempo at cliente
receber o captulo
(em milissegundos)

Marian dismisses guards from the White Palace. Brian

goes to the Green Forest. Turjan gives strength to
Brian.

156

Draco goes to the White Palace. Draco attacks the

White Palace. Draco kidnaps Marian.

31

Brian goes to the Red Castle. Brian attacks the Red

Castle. Draco fights against Brian. Brian kills Draco.
Brian frees Marian.

47

Brian goes to the Church. Marian goes to the Church.

Brian and Marian get married.
Tabela 7.1: Exemplo de narrativa sem interferncias.

94

Para evitar problemas quando ocorrem falhas de comunicao, ainda h espao

para otimizar a estratgia de recuperao dos captulos futuros. Atualmente, um novo
captulo a ser exibido s recuperado quando o ltimo evento do captulo atual acaba de
ser apresentado. Como uma possvel estratgia, a solicitao de um novo captulo ao
servidor poderia ser antecipada, ocorrendo antes da apresentao de alguns eventos do
captulo corrente. Consegue-se, dessa forma, reduzir o impacto que uma conexo de
rede mais lenta poderia ter no processo. Entretanto, importante ressaltar que, no modo
contnuo, as informaes correspondentes aos captulos so estruturas bem simples. Em
condies normais, o simples envio desses dados para os clientes no deve causar
atrasos. A questo principal seria ento apenas a compatibilizao entre o tempo de
gerao de um novo captulo no servidor enquanto o captulo anterior apresentado no
cliente. No caso da gerao de histrias sem interferncia, verificou-se que o processo
funciona sem maiores problemas.
Foram realizados testes com o uso das novas formas de interao fraca, que
foram implementadas no novo modo contnuo. Com o comando Rewind, que tem a
funo de voltar o processo de gerao at o momento em que um certo captulo
passado foi gerado, o comportamento esperado do sistema de pouca demora, dado que
81

os captulos anteriores e seus respectivos retratos (snapshots) da histria j esto

gravados.

Captulo sendo
dramatizado

Captulo requisitado pelo

Rewind

Tempo em milissegundos
at captulo chegar na
interface (em
milissegundos)

235

360

2
Tabela 7.2: Alguns tempos para o Rewind

266

Como a tabela 7.2 demonstra, os resultados so compatveis com o esperado: o

tempo que demora aps um comando de Rewind desprezvel, no ambiente em que foi
testado. Como descrito antes, ao fazer um Rewind, o sistema apenas recupera as
informaes do retrato da histria no passado e as envia para o cliente, levando um
tempo desprezvel a mais porque interrompe a dramatizao brevemente. importante
ressaltar que, no prottipo atual, alm de fazer isso, os captulo seguintes que j haviam
sido gerados e possivelmente dramatizados so descartados, pois, com interaes dos
usurios em pontos anteriores a eles, eles se tornariam inconsistentes. Uma otimizao
possvel seria mant-los enquanto no ocorresse alguma interao que os invalidasse.
Os resultados obtidos com o uso da funcionalidade de Rewind mostram que o
tempo para o retorno a um captulo anterior compatvel com o tempo para retorno a
um captulo anterior em um DVD (em torno de 1 segundo), podendo ser at menor,
dependendo do aparelho.

Captulo sendo
dramatizado

Captulo requisitado pelo

Another

Tempo em milissegundos
at captulo chegar na
interface (em
milissegundos)

5219

5250

2
Tabela 7.3: Alguns tempos para o Another

5203

A execuo de um comando Another bem semelhante execuo de um

82

comando Rewind, com a diferena de que, alm de se solicitar a volta do processo de

gerao a um ponto anterior da histria, pede-se que seja fornecida uma verso
alternativa do captulo selecionado. Como essa operao envolve, alm da recuperao
de um snapshot, a solicitao de uma alternativa do captulo ao IPG, razovel que esta
operao no seja instantnea. Como a tabela 7.3 demonstra, a operao demora algum
tempo, porm ainda muito pequeno (na maioria dos captulos gerados), dado que, para o
IPG o custo de pedir uma nova alternativa menor do que o tempo normal de inferncia
e planejamento de objetivos numa fase de simulao de um novo captulo.
De um modo geral, verificou-se que, em condies ideais, obteve-se resultado
plenamente satisfatrio no que tange continuidade do fluxo quando ocorrem
intervenes fracas. Por condies ideais entenda-se a situao onde as requisies
decorrentes de comandos Rewind e Another so atendidas por servidores que no esto
sobrecarregados. Como j explicado antes no captulo 6, devido a limitaes no
prottipo atual, apenas uma instncia do IPG pode existir por servidor de aplicao, o
que significa que, se essa instncia estiver ocupada, por exemplo, em escrever o captulo
futuro de uma histria, o tempo necessrio para atender a uma requisio de Another
para outra histria ser logicamente maior. Nesse caso, foram obtidos tempos que
variavam de 15 segundos at 30 segundos, dado que as chamadas ao IPG so
enfileiradas.
Quanto aos casos em que se fazem inseres na histria no modo contnuo, ou
seja, quando se utiliza a funcionalidade de insero de sugestes na histria, no
ambiente ideal descrito antes, no ocorrem atrasos. Isso acontece porque as inseres de
sugestes, dentro do novo mecanismo, ocorrem de forma assncrona para os usurios,
ou seja, o cliente envia uma sugesto e o servidor ento a redistribui para o processo que
est escrevendo a histria. Uma das questes principais no que concerne ao fluxo
contnuo e s inseres de sugestes justamente o tempo que se leva para processar as
mesmas. Nos casos em que a sugesto enviada em um momento muito prximo do
fim da dramatizao de um determinado captulo na interface do cliente, o que ocorre
que o tempo para processar a sugesto pode demorar demais. Alm disso, quanto mais
inapropriada for a sugesto, potencialmente mais tempo se levar para que o IPG tente
utiliz-la. Deve-se ressaltar, por isso, a necessidade futura da implementao de
mecanismos que criem sugestes tanto promissoras para as histrias quanto o possvel.
Quando a insero de uma sugesto feita e o IPG no tem tempo suficiente
para incorpor-la antes que o primeiro cliente solicite o prximo captulo, fornecido
83

um captulo que no a incorpora e a verso que incorpora a sugesto descartada. Isso

ocorre porque no faz sentido modificar um captulo que j est sendo dramatizado em
algum cliente. De fato, como algumas sugestes podem levar um tempo grande para a
gerao do captulo que as incorpora, estratgias precisam ser adotadas de modo a
reduzir o nmero de situaes em que sugestes coerentes so descartadas.
Para se obter melhores resultados em situaes crticas, uma alternativa a
gerao prvia de captulos alternativos, a qual no foi ainda implementada. Quando a
solicitao de alternativas para um captulo fosse feita atravs de um comando Another
ou da insero de sugestes, a alternativa j estaria pronta para ser fornecida ao cliente.
No caso das sugestes, elas poderiam at mesmo ser testadas antes de serem
disponibilizadas aos usurios. Para que isso no criasse um gargalo no sistema, seria
importante ter vrios servidores com cada um deles executando vrias instncias do
IPG. Conforme foi mencionado antes, no captulo 5, o melhoramento do algoritmo de
planejamento e o controle do tempo de durao dos eventos tambm podem ser
determinantes para a obteno de resultados bons em situaes crticas.
7.2 Diversidade e Coerncia das Histrias
Como forma da verificao da diversidade e coerncia das histrias que o
prottipo capaz de gerar, tem-se o seguinte critrio em mente: se o novo modelo for
capaz de incorporar todos os mecanismos de interveno do Logtell original,
subentende-se que capaz ento de herdar a diversidade e coerncia das histrias
geradas.
Na verso anterior, que implementava apenas o modo de interao passo-apasso, o usurio era capaz de influenciar a histria basicamente de 3 maneiras: inserindo
sugestes (apesar de no terem esse nome, as interaes fortes de insero de eventos
e situaes, de certo modo, sempre foram sugestes, dado que o Logtell as rejeita
quando no so coerentes com a histria); pedindo a gerao dos prximos eventos da
histria e pedindo alternativas.
De fato, no modo contnuo que foi implementado, o usurio capaz de alcanar
basicamente as mesmas histrias obtidas no modo passo-a-passo. O mecanismo de
continuar a histria j implcito, dado que, no modo contnuo, a histria est sempre
sendo escrita frente. Quanto s verses alternativas, elas tambm podem ser obtidas de
forma at mais flexvel, dado que, anteriormente, o usurio somente poderia pedir
alternativas para o ltimo trecho da histria que foi criado pelo IPG e, agora,
84

alternativas podem ser pedidas para qualquer captulo anterior. Finalmente, a insero
de eventos e situaes agora ocorre por meio da seleo de sugestes a serem
incorporadas. O nico mecanismo de interao, disponvel para o usurio no modo
passo-a-passo, que no possvel no modo contnuo o estabelecimento da ordem total
dos eventos, dado que essa ordenao ocorre automaticamente. No entanto, esse
mecanismo tende a gerar pouca variedade no resultado final das histrias. Dessa forma,
possvel dizer que, no modo contnuo, obtm-se o mesmo nvel de coerncia do modo
passo-a-passo e, aproximadamente, o mesmo nvel de diversidade.
Contudo, h de se admitir que, no modo passo-a-passo, existe uma liberdade
maior na insero de eventos e sugestes, liberdade essa que foi cerceada no modo
contnuo. Isso foi necessrio porque, em uma interao em modo contnuo, natural que
exista menos tempo para tomar decises a respeito do que se deseja modificar na
histria. Se as sugestes cobrirem as principais possibilidades, tende-se a obter o mesmo
tipo de resultado no modo contnuo e no modo passo-a-passo. Ressalta-se, por isso, a
importncia de se dispor de mecanismos que forneam sugestes potencialmente
interessantes e coerentes. De qualquer maneira, como j foi explicado antes, o modo
passo-a-passo ainda permitido na nova arquitetura, sendo til, em particular, para a
anlise das histrias que so geradas.
Com o uso dos modos de interao fraca disponveis no modo contnuo,
representados pelos comandos Rewind e Another, possvel obter praticamente todos os
enredos gerveis sem intervenes fortes no modo passo-a-passo.
Apenas com o uso do comando Another, foi possvel gerar histrias diferentes.
Abaixo, temos um exemplo de histria gerada, com os seguintes captulos:
1. Draco goes to the White Palace. Draco attacks the White Palace. Brian goes to
the Green Forest. Turjan gives strength to Brian.
2. Draco attacks the White Palace. Draco kidnaps Marian.
3. Brian goes to the Red Castle. Brian attacks the Red Castle. Draco fights against
Brian. Brian kills Draco. Brian frees Marian.
4. Brian goes to the Church. Marian goes to the Church. Brian and Marian get
married.
Nesse exemplo, obtido com aplicao de um comando Another para o primeiro
captulo, nota-se que a histria foi diferente da apresentada na Tabela 7.1. Draco ataca o
85

castelo e reduz sua proteo, enquanto que, na histria original, Marian colaborava
com Draco, dispensando guardas. Outro exemplo, obtido com um Another para o
terceiro captulo o seguinte:
1. Marian dismisses guards from the White Palace. Brian goes to the Green Forest.
Turjan gives strength to Brian.
2. Draco goes to the White Palace. Draco attacks the White Palace. Draco kidnaps
Marian.
3. Brian goes to the Red Castle. Hoel goes to the Red Castle. Hoel attacks the Red
Castle. Draco fights against Brian. Brian kills Draco. Hoel frees Marian.
4. Hoel goes to the Church. Marian goes to the Church. Hoel and Marian get
married.
Como se pode notar, neste exemplo uma histria diferente foi criada, e possui
uma peculiaridade: embora os dois heris tenham atacado o castelo juntos, a princesa
grata a quem a liberta, como definido nas regras do contexto; portanto, embora os dois
tenham mrito, com Hoel que ela se casa, mesmo tendo sido Brian quem matou o
drago Draco.
Tambm com o uso das intervenes fortes, possvel obter praticamente todos
os enredos possveis do contexto exemplo, desde que existam sugestes que explorem
essas alternativas, e os mecanismos do modelo para a gerao destas.
Para os testes com o prottipo, como alternativa inicial para permitir
intervenes fortes, foi feito um esforo autoral que teve como resultado a criao de
uma srie de sugestes, que para o contexto mapeado, costumam ser, mais ou menos
promissoras, dependendo do momento em que so inseridas na histria. Essas regras
foram adicionadas ao contexto inicial das histrias e foram usados para testar o
prottipo.
Foi mapeado um conjunto de regras, cada uma com um momento mais adequado
para serem inseridos nas histrias, que so:

No incio da histria:

go(marian, church).

go(marian,green_forest).

attack(draco,white_palace).

fight(brian,hoel).
86

reduce_protection(marian,white_palace).

Com a vtima frgil:

kidnap(draco,marian).

kill(draco,marian).

Com a vtima raptada:

free(brian, marian).

free(hoel,marian).

kill(hoel,draco).

kill(brian,draco).

Com a vtima morta:

kill(brian,draco).

kill(hoel,draco).

Com a vtima libertada:

marry(brian, marian).

marry(hoel,marian).

kill(brian,hoel).

kill(hoel,brian).

Com o uso das sugestes, foi possvel criar histrias diferentes das que seriam
criadas naturalmente pelo IPG. Dessa forma, podem-se explorar alternativas coerentes
segundo o gnero.
Por exemplo, ao inserir a sugesto Draco kills Marian no primeiro captulo,
obteve-se a seguinte histria:

Marian dismisses guards from the White Palace. Marian goes to the Red Castle.
Brian goes to the Green Forest. Turjan gives strength to Brian. Draco kills
Marian.

Brian goes to the Red Castle. Brian attacks the Red Castle. Draco fights against
Brian. Brian kills Draco.
Nessa histria, como foi inserido o evento do assassinato de uma vtima, a regra

de inferncia da vingana foi ativada, e, portanto, Brian terminou por vingar o

assassinato de Marian. Em outra histria, ao inserir Hoel kills Draco no segundo
87

captulo, obteve-se:

Marian dismisses guards from the White Palace. Brian goes to the Green Forest.
Turjan gives strength to Brian.

Hoel goes to the Red Castle. Hoel attacks the Red Castle. Brian goes to the Red
Castle. Draco goes to the White Palace. Draco attacks the White Palace. Draco
kidnaps Marian. Brian fights against Draco. Hoel kills Draco.

Hoel frees Marian.

Marian goes to the Church. Hoel goes to the Church. Hoel and Marian get
married.
Nessa histria, acontece uma estrutura diferente: os dois heris de fato lutam

contra o drago Draco juntos, mas Hoel quem d o golpe final. Logo aps, ele liberta
Marian, ficando ento mais justa a gratido de Marian por Hoel.
7.3 Facilidade e Comodidade da Utilizao
O ambiente de TV interativa imps ao modelo a necessidade de fornecer
mecanismos fceis e cmodos para a interao, pois o usurio no tem muito tempo
para se concentrar na interao enquanto assiste histria.
A insero de sugestes e a execuo de comandos de Rewind e Another pode
ser solicitada com apenas dois cliques. Uma nica interferncia dessas pode ser
suficiente para a obteno de uma histria completamente diferente. Acredita-se, ento,
que esses mecanismos so condizentes com a possibilidade de interao preguiosa
(lazy interaction) tpica para ambientes de TV interativa. Note-se que a execuo desses
comandos, que hoje ocorre atravs do mouse, poderia ter que ser adaptada quando o
cliente estivesse interagindo atravs do celular ou de sua TV.
Alm dos mecanismos bsicos, o modelo props outros mais avanados e que
no chegaram a ser implementados ainda. O uso de linguagem natural, especialmente se
usado em conjunto com reconhecimento de voz, pode ser bastante til em contexto de
TV digital. O uso de conceitos abstratos em sugestes dramaticamente interessante
pelo fato de permitir sugestes vagas cuja incorporao de uma forma concreta nos
enredos pode surpreender o usurio. Outro mecanismo proposto o controle, por parte
do usurio, de variveis numricas que interfiram na simulao, determinando, por
88

exemplo, nveis de suspense, romance, violncia, etc. Mecanismos como esse podem ser
implementados de forma anloga ao controle de volume e permitem uma forma de
interao indireta que tem bom potencial para surpreender o usurio.
Um fato que demonstra o nvel de facilidade e comodidade da utilizao dos
mecanismos implementados o nmero de interaes necessrio para se obter uma
determinada histria. A primeira histria citada na seo 7.2 foi obtida usando o
comando Another 2 vezes no captulo 1; a segunda foi um pouco mais trabalhosa, mas
mesmo assim fcil de ser feita, usando o comando Another 4 vezes no captulo 3 (o
nico esforo do usurio foi o de ver o captulo gerado, e ento, solicitar outra opo,
sem ter que reiniciar todo o processo); na terceira e na quarta histrias, foram
necessrias somente inseres de sugestes pontuais: na terceira, foi inserido um evento
no captulo 1, e, na quarta, um evento no captulo 2.
Os mecanismos previstos no modelo no esgotam o assunto. Dentro do ambiente
de storytelling interativo, existem muitas outras possibilidades que ainda no foram
exploradas. Mecanismos de realidade aumentada, por exemplo, podem ser
especialmente teis para usurios com dificuldades motoras e para crianas.
7.4 Escalabilidade
O prottipo utiliza o JBoss, que uma plataforma que procura fornecer
escalabilidade e confiabilidade na distribuio de recursos em rede. Entretanto, como foi
explicado, o prottipo ainda no est pronto para trabalhar com vrios servidores
simultaneamente. Para tal, seria preciso usar um banco de dados na implementao dos
DAOs e tambm configurar o ambiente para executar em cluster.
O Logtell j funciona agora em um ambiente J2EE cliente-servidor, s que com
um nico servidor. As mudanas na configurao do sistema e na camada que faz acesso
ao banco de dados (que, por hora, virtualmente implementado em memria) no
afetariam o cdigo do restante do sistema. Dessa forma, possvel afirmar que a base
necessria para se obter escalabilidade j foi criada.
Uma questo pertinente escalabilidade j foi elucidada antes: o fato do acesso
ao IPG ser feito atravs de uma biblioteca que no suporta bem mltiplas instncias na
mesma mquina virtual. Entretanto, isso dever ser resolvido em futuro prximo. Como
o cdigo que faz acesso ao IPG bem encapsulado, o esforo de alterao do
Simulation Controller no ser grande.
Mesmo assim, existe uma verificao que pde ser feita: o uso do modo
89

multiusurio. Utilizando o modo multiusurio, foi possvel assistir a uma histria em

modo contnuo compartilhado. Testes feitos em rede local mostraram que no houve
atrasos no tempo de transmisso dos captulos para os clientes. Isso ocorre porque, na
verdade, em uma histria compartilhada, a gerao feita por um nico processo,
independente do nmero de clientes que a assistem. As nicas diferenas em termos de
carga do servidor ocorrem na comunicao com os clientes. Como a comunicao com
os clientes bem mais leve que a gerao do enredo, no de se estranhar que o custo
de processamento de uma histria contnua multiusurio seja aproximadamente
equivalente ao custo de uma histria contnua para apenas um usurio. A Figura 7.1, a
seguir mostra um teste onde o servidor e dois clientes so executados em uma mesma
mquina e os dois clientes compartilham uma mesma histria. Nesse teste, a mesma
histria dramatizada em duas janelas diferentes, sem interrupo de fluxo e
permitindo, inclusive, a incorporao de intervenes fortes.

Figura 7.1 Modo multiusurio com dois clientes assistindo mesma histria

90

8. Concluses e Trabalhos Futuros

8.1 Consideraes Gerais
Nesta pesquisa, foi apresentado um novo modelo de storytelling interativo, que
busca atender aos requisitos de alta responsividade da TV interativa. O modelo estende
o que foi originalmente definido no sistema Logtell, tendo como principal preocupao
a conciliao entre a coerncia das histrias e a continuidade do fluxo de apresentao.
Outras caractersticas como a diversidade das histrias, a definio de mecanismos de
interao prprios para o meio e a escalabilidade tambm foram considerados.
Apesar de inspiradas pelas demandas de responsividade de ambientes como o da
TV digital, as solues propostas so de natureza interoperveis, e compatveis com
outros ambientes tais como a Web.
Para a validao das idias, foi implementado um novo prottipo do Logtell que
passou a ser executado agora em rede, segundo uma arquitetura cliente-servidor. O
prottipo foi testado com base no mesmo contexto exemplo de histrias usado para
validar a primeira verso do Logtell, correspondente ao gnero Espadas e Drages.
Os resultados obtidos com este trabalho mostram, de forma geral, a viabilidade
da utilizao de storytelling interativo para TV, em um tipo de aplicao onde a
coerncia dos enredos valorizada. A seo 8.2 faz um relato mais detalhado das
principais contribuies. Uma grande quantidade de trabalhos futuros potenciais
podero ser feitos usando como base o modelo proposto e o prottipo implementado. A
seo 8.3 destaca as principais possibilidades.
8.2 Principais Contribuies
Estudo da Conciliao entre Coerncia e Continuidade do Fluxo
Devido s caractersticas do meio, a coerncia e a diversidade das histrias
ganham maior importncia em um ambiente de TV interativa. Para garanti-las,
escolheu-se utilizar a simulao baseada em lgica formal adotada no Logtell. Obtm-se
assim a flexibilidade para a gerao de um conjunto grande de alternativas coerentes.
No entanto, o tempo de simulao pode no ser irrelevante e, na TV, as histrias
precisam ser apresentadas sem interrupo, para no comprometer a responsividade.
Para conciliar esses requisitos, foram definidas estratgias especficas de distribuio do
processamento, de controle do fluxo e de coordenao entre a produo de enredos no
servidor e a sua apresentao nos clientes. Os testes realizados com o prottipo mostram
91

que o modelo viabiliza essa conciliao entre coerncia e responsividade, que foi o
principal foco deste trabalho. Alm disso, o modelo prev estratgias que podero vir a
ser implementadas para garantir essa conciliao em condies mais crticas, tal como a
utilizao paralela de vrias instncias do mdulo gerador de enredos.
Estudo de Mtodos de Interao
Para permitir a apresentao contnua do contedo em paralelo com a interao
com o usurio, foram propostos alguns mtodos bsicos de interao, os quais
incorporam basicamente todas as possibilidades oferecidas pelo Logtell para interao
fraca e forte com as histrias. Os novos mtodos criados para o modo de interao
contnuo, demandam pouco esforo do usurio e, virtualmente, permitem a obteno de
qualquer histria que pode ser obtida no modo passo-a-passo. Alm disso, foram
propostos, no modelo, mtodos mais avanados que possibilitariam interaes ainda
mais cmodas. Foram tambm estudados e implementados os mecanismos para que
usurios pudessem interagir de forma conjunta com uma mesma histria que estejam
compartilhando.
Proposta de Arquitetura
A adoo de uma arquitetura cliente-servidor uma soluo natural dentro de
um ambiente distribudo como a TV interativa. Foi feita uma distribuio de carga de
processamento entre clientes e servidores, na qual o controle do processo e a gerao
dos enredos so executados no servidor e a interface com o usurio e a dramatizao
ficam no cliente. A gerao dos enredos no servidor faz sentido em virtude da maior
demanda de recursos computacionais. Essa soluo permite que o trfego na rede possa
ser bastante reduzido, mas exige que os clientes tenham poder de processamento
suficiente para executar o mdulo de dramatizao.
Uma alternativa com centralizao da dramatizao no servidor e envio de vdeo
em broadcast pode, eventualmente, ser conveniente em virtude de limitaes
computacionais das set-top boxes. No entanto, para isso, algumas modificaes teriam
que ser introduzidas no prottipo.
A adoo de um servidor de aplicao que permite a ligao de vrios servidores
em cluster possibilitar que, no futuro, o prottipo seja adaptado sem muito esforo para
atender a um grande conjunto de clientes, como esperado em um ambiente de TV
interativa. Alm disso, o uso de tcnicas que facilitam a interoperabilidade foi
92

importante para permitir que o sistema de storytelling interativo seja usado em

diferentes ambientes, com transmisso terrestre digital, por IPTV; pela Web, etc.
Base para Pesquisa em Storytelling Interativo
O prottipo, que foi implementado de forma modular, servir como base para
estudar a incorporao de diversos mecanismos atravs do desenvolvimento de novas
verses. Alm disso, com a colocao do sistema em rede, ser muito mais fcil
disponibiliz-lo a um grande conjunto de usurios, que podero test-lo e dar retorno
importante para o direcionamento de pesquisas futuras.
Publicaes
Ao longo da pesquisa, trabalhos submetidos foram aceitos para serem publicados
(CAMANHO et al., 2008; CIARLINI et al., 2008). Desta forma, isto serviu como um
indicativo de que os propsitos da pesquisa so vlidos, dados que foram aceitos pela
comunidade cientfica, inclusive em eventos internacionais.
8.3 Trabalhos Futuros
Aperfeioamentos no Prottipo
H um conjunto de aperfeioamentos no prottipo que devero ser feitos para
permitir a implementao completa do modelo de storytelling interativo proposto no
captulo 5.
Atualmente, as sugestes de interao forte so obtidas apenas atravs do uso de
regras de inferncia de sugesto, as quais demandam um esforo autoral considervel. O
modelo prev tambm alternativas mais automticas, como o uso de reconhecimento de
planos associados a estruturas recorrentes nos gneros narrativos (motivos). Em
(KARLSSON et al., 2006) so descritos mecanismos que permitem a incorporao ao
enredo de planos tpicos reconhecidos no modo passo-a-passo do Logtell. A idia bsica
adaptar esses mecanismos para obter as sugestes de interao forte no modo
contnuo. Com esses novos mecanismos, espera-se obter, com mais facilidade, sugestes
que levem a enredos surpreendentes e diversos.
Para permitir a utilizao simultnea do prottipo por um grande nmero de
usurios, algumas modificaes no prottipo sero necessrias. Dentre estas, inclui-se a
integrao com um banco de dados para o armazenamento dos snapshots das histria, de
93

modo que vrios servidores possam trabalhar em paralelo, controlando um mesmo

grupo de histrias. Outra limitao do prottipo atual o fato de que o acesso ao IPG
ainda feito atravs de uma biblioteca que obriga a existncia de apenas uma instncia
da conexo com o Prolog por mquina virtual. Futura verso do sistema dever eliminar
esse problema com mudanas nos mtodos de acesso e, eventualmente, do ambiente
Prolog usado pelo IPG.
Com a possibilidade de trabalho de servidores em cluster e com vrias instncias
do IPG por servidor, ser possvel obter melhores resultados em situaes crticas onde
o servidor nico de instncia nica fica sobrecarregado.
Novas Implementaes e Extenses do Modelo de Storytelling Interativo
Existem outras pesquisas em andamento que visam a extenso do Logtell e que
podem ser integradas com o novo modelo proposto neste trabalho.
A pesquisa descrita em (DORIA et al., 2008) uma das mais relacionadas ao
trabalho desta dissertao. Nessa pesquisa, usa-se um modelo no-determinstico para
controlar em alto nvel a dramatizao dos eventos, de modo a obter: durao varivel
dos eventos conforme a convenincia; dramatizao variada, mesmo que o enredo seja o
mesmo; e oportunidades de interao no nvel de dramatizao. O controle do tempo de
durao dos eventos pode ser uma ajuda importante para garantir a continuidade do
fluxo em situaes crticas. Por isso, um dos primeiros trabalhos futuros a serem
realizados a obteno de uma verso do Logtell que seja capaz de combinar os
resultados dos dois trabalhos (CIARLINI et al., 2008).
A necessidade de uso do IPG em tempo real faz com que a sua eficincia seja
crucial para o funcionamento do Logtell. No contexto de exemplo, o IPG consegue, na
maior parte das vezes, gerar captulos em velocidade suficiente para no haver
interrupo de fluxo. No entanto, em contextos mais complexos, h um risco maior de
ocorrncia de interrupes. Para evitar isso, pretende-se investir no desenvolvimento de
uma nova verso do IPG. Essa verso dever incorporar mecanismos de planejamento
onde se mistura o conhecimento do domnio, sob a forma de redes hierrquicas de
tarefas (HTNs), com planejamento independente de domnio. A idia ter um ganho de
eficincia decorrente do uso de HTNs, mas sem perder a flexibilidade atual para a
obteno de solues novas. Alm da preocupao com a eficincia, deseja-se dar mais
flexibilidade para a dramatizao. Seria desejvel que algum nvel de no-determinismo
fosse possvel na gerao dos enredos. Isso permitiria maior variao para a
94

dramatizao e mais opes de interao com o usurio.

Uma questo fundamental para o sucesso de sistemas de storytelling interativo
o desenvolvimento de mecanismos que facilitem o esforo autoral de especificao dos
contextos das histrias, em especial quando se deseja trabalhar com gneros mais
complexos do que contos de fadas. Para o Logtell, um esforo inicial j foi feito com a
implementao de uma verso preliminar do Context Control Module (CCM), que
facilita a especificao, atravs de uma interface grfica, das operaes, personagens,
lugares e regras de inferncia de objetivos de um contexto. Essa verso do CCM
armazena os dados em um banco de dados e capaz de gerar um arquivo de contexto no
formato usado pelo IPG para gerar os enredos. Pretende-se aperfeioar o CCM para
permitir o armazenamento unificado e sem redundncias das informaes referentes
lgica de gerao de enredos, ao controle da dramatizao e animao grfica. Alm
disso, o CCM dever se comunicar diretamente com os outros mdulos do sistema,
facilitar o reaproveitamento de contedo e prover os meios para a especificao rpida e
flexvel dos contextos das histrias.
Novos mecanismos de dramatizao devero ser implementados. Planeja-se
migrar a dramatizao para um motor de jogos customizvel, o que permitir a obteno
de animaes grficas mais realistas. Alm disso, vm sendo estudados tpicos ligados
direo, tais como o posicionamento de cmera e o controle dos atores virtuais nas
cenas.
Alm das pesquisas atualmente em andamento, h diversas possibilidades de
incorporao futura de recursos ao modelo de storytelling interativo do Logtell. O
tratamento de emoes e drives (motivaes) dos personagens tanto no nvel de autoria
dos enredos quanto de dramatizao, o uso de msica, a gerao de textos para dilogos
e a narrao das histrias so possibilidades interessantes.
Por fim, deve-se ressaltar que boa parte das tcnicas aqui citadas no se limita
apenas a entretenimento. Podem ser utilizadas em simulaes em geral, em particular
com propsitos de educao, treinamento e suporte deciso. A interao contnua,
incorporada agora ao sistema, de fundamental importncia para que bons resultados
sejam obtidos tambm com esses propsitos. Em muitos casos, a dramatizao atravs
da animao de atores virtuais pode ser substituda por outras formas de representao
das histrias, tal como a composio automtica de (partes) de vdeos.

95

Referncias Bibliogrficas
AARNE, A., 1964. The Types of the Folktale: A Classification and Bibliography.
Traduzido e editado por Stith Thompson, FF Communications, 184. Helsinki:
Suomalainen Tiedeakatemia.
ALUR D., CRUPI & J., MALKS, D., 2001. Core J2EE Patterns: Best Practices and
Design Strategies. Publisher: Prentice Hall / Sun Microsystems Press.
APPLE,

2009.

"What

is

Apple

TV?"

Disponvel

em

<http://www.apple.com/appletv/whatis.html>. Acesso em Janeiro de 2009.

BLUM, A. L. AND FURST, M. L.,1997. Fast Planning through planning graph analysis.
Artificial Intelligence, v. 90, n. 1-2, pp 281-300.
BECKER, V., VARGAS, R., FILHO, G. H., MONTEZ, C., 2008. Jri Virtual I2TV:
Uma Aplicao para TV Digital Interativa baseada em JavaTV e HyperProp.
Disponvel em <http://www.tvdi.inf.br/index.php?s=artigos>. Acesso em Dezembro de
2008.
CAMANHO, M. M. ; CIARLINI, A. E. M. ; FURTADO, A. L. ; POZZER, C.T. ; FEIJ,
B., 2008. Conciliating Coherence and High Responsiveness in Interactive Storytelling.
In: Proceedings of the 3rd ACM International Conference on Digital Interactive Media
in Entertainment and Arts (DIMEA 2008), Atenas.
CAVAZZA, M., CHARLES, F., MEAD, S., 2002. Character-based interactive
storytelling. IEEE Intelligent Systems, special issue on AI in Interactive Entertainment,
v. 17, n. 4, pp. 17-24.
CHARLES, F.; CAVAZZA, M., MEAD, S., 2001. Character-driven story generation in
interactive storytelling. Relatrio Tcnico, VSMM, Berkeley.
CIARLINI, A. E. M. ; CAMANHO, M. M. ; DORIA, T. R. ; FURTADO, A. L. ;
POZZER, C.T. ; FEIJ, B., 2008. Planning and Interaction Levels for TV Storytelling.
1st. Joint International Conference on Interactive Digital Storytelling, Erfurt, Alemanha,.

96

CIARLINI, A.E.M., POZZER, C. T., FURTADO, A.L., FEIJO, B. A., 2005. LogicBased Tool for Interactive Generation and Dramatization of Stories. In: Proc. ACM
SIGCHI International Conference on Advances in Computer Entertainment Technology
(ACE 2005), Valencia.
CIARLINI, A.; FURTADO, A., 2002. Understanding and Simulating Narratives in the
Context of Information Systems. In: Proc. ER'2002 21st. International Conference on
Conceptual Modelling, Tampere, Finlndia, Out. 2002..
CIARLINI, A.; VELOSO, P. ; FURTADO, A., 2000. A formal framework for modelling
at the behavioural level. In: Proc. of the 10th European-Japanese Conference on
Information Modelling and Knowledge Bases, Saariselk, Finlndia.
CIARLINI, A., 1999. Gerao interativa de enredos. Tese de Doutorado, Departamento
de Informtica, PUC-Rio, Rio de Janeiro.
CPqD, 2005. Poltica Regulatria: Panorama Brasileiro Atual Projeto Sistema
Brasileiro de Televiso Digital: Modelo de Implantao. Verso PD.30.12.36A.0002A/
RT-05-AA. Campinas, CPqD, 2005, (Relatrio Tcnico, Cliente: Funttel, atividade
1236, OS:40539).
CPqD, 2001. Relatrio Integrador dos Aspectos Tcnicos e Mercadolgicos da
Televiso Digital. Anatel. Maro de 2001.
CPqD, 2008. Modelo de Referncia Sistema Brasileiro de Televiso Digital Terrestre.
Verso

PD.30.12.36A.0002A/RT-08-AB.

2006.

Disponvel

em

<http://www.tvdi.inf.br/index.php?s=artigos>. Acesso em Dezembro de 2008.

CRAWFORD, C., 1999. Assumptions underlying the Erasmatron storytelling system. In
Working Notes of the 1999 AAAI Spring Symposium on Narrative Intelligence. AAAI
Press.
CRAWFORD, C., 2005. Chris Crawford on Interactive Storytelling. Indianpoilis,
Estados Unidos: New Riders Games, 2005. 384 p. ISBN 0-321-27890-9
DAVIC, 2008. DAVIC 1.4 Part 2 DAVIC Specification Reference Models and
Scenarios, 1998. Disponvel em <http://www.davic.org>. Acesso em Dezembro de
97

2008.
DOHERTY, P., KVARNSTRM, 2001. J. TALplanner: A temporal logic based planner.
AI Magazine, v. 22, n. 3, pp. 95-102, 2001.
DORIA, T. R. ; CIARLINI, A. E. M. ; ANDREATTA, A., 2008. A Nondeterministic
Model for Controlling the Dramatization of Interactive Stories. In: Proceedings of the
ACM MM2008 - 2nd ACM Workshop on Story Representation, Mechanism and Context
- SRMC08.
DRISCOLL, G., 2000. The essential guide to digital set-top boxes and interactive TV.
Prentice Hall, Upper Saddle River, NJ, 1st edition, Novembro 2000.
EROL, K.; HENDLER, J.; NAU, D. S. UMCP, 1994.: A sound and complete procedure
for hierachical task-network planning. In Proceedings of the International Conference
on AI Planning Systems (AIPS), pp. 249-254.
ETSI, 2003. TS 102 812 V1.2.1: Digital Video Broadcasting (DVB) Multimedia Home
Platform (MHP) Specification 1.1.1. ETSI Standard.
ETSI, 2005. TS 102 819 V1.3.1: Digital Video Broadcasting (DVB) Globally
Executable MHP version 1.0.2 (GEM 1.0.2). ETSI Standard.
FRANZ, M. L. V., 1980. O significado psicolgico dos motivos de redeno nos contos
de fadas. Editora Cultrix, So Paulo.
FURHT, B., 1996. Interactive television systems. In: Proceedings of the 1996 ACM
Symposium on Applied Computing, pp. 7-11, Philadelphia, Pennsylvania, February
1996. ACM Press.
FURTADO, A.; CIARLINI, A., 2000. Generating narratives from plots using schema
information. In: Proceedings of the 5th International Conference on Applications of
Natural Language to Information Systems-Revised Papers, Versalhes, Frana, Junho
2000.
FURTADO, A.; CIARLINI, A., 2001. Constructing Libraries of Typical Plans. In
Proc. CAiSE01, The Thirteenth International Conference on Computer Advanced
Information System Engineering, Interlaken, Sua.
98

GEVERINI, A., SERINA, I., 2002. LPG: A planner based on local search for planning
graphs. In Proceedings of the International Conference on AI Planning Systems (AIPS),
pp. 968-973.
GLASSNER, A., 2004. Interactive Storytelling: Techniques for 21st Century Fiction.
AK Peters Ltd.
GRACIOSA H. M. M. G., 2008. TV Digital no Brasil. Disponvel em
<http://www.teleco.com.br/tutoriais/tutorialtvd2/default.asp>. Acesso em Dezembro de
2008.
GRASBON, D. and BRAUN, N., 2001. A morphological approach to interactive
storytelling. In Proc. CAST01, Living in Mixed Realities. Special issue of
Netzspannung.org/journal, the Magazine for Media Production and Inter-media
Research, pp. 337-340, Sankt Augustin, Germany..
HOFFMAN, J., 2001. FF: The Fast-Forward planning system. AI Magazine, v. 22, n. 3,
pp. 57-62.
HAVi, 2008. HAVi Level 2 Graphical User-Interface -Specification of the Home Audio/
Video

Interoperability

(HAVi)

Architecture.

HAVi,

Inc.

Disponvel

em

<http://www.havi.org>. Acesso em Dezembro de 2008.

IBGE, 2008. IBGE - Pesquisa Nacional por Amostra de Domiclios. Disponvel em
<http://www.ibge.gov.br/home/estatistica/populacao/trabalhoerendimento/pnad2007/tab
sintese.shtm>. Acessado em Dezembro, 2008.
ISO, 1996. ISO/IEC 13818-1 - Information Technology Generic Coding of Moving
Pictures and Associated Audio Information Part 1: Systems (MPEG-2 Systems).
ITU, 2001. ITU Recommendation J.200:2001, Worldwide common core Application
environment for digital interactive television services.
ITU, 2003. ITU Recommendation J.202:2003, Harmonization of procedural content
formats for interactive television applications.
ITU, 2004. ITU Recommendation J.201:2004, Harmonization of declarative content
format for interactive television applications.
99

JOHNSON, R., 2004. Expert One-on-One J2EE Development without EJB. Wiley
Publishing Inc., 2004.
KAUTZ, H. A., 1991. A Formal Theory of Plan Recognition and its Implementation. In:
Allen, J. F. et al (eds.): Reasoning about Plans. Morgan Kaufmann, San Mateo..
KARLSSON, B.; POZZER, C. T.; CIARLINI, A. E. M.; FURTADO, A. L.; FEIJ, B.,
2006. Improving the Scene: Extending LOGTELL to Support a Plan-recognition / Plangeneration Paradigm. In: V Brazilian Symposium on Computer Games and Digital
Entertainment..
MATEAS, M., STERN, A., 2000. Towards integrating plot and character for interactive
drama. In: Working notes of the Socially Intelligent Agents: The Human in the Loop,
AAAI Fall Symposium. Technical report, pp. 113-118, Menlo Park, CA, 2000. AAAI
Press.
MATEAS, M., STERN, A., 2004. A Behavior Language: Joint action and behavioral
idioms. In: Life-like Characters. Tools, Affective Functions and Applications: Springer
Verlag.
MATEAS, M., STERN, A., 2005. Structuring content in the Facade interactive drama
architecture. In Proc. Artificial Intelligence and Interactive Digital Entertainment
Conference (AIIDE 2005).
MARRS, T. and DAVIS, S., 2005. JBoss at Work: A Practical Guide. O'Reilly Media,
Inc.
MCKEE, Robert, 2006. Story: Substncia, Estrutura, Estilo e os princpios da escrita
de roteiro; traduo de Chico Mars. Ed. Arte e Letra, Curitiba, 2006. ISBN: 978-8560499-00-7.
MONTEZ.C, BECKER.V., 2005. TV DIGITAL INTERATIVA; 2 Edio. Florianpolis:
Editora da UFSC.
MSN TV2, 2008. Disponvel em <http://www.webtv.com/pc>. Acesso em Dezembro de
2008.
NAU, D. S., AU, T.-C., ILGHAMI, O., KUTER, U., MURDOCK, W., WU, D.,
100

YAMAN, F., 2003. SHOP2: An HTN planning system. Journal of Artificial Intelligence
Research, 20:379-404.
PAIVA, A., MACHADO, I., PRADA, R., 2001. Heroes, villains, magicians, ... Dramatis
personae in a virtual story creation environment. In Proc. Intelligent User Interfaces.
POLTI, G., 1945. Thirty-Six Dramatic Situations. Whitefish, MT: Kessinger Publishing.
POZZER, C. T., FEIJO, B., CIARLINI, A. et al., 2004. Managing Actions and
Movements of Non-Player Characters in Computer Games. In Proc. of the Brazilian
Symposium on Computer Games and Digital Entertainment.
POZZER, C.T., 2005. Um Sistema para Gerao, Interao e Visualizao
Tridimensional de Histrias para TV Interativa. Tese de Doutorado, Departamento de
Informtica, PUC-Rio.
PRADA R., MACHADO I.,PAIVA A., 2000. TEATRIX: Virtual Environment for Story
Creation. In Lecture Notes in Computer Science. Vol. 1839/2000. pp. 464-473.
PROPP, V., 1968 Morphology of the Folktale, Laurence Scott (trans.), Austin:
University of Texas Press.
RIEDL, M. and YOUNG, R. M., 2004. An intent-driven planner for multi-agent story
generation. In the Proceedings of the 3rd International Conference on Autonomous
Agents and Multi Agent Systems, Julho 2004.
RIEDL, M. and YOUNG, R. M., 2006. "From Linear Story Generation to Branching
Story Graphs". IEEE Computer Graphics and Applications, v. 26, n. 3, pp. 23-31,
May/June 2006, doi:10.1109/MCG.2006.56
RIEDL, M.O., STERN, A., DINI, D., ALDERMAN, J., 2008. Dynamic Experience
Management in Virtual Worlds for Entertainment, Education, and Training.
International Transactions on Systems Science and Applications, Special Issue on Agent
Based Systems for Human Learning, v. 4, n. 2.
RODRIGUES, P. S. L.; FEIJ, B., VELHO, L.; POZZER, C. T.; CIARLINI, A. E. M.;
FURTADO, A. L., 2006. Narrating Stories in Participatory Games. In: V Brazilian
Symposium on Computer Games and Digital Entertainment.
101

MARRIOT; STUCKEY, P., 1998. Programming with Constraints. MIT Press.

MORRIS, S., SMITH-CHAIGNEAU, A., 2005. Interactive TV Standards A Guide to
MHP, OCAP and JavaTV. ISBN-13 978-0-240-80666-2. Elsevier, Focal Press..
SANCRINI, M., 2005. O Uso da Televiso Digital no Contexto Educativo, Educao
Temtica Digital, Campinas, v. 7, n. 1, ISSN 1676-2592, pp. 31-44..
SANTOS, D. T., SILVA, M.R.C, MELONI, L.G.P., 2005. Ferramentas de Apoio ao
Ensino a Distncia via TV Digital Interativa. In: Taller Internacional de Software
Educativo, Santiago-Chile.
SCHWALB, E. M., 2003. iTV Handbook: Technologies and Standards, Prentice Hall
PTR, July 2003.
SGOUROS, N.M., 1999. Dynamic generation, managing and resolution of interactive
plots. Artificial Intelligence, v. 107, n. 1, pp. 29-62.
SI, M., MARSELLA, S.C., RIEDL, M., 2008. Integrating Plot-Centric and CharacterCentric Designs: An Mixed-Initiative Framework for Interactive Drama. Proceedings of
the 4th Conference on Artificial Intelligence and Interactive Digital Entertainment
(AIIDE), Palo Alto, California.
SI, M., MARSELLA, S.C., PYNADATH, D.V., 2005. THESPIAN: An Architecture for
Interactive Pedagogical Drama. In: International Conference on Artificial Intelligence in
Education, Amsterdam.
SICSTUS,

2008.

Rebaseing

JVM

for

SICStus.

Disponvel

em

<http://www.sics.se/~perm/sicstus/rebase_jvm.html>. Acesso em Dezembro de 2008.

SOARES, L. F. G., RODRIGUES, R. F., MORENO, M. F., 2007. Ginga-NCL: the
Declarative Environment of the Brazilian Digital TV System. Journal of the Brazilian
Computer Society, Revista n. 4; v. 12; Mar. 2007 - ISSN 0104-6500.
SOUZA, G. L. F., L. E. C. LEITE, BATISTA, C. E. C. F., 2007. Ginga-J: The Procedural
Middleware for the Brazilian Digital TV System. Journal of the Brazilian Computer
Society. Revista n. 1; v. 13; Mar. 2007 - ISSN 0104-6500
102

SPIERLING, U.; BRAUN, N.; IURGEL, I. ; GRASBON, D., 2002. Setting the scene:
playing digital director in interactive storytelling and creation. Computers & Graphics,
v. 26, n.1, pp. 31-44, 2002.
SUN,

2008a.

Sun

Microsystems,

Java

TV

API,

Disponvel

em

<http://java.sun.com/products/javatv/>. Acesso em Dezembro de 2008.

SUN, 2008b. Sun Microsystems. Java Media Framework API (JMF). Disponvel em
<http://java.sun.com/products/javamedia/jmf/index.jsp>. Acesso em Dezembro de 2008.
SWEDLOW, T. 2000: Interactive Enhanced Television: A Historical and Critical
Perspective. Disponvel em <http://www.itvt.com/etvwhitepaper.html>. Acessado em
Dezembro, 2008.
SZILAS, N., 2008. The mutiny: an interactive drama on IDtension . In: Proceedings of
the 3rd ACM International Conference on Digital Interactive Media in Entertainment
and Arts (DIMEA 2008). New York, NY, USA : ACM, 2008. pp. 539-540.
SZILAS, N., 2003. IDtension: The simulation of Narrative. In Proc. of the 3rd
International Conference on Computational Semiotics for Games and New Media,
Middlesbrough (Royaume-Uni), pp. 10-12.
TANENBAUM, A., 2003. Redes de Computadores. 4a edio. Rio de Janeiro: Editora
Campus.
TOME, T.; PESSOA, A.C.F.; RIOS, J.M.M.; LOURAL, C.A.; DALL'ANTONIA, J.C.,
2001. Relatrio Integrador dos Aspectos Tcnicos e Mercadolgicos da Televiso
Digital. Verso AB PD.33.SV.E5A.0005A/RT-02-AB. Campinas: CPqD, 2001, 84p.
URSU, M. F., THOMAS, M., KEGEL, I., et al., 2008. Interactive TV Narratives:
Opportunities, Progress, and Challenges. In: ACM Transactions on Multimedia
Computing, Communications, and Applications, v. 4, n. 4 (Outubro 2008). ISSN:15516857
YANG, Q., TENENBERG, J. and WOODS, S., 1996. On the Implementation and
Evaluation of Abtweak. In: Computational Intelligence Journal, v. 12, n. 2, Blackwell
Publishers (1996) pp. 295-318.
103

YOUNG, R., 2000. Creating interactive narrative structures: The potential for AI
approaches. In: AAAI Spring Symposium in Artificial Intelligence and Entertainment,
Palo Alto, California, 2000. AAAI Press.
YOUNG, R., 2001. An overview of the mimesis architecture: Integrating narrative
control into a gaming environment. In: Working notes of the AAAI Spring Symposium on
Artificial Intelligence and Interactive Entertainment, pp. 78-81, Stanford, CA, Maro
2001. AAAI Press.
YOUNG, R.M., RIEDL, M.O., BRANLY, M., JHALA, A., MARTIN, R.J., SARETTO,
C.J., 2004. An Architecture for Integrating Plan-Based Behavior Generation with
Interactive Game Environments. Journal of Game Development, v. 1, pp. 51-70. 2004.

104

Apndice A Arquiteturas e Padres Para a TV Digital

Interativa
Transmisso de Dados
Uma das principais mudanas dentro do novo meio digital da iTV o prprio
canal de transmisso, fundamental para a construo da DTV, ou Digital Television. O
modelo de referncia para a DTV na maioria dos sistemas, se faz atravs do uso de
algoritmos de compresso, em especial o MPEG-2 para imagem e MP3 pra udio,
reduzindo o uso da banda enquanto se preserva a qualidade.
O MPEG-2 tem uma srie de particularidades, como o fato de ser um algoritmo
assimtrico, tendo portanto um custo de codificao muito maior que o da
decodificao, algo conveniente para a DTV. Alm disso, um algoritmo flexvel, capaz
de codificar imagens em diversos nveis de qualidade, sendo ainda escalonvel, o que
possibilita arranjos compostos de sinal de udio e vdeo (x vdeos com y udios). Por ser
to adaptvel, ele tambm permite que at mesmo um decodificador de baixa
capacidade de processamento, adapte as informaes de acordo com seu potencial, sem
perder a oportunidade de exibir o contedo recebido. importante ressaltar que o
MPEG-2 apenas uma descrio genrica da forma de codificao e multiplexao dos
sinais, sem impor especificaes concretas na implementao.
importante ressaltar que h uma grande diferena entre o padro DTV e o
conhecido por HDTV High Definition TV. O consumo de banda da HDTV muito
maior, e s possvel atualmente atravs de transmisso digital. Sua resoluo varia em
tamanho, dependendo do padro: 1080x1920 (USA), 1000x1778 (Europa) e 1080x1920
(Japo). Trata-se de resoluo muito maior que a da TV convencional, tambm chamada
de SDTV Standard Definition TV: 484x720 (Padro NTSC, USA) e 575x767 (Padro
PAL, Europa). Existem ainda padres ainda mais impressionantes, devido suas grande
resolues de imagem como o padro japons Ultra High Definition Video (UHDV) da
NHK (Japan Broadcasting Corporation). De todo modo relevante lembrar que quanto
maior a qualidade da imagem e som, maior ser a banda necessria, o que aumenta as
exigncias na infra-estrutura, ainda mais quando se deseja adicionar recursos de
interatividade, por exemplo, na transmisso do sinal.

105

Figura A.1: Representao esquemtica de TV Digital

Para existir interatividade em uma ambiente de TV Digital, como esquematizado
na Figura A.1, no estritamente necessria a aquisio de novos televisores digitais.
At televises analgicas podem ser utilizadas em conjunto com set-top boxes ou
URDs - Unidades Receptoras-decodificadoras que contenham conversores de sinais
digitais para sinais analgicos. Set-top boxes (SCHWALB, 2003) tm a capacidade de
processamento de sinais de vdeo e udio, alm de poderem executar programas. So
capazes de recepo, demodulao, decodificao e remodulao do sinal digital,
gerando sinal de udio e vdeo compatvel com televisores analgicos, alm de dar
suporte s formas de interao denominadas "Pseudo" e "Real".
Na "pseudo" interatividade, o set-top box se comunica com a central de
produes do canal desejado e processa os fluxos de dados multiplexados, sendo capaz
de exibir na televiso uma interface para o usurio, que pode ento interagir com o
programa de TV atravs do controle remoto, ou teclado. A interatividade "real"
viabilizada atravs de uma conexo com um canal de retorno, geralmente por internet ou
no caso de TV a cabo por exemplo, transmitindo pelo prprio meio por onde recebe o
sinal de TV; e possibilita uma maior gama de oportunidades de interao. possvel a
instalao dinmica no set-top box de uma cpia de um sistema de arquivos produzido
no estdio de dados. No set-top box podem ento ser exibidos textos transmitidos e
recebidas aplicaes para serem executadas.
106

Figura A.2: Esquema Geral Simplificado de Padres para TV Digital (adaptado de

GRACIOSA, 2008)
No mundo, existem diferentes padres de transmisso TV digital, como
apresentado na Figura A.2, cada um com vantagens e desvantagens:

Figura A.3: Esquema Simplificado de Padres do ATSC (adaptado de GRACIOSA,

2008)

Americano ATSC (Advanced Television Systems Committee) - o mais antigo,

representado na Figura A.3, comeou a ser utilizado em 1998, e focado na
transmisso de vdeo em alta definio, o HDTV.

Figura A.4: Esquema Simplificado de Padres do DVB (adaptado de GRACIOSA,

2008)

Europeu DVB (Digital Video Broadcasting) - Implantado em 1993,

representado na Figura A.4, tem a possibilidade de multiprogramao,
interatividade e novos servios. Alm disso, tambm privilegia a HDTV, e
107

tambm a recepo mvel e porttil.

Figura A.5: Esquema Simplificado de Padres do ISDB (adaptado de GRACIOSA,

2008)

Japons ISDB (Integrated Service Digital Broadcasting) - Implantado em

1999, representado na Figura A.5, tem como principal vantagem a facilidade e
qualidade na transmisso para variados dispositivos, como TV, celulares, etc,
aliando mobilidade alta definio. Privilegia multiprogramao, interatividade
e novos servios.
Alm disso, existem as possibilidades de transmisso para a TV Digital atravs

de cabo, satlite e por via terrestre. As caractersticas geogrficas do Brasil privilegiam a

transmisso por via terrestre. Por outro lado, a TV por assinatura obedece seus prprios
padres, que j utiliza transmisso digital h alguns anos, muito antes da definio do
sistema de televiso digital brasileiro pelo governo.
A largura da banda disponvel por banda terrestre de 6MHz, o equivalente a
29,162 Mbps. Com o uso de MPEG-2, uma emissora de TV pode transmitir um nico
programa em qualidade de HDTV, ou ento diferentes combinaes, podendo usar a
banda para transmitir 6 canais SDTV simultneos, ou at outras opes (CPqD, 2001).

Figura A.6: Algumas opes de distribuio da largura de banda para TV digital

A Figura A.6 ilustra algumas das opes de modelos de negcio para a utilizao
da banda disponvel. Como se evidencia pela quantidade de diferentes padres, e pelos
exemplos de distribuio de banda na figura, no h ainda consenso no que concerne
108

melhor opo para uso da televiso Digital. Uma opo priorizar uma melhor
resoluo, utilizando a banda toda para o a HDTV. Outra opo simplesmente manter
o padro SD (lembrando que sua qualidade j superior ao sinal analgico recebido por
antenas convencionais) e acrescentar interatividade, o que permitiria integrao com
servios interativos e internet. Pode-se considerar ainda a opo de variar a resoluo da
imagem de acordo com o contedo, aproveitando a flexibilidade do meio. De todo
modo, de se esperar que se reserve sempre uma parte da banda para interatividade, de
acordo com todo o seu potencial. Para dar suporte comunicao entre o espectador e o
contedo que est sendo gerado de forma interativa, sero necessrias linhas de
comunicao rpidas e confiveis, ainda mais num contexto de vdeo sobre demanda.
No Brasil, o sistema de transmisso digital foi definido aps longo processo de
comparao com os outros sistemas existentes (o americano, o japons e o europeu) e j
est em implantao, em carter livre e gratuito. Decidiu-se por um sistema baseado no
modelo japons (ISDB-T: Integrated Services Digital Broadcasting Terrestrial), por
ser mais novo e mais facilmente adaptvel. Dentre as principais facilidades includas
nele, esto:

Modulao COFDM-BST (Coded Orthogonal Frequency Division Multiplexing

- Band Segmented Transmission). O BST divide o canal em treze segmentos e
cada segmento pode levar um contedo/programa diferente. O segmento do
meio, stimo, usado para transmitir para os celulares e equipamentos portteis,
e de forma gratuita.

Possibilidade de transmitir mais de um programa no mesmo canal; por exemplo,

um programa em alta definio e outro para o celular, podendo assim transmitir
o mesmo programa de diferentes formas.

Possibilidade de incorporar novas tecnologias tal como o uso de MPEG4 no

lugar do MPEG2, usado pelos outros sistemas.

Possibilidade do uso de middleware para prover interatividade o Ginga,

criao nacional desenvolvida pela academia, atravs da PUC-RIO e da
Universidade Federal da Paraba.

Possibilidade de criar, no mesmo municpio, uma rede de transmissores na

mesma freqncia para cobrir reas de sombra - onde a imagem no pode ser
vista - e permitir que toda a populao possa ver os programas de todas as
emissoras.
109

O sistema final definido para Brasil foi o ISDB-TB (ISDB-T do Brasil), tambm
denominado SBTVD (Sistema Brasileiro de Televiso Digital) (CPqD, 2006). Ele
incorporou atualizaes ao modelo japons nas partes de udio, vdeo e interatividade e
traz uma srie de vantagens para a realidade brasileira, como, por exemplo, a reduo no
pagamento de royalties e o preo do set-top box mais acessvel, o que possibilita uma
maior incluso digital. Ao utilizar set-top boxes para a converso do sinal digital para
analgico, o parque instalado aproveitado, permitindo uma implantao gradual, que
leve em conta as diferentes condies scio-econmicas do Brasil. Com o uso do settop box ligado internet, possvel ainda utilizar a televiso como um browser
(contudo, ainda que normalmente mais limitado que o de um PC).
Alguns projetos tm servido como modelo para a TV Digital. O Projeto I2TV
(Infra-estrutura Internet2 para Desenvolvimento e Teste de Programas e Ferramentas
para TV Interativa), desenvolvido no Brasil (BECKER et al., 2008) por um conjunto de
entidades que integram universidades (UFSC, USP, PUC-Rio, UFPB e UFRN) e
emissoras de TV de seus estados, usou a internet para a transmisso de contedo digital.
Nesse projeto, foram estudadas e analisadas camadas de hardware, de middleware, de
exibio e de gerao de contedo, sob um uma abordagem que busca integrar
broadcast de TV Digital com a Internet. Esse projeto serviu para demonstrar a
possibilidade da criao de prottipos funcionais para o ambiente desejado.
Middleware
Para implementar aplicativos para televiso digital existem duas abordagens
principais: o uso de aplicaes declarativas ou de aplicaes procedurais. Define-se por
aplicao declarativa aquela cujo contedo projetado de forma declarativa, enquanto
que, nas aplicaes procedurais, seu contedo projetado de maneira procedural. Esta
diferena de padres define a prpria filosofia e utilidade para cada aplicao feita.
Ao projetar um contedo declarativo, deve-se ento utilizar uma linguagem
declarativa, ou seja, uma linguagem que se baseie em modelos lgicos declarativos, em
vez de algoritmos seqenciais, mais comuns maioria das linguagens de programao.
Por outro lado, quando um contedo procedural, deve-se usar uma linguagem no
declarativa. Podem ser adotadas diferentes abordagens ao se utilizar linguagens no
declarativas, incluindo entre elas a programao orientada a objetos, o desenvolvimento
baseado em componentes, e outros padres de implementao e projeto. Porm, na
bibliografia comum sobre televiso digital, o termo procedural usado para
110

representar todas as linguagens no declarativas. Na programao procedural, utiliza-se

uma abordagem baseada em chamadas a procedimentos, tambm conhecidos como
funes, mtodos etc., que so utilizados em algoritmos seqenciais estruturados, o que
d, de certa forma, um controle maior sobre o comportamento do cdigo, e sobre o
controle fluxo de execuo dos programas. Dentre as linguagens procedurais, incluemse a maioria, como C, C++, Java, etc., sendo que, usualmente, a linguagem procedural
mais utilizada na rea, dada a popularidade e grande quantidade de projetos e iniciativas
da Sun Microsystems, tais como a JavaTV (SUN, 2008), o Java.
No Brasil, atravs de uma pesquisa conjunta de diversas instituies foi criado o
middleware Ginga (Figura A.7), para a implementao de aplicativos interativos para a
TV Digital. Em concordncia e com a filosofia do Java, o Ginga busca o
desenvolvimento independente da plataforma de hardware dos diferentes set-top boxes.
O Ginga aplicvel aos receptores para sistemas de transmisso terrestre, e busca
cumprir completamente uma srie de especificaes para serem usadas em aparelhos de
TV Digital integrados, computadores multimdia e clusters locais de aparelhos em redes
domsticas (HAN). O ncleo do Ginga, a Ginga-Core (Figura A.8) composta por
diversos decodificadores de contedos comuns, como imagens JPG, PNG, etc. e
procedimentos para obter contedos transportados em canais (Streams) de transporte do
MPEG-2 e atravs do canal de retorno.

Figura A.7: Arquitetura do Ginga, compatvel com (ITU, 2001).

111

Figura A.8: Componentes da Ginga Common Core.

O padro Ginga compatvel com vrias definies internacionais ITU (ITU
2001, 2003, 2004), e suporta tanto aplicativos declarativos quanto procedurais.
possvel ainda a criao de aplicativos em que as duas formas de contedo existem
simultaneamente e uma referencia a outra.
O Ginga-NCL (SOARES et al., 2007) a poro declarativa do Ginga. Ele prov
uma estrutura para a apresentao de aplicaes declarativas escritas na linguagem
NCL. Atravs de um decodificador, tambm conhecido como NCL formatter, o
contedo pode ser processado. Outros mdulos importantes do Ginga-NCL incluem o
agente de usurio, baseado em XHTML, que inclui folhas de estilo (CSS) e um
interpretador ECMAScript, alm da engine LUA, capaz de interpretar scripts LUA,
muito utilizados em jogos e outros produtos interativos. Alm disso, possvel o uso de
outros padres declarativos atravs de implementaes diferentes baseadas em XHTML.
O aspecto procedural do Ginga implementado atravs do Ginga-J (SOUZA et
al., 2007), o qual inclui diferentes APIs baseadas em padres JavaTV. O Ginga-J
projetado para ser capaz de suprir as funcionalidades necessrias para a criao de
aplicaes para a TV Digital, com funcionalidades para protocolos de acesso, interao,
manipulao de objetos multimdia, etc. O Ginga-J utiliza aplicativos procedurais,
tambm conhecidos como Xlets Java. Como toda implementao Java, utiliza uma
maquina virtual Java (JVM), que estabelece uma camada de abstrao sobre o sistema
operacional subjacente, o que facilita a compatibilidade e portabilidade das diferentes
implementaes em diferentes hardwares, dado que se siga corretamente a sua
especificao. Uma aplicao Ginga-J deve-se basear nas definies GEM 1.1 (ETSI,
2005) (Globally Executable MHP), que so especificaes unificadas para a criao de
niddlewares para TV Digital. Uma aplicao compatvel com este padro ser, em
princpio, compatvel com o Ginga-J.
112

Figura A.9: Arquitetura do Ginga-J

O Ginga se baseia em 3 conjuntos de APIs chamadas Green, Yellow e Blue. As
APIs Green so compatveis com as especificaes GEM. As APIs Yellow so extenses
feitas para alcanar requisitos especficos do sistema brasileiro, e que podem ser
implementadas atravs de um software adaptador usando as APIs Green. As APIs Blue
so as que no so compatveis com as API GEM, ou seja, s podem ser executadas nos
ambientes middleware Ginga.
A API Green do Ginga-J composta pelas APIs Sun JavaTV (SUN, 2008a),
DAVIC (DAVIC, 2008), HAVi (HAVI, 2008) e DVB (MORRIS, 2005; ETSI, 2003),
todas includas na especificao do framework GEM. As APIs Yellow do Ginga-J so
compostas pela API JMF 2.1 (SUN, 2008b), que necessria para o desenvolvimento de
aplicaes avanadas, com captura de som por exemplo, e outras funcionalidades
ligadas ao processamento multimdia. Trata-se de uma extenso API de apresentao
do GEM, com funcionalidades para suporte de stream de vdeo no padro Ginga-J, uma
extenso API do canal de retorno presente no GEM, que permite o envio de
mensagens assncronas, e uma extenso API de Service Information do padro B.23 do
ISDB ARIB. O conjunto de APIs Blue do Ginga-J contm uma API de integrao de
dispositivos, que permite a comunicao do receptor de TV Digital com qualquer
dispositivo de entrada ou sada que use uma interface compatvel (como Bluetooth,
infra-vermelho, rede Ethernet, etc.). Contm tambm uma API multiusurio que usa a
API de integrao de dispositivos para permitir que vrios usurios possam interagir
simultaneamente com aplicativos de televiso digital. Alm disso, contm uma API para
fazer uma ponte com o NCL, para a criao de aplicativos Java que contenham
aplicativos NCL.
113