Portowanie gier z XNA WP7 na Windows 8 MonoGame

Posted on by

MonoGameDo tej pory omówiłem już projekt MonoGame, jego szablony oraz przedstawiłem sposób na XNA Content Pipeline. Najwyższy czas na portowanie prawdziwej gry z Windows Phone 7 do Windows Store.

Ten post jest częścią serii poświęconej tworzeniu i portowaniu gier dla Windows Store w technologii XNA (MonoGame).

Zobacz też

Projekt źródłowy

Źródłem będzie moja aplikacja Classic Blocks  czyli pospolity Tetris. Projekt został stworzony na Windows Phone 7 jako aplikacja Silverlight/XNA. Menu gry, opcje są wykonany w technologi Silverlight (XAML/C#), a sama gra jest napisana w XNA.

Classic Blocks jest grą 2D, sterowanie odbywa się za pomocą dotyku. Podczas rozgrywki gracz może słuchać muzyczki i efektów dźwiękowych. Dodatkowo obsługiwana jest wibracja.

Zakładanie nowego projektu Windows Store

Zaczynamy od utworzenia nowego projektu MonoGame / MonoGame (XAML) dla Windows Store (na początek zrobimy całą część XNA, w przyszłości przerobimy menu XAMLowe, ale o tym będzie osobny wątek).

Nowy projekt MonoGame

Importowanie plików

Teraz przenosimy źródła naszej gry do nowego projektu. Importujemy jak leci wszystkie pliki oraz katalogi (no może poza App.xaml i App.xaml.cs, i nie nadpisz sobie głównego pliku z grą, gdzie jest pętla Update-Draw. Nie chesz jej stracić. Potem ręcznie przeniesiemy logikę tego pliku).

Gdy wszystkie źródła są już gotowe musimy skompilować projekt i rozwiązać napotkane problemy.

Usuwanie zbędnych przestrzeni nazw

W moim przypadku przy pierwszej próbie kompilacji, kompilator naliczył ponad 120 błędów. Ale spokojnie. Zdecydowana większość to nieprawidłowe przestrzenie nazw. Okazało się, że kilka plików, kilka klas importowało (zupełnie niepotrzebnie) przestrzenie charakterystyczne dla Windows Phone. Gdy je usunąłem zostało już tylko 10 błędów.

Usuwanie innych odwołań do elementów platformy

Następnie wykomentowałem fragmenty gdzie aplikacja używała wibracji, MessageBoxy itd. Elementy charakterystyczne dla danej platformy. Jest to logiczne. Musimy nauczyć się tak projektować nasze gry, by jej core był możliwie jak najbardziej niezależny od platformy i urządzenia.

Na koniec zostało mi posprzątanie App.xaml.cs, gdyż tam miałem np. obsługę cyklu życia aplikacji np. Suspended, Resume, SaveState, LoadState itd. Takie rzeczy na początek można usunąć (wykomentować), a później zaimplementować je ponownie, ale już konkretnie tak jak się to robi w WinRT.

Naprawianie Game.cs

Ostatnia rzecz, którą naprawiłem to przeniesienie logiki takich kawałków jak LoadContent, Update(), Draw() – czyli wczytywanie Content’u, główna pętla gry itp.

Teraz projekt zaczął się już kompilować. Pierwszy sukces, ale… w runtime aplikacja się wysypuje, bo okazuje się, że nie ma jeszcze naszych assetów, czyli tekstur, dźwięków, muzyki itd.

Importowanie Content’u *.XNB

W osobnym poście opisywałem problem z XNA Content Pipeline w projektach MonoGame dla Windows 8. Ale to przecież żaden problem dla nas.

Uruchomiłem Explorer Windows, poszedłem do odpowiedniego katalogu mojej gry Classic Blocks pod Windows Phone, znalazłem katalog z build’em, a następnie skopiowałem cały Content i wkleiłem go do analogicznego katalogu z Classic Block dla Windows 8.

Następnie powrót do Visual Studio 2012, Run i włala! Projekt skompilował się, uruchomił i wszystko zaczęło działać.

Interakcja z użytkownikiem

Ważne jest by testować aplikację na symulatorze w trybie Basic touch mode. Aplikacje Windows Phone zazwyczaj są obsługiwane przez dotyk (klasa TouchPanel). Okazuje się, że na Windows 8 na dzień dobry mamy dwa różne input’y: dotykowy oraz myszka. Co więcej, w Windows 8 mamy też przecież klawiaturę. Ba! Żeby było mało, ktoś może mieć podłączonego pada z Xbox’a 360. Teraz należało by uwzględnić w naszym projekcie różne sposoby interakcji z użytkownikiem.

Ale tak na prawdę to nie jest to żadna nowość. Przykłady „best practices XNA” przedstawiają jak wcześniej należało sobie radzić z takim problemem, gdy np. mieliśmy wspólne źródła gry na Xbox, Windows i Windows Phone. To tylko ja byłem na tyle  leniwy  i wygodny (i głupi chyba..), że pisałem konkretnie, tylko i wyłącznie pod Windows Phone, nie myśląc o innych platformach.

Skalowanie, rotacja

Na koniec jeszcze jedna uwaga. Windows Phone 7.5 to jasna specyfikacja urządzenia. Rozdzielczość telefonu to 800×480 px. Ja idąc na łatwiznę przygotowałem sobie grafiki właśnie pod taką rozdzielczość. Po uruchomieniu gry na Windows 8 w rozdzielczości 1920×1080 (Full HD) nie potrafiła się ona odpowiednio przeskalować. Zawartość gry wyświetla się w górnym lewym rogu, a resztę ekranu wypełnia CornflowerBlue.

Zatem kolejnym krokiem była delikatna modyfikacja źródeł w celu wyliczenia współczynnika skali i zaaplikowanie go w logikę aplikacji. Zabieg spowodował, że aplikacja skaluje się i centruje na całym ekranie nie zależnie od rozdzielczości i orientacji urządzenia. Przy tej okazji to samo muszę zastosować w swoich źródłach Windows Phone, by moja aplikacja była gotowa na Windows Phone 8 i nowe, wyższe rozdzielczości telefonów.

W kolejnych postach zajmę się menu gry w XAML i cyklem życia aplikacji.