Twórca TrueCraft zbiera dotacje na rozwój projektu

14
2667
TrueCraft, Minecraft
TrueCraft, Minecraft

O projekcie TrueCraft, mającym na celu stworzenie od zera otwartej implementacji Minecrafta w wersji 1.7.3 Beta, pisaliśmy kilka miesięcy temu. Od tego czasu projekt stopniowo posuwał się do przodu, dorabiając się nie tylko nowych elementów fizyki, ale również własnego klienta do gry. Jednak w ostatnim wpisie na oficjalnej stronie gry Sircmpwn, główny developer i pomysłodawca całego przedsięwzięcia, postanowił ogłosić o zbiórce pieniędzy na rzecz projektu. W TrueCraft, podobnie jak w jego pierwowzorze, wcielimy się w bliżej nieznaną postać, której przyjdzie budować i walczyć w zbudowanym z sześciennych klocków świecie.

TrueCraft - las

Według Sircmpwn, dotacje zebrane w odpowiedniej ilości mają pozwolić mu na cały tydzień pełnodniowych prac wyłącznie nad rozwojem projektu. Dalej jednak całość będzie dostępna dla każdego do pobrania za darmo, wraz z pełnym kodem źródłowym. Osoby zainteresowane wsparciem finansowym przedsięwzięcia mogą to zrobić już teraz poprzez platformę Fosspay (zresztą również stworzoną przez tego samego developera). Nadal również możliwa jest pomoc poprzez bezpośrednie dołączenie do rozwoju projektu na GitHub lub kanale IRC #truecraft, dostępnego na serwerze irc.esper.net.

ŹRÓDŁOtruecraft.io/blog
Poprzedni artykułDruga i trzecia część Saint’s Row wyjdą na Linuksa
Następny artykułKING Art Games tworzy grę o Krasnoludach na podstawie książek

14 KOMENTARZE

  1. Czy ten TrueCraft, tak jak oryginał, jest pisany w żałosnej Javie zżerającej zawsze o 100MB więcej RAMu niż jest zainstalowane w komputerze?

    • Twórca zaznaczył, że chce by TC był w pełni zgodny z oryginałem, więc to raczej oczywiste. :P Java nie jest taka straszna jak ją malują, jak się ma 4GB RAMu można grać płynnie z prawie całkiem wymaksowanymi ustawieniami. Oczywiście trzeba mieć też jakiś tam procek i kartę graficzną, ale za grafikę odpowiada natywny kawałek kodu a obciążenie procesora jest dosyć niskie. Java jest idealna do takich gier.

    • Java nie nadaje się do absolutnie niczego.

      Ostatnio przekonałem się o tym używając Android Studio. Proste IDE, nie ma nawet 10% funkcjonalności KDevelop, a przy praktycznie pustym projekcie zeżarło 2GB RAMu. Przy odpalonych innych aplikacjach spowodowało to swapowanie na dysk i słowa na 'k’ same cisnęły się na usta. Do tego muli jak cholera.
      Java to absolutne dno, tak samo jak .net.

      Java to był ciekawy proof-of-concept na to, że za pomocą wirtualnej maszyny i bajtkodu da się zaimplementować przenośną platformę dla aplikacji. I tyle.
      Dzisiaj przenośne aplikacje mogą być natywne, bo epoka microsoftu minęła i nastał czas standardów i przenośnego kodu.

    • Java bierze więcej pamięci, bo to maszyna wirtualna.
      To tak jakbyś odpalił dowolną dystrybucję Linuxa w VirtualBoxie pod Windowsem i stwierdził że to beznadziejny system, bo bierze zawsze 500 ram więcej, niż faktycznie potrzebuje i lepiej pisać natywnie na Windowsa.
      Java jest dobra, jeśli chcesz skompilować kod 1 raz i odpalać dosłownie wszędzie, gdzie masz zainstalowaną Javę, lub odpalić jakąś aplikację, którą uruchamiasz raz na ruski rok i pozwalasz JITowi skompilować i zoptymalizować kod. W przeciwnym razie owszem, są lepsze języki.

    • Wyraźnie napisałem do czego wg mnie nadaje się java, wspomniany przez ciebie program do tego nie pasuje. Co ci po przenośnym kodzie jeżeli deweloper ma gdzieś Linuksa? A epoka M$ nie minęła, i trwać będzie dalej doputy, dopóki deweloperzy nie zrezygnują z powszechnie wykorzystywanego DX i WinAPI.

    • I tak i nie.
      Java ma sens, ale wymaga bardzo przemyślanej budowy systemu. Dzięki budowie systemu dla Javy, otrzymuje się sprawnie działającą Javę. Tyle, że takich systemów (nie licząc wbudowanych) były dwa – dwie wersje OS/2 oraz pewna wersja Sunowskiego. Oba już nie wspierane.
      Problem jest w tym, że developerzy Linuksa (i większości softu Open Source) dostają od bogatych tatusiów sprzęt, na którym nie mogą nauczyć się optymalizacji swojego kodu, bo nie zauważają zmian. Atomizacja zadania, która tak dobrze się sprawuje w Uniksie, nie zawsze idzie w parze z optymalnością, szczególnie jeżeli chodzi o I/O. I stąd problemy.
      Przykład spoza Javy: Biblioteka DjvuLibre. Podział zadania kompresji dokumentu na skryptowane fragmenty spowodował, że segmentacja warstw (istota kompresji DjVu) została potraktowana po macoszemu, a słownikowe scalanie stron (zmniejsza objętość o 15-20%) nie istnieje, bo psułoby szyk skryptów przetwarzających strona po stronie.
      Java ma swoje miejsce. Można ją portować, działa na niektórych systemach przenośnych i wbudowanych, gdzie Qt nie dałby rady z racji wymaganych bibliotek. Ale uruchomienie naprawdę wielkich aplikacji w Javie sprawi problem nawet na 2-3 letnim komputerze.

      P.S.
      ->Roman, Z Mono mam doświadczenia gorsze niż z Javą, ale może to kwestia implementacji w Debianie 7, że program do pobierania plików tuż po uruchomieniu konsumuje 250MB RAMu.

    • Nie wątpię. Wielu programistów narzeka na Mono. A użytkownicy Unity3d bluźnią na zawieszający się Monodevelop.
      Co do Javy zawsze się mówi o tym, że można z niej wycisnąć, jeśli się dobrze programuje i inne tego typu sprawy. Mnie to nie przekonuje. Kiedyś widziałem prezentację pracownika RH o tym jak paskudnie wygląda optymalny kod w Javie.

    • zupełnie do niczego. Normalnie nic a nic. Człowieku, jeśli czegoś nie rozumiesz, to po prostu nie komentuj, nie rób z siebie kretyna.

  2. Warto zrobić takie porównanie otwartych alternatyw z użyciem RAMu, CPU, wymaganiami graficznymi. Bawiłem się wczesną wersją projektu Minetest i było po prostu fajnie, ale inny klon, w Javie, doszczętnie zapchał 2GB RAMu (!), nie mając nawet takiego ciekawego generatora proceduralnego jak Minetest.

ZOSTAW ODPOWIEDŹ

Proszę wpisać swój komentarz!
Proszę podać swoje imię tutaj