Autor Wątek: Języka dla początkującego  (Przeczytany 6586 razy)

Offline Kyroaku

  • Użytkownik

  • +1
# Grudzień 21, 2015, 17:57:32
Nauka jakiego języka (wraz z całą infrastrukturą), na dzisiaj, pozwoli beginnerowi najszybciej i najmniej boleśnie zrobić działającą grę?

Wydaje mi się, że na tak postawione pytanie, właśnie C# będzie najlepszą odpowiedzią...
Błąd. Na takie pytanie najlepszą odpowiedzią jest...
Unity3D, UnrealEngine.

Offline Mr. Spam

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

Offline Vault 11th

  • Użytkownik

# Grudzień 21, 2015, 18:13:49
To właśnie mam na myśli - C# + Unity. W UE4 + C++ trzeba się jednak nieco więcej naklepać, żeby coś zrobić.

Offline Kyroaku

  • Użytkownik

# Grudzień 21, 2015, 19:02:04
Z tym, że nauka C#/C++ dla Unity/UE IMHO niczym nie przypomina C#/C++.
Dla mnie to jak język skryptowy oparty na tych językach.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 21, 2015, 19:15:31
Cytuj
Z używaniem IDE jest podobnie. Ale to nie wszystko. Ten podlinkowany artykuł był naprawdę sensowny. Otóż chodzi o to, że masz w głowie pewną ,,przestrzeń mentalną'' takie ,,rejestry'' na których możesz operować. I to nie jest bynajmniej duża przestrzeń. A na dodatek maleje z wiekiem. Wiec jak jej nie wykorzystujesz (a IDE właśnie na to Ci pozwala -- na mentalne lenistwo) to się degraduje.
Wiem o czym mówisz. Myślę że zależy jeszcze co kodujesz, bo ja na ten limit przestrzeni mentalnej regularnie trafiam (chociaż najczęściej jak próbuję wymyślić idealne rozwiązanie zbyt dużego problemu na raz).

Cytuj
Druga sprawa jest taka, że ta przestrzeń jest skończona i mała. W związku z tym rozwiązania które tworzysz muszą się w niej mieścić -- są mniejsze, zgrabniejsze i lepiej przemyślane (to jest właśnie teza z artykułu). IDE sztucznie poszerza Ci przestrzeń w której pracujesz, co może prowadzić do zmutowanej kupy... kodu.
Wiesz, myślę że zależy to od stylu kodowania. Większość problemów jakie rzeczywiście mi tą przestrzeń mocno wykorzystują to rzeczy wysokiego poziomu: architektura, czy algorytmy. Nie mam problemu z pamiętaniem co gdzie i w którym miejscu kodu się znajduje i dla mnie IDE to raczej tylko ułatwienie niż coś bez czego nie dało by się żyć. Zwłaszcza że często IntelliSense potrafi zamulić/się wyłączyć i zdążę wpisać dany identyfikator przed jego zaproponowaniem, czy ręcznie przejść do szukanego miejsca.

Cytuj
Przykład, zachwycasz się debuggerem -- ja nie debuguję swojego kodu. Po co? Przecież napisałem ten kod. A skoro go napisałem to go znam (jest w moich ,,rejestrach'' lub jestem go w stanie ,,załadować''). Po opisie błędu, czasami stack-trace'ie lub logu wiem na czym polega błąd.
Piszemy w temacie "język dla początkującego" - a dla początkującego taki debugger to moim zdaniem świetna rzecz żeby podejrzeć jak rzeczywiście coś działa.

Co do "znam kod, więc nie debuguję" - właśnie napisałeś, że debugujesz. Dochodzenie do błędu po logach/stacku to też debugowanie. I też w ten sposób mogę powiedzieć że też rozleniwiasz swoją przestrzeń mentalną, bo niekiedy takie rzeczy to naprawdę luksus (tak, pracuję przy embedded i zdarzało mi się "debugować" mając jako wyjście kilka LEDów). :)

Offline Vault 11th

  • Użytkownik

# Grudzień 21, 2015, 19:24:20
Z tym, że nauka C#/C++ dla Unity/UE IMHO niczym nie przypomina C#/C++.
Dla mnie to jak język skryptowy oparty na tych językach.
To jest dobry start dla wielu osób. Jedni wolą uczyć się w akademicki sposób, drudzy lepiej uczą się robiąc coś działającego. Unity bynajmniej nie ogranicza wachlarza umiejętności, jakie możesz rozwinąć; zaprojektowanie dobrej architektury gry nadal jest wyzwaniem i pozwala nauczyć się myślenia w C# jako takim. To, że wiele osób używa Unity do wyklikania gry to inna kwestia, jestem jej świadomy.
Co - swoją drogą - kolejny raz przypomina, że ludzie są różni i nie ma jednej uniwersalnej odpowiedzi w tym temacie. Sam zaczynałem od asma na C64 i wiem, że dużo mi to dało.

Offline Galardo

  • Użytkownik

# Grudzień 21, 2015, 20:12:20
Chciałbym trochę uściślić to co napisałem. Xender napisał, że jest to forum o tworzeniu gier :) żeby stworzyć taką potrzebny jest silnik, który będzie podstawą naszej gry i który będzie zawierał w sobie efekty która chcemy aby były w naszej grze, jeśli to dobrze rozumiem :). Ale, żeby napisać silnik/dostosowywać inny do naszych potrzeb potrzebna jest znajomość jakiegoś lub pewnie najlepiej kilku języków.
Dodam tylko, że jestem bardziej osobą wzrokową, wole widzieć efekt mojej pracy, znaczy zmienię coś w kodzie to lubię jak widzę konkretny efekt ciężko mam tak na sucho :) A jak ktoś napisał w temacie Xendera, że wyświetlany tekst "Hello world" nie bardzo mnie rajcuje, że tak powiem.

Offline Xender

  • Użytkownik

# Grudzień 21, 2015, 23:23:34
Czyli co? Skoro nie jesteśmy w stanie przy kompilacji wykryć wszystkich błędów, to nie wykrywajmy żadnego?
Do poczytania: link ;)

Poza tym we w miarę nowoczesnym C++ przy vectorach i smart pointerach o segfaulta już relatywnie ciężko.
Nie, to znaczy, że trzeba policzyć, gdzie jesteśmy do przodu a gdzie do tyłu w failure mode'ach C++ a Pythona.

Z Pythonem sprawa jasna i prosta - wszystko, co może pójść nie tak, rzuca wyjątek.
Niezłapany wyjątek to stacktrace z zaznaczonymi miejscami w kodzie na stdout.
Sytuacja bardzo przewidywalna - przy każdym błędzie można liczyć na tę samą ilość informacji na dzień dobry.
No chyba, że sam interpreter się wyłoży, to rzadka sytuacja (o ile nie chce się jej świadomie sprowokować) i poważny problem.

W C++ - jesteśmy do przodu na błędach wykrytych w czasie kompilacji, miło.
Ale na segfaultach jesteśmy czasami do tyłu.
Uwaga na braki w symbolach debugowych bibliotek (w Pythonie nie są potrzebne, każda normalna klasa poddaje się inspekcji tak samo).
Podgląd zmiennych też czasem nie działał z jakimiś klasami bibliotecznymi.
No i symetrycznie do crasha interpretera, tu można nadziać się na błąd w kompilatorze - to też jest rzadkie i problematyczne.

To, jak te argumenty wyważyć, to często kwestia osobistego doświadczenia.
Moje skłania mnie ku Pythonowi.

A na pewno dużo ciężej niż o zwykłą literówkę, którą Python wykryje dopiero jak już będzie za późno.
Ale co to znaczy "za późno"?

Jak kod będzie na produkcji?
Do tego czasu powinien być otestowany - statyczne typowanie nie zastąpi testów, to chyba jasne - typy to tylko jedna z rzeczy, które mogą pójść nie tak - są jeszcze algorytmy, niespodziewane dane wejściowe, niezrozumienie jak działa jakaś biblioteka lub błąd w tejże, i różne inne.
Przy zaniedbaniu testów i statyczne typowanie może nie pomóc.

Jak jakiś skrypt-lifehack mi się wysypie w połowie roboty?
Przeważnie to przeżyję i dość szybko naprawię.

Ale jak już się wysypuje, to najczęściej dość łatwo to jest zreprodukować i pod debuggerem. Poza tym jak poważnie podchodzisz do tematu to możesz w reakcji na segfaulta zrobić dumpa i załadować go potem pod debuggerem.
Gorzej, jak pod debuggerem nie daje się zreprodukować.
Przeważnie jest to oznaka, że błąd ujawnia się dopiero przy bardziej agresywnych optymalizacjach kompilatora, które domyślnie są wyłączone w buildzie debugowym. No to dobra, robimy kompilację w trybie debug z -O2 i... brakujące symbole - kompilator coś zinlinował i debugger się gubi.
Bywało i tak.

Tak samo jak mi przez bardzo długi czas w zupełności wystarczał DevC++ i debug przez printf. Dopóki nie odpaliłem Visuala i mnie wgniotło, że można zupełnie inaczej.

Nie powiesz chyba, że nawet w Pythonie taki tree-view do przeglądania struktur danych nie byłby przydatny?
Ok, byłby.

Fajnie byłoby mieć, ale mam zastępnik - możliwość wywołania debuggera albo REPL-a w praktycznie dowolnym miejscu kodu, z dopełnianiem obiektów i ich składowych pod tab:
Kod: (python) [Zaznacz]
import ipdb; ipdb.set_trace()  # Debugger
import IPython; IPython.embed()  # REPL
Ew. jeśli ipdb lub IPython nie są dostępne, to pdb i REPL-a z biblioteki standardowej, ale one mają mniej bajerów.

No nie tak do końca. Iteracje w których w Pythonie trzasnąłeś literówkę są duużo dłuższe od C++'owych.
W normalnej aplikacji, gdzie muszę się przeklikać przez różne rzeczy, zanim dana funkcja zostanie wywołana, pewnie by tak było.
Ale akurat piszę webówkę, mam reloader. Odświeżam stronę, widzę stacktrace przez pomyłkę w nazwie właśnie, poprawiam, zapisuję, odświeżam - cała iteracja. Sytuacja z dzisiaj.

Uznałbym argument i o tym nie pisał, gdyby nie czasy kompilacji C++ - też trochę loteria, zależy od ilości użytych templatek, włącznie z bibliotekami. Niestety nawet pod buildem inkretmentalnym bywa dramatycznie.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 22, 2015, 00:23:54
Cytuj
To, jak te argumenty wyważyć, to często kwestia osobistego doświadczenia.
Moje skłania mnie ku Pythonowi.
Cóż, ja choruję jak coś w Pythonie muszę zrobić (np. eksport z Blendera), głównie przez czas zmarnowany na łapaniu właśnie dupereli typu literówka, brak jakiegoś taba, itp. :)

Cytuj
W normalnej aplikacji, gdzie muszę się przeklikać przez różne rzeczy, zanim dana funkcja zostanie wywołana, pewnie by tak było.
Ale akurat piszę webówkę, mam reloader. Odświeżam stronę, widzę stacktrace przez pomyłkę w nazwie właśnie, poprawiam, zapisuję, odświeżam - cała iteracja. Sytuacja z dzisiaj.
No to mamy różne doświadczenia. Mój pierwszy kontakt z Pythonem był w QuArKu (edytor do Quake), gdzie żeby znaleźć literówkę musiałem przeklikać się przez całą aplikację.

Cytuj
Uznałbym argument i o tym nie pisał, gdyby nie czasy kompilacji C++ - też trochę loteria, zależy od ilości użytych templatek, włącznie z bibliotekami. Niestety nawet pod buildem inkretmentalnym bywa dramatycznie.
Inkrementalne linkowanie daje akurat dość mało. Największy zysk na kompilacji można uzyskać zrównoleglając ją i używając prekompilowanych nagłówków.

Offline Xender

  • Użytkownik

# Grudzień 22, 2015, 10:35:19
głównie przez czas zmarnowany na łapaniu właśnie dupereli typu literówka, brak jakiegoś taba, itp. :)
A wiesz, za składnią opartą na wciąciach to akurat będę stał murem.
Python tutaj wymusza tylko 2 rzeczy:
- Nie mieszać tabów i spacji - wcinać albo jednym, albo drugim.
- Wcinać kod sensownie.

Czasem jest to problematyczne, jeśli ktoś wkleja w internet kawałek kodu "na odwal", np. nie sprawdzi, jaki jest tag do oznaczania kodu na forum albo w silniku, na którym ma własnego bloga, to fakt.

Ale jest to niezbędne minimum czytelnego formatowania kodu tak, żeby móc się w nim później połapać.
Dla początkującego jest to szczególnie ważne i wydaje mi się, że często olewane, zupełnie bezpodstawnie.

Offline Kos

  • Użytkownik
    • kos.gd

# Grudzień 22, 2015, 11:56:46
Cóż, ja choruję jak coś w Pythonie muszę zrobić (np. eksport z Blendera), głównie przez czas zmarnowany na łapaniu właśnie dupereli typu literówka, brak jakiegoś taba, itp. :)

Wrzuć sobie pyflakes / flake8 w edytor, wykrywa 80% literówek.

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Grudzień 24, 2015, 16:50:42
Chciałbym trochę uściślić to co napisałem. Xender napisał, że jest to forum o tworzeniu gier :) żeby stworzyć taką potrzebny jest silnik, który będzie podstawą naszej gry i który będzie zawierał w sobie efekty która chcemy aby były w naszej grze, jeśli to dobrze rozumiem :). Ale, żeby napisać silnik/dostosowywać inny do naszych potrzeb potrzebna jest znajomość jakiegoś lub pewnie najlepiej kilku języków.
Dodam tylko, że jestem bardziej osobą wzrokową, wole widzieć efekt mojej pracy, znaczy zmienię coś w kodzie to lubię jak widzę konkretny efekt ciężko mam tak na sucho :) A jak ktoś napisał w temacie Xendera, że wyświetlany tekst "Hello world" nie bardzo mnie rajcuje, że tak powiem.
Dla mnie wybór jest prosty. Jeżeli chcesz robić gry na mobile to Unity, jeżeli na PC to Unreal. Jeżeli chcesz robić silniki to c++ i jakiś tetris w konsoli na początek. Jeżeli jeszcze nie wiesz co chcesz robić to lepiej się najpierw zapoznać z gotowymi rozwiązaniami.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 24, 2015, 17:01:51
Cytuj
Jeżeli chcesz robić gry na mobile to Unity
Wydajność Unity na mobile generalnie leży i kwiczy, więc ja bym w tym kierunku nie szedł.

Offline Kos

  • Użytkownik
    • kos.gd

# Grudzień 24, 2015, 17:15:31
Wydajność całego mobile leży i kwiczy, więc why bother? :P

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Grudzień 24, 2015, 17:22:57
Wydajność całego mobile leży i kwiczy, więc why bother? :P
Ja bym tak nie powiedział. Jak odpowiednio do tego podejść, to śmiga to naprawdę ładnie.

Offline laggyluk

  • Użytkownik
    • http://laggyluk.com

# Grudzień 24, 2015, 18:22:24
Wydajność Unity na mobile generalnie leży i kwiczy, więc ja bym w tym kierunku nie szedł.
A jaka jest sensowna cross-platformowa alternatywa? Większość pracy na mobile jest w Unity na ten moment. Wydajność Unreala na mobile leży i kwiczy btw.