Temel UDK Terimleri ve Oyun Tasarım Prensipleri

Bir oyun ekibi genel olarak 4 tip kişiden oluşur:

1 - Sanat Yönetmeni (art director): aynı zamanda tasarım şefidir. Oyunun tüm içeriğini kavramsal konseptini ve tüm atmosferini o belirler.

2 - Level Tasarımcısı (level designer): Sanat yönetmeninin konseptine uygun olarak haritaları (maps) ve levelleri, ve her level içindeki yapıları basitçe ayırır. Bunu yaparken detaya inmeden basit / kaba geometrik şekiller kullanır; küp gibi. Onun işi detaylarda boğulmak değil levellerin kaba prototiplerini yani level taslaklarını hazırlamaktır.

3 - 3D Sanatçılar (3D artist): prototipi hazırlanmış level içindeki objelerin gerçek hallerini hazırlar ve leveldeki kaba objeler ile değiştirir. Görsel detaylar ile boğuşur. bir level, level tasarımcısı ve 3D sanatçılarının ortak çalışması sonucu ortaya çıkar.

4 - Programcı (coder): Oyunun arka plan kodlamasını yapar. Adına GameLogic denen oyunun tüm kuralları, işleyişi için UDK da Kismet görsel script araçları mevcuttur. Bunlarla kod yazmaya gerek kalmadan hazır davranış (behavior) şemaları ile de temel bir gamelogic yapılabilir. Ama onun yetmediği durumlarda mutlaka devreye programcı girerek kodlama yapar. Bir gamelogic oluşurken programcı da level tasarımcısı ile birlikte çalışır. UDK motorundaki hali hazırdaki behavior lar yetmediği durumlarda kod ile yenileri yaratılabilir. Yada doğrudan kod ortamında tüm bunlar programlanabilir. Tüm bu işlemler genellikle tek bir level içinde geçerlidir. Kod ile veya Kismet ile tanımlanan scriptler level içindeki görsel bir obje (geometri) ile alakalı olabileceği gibi, levelin sistemi ile ilgili de olabilir. Sonuç olarak tamamı o level içindeki objelerin (geometri veya sistem) davranışsal programlanmasıdır.


Level Tasarımı
Harita (map) yaparken genellikle büyük şekiller küçük şekillere bölünerek ayrı ayrı mesh ler olarak birleştirilir. Bu bize başta ciddi bi performans getirisi olmak üzere bazı hatalardan da korunmamızı sağlar. Yeni 3D yazılımların bu işi otomatik olarak yapabildiğini duymuştum (3D Max daki shtools gibi). Oluşturulmuş map ler de genellikle ard ard yapıştırılarak geniş bir oyun alanı elde edilir.


Texture
Map bir kez yaratıldımı artık texture sanatçısı map texture leri üzerinde çalışmaya başlar. Geniş ekiplerde 3D sanatçıları, modelleyiciler, texture, animatör ler olmak üzere genellikle 3 kola ayrılıyorken yurdum ekiplerinde 3D sanatçısı genellikle her üç kol ile de ilgilenir :) Konumuza dönersek,, Texture ler çoğunlukla bir dış imajdan (resimden) yaratılırlar. Yapımı tamamlanan bu imaj content browser dan UDK ya import edilir. Bazı texture ler ise UDK içinde dinamik olarak oluşturulur, örneğin render texture leri gibi.

UE, 4096 x 4096 pixel e kadar texture çözünürlüğünü destekler. UDK da texture ayarlamaları için bir çok ayarlama (settings) vardır. bu ayarlardan DeforCompression ayarı ile o an texture sıkıştırma yapmadan işlemlerde hız kazanabiliriz. Bu erteleme bir paket olarak UDK ya kaydedilene kadardır.

Texture ler UDK editörüne TGA veya BMP formatında imajlar olarak Content Browser panelinden import edilir.


Material
Ve ardından sıra bu texturelerden materyallerin üretilmesine geçer. Genellikle texture ler materialerde kullanılan imajlar olduğundan material yüzeyi üzerine konumlandırılarak (map edilerek) uygulanırlar. Materialler de daha sonra geometrik objelerin yüzeylerine uygulanır. Ancak UDK da HUD grafikleri denen ekrana çeşitli bilgileri anlık basmak için kullanılan texture ler vardırki burada materialler söz konusu olmadan sadece texture olarak doğrudan kullanılır.

Bir material bir den fazla texture den oluşabilir. Her biri farklı şekillerde uygulanmış olabilir ve farklı bir amaca hizmet edebilir. Ve bir den fazla texture bir alfa kanalı içinde birden fazla emissive, specular vs.. gibi değişik özelliği aynı anda barındırabilir. Sonuç olarak materialler yüzey görünümleri üzerinde doğrudan rol oynarlar. Material uygulanmış bir mesh e ışık çarptığında ışığın texture ile etkileşiminin nasıl olacağının tüm detaylarını material özellikleri belirler. Her bir yüzeyin ışık ile etkileşimi kullan ışık modeline göre (Lighting Model) değişiklik gösterebilir. Yani materialler ışık modellerini doğrudan kullanır ve onlarla birlikte çalışır. Materialler çok detaylı bir konudur. Başlı başına bir uzmanlık alanıdır bile diyebiliriz.


HUD - UI
Head up Display (HUD) grafikleri daha çok durum bilgisini ya da oyuncuya anlık olarak sunmak istediğimiz diğer gerekli bilgileri ekrana basar. Player durumu, skor, sağlık, kalan zaman, mermi sayısı, vs... HUD grafikleri çoğunlukla oyuncu ile etkileşime geçmezler sadece bilgiyi ekranda gösterirler. Yani oyuncu üzerlerine tıklayamaz. Bu yönleri ile tek yönlüdürler yani interaktif değillerdir.

UI (user interface) ler ise oyuncu ile etkileşime girerler. İnteraktifdirler. Genellikle oyun ekranının üzeirne bir katman penceresi olarak belirirler. Bazı durumlarda UI ler oyun atmosferinin bir parçası da olabilir. Yani UI render edilmekte olan oyun ekrnanının üzerinde belirir ve anlık olarak oyuna etki de edebilir. En bilinen UI örneği oyun ana menüleridir. Menüler oyunun en başında yada sonunda göründüğü gibi oyunun ortasında da görünebilir. Mesela oyun ortasında pause yada menü buttonuna basıldığında... Oyun durmadan da görünebilir buna da örnek olarak iki olabilir.

HUD sınıfının ekrana görüntü basmak için iki temel metodu vadır : CanvasDrawing ve ScaleFormGFX movies.

Canvas: Canvas sınıfı ekrana imaj ve text basar. Sadece ekranlara değil Scripted Textures vasıtası ile texture yüzeylerine de baskı yapabilir. Her bir zaman döngüsünde bir çizim için yeni bir canvas HUD a atanır.

Scaleform: flash ta build edilmiş hareketli grafiklerin HUD grafiği veya UI olarak kullanılmasıdır.



Static Mesh
Mesh, sahnedeki her bir şeklin x,y,z vertex noktalarının birleşimi ile 3D ortamda tanımlanması ile oluşan bir poligonlar setidir. Birbiri ile ilişkili (genellikle) üçgenlerin birleşik koleksiyonu ile ortaya çıkan şekil tanımıdır. 3D ci arkadaşların adına “tel kafes” dediği, çizgilerle oluşan bir ızgaradır. Mesh ler 3D modelleme uygulamalarında üretilir ve her bir şeklin temel yapısını teşkil eder. Daha sonra üzerine istenilen her şekilde texture veya material uygulanabilir. Mesh ler de UDK ya content browser dan import edilir.

UDK nın içinde basit modeller, ve basit yer yüzü yapmak için adına BSP brush denen fırçaları kullanabiliriz; ancak basit şekiller bile olsa doğrudan (3D uygulamadan import edilen) mesh kullanmak çok daha performanslıdır.

Static mesh ler Level içinde tanımlanacak olan bir kaç actor tipinde kullanılır. En çok bilineni StaticMeshActor dür. Bu sadece ortamdaki bir geometridir. Hareketli objeler yaratmak için InterpActor kullanılır. RigidBody fizik objesi yaratmak için ise KActor kullanılır.

Static Mesh leri detaylı görüntülemek ve bazı özelliklerini değitirmek için UDK da StaticMeshEditor kullanılır. Satic Mesh Editorde genel / yüzeysel özellikler değiştirilir. Ve basit collision / geometri özellikleri de yine buradan eklenebilir veya kaldırılabilir. Temelde mesh in geometrik şeklini UDK içinden değiştiremiyoruz. Ama scale ile bir miktar enine boyuna çekiştirebiliyoruz.

3D sanatçısı, level tasarımcısından aldığı leveldeki kaba objelerini gerçekleri ile değiştirirken tekrar eden yada çok benzeyen objeler için mümkün mertebede aynı mesh in kopyalarını kullanmalıdır. Bu oldukça hız kazandırır. Aynı durum materyaller içinde geçerlidir. Aynı materyal tipini bir den fazla kez kullanması yine hız / performans kazandıracaktır.

Tüm görsel içerikleri üretmek ve onları UDK editörüne import etmek 3D sanatçısının görevidir. tüm mesh ler 3DS MAX in ascii scene export (ase) fırmatı ile editöre import edilebilir. Tüm objeler import edilirken belli guruplar halinde paketlenmesi ve isimlendirmenin belli bir sistematik dahilinde düzenlenmesi oldukça gereklidir. Böylece sonradan aranan şey kolayca bulunabilir.



Collision
Kelime anlamı çarpışma olan collision, oyun ortamında mesh lerin birbirine temasının takibini yapar. Böylece fizik kuralları her bir temas anında hesaplanarak gerçek dünyadaki cisimlermiş gibi çarpışma etkileri verilebilir. Collision olmasa idi oyundaki bütün hareketli objeler birbirinin içinden geçerdi :) Collision ile static mesh lerin etrafında görünmez bir blok oluşur. Artık o blok içine başka bir cisim giremez.

Ancak pratikte sisteme fazla yüklenmemek için mesh ile tamamen aynı yapıda şekilde bire - bir collision yerine çok daha basit ve kaba şekilli (dikdörtgen prizması gibi) bir collision modeli kullanılır. Bu karmaşık işlemleri sadeleştirerek performansı artırır. Ne çok kaba ne de bire bir ölçek uygun olmayabilir,, işimizi görecek yeterlilikte minimum detaylandırılmış collision en uygunudur. Mümkün mertebede kaba ve düzgün hatlar tercih edilir.

Collision bilgisi 3D uygulama ortamında tanımlanabilir. Ve Mesh ile birlikte UDK ya import edilebilir. Static Mesh Editor de Collision geometrisi eklemek için bazı araçlara sahiptir ancak, buradaki araçlar 3D programlara göre daha az esnektir; yinede belli koşullarda gayet içi çalışırlar.



Physical Assets (fiziksel varlıklar)
Bir static mesh import edildiğinde basitleştirilmiş bir collision a sahip olur. Ancak henüz bildiğimiz fizik kurallarına tabii değildir; örneğin yer çekimi gibi. Eğer onu fizik kurallarına uygun bir obje haline getirmek istersek RigidBody özelliği atamalıyız.



Skeletal Mehs (iskelet sistemi)
İskelet sistemidir. Anime edilebilen mesh lerin temelinde o vardır. Burada söz konusu animasyonlar mesh lerin iskelet yapılarındaki hareket edebilen eklem noktalarına uygulanır. Böylece kontrol edilebilir bir kemik sistemi sağlanmış da olur. Bu kontroller Skeletal Controllers tarafından sağlanır. skeletal mesh de yine 3D uygulamaları ile detaylı olarak ayarlanabilir ve content browser dan UDK ya import edilebilir.

Skeletal Mesh ler tipik olarak karakterlerde yaygın olarak kullanılır. Silahlar, ara. gereçler, araba uçak vs... yada translation ve rotation un yetmediği animasyon tanımlarında skeletal sistemler kullanılır. Kemik noktaları bir kez verildiğinde artık her biri kendi fiziğine sahip objeler koleksiyonu gibidir. Bu özellikleri tanımlamak için PhAT fizik editör kullanılır. Karakter animasyonları gibi karmaşık animasyon işleri için ise Animation Set Editör, ve Animation Tree Editor kullanılır. Burada Anim Tree leri, skeletal kontrolleri, ve hareket hedefleri tanımlanır.

Peki Skeletal Kontrolleri nelerdir ?

a - Morph Targets:
skeletal mesh leri real-time hareket ettirmenin bir başka yoludur. Ancak morph targets lar kemik hareketlerinden çok daha fazla hareket kontrolü imkanı sağlarlar. Burada şeklin yüzeyindeki vertices (vertex) köşe noktalarının yeri kontrollü olarak değiştirilerek öncekine yakın ama daha farklı dönüşüm animasyonları oluşur. Konuşan yüz şekli gibi. Morph Targets animasyonları aynı zamanda hasarlı şekil görüntüleri olulturmak için de kullanılabilir. Carmageddon oyunundaki hasarlanma ve tamir olma animayonu gibi.

b - Sokets:
socket ler bir skeletal mesh in kemik büküm noktasına ataçlanan objelerdir. temelde iki amacı vardır; ilki herhangi bir mesh i, bir skeletal mesh e monte etmede kullanılır. Yada patlama / parçalanma effectleri için de kullanılabilir. Bu tür şeyler Anim Set Editör içinde ya da programlama kodları içinden tanımlanır.



Light (ışık)
UDK içindeki nerede ise tüm objeler nasıl statik ve dinamik olarak ikiye ayrılıyorsa; aynısı ışıklandırma içinde geçerlidir : Statik ışıklar (static lights) ve Dinamik ışıklar (dynamic lights).

Statik ışıklandırma önceden hesaplanmış / derlenmiş bir ışık haritası (LightMap) kullanır. Çok performanslıdır. Fakat statik ışıklandırma haritası hafızada çok yer kaplar. ve ışık kalitesi arttıkça da LigtMap in hafızada kapladığı alan da artar. Bu konuda bilinmesi gereken en önemli şey statik ışıkların sahnedeki dinamik objelerden (karakterler ve fizik -rigidbody- objeleri vs.. ) bağımsız olarak ortamı aydınlattığıdır. Statik ışıklar daha çok ortam ışıklandırmasını renklendirmek / çeşitlendirmek için kullanılır. UDK ortamında klavyeden L tuşu basılı tutularak sağ mouse menüsünden add diyerek kısa yoldan sahneye bir tanesi eklenebilir. Elbette statik ışık kaynaklarından kaynaklanan gölgeler de sabittir. Çünkü LightMap de kendileri hesaplanırken gölgeleri de o an hesaplanır. UDK da default tipi statiktir.

Sahnedeki herhangi bir ışığın neleri aydınlatacağına gözatabilir ve hatta seçebiliriz. Işığa sağ tıklar ve menüden “see what tihs light affects” seçeneğine tıklarsak önümüze üç farklı seçenek çıkacaktır :

• Only Dynamic Objects

• Only Static Objects

• Both Dynamic and Static Objects

Dinamik objeleri aydınlatmasını söylediğimiz ışık artık dinamik ışıktır. Karakterler, movers objeleri ve fizik objeleri zaten default olarak “Dynamic Lighting Channel Set” olarak ayarlıdır. Yani tüm dinamik objeler dinamik ışıklardan etkilenirler. Dinamik ışıklandırma staticten farklı olarak realtime olarak yani anlık olarak sürekli bir döngü ile hesaplanır. Pek bir bellek tüketimi olmaz. Dinamik ışıklandırmada ön hesaplama / derleme de gerekmez. Ancak çok fazla işlemci tüketimi ve extra render süresi söz konusudur. O yüzden dinamik ışıkları kullanırken biraz dikkatli ve tutumlu olmak gerekir. Hele ki Both Dynamic and Static olarak ayarlanmış ise ortamdaki her objeyi ışık yönünden etkileyecek demektir. bu da çok fazla işlem gücüdür. Ortamdaki herşeyi etkileyecek olan başlıca ışık gün ışığı olduğundan UDK da da sadece Directional Ligth tipi bu şekilde default ayarlı olarak gelir. Ve gün ışığını simüle eder.

Temel ışık tipleri şöyledir :

• Point Linght
• Spot Light
• Directional Light
• Sky Light

Sky Light
Ortam ambians ışığıdır. Gökyüzünden kaynaklanan ve her tarafa eşityayılan ıgün ışığını sembolize /simüle eder. Sistem kaynaklarını ekonomik kullanır. Yüksek performanslıdır.

Sahnedeki ışıklar ve onlar için seçtiğimiz ışıklandırma tipi projemizin gereksinimlerini doğrudan etkiler. Hatta ışıklandırma, UDK içindeki sistem kaynaklarını en çok sömüren ve performansı etkileyen konudur. O yüzden ışıklandırmada optimizasyon ve performans ayarları çok önemlidir.

Işıklar da birer sınıf tipi ve nihayetinde sahneye konumlandırılabilen ve örneklenerek çoğaltılabilen bu objeler de UDK nın actor class larıdırlar. Her ışık tpinde ortak olan genel özellikler olduğu gibi kendi tipine özel özellikleri de vardır.


LightMass
Lightmass özelliği yüzeyleri kaplayan renklerin aydınlatmadan (ışıklardan) etkileneceği durumlarda enable edilen bir özelliktir. Benzer şekilde eğer materialin içinde ışık yayan bir emmisive component var ise yayılan ışık miktarının hesaplanması içinde bu özellik açılır. LightMass karmaşık ışık etkileşimleri için bir LightMap ön derlemesi yaratır.

UDK editörünün içinden stat memory komutu ile birlikte memori istatistikleri görünebilir. Yani her bir varlığın hafızada ne kadar yer tükettiği bilgisi / istatistikleri. stat d3dscenekomutu da render da kullanılan üçgenler sayısı, render süresi, vs bilgileri için istatistikleri verir.



Shadows
UDK da farklı gölge tipi mevcuttur :

Shadow Volumes: Genel gölge çözümüdür. %100 dinamik ve gerçek özelliklere yakın gölgelendirme yapılır. Köşe kenarlarda yoğunlaşmalar dahi olur. Konsollarda bu özellik default olarak kapalıdır çünkü hafızayı çok tüketir.

ShadowBuffers: Daha da dinamiktir; çok şık ve yumuşak kenarlı gölgeler oluşur. ShadowBuffers da dinamik geometriler ve hatta karakterler dahi gölgelendirmeye maruz kalır.

Precomputed Shadows : Static ışıkların aydınlattığı static geometriler (BSP primat şekilleri ve statik mesh ler) de uygulanabilir. Statiktir. Ön derleme gerektirir. Ve bu gölgelendirme bir ShadowMap olarak çıktı alınabilir ve kaydedilebilir.

bu üç gölgelendirme tipinin hepsi de aynı sahne (scene) içinde birlikte uygulanabilir. Belli ışık tipleri ve belli gölgeler aynı anda bir araya gelirse çok esnek bir görsellik oluşabilir.



Camera
Oyuncunun ekrana doğru baktığı yöne bir ViewPort denir. Bu daha teknik bir tabirle PlayerViewPort tur. Başka görüş açıları dolayısı ile başka viewport lar da olabilir. FPS oyunlarında (quake, half life vs..) sürekli render edilen PlayerViewPort ile aynı yöne bakan ve player ile birlikte hareket eden bir kamera vardır. Böylece oyunu kendi gözümüzden görür gibi oynarız. Dolayısı ile kameranın görüntüsü için genel anlamda render edilen bir viewport tur diyebiliriz. Kamera sınıfının özellikleri arasında da de viewport un başlıca özellikleri olan location (konum), ve rotation (yön) bilgileri vardır.

UDK da custom (özel) kamera tipi kullanılarak ya da tamamıyla özel bir kamera sistemi yaratılara değişik viewport tipleri yaratılabilir. FPS oyunlarındaki viewport larda default viewport olarak oyuncunun gözü olduğundan oyunncu kendisini göremez :) Ama custom kamera sınıfı kullanırsak bu viewport u kolayca değiştirebiliriz. Yani kameranın lokasyon bilgilerinin değiştirerek onu oyuncudan uzaklaştırabiliriz. Bölyece oyuncu karakterini oyun içinde görebilir.

Bilinen bazı temel viewport tipleri vardır : top-down, side-scrolling, isometric perspective (örneğin diblo vs..), gibi bilinen bazı viewport tipleri oyunlarda yaygın olarak kullanılır. Ama dediğim gibi oyun içinde kendi özel viewport tipimizi yaratabiliriz.



Particle Systems
bir partice sisitemi bir dizi emitter den oluşur. Emitter kaba bir tabirle fışkıran yapı demektir. Particle sistemi daha çok ateş, patlama, enerji hüzmesi, ışık hüzmesi / patlaması, vs.. effecktleri vermek için kullanılır. Emitter objesi parçacıkları yaratır ve fışkırtır. Her bir emitter tek tip parçayı yada TypeData yı fırşkırtır (emit eder), yayar. Yaratmaya çalıştığımız effect tipine göre bir kaç farklı emitter tipi vardır:

Sprite: default emitter tipidir. özellikle belirtmeye dolayısı ile gerek yoktur. emitter default olarak zaten sprite (yama) dır. Emitter den fışkıran he bir particle, emitter in uygulandığı materyale uygulanan bir sprite (yama) şeklinde olur. Srpite emitter tipi kameranın nasıl konumlandığına aldırış etmez. Nerede olursa olsun aynı görüntüyü verir. Sprite emitter leri daha çok volumetrik (alansal) effectlerde kullanılır; örneğin duman, ateş, kar, yağmur, hava, toz, flare, kıvılcım, vs....

Mesh Emitter: çoğunlukla bir patlama sonucu etrafa dağılan küçük parçacıklar, hurdalar, kıymıklar, yaratmak için kullanılır. Bu küçük parçalar için de 3D objesi gibi static mesh ler kullanılır. Ör: md da adam ateş edince çıkan üçgen parçacıklar...

Anim Trail: daha çok bir skeletal mesh in hareketini daha belirgin hale getirmek için kullanılır. Örneğin bir kılıç savurma effecti gibi..

Beam: bir kaynak ile hedef lokasyonu arasında hüzme neon yansıması uygulanır. enerji silahları büyü gibi bir görsellik sunabilen parçacık effectidir.

Ribbon: bu tipteki emitter birbirine uc uca bağlı parçacıklar yayar. şerit, kurdela, spiral gibi bir effect oluşur. Quake deki rail gun silahı ateşi görüntüsü gibi..

PhysX: bu emitter tipi de tıpkı sprite veya mesh emitter tipi gibi davranabilir. ama parçacıkları akışkan fiziği tarafından kontrol edilir.

Modules: bu particle tipinde her bir parçacığın nasıl davranacağına ve görselliğine biz karar veririz. Ekranda ne kadar kalacak? Nerede spawn olacak? hareketin yönü ve hızı? particle in genişliği, rengi? rotate dönüşüm yönü ve hızı? collision a sahip olup olmaması vs...



Post Process Effects
Post Process Effect leri render edilmiş sahneye uygulanır. Full ekran effectlerdir. Bu effect ler her biri farklı bir effect i yerine getiren farklı modüller tarafından yaratılır. Bazen bir modülün bir den fazla effecti yerine getirdiği de olur. Performans verimliliğine göre uygun tercih yapılır. Bloom, Blur, Depth of Field (DOF), MotionBlur, Material Effects, Ambient Occulusion, Anti-Aliasing, Color Granding, ... gibi türleri vardır.

Post Process Effect leri content browser da yaratılır, Post Process Editor de edit edilir. Bu eidtör de yine Node / Sembol tabanlı bir editördür. Burada türlü effect modülü eklenebilir ve istediğimiz şekilde düzenlenebilir. Bazı Post Process Tipleri :

Bloom: bir tür glow effectidir. çok parlak objelere bakarken meydana gelir. özellikle bu objeler kendilerine oranla daha karanlık bir yüzeyde duruyorlar iseetkisi daha yoğun hissedilir. Işıktan ortama bir Glow luk gibi bir görsellik gelir. Bloom effecti PostProcessEffect modülünün bir parçasıdır.

Depth of Field (DOF): kamera odağındaki keskinlik düşüşlerini simüle eder. Yakın objelerin keskin, uzaklaşan objelerin blurlanmış görünmelerini sağlar. bu görüntüye gerçekçilik katar. Bu zaten normal film veya fotoraflarda böyledir. DOF post process effecti UberPostProcessEffect modülünde bulunur.

Material Effects: material effectleri ile material sistemini kullanarak, materyal özelliklerindeki değişiklikler / işlemler yaparak, render edilmiş sahneye etki eder. Material sistem sahne texture lerine ve sahne derinliğine etki edebilir. Bu da bize pek çok özel effentin yolunu açar. Sahnede ÇOKLU material effectleri aynı post process zinciri içinde uygulanabilir.


Motion Blur: sahnedeki çok hızlı hareket eden objlerin blur görünmesini sağlar, çünkü kamera frame sayısı az olduğunda bu hız sorun yaratabilir. Motion Blur insan gözünün algılayabileceği kusurları örter.


Ambient Occulusion: bazı bölgelerdeki ışık şiddetini azaltarak derinlik ve gerçekçilik hissi verir. Özellikle köşeler gibi büküm noktalarında ışık normalden fazla azaltılarak derinlik hissi sağlanır. Ambient Occlusion mantık olarak ortam ışığından (ambient) sahnedeki tüm nesnelerin aynı oranda etkilenmediği düşüncesinden hareket eder. Aydınlatılan yüzeylerin hangi oranlarda ışık alabileceğini ayırt etmeye / hesaplamaya çalışır. Bu effect sahne karmaşıklığından etkilenmez. Ancak standartların üzerinde kullanıldığında görüntü kalitesini kurban eder. Yani her zaman istenen durum olmayabilir. Fazla kullanılırsa görüntüyü bozabilir. Ve işlem yükü de bindirir. bu effect UberPostProcessEffect modülünde bulunur.

Color Granding: renk düzenleme effectidir. Sahneyi belli bir renkle filitrelendirir. (eşkiya filminin sarı teması gibi). sahnedeki ışıklandırma da bundan nasibini alır.



Audio - sound (ses)
ses dosyaları da yine content browser dan “Sound Waves” tip adını alarak eklenirler. Bu, UDK ya eklenmiş, istersen kullanılabilir; ama henüz tam anlamı işlenmemiş ses demektir. Bunların hangi durumda nasıl davranacakları vs bilgisi / operasyonları işlenerek birer “Sound Cues” haline getirilirler. SoundWave ler temel (base) varlık (asset) tipidir.



Game Type (oyun tipi)
GameType, oyunun genelini kapsayan genel kurallar, şartlar, süreci belirleyen yapıdır. Yani oyunun alt yapısıdır. Oyun tipi GameInfo sınıfı tarafından kontrol altındadır. Bu sınıftan üretilen her sub class bir GameType i dir. Bir oyun bir den çok GameType a sahip olabilir. Her birinin farklı kuralları ve hedefleri olabilir. Ancak real-time da sadece bir tanesi yürürlüktedir. Yani bir Level boyunca bir GameInfo class tipi (aktörü) aktif kalır.


GameInfo sınıfı,

• oyuncunun başlarken nerede belireceğine (spawn olacağına) karar verir.
• oyuncunun oyun içinde elde ettiği itemlerin envanterini tutar.
• zaman limitlerini ayarlar.
• scor ve ölümlerin kaydını tutar.
• gerekirse Level i resetler, sıfırlar.
• oyun bitiş şartlarını tanımlar.
• oyuncuyu oluşturmak, hazırlamak için hangi actor class ların kullanılacağına ve bu sınıflarında neleri kullanacağına karar verir.
• hangi HUD class ların kullanılacağına karar verir.

vs...


GameInfo oyunun kendisini ifade eden temel sınıftır. UDK için uygulama geliştirirken genellikle oyunun kendisini ifade eden sınıf yaratmamız gerekir. İşte bu sınıfı yaratırken GameInfo sınıfını miras alarak kendi oyun nesnemizi tanımlıyoruz.



Player
bir player objesi kendisi ile birlikte çalışan bir kaç sistemden meydana gelir. Bu diğer sistemler onun görünümüne ve nasıl davranacağına karar verir. Dahası player in dış dünya ile etkileşimini belirler. Oynayan kişinim input girdilerinin oyunda nasıl yorumlanacağına da yine Player nesnesi ile ilişkili olan Controller nesnesi karar verir. Controller oyundaki bir varlığın beynidir. Onun nasıl davranacağına controller karar verir. Ama oyuncu için ise daha özel bir controller vardır o da : PlayerController. Bu nesne oyuncudan aldığı inputları oyuna yansıtır ve oyunun, oyundaki bazı varlıkların belli bazı axiyonlarına çevirir.



Actor
UDK da belli bir niteliği, işlevi teşkil eden özelliklerin tamamı Actor base sınıfından türetilmiş daha üst düzey sınıflardır. Kısaca UDK editöründe gördüğümüz hemen her ikon bir actor sınıfıdır. Sahnedeki 3D objeler hariç herşey.  Dolayısı ile yukarıda bahsettiğimiz herşey de birer actor sınıfıdır. Tam listeyi görmek için content bworser in hemen yan tarafındaki Actor Classes tabına geçebiliriz. Buradan istediğimizi seçerek ortama ekleyebiliriz.




UDK editöründe sahnede herhangi bir actor ün üstüne çift tıklayarak ya da actor seçili iken f4 tuşuna basarak o actor ün özelliklerini içeren pencereye erişilir.



Inputs
PlayerController sınıfı oyuncu girdilerini oyun içindeki aksiyonlara çevirir. inputları ilk yakalayan PlayerInput sınıfıdır. Bu sınıf klavye, mouse, gamepad, joistik vs.. girdilerini alarak veriye dönüştürür. Bu input verileri kamera sistemi ve oyuncunun viewport u ile yakından ilişkilidir. Çünkü farklı perspective açılarında onynanış da farklı input yöntemleri gerektirmektedir. Viewport karmaşıklaştıkça input sistemi de karmaşıklaşabilir. Kamera ve PlayerController sistemleri farklı sistemler olsa da birbirlerine etkileri söz konusudur. Çünkü kamera perspectifini yani oyunun viewport unu değiştirdiğinizde çok yüksek bir olasılıkla playeri kontrol ediş input sistemini de güncellememiz gerekebilir.



PlayerController
oyuncunun kendisini temsil eden sınıftır. Oyuncunun tüm girdileri ve hareketlerin yerine getirilmesinden sorumludur. PlayerControler in işlemleri ekran arkası gerçekleşen olaylar dizisidir. İşin görsel ifadesinden Pawn sınıfı sorumludur. Buradaki görsel ifade dediğim, ekrandaki karakterlerin PlayerController sınıfının olaylarına göre hareketlerinin oluşturulmasıdır. Yani PlayerController sınıfı inputları ve hareket olaylarını işler

Pawn
Oyuncunun ya da oyundaki herhangi bir varlığın bedeninin temsilcisidir (görsel temsilcisi). Pawn, Conroller dan komut alır. bu talimatları animasyonlar, hasar oluşumları (damage) ve diğer handle edilmiş oyuncu atraksyonları şeklinde oyun görsel atmosferine yansıtır.




UDK KISMET
Bir level içindeki tüm oyundavranışlarını kod yazmadan görsel (şematik) bir ortamda oluşturmamızı sağlar. Level tasarımcıları level içindeki tüm script lerden de sorumludur. Belli görevlerin yerine getirilmesi, belli kuralların tanımı, belli bir zaman içinde değişik eventlerin ve particle effect lerin (duman ateş, yağmur vs..) tetiklenmesi, bir objenin bir durumda belli bir şekilde davranması, kısaca bir gamelogic inin oluşması için level tasarımcıları UDK kısmet editörünü kullanır.

Kısmette simgesel objeler belli bir akış içinde istenen durum ve özelliklerine göre birbirine bağlanır. Her bir simgesel objenin temsil ettiği bir özellik veya bir amaç vardır. Bu akış (sequence) objeleri temel olarak 4 tiptir :

Actions: Level içindeki actor lerin çeşitli aksiyonlarını yerine getirir.

Condition: Akış içindeki bazı mantıksal kontrol ifadeleri olarak yer alır. Bir şarta (condition) bağlı olarak hangi çıktının tetikleneceğine karar verir.

Events: Akış içinde bir input girdisi yaratır ve bu girdi oyundaki bir actor den gelecek şekilde ayarlanır. Böylece actor ün belli bir olayla işletilecek script blogu tanımlanabilir. En bilinen event (olay) Level Loaded olayıdır. Level in başında tanımlanacak olan işlemler için kullanılır.

Variables: Değişik veri tiplerindeki bilgiyi tutmak için kullanılır. Eventlar tarafından kullanılan tiplerin tümünü tutabilir.



UDK MATINEE
Level içinde görünen hareketli animasyonların tamamı burada tanımlanır. Mantık yine belli bir zaman içinde bir objenin iki anahtar kare (frame) arasındaki hareketsel değişimidir. Matine editörü içinde fazla sayıda actor ler gruplaştırılarak da anmasyonlar tanımlanabilir. Her bir grup her hangi bir sayıda track içerebilir. Matine ile yaratılan animasyon örneklerinden en yaygını şu ünlü yakınlaşınca açılan asansör kapısıdır. Ama dediğim gibi bir actor ün belli bir komutla yaptığı hazır hareketlerin tamamı animasyondur ve udk matine editörü içinde tanımlanır. Tek püf noktası hareket edebilen actor ler UDK nın InterpActor actor tipine çevrilmiş olması gerekir. Yoksa kımıldamaz. Son olarak matinee içinde Cinamtic Sequence ler de kullanılabilir. Yani matinee ile bunları da oyun içinde real time oynatabiliriz.


Evet, oyun konusunda sıkça karşılaştığımız bazı terimleri kısa kıasa açıklamaya çalışık. Özellikle yeni başlayanlar için faydalı olabileceğini düşündüğüm için bir yazı olarak paylaşmak istedim.
bir başka yazıda görüşmek üzere hoşçakalın.