#phaser3

[16naughts]

Dev Log Apr 25 - Spring Cleaning

New modes means new menus. And that means I get to talk about some programming and architectural stuff again. Quick recap - Crescent Roll is written in Javascript, pretty much 'from scratch' at this point. We used Phaser3 there for a bit, but then I recently tore that out to just do WebGL directly, so the only third-party piece is the wall collision through MatterJS. The 'engine' of the game is actually a series of specific libraries that we wrote for specific pieces, each with their own little codename and interactions. The root part of our system is something we call Plinth - it's a data contract declaration library that adds a little bit of spice to standard JSON and lets you do things like link to other files, copy and re-use declarations of objects, unpack arrays into vectors, specify equations for values, and, most importantly, blend overlapping data from multiple sources to support modding. It's extremely powerful and highly flexible, but also built to my personal preferences. So, you know - it probably doesn't make sense to anyone else. But it makes coding quite the breeze for me. The graphics system is known as Plaster. It's built around the idea of being able to toss one of the Plinth contracts for different objects, and then the display scene can be built from it. Here's a sample snippet from the Level Select on the Main Menu:

(I do want to note that these menu layouts will eventually be made public for editing via the modding kit, but not quite yet, so some of this is probably going to change). This whole thing is very similar to Godot's system, except instead of the nodes driving the program, the program pulls the nodes for data. You can't use Crescent Roll as a general-purpose game engine. So, I guess the closest analog is kind of like a more matured version of the Data Packs in Minecraft. This current system does have a bit of a weakness when it comes to dealing with User Interface stuff. (Which, looking at the most popular JS frameworks, I would say is also probably the biggest issue in the industry, period.) Making the button that moves when you mouse over it is no problem - it's whenever you click on it and now the text for showing the current clear times needs to switch for the next world that we start to hit issues. Our idea for handling the interactions was the concept of 'binding' to specific tags on the objects defined in the JSON, and then whenever those objects were defined or interacted with or an action was to be executed on a particular binding type, code would automatically run to handle whatever the binding was. However, our current implementation for that is a little, we'll say lopsided? I suppose. Bindings all have to be defined before the objects are loaded in to avoid having to re-search everything single sprite every time. Changing hierarchy at runtime would trigger a re-calculation of the binds, which was usually extra wasted work. The different types had to be pre-defined to a code type, so you couldn't decide to just inject an extra description text into one particular type of button with a special binding without doing it to all of them. I wouldn't call it an outright mess, but compared to the other systems, it's not quite up to par. After a bit of pondering, we've decided that the reason it wasn't so great was that it was trying to solve two problems at once. The first being, of course, triggering things to happen to other things in code. However, the second thing was injecting data from higher up into lower below (like setting icons and text when trying to re-use a button). Which that second issue, we realized that it was already accidentally solvable a different way - Plinth already had re-usable object prototyping. Why not just make those work for things other than objects? Plinth has several special fields that you can declare to do specific things. "*" lets you inject whole files as if they were inline, which is the basis for re-using multiple buttons and other controls in other spots. The At Symbol (don't want to accidentally tag somebody here) lets you define sub-objects, and you can inject those values by referring to the tag in a string value. So, we just made it so that you can just define strings and numbers for those, and then made them work cross-file, and presto:

The button would get the defined icon field from the one in the menu that refers to it. Previously, the iconImage would have required a "bind:icon" extra field in it, and then the buttonA in the menu would have a field "icon:ButtonAIcon.json" What about when the icon needs to change from code? Well, there's some transformation that happens when reading from the json into actual graphics objects, and the tags themselves are lost when they're resolved. Even if we did keep them, it would turn into the same kind of tracking done for the bindings to avoid needing to scan potentially hundreds of children on every click. So, in the spirit of KISS, we're currently experimenting with just having a generic "tags" field that is a string:string object that you just stick the name of the binding would have been to point to the object at the top-level menu, and so far it's kind of working surprisingly well. I anticipated needing to daisy-chain to things like button icons, but you never really need to ever touch a pre-existing button, and any created ones will just have direct access through their own tags anyway. The only real downside is that if you want to do both replacement in json and replacement in code, you need both annotations at the same time, but it actually hasn't come up once so far. But hey - adding the times to the level select button was a breeze. So I'll trade off that little bit of elegance for a lot more velocity.

[browndragon]

The Problem With Arcade Physics

TL;DR: I have a fix for arcade physics, but it's disruptive, so I'm not trying particularly hard to get it upstream. Let me know if I should! My asks (etc) are open!

If you want it, it's available @ [my github](https://github.com/browndragon/phaser/tree/solidArcade)

Phaser comes batteries-included with arcade physics, an AABB basic physics engine. So of course I'm building fidough, my ridiculous boxes on conveyor belt game with it. Which is insane. It's fine.

But I hit a problem: naive conveyorbelts didn't work:

Okay. So why does that happen?

The code was simple:

function overlap(sprite, tile) {

const {x, y} = this.offsets[tile.index];

console.assert(Number.isFinite(x) && Number.isFinite(y));

ticknudge(sprite, x, y);

}

function ticknudge(sprite, x, y, still=.01, nudge=.001) {

sprite.body.x += x;

sprite.body.y += y;

sprite.body.updateCenter();

}

So what gives? that looks right! It isn't.

_dx and _dy: why?

The old code had a simple flaw: it had multiple representations of the same data, and needed to remember them all. The core metaphor of arcade physics separation is to determine the motion of the two intersecting objects and to restore them roughly antiparallel to the direction of motion.

This is deadly: motion is underspecified. Antiparallel isn't hugely specified. Motion brings in the notion of time.

Obviously, the old code had `velocity` concept, it is a physics engine. Velocity is tricky. In a physics engine, it represents the continuously updated per-frame motion component, but it is obviously not the actual total amount of movement that was definitely executed. For instance: if the physics body has a lot of drag and perpendicular acceleration and lots of colliding objects, its actual displacement over the last tick (upcoming AND over the last frame!) isn't necessarily the velocity times time.

This is a problem for me. Remember, my whole schtick is walkways, which are effectively sticking an object in a constant velocity frame of reference relative to the camera, which for one reason and another isn't ideally represented with careful force-and-drag (or absolute max veloc), but instead a per-tick direct modification to colliding objects' velocity.

The first advice was to ensure that if I modified `position.x`, to modify `_dx`. That's definitely good advice; the way that Arcade Physics detects motion is through that _dx thing; if I modify position.x of a completely still object, it won't reflect in its actual motion, and so it won't reject from the walls. QED.

Okay, so let's grab a snap with the above code modifying _dx & _dy whenever we modify position.x and position.y. Spoiler, it still doesn't work!

This is the `embedded` logic biting us, deciding that two colliding objects without motion can't be repaired. At first, I thought that Phaser was wrong when it estimates how much an arcade body has moved, because it uses velocity ("per-tick added motion") instead of a continuously evaluated _dx & _dy ("per-tick observed displacement"); it does so much math already that I just deleted _dx and _dy in favor of subtracting previous position from current position. I also gave it enough intelligence to extrapolate a per-second displacement from the observed previous-tick displacement.

And do you know what? It still didn't work!

On passing data between ticks

The logic was simple. The physics algorithm is:

For each body: Start the frame: copy bounds and transform information from the game object back into the arcade body

For each body: Start the tick: calculate next position from velocity, drag, acceleration, etc

For each collider: Execute it! (and by coincidence, I'm doing object intersection first and walls nearly last)

Goto 2 if there's more time left in this frame

For each body: End the frame: Push position information back to the game object.

So what's missing? The only logical time to snapshot prev (and calculate dx) is on step 2. But my treadmills execute in step 3! So their motion is *always* forgotten by this algorithm, since the snapshot captures the value they'd written; any objects that are stranded within walls seem always to have been there, since the current and previous position are equal as an accident of this algorithm.

The Fix

We truly don't need dx as a body property; it's just the difference of current and previous position, so we can throw that out. But we need to capture previous position in such a way that the velocity in the last tick and the wall rejection, tread application etc are included! The obvious fix is to calculate a snapshot just *after* calculating position at 2, but to put it in place just *before* calculating 2 on the next run through. As a result, the displacement on each tick is the previous tick's collider adjustments, any updates from the game object position [for ticks that span frames], and the current round's velocity update. There's a risk here! We actually sync out to the game object a value which is never actually used as a previous value in the physics engine. This doesn't seem to be a problem in practice, but perhaps there are exotic collision schemes which pose a problem here.

This version no longer uses velocity as an input to collision or separation, preferring to use calculated-on-demand dx & dy values. Everywhere. This means that everything "just works":

If you modify your game object's position during e.g. `update`: the body will be set to that position during its next step 1 as before (and then have its velocity added), but newly, the body's prev during update & collision will be the value just after the velocity was added

If you modify your body's position during a collider: the body's prev was snapshotted before any colliders ran, so that new position will count as motion for collision and embedding logic.

So, the ridiculous finished project: fully generic relative motion on walkways in arcade physics. Whew!

[voodoospazm]

Really wish I kept my PSD files....

[yudizblog]

As the gaming industry is on the verge of continuous development. Small scale gaming is taking over the industry by storm. There are many critical aspects that support this development and will continue to do so.  The HTML5 Game Development Specifications introduced numerous APIs to enable Development of the Web, allows our games to reach as many users of different computing devices. Phaser is a popular Game Framework that quickly enables us to build games for the web.

[ericvanderburg]

Embedding Phaser3 Games into React 18 Function Components with useEffects

http://dlvr.it/SkN29q

[html5-games]

For every video in my tutorial series about #mobile #gamedev, I make a written summary on my Dev Blog! I've recently summarized Ep. 06 "How to Make an Endless Scrolling Level with Phaser 3" https://browsergameshub.com/endlesscave06-floor-scrolling-mobile-games-phaser3/ 👈 

[fkumnk]

なんかNinjaが活躍を報告してくれて嬉しい話

まず背景として

こんにちは。 この記事はCoderDojo Advent Calendar 2020 - Adventar 6日目の投稿です。 2年ぶりの参加となりますが、今回もCoderDojo紫雲での活動内容についてお届けしたいとおもいます。

※この文章はノリと勢いで一気にグワッっと書き綴ったので、後で恥ずかしくなって数カ月後くらいに加筆修正されるかもしれません。乞うご期待。

CoderDojo The community of 2322 free, open and local programming clubs for young people

CoderDojo – 世界中の子どもたちがともに技術を創造し探求することを可能にします

時は2019年末、愛知県名古屋市……

ちょうど1年ほど前に愛知県を舞台に開催されたDojoCon Japan 2019に、ぼくもスタッフとかチャンピオン相談員とかで参加しておりまして、その時の懇親会のライトニングトークで、やがてCoderDojoを離れていくNinjaたちのことについてお話しました���

年末から年度末に掛けては、一部の学生にとっては受験シーズンにあたり、出会いと別れの季節であったりします。たぶん。 NinjaたちのCoderDojoを離れていく理由についてはもちろん人それぞれの千差万別なんですが、成長につれて広がっていく社会的な世界に合わせて、自分たちの道を見つけながら逞しく進んでいってもらえれば、それはめっちゃ頼もしいやんけ！ というふうにおもいます。

新しく入ってくるNinjaと、新しく始めたこと

ここからは、2020年に入ってCoderDojo紫雲で新しく始まったことと、変化について書いてみたいとおもいます。

Case1.デジタルグラフィックス

これまでも単発では絵を描いたりすることもあったんですが、継続的な取り組みが始まりました。ペンタブ持参でどんどん描き進めていくので、メンターとしては完成を見守るばかりですｗ グラフィックツールの作法とか概念的なものが、最���は分かりづらかったりするので、レイヤを組み合わせるというようなデジタルツール側のアドバイスを行っています。最近は別のGameJamで教わったBlenderで立体オブジェクトの作成にも挑戦したりしていて、成長が著しいです。田舎あるあるの、周りに同じような興味を持つ仲間が見つからないというのが惜しいところですが、年齢が上がるに連れて使用できるオンラインサービスも増えてくるので、いずれはそこで活躍の場を見いだせることができるんじゃないかなーと期待しています。

主な使用ツール：Krita | デジタルでのお絵描きと創造の自由を

Case2.動画編集

まったく何も無い状態から、動画編集を始めてみたいっていう希望があったので、メンターとして取り組んでみました。持ち込みできるPCが無くて家庭でも共用ということだったので、ひとまずDojoのPCを使ってもらうことにして、動画編集の基礎中の基礎をKdenliveを使って体感してもらいました。上から下に映像と音声のトラックが重なってて、左から右に進む時間軸を切ったり貼ったりしながら操作して、一つの作品を生み出していくみたいなやつですね。

次回来るときには、編集してみたい動画を撮影して持ってきてねって約束して、持参してもらったんですけど、その時気がついたんですよね、お手持ちのその端末はiPod なのでは？ ということに！ (※nanoではない) その日からは、急遽予定を変更してiPodでできる方法を使っていつでも自由に動画編集ができる方法を探っていくことにしました。コンピュータは、人の持つ力を増幅させる装置でもあるので、使う人の身近にあって自由に使うことができる端末である方が自分自身のポテンシャルをより良く引き出すことができるんです。しらんけど。

誰かに届けるために作りたいという動機もあってか、開催回数の減少にも関わらず、その日以降の技術の向上には目覚しいものがありました。なんかちょっと良い話になりそうなので、これはここで以上です。

Case3.Scratchの次の道

Scratch、その次に。というやつです。これはある意味世界中のCoderDojoの業であり命題なのかも。ということで我々は何の考えもなく唐突にC#に突撃して三ヶ月の激闘の末、ボコボコに敗北しました。 いや、これは、言い訳をすると、ぜんぜん駄目だったわけじゃなく、チュートリアルを完了して、だいたい基礎も理解できたとおもったけど、気がついたら太平洋の真ん中を当て所もなく漂流してたっていう感じです。例えるならばッ！

では気を取り直して、もう少し近い道を探しましょう。太平洋横断とかではなくて、Scratchちょっと次の道、2つの道が見えてきました。1つ目の道は、GDevelop。これはブロック型ではないんですが、いろんな選択肢を選んだり組み合わせたりしてプログラミングしていく、オーサリングツール的なゲームエンジンです。最初はこれのチュートリアルを進めながら少しずつScratchから旅立っていきました。このままGDevelopを極めてもいいんですが、2つ目の道にも挑戦してみました。なぜなら我々にはもう残された時間がありません。受験勉強が控えているのです。

そんなこんなで、残された時間の2つ目の道は、Phaser3。これはHTML5を使った本格的なゲームエンジンです。ガリゴリとコードを書き続けることになるので、プログラミングぅって気持ちも高まることでしょう。しらんけど。 いろいろあって、限られた期間ながら、デザインスプリント的手法も取り入れつつ、最終試練シリーズ、「始まりと終わりのある遊べるゲーム」を作ることに成功しました。この成功を糧に、進み始めたエンジニアリング人生を逞しく生き抜いてほしいです。

Case4.オンラインCoderDojo

これはもう、文章が長くなってきたので省略したいくらいNinjaたちには不評でした。オンラインが駄目っていうよりは時世の変化の影響が強いです。 参加してるNinjaたちのシチュエーションに合わせたオンライン環境を運営者側でうまく用意することができれば継続していくことはできそうですね。

行動することで変化すること

大人はなんというか、ほしい物、必要な物があると、頑張って働いたりコツコツ貯金したりゴメンナサイしたりして買って手に入れますよね。では未成年の時はどうだったでしょうか。なかなか難しかったりしますよね。ぼくも道を踏み外して踏み抜きました。 さて、ここで回想には入らずに、ここ数年のお話なんですが、どうもNinjaの経験と成長に比例して、手持ちのデバイスが増えたりレベルアップしたりしてるんです。あれっ？ 髪切った？ みたいな勢いで端末が新しくなるので、話題には事欠かないんですが、そういうことではなくて、とても大切なポイントです。最初に、未成年欲しい物があっても一人ではままならねえ、みたいな事を書きました。Ninjaたち各家庭でどのような経緯があったのかを知る由はないんですが、一人ひとりの行動の積み重ねが、身近な人々の何かを動かしたことは間違いないでしょう。でももしかしたらやっぱ偶然かも。自信が無くなってきたので、この話は以上です。

Ninjaフォーエバー

CoderDojo紫雲は中学生が多いので、継続参加者向けのDiscordサーバを用意しています。みんな優しいので、ぼくがお知らせを通知しても、いつもそっとしておいてくれるんですが、志望校に合格したり、国家資格を取ったり、全国大会に出たりとかは、聞いてもいないのにガンガン投げつけてきてくれてとても嬉しいです。 わしがそだてた！　わしがそだてた！ って言いたいので、これからも自分たちの道を広げながら、誉れを重ね続けていってほしいなあとおもいます。あと、今月27日はお待たせしました起死回生の、無いかとおもった？ やったぜ、ありますDojoCon Japan 2020 - Beyond the distance(距離を超えて) - フルオンライン開催が控えていますので来て。

明日は、CoderDojo Advent Calendar 2020 - Adventar の7日目です。たぶん。

[tak4hir0]

この記事は エムスリー Advent Calendar 2019 の 9日目の記事です。 エンジニアリンググループ AI・機械学習チームの安田です。 現在、未踏で「web開発向けオープンソース量子計算ライブラリの開発」をしており、今回はそれに関連して量子タワーディフェンスを開発した開発中... なのでその話とそれに絡めて量子ゲームについてお話しします。 量子ゲームとは なぜ量子ゲームか 既存の量子ゲーム 今回開発しているゲームについて 簡単なゲームと画面説明 コンセプト これおもしろいの？ まとめ We're hiring! 量子ゲームとは ここでいう量子ゲームとは、ゲート式の量子コンピュータを使った or 量子コンピュータの原理をネタにしたゲームになります。 今回は開発しているゲームは、未踏で開発しているqramanaというシミュレータを使って、タワーディフェンスに量子要素を取り込んだものです。 github.com なぜ量子ゲームか なぜ量子ゲームかというと、単純に面白いものが作れるかもしれないという考えがあります。しかし、それより面白いテーマとして教育的な観点があります。 簡単にいうと、量子現象が直感的じゃないので、ゲーム体験の中から量子ネイティブな人がでてきたら量子コンピュータももっと発展しそうだよね、というわけです。 例えば、以下は量子コンピュータ界隈のPreskill氏の論文ですがそこでも言及があります。 arxiv.org 6.11 Quantum games Advances in classical computing launched a new world of digital games, touching the lives of millions and generating billions in revenue. Could quantum computers do the same? Physicists often say that the quantum world is counter-intuitive because it is so foreign to ordinary experience. That’s true now, but might it be different in the future? Perhaps kids who grow up playing quantum games will acquire a visceral understanding of quantum phenomena that our generation lacks. Furthermore, quantum games could open a niche for quantum machine learning methods, which might seize the opportunity to improve game play in situations where quantum entanglement has an essential role. この点は、量子力学を学んでいる際にもボーアやファインマンが量子力学わかってるっていう奴は量子力学わかってない的なセリフを言っていたと目にしていたので、共感できるとともに個人的に関心のある理由です。 なので、ライブラリへのFBも兼ねつつ個人的に量子ゲームを開発しているというのが今回の開発の発端になります。 既存の量子ゲーム そんな量子ゲームですが今現在どんなものがあるのか、またその辺の活動事情について簡単に紹介します。 まず有名どころですが、IBMのHello Quantumです。 Hello Quantum pc.watch.impress.co.jp こちらはスマホで量子ビットを学べるパズルです。Qubitにどのような演算を作用させるとどのように状態が変化するか、ということをパズルを通して体感できるゲームになっています。インストールもスマホということでお手軽なので、ぜひ一度遊んでみてください！ 他にQiskit Campにて量子ゲームを開発するイベントなどもあります。 medium.com また、Qiskit Campの話も含めここ数年の動向をまとめた記事があるのでついでに紹介します。 medium.com このように、これまでも多くはないものの開発されたゲームや開発イベントなどが開催されているゲームジャンルになっています。 今回開発しているゲームについて 前述の通り、今回開発しているゲームは量子タワーディフェンスです。 技術選定としては TypeScript Phaser3 qramana を使用したブラウザ上で動くゲームです。 github.com 簡単なゲームと画面説明 このゲームは、 敵が自分の陣地(一番左の青い1マス)に入らないように排除するゲームです 敵は上か右の赤い陣地から出現します 敵はゴールまで最短経路で移動します プレイヤーは以下のコマをマップ上に配置して敵の排除を狙ってください 何種類かのレーザーが出る塔 弱った敵を排除するなんかすごい場を作る塔 敵は、レーザーを浴びると強くなったり弱ったりします 色でその状態がわかります どのレーザーを当てれば敵が弱るのかは遊んで研究しよう！ みたいなゲームです。 画面の説明をすると、 黒い画面端の部分: 通り抜け不可能な壁 左端の���い1マス: プレイヤーの陣地(侵入されたら負け) 画面上と画面右の赤いマス: 敵の出現位置 マップ上の白い丸: レーザー塔 マップ上の小さい赤い丸: 敵(状態で色が変わる) という風になっています。 コンセプト これまでリリースされているゲームを見たところ、量子ゲートや量子ビットを知っている前提で作られているように感じたため、 量子ゲートを知らなくても遊べる ことをコンセプトにしました。 その結果、内部的には以下のような設定を上のように表現できるようになりました（なった気がする） 敵が1Qubitの状態を持っている その状態を攻撃して(レーザーで操作して)変更する その後観測して0になれば敵が消える 敵の色はブロッホ球の3軸をRGBで表現する これおもしろいの？ ぜんぜんわかんないです。少なくとも開発を進めている中で開発前には にするようなレーザーと観測器を並べれば戦略的にあそべるのでは とか思ってたのですが、 レーザーは距離等に応じてランダムな回数敵を攻撃するため、ある敵に狙った回数狙ったレーザーを当てるのはむり ということがわかっていて、開発前に考えていた1つの戦略は崩壊しています.... 実際のところもう少し作り込んで遊んでみないと、どのような遊び方ができるのかはよくわからないのが実際です。 まとめ 今回は、申し訳ないことに開発途中のため量子ゲーム自体の紹介と今回作っているゲームを簡単に紹介する形になりました。もし興味を持たれた方は、紹介した通りいくつか公開されているゲームがあるので是非遊んでみてください！ 量子の世界が少し身近になるかもしれません。 We're hiring! エムスリーでは業務に限らず量子計算や自宅IoTやVtuberなどなど色々なことをしている人が沢山います！ ディープな仲間募集中です！ jobs.m3.com

[octopusoddments]

Some screenshots from a point and click adventure game I’ve been working on. Definitely still in the prototyping phase, but it’s been a lot of fun to work on. Currently written using Phaser3, although I did a basic Inform text version to pan out the interactions I wanted first. The github page lives here if you feel like looking it over.

[16naughts]

Dev Log Mar 21 2025 - More Steam Deck Progress

The St. Patrick's Day update is live, and includes full Controller support for the game. Valve was kind enough to include button icons in their install and an API to retrieve the correct ones for which controller you have plugged in, which was a huge, huge plus. I've picked on them a little for their weird decisions with the Alt+Tab overlay rendering stuff, but everything else they give you is absolutely spectacular. There's a reason why both consumers and devs love them so much. Same as last week, we're working on getting that Steam Deck version up and running. We were actually planning on enabling it on the main branch with the last update, but discovered a last-minute issue where all of the API endpoints were mysteriously getting dropped, so save data wasn't able to be read from file. We think it has something to do with WebKit dropping object declared on the window global scope for security reasons, but haven't been able to pin it down just yet, mostly because we're smack-dab in the middle of swapping out the rendering back-end. I explained it a bit in the previous post, but to quickly summarize, Crescent Roll was originally made with Phaser3. Over its lifetime, we've essentially pulled all of it out and replaced it with our own, more specialized code. The only two things remaining were the reliance on its physics system for wall collisions, and the final step of rendering to the screen with WebGL. And as of today, the physics system is completely removed and replaced with a direct usage of MatterJS, and our very own WebGL back-end is now running (albeit not 100% complete), and thus Phaser3 has been effectively removed. Originally, we were hoping to just be drag-and-drop so that the previous version can just be restored with a setting, but there's a couple of quirks with the Phaser systems that it ended up being more efficient to just do what we need instead of trying to retrofit for it. First point is ditching the multi-stage shader pipeline - it's just one pass and done. Even though we'll have to duplicate a little bit of code in our shader files, we're not doing anything insane, so no point in adding extra cycles. Index sorting is also gone, as our container system already has implicit ordering, so we can just lean on that. Pretty simple, just takes time.

Timeline on the project is still looking to be about a week out at this point., and additional performance improvements should continue to trickle in afterward, especially once the mobile ports are in full swing. The next update after this should be some fun actual gameplay stuff.

[browndragon]

Phaser tile + arcade shenanigans

I'm actually designing fidough levels now, since I've got autogroups (& colliders), dough springs, treadmills, 2d models, and other fanciness. I've open sourced all of it, reach out if there's something you want that I haven't already made available or want some help with.

I wired it all together and... it didn't work. I could either have map collisions working or else have intersprite collisions working. Everything I'm doing is sane, so the bug is either in phaser's implementation or else I've misunderstood something (latter more likely). But it's easy enough to test for phaser bugs, so I did (link to the multimedia tax). The problem is a programmer understanding one.

What I learned along the way (no I haven't fixed the underlying issues yet)

Tile collision faces are mess(ier than you could possibly imagine)

Say that you have a map composed of tiles like floor, wall, spike, coin (for a variety of reasons that's silly, but whatever), etc, and of mobs and pickups like player, enemy, coin (again!), maybe bullet, you know, that sort of thing.

The graph of interactions is complex. Neither players or enemies can walk through walls. Players can step on spikes but they hurt; for simplicity, we might say that enemies simply cannot step on spikes. Players can step on coins (and flip them into floor), but we'll say again that enemies treat coins as solid.

Phaser supports this super duper messily. At the end of the day, the internal structures are boolean "does this block movement" and maybe a callback. Which means that if the answer to blocked movement is complex -- you have characters that can swim and fly and so on -- it's going to be a bit uphill.

There's actually an example on the included game. If you line yourself up with the spikes along the bottom edge of the map, you can walk through walls. You see, phaser checked whether it should separate you when you entered the spikes (they're solid... to robots...) and the spikes said "no, let them in, we'll just hurt them". But Phaser removed the internal boundary between the southern edge of the spikes and the wall -- because the wall is solid too! -- and so the player was effectively embedded in the wall the moment they touched the spikes!

The answer is annoying; disable recalculateFaces for anything you know you want to treat as a separate crossing domain. So for instance in this example, I wanted to prevent robots from stepping on spikes and players from crossing over from spikes (ouch) to walking through walls; by doing this I accomplish that. I think there will be micro-jaggedies as a result. Alas. Ai me.

Phaser tilemap callbacks basically require double dispatch

You can associate one callback per tile type -- not per tile type per colliding group, note. So since your one tile layer likely has tiles that different units respond to differently, you have to do double dispatch from the tile callback back into the colliding instance. Due to... reasons... the callbacks are always called (sprite, tile) (even if your collider registered them in the order (layer, spritegroup)), so it seems very likely that the tile callback is always literally (sprite, tile) => sprite[`on_${tile.type}`](tile) (or similar).

What should you do?

Note, I haven't done any of this.

A lot of people suggest you have one colliding layer and n art layers. I've resisted that for a while, but I think I have to give it up. If you had one colliding layer per movement type, you could absolutely have water and walls block walking, floor and walls block swimming, and walls (only) block flying. Building that out without a separate layer per collision type seems hard. You can even derive that on the fly (generate the additional colliders dynamically off of the loaded map's tile types).

[yudizblog]

Overview

Game Development is most trending branch of Software Development. When thinking of creating games, we always use an application to install and play it on our devices and consoles. The HTML5 Specifications introduced numerous APIs to enable Game Development of the Web, allows our games to reach as many users of different computing devices. Phaser is a popular Game Framework that quickly enables us to build games for the web.

In this Series of Blogs, we will be covering the Development of HTML5 Games in Phaser3 and PhaserEditor2D. Let’s Start!

What is Phaser3?

Phaser is a game framework for making 2d HTML5 games for desktop and also mobile. Phaser is free of cost and easy to understand. Phaser 3 is the latest version of the Phaser Framework.

Why use Phaser?

Phaser is very useful game engines for the Web games using JavaScript. Phaser is a free framework. Phaser allows to render game across different platforms. Phaser is powerful and easy to use if you want to start your own game.

Original Source : HTML5 Game Development

[ionictutorial]

RT @sagivs: Just created ionic4-phaser3-template using #ionicframework #ionic4, #angular7 and #Phaser3. It's not a boring blank template. You get a dude to play with but CAREFUL! don't let him stare at you. He can microwave your brain. Keep moving. https://t.co/1bPZbpTRFf https://t.co/T6v8dBTHNG (via Twitter http://twitter.com/Ionicframework/status/1078074613312245761)