Patch 1.3 do Minecrafta połączy tryb singleplayer i multiplayer

Małgorzata Trzyna

2012/07/06 15:17

Już 1 sierpnia zostanie wprowadzona do Minecrafta aktualizacja 1.3 na PC. Najważniejszą zmianą, jaka nas czeka, jest połączenie trybów singleplayer i multiplayer.

Oznacza to, że po udostępnieniu API dla moderów (w późniejszym terminie) nie trzeba będzie tworzyć kilku wersji modyfikacji, po jednej dla singleplayera i multiplayera. Połączenie tych trybów oznacza, że łatwiej będzie również naprawiać bugi – w obu jednocześnie. Są też wady tego rozwiązania. Gdy tryb dla pojedynczego gracza stanie się jedynie nakładką na tryb wieloosobowy, gra będzie wymagać większej mocy obliczeniowej od naszego sprzętu. Mojang ma jednak nadzieję, że w kolejnym patchu, 1.4, uda się ją nieco zoptymalizować.

Lista poprawek w patchu 1.3:

Poprawiono liczne błędy w grze. Ci, którzy grają głównie na multiplayerowych serwerach, powinni cieszyć się płynniejszą i bardziej stabilną rozgrywką. Wprowadzono kodowanie pakietów sieciowych, by zapobiegać kradzieży sesji. Okno czatu zostało zaktualizowane, by ułatwić edytowanie wiadomości i umożliwić wstawianie linków
Połączenie singleplayera z multiplayerem pozwala na udostępnianie swoich światów w sieci lokalnej, a także wykorzystywanie komend, jak np. /give, jeśli na zezwolimy na cheaty
Dodano szmaragdy i szmaragdowe bloki oraz system umożliwiający kupowanie przedmiotów u mieszkańców wiosek
Dodano możliwość pisania w książkach i zostawiania swoich opowieści dla innych graczy
Dodano nowe elementy w terenie i opcję otrzymania „bonusowej skrzynki”, by ułatwić start w grze
Dodano linki umożliwiające ustawianie nowych pułapek i mechanizmów
Dodano mnóstwo nowych przedmiotów i możliwość otrzymywania magicznych kulek również za kopanie i przetapianie, nie tylko za zabijanie potworów.

GramTV przedstawia:

Tymczasem w Minecrafcie w wersji na Xboxa 360 już wkrótce będzie można wypróbować lub kupić pakiet 40 skórek. Wśród nowych modeli znajdują się: Creeper Man, Trials Man, Covenant Grunt, King, Jack of Blades, Clayton Carmine, Banjo, Ms ‘Splosion Man oraz Prisoner. Możecie zobaczyć je na poniższych screenach:

Źródło: mojang.com, playxbla.com

Komentarze

KapiX

Gramowicz

10/07/2012 13:57

Dnia 07.07.2012 o 07:34, ziptofaf napisał:

Ciężko się z tobą nie zgodzić. Choć faktem jest że samo projektowanie aplikacji w zwykłym C JEST trudniejsze niż w Javie/C#. Jednak pełna obiektowość języka, możliwości dziedziczenia, bardzo ładnie rozwiązany garbage collector, ogólnie wszelki debugging jest o wiele prostszy w Javie niż w C (nie bez powodu wśród programistów krążyły jednak dowcipy w stylu: "Mój program w C się kompiluje więc na pewno będzie działać"). Do tego mamy wielowątkowość dostępną od ręki, bez konieczności bawienia się z dodatkowymi bibliotekami. Osobiście uważam iż języki pokroju Javy/C# są o wiele lepszymi paradygmatami do nauki obecnie niż kurczowe trzymanie się starych nieobiektowych rozwiązań.

No i właśnie niektóre z tych udogodnień są przyczyną dla której pisanie gier w Javie (i ogólnie językach zarządzanych) jest odradzane. Garbage collector może i jest ułatwieniem, ale bywa nieprzewidywalny w tym sensie, że może włączyć się w dowolnym momencie a to spowolni grę. W aplikacji biznesowej nie stanowi to żadnego problemu i może być nawet niezauważalne, ale w momencie gdy gra wyciska ostatnie soki z komputera, uruchomienie garbage collectora bywa bolesne. (Wiem, że można sterować jego działaniem, ale w temat się zbytnio nie wgłębiałem, w Javie na codzień nie piszę, stąd nie wiem na czym to sterowanie polega i czy jest rozwiązaniem problemu.)tl;dr: Java do aplikacji i nauki jak najbardziej, do gier - nie.

Dnia 07.07.2012 o 07:34, ziptofaf napisał:

Zresztą podejrzewam (bo kodu źródłowego jednak nie widziałem) że te problemy z wydajnością to nawet nie są winą wybranego języka (choć nie wykluczam że zmiana języka mogłaby pomóc, nie próbowałem robić pełnoprawnych aplikacji w 3D w Javie i porównywać ich z C więc mogę się opierać tylko na wynikach testów) a po prostu fatalnej optymalizacji. Technicznie ten tytuł nie ma nic co usprawiedliwiałoby tak wysokie wymagania i podejrzewam że powodem jest to że to jednak Notch pracował nad nim w zasadzie sam, nawet nie wiem czy ktoś potem przepisywał ten kod na czysto. To i powstał taki potworek - każdy wie jak się kończy dopisywanie kolejnych linii do już gotowej aplikacji... a tych dodatkowych elementów jest w tej chwili więcej niż oryginalnej gry.

Też się domyślam, że kod Minecrafta jest niezoptymalizowany. I tutaj powstaje pytanie: co dają Notchowi te wszystkie javowe udogodnienia (ot, wspomniana przez Ciebie wielowątkowość) skoro z nich nie korzysta? :P

Usunięty

07/07/2012 11:31

Gdyby sobie wyobrazić King=Lord Britih z Ultimy... hm.

Usunięty

07/07/2012 07:34

Dnia 07.07.2012 o 01:03, KapiX napisał:

Naprawdę nie wiem, czemu Notch trzyma się tego języka, przecież gdyby jego gry miały mniejsze wymagania, więcej ludzi by je kupiło. Przenośność Javy IMHO nie jest argumentem, bo jest dużo bibliotek dla C, które portowanie aplikacji upraszczają do bólu.

Ciężko się z tobą nie zgodzić. Choć faktem jest że samo projektowanie aplikacji w zwykłym C JEST trudniejsze niż w Javie/C#. Jednak pełna obiektowość języka, możliwości dziedziczenia, bardzo ładnie rozwiązany garbage collector, ogólnie wszelki debugging jest o wiele prostszy w Javie niż w C (nie bez powodu wśród programistów krążyły jednak dowcipy w stylu: "Mój program w C się kompiluje więc na pewno będzie działać"). Do tego mamy wielowątkowość dostępną od ręki, bez konieczności bawienia się z dodatkowymi bibliotekami. Osobiście uważam iż języki pokroju Javy/C# są o wiele lepszymi paradygmatami do nauki obecnie niż kurczowe trzymanie się starych nieobiektowych rozwiązań.Zresztą podejrzewam (bo kodu źródłowego jednak nie widziałem) że te problemy z wydajnością to nawet nie są winą wybranego języka (choć nie wykluczam że zmiana języka mogłaby pomóc, nie próbowałem robić pełnoprawnych aplikacji w 3D w Javie i porównywać ich z C więc mogę się opierać tylko na wynikach testów) a po prostu fatalnej optymalizacji. Technicznie ten tytuł nie ma nic co usprawiedliwiałoby tak wysokie wymagania i podejrzewam że powodem jest to że to jednak Notch pracował nad nim w zasadzie sam, nawet nie wiem czy ktoś potem przepisywał ten kod na czysto. To i powstał taki potworek - każdy wie jak się kończy dopisywanie kolejnych linii do już gotowej aplikacji... a tych dodatkowych elementów jest w tej chwili więcej niż oryginalnej gry.

Trwa Wczytywanie