Cześć
Wróciłem na forum po długiej przerwie (zawitałem tutaj w styczniu) zobaczyć jak Wam leci i jak wygąda sprawa z Clashem Deluxe. Otóż jestem jedną ze zmotywowanych osób umiejących kodzić, która chce pomóc w projekcie. Prawdopodobnie jestem najmniej doświadczoną osobą w tej dziedzinie z programistów na tym forum. Jednak umiem pisać w Javie, C, C++ na poziomie wystarczającym do napisania gry jak Clash.
Ja myślę, że najpierw warto byłoby zacząć od przysłowiowych fundamentów i ustalić, czy w danym momencie ktoś w ogóle pracuje nad Clashem Deluxe.
Kilka miesięcy temu napisałem, że rozpocząłem prace nad remake'm Clasha. Aktualnie studiuję i (niestety) praktycznie nie mam czasu na nic innego niż studia. Dlatego byłem zmuszony wstrzymać projekt. Ale mam zamiar go wznowić i chciałbym, razem z Wami, napisać Clasha (a przynajmniej 75%... albo chociaż połowę) w trakcie wakacji.
Przeczytałem posty w tym temacie i chciałbym dołączyć się do dyskusji, bo poruszono bardzo ważne tematy.
Wiem, że temat stary, ale naszyły mnie pewne doświadczenia z innego remake gry (Settlers 2 => Widelands):
1. Nowy projekt jest Open Source i nie ma linijki kodu wspólnego z orginałem
Otóż moim zdaniem Clash Deluxe powinien być Open Source, bo to znacznie przyspieszyłoby proces tworzenia gry. Ja jestem jedną z tych osób, które niechętnie dzielą się kodem
, ale jest to najlepsze rozwiązanie.
2. Nowy projekt ma nową szatę graficzną i muzykę
Oczywiście będziemy czerpać z zasobów oryginalnej gry. Z drugiej strony dobrym pomysłem byłoby znalezienie grafika, który stworzyłby szatę graficzną wzorowaną na oryginalnej, ale za to z większą ilością detali. Uważam, że należy taką opcję rozważyć, ale to dopiero gdy projekt będzie ukończony.
3. Nowy projekt potrafi otwierać stare pliki (tutaj: mapy, misje, logikę CPU?), ale również ma swoje własne, które są jego podstawą
Według mnie najlepszym rozwiązaniem byłoby napisanie
wszystkiego od nowa. Dlaczego mielibyśmy używać plików i algorytmów sprzed dwóch dekad? Po pierwsze gry były wtedy pisane bardzo niskopoziomowo (w asemblerze, w C), zatem rozszyfrowanie plików map itp. to według mnie strata czasu (trzebaby rozłożyć grę na czynniki pierwsze i zrozumieć w jaki sposób wczytuje ona pliki). Szybciej byłoby napisać edytor do tworzenia map (który dodatkowo można dodać do gry), na to wystarczy kilka dni, a potem dzięki niemu odtworzyć mapki ręcznie lub za pomocą jakiegoś skryptu.
4. Nowy projekt rozwija się już ponad 10 lat i końca nie widać
Moim zdaniem jak napiszemy Clasha w języku wysokiego poziomu: Java, C#, ewentualnie C++, to ukończymy go kilka miesięcy. Java nie jest zoptymalizowana do takich projektów jak gry, ale akurat gry turowe, strategiczne, nie wymagają dużo pamięci operacyjnej. Dodatkowo Java jest bardzo elastyczna i można przenieść naszą grę na np. Androida, co myślę że byłoby fajne
Grać w Clasha na smartfonie (właściwie można grać w niego na smartfonie również teraz ale jest to trochę problematyczne).
Co do pomysłów, co poprawić, to proponowałbym dostarczenie WYBORU możliwości opcji logiki wewnątrz gry, bo nie dla każdego na przykład zmęczenie jednostek jest złe. Ja na przykład je bardzo lubię.
Ogranicza nas tylko wyobraźnia
Co do kodu źródłowego gry: forma, w jakiej gra została stworzona i słowa twórców sugerują (bez obrazy dla nikogo!), że projekt nie było tworzony według nam współcześnie znanych standardów z innych projektów. To również daje do myślenia: prawdopodobnie trzeba byłoby i tak napisać wszystko na nowo, bo byłyby miejsca nie do ruszenia, a jakiś bug tam by siedział.
Dokładnie! Z zupełności się zgadzam. To co napisałem powyżej
Warto też przemyśleć architekturę kodu / programu, żeby za 10 lat nie musieć przepisywać wszystkiego od nowa (rozdzielić różne silniki poszczególnych części od siebie, nawet jeśli coś wydaje się bliskie sobie). No i jeśli chcielibyśmy stworzyć edytor map / edytor czegokolwiek, to warto wprowadzić to jako swoisty framework wewnątrz gry. Aktualnie siedzę nad projektem (język: Python), w którym utworzyłem chyba z 5 różnych frameworków i silników do konkretnych zadań. Dodanie rozszerzenia funkcjonalności w takiej architekturze to tylko edycja pliku tekstowego (tu akurat json), zamiast kodzenia nowej części. Oczywiście niczego nie narzucam, a tylko proponuję
Stworzenie dobrego schematu projektu pomoże później w jego rozwoju