Existem muitos programas de script e muitas ocasiões para escrever seu próprio script. Mas, como todas as ferramentas de trabalho, o software de cenário se adapta aos requisitos da área de assunto. Por esse motivo, um programa de script de filme não é adequado para escrever um script para um jogo de computador e vice-versa. Minha área é ainda mais específica - desenvolvi o programa NIMS (um conjunto de ferramentas para o enredo principal) para criar scripts para jogos de RPG de ação ao vivo (doravante RI).
Perguntas Blitz:
É usado? Sim, o projeto já tem dois anos. Durante esse período, o NIMS fez mais de 20 jogos.
É pago? Grátis - donationware.
Neste post, falarei sobre os tipos de tarefas de cenário, as especificidades de escrever scripts para a República da Inguchétia, que o NIMS pode fazer e os recursos de sua implementação.
A figura mostra uma rede social baseada nas parcelas do RI “Port Arthur”, MG S&M (clicável).
Isenção de responsabilidade 1: os role-playing games de tabuleiro são um tipo independente de jogo e eu os referirei como NRI.
Classificação de tarefas de script
Por muitos séculos, o roteiro como fenômeno pertenceu exclusivamente à cena. No final do século XIX, o cinema apareceu e no final do século XX - vários jogos (computador, tabuleiro, ação ao vivo etc.) e em todos os lugares existem cenários. Do ponto de vista artístico, eles são semelhantes e obedecem às leis uniformes da escrita de roteiro. Mas, do ponto de vista da forma de apresentação das informações, cada área de aplicação de scripts apresenta suas próprias tarefas. Vamos tentar descobrir.
As tarefas de script podem ser divididas pela presença / ausência de interatividade com o visualizador / usuário. Cinema, programas de TV, livros e teatro exigem um cenário não interativo . Consequentemente, o espectador não pode influenciar o curso da história e, no final, existe apenas um cenário. Por outro lado, existem cenários interativos que envolvem a influência do visualizador. Estes são cenários de vários jogos.
Os scripts interativos podem ser divididos em fechados e abertos. Cenários fechados requerem uma descrição de todas as opções possíveis para o desenvolvimento da história. Por exemplo, scripts para jogos de computador e role-playing books-games.
Os cenários interativos abertos , por sua vez, podem ser divididos condicionalmente de acordo com o grau de dependência principal. Nos jogos de RPG de tabuleiro, como D&D , todas as ações dos jogadores são comunicadas ao mestre e ele narra. Esses jogos são completamente dependentes do mestre e o jogador não pode dar um único passo sem um mestre.
Na República da Inguchétia, um grande número de jogadores interage dentro das regras e acordos estabelecidos antes do jogo. Os mestres não precisam seguir todas as etapas, mas sua competência geralmente permanece a resolução de problemas controversos e a correção de erros de regras durante o jogo. Eu enfatizo mais uma vez que os jogadores interagem entre si de forma autônoma , sem a intervenção de um mago.
Isenção de responsabilidade 2: o dogma descrito aqui não é uma opção típica; os NRIs são autônomos, os RIs são autodependentes e ainda existe uma gama completa de opções intermediárias.
Cenários em role-playing games de ação ao vivo
O desenvolvimento do RI tem certos requisitos. No processo de desenvolvimento, um modelo do mundo é criado, habitado por personagens, e os conflitos são registrados. Muitas vezes, para um jogo, você precisa criar dezenas de personagens ativos e dezenas de histórias abertas com métodos de resolução.
Antes do jogo, o jogador recebe uma descrição introdutória da posição de seu personagem: antecedentes, parentes, amigos, inimigos, propriedades, conflitos, posições de facção em questões-chave, etc. Resumindo, na introdução, você pode colocar qualquer informação que "possa ser reproduzida".
E mais um aviso: o descrito aqui também não é um dogma. Existem jogos sem qualquer abertura, ou alguns dos jogadores têm abertura, mas outros não. O jogador pode ver sua introdução diretamente ao jogo e pode participar de seu desenvolvimento alguns meses antes do jogo, indicando o que ele quer jogar com e com quem.
Uma parte significativa dos relatos introdutórios da pré-história, projetados para responder às perguntas “Por que ...?”: “Por que odeio o rei?”, “Por que nossas casas estão em guerra?”, “Por que é importante para nós que o ritual corra bem?”
Cada jogador deve receber sua parte da informação e operá-la no jogo. O flagelo de escrever uma introdução é inconsistências. Qualquer evento da história é recontado repetidamente e com sotaques diferentes, porque cada participante vê a situação à sua maneira. Não apenas cada fato deve ser descrito em várias versões, mas também no caso de alterações, todas essas alterações devem ser duplicadas em cada uma das opções. Por exemplo, se em um determinado episódio 5 personagens estiveram envolvidos, no caso da menor alteração nesse episódio, você precisará fazer 5 edições, e não uma. Essa situação leva a um grande número de inconsistências.
O projeto NIMS foi desenvolvido para desenvolver cenários do RI envolvendo várias histórias com um grande número de participantes. Com sua ajuda, as informações são distribuídas entre os jogadores, e o processo de redação de textos é acompanhado por mecanismos de controle para eliminar inconsistências e identificar linhas "esquecidas".
Processo introdutório de redação
Condição do problema: há uma história na qual muitos personagens estão envolvidos. É necessário fornecer a cada personagem a parte da história que ele conhece.
Você pode resolver esse problema de frente: Frodo, sua história de fundo é essa, Gandalf, sua história de fundo é essa. O problema que estamos enfrentando é a informação fora de sincronia. Por exemplo, escrevemos na abertura Frodo “Apite alto se você vê orcs”. Mas esqueceremos de escrever isso para todos os outros membros da Irmandade do Anel, e eles não saberão o que significa o apito de Frodo. É ainda "melhor" se escrevermos sobre "o apito de Frodo" apenas metade do anel da Irmandade.
Esse problema pode ser resolvido com a introdução de outro texto - o texto da história original, com base no qual escreveremos textos adaptados ou textos de adaptação para cada personagem. O texto original lerá “Antes de embarcar em uma jornada, a Irmandade do Anel concordou que, ao ver os orcs, Frodo assobiaria”. Frodo terá: "Concordamos que, ao ver os orcs, assobiaremos". Todos os outros: "Tendo ouvido o apito de Frodo, estou correndo para salvá-lo dos orcs".
Mas há o seguinte problema. Sabemos perfeitamente quem entra na Irmandade do Anel. Mas em outra situação, podemos não conhecer todos que estiveram presentes no evento. Um exemplo de tal situação: conselhos sobre os quais eles decidiram o que fazer com o anel. Sabemos com certeza que toda a Irmandade do Anel, Elrond, se reuniu lá e poderia muito bem haver outra pessoa (mesmo que isso contradiga a fonte original). Se uma decisão foi tomada neste conselho, que precisa ser fixada nos introdutórios, então temos incerteza - qual dos 140 caracteres de nosso jogo estava no conselho e sabe alguma coisa?
Para resolver esse problema, dividimos a história em eventos, onde o evento é a unidade de tempo, local e personagens. Corrigimos o evento: “Conselho do ringue, horário: 3018/10/25 12:00, participantes: ..., descrição do evento: ...” Agora sabemos exatamente quem foi o participante do evento. Cada participante tem sua própria visão do evento, que descrevemos na adaptação do evento. A adaptação de toda a história para o personagem selecionado consiste em todas as adaptações de eventos com esse personagem.
Fase final: todas as adaptações são escritas, agrupadas em arquivos de texto por caractere. Em uma foto, fica assim:
Como resultado, obtemos dados estruturados que também são adequados para visualização:
- Podemos criar uma cronologia de eventos, tanto para cada história quanto individualmente para cada personagem.
- Rede social em um sentido sociológico. Temos muitos personagens e podemos interpretar o fato de estarem em um evento como uma conexão social entre cada um dos participantes do evento. No mínimo, eles podiam se ver, mas na maioria dos casos os personagens interagem ativamente entre si.
Um exemplo da cronologia dos eventos da amostra base do Senhor dos Anéis (clicável):
Um exemplo de rede social do jogo RI "Mad Mad Max", Mk. Albion (clicável):
Relações de Personagem
A tabela de relacionamentos de caracteres é amplamente usada no RI e NRI. A tabela de relacionamento é uma tabela quadrada na qual cada linha e cada coluna corresponde ao caractere, e nas células da tabela registramos a relação do caractere A ao caractere B. Um ponto interessante: os caracteres não precisam estar familiarizados entre si para se relacionarem. Um personagem de baixo pode ter algum tipo de ábaco com o chefe da máfia, mas o próprio chefe da máfia pode não ter consciência disso.
Dossiê
O dossiê é uma lista de fatos sobre o personagem. A estrutura do dossiê é determinada pelo mestre do jogo, pois informações importantes para um jogo não são importantes para outro. Por exemplo, a idade de um personagem pode afetar a admissão a vôos em algum jogo espacial, mas no Senhor dos Anéis não há relação com a idade e nada depende disso.
O dossiê é, obviamente, bom, mas não é útil por si só, mas em combinação com a capacidade de procurar caracteres nele. Por exemplo, precisamos adicionar um jovem nobre solteiro a uma história romântica. Configure um filtro: idade "até 30", estado "nobre", estado civil "solteiro", classifique por idade ascendente.
Grupos de caracteres
Desenvolvendo a idéia de um filtro, chegamos a grupos de caracteres. Por exemplo, temos um grupo templário no jogo e queremos fornecer o histórico do pedido apenas para as pessoas desse grupo. A decisão na testa: Petya, Vitya, Borya Templários, nós os incluímos no grupo, o texto do grupo é exibido no introdutório. Então Victor entra em assassinos, Gosha entra em seu lugar e editamos manualmente as listas de grupos. Em vez disso, podemos coletar o filtro através de um dossiê: a facção templária. Somente os caracteres que passam nesse filtro receberão texto para os Templários e não terão problemas com a atualização manual dos dados.
Traçar mapa
O mapa de plotagem é uma ferramenta para resolver conflitos entre facções. A ferramenta também é bastante conhecida no RI e no NRI. Eu usei este artigo como uma especificação. Em resumo - existem grupos de forças atuando no jogo que de alguma forma se relacionam. Por exemplo, os bons querem destruir o mal e vice-versa. Existem recursos passivos, mas que se enquadram no escopo de interesse dos grupos. Por exemplo, se você considera o anel da onipotência um recurso, o bem quer destruí-lo, o mal quer capturá-lo, o neutro quer usá-lo efetivamente. Com base no mapa da trama, podemos planejar uma lista de conflitos que serão resolvidos pelo jogo e criar uma história para eles.
Sobre implementação
O requisito inicial do sistema é autonomia. Eu queria que o mestre de interpretação de papéis pudesse trabalhar em um laptop que é ruim na comunicação. Por exemplo, em uma praça de alimentação ou mesmo em um campo de treinamento. É por isso que o NIMS é criado como um aplicativo e não como um serviço (a maioria dos sistemas para RI com funcionalidade semelhante são serviços).
O segundo requisito é a falta de arquivos executáveis e instaladores. Porque eles entopem o sistema, porque são dispostos em arquivos lavados com a capacidade de reinstalar qualquer lixo desnecessário etc.
Para iniciar, você precisa de uma máquina virtual no computador do usuário, e ela é - é um navegador. Na verdade, é assim que o NIMS é implementado - um arquivo com uma página da web independente que é aberta em um navegador.
Esta foi a minha primeira aplicação totalmente escrita em JavaScript, então tentei minimizar o uso de bibliotecas e estruturas.
Uma implementação de página da web independente tem os seguintes efeitos colaterais desagradáveis:
- não há acesso ao sistema de arquivos, por isso é impossível criar o botão "Salvar" e para que tudo seja salvo discretamente em um arquivo. Em vez disso, a versão atual do banco de dados é baixada da página. Da mesma forma, quando o sistema é aberto, não o último banco de dados é exibido, mas um banco de dados de exemplo. É necessário carregar a última base de trabalho no início do trabalho manualmente. Sim, isso é inconveniente, mas o risco de perda de dados devido a uma falha no armazenamento local e análogos é ainda pior.
- incapacidade de usar arquivos com “extensões não padrão” (oi Chrome). Por exemplo, você não pode colocar docx na pasta da página e, se necessário, carregá-lo através de uma solicitação GET. Da mesma forma, a biblioteca l20n com seus arquivos ftl não funciona. Do servidor - por favor. Resolvi o primeiro problema, codificando docx em base64 e salvando no arquivo js. Eu resolvi o segundo problema criando uma bicicleta.
- a impossibilidade de chamar programas executáveis, mesmo quando você realmente deseja. Aqui é necessário anotar o subsistema para a formação dos introdutórios - aqui escrevemos tudo, precisamos salvar isso em um arquivo e enviá-lo ao jogador por correio ou por impressão. O principal requisito era "manter a introdução no docx" (não foi isso que eu criei). Eu implementei isso com um docxtemplater. Permite gerar arquivos docx por modelo. Para esse propósito, eu precisava, mediante solicitação, carregar o modelo docx na página do parágrafo anterior.
E, a propósito, a falta de arquivos executáveis e um possível resultado offline no fato de que eu não posso usar um DBMS externo. Apenas algo no navegador da memória. Eu escolhi a ciclovia e fiz o armazenamento de dados como um objeto JSON com validação do esquema JSON na inicialização. O objeto JSON é armazenado em um arquivo de texto sem formatação chamado "base".
Em todos os outros aspectos, este é um SPA regular.
Logo após o lançamento, eles me informaram de um problema: jogos nos quais estritamente um mestre trabalha, uma minoria. Portanto, a possibilidade de trabalho conjunto no jogo de vários mestres é uma questão de vida ou morte do projeto.
Problema: temos um núcleo de trabalho, mas aprimorado para o trabalho autônomo. Como garantir a colaboração de vários mestres?
Solução: refazemos o kernel para trabalhar com o banco de dados para operação assíncrona e modificamos para que ele possa ser executado no node.js. O modo offline funciona como antes. O modo de servidor distribui uma página da web e todas as chamadas para o kernel são convertidas em Chamada de procedimento remoto para executar solicitações no servidor. O que costumava ser uma interface de kernel se torna uma API. No caminho, o modo de servidor estende a API com recursos de gerenciamento de usuários e controle de acesso.
Como resultado, as soluções offline e de servidor usam o mesmo núcleo. Esquematicamente, fica assim:
Materiais
Nós preparamos muitos materiais para os usuários:
- Apresentação online - uma breve descrição dos conceitos básicos para usuários não familiarizados com o NIMS.
- Os screencasts são vídeos em que falo sobre como usar o NIMS.
- Documentação - uma descrição completa dos conceitos usados e da funcionalidade implementada.
- Demonstração online - versão offline postada na Internet. Ele vem completo com um exemplo de banco de dados que ilustra, se não todos, a maioria dos recursos implementados.
A versão offline pode ser baixada aqui . Trabalho verificado no Chrome e Firefox. Ele deve funcionar independentemente do sistema operacional, mas isso não foi especificamente testado.
Quanto ao código fonte - o projeto é dividido em recursos de cliente, servidor e texto:
- O cliente inclui toda a funcionalidade de script.
- Os recursos de texto são um exemplo de base, apresentação, documentação, modelos de upload.
- O servidor é uma extensão do núcleo do cliente para trabalhar com direitos e organizar o acesso remoto para vários usuários. Atualmente, essa parte do projeto não está disponível ao público.
Conclusão
O projeto NIMS oferece uma oportunidade de analisar roteiros de uma perspectiva diferente. Os cenários para o RI são histórias incompletas e não é necessário formar uma narrativa consistente para o espectador / leitor. No RI, cada jogador recebe sua informação e age com base nisso, assim como na realidade. Nesse caso, a tarefa do roteirista não é apenas contar a história, mas também distribuir a história entre os personagens.