Ada banyak program skrip dan banyak kesempatan untuk menulis skrip Anda sendiri. Tetapi, seperti semua alat kerja, perangkat lunak skenario beradaptasi dengan persyaratan area subjek. Karena alasan ini, program skrip film tidak cocok untuk menulis skrip untuk permainan komputer dan sebaliknya. Area saya bahkan lebih spesifik - saya mengembangkan program NIMS (seperangkat alat untuk alur cerita utama) untuk membuat skrip untuk permainan peran-bermain aksi langsung (selanjutnya disebut RI).
Pertanyaan Blitz:
Apakah ini digunakan? Ya, proyek ini sudah berumur dua tahun. Selama ini, NIMS membuat lebih dari 20 game.
Apakah sudah dibayar? Gratis - donationware.
Dalam posting ini, saya akan berbicara tentang jenis-jenis tugas skenario, spesifikasi penulisan skrip untuk Republik Ingushetia, yang dapat dilakukan NIMS dan fitur-fitur implementasinya.
Gambar tersebut menunjukkan jejaring sosial berdasarkan plot RI “Port Arthur”, MG S&M (dapat diklik).
Penafian 1: permainan permainan peran papan adalah jenis permainan independen dan saya akan menyebutnya sebagai NRI.
Klasifikasi Tugas Scripting
Selama berabad-abad, naskah sebagai sebuah fenomena milik eksklusif adegan itu. Pada akhir abad ke-19, bioskop muncul, dan pada akhir abad ke-20 - berbagai permainan (komputer, papan, aksi langsung, dll.) Dan di mana-mana ada skenario. Dari sudut pandang artistik, mereka serupa dan mematuhi hukum penulisan naskah yang seragam. Tetapi dari sudut pandang bentuk penyajian informasi, setiap area penerapan skrip memiliki tugasnya masing-masing. Mari kita coba mencari tahu.
Tugas skrip dapat dibagi dengan ada / tidaknya interaktivitas dengan pemirsa / pengguna. Bioskop, acara TV, buku, dan teater membutuhkan skenario non-interaktif . Dengan demikian, pemirsa tidak dapat mempengaruhi jalannya cerita dan pada akhirnya hanya ada skenario. Sebaliknya, ada skenario interaktif yang melibatkan pengaruh pemirsa. Ini adalah skenario berbagai game.
Script interaktif dapat dibagi menjadi tertutup dan terbuka. Skenario tertutup membutuhkan deskripsi dari semua opsi yang mungkin untuk pengembangan sejarah. Misalnya, skrip untuk permainan komputer dan permainan peran-bermain buku.
Skenario interaktif terbuka , pada gilirannya, dapat dibagi secara kondisional sesuai dengan tingkat ketergantungan master. Dalam permainan papan permainan peran, seperti D & D , semua tindakan para pemain dikomunikasikan kepada master dan dia menceritakan. Permainan ini sepenuhnya tergantung pada master , dan pemain tidak dapat mengambil satu langkah pun tanpa master.
Di Republik Ingushetia, sejumlah besar pemain berinteraksi dalam kerangka aturan dan kesepakatan yang ditetapkan sebelum pertandingan. Master tidak perlu mengikuti setiap langkah, tetapi kompetensi mereka biasanya tetap merupakan resolusi dari masalah yang diperdebatkan dan menambal kesalahan aturan selama pertandingan. Saya menekankan sekali lagi bahwa pemain berinteraksi satu sama lain secara mandiri , tanpa campur tangan penyihir.
Penafian 2: dogma yang diuraikan di sini bukanlah opsi yang umum, melainkan, NRI bersifat otonom, RI independen dan masih ada berbagai opsi perantara.
Skenario pada game role-action live-action
Perkembangan RI memiliki persyaratan tertentu. Dalam proses pembangunan, model dunia diciptakan, yang dihuni oleh karakter, dan konflik direkam. Seringkali, untuk gim, Anda harus membuat lusinan karakter aktif dan lusinan cerita terbuka dengan metode penyelesaian.
Sebelum pertandingan, pemain diberikan deskripsi pengantar tentang posisi karakternya: latar belakang, kerabat, teman, musuh, properti, konflik, posisi fraksi pada masalah utama, dll. Ringkasnya, dalam pendahuluan Anda dapat memasukkan informasi apa pun yang "dapat diputar".
Dan satu lagi penafian: yang dijelaskan di sini juga bukan dogma. Ada permainan tanpa pembukaan sama sekali, atau beberapa pemain memiliki pembukaan, tetapi beberapa tidak. Pemain dapat melihat pengantar langsung ke permainan, dan dapat mengambil bagian dalam pengembangannya beberapa bulan sebelum pertandingan, menunjukkan apa yang ingin ia mainkan dengan dan dengan siapa.
Bagian penting dari cerita pengantar untuk prasejarah, yang dirancang untuk menjawab pertanyaan "Mengapa ...?": "Mengapa saya membenci raja?", "Mengapa rumah kita berperang?", "Mengapa penting bagi kita bahwa ritualnya berjalan dengan baik?"
Setiap pemain harus menerima bagian informasinya dan mengoperasikannya di permainan. Momok menulis pengantar adalah inkonsistensi. Setiap peristiwa dari sejarah diceritakan berulang kali dan dengan aksen yang berbeda, karena setiap peserta melihat situasi dengan caranya sendiri. Setiap fakta tidak hanya harus dijelaskan dalam beberapa versi, tetapi juga jika ada perubahan, semua perubahan ini harus digandakan dalam setiap opsi. Misalnya, jika dalam episode tertentu 5 karakter terlibat, maka jika ada sedikit perubahan dalam episode ini, Anda perlu membuat 5 pengeditan, dan bukan satu. Situasi ini menyebabkan sejumlah besar ketidakkonsistenan.
Proyek NIMS dirancang untuk mengembangkan skenario RI yang melibatkan banyak cerita dengan sejumlah besar peserta. Dengan bantuannya, informasi didistribusikan di antara para pemain, dan proses penulisan teks disertai dengan mekanisme kontrol untuk menghilangkan ketidakkonsistenan dan mengidentifikasi garis yang "dilupakan".
Proses penulisan pengantar
Kondisi masalah: ada cerita yang melibatkan banyak karakter. Penting untuk memberi setiap karakter bagian dari cerita yang dia ketahui.
Anda dapat menyelesaikan masalah ini langsung: Frodo, cerita latar Anda adalah ini, Gandalf, cerita latar Anda adalah ini. Masalah yang kita hadapi adalah informasi tidak sinkron. Sebagai contoh, kami menulis di pembukaan Frodo "Bersiul dengan keras jika Anda melihat orc." Tetapi kita akan lupa untuk menulis ini kepada semua anggota lain dari Persaudaraan Cincin, dan mereka tidak akan tahu apa arti peluit Frodo. Bahkan "lebih baik" jika kita menulis tentang "peluit Frodo" hanya setengah dari cincin Persaudaraan.
Masalah ini dapat diselesaikan dengan memperkenalkan teks lain - teks dari cerita asli, yang akan digunakan untuk menulis teks adaptasi atau teks adaptasi untuk setiap karakter. Teks aslinya akan berbunyi, "Sebelum memulai perjalanan, Persekutuan Cincin sepakat bahwa saat melihat Orc, Frodo akan bersiul." Frodo akan memiliki: "Kami sepakat bahwa saat melihat para orc saya akan bersiul." Semua orang: "Setelah mendengar peluit Frodo, saya berlari untuk menyelamatkannya dari para orc."
Tetapi ada masalah berikut. Kita tahu betul siapa yang memasuki Ikhwanul Ring. Namun dalam situasi lain, kita mungkin tidak mengenal semua orang yang hadir di acara tersebut. Contoh dari situasi seperti itu: saran yang mereka putuskan apa yang harus dilakukan dengan cincin itu. Kita tahu pasti bahwa seluruh Persaudaraan Cincin, Elrond, berkumpul di sana, dan mungkin ada orang lain (bahkan jika ini bertentangan dengan sumber aslinya). Jika keputusan dibuat di dewan ini, yang perlu diperbaiki dalam pengantar, maka kita mendapatkan ketidakpastian - yang mana dari 140 karakter permainan kita yang ada di dewan dan tahu sesuatu?
Untuk mengatasi masalah ini, kami memecah cerita menjadi peristiwa, di mana acara adalah kesatuan waktu, tempat dan karakter. Kami memperbaiki acara: "Dewan cincin, waktu: 3018/10/25 12:00, peserta: ..., deskripsi acara: ..." Sekarang kita tahu persis siapa yang menjadi peserta acara. Setiap peserta memiliki visinya sendiri tentang acara tersebut, yang kami jelaskan dalam adaptasi acara tersebut. Adaptasi keseluruhan cerita untuk karakter yang dipilih terdiri dari semua adaptasi peristiwa dengan karakter ini.
Tahap akhir: semua adaptasi ditulis, kami mengelompokkannya ke dalam file teks berdasarkan karakter. Dalam satu gambar, terlihat seperti ini:
Hasilnya, kami mendapatkan data terstruktur yang juga cocok untuk visualisasi:
- Kita dapat membuat kronologi peristiwa, baik untuk setiap cerita dan secara individual untuk setiap karakter.
- Jejaring sosial dalam arti sosiologis. Kami memiliki banyak karakter, dan kami dapat menafsirkan fakta keberadaan mereka dalam satu acara sebagai hubungan sosial antara masing-masing peserta dalam acara tersebut. Paling tidak, mereka dapat saling melihat, tetapi dalam kebanyakan kasus karakter-karakter tersebut saling berinteraksi secara aktif.
Contoh kronologi peristiwa sampel dasar Lord of the Rings (dapat diklik):
Contoh jejaring sosial dari game RI "Mad Mad Max", Mk. Albion (dapat diklik):
Hubungan Karakter
Tabel hubungan karakter banyak digunakan di RI dan NRI. Tabel relasi adalah tabel kuadrat di mana setiap baris dan setiap kolom berhubungan dengan karakter, dan di dalam sel tabel kita mencatat hubungan karakter A dengan karakter B. Poin yang menarik: karakter tidak harus akrab satu sama lain untuk saling berhubungan. Karakter dari bawah mungkin memiliki semacam sempoa dengan bos mafia, tetapi bos mafia sendiri mungkin sama sekali tidak menyadari hal ini.
Berkas
Berkasnya adalah daftar fakta tentang karakter. Struktur berkas ditentukan oleh master game, karena informasi penting untuk satu game tidak penting untuk yang lain. Misalnya, usia karakter dapat memengaruhi tiket masuk pada beberapa game luar angkasa, tetapi dalam Lord of the Rings tidak ada kaitannya dengan usia dan tidak ada yang bergantung padanya.
Berkasnya, tentu saja, bagus, tetapi tidak berguna dalam dirinya sendiri, tetapi dikombinasikan dengan kemampuan untuk mencari karakter di dalamnya. Misalnya, kita perlu menambahkan seorang bangsawan muda yang belum menikah ke kisah romantis. Siapkan filter: usia "hingga 30", real "mulia", status perkawinan "lajang", urutkan berdasarkan usia naik.
Grup karakter
Mengembangkan gagasan filter, kami datang ke grup karakter. Misalnya, kami memiliki grup Templar di permainan, dan kami ingin memberikan riwayat pesanan hanya kepada orang-orang dari grup ini. Keputusan di dahi: Petya, Vitya, Borya Templar, kami sertakan dalam grup, teks untuk grup ditampilkan di pengantar. Kemudian Victor menjadi pembunuh, Gosha menggantikannya, dan kami secara manual mengedit daftar grup. Sebagai gantinya, kami dapat mengumpulkan filter melalui dokumen: faksi Templar. Hanya karakter yang lulus filter ini yang akan menerima teks untuk Templar, dan tidak ada masalah dengan memperbarui data secara manual.
Plot peta
Peta plot adalah alat untuk menyelesaikan konflik antar-faksi. Alat ini juga cukup terkenal baik di RI maupun NRI. Saya menggunakan artikel ini sebagai spesifikasi. Singkatnya - ada kelompok kekuatan yang bertindak pada permainan yang entah bagaimana berhubungan satu sama lain. Misalnya, yang baik ingin menghancurkan yang jahat, dan sebaliknya. Ada sumber daya yang pasif, tetapi termasuk dalam ruang lingkup kepentingan kelompok. Misalnya, jika Anda menganggap cincin kemahakuasaan sebagai sumber daya, keinginan yang baik untuk menghancurkannya, kejahatan ingin menangkapnya, yang netral ingin menggunakannya secara efektif. Berdasarkan peta plot, kita dapat merencanakan daftar konflik yang akan diselesaikan oleh game dan membuat alur cerita untuk mereka.
Tentang implementasi
Persyaratan sistem awal adalah otonomi. Saya ingin master peran dapat bekerja dari laptop di tempat yang buruk dengan komunikasi. Misalnya, di food court atau bahkan di tempat pelatihan. Itulah sebabnya NIMS dibuat sebagai aplikasi, dan bukan sebagai layanan (kebanyakan sistem untuk RI dengan fungsi serupa adalah layanan).
Persyaratan kedua adalah kurangnya file dan installer yang dapat dieksekusi. Karena mereka menyumbat sistem, karena mereka diletakkan pada file washes dengan kemampuan untuk menginstal ulang sampah yang tidak perlu, dll.
Untuk menghidupkannya, Anda memerlukan mesin virtual di komputer pengguna, dan itu adalah - itu adalah browser. Sebenarnya, ini adalah bagaimana NIMS diimplementasikan - arsip dengan halaman web yang berdiri sendiri yang terbuka di browser.
Ini adalah aplikasi pertama saya yang seluruhnya ditulis dalam JavaScript, jadi saya mencoba meminimalkan penggunaan perpustakaan dan kerangka kerja.
Implementasi halaman web mandiri memiliki efek samping yang tidak menyenangkan berikut:
- tidak ada akses ke sistem file, sehingga tidak mungkin untuk membuat tombol "Simpan" dan sehingga semuanya diam-diam disimpan ke file. Sebaliknya, versi database saat ini diunduh dari halaman. Demikian pula, ketika sistem dibuka, bukan database terakhir yang ditampilkan, tetapi database contoh. Penting untuk memuat pangkalan kerja terakhir di awal pekerjaan secara manual. Ya, ini merepotkan, tetapi risiko kehilangan data karena kegagalan penyimpanan lokal dan analog bahkan lebih buruk.
- ketidakmampuan untuk menggunakan file dengan "ekstensi non-standar" (hi Chrome). Misalnya, Anda tidak bisa meletakkan docx di folder halaman dan, jika perlu, muat melalui permintaan GET. Demikian pula, pustaka l20n dengan file ftlnya tidak berfungsi. Dari server - tolong. Saya memecahkan masalah pertama dengan encoding docx di base64 dan menyimpan ke file js. Saya memecahkan masalah kedua dengan membuat sepeda.
- ketidakmungkinan memanggil program yang dapat dieksekusi, bahkan ketika Anda benar-benar ingin. Di sini perlu untuk dicatat subsistem untuk pembentukan yang pengantar - di sini kita telah menulis segalanya, kita perlu menyimpan ini ke file dan mengirimkannya ke pemain melalui surat atau cetak. Persyaratan utama adalah untuk "menjaga intro ke dalam docx" (ini bukan apa yang saya hasilkan). Saya menerapkan ini dengan docxtemplater. Ini memungkinkan Anda untuk menghasilkan file docx oleh templat. Untuk tujuan ini, saya perlu, atas permintaan, untuk memuat template docx ke halaman di paragraf sebelumnya.
Dan omong-omong, kurangnya file yang dapat dieksekusi dan kemungkinan offline menghasilkan fakta bahwa saya tidak dapat menggunakan DBMS eksternal. Hanya sesuatu di browser dalam memori. Saya memilih jalur sepeda dan menjadikan penyimpanan data sebagai objek JSON dengan validasi Skema JSON saat boot. Objek JSON disimpan dalam file teks biasa yang disebut "basis".
Dalam semua hal lain, ini adalah SPA biasa.
Tak lama setelah rilis, mereka memberi tahu saya tentang masalah: permainan yang hanya digunakan oleh satu master, minoritas. Oleh karena itu, kemungkinan kerja bersama pada permainan oleh beberapa master adalah masalah hidup dan mati proyek.
Masalah: kami memiliki inti kerja, tetapi diasah untuk pekerjaan otonom. Bagaimana cara memastikan kolaborasi beberapa master?
Solusi: kami membuat ulang kernel untuk bekerja dengan database untuk operasi asinkron dan memodifikasinya sehingga dapat berjalan di node.js. Mode offline berfungsi seperti sebelumnya. Mode server mendistribusikan halaman web, dan semua panggilan ke kernel dikonversi ke Panggilan Prosedur Jauh untuk mengeksekusi permintaan di server. Apa yang dulunya merupakan antarmuka kernel menjadi API. Sepanjang jalan, mode server memperluas API dengan manajemen pengguna dan fitur kontrol akses.
Akibatnya, solusi offline dan server menggunakan inti yang sama. Secara skematis, tampilannya seperti ini:
Material
Kami telah menyiapkan banyak materi untuk pengguna:
- Presentasi online - deskripsi singkat tentang konsep dasar untuk pengguna yang tidak terbiasa dengan NIMS.
- Screencasts adalah video tempat saya berbicara tentang cara menggunakan NIMS.
- Dokumentasi - deskripsi lengkap dari konsep yang digunakan dan fungsionalitas yang diimplementasikan.
- Demo online - versi offline yang diposting di Internet. Itu datang lengkap dengan contoh database yang menggambarkan, jika tidak semua, maka sebagian besar fitur yang diterapkan.
Versi offline dapat diunduh di sini . Memeriksa pekerjaan di Chrome dan Firefox. Ini harus bekerja terlepas dari OS, tetapi ini belum diuji secara khusus.
Adapun kode sumber - proyek ini dibagi menjadi sumber daya klien, server dan teks:
- Klien mencakup semua fungsi skrip.
- Sumber daya teks adalah basis contoh, presentasi, dokumentasi, template unggahan.
- Server adalah perpanjangan dari inti klien untuk bekerja dengan hak dan mengatur akses jarak jauh untuk beberapa pengguna. Bagian dari proyek ini saat ini tidak tersedia untuk umum.
Kesimpulan
Proyek NIMS memberikan kesempatan untuk melihat penulisan layar dari perspektif yang berbeda. Skenario untuk RI adalah cerita yang tidak lengkap dan tidak perlu membentuk narasi yang konsisten dari mereka untuk pemirsa / pembaca. Di RI, setiap pemain menerima informasi dan tindakannya atas dasar ini, serta dalam kenyataan. Dalam hal ini, tugas penulis naskah tidak hanya untuk mengisahkan cerita, tetapi juga untuk mendistribusikan cerita antar karakter.