Warsztat.GD

Programowanie => Silniki => Wątek zaczęty przez: XPietrucha w Listopad 30, 2012, 18:32:26

Tytuł: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 18:32:26
Witam wszystkich!

Jestem po raz pierwszy na forum, długo już śledzę warsztat ale dopiero
teraz postanowiłem poprosić was o radę.

Napisałem sobie swój Framework.


+ jeszcze napisałem w wolnych chwilach moduł matematyczny i pomocnicze struktury.


Świetnie pisze mi sie na tym różne rzeczy, tylko chciałbym to bardziej rozszerzyć.

Ostatnio naszła mnie ochota napisania silnika. Tak wiem, projektów silnika jest nie ukończonych 99%
na całym warsztacie, ale Silnik chciałbym pisać dla gry (Zebrałem prostą ekipę [oczekują na start pracy]), tak więc nie będzie to nieskończony projekt.
Framework jest mało użyteczny jeśli chodzi o bardziej skomplikowane rzeczy, gdzie implementację różnych efektów trzeba pisać samemu.

(Silnik ten chciałbym później mieć jako ukończony projekt, który pomoże mi w przyjęciu do jakiejś firmy.)

Mam do was jedno ważne pytanie, co musi wchodzić w skład silnika gry.
Chciałbym dowiedzieć się na tyle, abym mógł zacząć przerabiać mój framework na poważny silnik.

Mam dopiero 16 lat (zaraz 17 :D).
Jeśli macie jakiś zastrzeżenia co do mojego stanu wiedzy dot. programowania, matematyki i fizyki to:

1.Więc, bardzo chciałbym sie dowiedzieć z czego powinien składać się Silnik Gry (z jakich modułów i co powininen zawierać w sobie).
2.Pod jaką bibliotekę pisać: pod DirectX czy dokończyć naukę OpenGL i pisać właśnie w OpenGL ?

P.S. Jeżeli macie jakieś artykuły, książki dotyczące architektury silnika, z czego się składa, to chętnie bym chciał zobaczyć tytuły lub linki ;).

Uhhh... Ale się napisałem.
To chyba na Tyle. Jeżeli nadal jakoś wątpicie, że nie podołam napisać czegoś takiego, to pytajcie.
(Jeżeli nawet tego nie napiszę, to chciałbym spróbować, bo bez próbowania nic by nie było.)
Pozdrawiam.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: 11 w Listopad 30, 2012, 18:38:14
Jeśli chodzi o uniwersalny silnik gry, to przejrzyj sobie listę ficzerów Unreal Engine'u i sam sobie odpowiedz, czy jesteś w stanie to napisać. ;)

http://www.unrealengine.com/en/features/
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 18:44:36
Nie chodzi mi o uniwersalny, bo w pojedynkę nie skończę tego przed 30 ;).

Chodzi mi o silnik RPG (może MMORPG, ale z tego co widać na warsztacie, projekty te nie dochodzą do końca), Świat 3D, Kamera (Styl Skyrim lub Gothic (albo wiedźmin), coś takiego [tryb 3-osobowy])..

coś na ten styl Silnik, tylko co powinien zawierać i co powinien robić, bo Unreal Engine 3, to jest "jedna wielka masa" wszystkiego :D
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: asmen w Listopad 30, 2012, 18:48:26
Chodzi mi o silnik RPG (może MMORPG, ale z tego co widać na warsztacie, projekty te nie dochodzą do końca), Świat 3D, Kamera (Styl Skyrim lub Gothic (albo wiedźmin), coś takiego [tryb 3-osobowy])..

I doszliśmy do sedna sprawy... :D
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 18:52:30
No tak, założenia mam, tylko
Co ma być w tym Silniku, żeby nie trzeba było, dowalać dodatkowych rzeczy, jak czegoś nam zabraknie np.

Wiem, że będę potrzebował języka skryptowego (swój ? nie bardzo, może LUA), ale nie napiszę go sobie (taki przykład z życia: zapomnienie) i w środku tworzenia gry zdam sobie sprawę, że nie mam tegoż w silniku i trzeba będzie tworzyć sobie to i sprawdzać, czy wszystko działa (u mnie to może być możliwę błędami i utratą włosów na głowie xD).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: flexi w Listopad 30, 2012, 18:58:24
Zadaj se pytanie co bedziesz potrzebowal w takiej grze, wtedy bedziesz wiedzial co zaimplementowac.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 18:59:13
W silniku jest Hierarchia, zależności pomiędzy klasami, nowe rzeczy, których będę musiał się chyba nauczyć, ale Jakie np. Moduły by tam musiały być i co będą mogły robić ... (takie podstawowe założenie, silnik będzie złożony z modułów)

Robiąc grę w Ogre -> u nich wg. mnie jest duży (WIELKI) nie porządek, za dużo klas i struktur, wszystko pomieszane. Ja to bym chciał zrobić, abym ja (i późniejsi użytkownicy silnika (w razie wydania na świat)) mógł w łopatologiczny sposób wiedzieć co gdzie i jak ... a nie tak jak w przypadku ogra.
(http://www.ogre3d.org/docs/api/html/ <- Opis Całego Ogra -,-, tam to trzeba umieć szukać, czasem coś znaleźć jak pisałem, to była męczarnia (ale udawało się))
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: flexi w Listopad 30, 2012, 19:26:52
Ogre to silnik graficzny, a nie silnik gry.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: .:NOXY:. w Listopad 30, 2012, 19:35:13
Najprostrzy sposob jak zrobic gre to taki zeby ja robic, pisz strukturalnie, w sposob zorientowany na dane, uzywaj gietkiego jezyka najlepiej jakiegos prostego jak objC czy cos podobnego. Jezeli chodzi o pisanie silnikow just don't. Wierz mi to jest never ending story. A jest tu paru takich co by moglo o tym mowic tygodniami. Czego to juz nie dodali do swojego 7silnika. No offence ale taka jest prawda albo sie pisze gry albo silniki tu nie ma za bardzo drogi pomiedzy.

Ach i jeszcze jedna rada, jak chesz sie brac za MMO to zacznij uczyc sie pisania multi, zlozonej sieciowosci, przesylania tony danych w 1/10 predkosci swiatla itp. Bo bez tego padniesz na samym poczatku. MMO to nie LAN.

To sa poprostu rzeczy trudne, nie mowie ze awykonalne ale wymagaja doswiadczenia na warsztacie jest duzo osob ktora ma za soba parenascie lat doswiadczenia w programowaniu, czesc z tych osob prawie caly ten czas poswiecilo w branzy. A jednak nikt sie na RPG / MMO nie porywa. Tego sie poprostu nie da zrobic w pojedynke.

Sorry za trucie, takie sa realia. To nie jest bajka, to walka z wiatrakami. Predzej uda ci sie ukonczyc srednio zaawansowany 3rd person shooter ala Gears of War, niz RPG/MMO ach no i trzeba jeszcze brac poprawke na postep technologiczny.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 19:35:52
No wiem, że OGRE to silnik graficzny (po samym rozwinięciu nazwy), ale pisałem na tym gierkę (a raczej coś co było podobne do gry, bo zbyt długie to to nie było), dodawałem kilka własnych rzeczy, ale ja ogólnie odwołałem się do wyglądu tamtego zorganizowania kodu (w sensie klas itp.)

Aktualnie pisze sobie jak to powinno wyglądać (Silnik). To czy moglibyście mi powiedzieć, co miało by się znaleźć w silniku (jak podam taki rys i co muszą robić), żeby dopełnić ten opis. (jakieś 15 min.)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: 11 w Listopad 30, 2012, 19:37:45
A jednak nikt sie na RPG / MMO nie porywa. Tego sie poprostu nie da zrobic w pojedynke.
Dużo ludzi z powodzeniem dałoby sobie radę ze zwykłym, single player RPG. Nie wiem, po co łączysz to z MMO.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: .:NOXY:. w Listopad 30, 2012, 19:41:07
Dużo ludzi z powodzeniem dałoby sobie radę ze zwykłym, single player RPG. Nie wiem, po co łączysz to z MMO.

Bo 90% ludzi ktorzy chca robic RPG musza je robic jako MMO (no wlasnie nie wiedzac dlaczego nikt sie nie porywa na stare dobre cRPG)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 19:48:00
@.:NOXY:.
Silnik chciałbym pisać w C++, bo w nim się czuję najlepiej. Jak już napisałem co do MMO to "Porywanie się z motyka na słońce". Wolę napisać coś co ukończę niż babrać się do śmierci i porzucić projekt.

Wg. mnie napisanie grywalnego RPG'a to Silnik + Fabuła + Ładna Oprawa Graficzna i Dźwiękowa.
Ostatnią rzeczą zajmą się moi znajomi i wolne assety w internecie (Znajomi też w tym siedzą już (po części dzięki mnie ^ ^)), a w internecie też jest bardzo dużo darmowych rzeczy / nie drogich.
Silnik chciałbym napisać ja, fabułą też bym się zajął (wyobraźnie mam, pomysł także).
Poza tym oprócz samego faktu gry na własnym Silniku, to pozostaje nam fakt, że własny Silnik byłby dobrym podparciem pod nowe projekty (jeżeli pierwszy w ogóle wypali), a poza tym jest to dobry punkt w przyjęciu do pracy (tak wyczytałem bynajmniej, chociaż jest to najmniejszym punktem)

50% osób zadowoli sama oprawa graficzna i dźwiękowa i możliwości postaci :D

@@@Napisałem Sobie Taki o to "Rys Silnika":

To jest taki początek czyli

Render, Input i Sound.


Chciałbym mieć także klasę Root, która by zarządzała innymi modułami, oraz robiła nadrzędne rzeczy w silniku (... sam nie wiem co :D)

Nie wiem czy implementować Manager (Zasobów np. Tekstur, Modeli, Efektów itp.)?
Nie lepiej ładować zasoby na starcie i trzymać gdzieś w pamięci i tylko się do nich odwoływać
w razie potrzeby ?

Czego mi tutaj jeszcze brakuje ?
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: asmen w Listopad 30, 2012, 20:02:26
Cytuj
Wg. mnie napisanie grywalnego
RPG'a to Silnik + Fabuła + Ładna
Oprawa Graficzna i Dźwiękowa.

Mylisz się i to bardzo. Gdzie w tym wszystkim gameplay, mechanika?
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 20:03:07
A wybacz, pisałem to z tym RPG bez przemyślenia ;).

To co mi poradzacie ?
pisać od razu grę, bez silinika ?
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: MoHeR w Listopad 30, 2012, 20:28:56
Jesli chcesz wiedziec, czego Twoj silnik potrzebuje, to zacznij pisac gre i dodawaj do silnika to, czego aktualnie potrzebujesz :P Jesli skonczysz ta gre, to wiesz, ze masz wszystko, co potrzebne, aby napisac gre :P
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 20:37:04
Pomysł fajny, tylko nie wiem czy u mnie to wyjdzie dodawać różne rzeczy podczas pracy. Zawsze robiłem najpierw projekt, lub cokolwiek, dopiero potem na tym tworzyłem (kiedy już miałem tak fajnie z górki).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: mihu w Listopad 30, 2012, 20:42:54
Jesli chcesz wiedziec, czego Twoj silnik potrzebuje, to zacznij pisac gre i dodawaj do silnika to, czego aktualnie potrzebujesz :P Jesli skonczysz ta gre, to wiesz, ze masz wszystko, co potrzebne, aby napisac gre :P
+1.

Cytuj
To co mi poradzacie ?
pisać od razu grę, bez silinika ?
Co rozumiesz przez pisanie gry bez silnika? Zawsze tworzy że jakąś część silnikową (chyba że masz na myśli użycie gotowego middleware). Linia między grą a silnikiem może się oczywiście rozmywać i nie jest to nic złego. Po prostu piszcie grę. Zestaw niskopoziomowych funkcjonalności, które powstaną, można nazywać silnikiem gry (jeśli koniecznie chcesz tej nazwy używać).
Jeśli zamierzacie tworzyć grę, to równoległe pisanie silnika, który z założenia ma być odseparowany, uniwersalny (a nie dostosowany pod aktualny projekt) to w waszej sytuacji (i pewnie w prawie każdej innej) automatyczne skazywanie się na niepowodzenie.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: 11 w Listopad 30, 2012, 20:44:54
To co mi poradzacie ?
pisać od razu grę, bez silinika ?
Pisać grę, a w trakcie pisania elementy, które należą do silnika (są na tyle generalne, że da się używać w innym projekcie) wrzucać do osobnego modułu.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Cerberus w Listopad 30, 2012, 20:51:28
Mocno polecam Ci ściągnąć UDK i pobawić się z tym chociaż trochę. Zrób mapkę z dwoma domkami i górką, zaskryptuj w kismecie włącznik światła w ciemnym pokoju, w unreal scripcie zrób własny rodzaj broni (dziedziczący oczywiście po już istniejącym, a niech się tylko fireratem różni). To Ci może dać jakieś pojęcie, jak wygląda praca na gotowym silniku.

Ta Twoja rozpiska potrzebnych rzeczy nie wygląda źle, z ważnych rzeczy do brakuje Ci zarządzania gameplayam i obiektami gry (czyli skryptowanie najpewniej), jakiś AI, jakaś fizyka (podpiąć zewnętrzna bibliotekę, nawet nie myśl żeby zrobić inaczej, ale to trzeba zrobić na początku) no i animacje. Generalnie zasada jest taka, że jeśli na czymś się znasz, zrobienie tego zajmie 3 razy więcej czasu niż zakładasz. A jeśli się nie znasz, 8 razy więcej ;)

Żeby to przedsięwzięcie miało szanse powodzenia, to zaprojektuj sobie ten silnik, ale w pierwszej kolejności rób tylko niezbędne rzeczy. Zaryzykuje stwierdzenie, że do zespołowego tworzenia bardziej rozbudowanej gry najważniejszy jest edytor plansz. Jak będziesz na etapie, że masz program, który wyświetla mapę, możesz wrzucić tam dwa sześciany i stożek, zapisać do pliku i odczytać po ponownym uruchomieniu, to już będzie solidna baza.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: rhdbisgrt w Listopad 30, 2012, 20:52:02
Witam wszystkich!

Jestem po raz pierwszy na forum, długo już śledzę warsztat ale dopiero
teraz postanowiłem poprosić was o radę.

Napisałem sobie swój Framework.

  • Obsługa Okna
  • Logger
  • Parser komend we własnej konsoli (ala. logger lub pomocnicze okno podczas sprawdzania błędów :D)
  • Tworzenie urządzenia Direct3D
  • Renderowanie Sceny
  • Rysowanie Prymitywów
  • Wczytywanie obiektów (modeli) z pliku

+ jeszcze napisałem w wolnych chwilach moduł matematyczny i pomocnicze struktury.


No to gratuluje, masz mw polowe ilosci lat ktore ja
osobiscie posiadam i wyniki mamy podobne, (bo ja tez kawalek wlasnego frameworka, para rzeczy przetrenowane & so)

Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 20:56:23
@mihu
jeżeli kierowałeś to do mnie, to błędnie napisałeś o moim postanowieniu do silnika. Nie mam zamiaru pisać ogólnego, uniwersalnego silnika, tylko Silnika pod moją grę, którą mam zamiast ukończyć, a tak jak napisałeś silnik tak czy siak będzie napisany, czy to zrobimy jawnie (sami go napiszemy świadomie), czy napiszemy go w formie niejawnej podczas tworzenia gry, tylko tutaj według mnie inne jest jak to będzie napisane.

Ponieważ myśląc nad Silnikiem z ogólu będziemy myśleć nad tym jak on będzie wyglądał, jak będziemy na nim coś tworzyć, a tworząc grę będziemy robili zestawy funkcji i klas, które nam się przydadzą i pozwalają uporządkować kod.

Takie przynajmniej wg. mnie jest myślenie o tworzeniu gry, a silnika odłącznie.

@@
Właśnie zapomniałem, że razem z Silnikiem warto dołączyć (czytaj. Zrobić) Narzędzia ... typu Edytory, podstawa to Edytor Świata.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Listopad 30, 2012, 21:26:58
Pytania dot. Edytora.

W jakim języku napisać Edytor ? ... Bardziej wygodnym byłby C# z platformą .NET.
Renderer napisać w C++ ... Bardzo wydajny język, a sam Edytor (który nie potrzebuje wydajności,
a Ładny i Kompatybilny z każdym użytkownikiem Interfejs, który użytkownik będzie mógł dostosować)

Narysowałem i opisałem wstępnie jak miałby wyglądać właśnie ten Edytor. Napiszcie mi co można by w nim poprawić. (Przeczytajcie opisy, bo tam jest dużo więcej niż samo ustawienie okien).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: flexi w Listopad 30, 2012, 22:03:13
Rob w tym ci bedzie najwygodniej :-)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Cerberus w Listopad 30, 2012, 22:13:28
Edytor wraz z GUI też da radę napisać w cpp + qt albo wixwidget albo jeszcze coś innego.

Gorąco zachęcam do zrobienia researchu, najpierw przejrzyj gotowe i sprawdzone rozwiązania, potem projektuj swoje.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Listopad 30, 2012, 22:53:16
Z własnego doświadczenia: każda biblioteka GUI z którą się zetknąłem i która nie jest Immediate Mode jest na dłuższą metę PITA.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Kos w Listopad 30, 2012, 22:58:24
Z mojego doświadczenia j.w., może poza "która nie jest Immediate Mode" :-).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Paweł w Listopad 30, 2012, 22:58:49
co to znaczy pita?
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: 11 w Listopad 30, 2012, 22:59:50
Pain In The Ass?
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Paweł w Listopad 30, 2012, 23:19:25
No, muszę zgodzić się z Kosem, próbowałem imgui np. tu: http://warsztat.gd/screen/9482/gui_na_ukonczeniu ale też lekko z tym nie było, a chcąc robić layoutery i tak trzeba znać rozmiary kontrolek w kontenerze, czyli trzeba je i tak przechowywać kontrolki po stronie gui.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Listopad 30, 2012, 23:29:22
No, muszę zgodzić się z Kosem, próbowałem imgui np. tu: http://warsztat.gd/screen/9482/gui_na_ukonczeniu ale też lekko z tym nie było, a chcąc robić layoutery i tak trzeba znać rozmiary kontrolek w kontenerze, czyli trzeba je i tak przechowywać kontrolki po stronie gui.
Nie twierdzę, że Immediate Mode zrobi z każdego GUI rzecz idealną.

A do zrobienia layoutu nie potrzebujesz rozmiaru kontrolek. printf daje sobie radę bez tego, a jeżeli chcę nawet wypełnić całą linię okna kontrolkami, to wcześniej deklaruję podzielniki. W przypadku mojego własnego GUI stan zaczyna się dopiero na poziomie całych okien, bo tam już gdzieś trzeba pamiętać układ, pozycje i rozmiary.


A końcowy efekt wygląda tak: ;)
(http://devkk.net/files/4ktool.jpg)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Kurak w Listopad 30, 2012, 23:47:42
I potem powstaje potworek z customowym GUI w rodzaju Blendera który swoim działaniem nie przypomina żadnego innego wytworu człowieka :) Ofc jeśli kroi się edytor pod siebie to wygodne bo zna się działanie tego doskonale, ale typowy użytkownik będzie miał dużo większy problem żeby tego zacząć używać bez czytania masy tutoriali (które też ktoś musi napisać). W ogóle wybieranie liba do GUI przez pryzmat tego w czym wygodnie się pisze jest co najmniej dyskusyjne - różnice wcale takie wielkie nie są, a toole nie są od tego żeby je się przyjemnie pisało tylko żeby użytkownik końcowy mógł ich efektywnie używać.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Paweł w Grudzień 01, 2012, 00:32:43
Noo, kozacko to wygląda. Ciekawi mnie jak zrealizowałeś to drzewko w rogu po lewej? W klasycznym imgui trzeba by dla każdego "liścia" zdefiniować położenie oraz etykietę. Do tego chcąc mieć możliwość dodawania i przesuwania liści dynamicznie (przez użytkownika), to trzeba dla nich i tak stworzyć Vector<Pair<Rect, String>> plus do tego dane logiki. Jak z góry znasz proporcje jakie mają mieć okienka to wszystko jest ok. Chodzi mi o to że i tak dane o położeniu przycisków oraz okien trzeba gdzieś trzymać, w podejściu imgui to użytkownik musi się o to troszczyć. Natomiast podoba mi się sprawdzanie stanu przycisków w imgui. Jednak mamy już c++11, tak więc to co w imgui wygląda tak:
if(doButton("name"){
  action();
}
moze w 'klasycznym' podejściu wyglądać tak:
window.addButton( Button("text").setOnClick([&](){action();}) } );
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 01, 2012, 01:38:19
Cytuj
W ogóle wybieranie liba do GUI przez pryzmat tego w czym wygodnie się pisze jest co najmniej dyskusyjne - różnice wcale takie wielkie nie są, a toole nie są od tego żeby je się przyjemnie pisało tylko żeby użytkownik końcowy mógł ich efektywnie używać.
To chyba za mało tooli pisałeś. ;)

Generalnie każda rzecz, którą robi się w gamedevie będzie dwa razy lepsza jeżeli będzie w postaci wygodnego toola. A tooli ludzie nie piszą wyłacznie dlatego, że programowanie GUI jest czasochłonne i irytujące. Używanie wygodnego GUI ma wręcz kluczowe jak dla mnie znaczenie. Na tyle kluczowe, żeby znaleźć motywację do przemęczenia się i napisania swojego raz a dobrze.

Cytuj
Ciekawi mnie jak zrealizowałeś to drzewko w rogu po lewej?
W ten sposób, że iterujesz po swojej tablicy gdzie trzymasz bloczki (zawierające predefiniowaną strukturkę), a system GUI już je renderuje i zmienia zawartość wedle uznania.

Cytuj
Jednak mamy już c++11, tak więc to co w imgui wygląda tak:
if(doButton("name"){
  action();
}
moze w 'klasycznym' podejściu wyglądać tak:
window.addButton( Button("text").setOnClick([&](){action();}) } );
Skoro takiś kozak to przepisz to:
static bool tab[10][10];
for(int y=0;y<10;y++)
{
    for(int x=0;x<10;x++)
        if(Button(tab[x][y] ? "X" : "-"))
            tab[x][y] = !tab[x][y];
    NewLine();
}

Poza tym lambda utrudnia o tyle, że nie masz w ogólności pojęcia kiedy się Twoja lambda odpali.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Paweł w Grudzień 01, 2012, 03:28:54
Do tego mogę jeszcze dorzucić przeciąganie przycisku prawym przyciskiem myszy:static bool tab[10][10];
for(int y=0;y<10;y++)
{
  for(int x=0;x<10;x++)
    window.add(Button().setOnEvent([&, =x,=y]() {
      switch( window.getProcessedEventType() ){
        case LMB_RELEASED:
          window.getProcessedButton()->text = tab[x][y] ? "x" : "-";
          tab[x][y] = !tab[x][y];
        break;
        case RMB_DOWN:
          window.getProcessedButton()->position = getMousePosition();
        break;
    });
  window.layouter.newLine();
}
Ale nigdy czegoś takiego nie zaimplementowałem w przeciwieństwie do imgui :) Choć wygląda całkiem nieźle.

Cytuj
W ten sposób, że iterujesz po swojej tablicy gdzie trzymasz bloczki (zawierające predefiniowaną strukturkę), a system GUI już je renderuje i zmienia zawartość wedle uznania.
No właśnie, tylko ze jak masz:struct MyPredefStruct{};
vector<MyPredefStruct> guiBlocks;
to równie dobrze możesz mieć:struct MyButton : Button{};
vector<MyButton> guiButtons;
A to nie jest już imgui, bo wprowadza stan, dochodzi konieczność inicjalizacji itd.

Ostatnio myślałem nad takim rozwiązaniem ( o nie, znowu bedę kodził gui zamiast gry ;) ):
Gui gui("layout.gui");

while(true)
{//main loop
  if(gui.check("button1_left_released") ){
    gui.getCheckedButton()->text = tab[x][y] ? "x" : "-";
    tab[x][y] = !tab[x][y];
  }
  if(gui.check("button1_right_down") ){
    gui.getCheckedButton()->position = getMousePos();
  }
}
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 01, 2012, 13:21:16
Cytuj
No właśnie, tylko ze jak masz:
struct MyPredefStruct{};
vector<MyPredefStruct> guiBlocks;
Możesz tak mieć, ale nie musisz. Predefiniowana struktura może być pochowana w dowolnych miejscach, bo Ty iterujesz po niej (i to jednokrotnie). W praktyce wychodzi IM, bo podajesz parametry samemu co klatkę, tyle że przez strukturę bo tych parametrów jest dużo. Ale nikt nie zmusza Cię do trzymania tych struktur gdziekolwiek (możesz w każdej klatce budować je od nowa osobno dla każdego obiektu).

Cytuj
A to nie jest już imgui, bo wprowadza stan, dochodzi konieczność inicjalizacji itd.
A kto mówił że jest to w 100% czyste IM GUI? To jest po prostu zrobione tak, by pisało się pod to jak najłatwiej. :)

Poza tym przegiąłeś trochę przykład. To, że do IM GUI da się dołożyć warstwę żeby stracić IM to chyba oczywiste. Główną zaletą jest to, że nie musisz tego robić.

Cytuj
Ostatnio myślałem nad takim rozwiązaniem ( o nie, znowu bedę kodził gui zamiast gry ;) ):
Wygląda bardzo słabo, powiem szczerze. Za dużo do zaklepania, za dużo do zapamiętania. :)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Grudzień 01, 2012, 13:37:28
Ja mam plan, aby Edytor był jak najmniej trudny, przynajmniej World Editor (co jest podstawą, aby świat gry ładnie wyglądał [a w RPG to też jakiś +]).
Nie próbowałem pisać w Qt ? (ale widziałem jak to wygląda [wygląd programów]).
Podstawą edytora to przynajmniej jedno okno gdzie będę mógł edytować wygląd świata w 3D i lista parametrów dla odpowiedniej rzeczy (typu światło, jakieś zdarzenie, punkt kontrolny, obiekt itp.)

Btw. Dzisiaj (kilkanaście minut temu skończyłem) napisałem pierwsze zarysy silnika i mają się dobrze (Zbieranie wejścia od klawiatury i myszy (czyli prawie cały zarys input), Renderowanie modeli (narazie .x i .obj, nad własnym to będę musiał pomyśleć (poczytać)), tekstur. Wczytywanie shadera do gry i obsługa poprzez klasę. Podstawowe światła (Point, Spot i Directional). Zalążek kamery (narazie 1-osobowa [czyli najzwyklejsza], dla testów). No i oczywiście obsługa urządzenia Direct3D i zarządzanie oknem.

A mam do was pytanie. Jakbym chciał, aby ktoś sprawdził wydajność jakiegoś demka (lub początkowej wersji gry), to jak to mam zrobić ? poprosić tutaj na forum ? czy założyć projekt na warsztacie i tam wrzucać linki do DL?
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Xion w Grudzień 01, 2012, 15:44:08
Cytuj
Generalnie każda rzecz, którą robi się w gamedevie będzie dwa razy lepsza jeżeli będzie w postaci wygodnego toola. (...)
Możesz rozwinąć, dlaczego w gamedevie taką wagę przykłada się do "otoolowania" wszystkiego? Przyznam, że to dla mnie fascynujące, bo to kolejne pole gdzie gamedev robi inaczej niż "reszta świata" :)

Normalnie programista w takiej sytuacji (tj. danych niebędących kodem, ale wpływających na wykonanie programu) wyciągnąłby po prostu jakiś format tekstowy - być może własny, ale częściej coś istniejącego a lekkiego, jak CSV czy JSON - i ustalił co tam się ma znajdować i jaką ma mieć strukturę. Najczęściej oznacza to po prostu stworzenie przykładowego pliku w ulubionym edytorze.

Potem parser to albo pikuś (jeśli rzecz jest oparta o już istniejący format), albo kilka godzin zabawy z pisaniem gramatyki i podaniem jej lokalnemu odpowiednikowi Flexa/Yacca/Bisona/etc. W rezultacie "toole" masz za darmo, bo wszystko co przetwarza tekst - począwszy od edytora, a skończywszy na grepie - będzie współpracować z twoim wynalazkiem.

Czemu więc spędzać dni/tygodnie/miesiące na tworzeniu dedykowanych programów?
* Rozumiem chęć nauki tworzenia aplikacji z GUI - umiejętności nigdy nie szkodzą. Zdziwiłbym się jednak gdybyś Ty, Krzyśku, mógł jeszcze coś z pisania takich aplikacji wyciągnąć :)
* Rozumiem że czasami z tooli korzystają nie-programiści, chociaż to też da się rozwiązać (graficy/muzycy mają swoje narzędzia, których wyjściowe formaty są znane). Ale w przypadku silnika pisanego na własnego potrzeby?...
* Rozumiem też "fun aspect", ale wydawało mi się że fajniej jest jednak pisać gry :)

Skąd więc ten 'toolism', który w studiach często prowadzi do desygnowania dedykowanych programistów do pisania tego rodzaju utili?
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 01, 2012, 16:00:56
Cytuj
Możesz rozwinąć, dlaczego w gamedevie taką wagę przykłada się do "otoolowania" wszystkiego? Przyznam, że to dla mnie fascynujące, bo to kolejne pole gdzie gamedev robi inaczej niż "reszta świata" :)
Generalnie to wszędzie się takie podejście sprawdzi.

Cytuj
Czemu więc spędzać dni/tygodnie/miesiące na tworzeniu dedykowanych programów?
* Rozumiem chęć nauki tworzenia aplikacji z GUI - umiejętności nigdy nie szkodzą. Zdziwiłbym się jednak gdybyś Ty, Krzyśku, mógł jeszcze coś z pisania takich aplikacji wyciągnąć :)
* Rozumiem że czasami z tooli korzystają nie-programiści, chociaż to też da się rozwiązać (graficy/muzycy mają swoje narzędzia, których wyjściowe formaty są znane). Ale w przypadku silnika pisanego na własnego potrzeby?...
* Rozumiem też "fun aspect", ale wydawało mi się że fajniej jest jednak pisać gry :)
Wszystko sprowadza się do jednego: czasu iteracji contentu. Gry fajnie się pisze, ale żeby była to gra to poza programem muszą powstać też assety, levele, itp. A one powstają tym szybciej, im łatwiejsze w obsłudze i bardziej WYSIWYG są toole.

Screenshot który wcześniej podesłałem przedstawia mojego toola do intra 4k. Jak inaczej bez tego wyobrażasz sobie sensowne stworzenie czegoś takiego bez dedykowanego toola?
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Pawelx156 w Grudzień 01, 2012, 18:38:44
Krzysiek K ma absolutnie rację. Dobre narzędzie to podstawa.

Ja sobie do swojej gry zrobiłem 2 programy.
1- program do textur ( wynikiem jest plik z którego korzysta gra )
2 - in-game-editor edytorek wygląda tak:
(http://onpilo.nstrefa.pl/Scr.jpg)

Nie wyobrażam sobie( choć to gra 2d ) żebym miał jakieś inne narzędzie, albo jak jaskiniowiec składał levele " Ręcznie" ( jakieś pozycje ręcznie wklepywał itp. 
A że ja poziomów czy sceneri ( menu, credist, itp ) nie składam tylko ktoś inny, więc takie narzędzie bardzo pomaga. Zwłaszcza że ten co robi poziomy ( mój brat ) to lewa noga z programowania.
A że to edytor In-game to w czasie rzeczywistym może robić poprawki, testować fragmenty mapy itp.



Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Xion w Grudzień 01, 2012, 18:44:00
Cytuj
Wszystko sprowadza się do jednego: czasu iteracji contentu. Gry fajnie się pisze, ale żeby była to gra to poza programem muszą powstać też assety, levele, itp. A one powstają tym szybciej, im łatwiejsze w obsłudze i bardziej WYSIWYG są toole.
Okej, to ma sens. Zwłaszcza w przypadku silników wielokrotnego użytku dobry toolset może rzeczywiście znacznie przyspieszyć tworzenie contentu.

Cytuj
Screenshot który wcześniej podesłałem przedstawia mojego toola do intra 4k. Jak inaczej bez tego wyobrażasz sobie sensowne stworzenie czegoś takiego bez dedykowanego toola?
Trochę trudno wywnioskować ze screenu jaka dokładnie funkcjonalność jest tam dostępna, no ale spróbujmy:

* Graf w lewym dolnym wygląda na strukturę drzewka sceny, które dałoby się zapisać w hierarchicznym formacie tekstowym. Ze względu na cross-linki pewnie konieczny byłby bardziej YAML niż JSON, który ponadto ma tę zaletę że pisze się go niezwykle szybko (praktycznie zero składni typu " czy { }). O XML-u nie wspominam, bo nikogo nie podejrzewam o taki masochizm :)

* Kod na prawo od grafu wygląda na GLSL z autorskimi dyrektywami (linie zaczynające się od @) więc to już jest w postaci łatwej do przetwarzania.

* Drzewko z plikami projektu to standardowy element dowolnego edytora.

* Nie wiem dokładnie do czego służą okienka Properties, ale strzelam że chodzi o regulowanie parametrów elementów wspomnianego na początku grafu, więc to też załatwiałby plik tekstowy grafu.

* Preview w czasie rzeczywistym to w sumie jedyna rzecz, którą należałoby dopisać do dema, tzn. observer na system plików i automatyczny reload gdy coś się zmieni. Nie sądzę, by było to trudniejsze niż osadzenie renderera we własnym edytorze.

Gdy tak patrzę na ten screen, to przychodzi mi do głowy porównanie z moim własnym setupem, gdzie ekran(y) mam podzielone na:

* edytor z kodem, skonfigurowany z opcją save_on_focus_lost
* konsolę z działającym serwerem, reloadowanym po każdej zmianie plików
* konsolę narzędziową (odpalanie testów, git-owanie, itp.)
* okno przeglądarki

Gdyby jeszcze to ostatnie potrafiło jakoś skomunikować się z serwerem i zrobić automatyczne odświeżenie strony po zmianach (plugin?...), to można by mówić o kodowaniu z iteracjami w real-time :)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 01, 2012, 19:31:10
Cytuj
Okej, to ma sens. Zwłaszcza w przypadku silników wielokrotnego użytku dobry toolset może rzeczywiście znacznie przyspieszyć tworzenie contentu.
Przyspiesza już przy pierwszej grze.

Cytuj
* Graf w lewym dolnym wygląda na strukturę drzewka sceny, które dałoby się zapisać w hierarchicznym formacie tekstowym. Ze względu na cross-linki pewnie konieczny byłby bardziej YAML niż JSON, który ponadto ma tę zaletę że pisze się go niezwykle szybko (praktycznie zero składni typu " czy { }). O XML-u nie wspominam, bo nikogo nie podejrzewam o taki masochizm :)
Jak nakłonisz dowolnego grafika do przesiadki z 3DS Max na ręczne pisanie glPushMatrix/glRotate/glPopMatrix, to się zgodzę. ;)

Cytuj
* Kod na prawo od grafu wygląda na GLSL z autorskimi dyrektywami (linie zaczynające się od @) więc to już jest w postaci łatwej do przetwarzania.
HLSL z dyrektywami. Tylko tutaj kwestia jest taka, że pod spodem siedzi tool w postaci parsera i optymalizatora HLSL pod rozmiar, co daje zyski rzędu 100-200 bajtów. Nie mam pojęcia jak chciałbyś się takiego dedykowanego toola do przetwarzania shaderów pozbyć (nie mówię tu o edytorze tekstu).

Cytuj
* Drzewko z plikami projektu to standardowy element dowolnego edytora.
True. Ale tutaj chodzi o całą resztę, która standardem już raczej nie jest.

Cytuj
* Nie wiem dokładnie do czego służą okienka Properties, ale strzelam że chodzi o regulowanie parametrów elementów wspomnianego na początku grafu, więc to też załatwiałby plik tekstowy grafu.
I tutaj dochodzimy do czułych kwestii. Z pozoru jest to zwykły property grid, ale:
- pozwala na "scrollowanie" wartości (łapiesz myszą za wartość i przesuwasz) z natychmiastowym podglądem widoku,
- pozwala na przejrzenie podobnych wartości użytych w projekcie i wybranie akceptowalnej wartości do reuse (co pozwala bardzo szybko zbić rozmiar intra przed deadlinem) - oczywiście z natychmiastowym podglądem, bo nie można tego robić w ciemno

I generalnie 90% pracy z projektem opiera się na scrollowaniu tych wartości i ustawianiu tak, żeby całość wyglądała ja najlepiej.

Cytuj
* Preview w czasie rzeczywistym to w sumie jedyna rzecz, którą należałoby dopisać do dema, tzn. observer na system plików i automatyczny reload gdy coś się zmieni. Nie sądzę, by było to trudniejsze niż osadzenie renderera we własnym edytorze.
Nie jest i poprzednie dema tak robiłem. Ale w takim układzie drastycznie wydłużasz czas iteracji. Z płynnego scrollowania dowolnej wartości w intrze i obserwacji jak to wygląda skaczesz do ~1-2s na każdą zmianę.

Wyobrażasz sobie co by było, gdybyś w przeglądarce nie miał scrollbara tylko wpisywał w osobnym pliku tekstowym ile px od góry ma zacząć się pokazywanie strony? No to tutaj było by to mniej więcej tak samo wygodne i praktyczne.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Xion w Grudzień 01, 2012, 21:11:21
Cytuj
Jak nakłonisz dowolnego grafika do przesiadki z 3DS Max na ręczne pisanie glPushMatrix/glRotate/glPopMatrix, to się zgodzę. ;)
Ale ja ci nie każę (tudzież grafikowi) modelować w pliku tekstowym. (Been there, done that, never again - ale przynajmniej dwa przedmioty na uczelni tym zaliczyłem ;)) Chodziło mi raczej o opis sceny złożonej z gotowych już modeli + ich przekształceń.

Cytuj
HLSL z dyrektywami. Tylko tutaj kwestia jest taka, że pod spodem siedzi tool w postaci parsera i optymalizatora HLSL pod rozmiar, co daje zyski rzędu 100-200 bajtów. Nie mam pojęcia jak chciałbyś się takiego dedykowanego toola do przetwarzania shaderów pozbyć (nie mówię tu o edytorze tekstu).
Wcale nie chcę się go pozbywać. Taki optymalizator to przykład narzędzi które bardzo cenię: jeden feature, tekstowe wejście, łatwe łączenie w większą całość (z kompilacją/linkowaniem/crinklerowaniem/cokolwiek strasznego robisz temu demu). Nie musi to być część jakiegoś wielgachnego dedykowanego edytora, żeby spełniało swoje zadanie.

Cytuj
I tutaj dochodzimy do czułych kwestii. Z pozoru jest to zwykły property grid, ale (...)
Więc jest to w sumie dość wyspecjalizowane narzędzie, które przypomina raczej wbudowany debugger zamiast zewnętrznego edytora. A skoro, jak twierdzisz:
Cytuj
(...) generalnie 90% pracy z projektem opiera się na scrollowaniu tych wartości (...)
to rzeczywiście takie narzędzie jest potrzebne. Tyle że jeśli użyjemy mojej analogii do webdevu:
Cytuj
Wyobrażasz sobie co by było, gdybyś w przeglądarce nie miał scrollbara tylko wpisywał w osobnym pliku tekstowym ile px od góry ma zacząć się pokazywanie strony?
to mówimy tutaj o toolu typu Firebug / Chrome Developer Tools. Różnica polega oczywiście na tym, że 90% aplikacji tam nie powstaje.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 01, 2012, 21:22:35
Cytuj
Ale ja ci nie każę (tudzież grafikowi) modelować w pliku tekstowym. (Been there, done that, never again - ale przynajmniej dwa przedmioty na uczelni tym zaliczyłem ;)) Chodziło mi raczej o opis sceny złożonej z gotowych już modeli + ich przekształceń.
Nawet jak jedynym dostępnym modelem jest sześcian i masz z niego wymodelować na przykład drzewo?

Cytuj
Więc jest to w sumie dość wyspecjalizowane narzędzie, które przypomina raczej wbudowany debugger zamiast zewnętrznego edytora.
Nie. To jest właśnie edytor. Za bardzo przyzwyczaiłeś się do kodowania, gdzie czasy iteracji są nawet rzędu minut. Przy tworzeniu contentu liczy się WYSIWYG i to niezależnie jakiego contentu.

Cytuj
Różnica polega oczywiście na tym, że 90% aplikacji tam nie powstaje.
Chodziło mi o 90% użytkowania toola. Samo użytkowanie toola to może 5-10% czasu developmentu intra. Pozostałe 90% to napisanie toola i playera. Tyle że bez toola proces robienia contentu był by morderczy na tyle, że intro by nie powstało w ogóle.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: mihu w Grudzień 01, 2012, 23:10:23
- pozwala na przejrzenie podobnych wartości użytych w projekcie i wybranie akceptowalnej wartości do reuse (co pozwala bardzo szybko zbić rozmiar intra przed deadlinem)
PROPS! Super pomysł.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Xion w Grudzień 01, 2012, 23:25:53
@Krzysiek: Drzewa z sześcianów, 90% developmentu na edytor... Coś mi się widzi, że twój case intr 4k jest trochę zbyt specyficzny ;)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 02, 2012, 00:10:17
@Xion: Jeżeli mi się opłacało 90% czasu poświęcić na toole żeby w pozostałe 10% zrobić w tym parę scen na intro, to chyba tym bardziej opłaca się poświęcić czas na toole w przypadku gier, gdzie stosunek toole:użycie nie wynosi 9:1 ale jest bliżej 1:9 w przypadku pojedynczej produkcji. Nie rozpisując się już o reuse silników i o gigantach pokroju Unity i UE gdzie ten stosunek podchodzi pewnie już pod 1:1000 000.

Ale żeby nie było jednostronnie, to mogę podać też case przeciwny - swego czasu na warsztatowe compo robiłem czarno białego FPSa, gdzie cały level składany był w Blenderze włącznie z umieszczaniem śmiesznie ponazywanych boxów jako spawn pointy i triggery, a toolchain składał się z dedykowanego eksportera w Pythonie i raytracera na CUDA (bo niestety, unwrap w Pythonie i wypalanie AO na CPU to było już jednak zbyt dużo jak na czas iteracji contentu).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Grudzień 02, 2012, 00:42:57
@@@
Panowie, tak patrząc na wasze posty, to wybiegliście daleko poza główny wątek tego tematu :D.
Przebijacie się argumentami na temat używania tooli w swoim projekcie.

A ja miałem do was jedynie pytanie na temat Silnika gry.
Ale teraz mam masę nowych pytań jak już zacząłem kodzić silnik.
Piszę go już 2 dzień (dosyć krótko), ale dopieszczam go jak się da.
Na razie wydaje mi się, że wszystko działa.

Ale męczy mnie jedno. Czy jeżeli będę już miał ten swój niezależny silnik, to modele
ładować do menadżera (Napisałem sobie prostego menadżera zasobów) w podstawowym
formacie czy napisać swój własny / ewentualnie exporter ?
NIe wydaje mi się to potrzebne, ale tak patrząc, zapobiega to ingerencji użytkownika końcowego w
wygląd gry.
Mógłbym Opakować sobie wszystkie assety w kilka zabezpieczonych i skompresowanych plików (jakiś VFS), ale to będzie dodatkowe 2 tygodnie na obczajenie jak to wszystko działa i napisanie tego jak najbardziej ładnie i optymalnie.

Co o tym sądzicie ?
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 02, 2012, 00:58:11
Cytuj
NIe wydaje mi się to potrzebne, ale tak patrząc, zapobiega to ingerencji użytkownika końcowego w
wygląd gry.
A jaki jest sens zapobieganiu takiej ingerencji? Przecież to potencjalny dodatkowy fun w modowanie.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Avaj w Grudzień 02, 2012, 10:57:31
wsadź je w zipa i zmień rozszerzenie na .dat albo .pak
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Grudzień 02, 2012, 12:09:33
Ingerencja, no owszem modowanie, ale jest jeszcze możliwość kradzieży rożnych rzeczy (modele, dźwięki, tekstury itp.). Dlatego chciałbym zrobić jakieś opakowanie / własny format z tylko mi znaną strukturą.

A wsadzenie assetów w .zip i zmiana formatu da cokolwiek (w zabezpieczniu), jeżeli nawet zwykły człowiek próbuje otworzyć dany plik (tutaj .zip) w jakimś programie (Nawet WinRAR), aby znaleźć potrzebne rzeczy. Poza tym chciałbym mieć Wszelkie zadania (Questy) umieszczone w skryptach no i użytkownik będzie mógł sobie konfigurować poszczególne zadania (już nie taki zwykły, ale obeznany) w łatwy sposób gdyby wszystko było wystawione na pokaz.

Nawet jeśli już by miał edytować, to chciałbym, żeby miał pod górkę ... wolę nie zostawiać rzeczy na pokaz, niech końcowy użytkownik widzi tylko to co ma widzieć.
Chciałbym zrobić "zamknięte drzwi"(szyfrowane, kompresowane lub spakowane pliki) dla "złodzieja"(użytkownik, który próbuje coś zmajstrować xD)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 02, 2012, 12:23:04
Cytuj
ale jest jeszcze możliwość kradzieży rożnych rzeczy (modele, dźwięki, tekstury itp.).
Zawsze jest i na to nie poradzisz.

Lepiej zrób najpierw grę, bo póki co to nie ma czego kraść. :)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: 11 w Grudzień 02, 2012, 12:25:35
Gwoli ścisłości, nie da się ukraść modeli, dźwięków, tekstur i innych assetów.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 02, 2012, 12:33:34
Gwoli ścisłości, nie da się ukraść modeli, dźwięków, tekstur i innych assetów.
Też racja. Przynajmniej do momentu gdy ktoś się fizycznie do Ciebie nie włamie i nie zabierze Ci dysku. W pozostałych przypadkach będzie to nielegalne kopiowanie.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: 11 w Grudzień 02, 2012, 12:34:28
Tak, i to tylko pod warunkiem, że uznajesz obecne "prawo" za obowiązujące. ;)
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Grudzień 02, 2012, 12:57:11
No to leciutka pomyłka ... ale o to mi chodziło "nielegalne kopiowanie", bo nie uznaję zabierania czegoś bez wiedzy tego kto to zrobił ... dla mnie to jest kradzież (chociaż nie taka fizyczna).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Krzysiek K. w Grudzień 02, 2012, 13:20:51
No to leciutka pomyłka ... ale o to mi chodziło "nielegalne kopiowanie", bo nie uznaję zabierania czegoś bez wiedzy tego kto to zrobił ... dla mnie to jest kradzież (chociaż nie taka fizyczna).
Ale przecież w tym przypadku niczego nikt nie zabiera. Nadal masz to u siebie (też).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Avaj w Grudzień 02, 2012, 13:28:09
Ingerencja, no owszem modowanie, ale jest jeszcze możliwość kradzieży rożnych rzeczy (modele, dźwięki, tekstury itp.). Dlatego chciałbym zrobić jakieś opakowanie / własny format z tylko mi znaną strukturą.

A wsadzenie assetów w .zip i zmiana formatu da cokolwiek (w zabezpieczniu), jeżeli nawet zwykły człowiek próbuje otworzyć dany plik (tutaj .zip) w jakimś programie (Nawet WinRAR), aby znaleźć potrzebne rzeczy. Poza tym chciałbym mieć Wszelkie zadania (Questy) umieszczone w skryptach no i użytkownik będzie mógł sobie konfigurować poszczególne zadania (już nie taki zwykły, ale obeznany) w łatwy sposób gdyby wszystko było wystawione na pokaz.

Nawet jeśli już by miał edytować, to chciałbym, żeby miał pod górkę ... wolę nie zostawiać rzeczy na pokaz, niech końcowy użytkownik widzi tylko to co ma widzieć.
Chciałbym zrobić "zamknięte drzwi"(szyfrowane, kompresowane lub spakowane pliki) dla "złodzieja"(użytkownik, który próbuje coś zmajstrować xD)
Generalnie możesz sobie zabezpieczać ile chcesz a ktoś komu zależy i tak ci zakosi. Modele i tekstury można przechwycić jakimś debuggerem 'graficznym' albo podstawiając lewą DLLkę OpenGLa/Direct3D. Dźwięki można przechwycić głupim rejestratorem dźwięku w windowsie przekierowując wyjście.

Zipy ze zmienionym rozszerzeniem stosuje np. Quake3 i Doom3. Gry Blizzarda też mają archiwa bez zabezpieczeń (chociaż format własny). Ogólnie to nie licząc kilku niechlubnych wyjątków, problem kradzieży assetów praktycznie nie istnieje.

Archiwa stosuje się raczej, żeby trzymać wszystko w jednym miejscu i optymalizować wczytywanie zasobów (RAM jest duuuuuuużo szybszy od dysku).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Xion w Grudzień 02, 2012, 14:55:27
Cytuj
(...) i optymalizować wczytywanie zasobów (RAM jest duuuuuuużo szybszy od dysku).
Ale gdy już coś wczytałeś do RAM-u, to chyba nie ma znaczenia, czy wcześniej było to jedno wielkie archiwum czy kilkaset plików, prawda? :) Chodzi raczej o to, że narzut systemu plików na wczytywanie tych kilkuset plików jest spory w porównaniu do otwarcia jednego uchwytu/deskryptora/file pointera/etc. do pojedynczego pliku i zassania go w całości.
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: Avaj w Grudzień 02, 2012, 15:59:11
Ale gdy już coś wczytałeś do RAM-u, to chyba nie ma znaczenia, czy wcześniej było to jedno wielkie archiwum czy kilkaset plików, prawda? :) Chodzi raczej o to, że narzut systemu plików na wczytywanie tych kilkuset plików jest spory w porównaniu do otwarcia jednego uchwytu/deskryptora/file pointera/etc. do pojedynczego pliku i zassania go w całości.
chodzi mi o to, że szybciej wczytać całe archiwum do pamięci niż wczytywać małe parokilobajtowe obrazeczki
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Grudzień 02, 2012, 17:39:40
Mówicie dobrze, że to nie ma zbytniego sensu.
Ale jak ktoś chce wziąć coś, to lepiej jest przynajmniej utrudnić, a nie zostawić
to na widoku.

Poza tym tworzenie takiego archiwum jak to napisał Xion będzie o wiele szybsze niż
wczytywanie każdego pliku z osobna.

Tak więc co jak co, ale nawet nie ze względu na kopiowanie assetów, ale
na wydajność, chyba warto takie coś uczynić

Tak przynajmniej sądzę ;).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: mihu w Grudzień 02, 2012, 17:54:17
Popełniasz podstawowy błąd - zrób najpierw coś, co ktoś chciałby kraść/coś co jest tak rozbudowane, że trzeba przyspieszać wczytywanie, potem się będziesz martwił takimi takimi rzeczami.

To trochę jak planowanie co zrobię z pieniędzmi zarobionymi na grze, której jeszcze nie zacząłem tworzyć (niezupełnie to samo, ale nieco podobnie) :).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Grudzień 02, 2012, 18:38:31
Ale ja sobie wolę najpierw zaprojektować jak to mniej/więcej ma wyglądać
i dopiero zacząć składać do całości (już zacząłem pisać dawniej), ale wciąż
wchodzą mi do głowy nowe pomysły (Microsoft OneNote musiałem włączyć i pisać pomysły [dosyć
przydatny program] i całą koncepcję silnika [sprawdza się świetnie do tego celu])
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: mihu w Grudzień 02, 2012, 19:30:16
Ale ja sobie wolę najpierw zaprojektować jak to mniej/więcej ma wyglądać
i dopiero zacząć składać do całości (już zacząłem pisać dawniej), ale wciąż
wchodzą mi do głowy nowe pomysły (Microsoft OneNote musiałem włączyć i pisać pomysły [dosyć
przydatny program] i całą koncepcję silnika [sprawdza się świetnie do tego celu])
Nie no, każdy tak spędza czas jak lubi. Rzecz w tym, że jak sam pisałeś, chcesz mieć coś w portfolio do pokazania. Nadmierne planowanie, projektowanie, rozrysowywanie oraz tworzenie pobocznych funkcjonalności to najprostsza droga, żeby para poszła w gwizdek i zapał ostygł, zanim powstanie coś, co można (i warto) pokazać. Bo dwanaście diagramów, logger, konsola i moduł do wczytywania modeli to nie jest coś, co chciałbym zobaczyć, gdybym zatrudniał do firmy tworzącej gry. Wolałbym zobaczyć jakąś technikę renderingu albo gotową prostą grę (ale nie zatrudniam, więc mogę się mylić).
Tytuł: Odp: Budowa Silnika Gry
Wiadomość wysłana przez: XPietrucha w Grudzień 02, 2012, 20:35:47
Dobre słowa mihu, w 100% się z Tobą zgadzam. Nie warto robić czegoś nadmiernie, i nie robię
tego w moim projekcie.
Świetnie mi się przydaje OneNote. Rozpisuję sobie osobno co i jak ma wyglądać i jak ma to działać.
Kiedy już sądzę, że się napracowałem (zebrałem należyte materiały / wiedzę / sposoby) dodaję (implementuję) to w silniku.
Pewnego rodzaju powstaje dokumentacja jak co jest użyte, działa i to jest wielkim plusem.

Tak wiem, że mam mało, a czas nagli. No ale gdybym pracował bez żadnej podstawki (jakiegoś ogólnego, lub bardziej szczegółowego projektu + dokumentacji), po miesiącu, dwóch, trzech
... pozapominałbym to co jest na początku i jak to działa. Nawet jakbym chciał coś zmienić popatrzę do dokumentacji, szybko znajdę
(+ OneNote, podzielenie na notesy, sekcje, strony i podstrony), potem odnajdę to w silniku i zmienię, bez obaw ryzyka, popsucia czegoś innego (piszę co dana rzecz używa, aby podczas zmiany wiedzieć gdzie dopatrzeć możliwości błędu).