Kiedy powinienem użyć silnika fizyki? [Zamknięte]

12

Odkąd odkryłem Box2D , używam go do jakiejkolwiek aplikacji podobnej do gry, którą próbuję napisać, od bardzo małych prototypów lub małych programów do testowania czegoś, do rzeczywistych projektów.

Dzięki temu tak strasznie łatwo poradzić sobie z wszystkim, od kolizji, aż po rzeczywistą fizykę.

Czasami mam jednak pewne wątpliwości: jeśli muszę obsługiwać tylko koła lub AABB i nie potrzebuję zaawansowanych narzędzi fizyki (stawów lub podobnych rzeczy), myślę, że silnik fizyki mógłby dodać coś w rodzaju dużego, niepotrzebne koszty ogólne.

Aby ponownie odpowiedzieć na moje pytanie: czy użyłbyś Box2D (lub innych silników fizyki) w grze, w której fizyka jest naprawdę prosta (powiedzmy Super Mario, powiedzmy)? A jeśli nie, to dlaczego?

physics

— peoro
źródło

2

Rób to, co wydaje się właściwe. Czy uważasz, że twoja gra potrzebuje silnika fizyki? Czy uważasz, że Mario skorzystałby na Box2D? Najnowszy Mario z pewnością ma fajną atmosferę dzięki przyjemnej fizyce, ale nie przypomina niczego, co widziałem wbudowane w Box2D.

— Jeff

@Jeff: To zależy od tego, czy pytanie „Kiedy powinienem użyć Box2D?” lub „Kiedy powinienem użyć silnika fizyki?”. Nowy Mario z pewnością zawiera silnik fizyki.

1

@Joe Wreschnig: Tak, ale czy zdarza się, że silnik fizyki nie jest używany? Tylko czas, który mogę wymyślić, to przygoda tekstowa lub wskaż i kliknij. Myślę, że to zależy od tego, jak ogólna jest twoja definicja silnika fizyki

— Jeff

@Jeff: Niewiele (niefizycznych) gier logicznych potrzebuje jednej, np. Tetris, Bejeweled. W grach akcji mogłem argumentować, że większość shmupów 2D nie korzysta z silnika fizyki, ponieważ generalnie potrzebują one tylko kontroli nakładania się AABB / koła, braku reakcji na kolizję, absolutnie ustalonych ścieżek ruchu i stałej prędkości. W platformówkach chodzi jednak o fizykę.

8

Jeśli pamięć, miejsce na dysku, wysiłek programistyczny lub czas procesora wykorzystywany w Box2D jest zbyt duży dla twoich celów, nie używaj go. W przeciwnym razie nie ma powodu, aby tego unikać, jeśli uznasz to za przydatne.

— Gregory Avery-Weir
źródło

2

To wszystko, co naprawdę sprowadza się do. Jeśli ułatwia ci życie i nie blokuje cię na pożądanych platformach, to wygrywa, nawet jeśli nie korzystasz z części.

1

Lub innymi słowy - „Jedynym powodem do wynalezienia koła jest nauka o ponownym wynalezieniu koła”.

— Exilyth,

4

Coś tak łatwego jak Super Mario nie, ponieważ tak naprawdę nie ma dużo fizyki. (Mario nie wpływa na fizykę innych obiektów podczas skoku)

jeśli używasz fizyki w sensie wielu przedmiotów (więcej niż jednego) wykorzystujących fizykę do wpływania na wynik innych obiektów, wtedy użyłbym silnika.

— Strachy
źródło

Z drugiej strony Mario ma pęd, przyspieszenie, zmienną wielkość i kierunkową kolizję, z których wszystkie otrzymujesz „za darmo” dzięki silnikowi fizyki, a nie są to zwykłe kontrole nakładania się granic.

Zgadzam się - myślę, że przez większość czasu silnik fizyki da ci wiele rzeczy, których wdrożenie byłoby trochę stratą czasu.

— Christopher Horenstein,

3

To prawda, że zawsze lepiej nie wymyślać koła, po prostu stwierdzam, że jeśli chcę tylko koło, nie zamierzam brać planu na samochód. Ponadto dowiesz się więcej o swojej grze jako całości i łatwiej będzie zmieniać / zmieniać fizykę.

— Spooks

1

To naprawdę okropna analogia. To bardziej przypomina koło i osie, a może kolumnę kierowniczą i silnik, ale może nie deskę rozdzielczą ani elektryczne szyby.

3

kto nie chciałby szyb elektrycznych?

— Spooks

2

Moja odpowiedź brzmi tak, absolutnie używaj silnika fizyki, takiego jak Box2D, do prostych rzeczy, ponieważ nie powinieneś spędzać niepotrzebnego czasu na programowaniu, wdrażając niektóre funkcje, które szybko otrzymujesz z silnika fizyki. Na przykład zdefiniuj ciało statyczne i upuść na niego ciało dynamiczne i zastosuj siłę do ciała dynamicznego w celu wprowadzenia danych kierunkowych, a za kilka minut będziesz mieć platformówkę. Nie sądzę, że silnik dodaje wystarczającej mocy, aby nie było tego warte.

— Christopher Horenstein
źródło

3

można jednak powiedzieć, że wymyślenie, jak wdrożyć i używać Box2D, zajęłoby więcej czasu niż stworzenie prostej fizyki. (choć myślę, że zależy to od stopnia wykorzystania fizyki)

— Spooks

1

@Spooks: Nie wyobrażam sobie nic „łatwiejszego” niż Box2D, które byłoby nadal przydatne.

Zgadzam się tutaj z Joe; po prostu nie ma prostego zamiennika użyteczności, która pojawia się przy korzystaniu z Box2D. Nie wyobrażam sobie kodowania czegoś, co zaspokoi twoje potrzeby szybciej niż nauczenie się tworzenia niektórych urządzeń i definiowania grawitacji za pomocą Box2D.

— Christopher Horenstein,

1

Jeśli „fizyka” w grze jest prosta, nie trzeba importować silnika fizyki.

Używam terminu fizyka luźno, ponieważ istnieje różnica między modelowaniem fizyki a symulacją fizyków. Bardzo ważna rzecz do odróżnienia.

Na przykład w Mario Bros. po uruchomieniu i zatrzymaniu przesuniesz się trochę. Zastanów się, jak możesz to zaimplementować.

Możesz modelować, definiując wszystkie niezbędne zmienne: np. masa, grawitacja, współczynnik tarcia, ciąg itp., a następnie obliczanie nowej prędkości, przyspieszenia itp.

ale czy warto? Możesz symulować ten sam efekt, zmniejszając prędkość graczy, gdy się nie poruszają ...

Coś jak:

if( pressing movement key ) { 
 speed = 5; 
} else { 
 if(speed) speed--; // slide!
}

Różnica polega na tym, że jedna to fizyka, a druga nie. Oba mają swoje zalety i wady. Ale z reguły w przypadku prostych gier o wiele łatwiej jest je sfałszować.

— aaronfarr
źródło

1

Ten rodzaj fizyki jest obrzydliwy. Jeśli masz zamiar je sfałszować, równie dobrze może sprawić, że będzie ładnie wyglądać. tarcie = .9 lub pewna liczba poniżej 1. speedX * = tarcie; speedY * = tarcie;

— AttackingHobo

2

Oczywiście pod koniec projektu zmienia się on w „jeśli (naciskając klawisz ruchu i nie poruszając się i na lodzie, a nie pod wodą i masz to specjalne wzmocnienie i nie jeździsz w bagażniku i ...)”.

@AttackingHobo: Celem tego postu nie jest stworzenie ładnego algorytmu przesuwnego. Ma on zilustrować różnicę między symulacją a modelem.

— aaronfarr

@Joe: To tylko modyfikacje zmiennej tarcia. Być może ty i @AttackingHobo powinniście porozmawiać: P W silniku fizyki musisz zdefiniować właściwości każdego obiektu w grze. Chodzi mi o to, że podłączenie silnika fizyki do prostych gier nie powinno być automatyczne. To sytuacyjne.

— aaronfarr

1

@aaronfarr: Nie ma różnicy między symulacją a modelem; do tych celów są synonimami. Wszystko, co pokazałeś, to to, że izolowana część modelu zabawki / symulacji zawiera mniej kodu niż całość Box2D.

0

Musisz zdecydować w zależności od sytuacji

Profesjonaliści używający niestandardowego silnika

Oprogramowanie pod kontrolą (bez zmian z powodu nowej wersji)
Dostosowane do Twojej gry (tylko funkcje, których potrzebujesz w grze, tak jak potrzebujesz)
Elastyczność (dowolna szalona dynamika, którą chcesz zakodować, żadna przyszła funkcja nie będzie zależała od silnika)
Doświadczenie w nauce (może pewnego dnia musisz ulepszyć silnik i musisz go zbudować)
Mniej nauki i programowania dla prostych funkcji (czasem zrobienie czegoś z silnikiem może wymagać głębokiego zrozumienia jego struktury .. i może nie być tego warte)
Wyższa wydajność w przypadku prostych funkcji (w przypadku prostych określonych funkcji można uzyskać wyższą wydajność niż w przypadku silnika ogólnego przeznaczenia)
Mniej pamięci (obiekt i kod mogą zajmować znacznie mniej miejsca i pamięci, gdy używane są tylko niezbędne funkcje)

Zalety gotowego silnika fizyki:

Może dostosować się do nowego sprzętu i nowego systemu operacyjnego bez większego wysiłku
Mniejsze nakłady na naukę i programowanie złożonych funkcji
Wyższa wydajność złożonych funkcji

— Dimitri Ognibene
źródło