タグ

developmentとprogrammingに関するrikuoのブックマーク (45)

  • 『メタルギア』『ZOE』の開発者がレトロゲームエンジン「Pyxel」を作った理由【フォーカス】 | レバテックラボ(レバテックLAB)

    レトロゲームエンジン「Pyxel」開発者 北尾 崇(Takashi Kitao) 元ゲーム開発者。コナミ在籍時に『METAL GEAR SOLID』(企画・ツール開発・CGムービー制作)、『ZONE OF THE ENDERS』(メインプログラマ・ゲームデザインユニットディレクター)、『ANUBIS ZONE OF THE ENDERS』(メインプログラマ・グラフィックエンジン開発)などに携わる。現在はエンターテインメント・テクノロジー企業でデジタル機器やゲーム向けのXR技術の研究開発を統括。2018年から個人活動として、オープンソースのゲームエンジン「Pyxel」の開発を手がける。2025年1月には技術評論社よりPyxelの入門書籍「ゲームで学ぶPython! Pyxelではじめるレトロゲームプログラミング」が発売予定。 X Pyxel レトロゲームエンジン「Pyxel」は、GitHub

    『メタルギア』『ZOE』の開発者がレトロゲームエンジン「Pyxel」を作った理由【フォーカス】 | レバテックラボ(レバテックLAB)
  • カナダ大使館でだけ名刺交換やしりとりが失敗する話|南治 一徳

    祖母の就寝と、システムの不具合が同期して起こる事件IT業界にはこういった事件がまま見られる……。ITサスペンス物としてこういうネタ楽しいのができるかもしれない。いや、間口狭すぎるか? 祖母が就寝するとDBインサートができなくなる https://t.co/q2PBRL3JzS — 寺島壽久/ゲームキャストの中の人 (@gamecast_blog) January 8, 2024 この手の話、自分も大好物なんで早速リンク先に飛んで読ませていただいたのですが、自分の経験でもちょうどこんな話に当てはまる出来事があったことを思い出したので、noteにまとめました。それが、タイトルにもある「カナダ大使館でだけ名刺交換やしりとりが失敗する話」です。 まず、前提としてこの話は「どこでもいっしょ」(以降、どこいつ)というゲーム開発中の話でになりまして、25年ほど昔の話になります。タイトル中の「名刺交換」

    カナダ大使館でだけ名刺交換やしりとりが失敗する話|南治 一徳
  • 「キャッシュは麻薬」という標語からの脱却 - id:onk のはてなブログ

    これは はてなエンジニア Advent Calendar 2023 の 18 日目の記事です。昨日は id:gurrium による private-isuで70万点取るためにやったこと - ぜのぜ でした。私は 50 万点ぐらいで満足してしまっていたので、しっかり詰めていて凄いなと思う。 developer.hatenastaff.com Web アプリケーション開発において、「キャッシュは麻薬」という言葉がインターネット上をよく飛び交っています。YAPC::Kansai OSAKA 2017 の id:moznion のトークでよく知られるようになったワードじゃないかな。 初出はちゃんとは分からないんですが、少なくとも 2011 年には言われていますね。 「キャッシュは麻薬」とはよく言ったものだ。— TOYAMA Nao (@nanto_vi) November 5, 2011 キャッシ

    「キャッシュは麻薬」という標語からの脱却 - id:onk のはてなブログ
  • Web のセマンティクスにおける Push と Pull | blog.jxck.io

    Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装 と Pull 型の実装 があると考えている。 もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。 この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。 「自分は今 Push で実装しているのか、 Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (エントリでの Ossification は、一般に言われている Pro

    Web のセマンティクスにおける Push と Pull | blog.jxck.io
  • ワンボタンゲームをたくさん作ったので、その作り方をおさらいしたい - ABAの日誌

    English version: How to realize various actions in a one-button game はじめに 自作ゲームライブラリcrisp-game-libを使ったミニゲームを最近たくさん作っているが、特に多く作っているのがワンボタンゲームだ。ここで言うワンボタンゲームは、レバーによる移動の他のボタンが1つ、といったものではなくて、純粋に1つのボタンしか操作に使わないゲームを指す。 ワンボタンゲームの利点は、操作が分かりやすく、タッチデバイスでも操作しやすい点にある。とにかく何かボタンを押せばそれがプレイヤーが取れる動作の全てであり、操作説明がほぼ不要である。またタッチデバイスでも画面中のどこかをタップあるいはホールドすれば操作ができるので、バーチャルパッドでよく起こる、ボタンを押した感触が無いので操作がしづらいという問題が発生しない。 欠点は、当然

    ワンボタンゲームをたくさん作ったので、その作り方をおさらいしたい - ABAの日誌
  • ゲームエンジンはアートである - 8 年以上自作ゲームエンジンをメンテし続けている話|Hajime Hoshi

    自分は Ebiten という 2D ゲームエンジン (ゲームライブラリ) を趣味で開発しています。使用しているプログラミング言語は Go です。 2013 年 6 月に最初のコミットを行ったので、現在 8 周年の 9 年目です。 Ebiten は「くまのレストラン」などのモバイル及び Nintendo Switch 向けゲームで使われており、一定の実績があります。 ゲームエンジンの開発は一朝一夕では終わりません。UnityRPG ツクールといった既製品がある中、ゲームエンジンをわざわざ自作することは酔狂かもしれません。ではなぜそのようなことをしたのでしょうか。端的に言うと「ミニマムな API で実用的な 2D ゲームが作れるかどうか」ということを証明したかったのです。自分の美的感覚の追求です。この目的に気づいたのは割と最近のことです。やっていくうちに「自分がやりたかったのはこういうこ

    ゲームエンジンはアートである - 8 年以上自作ゲームエンジンをメンテし続けている話|Hajime Hoshi
  • タイムゾーン呪いの書 (知識編)

    「タイムゾーン呪いの書」は、もともと 2018年に Qiita に投稿した記事でしたが、大幅な改訂を 2021年におこない、同時にこちらの Zenn に引っ越すことにしました。 この改訂では Software Design 誌の 2018年 12月号に特集の一章として寄稿した内容も取り込みつつ、夏時間をめぐって各地で起きつつある変化について 2021年 6月現在の状況なども追加しました。そんな追記もしていたら記事全体が長大になってしまったため、この「知識編」と、「実装編」・「Java 編」に記事を分けました。「知識編」は、導入にあたる第一部です。 Qiita のほうは、引っ越した旨とこの引っ越し先へのリンクだけ追記して、しばらくそのまま残すつもりです。 はじめに タイムゾーンという概念のことは、ほとんどの人が聞いたことがあると思います。ソフトウェア・エンジニアでも多くの方が、時刻やタイムゾ

    タイムゾーン呪いの書 (知識編)
  • 普通に開く“扉”をゲーム内に作るのは,なぜそんなに難しいのか

    普通に開く“扉”をゲーム内に作るのは,なぜそんなに難しいのか ライター:游研社 下記の記事は,游研社(→リンク)に掲載された記事を,許可を得て翻訳したものです。可能な限りオリジナルのまま翻訳することに注力していますが,一部,画面写真などを変更したり,文化的な背景などで理解されづらいものについては日向けに表現を変えたりしている箇所があります。→元記事 デベロッパー達は,長い間「扉」に苦しめられている 少し前に,インディ開発者のStephan Hövelbrinks氏が,個人の感想をツイートした。「ゲームにあるドアは開発が複雑すぎて,いろんなバグの誘因になる」「デベロッパーであれば誰もが痛感していることだ」 Doors #gamedev pic.twitter.com/7CJgKin1dE— Stephan Hövelbrinks (@talecrafter) March 9, 2021 こ

    普通に開く“扉”をゲーム内に作るのは,なぜそんなに難しいのか
  • Windowsのタスクバーでもネコ走らせてみた🐈 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに みなさまはMacのメニューバーでネコを飼うRunCatというアプリをご存知でしょうか?CPU負荷に合わせて走る速度の変わるネコをメニューバー上に表示するだけというしょうもないアプリですが、現在では世界累計45,000ダウンロードを突破し、多くのみなさまに可愛がってもらえる定番アプリとなりつつあります。はじめは悪戯心で作成したジョークアプリが、思いもよらず高評価をいただけており大変嬉しいです。 一方で、Windows版がほしいとの声もちらほら聞こえるようになり、Windows版の模倣アプリも作られつつあることを知りました。そこで

    Windowsのタスクバーでもネコ走らせてみた🐈 - Qiita
  • やっていく技術テーマを探す - はこべにっき ♨

    Webエンジニアを8年くらいやっていて、なんとなく、一通りのことはできるようになってきた。ただ、ちょっと得意な分野もあるとはいえ、基的になんでも屋さんとしてやっているので、技術者としてのアピールがいまいちだなーというのが気になっている。そこで、技術者としての自分をアピールできそうな技術テーマを一つ選んで、それにじっくり取り組んで見ようと考えた。 しかし、取り組む技術テーマをうまく選ぶ自信がない。そこで、ちょっと作戦を考えて取り組む技術テーマを見つけようと試行錯誤してみたので紹介してみる。 ステップ1: 指標を考える やっていく技術テーマを見つけるにあたって、テーマの候補をスコアリングしてみることにした。漠然とスコアをつけるのは難しいので、自分が普段技術テーマに取り組むかどうかを考えるときに気にしていることを思い出して、5つの指標に分解してみた。 指標1: 自分の興味 自分がおもしろい、や

    やっていく技術テーマを探す - はこべにっき ♨
  • イマドキのJavaScriptの書き方2018

    PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」(よりよい代替がある)というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前のやウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい

    イマドキのJavaScriptの書き方2018
  • JavaScript fatigue fatigue

    Enough with the fatigue – tips against feeling overwhelmed: Don’t try to know everything – it’s impossible in modern web development. Given that there is always more to know, it doesn’t matter that much what you learn (unless you have a specific need). Go for depth in areas you love. Go for breadth and on-demand learning in areas you are merely interested in or think you should know more about. Wa

  • 続: OSSプロダクトとコミュニティの話 - たごもりすメモ

    先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。 t-wada.hatenablog.jp t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。 明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。 なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく

    続: OSSプロダクトとコミュニティの話 - たごもりすメモ
  • OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

    YAPC::Asia Tokyo 2015 前夜祭に参加して、柴田さん( hsbt さん)とモリスさん*1( tagomoris さん)の講演を聴いた。特に最後のモリスさんの講演を聴いていて、ちょっとした衝撃を受けると共に、気づきや疑問もあったので、久しぶりに blog エントリを書こうという気になった。 なお、このエントリは講演メモや浮かんだ疑問、その後の議論等を記したものであり、すっきりとした結論は無いのでご注意。 モリスさんの講演 講演資料が公開されていた How to create/improve OSS products and its community from SATOSHI TAGOMORI 講演時に取ったメモがこちら 我々にできるOSSとそのコミュニティの育てかた ======================= id:tagomoris TD のモリスさん TD はデー

    OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ
  • 仕事とは、プログラミングとは - mizchi's blog

    これは、冒頭の問いから端を発した、各章のつながりが不明瞭なエッセイ、流行りのミームでいうと技術的ポエム、であり、プログラミングをテーマにしていてもプログラミングの記事ではない。(と一番最後まで書き終わった自分が注釈を入れている) 良いコードとは何か 趣味で4年、腰を入れたは最後の2年なのだが、それから3年間ほど仕事でプログラムを書いてきた。それで、趣味プログラマと業務プログラマの一番の違いは、業務プログラマが要求されるのが「他人にどれだけ意図を伝えることができるか」ということに尽きると思うようになった。 他人にとって良いコードとは、書いた人の意味が読み解けるコードであると思う。どれだけ書いた人の自意識の中でかっこいい・よいコードを書いたと思っていて、実際にちょっと紐解けばそのポテンシャルがあったとしても、隣に座っている人間に伝わらなかったら意味が無い。正しくコードレビューが行われるなら

    仕事とは、プログラミングとは - mizchi's blog
  • CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」

    社内ライブラリを8年間に渡って作り、サポートし続けてきた講演者が、1~2年で完成するだろうという当初の想定とは裏腹に、なかなか進まない作業、得られないサポート、バグの押し付け合い、それら数々の修羅場から得られた、技術面およびサポート面でのノウハウをお伝えします。 http://cedec.cesa.or.jp/2014/session/ENG/8073.html ※2014/9/4にCEDEC2014@パシフィコ横浜で行った講演です。

    CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」
  • JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD

    この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり:私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ

    JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD
  • はてなブログ編集画面JSのページャ見どころ紹介 #pagernight - hitode909の日記

    昨日,ページャNightという勉強会で,はてなブログのJSの見どころを紹介するLTをした.(昨日の日記). 資料公開しようかと思ったのだけど,発表資料そのまま公開しても意味不明なので,エントリに書き直すことにした. たとえば,このLGTM画像は発表資料の1枚目で,もし発表資料をそのまま公開したら,こういう謎の画像を解説もないまま見ることになっていたはず. JSのページャいっぱいある はてなブログの編集画面には編集サイドバーというのがあって,写真とかAmazon検索とかTwitterとかinstagramとかあれこれ貼れるようになってる. Amazon検索しても画面遷移するわけじゃなくて,ウェブ2.0という感じで,XHRでJSONを取ってきて,HTMLを組み立てて表示,クリックすると選択,貼り付けを押すとエディタに挿入される,という仕組み. 編集サイドバーから貼れるサービスは10種類くらいあ

    はてなブログ編集画面JSのページャ見どころ紹介 #pagernight - hitode909の日記
  • Google Design - Discover the people and stories behind the products

    How to balance the emotional and rational to create powerful palettes

    Google Design - Discover the people and stories behind the products
  • 開発のドキュメントをどこに置くか問題 - $shibayu36->blog;

    最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは

    開発のドキュメントをどこに置くか問題 - $shibayu36->blog;