Autor Wątek: Wybór silnika  (Przeczytany 15637 razy)

Offline oy

  • Użytkownik

# Sierpień 12, 2007, 11:17:58
Niektórzy na tym forum naprawdę są nie reformowalni - Plibz pytał się, który silnik polecacie, podał też swoje typy, Ogre i Irrlicht. Tylko po co czytać i odpowiadać na pytanie skoro można wciskać kit o pisaniu własnego - nie o to było pytanie, ale takie głosy powtarzają sie non stop. Nie mam nic przeciwko pisaniu własnych silników, ale niech posty na ten temat będą chociaż w tematach pytań.  Poza tym czy to jest enginedesgin.pl czy gamedev.pl. Wystarczy zatrzymać się na chwilę w zapędach "silnikologicznych"(;)), i pomyśleć jakiego silnika użyłbym gdybym nie pisał własnego, a później już tylko odpowiedzieć.

Wracając do pytania: na początek polecam Irrlicht, jest prosty i ma całkiem niezłe możliwości. Jeśli jednak chcesz naprawdę dobrej grafiki to polecam Ogra, który jako silnik nie jest jakoś specjalnie trudniejszy od Irrlichta, ale wymaga nieco lepszej znajomości języka programowanie .   

Offline Mr. Spam

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

Offline mosowski

  • Użytkownik

# Sierpień 12, 2007, 12:50:42
Powiem w ten sposób.
Chcesz pisać drobną gierkę na miesiąc pracy - użyj Irrlichta.  Silnik ten zagwarantuje Ci kłopoty z formatami plików (brak mu oficjalnego). Nie napiszesz sobie shaderów w CG no i wiele rzeczy trzeba do niego dorobić  samemu. Irr szczyci się tym, że jest silnikiem gier, a nie tylko graficznym. Owszem, IrrKlang jest całkiem niezły. Ale tylko on. Reszta składników jest kiepskiej jakości, już Ogre ma lepszą built-in fizykę.

Jeżeli porywasz się na coś ciut ambitniejszego - Twoim wyborem powinien być Ogre. Ten silnik stanowi solidną bazę do tworzenia gry. Niby posiada wiele gotowych shaderów, ale są one napisane na potrzeby demek, więc wertuj już dokumentację CG.  Oczywiście jeśli myślisz o poważniejszym projekcie, także będziesz musiał dorobić parę elementów samemu. Ogre jest silnikiem tylko graficznym, więc przygotuj się do poznawania Newtona, ODE, Tokamaka lub innego im podobnego.

Niezależnie jakiego silnika użyjesz, nie wykona on za Ciebie wszystkiego... Poza tym używam Ogre w swoim projekcie (patrz: podpis)
« Ostatnia zmiana: Sierpień 12, 2007, 12:52:45 wysłana przez Lubię Kluski »

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 12, 2007, 12:56:02
Cytuj
Ogre jest silnikiem tylko graficznym, więc przygotuj się do poznawania Newtona, ODE, Tokamaka lub innego im podobnego.
Tak było kiedyś. Ogre już od dawna nie jest tylko rendererem. Faktycznie nie ma wbudowanej fizyki, ale za to jest NxOgre (tak to się chyba nazywa) będące wrapperem dla PhysXa. Wrapper powstał dzięki community, i jest stale rozwijany (ostatnio była chyba wersja 0.9), a jego podpięcie pod Ogre'a jest bajecznie proste.

Cytuj
Jeśli książka jest słaba to najlepsze są tutoriale na stronce ogra i wiki(ogra) , czy może znasz jakieś szczególnie warte polecenia?
Problem z silnikami generalnie jest taki, że nie ma o nich zbyt wiele materiałów, poza kodem źródłowym. Bez względu na to czy jest to silnik open-source'owy, czy technologia warta tysiące dolarów, dostarczane tutoriale są zwykle bardzo skąpe i trzeba siłą rzeczy przekopać się przez kod źródłowy, albo samego silnika, albo gier na nim zrobionych. Ogre/Irrlicht są w tyle lepszej sytuacji, że mają żywe community, które zawsze można zamęczać pytaniami, nawet podstawowymi ;)

Offline Charibo

  • Redaktor

# Sierpień 12, 2007, 13:57:14
Ja jeszcze troche pociagne OT:
Cytuj
Co do engine'ów 3D - to jest zajęcie na całe życie
Te przyklady znalazlem w kilka minut, a wydaja sie byc skonczone ;)

edit@down: Mowiac "skonczony" chodzilo mi o to, ze mozna napisac na nim gre. Jednoczesnie, mozna skonczyc silnik na takim etapie, zeby spelnial twoje wymagania :) btw, ayufan pisze juz inny silnik, Dexio tez w swoim cos edytuje (przynajmniej z tego co ostatnio do niego slyszalem), tylko luc juz ffe olal :)
« Ostatnia zmiana: Sierpień 12, 2007, 14:11:11 wysłana przez Charibo »

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 12, 2007, 14:06:26
Cytuj
Te przyklady znalazlem w kilka minut, a wydaja sie byc skonczone
IMO nie ma czegoś takiego jak skończony engine (a w zasadzie nie powinno być). To, że na enginie można zrobić grę nie oznacza jeszcze, że jest skończony (lecz, że jest w miarę kompletny), bo to często równoznaczne jest z zaprzestaniem jego developmentu. Jeśli narzędzie tego typu nazywa się skończonym to oznacza, że jest złe, bo nie jest rozszerzalne. A o sile silnika świadczy jego rozszerzalność i łatwość wprowadzania zmian (czyli np. otwarta architektura, nastawienie na refaktoring). Przywołując znowu przykład Ogre'a i Irrlichta - silniki te powstają i są rozwijane od bodaj 6 lat. I nic nie wskazuje na to, aby ich rozwój miał się zatrzymać... kiedykolwiek. Sam też napisałem silnik i też mogę powiedzieć, że był skończony. I wcale mnie to nie cieszy - dlatego piszę zupełnie nowy ;)

maxest

  • Gość
# Sierpień 12, 2007, 14:21:12
Cos jak kolejne wersje kolejnych dystrybucji Linuksa ;)

Offline Mattrick

  • Użytkownik

# Sierpień 12, 2007, 15:48:35
Ja jeszcze troche pociagne OT:
Cytuj
Co do engine'ów 3D - to jest zajęcie na całe życie
[blablablabla]
Te przyklady znalazlem w kilka minut, a wydaja sie byc skonczone ;)

Myślę, że przeczytanie całego mojego posta (wraz z Editem powstałym parę minut po postnięciu) jest najlepszym wyjściem w tej sytuacji.

@halun
Wydawało mi się, że forum jest od tego, aby można było wyrażać i wymieniać się opiniami wraz z innymi użytkownikami, a sama odpowiedź na temat jest IMO niewystarczająca. Bo co, jeżeli pod wpływem odpowiedzi nie na temat (w tym przypadku np. o własnym silniku) autor zmieni zdanie i plany na zupełnie odległe od tych zamierzonych przy zakładaniu tematu?

Offline oy

  • Użytkownik

# Sierpień 12, 2007, 16:19:15
Wiesz Mattrick, równie dobrze można napisać - a co jeżeli pod wpływem odpowiedzi nie na temat autor zmieni zdanie i plany, po czym nie wyjdzie mu przez co się tylko zniechęci ;). Może rozróżnijmy dwie rzeczy, kiedy chcę pisać grę na gotowym silniku to ją pisze (plus ewentualnie małe grzebanko w kodzie), a kiedy chcę pisać grę na własnym silniku to najpierw muszę go napisać (o ile oczywiście takiego jeszcze nie mam) a dopiero później jeśli starczy sił i zapału mogę zabrać się za główny cel czyli grę. Ogólnie sprawa nie rozstrzygnięta, może masz rację, sam teraz robie off topa, ale można się zirytować kiedy po raz setny na pytanie "który silnik - x czy y?" czyta się "pisz własny z";). Widać że autorowi nie o to chodziło.

PS. Sam przymierzam się do pisania małego frameworka, bo silnika to za dużo powiedziane, ale korzystam też z innych na których coś tam robię. To też chyba dobre rozwiązanie, korzystać ze sprawdzonych rzeczy, a kiedyś jeśli uda się skończyć własny silnik, zabrać się za tworzenie na nim.

Offline Charibo

  • Redaktor

# Sierpień 12, 2007, 16:25:26
Edit, ofc., przeczytalem. Jednak sensu sie w nim nie doszukalem.

Cytuj
pisanie silnika 3D też ma sens, gdy zamiast planować jego hiper-och-ach-och-ach funkcje będziemy pisać go w miarę rozwoju gry i implementować tylko to, co jest nam akurat potrzebne
I dostajemy na koncu zle napisany silnik, gdzie 3/4 kodu to jedna wielka kula blota, kod jest niereuzywalny bez znacznych zmian oraz sam design silnika (nawet jesli zapewnia jakies mozliwosci) odpycha od uzywania go - co wiecej, czasami moze sie okazac, ze musimy polowe gry czy silnika przepisac zeby wogole cos dzialalo.

Jednak najgorsze jest to, ze kiedy juz skonczymy taki "silnik-pod-konkretna-gre" (te gre moze i napiszemy) i zabierzemy sie za kolejny projekt - wtedy nasz kochany engine moze okazac sie bezuzyteczny ;)

Prawidlowym podejsciem moze byc pisanie gry rownolegle z silnikiem, ale na zasadzie:
"tu nie dziala, to zmienie to i to w grze i zadziala" a nie "zmienie to i to w silniku, co prawda w innych grach bedzie zle, ale zajmie mi to pol godziny mniej". Innymi slowy: pisanie gry pod silnik - a nie silnika pod gre.

Zeby nie bylo, ze jestem goloslowny - pierwszy silnik napisalem w taki sposob i nigdy nie udalo mi sie nic na nim napisac wiekszego.

Offline Mattrick

  • Użytkownik

# Sierpień 12, 2007, 17:17:59
Może nie jasno się wyraziłem - chodziło mi o to, żeby pisać silnik pod konkretne progi i według aktualnych potrzeb, ale z rozmysłem i planem. W ten sposób przy następnej grze będziemy mogli rozszerzyć funkcjonalność bez dużych strat (czyt przepisywania dużych ilości kodu, bo zapewno pare[naście/dziesiąt] linijek trzeba będzie zmienić).

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 12, 2007, 17:50:37
Cytuj
I dostajemy na koncu zle napisany silnik, gdzie 3/4 kodu to jedna wielka kula blota, kod jest niereuzywalny bez znacznych zmian oraz sam design silnika (nawet jesli zapewnia jakies mozliwosci) odpycha od uzywania go - co wiecej, czasami moze sie okazac, ze musimy polowe gry czy silnika przepisac zeby wogole cos dzialalo.
Sorry Charibo, ale nie masz racji. Takie podejście jest dziś sugerowane. Prawie wszystkie nowoczesne metodologie tworzenia oprogramowania (nie tylko mój XP ;) ) mówią o Keep It Simple (ew. Keep It Simple Stupid) - nie należy implementować funkcjonalności do momentu, w którym nie będzie ona potrzebna. Dlaczego? Po prostu znaczna większość funkcjonalności (nawet 80-90%) nigdy nie zostanie użyta w grze. Zatem jej implementacja jest niczym innym jak zwykłym marnowaniem czasu (=> a zatem i marnowaniem pieniędzy), przedłużaniem czasu projektu (a im dłuższy czas tym mniejsza efektywność pracy, ze względu np. na znużenie zespołu developerskiego). Co więcej na początku ma to być maksymalnie prosty działający kod (make it work), później ma to być kod dobry (make it right), a dopiero na samym końcu zoptymalizowany (make it fast).
Takie podejście nie oznacza, że silnik ma brzydki kod, czy też, że jest nie elastyczny. Jeśli postępujemy w zgodzie z różnymi standardami może się okazać (i zwykle tak jest), że otrzymany kod jest dużo lepszy, łatwiejszy do refaktoringu i niesamowicie elastyczny. Podczas prac nad kolejną grą może się okazać, że czegoś mu brakuje, ale wówczas znów bez problemu można to zaimplementować.

Offline yarpen

  • Użytkownik

# Sierpień 12, 2007, 18:11:29
Tyle, ze te metodologie dotycza zazwyczaj systemow innych niz gry, takich, gdzie odbiorca/klient ma duzo do powiedzenia i moze sobie po prostu zazyczyc jakiegos feature'a. Poki go nie chce, to jasne - nie ma sensu go implementowac. Gra jest systemem zamknietym, powstajacym na podstawie design doca i wiadomo co bedzie potrzebne, a co nie. Nie dojdzie nagle nowy feature tylko dlatego, ze klienci go sobie zazycza. Nie ma (nie powinno) tu byc miejsca na robienie czegos, co akurat jest potrzebne.

maxest

  • Gość
# Sierpień 12, 2007, 18:37:45
Cytuj
a dopiero na samym końcu zoptymalizowany (make it fast).
I tego do konca nie rozumiem. Czesto przeciez jest tak, ze optymalne rozwiazanie problemu wymaga nieco innego podejscia a co za tym idzie, trzeba przebudowac kod. Dlaczego wobec tego nie powinno sie ("przedwczesna optymalizacja jest" [podobno] "zrodlem wszelkiego zla") optymalizowac juz za pierwszym podejsciem do danego zadania?

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Sierpień 12, 2007, 20:41:06
Cytuj
Tyle, ze te metodologie dotycza zazwyczaj systemow innych niz gry, takich, gdzie odbiorca/klient ma duzo do powiedzenia i moze sobie po prostu zazyczyc jakiegos feature'a.
Innych niż gry... polskie. Na zachodzie wiele z tych metodologii jest już z powodzeniem stosowana/wdrażana w gamedevie. Moje zdanie jest takie, że Polska w tym względzie jest jakieś 20 lat z tyłu :( Prawda jest taka, że klientem jest wydawca - nierzadko ma miejsce sytuacja, że czegoś chce, bo tak mu się podoba. I nic się z tym nie zrobi. W poważniejszych przedsięwzięciach dokumentacja jest jeszcze bardziej skomplikowana niż design doc, co wcale nie przeszkadza w implementacji takiego postępowania.

Cytuj
Gra jest systemem zamknietym, powstajacym na podstawie design doca i wiadomo co bedzie potrzebne, a co nie.
To jest tylko teoria, w praktyce jest to znacznie bardziej dynamiczny system - feature'y dodaje się i ujmuje wraz z postępem produkcji. Coś sprawia, że gra jest nużąca - wywalamy to. Możemy coś dodać, aby poprawić wrażenia wizualne - czemu nie!

Cytuj
I tego do konca nie rozumiem. Czesto przeciez jest tak, ze optymalne rozwiazanie problemu wymaga nieco innego podejscia a co za tym idzie, trzeba przebudowac kod. Dlaczego wobec tego nie powinno sie ("przedwczesna optymalizacja jest" [podobno] "zrodlem wszelkiego zla") optymalizowac juz za pierwszym podejsciem do danego zadania?
Odpowiedź jest banalna. Jeśli system (ogólnie mówiąc) jest we wczesnym stadium implementacji NA PEWNO wiele rzeczy trzeba będzie jeszcze przebudować w przyszłości. Nigdy nie jest tak, że wszystko zostało przewidziane, zawsze pojawią się jakieś dodatkowe trudności itp. Jeśli napisany początkowo kod jest prosty (a przez to zrozumiały) jego modyfikacja nie będzie zbyt problematyczna. Jeśli jednak są w nim optymalizacje (często bardzo niskiego poziomu), to programiści będą marnować czas na ich analizowanie, zrozumienie i dopiero po tym mogą je przerobić. Zresztą odpowiedz sobie sam: czy łatwiej jest zmienić coś prostego, czy coś skomplikowanego?

maxest

  • Gość
# Sierpień 12, 2007, 21:02:21
Cytuj
Odpowiedź jest banalna. Jeśli system (ogólnie mówiąc) jest we wczesnym stadium implementacji NA PEWNO wiele rzeczy trzeba będzie jeszcze przebudować w przyszłości. Nigdy nie jest tak, że wszystko zostało przewidziane, zawsze pojawią się jakieś dodatkowe trudności itp. Jeśli napisany początkowo kod jest prosty (a przez to zrozumiały) jego modyfikacja nie będzie zbyt problematyczna. Jeśli jednak są w nim optymalizacje (często bardzo niskiego poziomu), to programiści będą marnować czas na ich analizowanie, zrozumienie i dopiero po tym mogą je przerobić. Zresztą odpowiedz sobie sam: czy łatwiej jest zmienić coś prostego, czy coś skomplikowanego?
Ale jesli dobrze przemyslimy sprawe i od razu zaimplementujemy dobre optymalne rozwiazanie to moze nie trzeba go bedzie wcale zmieniac i sie przez nie przekopywac w pozniejszej fazie :). Chociaz faktycznie, przy naprawde duzych projektach, moze to wygladac dokladnie tak jak mowisz