ゲームボーイで動くゲームが作れる「GB Studio」作品6選 – もぐらゲームス
携帯型ゲーム機の金字塔である任天堂「ゲームボーイ」。『テトリス』『星のカービィ』『ポケットモンスター』など現在にも脈々と続く数多くの名作が生み出され、乾電池のみでも動作することから世界中で親しまれた名機である。市場での役目を後継機達に譲った後も電子音楽の音源としての役割を見出されるなど、愛好家たちの手によって様々な形での活用が続いており、近年では個人・同人によるゲームボーイ用ゲーム作品の開発が加速している。その立役者となっているのが今回紹介する「GB Studio」の存在だ。 「GB Studio」とは 「GB Studio」はChris Maltby氏が開発し、2019年4月より公開されているゲームボーイ向けの開発環境。Maltby氏がゲームボーイ風のゲーム作品『Untitled GB Game』を自作するにあたって用意した開発環境が元となっている。見下ろし視点型のアドベンチャーゲームを
「アジャイル型開発プレイブック」を公開しました –
東京都は、都政の構造改革「シン・トセイ」を進める中で、確認と改善のプロセスを絶えず繰り返す「アジャイル」を改革実践のキーワードの一つとしています。 これを都庁内にしっかりと定着させていくため、2022年度から、デジタルサービスの「アジャイル型開発（※）」に取り組んでいます。 この度、これまでの実践の様子や職員たちの気づきなどを記録した「アジャイル型開発プレイブック（※）」を公開しました。ぜひご覧ください！ （※）アジャイル型開発とは、 「顧客にとってより良いものにするために、見直しすることを躊躇しない開発手法のこと。 またそのマインドセット、および価値観のこと。」とされており、 システムの世界では、「迅速かつ柔軟に」開発ができる手法として注目されています。
アジャイルリーダーシップの実践 - 権力ではなく影響力でアジャイルな組織をつくるために【対談】 - Agile Journey
「アジャイルリーダーシップは、これからのリーダーシップです」 変化の速度が速まり、また、複雑化した現在のビジネス環境に適応し、価値を創出し続ける組織であるためには、旧来的ではない、新たなリーダーシップが必要になる。 こう説く書籍『アジャイルリーダーシップ』が2022年秋に刊行されました。著者であり高名なアジャイルコーチであるZuzana Šochová（ズザナ・ショコバ / @zuzuzka）さんは、自身の経験と多くの情報を融合し、変化に適応するアジャイル組織を形作るうえで重要な要素である、アジャイルリーダーシップを具体化し、それを体現するために必要なコンピテンシー（行動特性）やエクササイズを同書にまとめました。 書籍で語られる、アジャイルリーダーシップの価値はどこにあるのか、組織内で浸透させるための課題は何か、いかにして現場で発露するか。こうした「アジャイルリーダーシップの実践」を、同書
Mermaid flow
Mermaid Flow is an online Mermaid JS editor that takes this a step further and simplifies the creation and maintenance of your Mermaid Diagrams. Mermaid Flow generates Mermaid JS code which can be rendered directly in GitHub README's and also stored and version controlled in code. This app makes it easy to create Mermaid JS diagrams with its visual and interactive editor, so you get the stability
SSO（スクラム知らないおじさん）がスクラムチームにやって来た - ぐるなびをちょっと良くするエンジニアブログ
はじめまして、ぐるなび仕入モールでバックエンド開発を担当している中村です。2020年度に中途入社し、それまでは主にウォーターフォールモデルでの開発に携わっておりました。 今回はそんな スクラム知らないおじさん（以降、SSO）から見たぐるなび仕入モールチームのスクラム開発をご紹介できたらと思います。 この記事で書いていること この記事で書いていないこと 何を作っているか 現在のチーム構成 プロダクトオーナー スクラムマスター 開発メンバー 開発のサイクル プランニングからリリースに至るまで スクラムイベントのスケジュール ウォーターフォールとのフロー対比 何やらカタカナが多い 工数算出をどう行なっているか プランニングポーカー 数値の一律設定型 Tシャツサイジング（今ココ） 最後に この記事で書いていること スクラムを用いてチームで開発にどう取り組んでいるかをご紹介しています。主に、 スクラ
1年を超える長期プロジェクトを30人超でふりかえりした話（前編） 〜プラクティスの選択〜
新規プロダクトや大きな機能のリリース、大規模リニューアルなど、長い時間かけて行うプロジェクトは少なからず発生します。 みなさんは、そのようなプロジェクトのふりかえりは上手く行えていますか？また、オンラインでのふりかえりはどのように行っていますか？この記事では、長期間のプロジェクトに対するふりかえりの方法を、どのように準備して行なっていったかをご紹介します。 今回のふりかえり会の全体像 今回のふりかえりではmiroを用いて下記の流れで行いました。それぞれのプラクティスの内容については、本記事で説明します。 ふりかえり事前会アジェンダ 参画時期の共有（プラクティス1） 起こったことの共有（プラクティス1） ふりかえり本会アジェンダ 本日のチャレンジ宣言（アイスブレイク） 良かったこと、気になったことを共有（プラクティス1） インタビュー×3（プラクティス2） 課題の狙いを定める（プラクティス3
プロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行する - $shibayu36->blog;
プロジェクトマネジメントにおいて、見積もりをどのように行うかは結構難しい。僕は理想日見積もりの形式も、相対見積もり(ストーリーポイント)の形式も試したことがあるが、どちらも一長一短であった。 最近色々試す中で、プロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行するという方式がやりやすいと感じた。今回はその様子を紹介してみる。 理想日見積もりと相対見積もりそれぞれのメリット・デメリット 見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察の記事を読むと、理想日見積もりと相対見積もり(ストーリーポイント)それぞれのメリット・デメリットがさっと把握しやすい。自分としては、それぞれ以下のように思っている。 理想日見積もり : 他の割り込みが全くなく、1日中タスクに取り組んだ場合を1理想日とする見積もり方式 メリット: 他に基準となるタスクがなくてもとりあえず雑に出せる。相対見積
ジャンル別ゲームの作り方 （2Dアクション・2Dシューティング）｜しゅん
今回はゲームジャンル別に、そのジャンルを代表する要素の作り方を紹介したいと思います。 ◾️シューティングゲーム シューティングゲームの基本的な面白さは、おおよそ以下の通りになるかなと思います。 * 動き回る敵を狙って倒すのが面白い * 自機がパワーアップして敵を蹴散らすのが楽しい。もしくはパターンを覚えて効率よく敵を倒す * 大量の敵弾をくぐり抜けた時のうまく操作した感、達成感こういった面白さを実現するために、シューティングを作る場合、たいていは以下のステップでゲームを作ることになるかと思います。 (※１つの例です） 1. 自機の実装: 自機の表示・操作・画面からはみ出ないようにする 2. 自弾の実装: 自機から弾を発射する。弾が画面外に出たら消える 3. 敵の実装: 敵の表示。自機や自弾と衝突したらお互いに消える 4. 敵弾の実装: 自機に敵弾が当たったらゲームオーバー 5. アイテムの
よくわかる音ゲーの作り方
◆プランナー向けの本 全国書店、またはネットで発売中。 「アプリ＆ゲームプランナー必読！レベルデザイン徹底指南書」 2786円(税別) 翔泳社 http://bit.ly/LevelDesignManual 「アプリ・ゲームプランナー完全マニュアル」 全国書店、またはネットで発売中。1900円(税別) 宝島社 http://bit.ly/GamePlannerPerfectManual ゲームプランナー向けのブログ「あなたの町のゲーム屋さん」 http://gameplanner.blog.jp/ update info ・ver.1.2.0 細かな調整と新著の宣伝追加。（2016.12.18） ・ver.1.1.7 細かな調整。（2015.01.15） ・ver.1.1.6 細かな調整。（2014.10.19） ・ver.1.1.5 ゲーム本の詳細を後半ページに追記（2014.09.23
企画を元にゲームのUIを作るときの流れ｜tkm
「Game Graphic Design Advent Calendar 2019」の初日の記事です。 ゲーム制作に関する素敵な記事がたくさん公開されると思いますので、私自身もワクワクしてます。 言い出しっぺとして、初日としてまず何を書こうかなと思ってたんですが、以前Twitterでチラッとつぶやいた「普段ゲームUIを作るときってどういう工程があって、どういう流れで作っているか」をまとめてみたいと思います。 というのも、いろいろな方から「何から手を付けていいのか…」「デザインが上手くまとまらない」「デザイナーが社内外注みたいになってしまって…」みたいな話をよく聞きまして。 そのアンサーになるかは分かりませんが、自分の場合はこういうフローで、こういうことを意識してますよ。というのを書いてみたいと思います。 もちろん組織や人によってやり方は様々だと思いますので、こんな風にやってる人もいるんだ、
「技術的負債とはどういうものなのか？」をテトリスに例えるとこうなる
テトリスは落ちてくるテトリミノを積み上げ、横一列に並べて消すという有名なゲームですが、そのテトリスを例に「技術的負債」がどういうものかたとえた記事を、エンジニアでありコンサルタントでもあるというエリック・ヒギンズ氏が公開しています。 Technical Debt Is Like Tetris – Featured Stories – Medium https://medium.com/s/story/technical-debt-is-like-tetris-168f64d8b700 「技術的負債」とは、ソフトウェアの開発において、時間がかかるより良いアプローチではなく一番早く新機能の実装などの目的を達成できるアプローチを選んでしまったために生じたソフトウェアの複雑さのこと。例えば既存の機能を変更した際に説明書を書きかえなかった場合、後から別の人が動作を把握するにはソースコードを読む作業が
『ベヨネッタ2』開発を陰から支えたオートプレイ機能とパフォーマンス計測 CEDEC＋KYUSHU2016 - AUTOMATON
「仕事をしたくないでござる、コードを書きたくないでござる」。実は優秀なプログラマーに必須の資質だ。画面を点描で埋め尽くせと言われて、素直にマウスをクリックし続けるのがアーティスト。スクリプトを組んで作業を自動化するのがプログラマーだともいえる。 プラチナゲームズでQAエンジニアをつとめる森田和則氏も、「プログラムを極力書きたくないのでプログラムを必死に書き続ける」のだという。CEDEC2016で行った「『ベヨネッタ2』におけるゲーム品質を上げる為の自動化～オートプレイと継続的なパフォーマンス計測～」も、そうした森田氏ならでなの思想に裏打ちされたセッション。聴講者から高い評価を受け、「CEDEC＋KYUSHU2016」でも招待講演が行われた。 なお本セッションの講演資料はCEDECの資料サイト「CEDIL」で公開されている。CEDILはメールアドレスを登録すれば誰でも無料で活用できるので、ぜ
コードレビューで気をつける言葉や行い - macotox’s blog
コードレビューにstashを使ってます。 こいつはgitのブランチ間の差分に対してコメントをつけることができるツールです。 ただ、ネットを介したコミュニケーションって何故か気が大きくなってしまったり、感情が見えづらかったりで誤解を生みがちです。 特にコードレビューって間違いを指摘するとかあんまり楽しい会話をするわけでもないので、言葉には気を使わないといけません。 今日は自分が気をつけている言葉や行いを上げてみます。 否定しない def get_name(name) @user.find(name: name) end ☓：getは軽量なアクセッサとして使うのが常識なのでやめて下さい。 ◯：findしてることが分かるメソッド名が良いです いちいち否定する必要はないです。素直にどうして欲しいか書きましょう。 否定しない2 「けど〜」 def search(name) @user.find(na
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
ネイティブ開発アンチパターン
Desarrollo de módulos en Drupal e integración con dispositivos móviles
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
iTerm2 + zsh + tmux + vim で快適な256色ターミナル環境を構築する - ( ꒪⌓꒪) ゆるよろ日記
こんにちわ。債務者ことゆろよろです。家買いました。 さて、最近こんなまとめが話題になりました。自分もコメントしましたが、すごい情報量になってます。 これ知らないプログラマって損してんなって思う汎用的なツール #JavaScript #PHP #Ruby #Python #HTML - Qiita 【まとめ】これ知らないプログラマって損してんなって思う汎用的なツール 100超 #PHP #JavaScript #Python #Ruby #HTML - Qiita で、自分のコメントにも書いたのだけど、基本的に仕事はターミナルでssh接続して、Vimでコード書いてるので、この辺の環境構築についてまとめてみた。最近Terminal.appからiTerm2に移行して、screenからtmuxに乗り換えたので、その辺も含めて導入方法を書いておく。 手元の端末はMBPでOSX Lionだけど、ほぼ同
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デイリースクラムいらなくなくなくなーい！？
ゲームサーバ開発現場の考え方
Quicksilver — LoveQuicksilver Blog