Tworzysz gry w Go? [Zamknięte]

40

Nowy język Google w Go jest jeszcze w powijakach i nie znalazł jeszcze powszechnego zastosowania lub wsparcia w świecie rzeczywistym. Mimo to wydaje się to obiecującym eksperymentem i zastanawiam się, czy może mieć przyszłość w rozwoju gier. Nie byłem w stanie znaleźć dużo dyskusji na temat Go w innych grach i uznałem, że dyskusja CW może być odpowiednia.

Kilka myśli:

  • Według golang.org , programy Go „działają prawie tak szybko, jak porównywalny kod C lub C ++” - wystarczająco szybko?
  • Czy funkcja usuwania śmieci Go nadaje się do gier?
  • Ile mentalnego przeprojektowania jest potrzebne do tworzenia gier w krainie współbieżnych goroutines?
  • Go jest często nazywany językiem „systemowym”, z przykładem oprogramowania serwera. Słysząc to, trudno nie myśleć o serwerach gier dla wielu graczy.

Twoje myśli?

go TSomKes
źródło
1
Radziłbym każdemu, kto nie jest zaznajomiony z GO, aby faktycznie podążył za linkiem przed odpowiedzią, w przeciwieństwie do zwykłej odpowiedzi na podstawie podanych „myśli”, które są powiedziane, jeśli twoja odpowiedź jest ogólna i nie jest specyficzna dla tego języka, to chyba nie ma znaczenia
lathomas64
1
Zastanawiam się, czy możesz tworzyć gry w ruchu (gra): P
RCIX
4
Nie jestem pewien, czy „ Go ” uważa się za zakończone (to znowu jest obsługiwane przez człowieka). Ale przestrzeń do przechowywania jest bardzo ograniczona (przynajmniej jeśli używasz tablicy regulacyjnej).
David C. Bishop
@ DavidC. Bishop Funny ...
Brian Ortiz
1
Jeśli stworzysz silnik gry go, powinieneś upewnić się, że korzystasz z tego, co potrafi język, zamiast próbować używać go w taki sam sposób, jak w przypadku bardziej „konwencjonalnego” języka i kopiować to, co już istnieje.

Odpowiedzi:

34

Moje zdanie na twoje pytania:

  • Język jest wystarczająco szybki. Do tworzenia gier wykorzystywany jest wolniejszy język Java. Nawet Python (pygame) jest używany do tworzenia gier i jest znacznie wolniejszy niż Java. Wszystko zależy od rodzaju gry i intensywności procesora.
  • Śmieci w ogóle nie są zbyt dobre dla gier. Jednak Go ma szczególnie zły system zbierania śmieci (mark-and-sweep), który zatrzymuje świat podczas czyszczenia rzeczy. Trudno sobie z tym poradzić i spowoduje to zatrzymanie klatek na sekundę.
  • Do stworzenia gier z goroutinami niezbędna jest przyzwoita ilość zmian mentalnych. Grafika i logika nie mogą być zbieżne w tradycyjnym sensie; ale na mniejszym poziomie części logiki są świetnymi kandydatami do jednoczesnych goroutyn (np. równoległe przetwarzanie decyzji AI, układów cząstek itp.)
  • Serwer gry wieloosobowej może być rzeczywiście świetnym kandydatem na język Go.

Moim zdaniem, jeśli masz dość siły, by spróbować pisać gry z językiem, idź na całość. Oczywiście, jeśli zastanawiasz się nad tym, masz do tego pasję i dlaczego nie podążać za tą pasją zamiast zmuszać się do przestrzegania normy? Mógłbym powiedzieć dużo więcej, ale już w mojej odpowiedzi na pytanie „Czy Ruby jest odpowiednim językiem do tworzenia gier?”.

Ricket
źródło
6
„szczególnie zły system zbierania śmieci (mark-and-sweep)” mark-and-sweep nie z natury powstrzymuje świata - na przykład Java ma równoległy kolektor mark-and-sweep, a Lua przez długi czas używała naiwnego - i wiele długości pauzy można kontrolować za pomocą starannego systemu generacyjnego. Biorąc to pod uwagę, Go's jest marką i zamiataniem świata. Ale to pierwsze, a nie drugie, jest kwestią gier. (Wątek Ruby również miał dziwne twierdzenia na ten temat.)
1
Obecny system Go GC wydaje się być symbolem zastępczym: „Obecna implementacja jest zwykłym narzędziem do zbierania znaczników i zamiatania, ale jest w stanie zastąpienia” ( golang.org/doc/go_lang_faq.html#garbage_collection ). Opcje wymiany zostały omówione; Nie znam żadnych zdecydowanych decyzji w tej sprawie.
TSomKes
1
Joe, dziękuję za wyjaśnienie! Nie byłam tego świadoma. I tak TSomKes, widziałem to, abyśmy mogli nadal mieć nadzieję, że Go zaimplementuje lepszy śmieciarz w pewnym momencie.
Ricket
4
Zauważ, że powyższa odpowiedź jest nieaktualna, jeśli chodzi o bieżący śmieciarz Go. Gra Go 1.5 to zupełnie inna gra w piłkę. Zastanawiam się, jak bardzo to niepokoi.
Jonas
3
I wydaje się, że w wersji 1.8 GC zostanie zredukowane do 100 μs równoczesnego stop-the-world. groups.google.com/forum/#!topic/golang-dev/Ab1sFeoZg_8
Dolanor
17

Napisałem mały silnik w Go dla OSX (używając OpenGl do okna graficznego). Mam pewne doświadczenie z silnikami gier C ++ ( http://morganjeff.weebly.com/ ) i postanowiłem wypróbować Go po przeczytaniu o niektórych jego funkcjach.

Począwszy od wersji Go 1.1, Go obsługuje większość funkcji potrzebnych do napisania silnika gry (tak naprawdę rdzeń gry, ponieważ silnik sugeruje edytorom, a co nie), w tym:

  • Powiązanie funkcji członka (dla systemu przesyłania wiadomości)
  • Odbicie jest wbudowane (przydatne do serializacji, obsługi zewnętrznych narzędzi itp.)
  • Interfejsy (do implementacji zachowania polimorficznego w systemach, komponentach itp.)

Niektóre zalety korzystania z Go (w przypadku dużego projektu):

  • Testowanie jest wbudowane w język (obejmuje to testy porównawcze i niektóre stwierdzenia)
  • Przykłady można łatwo dodać do języka (i są one kompilowane pod kątem poprawności)
  • Kod specyficzny dla architektury jest łatwy do dodania (poprzez konwencje nazewnictwa plików)
  • Profilowanie jest wbudowane w język
  • wbudowana wersja importu (pozwala na dodawanie dużych plików binarnych do oddzielnego repozytorium od źródła, przy zachowaniu wersji i aktualności)

Niektóre zalety korzystania z Go w ogóle:

  • Łatwy do refaktoryzacji kod
  • Go obsługuje wątki (w przeciwieństwie do C ++, które nakładały go warstwami na wierzch)
  • super szybka prędkość kompilacji zmniejsza potrzebę obsługi języka skryptowego
  • system typowania statycznego (interfejsy są spełnione poprzez typowanie kaczych aka niejawnie)
  • wiele zwracanych wartości, nazwanych parametrów, otagowanych atrybutów struktury
  • świetne wbudowane narzędzia i dokumentacja
  • zarządzany język

Niektóre wady korzystania z Go:

  • Brak makr i szablonów
  • Nie obsługuje bibliotek bardziej dojrzałych języków
  • język zarządzany (celowo wymieniony dwukrotnie)
  • BEZ IDE

Są sposoby na uzyskanie surowej pamięci w go (importowanie „niebezpieczne”), a link do artykułu, który pokazuje, jak program go może być profilowany pod kątem pamięci i szybkości. Podsumowując, twierdzenie Go, że jest to nowoczesne C, wydaje się bardzo prawdziwe. Myślę, że jest „elegancko” zaprojektowany (z wielu powodów, o których wspominałem) i, co ważniejsze, jest dobrze udokumentowany. Silnik zaprojektowany w Go będzie trochę inny niż silnik zaprojektowany w C ++ (coś, do czego wciąż się przyzwyczajam), ale silnik Go rozwiązuje wiele problemów, które tak naprawdę nie są rozwiązane w C ++ (mianowicie równoległość, złożoność języka C ++ i niewłaściwe użycie dziedziczenia).

Oto obiecany artykuł: http://blog.golang.org/2011/06/profiling-go-programs.html

-Jeff

jmorgan
źródło
wypróbuj Sublime z GoSublime, to naprawdę wygląda jak IDE i jest znacznie bardziej reaktywne niż wiele (jeśli nie wszystkie) IDE dla Java.
Arne
1
czy możesz sprecyzować, co rozumiesz przez „wbudowane wersje importowania”, jestem tylko nieświadomy znacznika wersji samego języka go.
Arne,
@jmorgan jakieś zmiany w perspektywie od wersji Go 1.2 i widzisz nadchodzące zmiany w wersji 1.3?
pokaż
@Arne: Dobra rozmowa! Bardzo lubię GoSublime. To, co miałem na myśli bez IDE, to to, że aby uzyskać wizualny debugger, musisz użyć gogdb (który jest świetnym narzędziem), ale nie jest tak przyjemny jak studio wizualne. Oto, co miałem na myśli na temat zależności pakietów i wersji: golang.org/cmd/go/… golang.org/cmd/go/#hdr-Import_path_syntax
jmorgan
@ylluminate: Szczerze myślę, że Go jest coraz lepszy. Teraz jest dostarczany z pakietem testów, dzięki czemu można szybko zobaczyć, co jest testowane, a co nie. Przekonałem się, że posiadanie porządnego zestawu testów znacznie ułatwia moje życie ... więc jest to dla mnie duża cecha. Go 1.3 wydaje się, że wprowadzi się ulepszenia w zakresie wielkości binarnej i szybkości działania (w szczególności modułu wyrzucania śmieci), więc to świetnie.
jmorgan
4

Należy jeszcze pomyśleć o tym, że ponieważ Go jest wciąż stosunkowo nowy, może nie być jeszcze powiązań dla wielu popularnych bibliotek używanych do tworzenia gier.

Bob Somers
źródło
Zdecydowanie tak. Na przykład natknąłem się na dwa projekty Go / SDL, z których jeden wydaje się być porzucony. Znalazłem garstkę (stosunkowo małych) gier, które korzystają z którejkolwiek z nich.
TSomKes,
1
Zdecydowanie powinieneś sprawdzić github.com/go-gl to nie SDL, ale dobra alternatywa, jeśli używasz OpenGl. Dla wektorów jest github.com/Jragonmiris/mathgl , ale znalazłem tam błędy. Go sprawia, że ​​bardzo łatwo jest owijać biblioteki C. Nie ma potrzeby używania plików makefile. Możesz także importować pliki nagłówkowe C i bezpośrednio korzystać z ich funkcji.
Arne
0

Nie używaj Go do rozwijania gry, będzie to po prostu albatros na szyi. Łańcuch narzędzi do tworzenia gier rozciąga się o wiele głębiej niż tylko język, w którym piszesz rzeczy, że na każdym kroku znajdziesz przeszkody, których po prostu nie będzie, jeśli pójdziesz z czymś ustalonym.

Nie zrozum mnie źle, uwielbiam grać z nowymi językami, ale jeśli próbujesz zmusić gry do wybrania języka, który ma społeczność i wsparcie, a będziesz znacznie lepiej.

Aaron Brady
źródło
9
Z drugiej strony, jeśli zamierzasz po prostu zaprogramować rzeczy w małym projekcie indie, aby grać w nowym języku, martwienie się o „łańcuch narzędzi” jest przereklamowane.
2
Nie mogę się tutaj zgodzić. Większość rzeczy związanych z tworzeniem gier nie ma nic wspólnego z językiem. Zadawanie pytań o OpenGL nie ma nic wspólnego z pogodą, którą programujesz w C C ++ Go, a nawet Javie. A tak przy okazji, o jakim łańcuchu narzędzi mówisz? I dlaczego miałoby być niekompatybilne?
Arne,