Czym różni się tworzenie gier od innych programów? [Zamknięte]

18

Co dla solidnego twórcy oprogramowania ogólnego różni się w tworzeniu gier, zarówno fundamentalne, jak i różnice w stopniu?

Zrobiłem gry z zabawkami, takie jak Kółko i krzyżyk, Tetris i solver sudoku z brutalną siłą (z interfejsem użytkownika) i teraz rozpoczynam średni projekt (średniej wielkości za to, że jestem pojedynczym programistą i nie mam zrobiłem wiele gier) i jedną z rzeczy, które znalazłem w tym konkretnym projekcie, jest to, że oddzielenie problemów jest o wiele trudniejsze, ponieważ wszystko wpływa na stan i każdy obiekt może oddziaływać z każdym innym przedmiotem na wiele sposobów.

Do tej pory udało mi się utrzymać kod w miarę czysty dla mojej satysfakcji, ale uważam, że utrzymanie czystego kodu w nietrywialnych grach jest o wiele trudniejsze niż w mojej codziennej pracy.

Gra, nad którą pracuję, jest turowa, a grafika będzie dość prosta (oparta na sieci, głównie poprzez manipulację DOM), więc praca w czasie rzeczywistym i praca w 3D nie mają do mnie zastosowania, ale nadal byłbym zainteresowany odpowiedziami na te, jeśli są interesujące. Jednak najbardziej interesuje go ogólna logika gry.

PS Nie mogę tego zmienić. Nie jestem pewien, jakie tagi mają zastosowanie.

game-design

— Davy8
źródło

23

Jest jedna główna różnica. Moim zdaniem to jedyna różnica, która naprawdę ma znaczenie.

Oczywiście możemy omówić szczegóły techniczne tego, dlaczego jest inaczej. W grę wchodzą silniki 3D, fizyka cząstek, wiele różnych rzeczy.

Ale wiele różnych form oprogramowania ma dołączone ciągi. Oprogramowanie do modelowania musi robić wiele takich samych rzeczy. Każdy znaczący program ma wyspecjalizowaną bibliotekę, z której musi korzystać.

Co wyróżnia GRY?

Oto on: Oprogramowanie zostało zaprojektowane, aby zaspokoić potrzeby biznesowe. Chcesz system zapasów? Możesz zdefiniować, jakie rodzaje przedmiotów obsługiwać. Możesz zdefiniować, co chcesz dla swojego harmonogramu produkcji. Możesz to wszystko zrobić. Lub jeśli chcesz oprogramowania bankowego, możesz zdefiniować, co chcesz z nim zrobić.

W przypadku gier Twoja biznesowa potrzeba to „zabawa”. Spróbuj napisać specyfikację techniczną dla „zabawy”.

To, moim skromnym zdaniem jako programisty, odróżnia gry od zwykłego oprogramowania. Po prostu nie można powiedzieć „Świetnie! To oprogramowanie jest teraz kompletne zgodnie z życzeniami klienta!” ponieważ chcą tylko dobrze się bawić.

To powiedziawszy, nie potrzebujesz grafiki 3D i ekstrawaganckiej fizyki, aby coś było zabawne. Dlaczego ludzie nadal grają w Tetris? Jego fizyka składa się z „przesuń blok w dół”, „nie pozwól blokowi wyjść poza granice” i „zatrzymaj blok, gdy coś uderzy”, a chociaż przez lata istniało wiele wersji, niektóre z bardziej wyszukaną grafiką niż inne, ale Najważniejsze jest - jest fajnie !!

Więc jeśli chcesz być świetnym twórcą gier, nie wyrzucaj tego, czego nauczyłeś się jako zwykły programista. To wciąż bardzo przydatne rzeczy. A @Sion ma rację, jeśli chodzi o rozdzielanie komponentów, tak jak w przypadku zwykłego oprogramowania. Ale najważniejszą funkcją, którą możesz dodać do swojej gry, jest zabawa. Zabawa, zabawa, zabawa, zabawa. Właśnie dlatego istnieje gra, której potrzebujesz, aby gra była udana. I zaufaj mi w tym, jakkolwiek fajnie jest grać, jest co najmniej 10 razy tak fajny!

Powodzenia w tworzeniu gier !! :RE

— corsiKa
źródło

2

Jeśli zamienisz „zabawne” na „przydatne”, myślę, że napotykasz ten sam problem z projektowaniem produktu (w przeciwieństwie do pisania oprogramowania dla klienta). Przypuszczam jednak, że istnieje różnica w stopniu. Ludzie czasami mylą się co do tego, co byłoby przydatne, zwykle nie mają pojęcia, co sprawia, że coś „sprawia im przyjemność”. (+1 chociaż)

— Davy8

1

Było niesławne orzeczenie Sądu Najwyższego dotyczące branży filmów dla dorosłych i tego, co klasyfikowało „hardkor” w latach 60. Sprawiedliwość powiedziała: „Nigdy nie uda mi się [zdefiniować], ale wiem to, kiedy to widzę”. Myślę, że to samo można powiedzieć dla zabawy. Mam na myśli, że mogę zapisywać rzeczy, które lubię w grach, ale często gram w gry i zadaję sobie pytanie: „Co sprawia, że jest tak fajnie?” (Oczywiście chcę wiedzieć, aby odtworzyć to w jednej z moich gier !!) Ludzie nie wiedzą, co sprawia, że coś jest zabawne, ale na pewno wiedzą, kiedy to znaleźli!

— corsiKa

Naprawdę podobał mi się ten post. Masz rację. Bardzo lubię tworzenie gier, ale tak naprawdę nie mam w sobie przekonania, czym jest „zabawa” dla „zwykłych” ludzi. Co spowodowało, że robię tylko gry, które lubię i niektóre inne loony takie jak ja :)

— Phil

1

@Fil i w porządku. Jeśli wiesz, co sprawia ci przyjemność, musisz pamiętać, że na tym świecie jest tylko kilkaset archetypów postaci. Rozejrzyj się po swoim miejscu pracy i dopasuj osobowości współpracowników do tych, z którymi chodziłeś do szkoły średniej lub college'u. Przekonasz się, że większość z nich można dopasować. Więc jeśli coś jest dla ciebie zabawne, prawdopodobnie będzie zabawne dla większej liczby osób, niż ci się wydaje. Sztuczka polega na tym, aby dowiedzieć się o grze, aby mogli się nią cieszyć!

— corsiKa

To najlepsza odpowiedź, jaką do tej pory widziałem. Istnieje mnóstwo artykułów na temat nisz biznesowych i tak dalej, ale niewiele na temat tworzenia gier. Hmmmm

— Johnny

21

Jestem przede wszystkim twórcą gier, a nie tradycyjnym programistą, ale myślę, że istnieje kilka kluczowych różnic.

Jest to oczywiście kilka uogólnień, które nie są wyczerpujące:
większe zespoły. Bardziej zróżnicowane tło (artyści, programiści, producenci, z każdym z nich jest jeszcze więcej odmian). Dłuższe cykle rozwoju. Wyższe standardy wydajności. Większa skala projektów. Większe i droższe ryzyko awarii. Bardziej stresujące środowisko.

Jeśli chodzi o interakcje między obiektami i układanie architektury, nadal można poprawnie oddzielić systemy. Twoje obiekty i zachowanie będą wyraźnie zależne od siebie nawzajem i od tych systemów. Taka jest natura gry (gra słów), łączy wszystkie te systemy w jedną spójną całość i nie ma w tym nic złego. Może się tak wydawać, ponieważ skala tego wszystkiego jest większa niż jesteś do tego przyzwyczajony.

Jakieś łatwe do zidentyfikowania i posegregowane systemy?

Wykrywanie kolizji
Reakcja na zderzenie
Fizyka
Animacja
Grafika (2D i 3D)
Sztuczna inteligencja
Wprowadzane przez użytkownika
Plik wejściowy / wyjściowy
Sieć

— Sion Sheevok
źródło

+1 za dobrą odpowiedź na pytanie, mimo że w mojej konkretnej grze nie muszę sobie z nimi radzić (turowa i płytkowa, więc nie ma prawdziwych kolizji, nie ma fizyki, grafika składa się z duszków i rzuca więcej JQuery w tym, 2 graczy, więc nie ma jeszcze AI, dane wejściowe są obsługiwane w przeważnie RESTful, który obejmuje również aspekt sieci) Nie jestem pewien, co masz na myśli przez File IO, poza zapisaniem / ładowaniem gry, co rodzaje IO są potrzebne w typowych grach?

— Davy8

4

Zgadzam się z większością tego postu i otrzymuję ode mnie +1, ale podważam linię „większe i droższe ryzyko awarii”. Jeśli pracujesz dla banku, dużej firmy produkcyjnej lub witryny o bardzo dużym ruchu, Twoja awaria może być mierzona w setkach tysięcy na minutę przestoju w wyniku awarii. W ciągu godziny możesz stracić (utraconą sprzedaż, utraconych klientów itp.) Więcej niż kilka miesięcy w sklepach dla twórców gier z pełną listą płac. Nie twierdzę, że nie może być duży, po prostu mówię, że nie jestem przekonany, że jest to coś więcej niż tradycyjne oprogramowanie.

— corsiKa

@glowcoder Wiem, co mówisz, ale myślę, że rozumiem też, o co Sion stara się powiedzieć, że w przypadku gier ogólnie albo cały projekt jest sukcesem, albo porażką, i zwykle jest to czynnik, o którym wspomniałeś w swojej odpowiedzi : czy to jest przyjemne? Możesz robić poprawki błędów, ale nie możesz poprawiać braku zabawy.

— Davy8

3

Wcale nie jestem przekonany, że „większe zespoły” są prawdziwe nawet w uogólnieniu. Jasne, gry AAA mają duże zespoły - ale podobnie są w przypadku oprogramowania nie będącego odpowiednikiem złożoności. Ogromna liczba gier jest produkowana przez osoby lub zespoły dwu- lub trzyosobowe.

— Peter Taylor

@ Davy8 oh, gdyby tylko komercyjny sukces gry był proporcjonalny do jej zabawy. :)

— tenpn

2

Nie sądzę, aby programowanie gier różniło się od innych domen aplikacji z tego względu, że trudniej jest wybrać odpowiedni rozdział problemów. Za każdym razem, gdy przenosisz swoje umiejętności do innego rodzaju domeny aplikacji, przekonasz się, że przejście nie jest tak płynne, jak można się było spodziewać, ponieważ zawsze występują różnice. To, co działało w aplikacji bazodanowej, ma wiele wzorców / idiomów, które nie działają tak dobrze we wbudowanej aplikacji, która ma wiele wzorców / idiomów, które nie działają tak dobrze w tym systemie czasu rzeczywistego, który ma również wiele wzorców / idiomów, które nie działają w programowaniu gier. Jednak programiści gier mają te same problemy, gdy opuszczają domenę programowania gier. To tylko kwestia tego, do czego jesteś przyzwyczajony.

Biorąc to pod uwagę, myślę, że programowanie gier wydaje się trudniejsze dla wielu osób, ponieważ wymaga pracy z częściami komputera, z którymi większość programistów nigdy nie musi sobie poradzić w swojej prawdziwej pracy (grafika i dźwięki niskiego poziomu) i matematyki bardziej stosowanej niż wielu ludzie czują się komfortowo, a nie z powodu rozdzielenia obaw. Chociaż zawsze występują trudności z określeniem właściwego wyboru w celu rozdzielenia problemów, myślę, że trudność w oddzieleniu problemów, których doświadczasz, polega po prostu na przeniesieniu się do nowej dziedziny problemów. Gdy zbudujesz kilka aplikacji, będzie to jak wszystko inne, dowiesz się, co lubisz i nie będziesz używać tego, czego nie.

— Maczać
źródło

0

a jedną z rzeczy, które znalazłem w tym konkretnym projekcie, jest to, że oddzielenie problemów jest o wiele trudniejsze, ponieważ wszystko wpływa na stan i każdy obiekt może oddziaływać z każdym innym przedmiotem na wiele różnych sposobów.

Myślę, że masz tam odpowiedź, jest wiele interakcji. Zrobiłem kilka gier z XNA (C #), teraz robię grę średniej wielkości, jak mówisz, grę strategiczno-symulacyjną, pracuję nad nią od prawie 2 miesięcy i robię to sam bez pomocy, więc ja mój kod musi być prosty. Myślę, że jedną wielką różnicą jest zrozumienie i zaprojektowanie niektórych klas pod kątem funkcjonalności, a innych do rysowania, to pomaga i czyni program czystszym. Oczywiście, jeśli grasz, musisz mieć więcej zasobów, takich jak obrazy (2d lub 3d) i muzyka (lub dźwięki). Są więc różnice, myślę, że to trudniejsze, ale bardzo zabawne.

— Żukki
źródło

0

Myślę, że programowanie gier jest przyjemniejsze. Możesz stale testować swoją grę, wdrażasz różne zasady fizyki, co skutkuje odmiennymi zachowaniami.

Z mojego doświadczenia wynika, że programowanie gier jest o wiele przyjemniejsze niż tworzenie oprogramowania. Podczas tworzenia oprogramowania musisz przestrzegać pewnych reguł biznesowych, a to staje się nudne. Tworzysz oprogramowanie, to nie jest fajne. Korzystanie z oprogramowania jest świetne, pomocne, użyteczne, ale nie zabawne.

Gry są fajne. Może to tylko ja, ale uważam, że tworzenie gier jest o wiele bardziej intrygujące i ekscytujące niż tradycyjne tworzenie oprogramowania, niezależnie od używanego narzędzia.

PS: Używam najnowszych narzędzi do tworzenia oprogramowania, HTML5, Asp.Net, C # itp. Nadal uważam, że kodowanie DirectX, UDK, XNA, Unity jest przyjemniejsze.

— harsimranb
źródło