前からずっと言いたかったことがある。同じ過ちを犯すゲーム開発者に。あるいは、「ゲームを完成させた体験が無い人」に。 あなたのゲーム開発に対する予測は、ほとんどの場合正しくない。それも、20%や40%などの振れ幅ではない。200%とか400%のスケールで大きく間違っている。 私はその感覚を確かめるべく一つのアンケートを実施した。結果は火を見るより明らかな傾向を示した。 個人ゲーム開発者に質問です。「１年で完成させる」と思って作り始めたプロジェクト、実際に完成したのは？ — じーくどらむす/岩本翔 (@geekdrums) June 4, 2024 Twitterアンケートの統計的な正しさは保証しない。そもそも母集団が偏っているし、最後の選択肢が「未完成」を含めていることに対して「４年以内に諦めて未完成」の人も含めているかもしれない。が、エターナったという意味では４年以上完成しないもの、に含め
祖母の就寝と、システムの不具合が同期して起こる事件。IT業界にはこういった事件がまま見られる……。ITサスペンス物としてこういうネタ楽しいのができるかもしれない。いや、間口狭すぎるか？ 祖母が就寝するとDBインサートができなくなる https://t.co/q2PBRL3JzS — 寺島壽久/ゲームキャストの中の人 (@gamecast_blog) January 8, 2024 この手の話、自分も大好物なんで早速リンク先に飛んで読ませていただいたのですが、自分の経験でもちょうどこんな話に当てはまる出来事があったことを思い出したので、noteにまとめました。それが、タイトルにもある「カナダ大使館でだけ名刺交換やしりとりが失敗する話」です。 まず、前提としてこの話は「どこでもいっしょ」（以降、どこいつ）というゲーム開発中の話でになりまして、25年ほど昔の話になります。タイトル中の「名刺交換」
これは はてなエンジニア 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 キャッシ
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装 と Pull 型の実装 があると考えている。 もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。 この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。 「自分は今 Push で実装しているのか、 Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (本エントリでの Ossification は、一般に言われている Pro
English version: How to realize various actions in a one-button game はじめに 自作ゲームライブラリcrisp-game-libを使ったミニゲームを最近たくさん作っているが、特に多く作っているのがワンボタンゲームだ。ここで言うワンボタンゲームは、レバーによる移動の他のボタンが1つ、といったものではなくて、純粋に1つのボタンしか操作に使わないゲームを指す。 ワンボタンゲームの利点は、操作が分かりやすく、タッチデバイスでも操作しやすい点にある。とにかく何かボタンを押せばそれがプレイヤーが取れる動作の全てであり、操作説明がほぼ不要である。またタッチデバイスでも画面中のどこかをタップあるいはホールドすれば操作ができるので、バーチャルパッドでよく起こる、ボタンを押した感触が無いので操作がしづらいという問題が発生しない。 欠点は、当然
自分は Ebiten という 2D ゲームエンジン (ゲームライブラリ) を趣味で開発しています。使用しているプログラミング言語は Go です。 2013 年 6 月に最初のコミットを行ったので、現在 8 周年の 9 年目です。 Ebiten は「くまのレストラン」などのモバイル及び Nintendo Switch 向けゲームで使われており、一定の実績があります。 ゲームエンジンの開発は一朝一夕では終わりません。Unity や RPG ツクールといった既製品がある中、ゲームエンジンをわざわざ自作することは酔狂かもしれません。ではなぜそのようなことをしたのでしょうか。端的に言うと「ミニマムな API で実用的な 2D ゲームが作れるかどうか」ということを証明したかったのです。自分の美的感覚の追求です。この目的に気づいたのは割と最近のことです。やっていくうちに「自分がやりたかったのはこういうこ
「タイムゾーン呪いの書」は、もともと 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 こ
こんにちは、スマートニュース株式会社の紀平です。 SmartNews のアプリ内では、最近 WebView を使った機能を多数公開しております。そのうちの一つにショッピングチャンネルという機能があるのですが、今日はそのショッピングチャンネルのタイムセール枠で以前発生した、謎のプチフリーズ問題の調査手法をご紹介します。 tl;dr 特定の Android 端末でプチフリーズが発生した 再描画領域を減らすことで現象は改善した Chrome の Tracing 機能を利用し、ブラウザのソースコードまで参照して、ついに根本原因まで突き止めた タイムセールで起こった問題 タイムセールは、SmartNews のショッピングチャンネル内において WebView で提供されている、期間限定のお得な商品をアグリゲーションした機能です。EC サイト各社のご協力の上にご提供しております。内部は HTML5 で開
更新日: 2020年8月14日 このページの目的 プログラマーは、クライアントから提供されたPDFファイルで、その要求を実現させようとしたとき、PDFのどんなところを見ているのでしょうか。このページでは、ちょっと珍しい視点でPDFファイルを解き明かしていきます。 自分でプログラムを書いてPDFファイルからテキストデータを取り出したいという人も、ぜひご一読ください。 はじめに PDFファイルをクリックすると、あたかも紙に印刷したかのように、どんなマシンでも同じような見た目で文章や画像がディスプレイに表示されます。 この単純な事実は、日常的にPDFファイルを利用していると当たり前に感じられるかもしれません。しかし、よくよく考えると驚くべきことです。 いったい、どのような仕組みがあれば、「過去から現在に至るさまざまな種類のコンピューターで見た目を変えずに同一の紙面を再現する」という目的を達成でき
はじめに みなさまはMacのメニューバーでネコを飼うRunCatというアプリをご存知でしょうか？CPU負荷に合わせて走る速度の変わるネコをメニューバー上に表示するだけというしょうもないアプリですが、現在では世界累計45,000ダウンロードを突破し、多くのみなさまに可愛がってもらえる定番アプリとなりつつあります。はじめは悪戯心で作成したジョークアプリが、思いもよらず高評価をいただけており大変嬉しいです。 一方で、Windows版がほしいとの声もちらほら聞こえるようになり、Windows版の模倣アプリも作られつつあることを知りました。そこで、ちゃんと本家からWindows版も出したいなぁと思い立ったが吉日ということで、格安でThinkPadを仕入れてWindowsアプリ開発に初挑戦してみました。 成果物 RunCat for Windows Windowsのタスクバー上に常駐し、CPU負荷に応
はじめに 現代では多くの人々がスマートフォンやタブレットを所持し、ゲームを楽しんでいることと思います。 モバイル向けのゲーム市場は大きく、世界では今も多くの開発者たちが iOS / Android 向けの商用ゲームを作っています。 さて、モバイルゲームの開発には、多くの開発者を悩ませるちょっと困った事情があります。 それは ディスプレイが非常に多くの多様性を持っている ことです。 正方形に近い形のタブレットもあれば細長い端末もあり、カメラがディスプレイの中に割り込んでいたり、 OS が専有する領域があったりと様々です。物理的な大きさもバラバラですね。 そのくせモバイル端末はタッチパネルで、ディスプレイに触れる UI になっているのです。 ゲーム開発を生業とする多くのエンジニア / アーティスト / ゲームデザイナーは、 これまでに何度も頭を抱えてきたことでしょう。 本稿では、2019 年現
たまに、今のこの状況は組織パターンに載ってたこのパターンだ、と思い出すことがある。数年前に読んでまだ役立ってる本のうちのひとつ。 今は「常に誰かが進捗させる」というプラクティスをやっている。それ自体はいいのだけど、問題なのは、チーム内チームのエンジニア二人チームでやっているので、一人が進捗させる、もう一人が差し込み対応する、という最小の形になっていること。 奥さんが家でやってる生け花教室のホームページを作る夫、みたいなものをイメージすると、奥さんが生花を教えることで進捗させて、夫がホームページ更新など雑務を巻き取るという構造をイメージできる。百人以上の人間がいる会社であっても、夫婦の生け花教室と同じ数の人のアサインでことを進めているのだとしたら、推進力では同じくらいしか出せないはず。実際には百人いる会社には経理の人がいたり総務の人が居たり、資本が潤沢にあったら良いパソコンを使えるとか、いろ
Webエンジニアを8年くらいやっていて、なんとなく、一通りのことはできるようになってきた。ただ、ちょっと得意な分野もあるとはいえ、基本的になんでも屋さんとしてやっているので、技術者としてのアピールがいまいちだなーというのが気になっている。そこで、技術者としての自分をアピールできそうな技術テーマを一つ選んで、それにじっくり取り組んで見ようと考えた。 しかし、取り組む技術テーマをうまく選ぶ自信がない。そこで、ちょっと作戦を考えて取り組む技術テーマを見つけようと試行錯誤してみたので紹介してみる。 ステップ1: 指標を考える やっていく技術テーマを見つけるにあたって、テーマの候補をスコアリングしてみることにした。漠然とスコアをつけるのは難しいので、自分が普段技術テーマに取り組むかどうかを考えるときに気にしていることを思い出して、5つの指標に分解してみた。 指標1: 自分の興味 自分がおもしろい、や
11. ● デザインはiOSのものが提供される ○ 必要なリソースはiOS版からもらってくるのでコスト減 ○ ビジネスロジックはiOS版コードを閲覧でできる ● 画面遷移等の仕様がはっきりしているので、仕様策定にか かる時間を削減できる ● SNSは指定ハッシュタグで投稿するだけ すでにiOS版が存在する
PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい
これからのCSSはmargin禁止！？CSSグリッドレイアウトやコンポーネント指向なCSSについて、矢倉さんに聞いてきた！ 白石 俊平（HTML5 Experts.jp編集長） こんにちは、編集長の白石です。 この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。 今回お話を伺ったのは、ピクセルグリッドの矢倉眞隆さんです。 矢倉さんのセッション「まあまあ最近のCSSとつらくならないための書き方」に関するスライド資料は、こちらで公開されています。 インパクト大！CSSグリッドレイアウト概要 白石: では、まずは簡単に自己紹介をお願いできますか？ 矢倉: 昨年（2
まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。 原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。 実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます（知っている世間が狭いだけかもしれないけど）。 とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。 そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。 もちろん、同じソフトウェア開発でもプロジェクト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
