整合營銷服務商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
者按：今天騰訊的同學從一款HTML5小游戲《植物大戰(zhàn)僵尸》說起，分享一些動畫實現(xiàn)的知識（動畫可控性、如何兼容不同分辨率、如何識別平板手機等），附上眾多實現(xiàn)小技巧，來收 >>>
hello~大家好，我是黑米！ Ｏ(≧▽≦)Ｏ
今天我來跟大家分享一些動畫實現(xiàn)的相關(guān)知識，希望大家能夠支持（鞠躬……
我很喜歡很喜歡看動畫片，一直有做出好看動畫片的夢想……所以最近做了不少動畫效果來玩兒，也為自己以后可以做出偉大的動畫片打好基礎！
Web端動畫表現(xiàn)有不少辦法，我列一些常見的，然后再說說在實現(xiàn)上的一些小技巧。
進入正題，我要開始認真了！（嚴肅臉…… (￣ー￣〃)
嗯……首先大家先來跟我一起玩?zhèn)€游戲，請快速的掏出手機，打開微信，“掃一掃”下面的二維碼，通關(guān)最多的前三名同學……什么獎品都沒有！！
相信大家都認真的玩兒了游戲吧？我們這里有一位萬技師一直玩到50多關(guān)，最后體力透支，主動“自殺”，否則相信他能玩出過百關(guān)，怎么做到的？有彩蛋，不知道你有沒有發(fā)現(xiàn)，哈哈……
嗯……回歸正題，這個小游戲當中用到了大量的動畫效果，主要是逐幀動畫，今天的第一部分，就先來講講動畫這個事情。
我先來列一排動畫效果給大家看……
圖1
圖2
圖3
剛才上面列的動畫效果分別是 GIF 動畫、Canvas + CSS 動畫、逐幀動畫。其實說起常見的動畫實現(xiàn)，除了 GIF（APNG）、Flash 和 Canvas 外，其他基本都是 CSS 動畫，即使是通過 JS 實現(xiàn)，大部分情況下只是通過 JS 來修改 CSS 屬性而已。
而 GIF 動畫僅支持 8 位色，顏色偏少，雖然 APNG 解決了這個問題，但是存在兼容問題，同時它和 GIF 一樣，沒有可控性，所以它們一般很少用于動畫制作流程中，僅用來展示。相對來說 CSS 動畫和 Canvas 動畫的可控性更易于制作頁面效果動畫以及頁面游戲。
一、可控性
剛才說了“可控性”，那到底什么是可控性？我們先來看一個動畫效果的大概示意圖！
一段動畫一般由“開始 – 過渡 – 結(jié)束”來組成，GIF 動畫是無法通過代碼來獲取到這些狀態(tài)的，但 CSS 動畫可以！
我這里的做法是把每一組圖片合成一張“雪碧圖”，然后利用 CSS 的 animation 做逐幀動畫，寫好函數(shù)通過不同的參數(shù)來調(diào)用不同的角色。
Role（dirt）
Role（rises）
Role（cast）
Role（broken）
Role（death）
合成“雪碧圖”的逐幀動畫
像上面 圖2 和 圖3 的例子，都是由好幾個動畫銜接完成，那么它們之間如何銜接呢？有的同學可能會說用setTimeout/setInterval/requestAnimationFrame 一類的延遲功能來做銜接，但是這樣會有個問題就是在性能不同的機器上，會有誤差，而且維護繁瑣。所以，我們需要一個觸發(fā)形式的銜接方式，即上一個動畫完成了，通知下一個動畫開始。
CSS 動畫實現(xiàn)一般使用 animation 和 transition 來搭配其他屬性使元素產(chǎn)生不同變化，從而達到動畫效果。
而這兩個屬性是可以通過 JS 中的事件來監(jiān)聽到“開始”和“結(jié)束”狀態(tài)。具體事件如下：
animationstart：
animationstart 事件在 CSS animation 開始時被觸發(fā)。如果有 animation-delay ，事件將在延遲時效過期之后立即觸發(fā)。 如果延遲時效是負值，事件觸發(fā)時將帶有等于延遲時效絕對值的 elapsedTime 。
animationend：
animationstart 事件在 CSS animation 完成時被觸發(fā)。
transionstart：
transionstart 事件在 CSS transition 過渡開始時被觸發(fā)。
transitionend：
transitionend 事件會在 CSS transition 結(jié)束后觸發(fā)。當 transition 完成前移除 transition 時，比如移除 CSS 的 transition-property 屬性，事件將不會被觸發(fā)。
這些事件在不同瀏覽器下需要加前綴什么的大家應該都懂得，至于 transionstart，目前僅在 IE10+ 上有效……
通過事件監(jiān)聽的方式銜接，并利用分層的形式疊加多重動畫，最終實現(xiàn)效果：
現(xiàn)在，開始狀態(tài)和結(jié)束狀態(tài)獲取到了，那中間的過渡狀態(tài)要怎么辦呢？比如說我要動畫執(zhí)行到 30% 的時候，執(zhí)行一個回調(diào)，親一口姐姐，腫么辦？?(?ε??)
雖然沒有直接的事件可以監(jiān)聽到過渡狀態(tài)，而且這個需求中也暫時用不到這個過渡狀態(tài)監(jiān)聽，但是我們也可以稍微做點事情的。（不拋棄，不放棄！）
怎么做呢？比如一個動畫的執(zhí)行時間是10s，那么在動畫開始的時候，跑一個 setInterval 來不斷的記錄過渡狀態(tài)，然后用當前跑到的值和總時長就能算出具體的進度了。這里要稍微注意一下，因為動畫播放控制（animation-play-state）屬性的存在，在暫停和重新播放時，需要對計時器稍微進行一下處理，否則得出的進度值會有錯誤。
這不是一個很完美的辦法，因為在不同的性能下，計時器的值可能會有微弱誤差，但如果你要求并不是很精確，還是可以嘗試這個辦法的。
二、如何 Perfect 的兼容各分辨率？
兼容各式屏幕一般有這樣的辦法：
還有這樣的辦法：
最后，還有傳說中的彈性自適應布局：∑(O_O；)
但是，在這個需求上，統(tǒng)統(tǒng)不適用！為什么？
viewport 和 media Query 在 iOS 和 Android 上識別的單位不同，在 iOS 上識別的是“設備像素”，而在 Android 上識別的是“CSS像素”，這兩個詞后面會講到。
因為這個頁面游戲上有大量的元素用到絕對定位，如果使用彈性自適應布局的話，會進行大量的布局計算，而且還不一定精準。
所以，這里的解決辦法是通過 discrimina.appVersion 獲取 UA 信息中的關(guān)鍵字來判斷不同的系統(tǒng)，針對不同的系統(tǒng)做不同的解決方案，Android 對最外層 div 進行 zoom 縮放，而 iOS 使用 viewport 縮放：
三、如何 Perfect 的識別平板和手機？
各設備上的布局問題解決了，但是如果設備屏幕比較大，你的圖片是糊的，怎么辦？
也許有的同學會舉手說去檢測 CSS 分辨率，但是這里就有問題了……有的老舊平板可能屏幕尺寸大，但 CSS 分辨率小；而有的新手機屏幕尺寸不如平板，但是 CSS 分辨率挺高，咋辦？
回歸現(xiàn)實，我們分辨平板和手機是以什么來分辨的？屏幕尺寸，對吧？那么我們這里也同樣，只要想辦法計算出訪問者的屏幕尺寸即可，就是平常我們說的幾寸屏…幾寸屏的那個尺寸。
怎么獲取那個尺寸呢？我們這里先來學習一些專業(yè)術(shù)語……
標紅的“屏幕尺寸”是我們的目標，綠色的元素是我們后續(xù)會用到的東西，其中我們可以直接通過 JS 獲取到的只有最后兩項，即“設備像素”和“設備像素比”。
然后我們來看看“屏幕尺寸”的計算公示：
屏幕尺寸 = 屏幕對角線的CSS像素值/（設備像素比*PPI） = (√長2+寬2)/（設備像素比*PPI）
屏幕是矩形，矩形對角線的計算公示就是上方右側(cè)那個公示；現(xiàn)在我們來看一下這個公示中用到的元素如何獲得……
現(xiàn)在，萬事俱備，就差 PPI，這東西雖然沒有直接獲取方式，但是我查了一下資料，還是得到了一些數(shù)據(jù)。
注意，這里給的是基準值，我們常說的 iPhone 多少多少 PPI，那個值是用基準值乘以設備像素比得出來的。由于 Android 手機廠商眾多，并沒有統(tǒng)一的標準，這里的 160 只是約等值，所以 Android 屏幕尺寸結(jié)果會有誤差，但是基本也夠用了。
現(xiàn)在公式中的所有要素都已經(jīng)齊備了，具體在代碼中實現(xiàn)，就是下面這樣子：
得出的值，單位是“英寸”，我們根據(jù)這個值就可以考慮針對平板和手機等不同屏幕尺寸做不同的事情了，比如最基本的，換一套高清圖……
四、音頻之殤 (T^T)
這個小游戲中一共用到3類音頻，共6個音頻，且存在同時播放問題，iOS 下沒問題，但是 Android 下會出現(xiàn)后播放的音頻打斷之前播放音頻的問題。
我測試了一些設備，發(fā)現(xiàn)無跡可尋，有的老設備支持，新設備反而不支持。我的解決辦法是 Android 用戶僅播放關(guān)鍵音頻，比如這個游戲當中就是背景音樂，其他的就不放了。因為沒辦法判斷設備到底是否支持多音頻同時播放……
五、形變+位移+旋轉(zhuǎn)=？
剛才講了“活捉兵馬俑”那個游戲的一些經(jīng)驗技巧，現(xiàn)在講講幾個 CSS 小屬性搭配起來可以做的東西。
不可否認，做動畫 Flash 是走在前面的，它的很多表現(xiàn)形式都值得我們借鑒，比如說這位豌豆射手。
這個豌豆的需求是一個雙屏互動需求，PC 端使用 Flash 實現(xiàn)，移動端沒辦法用 Flash，所以動態(tài)效果我就照著臨摹了下來。
具體做法是把豌豆拆成不同的小組件，然后再利用 animation、translate、scale、rotate，拼合出一個完整的動態(tài)效果，并沒有多少技術(shù)含量，但幾種屬性的搭配使用，讓這顆豌豆看起來還是挺贊的！
等于
所以，很多屬性稍微搭配一下，其實就可以做出很好玩的東西。哈哈……
六、其他一些小細節(jié)……
看了這么久的文章，你可能也累了，下面一些小細節(jié)快速過一下……
1）不要放棄 PC 訪問的用戶，如果沒有很好的引導，他們會直接關(guān)閉網(wǎng)頁的。
2）如果是橫屏沒法用的頁面，給予良好的橫屏提示。
3）為用戶添加桌面圖標，方便用戶啟動頁面。
好的，今天的分享基本就這樣告一段落，欲知后事兒如何，請聽下回分解！
原文地址：tgideas
優(yōu)秀網(wǎng)頁設計公眾微信號：youshege碎片時間學習利器！
onstruct 2是一款能夠幫助你制作HTML5電腦游戲的應用程序，它將為你帶來一個清晰直觀、支持“拖拽”操作的開發(fā)環(huán)境。程序中的大部分工具都可通過圖形界面來使用，完全無需寫下任何代碼，即使你沒有任何編程經(jīng)驗也能擁有自己的游戲哦。
Construct 2
Construct 2旨在創(chuàng)建2D游戲，內(nèi)置的各種資源讓游戲制作更加輕松：物理引擎使游戲中的物體支持地心引力，當然還有元件、背景、音效等各種游戲所需的圖形與聲音。另外，將媒體文件導入程序也很簡單。
Construct 2
Construct 2
簡單、直觀的視覺環(huán)境是Construct 2所信奉的哲理之一。當你拖拽元件至某個位置時，程序會使該元件與其他物體互動。例如：我的人物->撞墻->停止。很容易理解吧！
Construct 2
Construct 2
免費版允許你將作品導出至HTML5，在任何平臺的任何瀏覽器中運行，但這并不能幫你掙到一分錢。專業(yè)付費版則增加了一個導出工具，使用這個工具，你的游戲不僅能在安卓或iOS設備中運行，甚至，你還能創(chuàng)建一個可執(zhí)行文件，在電腦中運行游戲。
Construct 2
毫無疑問，對于任何想要制作游戲，卻不懂編程的用戶來說，Construct 2都是一款不可多得的工具。簡單好用的工具搭配大量素材，絕對是你創(chuàng)建游戲的好選擇。
/ Luiu
最近跟的一款項目是HTML5手游，在這個項目中遇到并解決了諸多問題，也學習到了很多項目開發(fā)過程中需要注意的事情。這個項目自立項到現(xiàn)在已經(jīng)過了5個多月，如今項目研發(fā)已經(jīng)過了早期的忙亂階段，于是借此機會梳理下思緒，為了能夠更好的完成以后的工作。如果能給想進入HTML5這個領(lǐng)域的新團隊一些參考，那也是一件極好的事情。
這款項目是我們團隊接到的第一款HTML5類型的游戲合約，在此前團隊一致在致力于傳統(tǒng)回合制手游研發(fā)。因此團隊可以說在這個領(lǐng)域幾乎是從零開始（當然一開始的時候我們不這么覺得），所以在研發(fā)進行到中期的時候遇到了很多影響效率的問題。
其中影響最大的問題之一就是——界面適配
HTML5手游這個品類說白了就是把頁游裝進一個殼里，本質(zhì)上他還是一個頁游，擁有很多頁游的特性。它是在頁游框架的基礎上，將UE對移動設備做了優(yōu)化。因此該類游戲在后期將會根據(jù)渠道需求發(fā)行多個版本，包括直接在網(wǎng)頁運行（電腦網(wǎng)頁和手機網(wǎng)頁）、在手機端運行、在平板電腦設備上運行。這樣就會帶來一個嚴重的問題——兼容性問題。由于HTML5跨平臺的特性，很容易產(chǎn)生兼容問題。最明顯的一個就是界面適配問題，最基本的要做到UI在不同長寬比的屏幕下均能完全展示，在這個基礎上再考慮對主流長寬比的屏幕進行特殊處理，優(yōu)化用戶體驗。
界面適配的方案一：約束比例縮放（主流方案）
方案描述：該是保持界面中元素的相對位置不變，在不同長寬比的屏幕中進行整體縮放。
這種方案會將界面分為上中下3個區(qū)域，將中間的主要區(qū)域視作一個窗口根據(jù)屏幕比例進行縮放。在縮放的過程中保證窗口長寬比不變，保持長或者寬任意一個維度占滿屏幕就可，不強求整體鋪滿屏幕。
方案優(yōu)勢：處理簡單，且最終效果還可以。可以保證UI在不同長寬比的屏幕下均能完全展示，并且UI布局不變。
最終效果如圖：
圖中黑色部分為空白區(qū)域，雖然對界面的美觀有一定影響，但是影響不大。如果把中間的區(qū)域設計為窗口的樣式，會使界面看起來更自然。
界面適配方案二：全屏鋪滿
方案描述：該方案同樣要將界面分為上中下3個區(qū)域，只是對中間那塊主要區(qū)域采用了不同的處理方式。這種方案會要求中間區(qū)域底板鋪滿屏幕，所有處于該底板上的元素坐標需要根據(jù)界面的長寬比進行計算，并且界面中的列表，底框等元素的大小也要根據(jù)屏幕的長寬比進行計算。
方案優(yōu)勢：該方案可以解決方案一種空白區(qū)域的問題，在移動設備上顯示更加美觀。
該方案的最終效果如圖：
這個方案實現(xiàn)較方案一來說更加復雜，并且最終效果不好把控。容易造成不同比例屏幕下UI出現(xiàn)重疊，超出邊界等問題。如果處理不好，最終效果反而不如方案一。
從目前市面上的HTML5游戲來看，基本采用方案一就可滿足當前用戶需求。采用方案二會增加項目研發(fā)時長，并且增加人力成本。
我們這個項目使用的是白鷺引擎，在該引擎的UI編輯器中有個約束坐標的功能。使用該功能，可以將元素的坐標相對屏幕四邊或者中心進行約束，確保縮放后界面布局隨之改變。建議界面中的元素更多的采用約束的形式，而不是絕對坐標。
白鷺引擎中的約束功能：
為什么建議使用約束的形式呢？這是因為約束的方案更有利于保證界面中元素的邊距，居中，四邊對齊等布局。這樣當用戶在兩個相似界面之間切換時，相同的元素位置也相同。不會出現(xiàn)切換時由于相同元素坐標的微小差異造成的晃動感。并且該方案更方便約定團隊成員在拼界面時的規(guī)范，只需要約定相同元素的邊距，元素互相之間的間距等。再者，如果采用界面適配方案一時使用約束功能的話，后期若要改為方案二，也會更加方便一些。
規(guī)定UI標準對于保證UI的最終效果十分重要。在項目開始之初，就需要設計好界面中的通用控件的樣式和規(guī)格，包括通用按鈕、列表、標簽等。并且不同功能標簽的字體大小、色值、樣式（加粗、描邊）等也要有統(tǒng)一的標準。除了以上這些控件的規(guī)格和樣式，還需要規(guī)定游戲中各種彈窗的樣式和規(guī)格，否則必然會出現(xiàn)彈框大小參差不齊，影響UI美觀。
UI就是游戲的臉面，是給用戶留下第一印象最直觀的內(nèi)容。因此UI中的各個細節(jié)必須保證統(tǒng)一美觀，這樣才能給用戶留下好印象。
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
