Autor Wątek: Edytor do silnika  (Przeczytany 8405 razy)

Offline Asmodeusz123

  • Użytkownik

# Lipiec 10, 2014, 19:29:38
Witam. Tworzę od około roku swój własny silnik graficzny w celu wydania na nim gry w niedalekiej przyszłości. Mam już gotową obsługę oświetlenia, cieni, własny format modeli, ogólnie rzeczy podstawowe. Chciałbym utworzyć do niego edytor. I tu nasuwa się pytanie: jaką technologię należy wykorzystać? Chodzi mi tutaj dokładnie o GUI.  Dodam, że silnik leży w całości na DirectX i C++. Chciałbym uniknąć wykorzystania bibliotek typu Qt czy CEGUI. Czy uważacie, że byłoby dobrze napisać swój system obsługi GUI? Dodam, że jakieś szczątkowe mechanizmy i kontrolki są już napisane, jednak nie wiem czy są one na tyle funkcjonalne i wizualnie poprawne by wykorzystać je w edytorze. Myślałem intensywnie o napisaniu wrappera dll i napisania samego GUI w C#, podobnie jak to zrobiono chociażby w Frostbite. Co o tym myślicie?

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline PsichiX (ΨΧΞ)

  • Użytkownik
    • PsichiX Website

# Lipiec 10, 2014, 19:34:43
c# i winformsy, jesli ma dzialac na windzie zwlaszcza (lub opentk(?) i mono). robienie toola pojdzie szybko i bezbolesnie. zawsze mozesz wtedy owrapowac grafike silnika w CLI/C++ i bezbolesnie uzywac w toolu.

Offline Asmodeusz123

  • Użytkownik

# Lipiec 10, 2014, 21:36:00
Dzięki za odpowiedź, ale mam jeszcze pytanie, czy nie lepiej byłoby użyć WPF? Jest to nowsza technologia, która podobno ma zastąpić Windows Forms. No i czy w ogóle w takiej sytuacji można wykorzystać WPF. Przepraszam za może nieco lamerskie pytania, ale wcześniej jeżeli robiłem coś w C# to całkowicie i raczej były to małe aplikacje, a tool do silnika to raczej coś bardziej skomplikowanego, no i jeżeli już bym go napisał, to raczej będzie mi służył przez jakiś czas co najmniej.

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Lipiec 10, 2014, 22:36:28
Opcje, jakie masz, można podzielić na:

- Napisać swoje GUI, jakieś bardzo proste i minimalistyczne, np. w stylu Immediate Mode GUI. Ale to zawsze będzie miało ograniczone możliwości.
- Napisać swoje GUI, wypasiony system. Pisanie tego to fajna sprawa, ale też dużo roboty, więc pytanie, czy chcecsz się w to zagłębiać, czy wolisz się skupić na pisaniu edytora do swojego silnika.
- Użyć gotowego systemu GUI do integracji wewnątrz swojego renderingu, np. CEGUI.
- Użyć biblioteki do robienia normalnego GUI Windows dla C++, w niej zrobić edytor i w nim osadzić panel z renderingiem z silnika. Tutaj można użyć np. Qt, wxWidgets.
- Napisać edytor w innej technologii, w której wygodnie robi się GUI, np. w .NET z użyciem Windows Forms albo WPF i w tym osadzić rendering z silnika, łącząc jakoś kod edytora z kodem natywnym silnika.

Którą opcję wybrać? To nie jest takie jednoznacze. Ja bym chyba wybrał bibliotekę do GUI w C++, najprawdopodobniej Qt.

Offline Asmodeusz123

  • Użytkownik

# Lipiec 10, 2014, 23:33:50
Pisanie superwypasionego GUI raczej odpada, bo pewnie zajęłoby mi to następne 3 miesiące, a ja chciałbym doprowadzić przez następne pół roku do stanu w którym dałoby się już coś robić w tym edytorze. Co prawda mam już tam jakieś podstawowe kontrolki i dialogi, ale jakość kodu, strona wizualna i liczba bugów odpycha mnie od pomysłu użycia tego przy pracy nad edytorm. Użycie zewnętrznych bibliotek też średnio mi odpowiada, chociażby ze względu tego, że nie wiem jak to zadziała z moi rendererem. Myślę  więc o ostatniej możliwości, tylko zastanawiam się czy użyć c++/clr czy wrzucić funkcje silnika do dllki i użyć jej w c#.

Offline PsichiX (ΨΧΞ)

  • Użytkownik
    • PsichiX Website

# Lipiec 11, 2014, 00:36:57
opcja #1 zawiera sie w opcji #2. Obczaj zrodla SFML.NET, zobaczysz jak sie to wrapuje.

Offline adsko

  • Użytkownik

# Lipiec 11, 2014, 02:02:08
Teraz ja się bawie w C++/CLI i musze powiedzieć, że bardzo miło się w tym pisze. Jedynym problemem dla mnie który był to update mojego VS2010 do 2013. Jeżeli masz 2010 i nie chcesz zmieniać to odradzam, IntelliSense z nim nie współpracuje.

P.S. C# i C++/CLI mało się różni. Podobna składnia kontrolek, tylko kwestia przyzwyczajenia. Różnica polega na odwołania do wskaźników na klase za pomocą "->" zamiast ".".

Offline PsichiX (ΨΧΞ)

  • Użytkownik
    • PsichiX Website

  • +1
# Lipiec 11, 2014, 02:21:25
może lepiej darujmy sobie porównania skłądni CLI/C++ do C# :>

Offline Dab

  • Redaktor
    • blog

  • +1
# Lipiec 11, 2014, 12:08:27
Na początek kilka linków:

http://msinilo.pl/blog/?p=212
http://28byteslater.com/2008/12/26/budujemy-silnik-edytor/
http://28byteslater.com/2010/05/24/game-and-editor-comunication/

Nie ma chyba sensu ostrzegać, że o ile "własny silnik" w ogólności jest zadaniem arcytrudnym to "własny silnik z własnym edytorem" jest w warunkach obserwowalnego Wszechświata nieprawdopodobny. ;) Przynajmniej jeżeli chodzi o tech ogólnego zastosowania, bo dla jakichś bardzo specyficznych zastosowań może się to sprawdzić.

Osobiście nie polecam integracji w rodzaju C++ plus C# z użyciem wrapperów czy socketów. Do sensownego działania i tak potrzeba w silniku masę przeróbek na potrzeby edytora, a skoro już mamy takie przeróbki to można całość obsłużyć już z jego poziomu. Przynajmniej z moim przypadku tak było - w pewnym momencie musiałem wycofać się z takiego podejścia i edytor otrzymał własny renderer, natomiast silnik został odchudzony z wszystkiego związanego z edytorem.

Własne GUI generalnie nie ma sensu, ale własny silnik i własny edytor też nie. ;) Natomiast polecam mimo wszystko rozważyć użycie gotowych komponentów, przynajmniej na początku - debugowanie jednocześnie GUI, silnika i edytora to zabawa dla masochistów. Z gotowych rozwiązań prosty i dość sympatyczny jest GWEN.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +2
# Lipiec 11, 2014, 12:34:04
Generalnie to moim zdaniem w takim wypadku od samego początku trzeba robić silnik z edytorem. Prościej jest wyłączyć edytor niż go później dopisać, zwłaszcza że przy dopisywaniu edytora może wyjść cała masa różnych kwiatków - ot, chociażby kwestia edycji meshów statycznych.


Innym, bardzo fajnym podejściem, może być też podejście bezedytorowe. W tym przypadku ogarniamy jedynie toolchain do przeniesienia kompletnego levelu z Blendera (czy czegokolwiek co wybierzemy) do silnika. Raz tak zrobiłem i naprawdę dawało to radę - mapkę można było edytować normalnie, a lokalizacje obiektów, spawn pointów i triggerów zaznaczało się odpowiednio ponazywanymi boxami. Prosty plugin eksportował geometrię plus wszystkie boxy jako listę (nazwa+wymiary). Sprawdziło się. :)

Offline adsko

  • Użytkownik

# Lipiec 11, 2014, 12:49:33
może lepiej darujmy sobie porównania skłądni CLI/C++ do C# :>
Wiem, że to dalej nie C#, lecz wraz z nowym standardem coraz bardziej go przypomina, a w szególności C++/CLI. Przesiadka nie jest, aż taka straszna.

Offline Asmodeusz123

  • Użytkownik

# Lipiec 11, 2014, 14:45:57
@Dab
Silnik i edytor będzie raczej ukierunkowany, więc myślę, że to się może udać. Dzięki za odpowiedź i link, na pewno się zapoznam, na razie jednak mam dość poważne problemy z komputerem.  Zastanowię się jeszcze nad zewnętrzną biblioteką, lecz jak wspomniałem wcześniej,  chciałbym tego uniknąć.
@Krzysiek K.
Silnik nie jest w aż tak zaawansowanej formie moim zdaniem, żeby nie można było łatwo wprowadzić poprawek. Był on zresztą od początku tworzony raczej z celem takim, że kiedyś będzie miał edytor. A co do toolchaina to rzeczywiście, mam już skrypt do blendera, który eksportuje do mojego formatu plików, jednak pisanie w pythonie to dla mnie katorga i nie wygląda on tak jakbym chciał. Może jest to jakieś rozwiązanie, ale nauka całkiem innego języka też zajęłaby mi trochę czasu. Oczywiście przemyślę tę propozycję i w ogóle dziękuje za zainteresowanie tematem.

Ja najbardziej przychylałbym się do rozwiązania tego właśnie przez .NET Frameworka. Wiem, że kilka większych silników działa na tej zasadzie i dobrze im to wychodzi. Oczywiście wiem również, że nigdy im nie dorównam, jednak sam pomysł uważam za dobry. Oczywiście jeszcze się zastanawiam, bo i tak nic raczej nie napiszę, dopóki nie naprawię sobie komputera. Dziękuje za wszystkie propozycje i za zainteresowanie.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Lipiec 11, 2014, 15:10:53
Cytuj
A co do toolchaina to rzeczywiście, mam już skrypt do blendera, który eksportuje do mojego formatu plików, jednak pisanie w pythonie to dla mnie katorga i nie wygląda on tak jakbym chciał. Może jest to jakieś rozwiązanie, ale nauka całkiem innego języka też zajęłaby mi trochę czasu. Oczywiście przemyślę tę propozycję i w ogóle dziękuje za zainteresowanie tematem.
Ano katorga, ale potem nie jest już tak źle. Polecam jakoś przeboleć ten etap i iść dalej, bo blenderowy Python wcześniej czy później może się przydać - np. jak przyjdzie do eksportowania animacji, czy automatyzacji sobie jakiejś roboty. Ja też się z Pythonem męczyłem i nadal nie czuję się z nim komfortowo, ale możliwość zaskryptowania czy eksportowania sobie czegokolwiek w Blenderze to bardzo duży plus.


EDIT: Ale jeżeli chcesz iść w kierunku .NET/WinForms, to to też będzie dobra droga, chociaż skryptowania Blendera i tak całkowicie nie ominiesz.

Offline ArekBal

  • Użytkownik

# Lipiec 11, 2014, 22:21:56
- Napisać swoje GUI, jakieś bardzo proste i minimalistyczne, np. w stylu Immediate Mode GUI. Ale to zawsze będzie miało ograniczone możliwości.
Większość pełnych gier i tak coś takiego musi zrobić dla potrzeb samej gry.

Cytuj
- Napisać swoje GUI, wypasiony system. Pisanie tego to fajna sprawa, ale też dużo roboty, więc pytanie, czy chcecsz się w to zagłębiać, czy wolisz się skupić na pisaniu edytora do swojego silnika.
Myślę że podejście zwinne ma tu największy sens... jakieś GUI i tak musisz mieć(pacz punkt wyżej) więc chociaż je dobrze zaprojektuj by się dało je rozwijać i minimalizuj poziom skomplikowania ile się da(w sensie nie ścinać zakrętów, tylko odkładać na bok rzeczy które można robić później(databinding... lol)).

Cytuj
- Użyć gotowego systemu GUI do integracji wewnątrz swojego renderingu, np. CEGUI.
Teoretycznie najprostsze, ale ograniczone w rozszerzalności podejście.

Cytuj
- Użyć biblioteki do robienia normalnego GUI Windows dla C++, w niej zrobić edytor i w nim osadzić panel z renderingiem z silnika. Tutaj można użyć np. Qt, wxWidgets.
- Napisać edytor w innej technologii, w której wygodnie robi się GUI, np. w .NET z użyciem Windows Forms albo WPF i w tym osadzić rendering z silnika, łącząc jakoś kod edytora z kodem natywnym silnika.
Te same.
No i tu znowu... dostaniemy najmocniejsze GUI, koszt integracji zazwyczaj stosunkowo niski ale do renderowania ingame raczej nie użyjemy. Musi iść w połączeniu z nr 1(z konieczności).

Cytuj
Innym, bardzo fajnym podejściem, może być też podejście bezedytorowe.
To nie jest bezedytorowe bo twoim edytorem staje się Blender. :)
Jak to trochę ogarnąć to taki "production pipeline" czy "workflow" staje się bardzo podobny do tego w Unity:
- mamy edytor który możemy rozszerzać, modyfikować(w Pythonie - co jest zaletą - bo to bdb język jest, ale i wadą bo to kolejny język do poznania),
- mamy natywny silnik... który będzie śmigał jak zakochany na czym zechcemy/obsłużymy,
- mamy skrypty które nakręcając silnik(z tą różnicą że natywne ;))

Od Unity to tylko gorsze w tym że wszystkie komponenty i właściwy silnik musimy napisać sami. ;P


Wszystkie powyższe mają sens... ja osobiście jestem za rozwiązaniem 2(z umiarkowaniem) lub ostatnim(od KK).
« Ostatnia zmiana: Lipiec 11, 2014, 22:24:08 wysłana przez ArekBal »

Offline Asmodeusz123

  • Użytkownik

# Lipiec 12, 2014, 12:27:31
Dzięki za wszystkie odpowiedzi. Zastanowiłem się i po dłuższym namyślę chyba wybiorę podejście C# + WinForms, albo WPF. Jakieś proste, minimalistyczne GUI w silniku mam, które będzie dobre do wykorzystania "ingame", ale jeżeli bym chciał wykorzystać je do edytora, to musiałbym je przerabiać i wywalić pewnie z połowę odpowiedzialnego za nie kodu. Wolałbym tego uniknąć.

Jak uda mi się stworzyć ten edytor to wrzucę go na warsztat. Dziękuje za wszystkie odpowiedzi i pozdrawiam.