[PsichiX]

hmm, na dziś kodowania edytora koniec, stanąłem przed designerską ścianą - property editorów z Ptakopyska wziąć nie mogę, są ograniczone, tj. istnieje limit rodzajów edytorów (głównie są składane z bazowych edytorów).
To, co chcę uzyskać to danie możliwości użytkownikowi zdefiniowania własnego dowolnie złożonego edytora dla customowego typu, który chcemy edytować i tu pojawił się problem natury: w jaki sposób napisać kod takiego edytora, który może przyjąć dowolną formę i akcje, jednocześnie będąc konfigurowalnym z pliku tekstowego bez konieczności tworzenia pluginu w .NET-cie do aplikacji?
Rozwiązanie widzę takie: stworzyć bazową kontrolkę edytora i bazowe edytory do kilku typów JavaScriptowych, które to dodają elementy UI do bazowej kontrolki i bindują akcje na edycję i update propertiesa (czyli reagują na serializację i deserializację JSONa).
Ale ale! Co, gdy ktoś musi zrobić edytor np. ścieżek, czy innego rodzaju bardziej niecodziennych danych, czego nie da się złożyć z edytorów bazowych typów? Ano mam na to patent! ^^ użytkownik będzie mógł zarejestrować swój własny customowy edytor napisany w JSie i wyświetlać się go będzie w nowym okienku z mini-browserem (geckofx)! Jak to będzie działać? Rozpatrzmy taki przypadek (pardon, że robię z Was debugowe kaczki :D):
1. developer stworzył skrypt, który jako jeden z atrybutów jest customowego typu: MovementPath;
2. Nie da się tego w żaden sposób złożyć z edytorów bazowych, więc tworzy sobie jako asset kodu skrypt MovementPath.editor.js i w tym pliku pisze kod który ma zawierać takie funkcjonalności:
a) funkcja initialize() przyjmuje JSON z danymi do zwizualizowania ścieżki i buduje UI do tego;
b) funkcja update() aktualizuje wizualizacje oraz dane (poprzez np. reakcję na input);
c) funkcja result() zwraca zedytowane dane do aplikacji podczas zamykania okienka edytora ścieżek.

Nom, a edytory do typów, które da się złożyć z bazowych (np. vector jako kilka kontrolek floatów) będzie się po prostu opisywało poprzez konfigurację w pliku JSONa (np. Vector3.editor.json) - i wszystko powinno banglać jak ta lala <3
Jakieś przemyślenia co do tego podejścia? :)

#playgate #gamedev #playcanvas

[Noct]

@PsichiX: a na polski?

[PsichiX]

@Noct: TL;DR: zastanawiam się, w jaki sposób pozwolić developerom na stworzenie własnych edytorów propertiesów do PlayGate (offline'owy edytor do PlayCanvasa, który robię) :)

[Noct]

@PsichiX: Hmm, nie sądzę, by danie devom takich uprawnień miało jakiś większy sens.
Większość korzysta z własnych/gotowych/acotosompropertisy skryptów. Masz jakąś betę do przejrzenia?
W czym znajdujesz do tego zastosowanie?

[PsichiX]

@Noct:
propertiesy w kontekscie edytora gier oznaczaja atrybuty obiektu, ktore mozna modyfikowac w aplikacji.
'problem' w tym, ze to sie swietnie przyjelo w Unity - dali developerom mozliwosc tworzenia wlasnych edytorow, dzieki czemu takie rzeczy jak edytor dla propertiesow typu MovementPath sa realne i umozliwia to edycje sciezki przez rysowanie jej, miast wpisywanie kolejno pozycji kazdego punktuvsciezki do listy. i taka mozliwosc jest cudowna w skutkach, edytor gier powinien byc piakownica

[regis3]

@PsichiX: Proponuję dać kod w C# do napisania który będziesz kompilował w locie.

[PsichiX]

@regis3: nope. nie moge pozwolic na az taka mozliwosc ingerowania w aplikacje - 'pluginy' musza byc sandboxowane i komunikowac sie z aplikacja wylacznie wolaniem API. jak zaczne ladowac dowolny plugin to moglby on wykonywac akcje poza kontrola. zdecydowanie lepiej widze to jako wykonywanie JSa, ktory defaultowo jest sanboxowany, nizeli dac pela kontrole nad aplikacja i systemem pluginom .NETowym.

[regis3]

@PsichiX: jasne, ale właśnie o takie sandboxowe środowisko mi chodziło. Np uruchamiać kod w stworzonej domenie (nie aplikacyjnej) https://msdn.microsoft.com/en-us/library/bb763046(v=vs.110).aspx

[PsichiX]

@regis3: ale nadal użytkownik będzie miał dostęp do systemu, rajt? bo ja chcę całkowicie go odseparować od systemu i aplikacji, dając jedynie dostęp przez API. inaczej jak ktoś będzie chciał użyć jakiegoś pluginu od kogoś, a on by w nim np. gromadził dane o Tobie, o sposobie użytkowania aplikacji, albo robiłby coś złośliwego w tle - pluginy muszą być transparentne dla użytkowników i całkowicie nie ingerujące w nic, poza dostępem przez

[regis3]

@PsichiX: Co masz na myśli przez dostęp do systemu? W przykładzie powyżej masz np ograniczenie do nieodczytywania plików. Sam określasz do jakich działań dany kod ma dostęp - https://msdn.microsoft.com/en-us/library/system.security.codeaccesspermission(v=vs.110).aspx To co robisz nie jest jakieś unikalne. Standardowe sandboxowe środowisko w c#. Masa edytorów z tego korzysta.

[PsichiX]

@regis3: wow. no to tego nie znałem :O dzięki! <3
dodam to jako opcję dla zaawansowanych, bo docelową grupą odbiorców są użytkownicy JSa, więc zmuszanie ich do uczenia się C# nie wchodzi w grę, ale jako opcja na zaawansowane edytory jest extra! :D