1 ポイント 投稿者 GN⁺ 2024-05-09 | 1件のコメント | WhatsAppで共有
  • Deckerは、サウンド、画像、ハイパーテキスト、スクリプト動作を1つの文書にまとめて作成・共有できるマルチメディアプラットフォームで、ブラウザですぐに体験できる
  • HyperCardとclassic MacOSの視覚的な感性を保ちながら、深いアンドゥ、スクロールホイール・タッチスクリーン対応、現代的なキーボードナビゲーション、一括編集を追加している
  • E-Zine、ノート、プレゼン資料、アドベンチャーゲーム、1ビットピクセルアートのような作品を作ることができ、完成したdeckはスタンドアロンの.html文書として保存可能
  • 複雑なプロジェクトはLuaとQの影響を受けたLilで拡張でき、ウィジェット・クリップボード共有・テキストベースの文書形式が再利用とバージョン管理を助ける
  • 広告、テレメトリ、ゲーミフィケーション、slop-generator統合を入れていないMITライセンスの無料オープンソースツールで、GitHubソースとItch.ioバイナリ配布を提供している

HyperCard感覚の対話型ドキュメント制作

  • Deckerは、サウンド、画像、ハイパーテキスト、スクリプト動作を含む対話型ドキュメントを作成・共有するためのマルチメディアプラットフォーム
  • Webブラウザですぐに体験できる
  • HyperCardとclassic MacOSの視覚的美学を受け継ぎつつ、HyperCardが持っていた単純さと学びやすさを維持している
  • 使い勝手の改善は、古いカードベース制作ツールの感覚を保ちながら、現代の入力環境に合わせることに重点を置いている
    • 深いアンドゥ履歴

      • スクロールホイールとタッチスクリーン対応
      • より現代的なキーボードナビゲーション
      • 一括編集作業
      • 作れるものの例は幅広い
      • E-Zine
      • ノート整理
      • プレゼン資料
      • アドベンチャーゲーム
      • 1ビットピクセルアートの落書き
      • 完成したdeckは、Webブラウザで単体実行できるスタンドアロンの.html文書として保存でき、Webページをホスティングまたは埋め込める場所ならどこでも共有可能
      • DeckerはMacOS、Windows、BSD、Linuxでもネイティブに動作する

Lil、ウィジェット、テキストベース開発フロー

  • 複雑なプロジェクトでは、Lilというスクリプト言語を使える
    • Lilは、ツールやゲームエンジンに組み込まれる命令型言語Luaの影響を受けている
    • 時系列データベースとともに使われるAPL系の関数型言語Qの影響も受けている
    • 既存のプログラミング経験があるユーザーにとって馴染みやすい構造を保ちつつ、暗黙的なスカラー・ベクター算術と統合SQL風クエリ言語を含む
  • インターフェース作成には組み込みの対話型ウィジェット群を使え、新しいウィジェット定義も可能
    • カスタムウィジェットと定義はシステムクリップボードでコピー・ペーストできる
    • テキストを共有または保存できる場所なら、カスタムウィジェットも共有可能
    • 各deckは、他のプロジェクトに持ち込んで使える再利用部品の集合として活用できる
  • ソースからビルドすると、スタンドアロンのLilインタープリタであるLiltも提供される
    • LiltはDecker文書を読み取り、書き込み、操作し、headless実行できる
    • Deckerより依存関係が少なく、クロスプラットフォームのAPE実行ファイルにコンパイルできる
    • POSIX AWK上で動作するLilインタープリタもある
  • deckは行単位のテキスト形式で保存されるため、GitやSVNのような既存のソース管理ツールとよく連携する
  • Deckerには、広告、テレメトリ、ゲーミフィケーション、slop-generator統合、ユーザープライバシーと自律性を損なう要素がない

サンプルdeckと拡張ライブラリ

ソース、配布、コミュニティ

  • 閲覧しやすいソースコードとバグトラッカーはGitHubにある
  • DeckerはMITライセンスの無料オープンソース
  • MacOSとWindows向けの定期的なバイナリリリースはItch.ioで入手できる
  • Itchページには、Deckerの議論やDeckerで作られたプロジェクト共有のためのコミュニティフォーラムがある
  • Deckerテーマの「Game Jams」は毎年7月と12月に開催され、次回予定のイベントはDecker Fantasy Camp, July 2026

1件のコメント

 
GN⁺ 2024-05-09
Hacker Newsの意見
  • 美しい!ここで追求している美学があるのは分かるけれど、1ビットグラフィックからほんの少し進んで2ビットグラフィックにすれば、実際に読める写真も可能になりそう
    似た美学を持つ好きなサイトがあって、そこの全画像は最大6色しか使っていない。ただしパレットは画像ごとに違う: https://solar.lowtechmagazine.com/

    • DeckerのUIは主に白黒だが、実際にはユーザーがカスタマイズ可能な16色パレットを使っている
      コミュニティフォーラム[0]にはディザリングとカラー写真の取り込みについての議論があり、ユーザーたちは色を活用してかなりすてきなプロジェクト[1]を作っている
      [0]: https://itch.io/t/2668739/16-color-dithered
      [1]: https://crowmorbid.itch.io/desker-deckmonth
  • 実際に試してみるのも忘れずに!
    https://www.beyondloom.com/decker/tour.html
    これを見て、驚くほど甘酸っぱい思い出がよみがえったのだけど、自分だけだろうか?望むのはモバイルでピンチズームできることくらい

    • どういうわけか、iPhone画面の20%くらいしか使っていないように見える
      小さすぎて文字が読めず、ピンチズームも無効になっているので近づいて見られない
    • Firefoxの問題かもしれないし、使い方が分かっていないのかもしれないが、New Cardを押すと空白の画面だけが出て、書いたり描いたりする方法がない
  • このプロジェクトの選択は尊重するが、HyperCard最大の欠点は、Macがカラーを受け入れ始めたときにカラーを実装できなかったことだと感じる
    高校生のころ、学校のMacはすべてカラー機だったのに、HyperCardには本物のネイティブカラーが結局入らなかった

    • 私の記憶もだいたい同じ。HyperCardは特に子どもたちにプログラミングを紹介する道具としてものすごく人気があったが、Quadra Macシリーズがカラーを搭載して登場すると、誰もがカラーを求めた
      HyperCardはネイティブカラー対応のアップデートを受け取れず、それこそがみんなが最も欲しがっていた機能だった
      関連製品としてSuperCardだったと思うツールがカラーを提供していて、使ってみたが不格好だった。理由は正確には覚えていないが、結局広まらなかった
      HyperTalkの制限されたAPIも問題だった。拡張機能の市場があり、何人かの開発者がしばらくその領域を支配していた。J5ersonはどうなったのか気になる。本当に優秀だった
      拡張機能はたいていPascalで書かれていて、HyperTalkに多くの機能を追加できたため、HyperCardを越えてプログラミングをさらに探求したい人にとって良い足がかりになった
      Deckerは、シンプルさや移植性といったHyperCardの長所を多く取り入れているように見える。ただ、HyperTalkにもっと近い言語を使っていないのは少し惜しい。あの言語はそれ自体、本当に良かった
  • Deckerは主に1ビットなので見た目はHyperCardに似ているが、実際には完全に新しく学ばなければならないほど違う
    使うのはかなり難しく、新しく独特な言語であるLilを学ぶ必要があり、HyperCardやMacPaintを期待すると探してしまう多くの便利機能が欠けている
    結局、HyperCardのアーティストたちは移行しにくく、Infinite Macのおかげでブラウザ上でHyperCardを使い続けることになる。とても近いのに遠い。似ているが違う

  • 学校に、シャトル情報がぎっしり入ったNASAのレーザーディスクがあった
    ナビゲーションと情報表示のためにHyperCardを実行するMacにつながっていて、かなり格好よかったが、当時はそれほどきちんと鑑賞できていなかったと思う

    • そういうものは覚えている!それは見たことがないけれど、画像入りの格好いいミニデータベースのようなHyperCardスタックが出回っていたのは確か
      90年代のマルチメディアブーム以前の、初期マルチメディアという感じだった :-)
  • AppleやMicrosoftが、なぜOSにカジュアル開発者向けのこういうツールをもっと熱心に作らないのか分からない
    VBやPythonも悪くないが、ときどき小さなアプリケーションを作るのに本当に特化したツールが必要になる

    • AppleにはSwift Playgroundsが一応ある
      それにSwiftUIは可能な限り簡単なほうだ
      ただしXcodeを使い、App Storeの設定までしようとすると、依然として難解な設定とXcode IDEについてのある程度の理解が必要になる :-)
  • HyperCard への愛着が本当に深い
    私自身は直接体験していないが、人々が小さくて便利なツールをたくさん作れるようにしてくれたものだったように思う。汎用性という面ではスプレッドシートに似ているが、用途は別物という感じ
    あの時代を経験した人たちにとって、今のどんなツールがあの感覚を与えてくれるのか気になる
    私はもう少し若い世代なので、Delphi/VB や Macromedia Flash のようなツールに郷愁がある。完璧ではなかったが、創造力を刺激してくれた
    今のツールははるかに良くなったが、その過程で何かを失ってしまったように思う

    • Flash はかなり近かったが、平均的なユーザーには複雑すぎ、高価すぎた。HyperCard は当初無料だったが、Performa Mac シリーズにはバンドルされていなかった
      HTML は HyperCard が提供していた多くの部分を引き継いだが、Web オーサリングツールは結局そこまで簡単にはならず、HyperCard のある機能、つまり UI の見た目と操作感が一貫しているという点も提供できなかった。これは長所にも短所にもなり得るが、ページに「前へ」「次へ」ボタンを 2 つ追加するだけでフリップブックを作れる点を好むユーザーもいた
      教材を HyperCard スタックとしてまとめて販売する事業を始めた人たちもいた
      HyperTalk プログラミング言語は優れていたわけではなく、ヒッピーが好みそうな種類の言語だったが、平均的なユーザーは C や Pascal を見たときと同じくらい戸惑っていた
      Apple はそれでできることを過度にコントロールしようとしていた、という感覚が常にあった。プログラミング言語とその周辺ツールに私が期待するものとは逆だった
      どんな感じだったか知りたいなら、AppleScript で何かをコーディングしてみればよい
    • 私も別の世代だが、HyperCard の特別さが何だったのか気になる
      VB と Macromedia のツールは覚えているし、最近のツールのほうが使いにくいと感じる
    • Flash は素早く何かを作り、広いユーザー層に配布するための優れたツールで、ブラウザベースかつマルチプラットフォームだったという点では、当時の HyperCard よりもその約束をうまく実現していた面が多かった
      ただ残念なのは、Flash の制作者と Flash の消費者の間に大きな隔たりを作ってしまったこと。意欲のある tinkerer なら .swf をデコンパイルして修正することもできただろうが、すべてのユーザーに編集ツールを渡し、すべてのスタックを再利用可能な部品の集まりにした HyperCard のモデルとは大きく違っていた
      Decker はエディタを隠す「ロックされた」スタンドアロンのデッキを書き出せるが、再び有効化する手順は些細なものだ。ゲームをクリアすると自分自身で「ロック解除」されるように設計した例も見たことがあり、かなり素敵な報酬だと思う
    • それほど愛されていたのに、なぜ HyperCard は消え、似たものがその座を占めることもなかったのかも気になる
    • 「小さくて便利なツールをたくさん作れるようにしてくれた」という面だけで見れば、今思い浮かぶ最も近いものは Godot “ゲーム” エンジンだ: https://godotengine.org
      多くの面で HyperCard とぴったり一致するわけではないが、関連する 3 つの領域では特に強力な候補だ。初期ダウンロードサイズが小さく(<100MB)、ロード/実行時間が短く、「動く何か」を作る初期の探索的な開発段階に適した反復的・ハック的な開発フローを支えている。GDScript はこれに非常によく合っており、最近の漸進的型付けのような追加によって、時間とともに堅牢性も高まっている
      Godot の配布/インストール方式も非常に強力だ。この領域では、ほかのどのエコシステム[0]よりも数光年先を行っていると思う。サポートしたいプラットフォームのエクスポートテンプレート、つまりプラットフォーム別の汎用バイナリ実行ファイルをダウンロードし、プロジェクトごとのコードとリソースをパッケージ化してエクスポートすればよい[1]
      現在の Godot が HyperCard や「古典的な」Visual Basic と比べて意外にも最も不足している部分は、ドラッグ&ドロップによる UI 作成だ。Godot にはかなり強力な UI システムがあるが、ときに不透明で、現在の UI 作成体験は、ウィンドウ上にツールバーからウィジェットをドラッグして置く方式ではなく、シーンのノードツリーをかなり意識させるものになっている
      このユーザー体験は Editor Plugin で比較的簡単に改善できそうで、いつかその沼に向けたプロトタイプを作るかもしれない :)
      完璧な解ではないが、最近 GUI ベースのユーティリティを作るときには、確実にデフォルトの選択肢になっている。そのうちいくつかは実際に「リリース」できるくらいまで完成させてもいる :D
      [0] この点では特に Python は悲惨なほど崩壊している
      [1] Web 用の WASM エクスポートも可能なので、最初は Web ベース版でユーティリティを試してもらい、十分に便利ならローカル実行ファイルもダウンロードしてもらうという二本立ての配布が可能だ
  • Decker は本当に良くて、とても面白い
    HyperTalk スクリプティングを探しているなら、Wyldcard も楽しめるはず
    https://github.com/defano/wyldcard

  • 先週の HyperCard 代替の議論で言及されてから、Decker を掘り下げ始めた
    デッキのパッケージングが本当に気になる。Redbean のように Lua、SQLite などを含めてすべてが 1 つのファイルに入り、zip ツールで開いて HTML と Lua コードを入れ、名前を変えるだけで配布準備が整う方式が気に入っている
    Decker も配布を簡単にするために、そうした種類の方式を検討しているのか気になる