Anında GUI - yae veya nay? [kapalı]

Birkaç yıl önce MFC, QT, Formlar, SWING ve birkaç web-GUI çerçevesi gibi birçok "tutulan" GUI sistemi (bununla ne kastettiğim hakkında daha fazlası) ile uygulama geliştirme üzerine çalışıyorum. Her zaman çoğu GUI sisteminin konseptini aşırı karmaşık ve sakar buldum. Geri arama olaylarının, dinleyicilerin, veri kopyalarının, bir şeye bağlanacak bir şeyin - dönüşümler (ve benzeri), uygulamadaki diğer bölümlere kıyasla her zaman bir hata ve baş ağrısı kaynağıydı. (Veri Bağlamalarının / Modellerinin "uygun" kullanımı ile bile).

Şimdi bilgisayar oyunları yazıyorum :). Şimdiye kadar bir GUI ile çalıştım: Miyagi (tanınmayan, ancak temelde diğer tüm sistemler ile aynı fikir).

O korkunçtu.

Oyunlar gibi gerçek zamanlı görüntü oluşturma ortamları için, GUI sistemlerinin "korunmuş" olduklarını daha da eski hissettiriyorum. Kullanıcı arabirimlerinin genellikle otomatik olarak düzenlenmesi veya anında yeniden boyutlandırılabilir pencereleri olması gerekmez. Bunun yerine, sürekli değişen verilerle (dünyadaki modellerin 3d konumları gibi) çok verimli bir şekilde etkileşime girmeleri gerekiyor.

Birkaç yıl önce, temelde bir Hemen Grafik moduna benzeyen, ancak kullanıcı arayüzleri için olan "IMGUI" üzerine rastladım. Çok fazla dikkat etmedim, çünkü uygulama geliştirme aşamasındaydım ve IMGUI sahnesinin kendisi gerçekten geniş ya da başarılı görünmüyordu. Yine de aldıkları yaklaşım son derece seksi ve zarif görünüyor, ki bu UI yöntemini kullanarak bir sonraki proje için bir şeyler yazmak istememi sağladı (işteki birini ikna edemedim: (...)

"tutulan" ve "hemen" ile ne demek istediğimi özetleyeyim:

Atanan GUI: Ayrı bir başlatma aşamasında, Etiketler, Düğmeler, Metin Kutuları vb. Gibi "GUI kontrolleri" yaratır ve bunları ekrana yerleştirmek için açıklayıcı (veya programatik) bir yol kullanırsınız - hepsi bir şey yapılmadan önce. Kontroller kendi durumlarının çoğunu X, Y konumu, büyüklüğü, sınırları, alt kontrolleri, etiket metni, resimler vb. Bellekte tutar. Olaylardan haberdar olmak ve GUI kontrolündeki verileri güncellemek için geri aramalar ve dinleyiciler ekleyebilirsiniz.

Anında GUI: GUI kitaplığı, tek seferlik "RenderButton", "RenderLabel", "RenderTextBox" ... işlevlerinden oluşur (düzenleme: Render ile karıştırılmaması)önek. Bu işlevler aynı zamanda "hemen" bir denetim yapmak için çağırabileceğiniz sorgulama kullanıcı girişi, karakter ekleme, karakter ekleme, karakter tekrar hızını kullanma gibi kontrollerin arkasındaki mantığı da kullanır. Derhal GPU’ya yazılmalıdır: Genellikle mevcut çerçeve için hatırlanır ve daha sonra uygun gruplar halinde sıralanır). Kütüphanede bunlar için herhangi bir "devlet" yoktur. Bir düğmeyi gizlemek istiyorsanız ... sadece RenderButton işlevini çağırmayın. Bir düğme veya onay kutusu gibi kullanıcı etkileşimi olan tüm RenderXXX işlevleri, örneğin kullanıcının düğmeyi tıklattığını belirten değerlere sahiptir. Demek "RenderGUI" işlev, oyun durumunuza bağlı olarak RenderXXX işlevlerinizi aradığınız veya aramamanız durumunda büyük bir if / else işlevi gibi görünür ve tüm veri güncelleme mantığı (bir düğmeye basıldığında) akış içine karıştırılır. Tüm veri depolaması GUI'nin "dışında" ve istek üzerine Render fonksiyonlarına aktarılmıştır. (Tabii ki, büyük fonksiyonları birkaç taneye bölersiniz ya da kullanıcı arayüzünün bölümlerini gruplamak için bazı sınıf soyutlamaları kullanırsınız. Artık 1980'deki gibi kod yazmıyoruz, değil mi?)

Şimdi Unity3D'nin aslında kendi GUI sistemlerinde aynı temel yaklaşımı kullandığını gördüm. Muhtemelen bu yaklaşımla birlikte bir kaç GUI vardır.

Yine de .. Etrafa bakarken, tutulan GUI sistemlerine karşı güçlü bir önyargı var gibi görünüyor? En azından Unity3D dışında bu yaklaşımı bulamadım ve orijinal IMGUI topluluğu oldukça sessiz görünüyor.

Yani, her iki fikirde de çalışan ve güçlü bir görüşü olan var mı?

Düzenleme: En çok gerçek dünya deneyiminden kaynaklanan görüşlerle ilgileniyorum. IMGUI forumunda, anlık GUI yaklaşımının herhangi bir "teorik zayıflığı" hakkında çok fazla ateşli tartışmalar olduğunu düşünüyorum, ancak her zaman gerçek dünyadaki zayıflıklar hakkında bilmek daha aydınlatıcı buluyorum .

Hayır. Ücretli gamedev'i korkunç bir 'tutulan mod' GUI'sinde ve korkunç bir 'anında modun' GUI'sinde yaptım ve her ikisi de beni gözlerimi yırtmak istememe rağmen, tutulan mod yaklaşımı hala daha iyi.

Acil modun olumsuz yönleri çoktur:

• sanatçılar ve tasarımcıların düzeni yapılandırmasını kolaylaştırmazlar;
• mantığı sunumla karıştırırlar;
• tek bir tutarlı girdi modeline sahip olmayı zorlaştırır;
• dinamik verilerin karmaşık kontrollerini önermezler (örneğin liste görünümleri);
• Katmanlama çok garipleşir (örneğin, RenderComboBox'u çağırırsam, açılır kutu henüz işleyemez çünkü pencerenin geri kalanının üstüne çıkması gerekir - araç ipuçları için aynıdır) l
• oluşturma stilinin yapılandırılması, globals (ick) veya ekstra fonksiyon argümanları (ick) ile yapılır;
• Tüm bu işlevleri, değişmiş olabilecek veya değişmemiş değerleri sorgulamaya çağırmak, bellek yöneticisini vurgulayarak birçok küçük nesne oluşturma eğiliminde olduğundan performans düşük olabilir;
• ... birisinin GUI'yi bir yere sürüklemesine izin vermek ve onları yeniden sıralamak için ne kadar acı verici olacağını hayal bile edemiyorum. Her şeyi nerede yapacağınızı söyleyen bir veri yapısını korumanız gerekir - ki bu tutulan mod sistemini kendiniz yeniden yazmak gibi.

Acil durum modu GUI'leri hızlı bir HUD sistemi isteyen yalnız programcılar için caziptir ve bu amaçla mükemmeldirler. Başka bir şey için ... sadece hayır de.

IMGUI ile masaüstünde beş veya altı yıllık gerçek deneyimi olan biri olarak, savunmak zorunda olduğumu hissediyorum. Tüm cevaplar (ve sorunun kendisi) IMGUI'nin çok kısıtlı bir tanımına dayanmaktadır ve pek çok şüpheli iddiada bulunulduğu görülüyor.

Birçoğu, bir IMGUI kütüphanesinin, başlık altındaki verileri tutamayacağı varsayımından kaynaklanmaktadır. Bu hiç doğru değil. Gelişmiş bir IMGUI kütüphanesi aslında eşdeğer bir RMGUI kütüphanesi kadar veriyi saklayacaktır. Aradaki fark, bir IMGUI kütüphanesinin çoğunlukla sonuçları önbelleğe almasıdır, oysa bir RMGUI kütüphanesi yetkili durumunu korur. IMGUI'de, uygulama geçerli model durumunu alan ve bu durum için bir GUI üreten bir işlev sağlar. Bu GUI'nin yetkili tanımıdır. Kütüphane, ekran GUI'sinin bu fonksiyonun sonucuyla eşleştiğinden emin olmaktan sorumludur. Bu, her bir kareyi bu işlevi tam olarak değerlendirmek ve GUI'yi tamamen yeniden kurmak zorunda olduğu anlamına gelmez. Önbellekleme noktası budur.

IMGUI'nin bu bakış açısıyla, aslında gelişmiş bir düzen yapabilirsiniz ve performans oldukça makul. Arabirimi daha kolay hale getirirse gerçek yetkili durumunu da koruyabilirsiniz. IMGUI'nin amacı, uygulamanın her şeyi elinde bulundurmasını sağlamak değildir. Uygulama muhtemelen her kaydırma çubuğunun konumunu ve her ağaç düğümünün genişletilmiş / daraltılmış durumunu saklamak zorunda kalmak istemez. Mesele şu ki, bu ağaç düğümlerinin içeriğini ve bunların varlığını usule göre belirleyebilmek.

Tüm IMGUI eleştirilerini noktalarına değinerek yanıtlardım, ama pek çoğunu anlamıyorum. Birçoğu IMGUI'nin haksız olduğu ve RMGUI'nin iyi yapılandırıldığı temel bir inançtan kaynaklanıyor gibi görünüyor, sanırım yukarıdaki yanlış anlaşılmalardan kaynaklanıyor. IMGUI kütüphanelerinin karmaşıklıkla ilgili sorun yaşamaması ya da küreselle karıştırılması veya sunumla mantığı karıştırması gerektiğinin doğal bir nedeni yoktur. IMGUI'nin avantajlarının, içeriğinizin sanatçıya yönelik daha fazla önem kazandığını söyleyeceğim, ancak sanatçıların yönlendirdiği içerik için neden daha kötü olacağından emin değilim. (Renkler, yazı tipi / kenarlık boyutları vb. Şeyler için stil sayfalarının yanı sıra sanatçı odaklı içeriği kullanmıyorum, ancak uygulamanın neden RMGUI'dan daha zor olacağını anlamıyorum.)

Aklımda, IMGUI tartışmasız iyi bir şey. GUI'niz hakkında muhakeme için size çok daha iyi bir model verir. Çok daha işlevsel ve reaktif hale gelir ve neden olmak zorunda olduğunuz değişken durum miktarını en aza indirirsiniz. Öte yandan, sofistike bir IMGUI kütüphanesini uygulamak oldukça zor ve kesinlikle eşdeğer bir RMGUI kütüphanesi uygulamaktan daha zor. Kütüphane karmaşıklığı ile uygulama karmaşıklığı arasındaki bir fark. Karmaşık uygulamalar (veya çok sayıda basit uygulama) oluşturmayı planlıyorsanız, tradeoff çok iyi. Bunu tek bir uygulama için yapıyorsanız ve oldukça basitse, muhtemelen hedefinize daha hızlı bir şekilde RMGUI ile ulaşırsınız.

Her durumda, iyi şanslar!

GUI kütüphanesi bir kerede "RenderButton", "RenderLabel", "RenderTextBox" ... fonksiyonlarını "hemen" kontrol etmek için çağırabileceğiniz (GPU'ya hemen yazılması gerekmeyen) fonksiyonlardan oluşur. mevcut çerçeve için ve daha sonra uygun gruplar halinde sıralanmış).

Bunun bir GUI kütüphanesi oluşturmadığını söyleyecek kadar ileri giderdim. Bu sadece bir sürü oluşturma işlevi.

GUI oluşturma, GUI yapmanın en kolay kısmıdır. Örneğin bir metin kutusu alın. Mümkün olan en kolay durumu kabul edeceğim: basit bir tek satırlık giriş metin kutusu.

RenderTextBoxsadece bir metin kutusu çizer. Bazı basit metin ölçümleri yapar ve ekrandaki glifleri çizer. O will not

• Kullanıcının kontrolün üzerindeki fareyi tıklattığını tespit edin ve imleci dizideki uygun konuma getirin.
• Kullanıcının kontrol panelinde fareyi çift tıklattığını ve bir metin bloğu seçtiğini tespit edin.
• Kullanıcının "Giriş" tuşuna bastığını tespit edin ve imleci metnin önüne getirin.
• Kullanıcının geçerli bir tuşa bastığını algıla ve dizeyi buna göre değiştir. Metin seçilmişse, seçilen kısım eklenen metin ile değiştirilecektir.

Devam edebilirim, ama bence amacım açık. RenderTextBoxBir metin kutusu çizmek için kullanmak istiyorsanız, alacağınız tek şey statik, işlevsel olmayan bir metin kutusudur. Gerçek işlevler sizin tarafınızdan uygulanmalıdır.

Metin ölçümü yapmak ve glif çizimi yapmak? GUI çalışmasının kolay kısmı budur . GUI, "Grafik Kullanıcı Arayüzü" anlamına gelir. Kullanıcıdan girdi aldığınız ve onunla bir şeyler yaptığınız son iki kelime zor kısımdır.

Oyun oyuncuları GUI kontrollerinin makul şekilde çalışmasını bekler. PC tarzı bir ortamda (yani: fare ve klavye), oyuncular bir metin kutusu görürse, normal bir metin kutusu gibi çalışmasını beklerler. Ok tuşları ile hareket edebilmeyi, öne atlayıp eve bırakıp silme, içindeki harfleri seçmeyi vb.

Bu, tüm bu UI kodunu uygulamak zorunda kalacağınız anlamına gelir. Hangi kontrolün tıklandığını test etmek zorundasınız. Daha sonra hangi kontrolün tıklandığını temel alarak bir şeyler yapmalısınız. Klavye girişi yapan bir "aktif" kontrol kavramına sahip olmalısınız. Farklı kontroller, farklı kullanıcı etkileşimi türlerine farklı tepkiler vermelidir.

Temel olarak, bir TextBoxWindowsınıfa ihtiyacınız olacak .

Bir oyun seçenekleri ekranı uyguladığınızı varsayalım. Böylece farklı seçenek gruplarınız var: oyun, grafik, ses, kontroller, vs. Ekranın sol tarafında farklı grupların bir listesi var. Her grup, kullanıcının değiştirebileceği bir dizi kontrol getirir. Kullanıcı Sekme tuşuna bastığında ne olur?

Hangi kontrolün aktif olduğuna bağlı. Grup kontrollerinden biri aktifse (en yakın zamanda tıklandı), o zaman bir sonraki gruba geçer. Bunun yerine , grup içindeki kontrollerden biri etkinse, o zaman gruptaki bir sonraki kontrole geçer. Sistemin çalışması bu şekildedir.

Yani sadece aktif kontrol süreci klavye giriş, artık kontrole herhangi işlenmemiş girişi çiftçilik gerekir gerekir değil sahibi onu. Ya öyle ya da kontroller bir tür bağlantılı listede olmalı, böylece ileri geri gidebilir. Bu, her kontrolde varsayılan davranış olması gerektiği anlamına gelir.

Bu, tutulan bir GUI'ye daha çok benziyor, değil mi? Tek fark şu ki ... sıkı çalışmayı yapan sizsiniz . Başka birisinin kullanılması GUI'nin daha az iş yapmanın bir yolu olduğu farz edilir. Ancak, kullanıcının beklediği gibi bir GUI yanıtı verme çabası önemsizdir.

Unutmayın: kullanıcı arayüzü sizin için değil, kullanıcılarınız için . Bu oyuncu için. Bekledikleri gibi davranmalıdır. Olmazsa, o zaman başarısız oldun .

Kullanıcı arabirimlerinin genellikle otomatik olarak düzenlenmesi veya anında yeniden boyutlandırılabilir pencereleri olması gerekmez.

Bu sınırlı ve sınırlı bir düşüncedir.

Bazı oyunlar o, farklı UI ihtiyaçlarını sahip farklı oyunlar hakkında spiel verebilir yapmak benzeri ihtiyaç resizeable pencere ve. Fakat çok daha büyük bir problem var.

Düşünceleriniz Gratuitous Space Battles problemine yol açar.

Bu oyunu hiç oynamadıysanız, ucuz, bağımsız ve GUI ağırlıklı bir oyun. Asıl oyun GUI'de yapılır (bu bir tür "birimler kur ve onları dövmelerini izle" türü bir oyun). Sorun?

GUI iyileştirilemez!

Normal bir monitör kullanıyorsanız veya normal bir görüşünüz varsa, bu sorun değil. Fakat eğer siz benim, örneğin, gülünç derecede büyük bir monitörü çalıştıran (eğer o kadar büyük bir Windows varsa tüm metnin boyutunu ölçeklendirmek için okuyabilirseniz, bu gerçekten korkunç) . Metin mikroskobiktir. Yazı tipi boyutunu değiştirmenin bir yolu yoktur.

Verilmiş, GSB GUI tabanlı bir oyun, bu yüzden kesinlikle onlar için affedilmez. Bir GUI-lite oyunu muhtemelen bununla kaçabilir.

Asla kullanıcılarınızın oyunlarına tam olarak sizin gibi baktığını düşünmeyin . Bunu yapmak aptalca.

Kendisini kullanıcının çözünürlüğüne dönüştürebilen bir GUI sistemine sahip olmak, gerçekten çözünürlükten bağımsız bir GUI, GUI sisteminin kendisinin bir parçası olmasını gerektirir. Bunu sağlamayacaksanız, metniniz birinin dev monitöründe küçük görünecek. Bu iyi bir şey değil .

Bu yüzden bu konudaki düşüncenizin yetersiz kaldığını söyleyebilirim. Sen do o şeyi gerekir. Tutulan GUI'lerin sağladığı şeylere ihtiyacınız var. Oh, belirli bir GUI sisteminin sağladığı her şeye ihtiyacınız olmayabilir . Ama bir kısmına ihtiyacın var.

Sisteme veri almak için yapmanız gereken kazan plakası çalışması, kullanıcının kontrollerle doğru bir şekilde etkileşime girebileceği ve oyuncunun gereksinimlerine uyacak şekilde yeniden boyutlandırılacağına dair makul güvencenin yanında ödenmesi gereken küçük bir bedeldir.

Oynatıcıdan çok fazla kullanıcı girişi almazsanız, anında çalışan bir GUI ile kurtulabilirsiniz. Ama bu konuda olurdu.

Önce IMGUIs de ilgimi çekti ederken, A, bir test olarak ben tekniklerle kendimi tanımak için öğreticiler bir çift yazdı (başlatmak burada eğer ediyoruz ilgilenen, ancak çok daha C # / XNA + orijinalinden daha değil 'öğretici' burada ) .

IMGUI'leri kısa bir süre gerçekten çok sevdim çünkü gösterdikleri bilgiler her zaman güncel ve doğru (çünkü her zaman gerçek verilere besleme yaptığınız bir durum yok). Ama sonunda ilgimi kaybettim, bu yüzden normalde tutulan GUI'leri tekrar kullanıyorum.

Sonunda, GUI'nin doğruluğunun GUI'yi verilerden ayırmayı zorlaştırdığını düşündüm ve zaman zaman IMGUI'lerin zarafetini kırarak bazı durumları tanıtarak bazı şeyleri daha fazla ayırmaya çalıştım. Ayrıca tutulan GUI'ler için kod yazmanın IMGUI'ler için kod yazmaktan daha fazla olduğunu düşünmüyorum ve tutulan GUI'lerin kovulması ve unutulması hoşuma gidiyor ve olayları gerçekten seviyorum :).

Bununla birlikte, birileri IMGUI'lerden her bahsettiğimde, içimdeki bir şey tekrar denemek ve bunu doğru yapmak için daha çok denemek ister, çünkü orada gerçekten bir zarafet var, çünkü işinizi her zaman kolaylaştıracaksa,% 100 emin değilim. Bunu denemeyi söyleyebilirim, belki de yaptığım gibi deneyebilir ve bazı dersler yazabilirim (yeni teknikleri öğrenmenin en iyi yolunu başkalarına açıklamaktır).

Sizin tanımladığınız gibi çalışan Unity3D GUI sistemi ile çok çalıştım. Ve söylemeliyim ki, tutkuyla nefret ediyorum.

"Acil" yaklaşımı bazı durumlarda gerçekten işe yarar. İlk olarak, sadece birkaç butona ve etikete ihtiyacınız olduğunda - örneğin, tetikçi HUD'yi düşünün. Onları “korunmuş” bir yaklaşımla yaratmak çok zor değil, UnityGUI ile çok kolay. İkinci durum, ekranda çok sayıda kontrol yapmanız gerektiğine ilişkindir, ancak gerçekten düzeni önemsemezsiniz. Özellikle tam kontroller yalnızca çalışma zamanında biliniyorsa. Bu aslında herhangi bir oyunda işe yaramaz, ancak Unity editöründe çalışan araçlar yaparken çok faydalıdır.

Bununla birlikte, herhangi bir yarı-karmaşık GUI - (MMO) RPG veya bir strateji oyunu için, kaçınılmaz olarak, kaçınılmaz olarak, çözülemez bir kod karmaşasına, özel vakalarla dolu ve tonlarca yol açıyor. Böyle bir GUI oluştururken, genellikle herhangi bir özünürlük için çalışması gereken ve yoluna gönderdiğiniz verileri gösterebilen, oldukça belirgin bir düzeniniz vardır. Daha uzun metne ulaşmak için, örneğin, bazı düğmeleri daha aşağı hareket ettirmek gibi şeylere ihtiyacınız var. "Retained" GUI ile, bunu otomatik olarak yapan bir kontrole sahip olabilirsiniz. "Acil" modu ile kontrol yoktur , bu yüzden her şeyi açıkça yapmanız gerekir.

UnityGUI ile ilgili başka bir sorun (tüm acil mod GUI'lerine gelip gelmediğinden emin değilsiniz), örneğin bir Button()aramanın başka bir GUI aramasını dikkate almadan çalışmasıdır. Bu nedenle, bir düğme diğerinin üzerinde ise, bir tıklama aynı anda iki düğmeye de basacaktır. Bu kesinlikle kullanıcının beklediği şey değil, bu yüzden ele alınması gereken başka bir özel durum ekledi.

Tüm bunlarla yaşamak için, her zaman "sarılmış" bir mod sistemine dönüştüren UnityGUI'nin etrafına kendi sargıcımı yazdım: kendi durumlarını saklayan ve sadece GUIbenim için her fonksiyonu gerekli işlevleri çağıran denetimler .

"Hemen" modunun "korunma" modundan kesinlikle daha kötü olduğunu söyleyemem , ancak "korunma" modunda çalışmak konusunda kendimi kesinlikle daha iyi hissediyorum.

Burada IMGUI'yi savunacağım çünkü daha önce listelenen sorunlardan bazıları, kodunu yazmak istemeniz durumunda çözülebilir. Ek olarak, eğer kodunu yazarsanız, yeniden kullanılabilir ve sadece çok nadiren değişiklik gerektiren sağlam bir kütüphaneye sahipsiniz.

• GUI şemadan yükleniyor

belki de ilk bakışta sanatçıların IMGUI ile fazla esnekliğe sahip olmadığı görülüyor, bu GUI mizanpajını bir xml veya JSON şemasından yüklemekle çözüldü veya gelişti.

• menü katmanı aramaları çizmek

Bu problem sıralama ile çözülür, beraberlik sırasını sıralayan UI Manager sınıfını oluşturmalısınız, bu problemi C # XNA'da birbirinin üzerine hareketli, tıklanabilir panellerle çözdüm. İstenirse sahte kod gönderebilirim.

• liste kutuları

Bir diziden dizeleri çekebilir misiniz? Dikdörtgen alanları, bu dizelerin fontlarının yükseklik ve genişliğinden tanımlayabilir misiniz? Kaydırma düğmenizin boyutunun, birlikte eklenen tüm bu dikdörtgenlerin yüksekliğine oranını oluşturabilir misiniz? Ardından yukarı veya aşağı hareket ettirmek için kaydırılabilir düğmeli bir liste kutusu oluşturmaya yarı yoldasınızdır. Zor olacağını düşündüm, ama düşündüğümden daha basit olduğu ortaya çıktı. tampon yok, devlet yok, geri arama yok.

• verileri GUI'den ayırma

panellerin, düğmelerin ve kutuların verileri tutmasına izin vermeyin. IMGUI'nin ilk girişiminde ani olduğunu ancak sadece grafik anlamında olduğumu biliyorum. Kullanıcı Arayüzündeki verileri tutma hatasını yaptım. Kullanıcı arayüzü değişiklikleri ile verilerin nereye yerleştirileceği ve değiştirileceği hakkında farklı düşünmek neredeyse felsefi bir değişimdi.

• SDK'lardan gelen GUI

bu SDK kodunun sınırı ve işlevselliğidir, sizinki değildir. SDK Kullanıcı Arabiriminin (Çekiç, Birlik, UDK) öğrenmenin neredeyse yeni bir dil olduğunu düşünüyorum. Aslında Windows gibi bana benzerler. Formlar, her ikisi de en geniş olasılık için ayarlanmış ve bunun için karmaşıklık konusunda biraz fazla ağırlık var.

ve son olarak bunu izleyin> http://mollyrocket.com/861

Kullanıcı arabirimlerinin genellikle otomatik olarak düzenlenmesi veya anında yeniden boyutlandırılabilir pencereleri olması gerekmez. Bunun yerine, sürekli değişen verilerle (dünyadaki modellerin 3d konumları gibi) çok verimli bir şekilde etkileşime girmeleri gerekiyor.

Söz konusu türe ve oyuna göre değişir. İyi bir envanter yönetimi sistemi, herhangi bir RPG için çok önemlidir. Sizin için mizanpajları işleyen, kaydırma çubuklarını, sürükle bırak, araç ipucularını ve Reided GUI kullanarak uygulanması daha kolay olan diğer özellikleri destekleyen bir şey isteyeceksiniz.

Çok fazla hokkabazlık yapmayan bir anlık GUI ile n 'drop'ı sürüklemenin ya da geçici olarak Z arabelleğini değiştirme ve zaman aşımına uğrayan bir tıklamayı dışlamak için zaman bilgisini saklama gibi kullanıcı durumu kaydetme yöntemini düşünemiyorum. bit.

Ancak tasarım açısından GUI olaylarım olmadan bir dünya hayal etmekte zorlanıyorum. Ayrıca bir Anlık Kullanıcı Arayüzü, sizi yordamsal programlamaya başvurmaya zorlayan OOP ile uyumlu değildir.

Anlık GUI'lerin sağladığı basitlik, kullanıcı arayüzünüzün gerektirdiği karmaşıklık arttıkça kodunuzdaki ek karmaşıklığın maliyetidir; iyi durumda tutulan bir GUI başlangıçta daha karmaşık ancak daha iyi ölçeklenirse. Dolayısıyla, belirli bir karmaşıklık noktasının altında acil bir GUI yeterlidir, ancak çoğu durumda tutulan bir GUI'yi tercih ederim.