1 Tasarım Belgesi Bölüm 19 Tasarım Belgesi Ders Sorumlusu: Doç. Dr. Hakan TÜZÜN Hazırlayan: Safiye OLGUN Hacettepe Üniversitesi 2012-2013 Bahar Dönemi.

... konulu sunumlar: "1 Tasarım Belgesi Bölüm 19 Tasarım Belgesi Ders Sorumlusu: Doç. Dr. Hakan TÜZÜN Hazırlayan: Safiye OLGUN Hacettepe Üniversitesi 2012-2013 Bahar Dönemi."— Sunum transkripti:

1 1 Tasarım Belgesi Bölüm 19 Tasarı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 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 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 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 5 Tasarım Belgesi zorlukları  Tüm bölümlere ait uygun bilgileri yapılandırma ve organizasyon

6 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 32 Tasarım Belgesi bir başlangıç  Asıl olan tasarım belgesinden tecrübe kazanmaktır.