Cześć. Od kilku tygodni uczę się programować w C++ (oczywiście Symfonia pana Grębosza), i trochę też liznąłem biblioteki SDL. Z programowaniem mam zamiar związać swoją przyszłość, w związku z czym chciałbym zadać kilka pytań developerom VCMI.
Jak długo musieliście się uczyć, aby osiągnąć poziom taki, aby napisać tą grę? Jaki polecilibyście mi kierunek studiów (kończę 1 klasę LO)? Jakieś inne przydatne biblioteki do nauki, gdy już poznam SDL?
Cóż, trudno policzyć, ile się uczyłem. „Symfonia” krążyła po domu przez zdecydowaną większość mojego życia i wiedza jakoś przesiąkała, choć moje zrywy do nauki programowania były tyleż liczne co krótkie. W pisaniu prymitywnych programów z lubością wprawiałem się w okresie gimnazjalnym, ale nic sensownego nie stworzyłem. Dopiero wraz z początkiem liceum wpadłem w tryby ekstremalnego kursu algorytmiki. Jakkolwiek „skończyłem” go… przedwcześnie, to jednak zapewnił mi solidne podstawy teoretyczne pod pisanie bardziej złożonych programów. Tak naprawdę bez znajomości algorytmów i struktur danych programowanie nie ma sensu — trzeba nie tylko znać język, ale i mieć w nim coś do powiedzenia.
Potem to już tylko praktyka: w 2006 roku zainicjowałem pierwszy bardziej znaczący projekt: AI do silnika Spring (reimplementacja Total Annihilation). Razem z Dragonem rozwijaliśmy go przez kilka miesięcy. Nie osiągnął sukcesu i w sumie zakałapućkaliśmy się w pewnym momencie w różnych problemach tak bardzo, że odechciało nam się kontynuacji prac; niemniej zdobyliśmy nieco doświadczenia i obycia zarówno z C++ jak i środowiskiem Visual Studio. Projekt VCMI ruszył z końcem maja 2007 roku. Było to drugie znaczące przedsięwzięcie jakie podjęliśmy z Dragonem, za prace wzięliśmy się zaraz po zdaniu matury. Mieliśmy wtedy chyba wciąż jeszcze więcej uporu niż umiejętności… jak widać ten pierwszy jest ważniejszy dla przeżycia projektu.
Gdzieś zaraz na początku „Symfonii” była taka złota myśl: „Aby pisać, trzeba pisać”. Ona chyba najtrafniej odpowiada na twoje pytania. Żadna szkoła, żadne studia nie nauczą Cię dobrze programować. Co najwyżej zmuszą Cię do zbudowania pewnych podstaw, ale to samo w sobie nie jest wiele warte. Jeśli idzie o programowanie praktycznie wszystkiego nauczyłem się sam, w toku prac nad kolejnymi projektami. Poszukując rozwiązań wyzwań, przed jakimi stawałem oraz ucząc się na własnych błędach. Nie powiedziałbym, żebym w ciągu blisko trzech lat studiów nauczył się czegoś, co konkretnie mi się przydało do VCMI. C++ znałem na wyraźnie wyższym poziomie niż był nauczany. Nie twierdzę tutaj, że studia informatyczne nic programiście nie dają — bo dają sporo, poszerzając ogólną wiedzę i horyzonty informatyczne. Studia informatyczne są na pewno przydatne, niemniej nie są ani koniecznie ani wystarczające, by zostać programistą zdolnym do napisania gry. Nigdy nie zastąpią samodzielnie zdobytego doświadczenia.
Tak więc po pierwsze, staraj się jak najwięcej tworzyć. Postaw sobie jakieś możliwie proste, ale jednocześnie konkretne cele i dąż do ich realizacji. Różne minigry (nawet typu kółko i krzyżyk) są zawsze dobrą wprawką, nawet jeśli będziesz wynajdywać koło po raz n-ty. Czego się przy tym nauczysz, to już twoje. Po drugie, radzę jak najszybciej oswoić się z jakimś solidnym środowiskiem programistycznym, ze szczególnym poleceniem Visuala. Wielu lekceważy ten element, ale dobrze dobrane IDE jest ogromnie ważnym czynnikiem wpływającym na efektywność i wygodę naszej pracy. Naucz się obsługi debuggera. Nikt nie pisze od razu bezbłędnych programów, kluczowe jest by móc szybko odnajdywać błędy; nadto sama umiejętność krokowego wykonywania programów i śledzenia zmian zachodzących w ich wnętrzu jest pożyteczna także dydaktycznie (np. analiza działania jakichś przykładów).
Jeśli idzie o biblioteki, to trudno mi coś doradzić — do C++ jest ich ogromna ilość. Zasadniczo bibliotek szukasz i (jak znajdziesz) uczysz się, gdy potrzebujesz zrealizować jakąś konkretną funkcjonalność. Dopiero pod jej i twojego programu kątem, można dokonać rozważnego wyboru.
Wyjątkiem jest może zbiór bibliotek Boost, w którym jest sporo możliwości ogólnego zastosowania, które mogą się okazać przydatne praktycznie we wszystkich programach — ale nie polecałbym tych bibliotek początkującym.
Moje doświadczenie jest nieco inne, bo choć próbowałem programować niemal od lat najmłodszych, to efektem były prymitywne i nieużyteczne półprogramy, które obrazowały głównie brak jakiejkolwiek wiedzy. Logo, jakieś bzdurki na informatyce w gimnazjum / liceum, strony internetowe, VB… wreszcie skrypty do piątej części herosów. Tam przynajmniej dało się napisać coś, co działa i jest funkcjonalne bez ogromnego nakładu pracy.
Tak naprawdę nauczyłem się programować na pierwszym roku studiów, po intensywnym kursie C/C++. A potem dołączyłem do teamu i przez dwa ostatnie lata zdobyłem mnóstwo doświadczenia, nie tylko wklepując banalne formułki mechaniki gry, ale też dowiadując się, jak są i mogą być zbudowane złożone aplikacje, takie jak VCMI.
Nadal co prawda nie wiem wszystkiego i bazuję na tym, co stworzyli Tow & Tow Dragon.
Reasumując, jeśli niewiele umiesz, studia Cię tego nauczą. Jeśli umiesz, to masz problem z głowy.
Jeśli nie umiesz nic, to zapewne tak już pozostanie - pozdrowienia dla wydziału EiTi 
A mógłbyś napisać z czego się uczyłeś?
Kurs algorytmiki? Najlepiej zacząć od “Wprowadzenia do algorytmów” Cormena, potem to już potrzeba wyższej matematyki (rachunek różniczkowy funkcji wielu zmiennych, matematyka dyskretna, trochę teorii liczb) i można zabierać się za prawdziwą algorytmikę - “The art of computer programming” Donalda Knutha. Choć w praktyce informatyka teoretyczna przydaje się rzadko - zerknij na zadania z OI ( oi.edu.pl/ ), 95% z nich ma bezsensowną treść lub absurdalną wielkość danych wejściowych.
Ale Tuńczyk chcial pisać gry, nie dysertację doktorską. Polecanie początkującemu Cormena i potem Knutha, to tak jakby na pytanie, jak się nauczyć angielskiego, zalecić przeczytanie na początek słownika i tablic gramatycznych.
Cormen dla osoby początkującej jest dość nieprzystępny. W dodatku jest w gruncie rzeczy napakowany informacjami, które „normalnego programistę” mało obchodzą — na co mi dowody poprawności, skoro wierzę na słowo, że opisany algorytm działa? Jest to poprawna odpowiedź, na pytanie, z czego się naówczas uczyłem, ale nie polecam ani dla pcozątkujących ani dla programistów.
Nie chodzi o to, by się uczyć algorytmów. Programista musi mniej więcej orientować się, jakie są popularne algorytmy i jakie problemy rozwiązują. Kluczowa jest umiejętność sprowadzania zadań właśnie do tych podstawowych problemów. Szczegóły działania, implementację i takie tam, to można sobie w razie potrzeby wyszukać.
Odpisywałem krystianowi1995… zdawał się pytać właśnie o książki do informatyki teoretycznej. Choć może rzeczywiście powinienem to zaznaczyć. Swoją drogą Cormen wydaje mi się dość dobry dla programisty umiejącego coś napisać, ale chcącego poznać podstawy teoretyczne. Jak kogoś nudzą dowody poprawności to nie musi ich czytać, ale na pewno warto sobie zdawać sprawę, że stanowią kluczowy element algorytmiki (do tego stopnia, że moim zdaniem informatykę teoretyczną należałoby raczej nazywać matematyką obliczeniową lub komputerową, gdyż chodzi w niej właśnie o dowody a nie tworzenie jakichś programów).
Dzięki wielkie za odpowiedzi, właśnie jestem w trakcie pisanie klona starożytnego ponga 
Trzymamy kciuki i ufamy, że się pochwalisz, gdy twe dzieło już będzie działać!
A do tego czasu pozostaję do twojej dyzpozycji, jak zawsze chętny do dzielenia się dobrymi radami. 
Zauważyłem że samo w sobie wykrycie kolizji między piłką a paletką nie jest trudne, ale wykrycie, z której strony piłka uderzyła paletkę to trochę inna historia. Dzisiaj na biologii narysowałem sobie parę szkiców i chyba opracowałem zestaw odpowiednich warunków 
jak znajdę dość czasu to sprawdzę, czy to działa.
@tuńczyk
najprostszy model to model oparty na prawie zwierciadeł płaskich
tzn. kąt odbicia=kąt padania
najprościej jeśli wszystkie krawędzie są pionowe lub poziome
wtedy odbicie polega wyłącznie na pomnożeniu jednej składowej wektora prędkości przez -1
w przypadku wielu możliwyczh kątów pod którymi są krawędzie potrzebna jest już większa algebra na wektorach (choć wystarczy znajomość trygonometrii)
można też dodać tarcie (prostopadle do osi odbicia) a także zderzenia wielu piłek (który sprowadza się do poprzedniego problemu gdy zastosujesz obrót układu współrzędnych - przed i po zmianie) - jakby co zderzenie kul działa jak zderzenie ze ścianą która jest w miejscu wspólnej stycznej zetkniętych kul
opanowałem to wszystko w modelu 2d a do modelu 3d już niewiele zmian pozostało
ojojoj, nie złapałeś w czym mój problem. Piłka porusza się wyłącznie pod kątem 45 stopni (na razie). Na razie próbuje wyczaić czy piłka uderzyła od boku, czy od góry (lub dołu). Reakcja na kolizję na razie jest właśnie taka jak opisałeś - mnożenie jednego wektora przez -1. Mój problem jest w tym, że jeśli piłka odbije się od piłeczki od góry lub dołu, to trzeba zmienić prędkość w osi y, a jeśli od boku (tego dłuższego) to chodzi o oś x. Muszę opracować warunki, które określą czy piłka uderzyła z góry czy z boku. Chyba trochę to zagmatwałem w tych wyjaśnieniach, więc załączę obrazek :S
Nie bardzo rozumiem w czym tu problem… wykrywając kolizję musiałeś robić ifa na położenie piłeczki względem paletki - coś w stylu xPaletki-szerPaletki/2 < xPiłki ± rPiłki (+warunki na y). Po prostu nie gub informacji, który if wykrył kolizję tylko wykorzystaj ją dalej (czy jak ty to tam tobisz).
Każdy złożony problem należy spróbować podzielić na mniejsze. W tym wypadku na przykład najpierw opracować algorytm dla każdej z osi x/y, a dopiero potem połączyć je w całość.
A tak z ciekawości- za pomocą czego piszesz tą gre(tzn. w konsoli czy graficznie).
Co do twojego problemu to górna linia paletki ma wspołrzędne od (połorzenie paletki x,połorzenie paletki y) do (połorzenie paletki x + szerokość paletki ,połorzenie paletki y) , a dolna (połorzenie paletki x,połorzenie paletki y + wysokość paletki) do (połorzenie paletki x + szerokość paletki ,połorzenie paletki y + wysokość paletki).Po prostu zrób warunek ,czy piłka uderza w któryś z tych punktów.
tuńczyk a bierzesz pod uwagę narożnik?
a tak serio widzę że masz poważne problemy z podstwami.
ja bym sprawdził czy podczas kolizji środek piłki jest powyżej, poniżej, czy z boku paletki, przy czym dodatkowo jeśli jest powyżej/poniżej i z boku na raz wziąłbym pod uwagę odbicie od narożnika (w uproszczeniu przyjmując że jest zaokrąglony)
tak więc wystarczą proste warunki mniejsze/większe
PS: kolizje sprawdzasz własną funkcją, jakimś BoundingBoxem czy funkcją z biblioteki graficznej (kolizja pixel w pixel przy uwzględnieniu przeźroczystości jako poza-obiektem)?
@krystian: graficznie, no i do tego to już doszedłem sam.
@majaczek: pomysł porównywania środka piłki jest o tyleż prosty i genialny, że jest mi nieskończenie głupio że sam na niego nie wpadłem 
Na kolizje mam własną funkcję.
Jak już doprowadzę to-to do używalności to wrzucę tu źródła.
Hosting provided by DigitalOcean
