Bölüm 19 Tasarım Belgesi

1. Bölüm 19Tasarım Belgesi Ders Sorumlusu: Doç. Dr. Hakan TÜZÜN Hazırlayan: Safiye OLGUN Hacettepe Üniversitesi 2012-2013 Bahar Dönemi Fen Bilimleri Enstitüsü, Bilgisayar ve Öğretim Teknolojileri Eğitimi ABD BTÖ 616 Eğitsel Bilgisayar Oyunları Tasarımı Dersi

2. Tasarım Belgesi ? • İçinde hangi bilgiler yer almalı? • Nasıl ortaya konmalı? • Kullanılacak biçim nasıl olmalı? • Standart formatı var mı? • Tasarım belgesi ile oyun tasarımı tamamlanır ama uğraş bitmemiştir.

3. Tasarım Belgesi • Belli bir formatı yok. • Her tasarımcı kendi formatını oluşturur. • Belgenin belli miktarda ve türde bilgi içermesi kesin değildir. • Belge yararlı bilgileri içermelidir. • Belli bir standardı yoktur. • Ama bazı büyük şirketlerin kendileri için geliştirdiği bir form vardır. (uyma, aşinalık, uygun bilgi)

4. Tasarım Belgesi ne içermeli? • Oyunun vizyonunu ifade etmelidir. • Oyuncuların nasıl bir deneyim yaşayacağını • Oyuncuların oyun dünyası ile nasıl etkileşime geçeceğini ifade etmelidir. • Gerekli bilgiyi sağlıyorsa başarılı olur.

5. Tasarım Belgesi zorlukları • Tüm bölümlere ait uygun bilgileri yapılandırma ve organizasyon

6. Yazım Tarzı • Aramayı kolaylaştıracak bir referans aracıdır. • İncelemenin kolay olması gerekir.(İçindekiler, başlıklar) • Yazım işinde kolaylık sağlama(otomatik format vb.) ve zaman kazanma adına özel yazım aracı kullanılabilir. • Yazılmasının sonrası diğer üyeler tarafından okunması gerekiyor. • Özel yazım aracının bulunmasının zor olabileceği için kelime işlemci kullanmak daha iyi olabilir. • Çevirici ile standart kelime işlemci formatlarına kaydetmesi ile sorun aşılabilir.

7. Yazım Tarzı • Tasarım belgesi geliştirme ekibinin tüm üyeleri tarafından okunacaktır. • Sıralı olarak kapsamlı tüm bilgileri içerecektir. • Tekrar içermemelidir. • Köprü(link) kullanılabilir. • Tutarsız oyun mekaniği(gameplay) tanımları olmamalıdır. • Kısa ve öz olmalı. • Hazırlanması ve okunması aşırı zaman harcanmamalıdır.

8. Yazım Tarzı • Heyecan değil gerekli bilgileri içermeli. • Finans için yazıldığında satış merkezli ve özet bilgi içermeli, ama geliştirme ekibine de hitap etmeli. • Focus’a göre Tasarım belgesinde karşılaştırma yapılabilir. • Başka oyun mekaniği benzeri olsa bile sistem tam olarak açıklanmalıdır. • Elektronik kaynaktan okuma okumayı kolaylaştıracaktır.

9. Tasarım Belgesi Bölümleri • İçindekiler Listesi • Giriş / Genel Bakış veya yönetici özeti • Oyun Mekanikleri • Yapay Zeka • Oyun Elemanları • Hikayeye Bakış • Oyun Akışı • Sistem Menüleri

10. İçindekiler Listesi • İçindekiler listesi; başlık, alt başlık, alt başlık alt başlığı vb. içerir. • Ayrıntılı içindekiler listesi belgenin yararlı olmasını sağlar. • 50 sayfayı geçen belge birden fazla bölüme ayrılmalıdır. • İçerik stili kullanılmadığı zaman okuyucu programlarında liste üzerinden farklı bölümlere geçilemez. • Başlıkların kalın yazılması gezinimi kolaylaştırır.

11. İçindekiler Listesi • Başlıklar ile kelime işlemci programlarında yapılır; • içindekiler listesi • otomatik güncelleme • içindekiler listesinde seçip okumayı

12. Giriş / Genel Bakış veya yönetici özeti • Tek sayfa ile sınırlanmalı, daha uzunu etkili özet olmaktan çıkar. • Fazlasında en az önemli veriler 1 sayfaya inene kadar çıkarılır. • Geliştiriciler için faydalı değildir. • Ekibe yeni katılanın oyunu anlaması için iyi bir başlangıçtır. • Yapımcı, yönetici ve pazarlamacının büyük resmi anlamasında yardımcı olabilir. • Belgenin tamamını okumaya zamanı olmayacaklar için gameplay özünü verir.

13. Giriş / Genel Bakış veya yönetici özeti • Sürükleyici (çekici ve benzersiz) bir özette ilk paragraf tüm oyunu kısaca anlatır, devam eden paragraflarda bunun yapısı ayrıntılı anlatılır. • Tasarım belgesi hazırlamadan önce oyun odağının tanımı üstüne çalışılmalıdır. • Odak özetin başlangıcıdır. • Genel bakış ile gelişme paragraflarından birinde oyun hikayesi özetlenmelidir. (varsa) • Geçmiş olmadan, gameplay sırasındaki macera • Hikayenin sonu • Karşılaşılacak diğer karakterler ve gezinimler

14. Oyun Mekanikleri • Belgenin en önemli parçası ve en zor yazılan bölümüdür. Oyunun özü, merkezidir. • Gameplay’ın ne olduğunu tanımlamak için ilk olarak bakılacak yerdir. • Oyuncuların yapmaya izinli oldukları ve oyunun nasıl oynandığını tanımladığı için bu bölüm gameplay bölümü olarak da ifade edilebilir. • Oyuncunun yapabileceği hareketlerin çeşitlerini tanımlamakla oyun tanımlanır. • Oyun dünyası nesneleri ve karakterleri detaylı anlatılmaz. (oyuncu karakteri dışında)

15. Oyun Mekanikleri • Oyuncuların oyunda ne göreceğinin anlatılmasıdır. • Oyun dünyasında oyuncu zorlukları nasıl aşacağını ayrıntılı anlatılmasıdır. • Okuyucu dostu olmalı • Varsayım içermemeli • Oyun türüne göre konuları değişir. • Ne nasıl nerede ne zaman niçin sorularına cevap vermeli?

16. Oyun Mekanikleri neler? • İlk kez oynayacak kişinin tecrübe etmesi düşünülmesi (basit başlanması) • Oyuncunun yapabileceği en temel hareketler • Oyuncunun avatarının ne olacağı ve hareketleri • İleri, geri, sağ, sol, zıplama, çömelme, yuvarlanma • Nasıl çalıştığı • Ulaşılamayan durumdaysa oyuna ne olacağı • Kaç düğme ile çalıştığı • Diğer nesneleri topluyor? Değiştiriyor? • Sağlık durumu • Hangi konum ve emirler düğmelere basılacağı

17. Oyun Mekanikleri neler? • Nesneler çarpışınca, dönünce nasıl tepkiler oluşacak • Eğimli yüzeylerde yavaş mı hareket edilecek • Teknoloji ile bağlantı 2d, 3d? Gerçek zamanlı? • Kamera çeşiti, oyuncuya etkisi, kapasitesi, açıları ve adeti • Gameplay ile ilişki olarak grafik arayüz tarifi • Oyun üzerine bindirilmiş verilerin tarifi • Nesnelere ait bulmacaların tarifi • Oyun içinde farkı görevleri yapmak için farklı modlara geçişler

18. Yapay Zeka • Oyuncu ile oyun dünyası arasında nasıl etkileşime geçileceğini ve oyun dünyasının oyuncu davranışına nasıl cevap vereceğini tanımlar. • Oyuncuya oyunun nasıl davranacağı tam tarif edilir. • Hangi durumda ne yapılacak? • Oyuncu bir şey yapmadığında oyun dünyası ne yapacak? • Oyun dünyasında rakipler nasıl davranacak? • Bu bölüm oyun mekaniği bölümü içinde de yer alabilir. (Oyunun özelliğine bağlı)

19. Yapay Zeka unsurları? • Tecrübe etme ile düşmanın yapay zekasının anlaşılmaya çalışılması • Oyuncunun karşılaştığı diğer karaktere nasıl tepki üreteceği • Saldırıyor mu? Görmezden mi geliyor • Diğer karakterler tanımlı yolu mu izliyor? Akıllı mı? • Seviye tasarımcıların yaptığı hangi şeyler nasıl tetikleniyor? • Düşmanlar oyuncuyu nasıl alt edecek?

20. Yapay Zeka • Programcı ile çalışarak hazırlanması ile oyun ajanlarından beklentiler daha net anlaşılır. • Bu bölümün tasarımı programcıya yardım eder. • NPC oyunlarında nasıl?

21. Oyun Elemanları • Elemanlar oyunun farklı yerlerinde bir araya gelerek düzeylerde oyuncular için zorlayıcı tecrübeleri oluşturur. • Tasarımcılar bu elemanları getirir, benzersiz birleştirip, oyuncunun düzeylerde saatlerce uğraşacağı hale getirir. • Hemen hemen tüm oyunların elemanı olur. • Bu kısım hikaye bakışı ve oyun akışı ile bağlıdır. • Burada karakterler listelenir.

22. Oyun Elemanları • Sanat ve programlama ekibi arasında bilgi akışını sağlar. • Sanat ekibi oyunda tasarlanmış her eleman için assert oluşturur. • Oyun mekaniği ve yapay zeka birçok oyunda benzer iken bu kısım oyunun benzersizliğini oluşturur. Bu iki kısmı birleştirmesini programlama ekibi üstlenir. • Ajanların özellikleri ne? • Birden fazla mücadeleden kaçılabilir mi? • Her yapay zeka öğesinin yetenekleri ve etkisi ne? • Nesnenin diğer nesneler göre ne kadar büyük?

23. Oyun Elemanları ? • Karakterler: Karşılan yapay zeka ajanları • Parçalar: Avatarın bazı şekillerde aldığı, kullandığı ve değiştirdiği varlıklar • Nesneler/mekanizmalar: Yapay zekanın çalıştırmadığı, avatarın alamadığı ama işlettiği varlıklar (diğer varlıkları değiştiren) • Bu üç sınıflandırma tüm oyunlar farklı şekilde olabilir. • Half Life ve Star Craft’da üçü de var • Diablo’da yok

24. Hikayeye Bakış • Düzgün yazılmış belgeler ile kolaylıkla oyun hakkında bilgi elde edilir. • Genel bakış gibi oyuna bir resimden bakmayı kısa yoldan sağlar. • Hikayenin tüm noktalarını ele alan ve kolaylıkla okunabilecek uzunlukta olmalıdır. • Hikayenin karmaşıklığına göre uzunluğunu değişebilir. Bir çift sayfa yeterlidir. • Oyunda tüm görevleri ve karşılaşmaları içermez. • Okunaklı, zevkli ve ilgi uyandıran olmalıdır.

25. Oyun Akışı • Oyuncunun aldığı düzeyi oynarken nasıl hissedeceği ve duygusal iletişimi nasıl olacağının ifadesidir. • Tasarım belgesinin en uzun olduğu kısım olabilir. • Oyuncu tecrübesinin olaylarla bölündüğü, değiştiği ve zamanın ilerlediğini ifade eder. • Tek çatışmaya göre düzey bölünmesi şart değildir. • RPG, RTS, FPS ve uçuş simülasyonların oyun akışı düzeyler ile kesilir. • Sanat ekibine ve düzey tasarımcılarına nasıl bir ortam geliştireceklerine dair rehberlik yapar.

26. Oyun Akışı ? • Her düzey ve oyuncununu karşılaşacağı zorluklar ve görsel estetik açıklanır. • Düzeyler oyuncuyu nasıl etkileyeceği ve gameplay tecrübe çeşidi ifade edilir. • Oyun boyunca düzeyler nasıl hissedecek ve nasıl duyguları dalganalacak? • Sürekli çatışma ve zorluk mu olacak? Gezinim araştırma yönlü olarak yavaş hızda mı olacak? • Düzeylerde tepe noktası olacak mı? Yoksa oyun yavaş hız da mı? • Nesneler ve parçalar hangi konumda yer alır? • Hangi tip düşmanlar ile karşılaşılacak ve ilerleyiş boyunca ne tip parçalar toplanacak?

27. Oyun Akışı • Her oyunun düzeyi olmayacağı için oyun akışının birimleri kolaylıkla bölünmesi mümkün olmayabilir. • Her oyunda oyun akışı olması gerek olmayabilir. • SimCity ve Civilization'da gameplay oyun mekaniği, yapay zeka ve oyun elementleri ile ilgili. Düzeyleri rastgele olduğu için oyun akışına ihtiyaç yok. • Oyun belli bir senaryoya sahipse, oyun akışı farklı senaryolar ile oyuncu karşılaşması ile tanımlanır.

28. Sistem Menüleri • Ana menünün açıklandığı ve diğer seçenek ekranlarının sunulduğu yerdir. • Gameplay için önemli değildir. • Oyuncuların oyunlarına kaydetme ve daha sonra yüklemeleri tanımlamalıdır. • Ne tip arayüz kullanılacağı ve ne ile kullanılacağı bu menülerde tanımlanır. • Fare mi klavye mi ikisi birden kullanır?

29. Yazarın görüşü • Tasarım belgesinin belli bir standartı yok. • Projeden proje değişebilir. • Belli bir tür oyunda standartlaşma vardır. Tabi oyunun gameplayına uygun olarak düzenlenmesi gerekir. • İnce belgeler • Kalın belgeler • Aşırı belgeler • Zamanla ve ekip gözardı edilen belgeler • Fosil belgeler

30. Kalınlık Sorunu • Tasarım belgelerinin ihtiyaç olunacağı düşünülen tüm bilgilerin konulması ile kalın bir belge elde edilecektir. • Belgenin kalın olması ekip üyelerinin çoğunun sadece içindekiler listesi bakmasına neden olur.

31. Okumaya Hazırlık • Hazır olan belgenin ekibin tümü tarafından okunmaması ciddi bir problemdir. • Belgenin taşıdığı bu özellikler okunması artırılabilir. • Güncel bilgiler • Gerekli bilgiler • Uygulanabilir şekilde sınırlandırma • Gameplay öğelerin yapılabilirliği • Detaylı içindekiler listesi • Kaliteli özet • Ekibin güvenini kazanma • Herkesin okuyabileceği hale getirme • Değişiklikleri ekibe güncel olarak iletilmesi • Versiyon numaraları kullanılması

32. Tasarım Belgesi bir başlangıç • Asıl olan tasarım belgesinden tecrübe kazanmaktır.