Skip to main content

Smooth movement --- JUMP ACTION


這個教學是上一篇 Smooth movement in FL1.1的加強版,並加入了跳躍動作。在FL1.1中是沒有所謂的hitTest(),所以這邊利用了一個方法來達到簡易的碰撞測試,讓火柴人可以跳到移動平台上:

取得跳躍平台的方塊四頂點的座標,與跳躍 MC作座標檢測


call hitTest: (mc = main control movieclip's name)
W =hitTestTarget._width/2;
xMin = hitTestTarget._x-W;
xMax = hitTestTarget._x+W;
H =hitTestTarget._height/2;
yMin =hitTestTarget._y-H;
yMax = hitTestTarget._y+H;
if (mc._x>xMin && mc._x < xMax) {
if (mc._y>yMin && mc._y < yMax) {
hitTarget =hitTestTarget;
trace(hitTarget add " be hit");
mc._y = yMin;
}
}


Key controler :
on (keyPress "") {
hitTarget = "";
if (!jump_co.jump) {
trace("跳躍開始");
jump_co.ymov = -21;
jump_co.jump = true;
jump_co.status = "jump";
tellTarget ("mc") {
gotoAndStop("jump");
}
}
}


Jump controler 跳躍控制器(jump_co):
if (jump) {
ymov += 3;
if (status eq "stand") {
//在hitTest中,如果確定碰撞到平台,status會設定為stand
jump = false;
tellTarget (__target) {
gotoAndStop("stand");
}
} else {
//drop
eval(__target)._y += ymov;
if (ymov>0) {
status = "drop";
call("/:hitTest");
}
}
}


[下載原始檔]

Comments

Popular posts from this blog

[Swift3] weak 與 unowned 關鍵字

雖然在 Swift 中看起來"很像"是不需要煩惱內存管理的問題,不過實際上它還是遵循著自動引用計數 (ARC) 的規則,當一個物件沒有被其他對象引用時會自動被銷毀,如果三魂七魄沒有完全回位的話,就會有個靈體留在現世的空間裡,最經典的範例如下: 閉包(Closure)引用 classClassA { typealias Complete = ()->() var name : String var onComplete : Complete? init(_ name: String){ self.name = name print("Hello I am \(self.name)") onComplete = { print("\(self.name): onComplete!") // --> 閉包引用 self, 計數 + 1 } } deinit { print("deinit: \(self.name)") } } var a : ClassA? = ClassA("A") // --> 引用計數 + 1 a = nil // 2-1 = 1 還剩下 1 所以沒辦法銷毀 ---output------- Hello I am A 由於這邊的 onComplete 宣告為 Optional, 正確的做法要連同 onComplete 一起刪除才可以被回收,若不是 Optional 則會進入無法回收狀態: var b : ClassA? = ClassA("B") b?.onComplete = nil // --> 還好是 Optional 可以設成 nil 計數 - 1 b = nil // 計數 = 0 所以被回收 ---output------- Hello I am B deinit: B 但是做人不需要煩惱太多,這時候就出動 unowned 關鍵字讓物件可以順利被回收: onComplete = { [unowned self] in print...

PureMVC 我也會 [6]

Mediator ViewComponents 與 pureMVC 架構的中介 監聽並反應 View Component 發出的 Event 可以發送與接收 Notification 儘量少操作 Proxy 公開方法,多用 sendNotification... Mediator design pattern 要多認識這個 Mediator 設計模式的話,請自行看連結說明啊! 簡單來講,假使有一個 View 裡面有好幾個 MovieClip 組成,而這些 MovieClip 會互相影響對方...這個情況在 Flash 中,通常都會變成下圖: MovieClip 直接控制其他 MovieClip 搞到整個關係很複雜...換一個元件簡直是災難。 加入 Mediator 後,示意圖就會變成: 這樣,所有的 MovieClip 都透過 Mediator 來跟其他 MovieClip 溝通,當某一個 MovieClip 替換成別的元件,這時候也只需要修改 Mediator 中的引用即可,是不是變得很乾淨?如果同一組 MovieClip 有另外一個操作模式,也只需要替換掉 Mediator 即可!天下太平啊~~~ 而 PureMVC 中就是利用 Mediator class 為與前端 ViewComponent 的中介,這樣可以切開 ViewComponent 與 PureMVC framework 的關係,不管你前端介面使用 Flash or Flex 製作都跟程式核心無關。 所以 ViewComponent 製作時只需要兩個原則,一把所有的請求都以 Event 送出由 Mediator 處理,二提供公開方法, Mediator 只需要監聽 View 的 Event,將收到的資訊透過公開方法喂進 ViewComponent 即可。 如在 ViewComponent 中: public function setList( result:Object ):void{ list.dataProvider = result as ArrayCollection; } //然後在按下取得資料的按鈕 Click action 寫上: dispatchEvent( new Event( "GET_LIST" )); 新建 Mediator 的時候一樣有幾個重點方...