Warsztat.GDCompo!ProjektyMediaArtykułyQ&AForumOferty pracyPobieranie

Opisz napotkaną sytuację, a redakcja niezwłocznie znajdzie rozwiązanie!

wyślij anuluj

Mophun - gry na komórkę

Tekst został importowany z Warsztatowych artykułów. Jego oryginalnym autorem jest exor. Jeżeli został importowany poprawnie, usuń ten szablon!

Wstęp

Chyba każdy z nas kiedyś przynajmniej raz grał w jakąś grę na swoim telefonie komórkowym. Nieważne czy to była gra napisana w Javie, asemblerze czy C++. Gwałtowny rozwój telefonów komórkowych spowodował że programiści coraz chętniej tworzą gry na te platformy. Kolorowe wyświetlacze, coraz lepszy dźwięk, coraz mocniejsze procesory i większa ilość RAM-u : to wszystko spowodowało że przeżywamy teraz prawdziwy wysyp mobilnych gier. Istnieje tylko jeden problem. Każdy telefon różni się przecież tym co ma w środku, systemem operacyjnym, etc. Czyli oznacza to że kiedy zrobimy grę na jakiś konkretny model telefonu to nie będzie on działał na innych. Rozwiązaniem tego problemu miało być powszechne zaimplementowanie Javy w każdej komórce, ale w rezultacie zaowocowało to powstaniem różnych implementacji Javy z zależności od liczby producentów telefonów komórkowych. Co oznacza dalej tworzenie kilku wersji tej samej gry dla różnych modeli.

Zdecydowaną większość gier na pecety pisze się w języku C/C++. Szwecka firma Synergenix postanowiła dać programistom możliwość pisania gier na komórki właśnie w tym języku. Kilku byłych "pecetowych" programistów napisało wspólną platformę(Mophun RTE) dla kilku modeli telefonów. Silnik mophuna mieści się w pamięci podręcznej procesora co jeszcze bardziej przyspiesza działanie gier. Programy można pisać w C, C++ i asemblerze. Można tworzyć aplikacje z grafiką 2D jak i 3D, a opanowanie biblioteki Mophuna jest banalnie proste, zwłaszcza dla tych którzy programowali na PC (np. biblioteka 3D przypomina OpenGL). Programiści z Synergenix mówią że Mophun jest nawet kilkanaście razy wydajniejszy od znanej J2ME.

Wbudowany silnik mophuna ma już wiele różnych telefonów, a liczba ta cały czas się powiększa. Po więcej informacji odsyłam na stronę internetowa www.mophun.com.

Stamtąd, po wcześniejszym zarejestrowaniu, można ściągnąć SDK. Wcześniej jednak proponuje zapoznać się z wszystkimi informacjami na tej stronie, zwłaszcza w umową licencyjną. W tym SDK znajdują się kompilatory, biblioteki, dokumentacje i tutoriale oraz emulator. Po zainstalowaniu tego na dysku radze zajrzeć też do katalogu 'tutorials' żeby zapoznać się z wszystkimi możliwościami tej platformy.

Po zainstalowaniu dobrze jest wpisać ścieżkę do katalogu mophun/bin do zmiennej środowiskowej PATH. Jeśli masz Win95/98/Me to po prostu dopisz tą linijkę do pliku autoexec.bat:

PATH = %PATH%;c:\mophun\bin;

Jeśli dysponujesz nowszym windowsem to wejdź do Panel Sterowania/System/Zaawansowane/Zmienne środowiskowe znajdź zmienną Path i dodaj do niej: c:\mophun\bin;

Konfiguracja

Pakiet Mophun SDK można skutecznie połączyć np. z Visual C++, aby pisać swoje gry właśnie w tym środowisku. Opiszę teraz jak odpowiednio skonfigurować VC++ 6, po reszte informacji (np. konfiguracje z .NET) odsyłam do dokumentacji.

Całość polega właściwie na stworzeniu makefile'a:

  • Otwórz Visual C++ 6
  • Wejdź do File | New i zakładce 'Projects' zaznacz 'Makefile'
  • Nazwij swój projekt, wskaż ścieżkę gdzie ma być utworzony i wciśnij OK

  • Potem wyskakuje ci okienko dot. generowania pliku 'debug' wpisz swoją nazwe makefile'a dla debug'a oraz nazwę pliku wykonywalnego który będziesz debugował. Plik ten musi mieć rozszerzenie *.mpn .

  • Podobnie robisz dla pliku 'release' wpisując inną nazwę makefile'a (np. makefile_release) i mpn'a (JakisTamProjekt_release.mpn), a następnie wciśnij 'Finish' i OK.
  • Teraz trzeba zrobić owe makefile'y . Otwórz notatnik. I zapisz czysty plik jako makefile_debug w katalogu z projektem. Potem musisz jeszcze dodać ten plik do projektu. Otwórz go w VC i piszemy:
DEBUGCFLAGS =  -g -WALL -pedantic  -D_MEMDEBUG -fvstudio

#rozmiar stosu i danych
STACKSIZE=1024
DATASIZE=20000

# Tu się wpisuje nazwy plików w projekcie, ale z rozszerzeniem .o
# czyli np. jeśli mam plik main.cpp to tutaj wpisuje main.o tak jak
# jest to pokazane poniżej. Przy dodaniu każdego pliku w do projektu
# trzeba pamiętać żeby tutaj też go dodać
OBJS =	\
			res.o     \
			cpp.o     \ 
			main.o

all: JakisTamProjekt_debug.mpn

res.o: res.morc
	morc -v res.morc


.cpp.o:
        pip-g++ -c $(DEBUGCFLAGS) -o $@ $<

JakisTamProjekt_debug.mpn: $(OBJS)
        pip-g++ -o $@ $(OBJS) -mstack=$(STACKSIZE) -mdata=$(DATASIZE) -g -mversion=1.1 -ldatacert
  • Teraz musimy zrobić plik makefile_release. Zrób dokładnie tak samo jak w poprzednim punkcie:
RELEASECFLAGS = -s -O9 -WALL -pedantic -DNDEBUG -fvstudio

STACKSIZE=1024
DATASIZE=20000

OBJS =	\
			res.o		\
			cpp.o		\
			main.o


all: jakisTamProjekt_release.mpn


res.o: res.morc
	morc -v res.morc

.cpp.o:
        pip-g++ -c $(RELEASECFLAGS) -o $@ $<


JakisTamProjekt_release.mpn: $(OBJS)
        pip-g++ -o $@ $(OBJS) -mstack=$(STACKSIZE) -mdata=$(DATASIZE) -s -mversion=1.1 -ldatacert
  • Została jeszcze jedna rzecz. Mophun przystosowany jest raczej do języka C niż C++, dlatego aby programy napisane w C++ prawidłowo się komplikowały trzeba stworzyć jeszcze jeden plik którego nazwiemy cpp.cpp . Będzie on zawierał np. definicje operatorów new i delete. Wiec tworzymy nowy plik, nazywamy go cpp.cpp i wpisujemy:
#include <vmgp.h> #include <stdlib.h> inline void *operator new (const unsigned long size) { return vNewPtr (size); } inline void *operator new [] (const unsigned long size) { return vNewPtr (size); } inline void operator delete (void *memory) { if (memory) { vDisposePtr (memory); } } inline void operator delete [] (void *memory) { if (memory) { vDisposePtr (memory); } } // the in-place operator new inline void *operator new (const unsigned long size, void *mem_ptr) { return mem_ptr; } extern "C" void __cxa_pure_virtual (void) { exit(-1); }

W tym pliku są definicje operatów new i delete. Nie trzeba ich już deklarować w żadnych plikach nagłówkowych, te funkcje po prostu muszą być dołączone do projektu. Funkcja __cxa_pure_virtual zapewnia polimorfizm.

Pierwszy program

Nadszedł w końcu czas na napisanie pierwszego programu na komórkę. Nie będzie on raczej żadną zapierającą dech w piersiach grą, a ma na celu sprawdzenie czy wszystko, to co zrobiliśmy wcześniej, prawidłowo działa. Proponuje teraz stworzyć plik main.cpp w którym napiszemy:

#include <vmgp.h> // ten nagłówek musi być w każdym programie Class JakasKlasa { int a,b,c; public: JakasKlasa(int _a, int _b, int _c) a(_a), b(_b), c(_c) { } }; int main() { JakasKlasa * JakisObiekt = new JakasKlasa(10, 20, 30); vClearScreen(VMGP_GREEN); // czyszczenie obrazu kolorem zielonym vFlipScreen(1); // przełączenie tylnego bufora delete JakisObiekt; return 0; }

Trzeba jeszcze stworzyć inny plik o nazwie res.morc. napiszemy w nim tak:

m_info METAINFO
{
	"Tilte"           	: "Moj Pierwszy Projekt"
	"Vendor"          	: "exor"
	"Copyright info"  	: "(c) warsztat, 2005"
	"Program version" 	: "0.1 beta"
	"Help"			: "http://forum.warsztat.gd/"
}

W pliku res.morc znajdować się będą deklaracje różnych zasobów programu (bitmapy, czcionki, dźwięki, etc). Oprócz zasobów znajduje się tzw. METAINFO, jest to struktura, która zawiera podstawowe informacje o programie. Można tu też umieszczać informacje na temat certyfikatu programu, są to dane stosowane do zabezpieczenia gry przed piractwem. Na razie nie korzystamy z żadnych zewnętrznych zasobów, wiec w tym pliku znajduje się tylko METAINFO.

Po skompilowaniu i zlinkowaniu, jeśli nie popełniłeś żadnych błędów, w katalogu z projektem znajdź plik JakisTamProjekt_debug.mpn albo JakisTamProjekt_release.mpn uruchom go w emulatorze. Powinien pokazać ci się zielony ekran, jeśli nie to znaczy że popełniłeś jakieś błędy.

Drugi Program

Teraz czas na stworzenie jakiegoś większego programu. Do naszego wcześniejszego projektu dodamy kilka szczegółów. Na ekranie telefonu będzie latał mały, zielony smok.

Najpierw dodajmy klatki animacji smoka. Będzie to bitmapa, składająca się z pięciu klatek animacji (jedna pod drugą). Bitmapa musi być 256 kolorowa. Rozdzielczość jednej klatki to 30x25, czyli cała bitmapa będzie miała rozmiar 30x125.

Do pliku res.morc, na dole, dodaj linijkę:

BITMAP_DRAGON PACKED SPRITE FORMAT RGB332 "dragon.bmp"

Od tej pory, przy konsolidacji projektu, bitmapa dragon.bmp zostaje połączona z plikiem wykonywalnym *.mpn. BITMAP_DRAGON to nazwa przez którą będziemy odwoływać się do tej bitmapy. Dyrektywa PACKED sprawia że dana bitmapa jest wcześniej kompresowana, aby nie zajmowała zbyt dużo miejsca. Dyrektywa SPRITE mówi o tym że jest to sprite, a nie np. czcionka (jeżeli chcielibyśmy żeby to była np. czcionka to należałoby wpisać FONT). FORMAT RGB332 ozna cza że dragaon.bmp jest obrazem 256 kolorowym. W katalogu mophun\bin znajduje się program morc.exe. To on jest odpowiedzialny za interpretacje res.morc. Tworzy on plik obiektowy res.o, w którym zawarte są wszystkie zasoby. Później musi on zostać połączony z pozostałymi plikami projektu (to wszystko robi już za nas 'makefile'). Oprócz tego tworzy się plik nagłówkowy res.h, w którym zadeklarowane są wszystkie zasoby, oraz ich cechy (nazwa, rozmiar, format, etc.). Jeśli gdzieś w programie chcemy użyć któregoś z zasobów musimy przede wszystkim zinkludować plik res.h.

Przejdźmy teraz do stworzenia klasy smoka. W tym celu dodajmy do projektu dwa nowe pliki: CDragon.h i CDragon.cpp . W CDragon.h będzie znajdować się definicja klasy CDragon, natomiast w CDragon.cpp będą definicje funkcji składowych tej klasy. Na początku pliku nagłówkowego trzeba zinkludować 3 pliki vmgp.h - podstawowe funkcje mophuna; vstream.h - operacje na strumieniach; res.h - zawiera deklaracje bitmapy smoka. Następnie stworzymy klasę CDragon:

// klasa smoka class CDragon { private: char* m_pBitmap; // klatki animacji char* m_pTempBuffer; // bufor pomocniczy int m_iPosX; // pozycja x int m_iPosY; // pozycja y int m_iSize; // rozmiar klatki animacji w bajtach int m_iWidth; // szerokosc smoka int m_iHeight; // wysokosc smoka int m_iFrameMax; // liczba klatek animacji int m_iCurrentFrame; // bierzaca klatka animacji int m_iStep; // krok public: void draw(); // wyswietlenie void move(); // przesuniecie CDragon(int _x, int _y, int _step); // konstruktor ~CDragon(); // destruktor };

Kod chyba nie wymaga wyjaśnień. Wszystkie ewentualne niejasności wyjaśniają komentarze.

Teraz zajmijmy się konstruowaniem funkcji składowych. W pliku CDragon.cpp, na początku, przyłączymy plik nagłówkowy (CDragon.h), a pod spodem napiszmy:

// globalna zmienna z informacjami o wyswietlaczu extern VIDEOCAPS g_VideoCaps;

Jest to zadeklarowanie używania w tym pliku globalnej zmiennej g_VideoCaps. Zmienną tę utworzymy dopiero w pliku main.cpp. Będzie ona zawierać podstawowe informacje o wyświetlaczu telefonu (np. rozdzielczość, głębia kolorów).

Ok. zacznijmy pisać konstruktor. Tak więc napiszemy:

CDragon::CDragon(int _x, int _y, int _step) : m_iPosX(_x), m_iPosY(_y), m_iStep(_step), m_iCurrentFrame(0), m_iFrameMax(5), m_iWidth(30), m_iHeight(25) { m_iSize=m_iWidth*m_iHeight; // stworzenie bloku pamieci na klatki animacji // m_iSize to rozmiar pojedynczej klatki animacji, 5 to ilosc klatek animacji, // a 10 to miejsce na naglowek bitmapy m_pBitmap = new char [m_iSize * 5 +10];

Wyjaśnienia wymaga chyba linijka, gdzie tworzymy blok pamięci dla m_pBitmap. m_iSize to rozmiar pojedynczej klatki animacji, a ponieważ wszystkich klatek jest pięć więc mnożymy to razy 5. 10 to rozmiar nagłówka, który musi posiadać każdy sprite w programie. W tym nagłówku znajduje się m.in. rozmiar bitmapy, format, itp. Taki sam nagłówek będzie też miał blok m_pTempBuffer.

// odpakowanie skompresowanej bitmapy i zaladowanie jej do 'm_pBitmap' int handle=0; handle = vResOpen(NULL, BITMAP_DRAGON); vDecompress(NULL, (uint8_t*)m_pBitmap, handle, 1024); vStreamClose(handle);

Jednym słowem to jest odpakowanie bitmapy z zasobów i przekopiowanie jej do m_pBitmap. Nagłówek tworzy się automatycznie na począ tku bloku.

// tworzymy pomocniczy bufor na bierzaca klatke animacji m_pTempBuffer = new char [m_iSize+10]; // ustawiamy naglowek pomocniczego bufora SPRITE* s = (SPRITE*) m_pTempBuffer; s->palindex = 0; s->format = VCAPS_RGB332; s->centerx = 0; s->centery = 0; s->width = m_iWidth; s->height = m_iHeight; } // koniec konstruktora

Teraz został stworzony drugi blok m_pTempBuffer o rozmiarze jednej klatki + nagowek. Tym razem trzeba samemu zdefiniować nagłówek. Robimy to za pomocą rzutowania m_pTempBuffer na strukturę SPRITE, która jest zdefiniowana w bibliotekach mophuna.

Typ SPRITE to podstawowa struktura bitmapy w mophunie. Pierwsze 10 bajtów to nagłówek zawierający dane o rozmiarach bitmapy, formacie koloru. Pola centerx i centery to środek bitmapy. Używa ich funkcja wyświetlająca obraz na ekranie. Pole palindex jest używane wtedy gdy mamy do czynienia z obrazem indeksowanym (a paletą kolorów). Nasza bitmapa dragon.bmp, chociaż jest 256 kolorowa, jest automatycznie zamieniana z indeksowanej na RGB332 (czerwony - 3 bity; zielony - 3 bity; niebieski - 2 bity). Bezpośrednio po nagłówku znajduje się już blok obrazu. Zauważ że nasza zmienna m_pTempBuffer jest właśnie takim strite'em.

Destruktor klasy jest bardzo prosty, bo zajmuje się tylko usuwaniem bloków pamięci powstałych w konstruktorze. Oto jego kod:

CDragon::~CDragon() // destruktor { delete m_pTempBuffer; delete m_pBitmap; }

Teraz zajmijmy się funkcją wyświetlającą naszego smoka na ekranie: funkcją draw()

void CDragon::draw() { // kopiujemy aktualna klatke animacji do bufora 'm_pTempBuffer' memcpy((void*)(m_pTempBuffer+10), (void*) (m_pBitmap+m_iSize*m_iCurrentFrame+10), m_iSize);

Na początku musimy określić jaką klatkę animacji będziemy wyświetlać. Robimy to za pomocą funkcji memcpy. Do m_pTempBuffer (po nagłówku, stąd +10) kopiujemy zawartość bieżącej klatki animacji. Obliczmy ją wg wzoru: (adres bitmapy z klatkami)+(rozmiar klatki)*(nr bieżącej klatki)+(rozmiar nagłówka).

// wyswietlenie na ekranie vDrawObject(m_iPosX, m_iPosY, (void*) m_pTempBuffer); // zwiekszenie klatki animacji if((++m_iCurrentFrame)>=m_iFrameMax) m_iCurrentFrame = 0; } // koniec draw()

Funkcja vDrawObject jest zdefiniowana w bibliotekach mophuna i zajmuje się wyświetlaniem sprite'a na ekranie. Pierwsze dwa parametry to pozycja na ekranie, a ostatni to adres bitmapy (z nagłówkiem).

Po wyświetleniu smoka zwiększamy licznik klatki animacji.

Funkcja move(), zajmuje się przesuwaniem smoka na ekranie. Jest on bardzo prosta. Kod znajduje się poniżej:

void CDragon::move() { m_iPosX += m_iStep; if(m_iPosX > g_VideoCaps.width) m_iPosX = -m_iWidth; }

Na tym skończyliśmy omawiać kod smoka. Musimy jeszcze plik ten wpisać do makefie'a żeby kompilował się z resztą projektu. Wpisz do obu makefile'ów nazwę tego pliku z rozszerzeniem .o (czyli CDragon.o) przed main.o :

OBJS =	\
		res.o		\
		cpp.o		\
		CDragon.o	\
		main.o			

Przejdźmy teraz do głównego programu, do pliku main.cpp. Na początku oczywiście załączamy pliki nagłówkowe:

#include <vmgp.h> #include <vmgputil.h> #include "CDragon.h"

Stwórzmy globalną zmienną g_VideoCaps:

// informacje o wyswietlaczu VIDEOCAPS g_VideoCaps;

Ok. teraz możemy już napisać funkcje main():

int main() { // pobieramy informacje o wyswietlaczu komorki g_VideoCaps.size = sizeof(VIDEOCAPS); vGetCaps(CAPS_VIDEO, &g_VideoCaps); // inicjalizujemy wyswietlanie vSetDisplayWindow(g_VideoCaps.width, g_VideoCaps.height); vSetClipWindow(0, 0, g_VideoCaps.width, g_VideoCaps.height); // przy wyswietlaniu bitmapy kolor czarny jest pomijany (kolor przezroczysty) vSetTransferMode(MODE_TRANS);

Pierwsze 2 linijki kodu to pobranie informacji o wyświetlaczu komórki na którym uruchomiony jest program. Zmienna g_VideoCaps zawiera teraz właściwości ekranu takie jak: rozdzielczość, głębia kolorów, orientacji wyświetlacza, a także to czy możliwe jest uruchomienie aplikacji 3D.

Kolejne 2 linijki to inicjalizacja grafiki.

Kolejna funkcja (vSetTransferMode) ustawia tryb wyświetlania bitmap. MODE_TRANS oznacza, że kiedy obraz zawiera czarne piksele to nie są one kopiowane na ekran. To znaczy np. tło w naszej klatce smoka nie jest wyświetlane. Jest to bardzo pomocne właśnie do takich celów. Kolor czarny jest jakby przeźroczysty.

CDragon dragon(10, 10, 3); // stworzenie obiektu smoka while(vGetButtonData() != KEY_SELECT) // dopoki ktos nie wcisnie 'Select (No)' { // przesuniecie smoka dragon.move(); // czyscimy ekran na czarno vClearScreen(vRGB(0,0,0)); // wyswietlenie smoka dragon.draw(); // przelaczenie tylnego bufora vFlipScreen(1); msSleep(100); // opoznienie petli } vClearScreen(VMGP_BLACK); vFlipScreen(1); return 0; }

Teraz tworzymy naszego smoka o pozycji x=10, y=10 i kroku=3.

W następnej linijce zaczyna się główna pętla gry. Warunkiem skończenia pętli jest wciśniecie przycisku KEY_SELECT (na Sony Ericssonach to przycisk 'NO'). Funkcja vGetButtonData pozwala nam sprawdzić jaki jest wciskany aktualnie przycisk na telefonie.

W pętli kolejno przesuwamy smoka na ekranie, czyścimy ekran jednym kolorem. Kolor jest zdefiniowany za pomocą makra vRGB(), pobiera ono 3 parametry - składowe koloru R, G i B. Parametry muszą być w zakresie 0..255. Możesz sam pozmieniać wartości tych składowych i zobaczyć jak zmienia się kolor tła.

Po czyszczeniu ekranu wyświetlamy naszego smoka i funkcją vFlipScreen() przełączamy tylni bufor. msSleep(100) to opóźnienie pętli o 100ms.

Po wyjściu z pętli czyścimy ekran na czarno i wychodzimy z programu.

Na tym zakończę omawianie tego programu. Pełny projekt możesz ściągnąć stąd. Zawarłem tam też plik complie.bat dla tych którzy nie mają Visual C++. Wystarczy go tylko uruchomić, plik wykonywalny sam się stworzy.

Debugowanie

Zestaw SDK zawiera w sobie debugger, który możemy używać do wyszukiwania błędów w programie. Jest on raczej średniej jakości. Często zdarza mi się że sam się wyłącza, zupełnie bez powodu, ale lepsze to niż nic. Pokaże teraz pokrótce jak uruchomić program na tym debuggerze.

Przede wszystkim musimy skompilować projekt do trybu debug. W VC++6 wejdź do menu Build/Set Active Configuration i zaznacz debug.

Utwórz plik wykonywalny (*.mpn) otwórz go za pomocą emulatora i w menu Run/Debug.

Pokaże ci się okienko. Wpisz wszytko tak jak na rysunku:

Wciśnij OK. powinien pojawić ci się debugger. Teraz wejdź w menu File/Target Settings. Ustaw tak jak na następnym rysunku:

Wciśnij OK. Teraz wybierz swój plik wykonywalny w File/Open. Od tej pory możesz debugować swój program.

Uruchamianie na prawdziwym sprzęcie

Przy tworzeniu jakiejkolwiek gry nie obejdzie się bez uruchomienia jej na prawdziwym telefonie w celu choćby przetestowania aplikacji. Niestety instalowanie gry na telefonie nie jest takie proste. Firma Synergenix dołożyła wszelkich starań, aby zapobiec piractwu swoich gier. Żeby móc uruchomić swój program na swoim telefonie trzeba spełnić kilka warunków. Po pierwsze napisać maila pod adres [email protected] z numrem IMEI swojego telefonu i prośbą o informacje co dalej. Oni prześlą ci specjalne hasło. W następnym kroku musisz ściągnąć dwa programiki ze strony mophuna: mopher i mocert. Pierwszy z nich służy do kopiowania twojego programu na telefon za pomocą kabla. Zanim jednak będziesz mógł to zrobić należy użyć programu mocert.exe. Służy on do przerabiana programu tak żeby działał na twoim telefonie. Wszystko jest opisane w pomocy do tego programu. Jedynie co musisz wiedzieć to, to ze mocert łączy się ze specjalnym serwerem, wysyła na niego twoją grę, serwer do przerabia i mocert pobiera go z powrotem na twój komputer. Do tego było potrzebne hasło. Teraz już możesz spokojnie przekopiować grę na telefon. Jest to trochę uproszczony opis. Więcej informacji można znaleźć na stronie www.mophun.com.

Zarabianie na grach

Od razu chyba powinienem powiedzieć że mophun powstał po to, żeby programiści mogli w prosty i przyjemny sposób zarabiać pieniądze ze sprzedaży swoich gier. Nie można napisać gry i rozprowadzać ją za darmo. Mophun to w pełni komercyjne przedsięwzięcie. Wszystko szczegółowo jest opisane jak zwykle na stronie mophuna, oraz w pomocy dołączonej do SDK. Ogólna zasada jest prosta: - rejestrujesz się na stronie www.mophun.com - ściągasz i instalujesz SDK - robisz grę i wysyłasz ją pod adres [email protected] - jeżeli gra się spodoba i okaże się że może się sprzedać należy wykonać następny krok :) - ściągasz ze strony umowę (agreement), drukujesz, wypełniasz odpowiednie pola, podpisujesz, i wysyłasz faxem pod numer jaki co podadzą. - następnie wysyłasz grę do testów. Po testach gra otrzymuje certyfikat i automatycznie jest umieszczana na stronie mophuna w miejscu 'marketpalce'. Od tej pory operatorzy sieci komórkowych mogą sprzedawać tą grę w różnych krajach. Ty za każdy sprzedany egzemplarz dostajesz ok. 60% ceny. Wypłata przychodzi raz na 3 miesiące na twoje konto.

Tak to wygląda w skrócie.

Mam nadzieje że przybliżyłem Ci choć w części platformę Mophun. Nawet jeśli nie zamierzasz sprzedawać swoich komórkowych gierek to i tak polecam bliższe zapoznanie się z tą platformą.

>>projekt używany w tym artykule: mophun_src

Adam 'exor' Gajewski
[[Kategoria:C++]]

Tekst dodał:
Adam Sawicki
28.03.2006 15:09

Ostatnia edycja:
Adam Sawicki
28.03.2006 15:09

Kategorie:

Aby edytować tekst, musisz się zalogować.

# Edytuj Porównaj Czas Autor Rozmiar
#1 edytuj 28.03.2006 15:09 Adam Sawicki 25.02 KB
Zwykły
Do sprawdzenia
Do akceptacji
  • ~pika 30 września 2007 17:28
    to mówisz, że mieli za dużo tego typu zgłoszeń i nie warto się pchać, bo i tak się nic nie zarobi?
  • ~Ron 31 października 2008 20:24
    Dlaczego zysk wynosi OKOŁO 60%? W takim razie mogą być wachania z ilością pieniędzy, którą dostane za swoje dzieło. Wolałbym mieć pewne 60%, a nie "odświętnie" tyle dostać.
  • ~Gregyyy 13 grudnia 2008 15:59
    Jak ściągnąć to SDK z tej stronki pomóżcie pliss
  • ~Ctrl 04 marca 2009 17:41
    Po przeczytaniu "Uruchamianie na prawdziwym sprzęcie" dostałem prawie zawału serca... Napewno wszystkie gry które napiszę pod mophuna będą bardzo popularne...
  • Mariusz Włodarczyk (@MDW) 02 września 2009 09:56
    Mophun już nie istnieje więc tekst ma wartość historyczną. Firma Synergenix zaczęła stawiać coraz bardziej na handel aplikacjami a coraz mniej na rozwój Mophuna (3D). Im więcej było marketingowców i mniej developerów tym gorzej sie aplikacje sprzedawały i coraz mniej było partnerów. W międzyczasie SonyEricsson przestał fabrycznie instalować Mophuna w swoich telefonach. Synergenix prawie zbankrutowało i wykupił ją Kajak Inteactive tworząc Blaze. Potem odeszli z niej wszyscy twórcy (developerzy) Mophuna i zostali sami marketingowcy przez co Mophun3D przestał się rozwijać. Twócy założyli firmę Polarbit i stworzyli Fuse3D (wielokrotnie przewyższający Mophuna). Tymczasem Blaze podejmując kolejne nietrafione kroki nadal się staczało aż stanęło na krawędzi bankructwa. Przed zupełnym bankructwem uchroniło ją kolejne sprzedanie się. Tym razem firma została wykupiona przez Oberon Media i tak sprawa wygląda do dzisiaj (wrzesień 2009). Jednak Mophun jako taki już nie jest rozwijany, programy pod niego nie powstają. Świetnie niegdyś zorganizowane kanały dystrybucyjne i świetny framework padły. A przy odrobinie dalekowzrocznego myślenia mogło to być prawie tym czym dzisiaj jest AppStore...
  • Napisz komentarz:
    Aby dodać swój komentarz, musisz się zalogować.
Licencja Creative Commons

Warsztat używa plików cookies. | Copyright © 2006-2017 Warsztat · Kontakt · Regulamin i polityka prywatności
build #ff080b4740 (Tue Mar 25 11:39:28 CET 2014)