SkovvGameMaker - Program do tworzenia gier(C++ / C#)

Jakby ktoś był chętny to zapraszam do testowania SkovvGameMaker

link
Trzeba także zainstalować Mono C#(link - zwykła wersja bez GTK) standardowo w C:\Program Files\Mono

Jest to program do tworzenia gier który piszę od jakiegoś czasu. Napisany w C++, obiekty w grze programujemy z użyciem C#.
Główne możliwości(na ten moment):
-> Obsługa Sprites + każdemu spritesowi możemy nadać Joint(uchwyt) dzięki czemu możemy łatwo się odwołać do danego punktu na spritesie
-> Obsługa Fontów
-> AnimationSheet(wiele klatek na jednym obrazku) z automatycznym wykrywaniem wielkości klatek + tworzenie list animacji z klatek(osobno animacja skok, bieg itp itd + prosta zmiana w kodzie)
-> Wbudowany edytor animacji szkieletowej + prosta obsługa tych animacji w grze. Możliwość nadania eventów animacjom w danym czasie i wywoływanie ich w C#
-> Proste dodawanie/ustawienie tilesetów + wbudowany edytor map kaflowych
-> Obsługa dźwięku/muzyki
-> Skryptowanie w C#, możliwość zmiany zmiennych danego skryptu dla danego obiektu z poziomu edytora(jak w Unity). Możemy nadać danemu obiektowi dowolną ilość skryptów, mogą się one do siebie odwoływać(przez GetComponent<..>() ) by współpracować. Jest wbudowany edytor kodu C#
-> Wbudowany edytor map przez który możemy tworzyć instancje, nadawać im komponenty, tworzyć mapy kaflowe itp
-> Menadżer projektów dzięki któremu możemy otworzyć ostatnie projekty/utworzyć nowy projekt/pobrać i odpalić jeden z kilku pierwszych przykładów który przygotowałem
-> Wbudowane komponenty koliderów które możemy nakładać na obiekty i w prosty sposób sprawdzić kolizje między dowolnymi obiektami/grupą obiektów. Koliderom można nadać nazwy dzięki czemu możemy sprawdzić co dokładnie zderzyło się z czym
-> Prosty instancing(InstanceCreate aby stworzyć instancje lub Destroy by ją usunąć).
-> Możliwość tworzenia instancji: na mapie tworzymy sobie obiekt, nadajemy mu w inspektorze dowolne komponenty/kolidery/grafike/animacje/skrypty, przeciągamy do okna Assetow na dole i tworzy nam sie instancja którą możme później wrzucić na mapę bądź stworzyć w trakcie gry z kodu C#
-> Przyjazny inspector(po prawej) do edycji instancji/ustawień edytora itp itd. Można w prosty sposób edytować wszystkie dostępne ustawienia wszystkich komponentów obiektu, zmieniać ustawienia mapy, ustawiać kości w edytorze Animacji Szkieletowych itp itd.
-> Przyjazny podgląd/dodawanie/edycja wszystkich assetów w oknach
-> Na dole lista Assetów, możliwość tworzenia folderów i segregowanie assetów w nich.
-> Inne rzeczy których nie pamiętam

Zapraszam do testowania i będę wdzięczny za opinie!

youtube

Michał Skovv napisał(a):

każdemu spritesowi możemy nadać Joint(uchwyt) dzięki czemu możemy łatwo się odwołać do danego punktu na spritesie

A czy nie chodzi bardziej o pivot?

Joint to raczej nazwa zarezerwowana dla fizycznych relacji między obiektami:
https://www.iforce2d.net/b2dtut/joints-overview

Możliwe - Joint lepiej brzmi :D Dodałem przykład gry TowerDefense

czyli robisz ograniczoną kopię unity? Nawet skryptowanie jest żywcem zerżnięte, jakie zalety ma twój projekt?
Robienie swojego edytora kodu bez AI to bezsens, lepiej otworzyć zewnętrzne IDE tak jak unity, szkoda na to w ogóle czasu.

Z jednej strony dość imponujące, z drugiej totalna strata czasu bez perspektyw. Czy ideą było poćwiczenie żeby mieć do cv i wkupić się w oficjalny team unity?

Robię po prostu hobbystycznie edytor do gier 2d. Skryptowanie nie jest żywcem zerżnięte z unity, owszem bardzo się na nim wzorowałem ale jakbyś poprzeglądał inne silniki to jest to samo - obiektowość oparta na funkcjach/eventach. W przyszłości może napiszę sobie coś ala blueprinty, nie potrzebuję AI do programowania.

Nie wiem czemu uważasz, że to kompletna strata czasu bez perspektyw stary :D To, że jest coś lepszego nie znaczy chyba że muszę używać tego? Mogę chyba chcieć napisać coś swojego gdy moim "marzeniem" jest napisać kompleny silnik do tworzenia gier z ciekawymi bajerami, prawda? Nie piszę tego do CV bo mam firmę w kompletnie innej brażny a programowanie to po prostu moje hobby, odskocznia od codzienności. Szkoda, że nazywasz to stratą czasu tylko dlatego, że jest coś dużo lepszego(bo rozwijanego od lat i spory zespół programistów). Jakoś muszę to przełknąć :D

Moim założeniem jest napisać działający silnik który będzie samowystarczalny - będzie w nim można dodawać grafikę, tworzyć animacje, łatwo ją obsługiwać, tworzyć mapy i programować - kompletne narzędzie do tworzenia gier 2d - darmowe i bez opłat jak Unity itp. Pewnie napiszę w nim z jedną/dwie małe gierki i mi się znudzi - tak to już mam, że zawsze wolałem pisać edytory niż gry ;)

Pozdrawiam

Michał Skovv napisał(a):

Szkoda, że nazywasz to stratą czasu tylko dlatego, że jest coś dużo lepszego(bo rozwijanego od lat i spory zespół programistów). Jakoś muszę to przełknąć :D

No dlatego pytam w czym twój projekt jest lepszy? Jeśli ma tylko podzbiór funkcji czegoś co jest gotowe do użycia to nie wiem jak to inaczej nazwać.

darmowe i bez opłat jak Unity itp.

Unity ma opłaty dopiero jak przekroczysz przychód 200 000 dolarów rocznie - myślę że większość jest w stanie to przełknąć i myślę że gdyby twój projekt okazał się udany to w końcu i tobie by się zaświeciły dolary w oczach i chciałbyś jakiś procent od zysków dużych projektów zrealizowanych dzięki twojemu projektowi i że w końcu chciałbyś jakiegoś wynagrodzenia za swoją pracę, więc jedyny potencjalny plus jest pod znakiem zapytania. Nawet gdyby pozostał darmowy to userzy byliby na łasce jednego programisty i tego że będzie mu się chciało to dalej łatać i rozwijać co w przypadku totalnie darmowych projektów ma mniejsze szanse bycia.

No ale rozumiem że to tylko hobbistyczny projekt do pudełka, no fajny. Gdybyśmy mieli rok 2002 to nawet by coś rokował.

Być może zacząłeś swój projekt w okresie kiedy unity chwilowo miał w cenniku opłaty od instalacji, zakładając że ludzie by się nie zbuntowali to alternatywy byłyby nawet pożądane. Zresztą unity moim zdaniem stracił sporo userów w tym okresie na rzecz godota.

Michał Skovv napisał(a):

nie potrzebuję AI do programowania.

Spoko, pisałem zakładając że nie masz być jedynym użytkownikiem tej aplikacji. Chodzi o wygodę, nie potrzebę. Większość obecnych programistów nie potrzebuje ale jednak nawet "proste" uzupełnienie oczywistej linii i zaoszczędzenie kilku sekund kilkaset razy dziennie uprzyjemnia kodowanie.

Michał Skovv napisał(a):

tak to już mam, że zawsze wolałem pisać edytory niż gry ;)

mam dla ciebie genialne zajęcie które w dodatku ma szanse na sukces i monetyzacje - pisanie pluginów do unity. Zamiast marnować zasoby ludzkie na nadganianie za rozwijanym przez dziesięciolecia projektem ze sztabem ludzi możesz się przyłożyć do jego rozwoju i dołożyć do niego wszystkie ciekawe bajery jakich ci w nim brakuje

Może kiedyś się pobawię w pluginy, chwilowo chcę dopisać to. Wiesz, mi chodzi o to że chcę samemu coś napisać by wiedzieć dokładnie jak działa. Tutaj mam całe własne UI, napisałem Inspektor wzorowany na Unity, pierwsze raz miałem styczność z animacjami szkieletowymi i dobrze działający edytor animacji szkieletowych.. Napisałem edytor kodu z kolorowaniem składni, podpowiedziami klas/funkcji, pełną integrację z C#, silnik w C#, analize kodu C# z poziomu C++, pobieranie danych z klas C# do C++ i ogółem wiele wiele innych. Mimo iż nikomu to życia nie zmieni to cóż, mam dziwne hobby i lubię programować nowe rzeczy - może udostępnie na koniec kod i ktoś będzie miał ciekawy przykład małego silnika 2d.

Edukacyjnie fajna inicjatywa, powodzenia!

Na zdjęciach i filmiku wygląda fajnie. Co prawda nie odpalę go, ze względu na Maca. Planujesz zrobić gierkę na tym? Po plikach, widze, że nie używasz SDL/SFML, sam piszesz obsługę grafiki w opengl/vulcanie?

Póki pracujesz nad tym edytorem to pracuj dalej, dorzucaj nowe funkcje i szlifuj obecne. To nad czym bym obecnie popracował to nad interfejsem, dlatego że troszkę wieje tandetą:

• brak zdefiniowanej głównej ikony aplikacji, przez co ikonka na belce okna jest domyślną systemową,
• kolorowe ikony, których używasz, są strasznie duże i za bardzo rzucają się w oczy — na Twoim miejscu skorzystałbym z minimalistycznych, coś na kształt tych używanych w Visual Studio (jedno- lub dwukolorowe, proste kształty),
• edytor skryptów musi wspierać font monospace — obecny jest o zmiennej szerokości znaków.
• ogranicz liczbę kolorów edykiet do kilku, aby interfejs edytora nie był przesadnie kolorowy — użytkownik powinien móc skupić uwagę na tym co tworzy, a interfejs edytora póki co trochę rozprasza.
• powinna być możliwość otwarcia edytora skryptu w osobnej zakładce, w głównym oknie aplikacji, a nie tylko jako osobne okno.

I taka mała uwaga — nie wymyślaj wszystko samodzielnie, a inspiruj się istniejącymi programami. Wzoruj się na Unity, UE, Game Makerze i innych edytorach, tak aby funkcjonalność Twojego była podobna i w podobny sposób obsługiwana. To jest kluczowe podejście — jeśli ktoś miał już do czynienia z profesjonalnymi edytorami, powinien móc bez problemu obsłużyć Twój, praktycznie bez żadnej nauki.

Myślałem nad tym by napisać mały silniczek 2d opengl do spritesów, shaderów i fontów ale ostatecznie mi się nie chciało i użyłem biblioteki Raylib. Jest nieduża, schludna i ma wszystkie funkcje do 2d których potrzebuję do renderingu i odtwarzania dźwięku.

Tak, planuję w tym napisać gierkę dla córki, może jak troszkę podrośnie to ją jakoś zainteresuję programowaniem :D

na razie piszę w sumie kolejne komponenty, poprawki itp i jak dopiszę wszystko czego potrzebuję to pierw port na przeglądarkę a następnie android.

W ramach odskoczni stwierdziłem że wezmę się troszkę za te boczkowe skryptowanie. Można zamiast Script stworzyć obiekt VisualScript i tworzyć kod bloczkami. Od Begin ciągniemy linie do funkcji która ma się wykonać jako pierwsza, od tej funkcji możemy ciągnąć dalej, w ten sposób nadajemy kolejność wykonywania działań. Z prawej strony w inspektorze mamy pierw zmienne które możemy sobie dodać prawym przyciskiem myszy(na razie wersja dodawania troszkę robocza), poniżej Main Event gdzie mamy listę podstawowych eventów w silniku - te funkcje które wywołuje silnik przy tworzeniu/usuwaniu obiektu oraz Update/Render itp które wywołujemy co pętle. Ostatnia pozycja to zakładka Functions gdzie możemy dodawać swoje funkcje, powinno to pomóc przy dzieleniu "kodu" na mniejsze partie. Aktualnie nie mam za wiele klocków, tylko podstawowe jak Variable(w nim wybieramy którą zmienną ma reprezentować i taki typ zwraca), String/Int/Float(możemy tam wpisać dany typ), MousePosition(zwraca mouse X/Y) i DrawText.. Do testów wystarczyło, działa już generowanie kodu C# na podstawie VisualScript więc pomału zabiorę się za if/else/while/for itp itd. Muszę dodać także bloczek Return, ale no.. wszystko w swoim czasie :D

Do shaderów też zrobisz?
Mógłbyś zrobić lepszy Shader Graph.
Bo tam jest bloczek Branch. https://docs.unity3d.com/Packages/com.unity.shadergraph@6.9/manual/Branch-Node.html
Ale on nie powstrzymuje kodu True/False przed wykonaniem. Branch tylko zwraca wartość zależną od predykatu.
Gdyby Twoja wersja potrafiła lepiej zmieniać Branch na kod, to było coś ;)
O ile to nie koliduje z działaniem takiego grafu, to warto by było taki upgrade wprowadzić.

Tak chcę to pierw napisać by działało, dobrze generowało kod i wtedy planuję napisać edycję shaderów, może i kilka dodatkowych zastosowań jak ustawianie zachowań NPC w grze, ustawianie animacji itp.

Nie do końca rozumiem do końca o co chodzi z Branch - zwraca true lub false zamiast 4 float czy jak? Nie robiłem shaderów w tych bloczkach

Wiesz co, dałem łapkę za implementację tego edytora bloczków (bo elegancki), ale nie za bardzo rozumiem jakie jest jego przeznaczenie i co ten edytor ma ułatwić.

Czy jego przeznaczeniem jest ”programowanie wizualne”, polegające na klikaniu bloczków, które następnie zostaną automatycznie przekonwertowane na kod źródłowy? Czyli klika się bloczki zamiast pisania kodu?

Michał Skovv napisał(a):

Nie do końca rozumiem do końca o co chodzi z Branch - zwraca true lub false zamiast 4 float czy jak? Nie robiłem shaderów w tych bloczkach

W zależności od wartości Predicate, Out przyjmuje wartość podaną w True albo False.

if (Predicate == 1)
{
  Out = TrueIn;
}
else
{
  Out = FalseIn;
}

Problem w tym, że to co podajemy do True albo False i tak jest obliczane.
Branch tylko decyduje, która liczba idzie do Out.

To jak miałoby to wyglądać według Ciebie?

flowCRANE: Tak, w sumie jest to do graficznego programowania. Planuję też takim sposobem programować shadery itp

Michał Skovv napisał(a):

flowCRANE: Tak, w sumie jest to do graficznego programowania. Planuję też takim sposobem programować shadery itp

Shadery to rozumiem, że w ten sposób fajnie i wygodnie się klika, ale jeśli chodzi o normalną logikę, to nie wyobrażam sobie tworzenia kodu w ten sposób — to absurd, ani to wygodne, ani ułatwiające pisanie/debugowanie.

Chyba że to narzędzie przeznaczone jest dla tych, którzy nie potrafią programować? Bodaj RPG Maker daje możliwość stworzenia całej gry, bez konieczności pisania choćby linijki kodu, więc to była zaleta Twojego edytora i przepustka dla tych, którzy nie potrafią programować i/lub nie chcą się uczyć jężyka.

Ogółem ja też nie jestem fanem tego typu programowania, dlatego dodaje kilka usprawnień dzięki którym możemy dzielić sobie "kod" na pomniejsze funkcje - będzie mniejszy syf na planszy. Druga sprawa, że np w Unreal Engine jest to dość popularne, ogrom osób tego używa :D Ja zrobię to po swojemu, postaram się to fajnie zgrać z silnikiem by ułatwiało. poza tym jak masz mały obiekcik który ma robić dosłownie z 3-4 rzeczy to myślę że jeśli dodam funkcje troszkę wyżej poziomowe robiące coś więcej niż DrawText to może to być nawet szybsze i wygodniejsze od kodu

Michał Skovv napisał(a):

To jak miałoby to wyglądać według Ciebie?

Żeby Branch generując kod shadera wrzucał całą logikę podpiętą pod True/False jako warunkowe wykonanie kodu.

Czyli takie coś:

if (Predicate == 1)
{
  Out = ObliczeniaDlaTrue();
}
else
{
  Out = ObliczeniaDlaFalse();
}

zamiast:

TrueIn = ObliczeniaDlaTrue();
FalseIn = ObliczeniaDlaFalse();

if (Predicate == 1)
{
  Out = TrueIn;
}
else
{
  Out = FalseIn;
}

Michał Skovv napisał(a):

Druga sprawa, że np w Unreal Engine jest to dość popularne, ogrom osób tego używa :D

W C++ łatwiej napisać kod, który robi crash, albo wyciek pamięci.
Blueprint jako alternatywa tutaj daje trochę poczucia bezpieczeństwa.

Owszem użytkownicy czasem się szczycą tym, że niby tworzą grę bez doświadczenia w programowaniu...
Ale programowanie bloczkami to też programowanie. Tylko poziom abstrakcji inny.

I oni serio tak to napisali? Po co liczą 2 wersje :D

Michał Skovv napisał(a):

Druga sprawa, że np w Unreal Engine jest to dość popularne, ogrom osób tego używa

Takie rozwiązanie jest często wykorzystywane z jeszcze jednego powodu:
pracując nad grą w zespole, programista definiuje metody/bloczki typu: pokaż dialog X, dodaj przedmiot Y, zwiększ statystyke Z o wartość N;
a następnie designer/level designer/inna-osoba-odpowiedzialna-za-temat używa ich, żeby tworzyć narracje, questy, zachowania gry w różnych sytuacjach.
W ten sposób programista nie traci kolejnych godzin zmieniając kod, bo zmieniło się coś w fabule czy mapie gry.
Część danych można oczywiście wyłuskać do zewnętrznych źródel (tabele z danymi o przedmiotach/postaciach/questach) jednak tam, gdzie potrzebne np. instrukcje warunkowe, to jest mega przydatne.

Michał Skovv napisał(a):

I oni serio tak to napisali? Po co liczą 2 wersje :D

Raczej serio...

Może dlatego tak zrobili, bo możesz użyć wartości każdego bloczka w różnych miejscach grafu, nie tylko w Branch i taka implementacja wydała się im najlepsza.
Inaczej każdy endpoint rozgałęzienia robiłby te same obliczenia. To zamiast przyspieszyć, spowolniłoby shader.
Chyba mogliby zrobić implementację uwzględniającą dwa warianty. Obecna implementacja pewnie generalnie jako tako się sprawdza...

Zapytałem ChatGPT:

Czy Branch w Shadergraphie zapobiega obliczeniom dla False, jeśli Predicate jest True?

Krótko: nie.
W Shader Graph Branch nie zatrzymuje obliczeń w gałęzi „False”, gdy „Predicate” jest True (i odwrotnie). Obie gałęzie są zazwyczaj wyliczane wcześniej, a Branch tylko wybiera wynik. To zachowanie wynika ze sposobu generowania kodu – wejściowe pod-grafy są obliczane do tymczasowych zmiennych, a potem następuje wybór wartości.

Co to znaczy w praktyce

• Jeśli w gałęzi masz ciężkie operacje (np. kilka próbek tekstur, pętle, szum), to zostaną policzone niezależnie od wyniku Predicate.
• Branch jest dobre do wyboru wartości (np. między dwoma kolorami), ale nie do sterowania „czy coś liczyć”.

Jak naprawdę pominąć obliczenia

1. Static Switch + Keyword (kompilacja warunkowa)

   • Dodaj Boolean/Enum Keyword w Graph Inspector i użyj węzła Static Switch.
   • Nieużywana gałąź jest wycinana przy kompilacji → kod (i koszty) naprawdę znika.
   • Dobre dla przełączników „na materiale” / „na buildzie” (shader_feature/local).

2. Custom Function (HLSL) z if

   • Zamknij ciężką logikę w Custom Function i decyduj if(...) { ... }.
   • Uwaga: na GPU z dywergencją (różne wyniki w obrębie tego samego warpa/wave) sprzęt może i tak wykonać obie ścieżki dla różnych pikseli, ale przynajmniej nie oblicza gałęzi, gdy warunek jest globalnie równy (np. uniform) lub spójny.

3. Rozdzielenie na passy/kolejkę renderowania

   • Czasem taniej jest policzyć „ciężką” rzecz w osobnym passie lub kamerze i używać wyniku wtórnie.

Szybkie wytyczne

• Chcesz oszczędzić czas GPU? Użyj Static Switch (kompilacja) albo Custom Function + if (wykonanie).
• Tylko wybierasz wartość? Branch jest ok — ale nie licz na oszczędność pracy po drugiej stronie.
• Unikaj wkładania drogich Sample Texture / szumów w obie gałęzie Branch, jeśli Twoim celem jest performance.

Jeśli podasz, co dokładnie chcesz warunkowo „wyłączyć”, podpowiem najprostszy wariant (Static Switch vs. Custom Function) i jak to połączyć w Twoim pipeline (URP/HDRP).

Nie było łatwo ale w końcu If/ElseIf działa :D

Klocek If działa tak, że podpinamy mu bool(albo zmienna albo ręcznie wprowadzane bool(klikany), dodam niebawem klocki do obliczeń (xx == / != / >= / ... yy)). Mamy 3 output - true(kiedy warunek jest prawdziwy[if(coś){...}), false - czyli else(na koniec ifa po wszystkich elseif) oraz na środku elseif do których możemy podłączyć klocki ElseIf. Tym sposobem możemy sobie tworzyć warunki if(..){ ..} else if(..) {... } else if(!...) { ... } else if(.....) {.. } else{ .. } - dowolną ilość else if.
Klocek ElseIf działa tak że możemy podpiąć albo pod true albo pod false linie funkcji do wykonania w przypadku true(if(warunek) { ciąg true }) lub false(if(!warunek) { ciag false }). Można też mu podpiąć else if który będzie kolejnym else ifem po tym.

szkoda na to w ogóle czasu

@obscurity No tak, teraz to już na forum dla programistów nie można pogadać o programowaniu. Bez planu biznesowego jak konkurować z korporacją to nawet nie podchodź.

czyli robisz ograniczoną kopię unity? [...] lepiej otworzyć zewnętrzne IDE tak jak unity [...] wkupić się w oficjalny team unity?

Ale masz fiksację, aż boli. Z całym szacunkiem do OPa ale nie wiem jak Ty tu się dopatrzyłeś podobieństw do unity. Jedyne podobieństwo jakie widzę na pierwszy rzut oka to skryptowanie w C# i fakt, że można w tym podobno zrobić grę. Czekaj czekaj, Ty wiesz że inne silniki istnieją? I profesjonalne i hobbystyczne?

Nawet skryptowanie jest żywcem zerżnięte

Skryptowanie w C# to dzisiaj codzienność, może nie każdy silnik ma ale nie trzeba też za daleko szukać. Bo wiesz, tak odpowiadając na moje własne pytanie, istnieją też inne silniki poza unity.