Jest kilka ogólnych podejść do zrobienia edytora do gry:
- dwie w całości niezależne aplikacje (każda z własnym rendererem itd.) -- na coś takiego zdecydowałem się przy PK, niestety takie podejście wymaga pisania dwukrotnie sporej części kodu, co na dłuższą metę jest bardzo nużące. Może jednak dobrze sprawdzić się w sporych zespołach, gdzie pewna grupa zajmuje się tylko edytorem -- wtedy obydwie grupy (czyli też ta od gry) wymieniają między sobą właściwie tylko informacje o formatach plików
- współdzielenie modułów -- edytor to osobna aplikacja, korzystająca jednak z tego samego renderera i innych elementów silnika. Mniej wspólnego kodu, ale jeżeli gra i edytor mają być w różnych językach (C++ i C#), to dochodzi nam sklejenie środowiska natywnego i CLR
- gra z wbudowanym edytorem -- edytor na stałe wbudowany w główny plik gry. Ekstremalnym przykładem są edytory z CryTEK (Far Cry, Crysis). Takie podejście wymaga jednak specyficznej architektury gry
- gra i edytor w osobnych aplikacjach/procesach, współpracujące ze sobą
Ostatnie podejście na swoim blogu opisał Maciej Sinilo (programista CDPR). Spróbowałem opisanego przez niego sposobu (aczkolwiek stosując gniazda zamiast potoków) i okazało się to strzałem w dziesiątkę.
Trzeba jednak pamiętać, że przy przesyłaniu komunikatów gra<-->edytor trzeba zmierzyć się z problemem architektonicznym. Komunikaty mogą bowiem być:
- przesyłane bezpośrednio do świata (stwórz obiekt X)
- wymagające użycia logiki gry (która musi z edytorem współpracować)
- zmuszające do wyświetlenia czegoś, albo przejścia w inny tryb (na przykład warto by w czasie edycji materiału wyświetlał się przykładowy obiekt pokryty tym materiałem)
- przesyłane w pewnym formacie (czysto tekstowy/XML/binarny), trzeba umówić się co z przesyłaniem danych (plików)
Generalnie problemów trochę jest, ale podejście wydaje mi się całkiem słuszne. Pewnie za kilka tygodni będę mógł opowiedzieć, jaki jest WTF/m socketowego edytora. ;)
PS. "Wnętrzności" edytora widać na załączonym screenie.
