Od czego zacząć tworzenie gier?

[HexiPlayGames]

Witam.

Tak jak w temacie, jestem bardzo zainteresowany tworzeniem gier, nie musi to być jakaś ogromna gra, chciałbym spróbować stworzyć przynajmniej jakąś dowolna grę.

Pozdrawiam, podawajcie silniki na jakich warto tworzyć grę oraz żeby było najłatwiej

[Gość]

Standardowe pytanie: Czy znasz jakiś język programistyczny?

Jest on wręcz niezbędny do tworzenia gier, między innymi do takich celów jak skryptowanie.

 

Edit:

 

Dzięki temu, że podasz mi taką informacje ja postaram się dobrać dla Ciebie jakiś silnik który takiego języka używa.

 

Oprócz tego do tworzenia gier przydała by się wiedza na temat tego co to jest sam silnik, co to jest gra, jak działa struktura server-client.

 

Edit2:

 

Dodatkowo jeżeli ma to być mała gra to okey, poszukasz sobie jakiś fajnych resource darmowych i tak dalej.

Jeżeli szykował byś się do czegoś większego to polecam ogarnąć jakiś mały team i rozdzielić obowiązki.

 

Ponad to nie wyobrażaj sobie, że tak po prostu bez żadnej wiedzy pobierzesz silnik i zaczniesz coś robić.

Do tego trzeba mieć także wiedzę teoretyczną, wiedzieć co się robi.

 

Nie mówie, że nie masz, dlatego pytam.

[DaltooN]

Myślę że swoją przygodę zacznij z ogarnianiem podstaw z programowaniem. Najlepiej by był to język C# lub JavaScript. Jeśli będziesz umieć tworzyć zmienne, wkładać do nich informacje, tworzyć instrukcje warunkowe, pętle to wtedy możesz rozpocząć przygodę z tworzeniem nawet jakieś średnio rozbudowanej gry. To wszystko oczywiście na pierwszy rzut oka może wyglądać strasznie, lecz jest to sprawa bardzo prosta, tym bardziej jeśli chcesz nauczyć się nie tylko tworzenia gier ale również programowania.

Co do silników graficznych do tworzenia takich gier to najlepszy na start (i nie tylko na start) moim zdaniem jest Unity3D.

[HexiPlayGames]

@skprime jakiś miesiąc temu próbowałem stworzyć grę w unity 5 oglądając filmiki od jakiejś tam osoby  ale jak tylko przeszedł do pisania jakiegoś tam kodu to od razu nie zrozumiałem niczego...

[Hans Kloss PL]

@up

Czyli sam sobie odpowiedziałeś - zacznij od nauki programowania tak jak inni już sugerowali.

[Gość]

A więc dobrze było by zacząć od programowania, zrozumienia co to jest gra, silnik, różne struktury, funkcje, systemy.

 

Źródeł jest bardzo dużo, w Google wystarczy poszukać.

[jimmyblack]

Jak zwykle dopowiem:

 

Nie zapomnij zaprojektować swojej gry, przemyśl jej elementy, mechaniki itp.

 

Kiedy będziesz już wiedział jaką grę chcesz zrobić, będzie łatwiej dobrać do tego narzędzia. Jak już ktoś wyżej wspomniał Unity może być dobrym wyborem, między innymi z powodu dużej ilości poradników. Tutoriale video na stronie Unity są bardzo dobre, przy okazji omawiania programu omawiany jest też pobieżnie c#. 

[Polskiekoksiwo]

polecam ci się nauczyć c# i c++. C# potrzebny jest do pisania skryptów  w unity 

 

 

 

Pomogłem daj lajka

[mcErykO]

@skprime jakiś miesiąc temu próbowałem stworzyć grę w unity 5 oglądając filmiki od jakiejś tam osoby  ale jak tylko przeszedł do pisania jakiegoś tam kodu to od razu nie zrozumiałem niczego...

Nie znając podstaw programowania to oczywiste że nic nie rozumiałeś . 

Unity jest moim zdaniem najlepszym silnikiem dla początkującego .  

 

https://www.youtube.com/channel/UC7zgpXvOmkUvQiixN89suMw/videos

 

Na tym kanale możesz poznać podstawy c# i unity .

 

//Oczywiście nie ograniczaj się tylko do jednego źródła

Na stronie unity można się też dużo nauczyć 

http://unity3d.com/learn/tutorials

[NGK_]

Bez sensem jest zaczynać swoją przygodę z programowaniem uderzając od razu w programy 3d czy silniki typu unity. Zacznij od programów konsolowych, bo w innym wypadku nie będziesz rozumiał wielu istotnych zagadnień, oraz procesów zachodzących w programach.

Osobiście nie polecam C++ na start bo można szybko się zniechęcić, zacznij z Pythonem który jest stosunkowo łatwy i posiada bardzo wiele ciekawych bibliotek.

[jimmyblack]

@UP

Nie zgodzę się. Do tworzenia prostych gier wystarczy znajomość programowania na poziomie podstawowym oraz np silnik typu unity. Ucząc się języka od podstaw też na początku wszystkiego nie zrozumie, tak samo jak przy kodowaniu gry wraz z tutkiem. To przychodzi z czasem.

Oczywiście można pierw uczyć się robić programy konsolowe, ale ta sama wiedza i tak przyjdzie z czasem.

[NGK_]

@UP

Nie zgodzę się. Do tworzenia prostych gier wystarczy znajomość programowania na poziomie podstawowym oraz np silnik typu unity. Ucząc się języka od podstaw też na początku wszystkiego nie zrozumie, tak samo jak przy kodowaniu gry wraz z tutkiem. To przychodzi z czasem.

Oczywiście można pierw uczyć się robić programy konsolowe, ale ta sama wiedza i tak przyjdzie z czasem.

 

Tak, jakby nie patrzeć wszystko można robić na opak. Tylko po co? 

Do tego, po co gość który zna podstawy programowania ma brać się za tworzenie gry? Czy tworzenie gry na gotowych sprite'ach to wyznacznik jakiejś umiejętności? Średno-ogarnięty nastolatek może pobrać sobie TGF czy tam innego RPGM i zrobić w niej grę, potrzebuje znajomości programowania? Nie. Może się nazwać koderem, czy chociaż osobą obeznaną w kodzie tejże gry? Też nie.

A wracając do tych konsol, to możesz mi wierzyć albo i nie, ale z konsol korzysta się tylko na wstępie nauki z programowanie, a w pracy, czy gdziekolwiek indziej do niej nawet nie zajrzysz (no chyba, że jesteś administratorem linuxowym/unixowym). Tak więc jedyną słuszną radą jest zaczęcie od konsoli, można robić inaczej ale to nie o to chodzi. Możesz zabrać się od dupy strony za wszystko, nawet za faceta, niby podobnie jak z kobietą jednak coś tu nie gra.

[DaltooN]

@skprime jakiś miesiąc temu próbowałem stworzyć grę w unity 5 oglądając filmiki od jakiejś tam osoby  ale jak tylko przeszedł do pisania jakiegoś tam kodu to od razu nie zrozumiałem niczego...

 

Nigdy nie ucz się programowania od osób, które robią poradniki do Unity5. Zacznij od poradników dotyczących głównie i wyłącznie programowania w jakimś tam wybranym języku.

 

polecam ci się nauczyć c# i c++. C# potrzebny jest do pisania skryptów  w unity 

 

 

 

Pomogłem daj lajka

 

C# do Unity owszem, bardzo fajny i ciekawy język. Co do C++ to jest to napewno bardzo dobry język na start przygody z programowaniem, lecz jeśli ktoś celuje tylko w Unity to nie ma on żadnego zastosowania.

 

Bez sensem jest zaczynać swoją przygodę z programowaniem uderzając od razu w programy 3d czy silniki typu unity. Zacznij od programów konsolowych, bo w innym wypadku nie będziesz rozumiał wielu istotnych zagadnień, oraz procesów zachodzących w programach.

Osobiście nie polecam C++ na start bo można szybko się zniechęcić, zacznij z Pythonem który jest stosunkowo łatwy i posiada bardzo wiele ciekawych bibliotek.

 

Moim zdaniem to wedle gustu. Można rozpocząć od programów konsolowych owszem, lecz jeśli ktoś chce od razu zaczynać od Unity to dlaczego nie ? W programowaniu uczymy się tylko tego co jest nam potrzebne, nigdy nie należy uczyć się czegoś co Ci się nigdy w życiu nie przyda.

[NGK_]

@up

C++ nie jest zbyt dobrym wyborem na start, no chyba że jesteś bardzo wytrwały i masz dużo czasu, ale to już kwestia indywidualna.

 

Co do tego, że ktoś zaczyna od unity to błąd. Napisz jeszcze, że bedzie się specjalizował przez resztę życia unity to przyklaskne. Podejście typu "po co mi to, jeżeli mi sie to nie przyda" jest idiotyczne. W programowaniu jest fajna zasada, która przynajmniej ja staram sie kierować, jeżeli nie lubisz jakiejś technologii czy języka, to go poznaj - trzeba dobrze poznać swoich prawdziwych wrogów

[DaltooN]

@up

C++ nie jest zbyt dobrym wyborem na start, no chyba że jesteś bardzo wytrwały i masz dużo czasu, ale to już kwestia indywidualna.

 

Co do tego, że ktoś zaczyna od unity to błąd. Napisz jeszcze, że bedzie się specjalizował przez resztę życia unity to przyklaskne. Podejście typu "po co mi to, jeżeli mi sie to nie przyda" jest idiotyczne. W programowaniu jest fajna zasada, która przynajmniej ja staram sie kierować, jeżeli nie lubisz jakiejś technologii czy języka, to go poznaj - trzeba dobrze poznać swoich prawdziwych wrogów

 

C++ to dobry wybór na start jeśli chcesz uczyć się jeszcze innych języków programowania. Dzięki niemu bardzo szybko pojmiesz całą resztę rzeczy, które są zawarte w innych językach programowania.

Co do Unity, to kwestia indywidualna, czy ktoś chce tworzyć tylko w unity. A podejście, o którym mówiłem, a które skrytykowałeś jest bardzo dobre, ponieważ uczysz się tego, co jest Ci na chwilę obecną potrzebne, bo jeśli na siłę będziesz uczył się tego co jest Ci nie potrzebne, to aby niepotrzebnie się zniechęcisz. Wiele doświadczonych programistów mówi że uczenie się czegoś, czego nie potrzebujesz w chwili obecnej, to strata czasu

[NGK_]

 

@up

C++ nie jest zbyt dobrym wyborem na start, no chyba że jesteś bardzo wytrwały i masz dużo czasu, ale to już kwestia indywidualna.

 

Co do tego, że ktoś zaczyna od unity to błąd. Napisz jeszcze, że bedzie się specjalizował przez resztę życia unity to przyklaskne. Podejście typu "po co mi to, jeżeli mi sie to nie przyda" jest idiotyczne. W programowaniu jest fajna zasada, która przynajmniej ja staram sie kierować, jeżeli nie lubisz jakiejś technologii czy języka, to go poznaj - trzeba dobrze poznać swoich prawdziwych wrogów

 

C++ to dobry wybór na start jeśli chcesz uczyć się jeszcze innych języków programowania. Dzięki niemu bardzo szybko pojmiesz całą resztę rzeczy, które są zawarte w innych językach programowania.

Co do Unity, to kwestia indywidualna, czy ktoś chce tworzyć tylko w unity. A podejście, o którym mówiłem, a które skrytykowałeś jest bardzo dobre, ponieważ uczysz się tego, co jest Ci na chwilę obecną potrzebne, bo jeśli na siłę będziesz uczył się tego co jest Ci nie potrzebne, to aby niepotrzebnie się zniechęcisz. Wiele doświadczonych programistów mówi że uczenie się czegoś, czego nie potrzebujesz w chwili obecnej, to strata czasu

 

 

Twoje pierwsze zdanie potwierdza tylko moje przypuszczenia o tym, że jesteś kompletnym laikiem w temacie programowania. Nie chce mi się dywagować z osobą która (tak przypuszczam) nie jest nawet średnio obeznana w "klimatach" koderskich. 

Daj mi wypowiedź tych informatyków, którzy uczą się tylko tego co potrzebują, oczywiście nie chodzi mi tu o ludzi z januszsoftów. 

 

W programowaniu jeżeli się nie rozwijasz to wypadasz. Nie ma czegoś takiego jak, umiem to i mi to wystarczy (no może i jest, ale tak jak powiedziałem, w typowych januszsoftach, gdzie taki "senior" od 20 lat klepie ten sam kod w tej samej technologi, a przez te n lat nie rozwinął się, a wręcz cofnął się w rozwoju) trzeba być na topie, aby móc dyktować warunki potencjalnym pracodawcom.

[Frejus]

 

Twoje pierwsze zdanie potwierdza tylko moje przypuszczenia o tym, że jesteś kompletnym laikiem w temacie programowania. Nie chce mi się dywagować z osobą która (tak przypuszczam) nie jest nawet średnio obeznana w "klimatach" koderskich. 

Daj mi wypowiedź tych informatyków, którzy uczą się tylko tego co potrzebują, oczywiście nie chodzi mi tu o ludzi z januszsoftów. 

 

W programowaniu jeżeli się nie rozwijasz to wypadasz. Nie ma czegoś takiego jak, umiem to i mi to wystarczy (no może i jest, ale tak jak powiedziałem, w typowych januszsoftach, gdzie taki "senior" od 20 lat klepie ten sam kod w tej samej technologi, a przez te n lat nie rozwinął się, a wręcz cofnął się w rozwoju) trzeba być na topie, aby móc dyktować warunki potencjalnym pracodawcom.

 

 

Nie wiem, czy teraz sobie jaja robisz, czy żyjesz w takim przekonaniu, że informatyk musi umieć wszystko, nawet to, co mu nie jest potrzebne.

To o czym pisał @DaltooN zawiera się w zarządzaniu projektem informatycznym, a dokładnie chodzi tutaj o teorię "just in time learning" wzięło się to od słynnego Henrego Forda, który zakładając firmę produkującą samochody wymyślił produkcję taśmową i wyznaczył kilka podstawowych zasad, które usprawniają i polepszają jakość produktów, jakimi były samochody. Do dzisiejszego dnia jego zasady są takimi przykazaniami we wszystkich fabrykach, ale nie tylko. Te zasady bardzo dobrze sprawdzają się w wielu innych branżach, między innymi IT. Gdyby jeden człowiek miał wyprodukować wszystkie części do samochodu, a potem jeszcze to wszystko sam poskręcać, to trwałoby to wieki i nie byłoby to wykonane na najlepszym poziomie. Dlatego Ford wyznaczył zasadę doskonalenia się w określonym zakresie, auto nie będzie już skręcane przez jedną osobę, a przez kilkadziesiąt, lub nawet kilkaset, jedna osoba przykręca kilka części do samochodu, lub zestaw części, które mu dostarczono i samochód z taśmą leci do następnego pracownika. Dokładnie tak samo jest w programowaniu, jeden człowiek odpowiada za część projektu, kiedy skończy swoją pracę, projekt zostaje przeznaczony następnej osobie, która wykona przy nim swoją robotę i znowu pośle dalej. Oczywiście nie wolno zapomnieć o czymś takim jak programowanie równoległe, jeden robi swoje, a drugi, czekając na część, którą otrzyma od Mietka, robi już coś, a nie siedzi bezczynnie. To też obowiązywało w fabryce Forda. Jeden złożył fotel, inny go miał przykręcić do podłogi, ale w oczekiwaniu na fotel przygotowywał już podłogę, którą otrzymał o Zdzisia. Just in time to kolejna z zasad Forda, która jest stosowana w większości firm informatycznych (te januszowe o tym jeszcze nie słyszały pewnie). Just in time w Fabryce forda jasno określało, że nie ma żadnych magazynów z częściami, których budowa kosztowałaby miliony dolarów, później sama produkcja tych części do magazynów kosztowała by kolejne miliony dolarów, a nie daj Boże okaże się, że np ktoś wymyślił nowy rodzaj opon, które się doskonale sprawdzają w różnych warunkach, w takim wypadku zostalibyśmy z magazynem starych opon, których nam już nikt nie kupi, bo konkurencja już produkuje nowe lepsze opony. W informatyce just in time learning polega na tym, że uczymy się tego, co potrzebujemy w danym momencie, to znaczy, umiemy programować (specjalnie piszę programować, a nie wymieniam żadnych języków, technologii itp), dostaliśmy zlecenie na aplikację mobilną dla banku, musimy się dowiedzieć jak działa bank, jak wyglądają u nich procedury wewnętrzne, jak Olek w banku wita się z Bolkiem, musimy znać wszystkie szczegóły, a potem analizujemy zebrane dane i ustalamy, jak najlepiej byłoby wykonać taki system, sprawdzamy i dowiadujemy się, jakie zabezpieczenia są wymagane itp. Jak już wszystko będziemy mieli przeanalizowane, zabieramy się za projekt. Uczymy się o wszystkich tych funkcjach i technologiach, których nie wykorzystywaliśmy wcześniej, a na czas tego projektu będą nam niezbędne. Doskonalimy swoją wiedzę z tego zakresu, tworzymy ten projekt i oddajemy go w ręce naszego pracodawny, czyli banku. To jest just in time learning. Inny przykład, troszkę prostszy, przychodzi do nas klient i chce projekt banalny, który będzie zbierał informacje z istniejącego już i wdrożonego w jego firmie systemu, i będzie drukował raporty, zapisywał je do pliku pdf. Co jednak, kiedy nie korzystaliśmy jeszcze z funkcji odpowiadających za zapis do pliku pdf? Mówimy klientowi, "sorry, ale nasza firma zapisuje tylko do pliku txt"?? Nie!! Googlujemy, sprawdzamy dokumentację językową i szukamy rozwiązania, a następnym razem, kiedy ktoś przyjdzie z podobnym problemem, to albo będziemy o tym pamiętali, albo? Just in time learning!!!! Znowu się tego nauczymy na czas wykonywania konkretnego projektu. Programowanie to szeroka dziedzina, nie da się wszystkiego umieć, nawet ucząc się na bieżąco nowych rzeczy, ponieważ ludzki mózg, jeśli czegoś nie powtarza w praktyce, to wywala to z pamięci, traktując to jak śmieci.

 

 

W programowaniu jeżeli się nie rozwijasz to wypadasz. Nie ma czegoś takiego jak, umiem to i mi to wystarczy (no może i jest, ale tak jak powiedziałem, w typowych januszsoftach, gdzie taki "senior" od 20 lat klepie ten sam kod w tej samej technologi, a przez te n lat nie rozwinął się, a wręcz cofnął się w rozwoju) trzeba być na topie, aby móc dyktować warunki potencjalnym pracodawcom.

 

 

Dokładnie tak!!! Ale zrozum to jak "Just in time learning", czyli to o czym pisał @DaltooN, a ja Ci to wytłumaczyłem, bo po TWOIM pierwszym zdaniu, TWOIM, nie Daltona  

 

 

Twoje pierwsze zdanie potwierdza tylko moje przypuszczenia o tym, że jesteś kompletnym laikiem w temacie programowania. Nie chce mi się dywagować z osobą która (tak przypuszczam) nie jest nawet średnio obeznana w "klimatach" koderskich. 

Daj mi wypowiedź tych informatyków, którzy uczą się tylko tego co potrzebują, oczywiście nie chodzi mi tu o ludzi z januszsoftów. 

 

 

widać, że nie wiesz co to znaczy, i możemy "przypuszczać", że jesteś kompletnym laikiem w temacie programowania.

[NGK_]

 

 

Twoje pierwsze zdanie potwierdza tylko moje przypuszczenia o tym, że jesteś kompletnym laikiem w temacie programowania. Nie chce mi się dywagować z osobą która (tak przypuszczam) nie jest nawet średnio obeznana w "klimatach" koderskich. 

Daj mi wypowiedź tych informatyków, którzy uczą się tylko tego co potrzebują, oczywiście nie chodzi mi tu o ludzi z januszsoftów. 

 

W programowaniu jeżeli się nie rozwijasz to wypadasz. Nie ma czegoś takiego jak, umiem to i mi to wystarczy (no może i jest, ale tak jak powiedziałem, w typowych januszsoftach, gdzie taki "senior" od 20 lat klepie ten sam kod w tej samej technologi, a przez te n lat nie rozwinął się, a wręcz cofnął się w rozwoju) trzeba być na topie, aby móc dyktować warunki potencjalnym pracodawcom.

 

 

Nie wiem, czy teraz sobie jaja robisz, czy żyjesz w takim przekonaniu, że informatyk musi umieć wszystko, nawet to, co mu nie jest potrzebne.

To o czym pisał @DaltooN zawiera się w zarządzaniu projektem informatycznym, a dokładnie chodzi tutaj o teorię "just in time learning" wzięło się to od słynnego Henrego Forda, który zakładając firmę produkującą samochody wymyślił produkcję taśmową i wyznaczył kilka podstawowych zasad, które usprawniają i polepszają jakość produktów, jakimi były samochody. Do dzisiejszego dnia jego zasady są takimi przykazaniami we wszystkich fabrykach, ale nie tylko. Te zasady bardzo dobrze sprawdzają się w wielu innych branżach, między innymi IT. Gdyby jeden człowiek miał wyprodukować wszystkie części do samochodu, a potem jeszcze to wszystko sam poskręcać, to trwałoby to wieki i nie byłoby to wykonane na najlepszym poziomie. Dlatego Ford wyznaczył zasadę doskonalenia się w określonym zakresie, auto nie będzie już skręcane przez jedną osobę, a przez kilkadziesiąt, lub nawet kilkaset, jedna osoba przykręca kilka części do samochodu, lub zestaw części, które mu dostarczono i samochód z taśmą leci do następnego pracownika. Dokładnie tak samo jest w programowaniu, jeden człowiek odpowiada za część projektu, kiedy skończy swoją pracę, projekt zostaje przeznaczony następnej osobie, która wykona przy nim swoją robotę i znowu pośle dalej. Oczywiście nie wolno zapomnieć o czymś takim jak programowanie równoległe, jeden robi swoje, a drugi, czekając na część, którą otrzyma od Mietka, robi już coś, a nie siedzi bezczynnie. To też obowiązywało w fabryce Forda. Jeden złożył fotel, inny go miał przykręcić do podłogi, ale w oczekiwaniu na fotel przygotowywał już podłogę, którą otrzymał o Zdzisia. Just in time to kolejna z zasad Forda, która jest stosowana w większości firm informatycznych (te januszowe o tym jeszcze nie słyszały pewnie). Just in time w Fabryce forda jasno określało, że nie ma żadnych magazynów z częściami, których budowa kosztowałaby miliony dolarów, później sama produkcja tych części do magazynów kosztowała by kolejne miliony dolarów, a nie daj Boże okaże się, że np ktoś wymyślił nowy rodzaj opon, które się doskonale sprawdzają w różnych warunkach, w takim wypadku zostalibyśmy z magazynem starych opon, których nam już nikt nie kupi, bo konkurencja już produkuje nowe lepsze opony. W informatyce just in time learning polega na tym, że uczymy się tego, co potrzebujemy w danym momencie, to znaczy, umiemy programować (specjalnie piszę programować, a nie wymieniam żadnych języków, technologii itp), dostaliśmy zlecenie na aplikację mobilną dla banku, musimy się dowiedzieć jak działa bank, jak wyglądają u nich procedury wewnętrzne, jak Olek w banku wita się z Bolkiem, musimy znać wszystkie szczegóły, a potem analizujemy zebrane dane i ustalamy, jak najlepiej byłoby wykonać taki system, sprawdzamy i dowiadujemy się, jakie zabezpieczenia są wymagane itp. Jak już wszystko będziemy mieli przeanalizowane, zabieramy się za projekt. Uczymy się o wszystkich tych funkcjach i technologiach, których nie wykorzystywaliśmy wcześniej, a na czas tego projektu będą nam niezbędne. Doskonalimy swoją wiedzę z tego zakresu, tworzymy ten projekt i oddajemy go w ręce naszego pracodawny, czyli banku. To jest just in time learning. Inny przykład, troszkę prostszy, przychodzi do nas klient i chce projekt banalny, który będzie zbierał informacje z istniejącego już i wdrożonego w jego firmie systemu, i będzie drukował raporty, zapisywał je do pliku pdf. Co jednak, kiedy nie korzystaliśmy jeszcze z funkcji odpowiadających za zapis do pliku pdf? Mówimy klientowi, "sorry, ale nasza firma zapisuje tylko do pliku txt"?? Nie!! Googlujemy, sprawdzamy dokumentację językową i szukamy rozwiązania, a następnym razem, kiedy ktoś przyjdzie z podobnym problemem, to albo będziemy o tym pamiętali, albo? Just in time learning!!!! Znowu się tego nauczymy na czas wykonywania konkretnego projektu. Programowanie to szeroka dziedzina, nie da się wszystkiego umieć, nawet ucząc się na bieżąco nowych rzeczy, ponieważ ludzki mózg, jeśli czegoś nie powtarza w praktyce, to wywala to z pamięci, traktując to jak śmieci.

 

 

W programowaniu jeżeli się nie rozwijasz to wypadasz. Nie ma czegoś takiego jak, umiem to i mi to wystarczy (no może i jest, ale tak jak powiedziałem, w typowych januszsoftach, gdzie taki "senior" od 20 lat klepie ten sam kod w tej samej technologi, a przez te n lat nie rozwinął się, a wręcz cofnął się w rozwoju) trzeba być na topie, aby móc dyktować warunki potencjalnym pracodawcom.

 

 

Dokładnie tak!!! Ale zrozum to jak "Just in time learning", czyli to o czym pisał @DaltooN, a ja Ci to wytłumaczyłem, bo po TWOIM pierwszym zdaniu, TWOIM, nie Daltona  

 

 

Twoje pierwsze zdanie potwierdza tylko moje przypuszczenia o tym, że jesteś kompletnym laikiem w temacie programowania. Nie chce mi się dywagować z osobą która (tak przypuszczam) nie jest nawet średnio obeznana w "klimatach" koderskich. 

Daj mi wypowiedź tych informatyków, którzy uczą się tylko tego co potrzebują, oczywiście nie chodzi mi tu o ludzi z januszsoftów. 

 

 

widać, że nie wiesz co to znaczy, i możemy "przypuszczać", że jesteś kompletnym laikiem w temacie programowania.

 

 

Przeczytałem ostatnie zdanie które skierowałeś do mnie, marna prowokacja? Nie wiem co znaczy ale co? Oświeć mnie.

[Frejus]

@Up po pierwsze nie spamuj cytatami, jak Twoja odpowiedź ma się zawrzeć w jednym nie logicznym zdaniu. Nie wiesz co to just in time learning, czyli to, o czym pisał @DaltoN. Naucz się czytać ze zrozumieniem, albo po prostu najpierw przeczytaj co napisałem, a później próbuj bronić swoich racji. 

BTW: Możesz także przyznać nam rację, bo jak na razie powyższym pytaniem i sposobem cytowania, jeszcze bardziej umacniasz mnie w przekonaniu, że pod nickiem NGK_ nie kryje się osoba, która cokolwiek ma wspólnego z programowaniem.

[NGK_]

Nie miałem czasu żeby czytać całego Twojego komentarza, obejrzałem go bardzo ogólnie i zauważyłem ciekawe zdanie w moim kierunku. To tyle.

Jak mam rozumieć cała ta "burza" jest wywołana poprzez moje stwierdzenie, że programista powinien uczyć się języków które nie są mu potrzebne. Uważam cały czas je za słuszne, znam tylko jeden przypadek ze studiów, w którym to znajomy w 100% skupił się na technologiach Microsoftu i udało mu się, pracuje tam do dziś, jednak w większości przypadków KAŻDY potrafił kodować w 5 językach. Oczywiście jeżeli poznasz jakiś język to przejście na inny nie jest żadnym wyczynem (głównie mowa o językach z "rodziny" C, przejście z C# na jave też jest łatwe, w drugą stronę też to działa, jednak javowcy piszący w szarpie mają strasznie nieczytelny kod). Sam kiedyś miałem krótki staż w firmie, która skupiała się na aplikacjach mobilnych, językiem wiodącym byłą java, jednak senior skierował wszystkich na szkolenia ze Scali (no tak, niby korzysta z wirtualnej maszyny javy, jednak to zupełnie inny język). Po szkoleniu w firmie nic się nie zmieniło, jak java rządziła tak rządzi, jednak wszyscy są mądrzejsi o jeden język. Znajomość każdego języka, czy frameworka to + dla Ciebie, oczywiście możesz nie lubić jakiegoś, ba, ja sam nie lubiłem javy, jednak jak zacząłem w niej pisać to nawet mi się to spodobało i uważam ten język za całkiem przyjemny. Możemy zatrzymać się na jednym języku, to oczywiste, jednak nie jest to korzystne dla nas.

 

Jeszcze mogę się odnieść do tego C++ jako pierwszego języka na start. Śmieszyło mnie stwierdzenie, że c++ jest dobry na start jeżeli chcemy się uczyć innych języków. No błagam, przecież oczywistym jest, że jak komuś zależy to na jednym języku się nie zatrzyma, chyba, że mówimy o kompletnym laiku, który potrzebuje znajomości czegoś tam do zrobienia czegoś tam, jednak taka osoba nie pozna wystarczająco takiego języka.

IMO ciągle twierdze, że C++ to słaby wybór na start, język ciężki, lepiej zacząć od czegoś lżejszego, jednak to już kwestia wyboru i mi nic do tego.