此文為翻譯 作為自己的學習資料,可能有些地方翻譯得不太準確,大家就抱著看看的態度就可以了。如果能學習東西當然是更好
原文地址:http://www.rbgrn.net/content/54-getting-started-android-game-development
如果你喜歡android平台遊戲開發,那你需要知道很多基礎東西。我是Light Racer,Light Racer 3D,Antigen,Deadly Chambers and Wixel的開發人員,如今這些遊戲都放置在android market上。在我開發遊戲之前,我的第一個android 應用程式是原始的Light Racer 。我也學到很多關於寫android遊戲的經驗,因此很願意分享給大家。我甚至寫了一本關於Light Racer 3D詳細開發的線上書籍——《development of Light Racer 3D》。裡面介紹了大量的基礎知識和關鍵的程式碼片段。如果你之前已經有遊戲開發的經驗,那麼跳轉到移動開發平台將不會太難。只需要學習android的架構和api就可以了。如果你是剛剛學習遊戲開發,那我這裡提供一個必須知道的列表讓你入門。它包括各種遊戲的類型,如行動、策略、類比和解題。
Android的環境是以java為基礎。因為java是比c++更容易上手的開發語言,也是移動開發的規範,再加上目前我也在用,所以這對新手將是一個很好的開頭。Google在這方面也做了很多工作,比如提供文檔形式的api和大量的例子。這些例子幾乎100%的使用api的函數,因此也被叫做API Demos。如果你對java有一定的熟悉和已經在使用Eclipse了,那麼開始第一個例子就會相當的容易。如果以前你從未學過任何的代碼,那它將會隨著你的前進不斷吸引著你,不過不能氣餒。如果你有過一些用c++開發的經驗以及想用c++開發跨平台或者高品質的android遊戲 ,那就看看BatteryTech,目前我正使用它來開發遊戲。
Get the SDK
第一步啟動android平台擷取SDK,這SDK裡包括核心的元件庫,模擬器,工具和例子代碼。推薦使用eclipse和android外掛程式。如果你只是做android開發,那Eclipse IDE for Java Developers是個不錯的選擇。如果這是你第一個java開發的項目,你就要下載java SE JDK。
Learn the application architecture
首先理解android 應用程式框架是很重要。如果你不學習它,你後面學習解決遊戲問題時將會困難重重。你應該去理解 Applications, Activities, Intents 和它們之間是如何聯絡的。Google已經提供了大量好的資訊在這架構裡。更重要的事情是理解為什麼遊戲需要多個activity組成和怎麼樣設計遊戲才有好的使用者體驗。所有的都關聯著activity的生命週期。
Learn the activity lifecycle
Activity 的生命週期由android系統管理。系統控制建立,恢複,暫停和銷毀Activity的狀態。想擁有好的操作的應用程式,那正確處理這些事件是非常重要。在設計遊戲之前理解這些的工作原理可以省去你調試時間和設計耗費的時間。對於大多數應用,android預設的設定就可以滿足大多數應用,但是對於遊戲你或許需要去考慮設定單例標誌。因為當設定的是預設時,android在適合的時候每次都會建立一個新的activity執行個體。對於遊戲,你或許只需要一個activity執行個體。這就意味著你需要去管理這些事物的狀態,但是對於我則需考慮解決一些資源管理的問題。
The main loop
無論你正在寫什麼類型的遊戲,你或許有或許沒有主迴圈。如果你的遊戲不是依賴於時間或者只是單純的回應使用者的動作,除了等待使用者輸入,就不會其他視覺的變化,你可能不需要主迴圈。但是如果你正在寫的遊戲包括動畫,時間或者其他自動化等等,你應該正視地考慮使用主線程。
The main loop of a game is the part that "ticks" sub systems in a specific order and usually as many times per second as possible.
主迴圈需要在自己的線程裡跑動,因為所有更新UI介面的線程都必須在android主 UI線程裡更新UI介面,更新介面執行的順序通常如下:State, Input, AI, Physics, Animation, Sound and Video.
情景的更新意味著要去管理情景的過渡,譬如遊戲結束,人物選擇或者下一情景。通常在一個情景你會去等待幾秒鐘,情景管理將會處理這些延遲和當時間到期時就設定下一情景.
輸入是通過使用者操作鍵盤,滾動和碰觸的來觸發,在處理物理性質之前必須處理這輸入,因為通常輸入會影響到物理性質,因此首先處理輸入將給遊戲帶來更有效響應。在android中,主線程發生輸入事件,因此你必須用代碼來緩衝你的輸入事件,這樣主迴圈才有時間去執行。這不是困難的任務。定義欄位,然後通過onKeyPressed 或者onTouchEvent 事件來儲存下一個使用者的輸入。當這個輸入是有效輸入時,將改變遊戲的情景以及讓物理性質處理響應它,來更新輸入。
AI的更新近似使用者決定他們去“按”下一步。學習如何取寫AI已經超出這文章的範圍了,不過一般的想法是AI會像使用者做的那樣按按鈕。這也會引起和響應物理性質的更新。
物理性質的更新或許是或許不是真的物理。比如行動類的遊戲,考慮上次時間的更新是關鍵點,目前時間會更新使用者的輸入,AI的輸入已經決定所有事物是否發生碰撞。對於一個遊戲,你在視覺上抓住一個物件並滑動它們,它將會是滑動的一部分,或者讓它掉入其他地方。對於一個益智問答遊戲,它將是答案正確與否的一部分。你還可以說出你別的什麼東西,對於這篇文章所有的遊戲都是這個遊戲引擎的一部分。我把它指做物理性質。
動畫並不是放入一個gif動畫那麼簡單。你需要在遊戲的正確時間內描繪每一幀。這不像聲音處理那樣難,儲存這些情景的欄位比如:isDancing, danceFrame and lastDanceFrameTime 來使動畫根據時間決定一下幀來更新。這是所有動畫都這樣做的。實際上顯示動畫的變化都是由視頻來更新。
聲音的通過處理觸發聲音,停止聲音,改變音量和改變聲音的聲調來更新。平常當寫遊戲時,聲音的更新實際是通過產生一個bytes流來發送到聲音的緩衝區,它是由android管理。因此你們可以選擇SoundPool 或者MediaPlayer來使用到遊戲裡。They are both a little sensitive but know that because of some low level implementation details, small, low bitrate OGGs will yield the best performance results and the best stability.
視頻的更新要考慮到遊戲的情景,人物的位置,分數,狀態,行為和螢幕的繪畫。如果使用主迴圈,你將要用到SurfaceView來繪畫。與其他views對比,view本身會回調繪畫的操作以及主迴圈將不得不做。SurfaceView擁有最高的幀每秒的速度以及在螢幕上最合適給遊戲做動畫或者移動組件的功能。All the video update should do is take the state of the game and draw it for this instance in time. Any other automation is better handled by a different update task.
代碼是怎麼樣的呢,這裡有個例子:
public void run() {
while (isRunning) {
while (isPaused && isRunning) {
sleep(100);
}
update();
}
}
private void update() {
updateState();
updateInput();
updateAI();
updatePhysics();
updateAnimations();
updateSound();
updateVideo();
}
3D or 2D?
在開始你的遊戲之前,你需要決定你打算往3D還是2D走。2D遊戲有比較低的學習曲線通常更容易得到良好的效能。3D遊戲需要更多深入的數學技能並且如果你不小心有可能出現效能的問題。他們還要求有使用建模工具的能力,像3D Studio和Maya。如果你打算要有形狀複雜的箱子和圓圈。那使用OpenGL,Android支援OpenGL的3D編程以及在OpenGL裡一定能找到很多好的教程去學習。
Build simple, high quality methods
在開始時一定要確定自己要避免在不要將方法寫得太長。如果你遵照主迴圈模式,我上面所述,這是相當容易的。每個方法只能完成一個功能並保證沒錯誤。比如:如果你需要洗桌子上的卡,你應該寫個方法叫"shuffleCards",就只做洗卡的功能。
練習代碼在遊戲開發中是一個很重要的部分。調試在有狀態性,真實的系統裡是非常困難的。盡量保持自己方法只有一個任務,不要一個方法裡完成多個任務。如果你打算編寫一個畫情境背景的方法,可以叫"drawBackground"。這會讓自己以後在複雜的系統裡很快速的理解。
It's all about efficiency!
Performance is a major issue for any game. The goal is to make the game as responsive as possible and to also look as smooth as possible. Certain methods like Canvas.drawLine are going to be slow. Also drawing an entire screen-sized bitmap onto the main canvas every frame will also be costly. Balancing things like that is necessary to achieve the best performance. Make sure to manage your resources well and use tricks to use the least amount of CPU to achieve your task. Even the best game will not be very fun if it can't perform well. People in general have little tolerance for choppiness or poor response.
Tips and Tricks
Take a look at the example for LunarLander in the SDK. It uses a SurfaceView and that would be the appropriate view to use for a game that needs the highest number of frames per second possible. If you're going 3D, take a look at GLSurfaceView. It takes care of the OpenGL device initialization and provides a mechanism for rendering. For LightRacer, I had to optimize the way I have everything drawn or else the framerate would be drastically lower. I drew the background to a Bitmap only once which was when the view is initialized. The light trails are in their own bitmap which gets updated as the racers move. Those two bitmaps are drawn to the main canvas every frame with the racers drawn on top and then finally an explosion. This technique made the game run at a playable rate.
It's also a good practice to have your bitmaps be the exact size you intend to draw them on screen, if applicable. This makes it so that no scaling is needed and will save some CPU.
Use a consistent Bitmap Configuration (like RGBA8888) throughout the game. This will save the graphics library CPU in having to translate the different formats.
If you're determined to develop a 3D game but have no 3D knowledge, you will want to pick up a book or two on 3D game programming and study up on linear algebra. At a bare minimum, you must understand dot products, cross products, vectors, unit vectors, normals, matrixes and translation. The best book I have come across for this math is called Mathematics for 3D Game Programming and Computer Graphics.
Keep the sound small and at a low bitrate. The less there is to load, the faster loading times will be and the less memory the game will use.
Use OGGs for sound, PNGs for graphics.
Make sure to release all media players and null out all of your resources when the activity is destroyed. This will ensure that the garbage collector gets to everything and that you don't have any memory leaks between launches of the game.
Join the Android Google group and find community support. There will be people that can help you along the way.
Above all, spend time testing and retesting and making sure that every little thing works exactly the way you would expect it to. Polishing the game up is the longest and hardest part of development. If you rush it out to market, you will probably have a disappointed crowd and you may feel that all your hard work is wasted. It's not possible to have 100% of people love what you write but you should at least try to put out the highest quality work that you can.