タグ

ブックマーク / labs.gree.jp (22)

  • モバイルゲームにおけるマスターデータ運用事例 | GREE Engineering

    こんにちは。Wright Flyer Studios部のにしだ(@hosi_mo)です。LINE タワーライジングのメインプログラマを担当しています。 こんかいは趣向を変えて、“モバイルゲームにおけるマスターデータ運用事例"という題で、タワーライジングでのマスターデータの運用まわりについてお話しいたします。 ゲームの実装はこちらを参照ください。slideshare : http://www.slideshare.net/greetech/towerrising ※この投稿は GREE Advent Calendar 2015の18日目の記事です。 マスターデータとは マスターデータとは、ゲーム内で不変の共通パラメータ群のことを指します。モバイルゲームにおいては、アプリのバイナリアップデートをせずにゲームに反映できるよう、起動時に最新のマスターデータを引っ張ってくることが多いです。Excel

    モバイルゲームにおけるマスターデータ運用事例 | GREE Engineering
  • Cocos2d-x で 3Dフライトアクションゲームを作ってみた - アメリカでの研修を通して | GREE Engineering

    GREE Advent Calendar 2015, 13日目です! whoami はじめまして、奥畑と申します。 新卒入社からの2年半で、プラットフォームの運用、Webゲームの新規開発・運用に1年ずつ携わり、現在は北米支社と共同で Nativeゲームの運用に携わっています。 私はこの夏、グリーが資業務提携している米Make School社によるアプリ開発者養成講座に、新卒1~4年目の社員8人で参加してきました。世界中から300人ほどの高校生・大学生が集まり、2ヶ月間のカリキュラムの中で、前半3週間は iOSアプリやゲームの作り方を学び、 後半5週間で各々オリジナルのアプリやゲームを作り App Store にリリースするというもので、我々はグリー専用コースとして Cocos2d-x によるゲーム制作を行いました。 その中で私は 3Dフライトアクションゲームを作りました。iOS (ついで

    Cocos2d-x で 3Dフライトアクションゲームを作ってみた - アメリカでの研修を通して | GREE Engineering
  • CPUに関する話 | GREE Engineering

    こんにちわ。せじまです。スティック型PCの購入は、 Core M版が出るまで見送ろうと思っている今日このごろです。 弊社では「Mini Tech Talk」という社内勉強会を隔週で開催しているのですが、それとは別に、「Infra Tech Talk」という社内勉強会を、半年くらい前から毎月開催しています。わたしはそこでほぼ毎月、45-60分くらいのスライドを作って話をしています。今までどういう話をしてきたかといいますと、TCPに関する話を二回、SSDに関する話を二回しました。(InnoDBに関する話だと軽く5-6時間くらいできるんですが、いささかマニアックなので、もっと幅広い人を対象に話をしています) 今までの話はちょっと社内向けの内容だったんですが、前回開催された Infra Tech Talk では、社外の方にも幅広く読んでいただける話ができたと思いましたので、その資料を slides

    CPUに関する話 | GREE Engineering
  • 男性エンジニアリングマネージャが長期育休を取った話 | GREE Engineering

    こんにちは、Data Engineering Groupマネージャのmoritaです。 このエントリはGREE Advent Calendar 2014 9日目の記事になります。 今日は、今年前半に半年間の育児休業を頂いたので、そこで感じた事を書こうと思います。会社に育休制度はあるし家族も育休取得に好意的、だけど周囲の眼や復帰後のキャリアが気になる、という方の背中を少しでも押すことができればいいなと思っています。 エンジニアブログなので、エンジニアの視点から見た育休、特に育休エンジニアキャリア/エンジニア組織の関係性についても書ければと思います。 育児休業のあらまし まず始めに育児休業の概要を説明します。 育児休業は育児・介護休業法により定められています。法律により、従業員は労使協定で定められた条件(典型的には勤続1年以上という条件が付くようです)を満たす場合に育児休業を取得できることに

    男性エンジニアリングマネージャが長期育休を取った話 | GREE Engineering
  • イノベーションが失われた組織から脱却する10のルール | GREE Engineering

    こんにちは! ガレージスタジオ部  岸田崇志です。 記念すべき『GREE Advent Calendar 2014』1日目の記事となります! GREE Engineers' Blogを書くことに憧れて入社したのですが、5年半経ってようやく夢が叶い感慨深いです。 と、前置きはさておき、題に入らせていただきます。 ここ数年大ヒットが生み出せていないグリーですが、会社が大きくなる中でゲームが作りにくい組織になっていました。 そこで、その課題と現在行っている取り組みについて紹介させて頂きたいと思っています。 めっきりクリエイティブなイメージが薄くなってきたグリーかなと思っているのですが、 「グリーらしくない!」と言われるゲームを作ることが私の狙いの一つでもあります。 過去の自分を振り返り会社が大きくなる中で、自分自身の至らないところもあり以下の様なケースがあったかと思っています。 今までの課題事

    イノベーションが失われた組織から脱却する10のルール | GREE Engineering
  • エンジニアリングのマネージメント | GREE Engineers' Blog

    こんにちは、岡崎です。最近はグリーのインフラチームにおける開発のマネージメントを担当しています。 このエントリーは「GREE Advent Calendar 2014」2日目の記事です。昨日は岸田さんによる「イノベーションが失われた組織から脱却する10のルール」でした。 さて、気がつけばここに書くのも昨年のAdvent Calendar 2013「開発ワークフローを、いつどう変えるか」以来です。去年は開発プロセスについてやってきた事の振り返り記事でしたが、今年も同じようにこれまでのプロジェクトを振り返りながら今回はエンジニアリングのマネージメントについて考えてみます。 エンジニアリングマネージャーとはどのような責任を持っているか エンジニアリングマネージャーとはどのような責任を持った役割でしょうか。題に入る前にまずは「責任」という言葉の定義について確認しておきます。 「責任」と一言で言う

    エンジニアリングのマネージメント | GREE Engineers' Blog
  • リアルタイム・ランキングを考える | GREE Engineering

    はじめに こんにちは。プラットフォーム開発部のsp1rytusと申します。 先日、私もついに30歳のおっさんになってしまいました。加齢臭が出ないようにがんばります! ランキングって? ランキングは誰でもわかる、何らかの得点をソートして順位位置を決定する凄く簡単でシンプルなものです。しかし、ゲームを扱うコンテンツ・サービスにおいては、得点を通算/日別に順位付けされたものが直ぐに目に入るように、他人と自分を比較する非常に重要な役割を果たしています。そこで、この記事では次の3つ要件を満たすようなランキング・システムの難しさと、それを解決するための一例を簡単に説明させて頂きます。 順位付けはリアルタイムに行い、集計時間を必要としない。 100万件以上の得点データが扱える。 すべてのデータが正しい順位付けで取得できる(線形補完などで順位を概算しない)。 リアルタイムによる正確な順位付けは、データ件数

    リアルタイム・ランキングを考える | GREE Engineering
    n-sega
    n-sega 2014/12/25
    リアルタイムランキング
  • オンラインゲーム開発のいにしえの技術 | GREE Engineering

    開発部の堀口です。昨年は git による分散作業パターン を書き、つい先月は 札幌での講演 を行い、当文章ではゲーム開発の設計に関するネタです。 昔話交じりのポエムですが20日目としてよろしくお願いします。 オンラインゲームとは 20 年ちかく前に Quake というゲームがリリースされ、一見すると単なる一人称視点のシューティングゲームにしか見えないが、プレイヤー自身の Quake の世界を公開し、来場者と遊ぶことができた。当時でいえば、自分のホームページに CGI 掲示板を設置するのと似ていたと思う。 Quake は、ゲーム世界のふるまいと世界の変化を伝える入出力が非常に良く分離されており、参加するプレイヤーはその世界の中に現れた自分の分身となるアバターの行動のみを制御し、アバターの目の代わりに世界の変化を、わずかな情報にしてプレイヤーに伝えた。プレイヤーの目の前にある端末では、その情

    オンラインゲーム開発のいにしえの技術 | GREE Engineering
    n-sega
    n-sega 2014/12/21
    [[greasemonkey][design]
  • よくわかるLinux帯域制限 | GREE Engineering

    矢口です。 みなさんはLinuxのtcという機能をご存知でしょうか。送信するパケットの帯域制御を行うことができる大変強力な機能で、グリーでもいくつかの用途で使用されています。 具体的な事例の一つはRedisです。Redisではreplicationを新規に開始する際やfailoverが発生しmasterが切り替わった際(特に2.6系)にストアされている全データが転送されます。しかし帯域制限をかける機能がないため、ネットワーク帯域を圧迫してしまう危険性があります。また通常のクライアントとの通信でも大量のクエリにより予想以上の帯域を使用してしまう可能性があります。このような場合にtcを用いることでRedisの使用する帯域をコントロールできます。 このように有用なtcですが残念なことに日語/英語ともにわかりやすい解説や詳細な情報は多くありません。 私も社内において使われていたtcの設定に問題が

    よくわかるLinux帯域制限 | GREE Engineering
  • CTOとはなんなのか、あるいはエンジニアの生存戦略 | GREE Engineering

    Merry Christmas! GREE Advent Calendar もいよいよ最終日、25日目はグリー株式会社でCTOをしておりますふじもとがお送りします。 今日まで24人のGREE Engineersなみなさまにエントリを書いていただいたわけですが、思ったよりも多種多様な内容で、あらためていろいろな方面で素敵なエンジニアがいるなー、としみじみしてしまいました。いやしかしgitとchefの記事人気ですね、そして、「当然CTOはすごい記事書くんですよね」とプレッシャーをかけて楽しむ仲間たちに囲まれてぼくは幸せです、あーすごい幸せー。そんなプレッシャーの中、今までのエントリとはちょっと方向性を変えて、CTOの話でも書いてみようかと思います。なお、ぼくの趣味は多分問題解決です。 そんなわたくしふじもとは来年で、CTOっていう肩書きでお仕事をはじめて10年とかになるんですが、なかなか先輩と

    CTOとはなんなのか、あるいはエンジニアの生存戦略 | GREE Engineering
  • グリーのインフラに Chef を導入した話 | GREE Engineering

    類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件(ランリストやノードのアトリビュート(以下、「アトリビュート」)などの組み合わせ)でテストを行っています。 また、一部仮想マシンを使う必要がないテスト(att

    グリーのインフラに Chef を導入した話 | GREE Engineering
  • git による分散作業パターン | GREE Engineering

    分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o JavaC++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした

    git による分散作業パターン | GREE Engineering
  • ImageMagick 改造入門 (その弐) 減色処理前編 | GREE Engineering

    こんにちは。クライアント基盤チームのよやです。 アバター等を表示する為に PNG や JPEG の画像を元に GIF アニメーションを生成する事がよくありますが、GIF は 256色までしか扱えない為、元画像が数万といった単位で色を使っていると減色処理に大変時間がかかります。そこで、ImageMagick の減色処理を改造して高速化した事例をご紹介します。 尚、一度に読む分量ではまとめ切れない為、前編と後編に分けました。前編は減色処理、後編はその改造について説明します。 プログラム構成では上の図の magick/quantize.c が減色処理に相当します。 まず、減色処理の一般的な話から始めます。 減色の利点 Web で見かける画像ファイルの多くは、1つのpixel(描画の最小単位)に対して、Red, Green, Blue が各々8bits で計 24bits(= 3bytes) 、透

    ImageMagick 改造入門 (その弐) 減色処理前編 | GREE Engineering
  • GREE Engineer's Blog coming soon...

    コンテンツへスキップ ナビゲーションに移動 Slackオートメーションプラットフォーム(次世代プラットフォーム)でSlackアプリを作ってみた新着!!2024/05/28hagiwaramasaru Slack情報システム部 こんにちは。情報システム部の萩原です。皆さんはSlackオートメーションプラットフォーム(少し前までは次世代プラットフォームとも呼ばれていました)をご存じでしょうか。2023年4月に正式リリースされ、端的に言うと、これま […] 新卒1年目の実体験から学んだ新卒の心構え2024/03/29hidakatakumaこんにちは! グリーでインフラエンジニアとして働いている日高です。 今回は、就活生に向けて、新卒エンジニアとして1年間取り組んだタスクの1つとそのタスクを通して気づいたことを紹介します。そして、これらのことを通して、私が […] 非エンジニア女子がRails

    GREE Engineer's Blog coming soon...
  • PNG軽量化の減色と圧縮について | GREE Engineering

    このテーブルの番号は 1 Byte になっているため、0-255 の 256 個しか登録できません。そのため、画像で使用されている色が 256 個より多い場合は、なんとかして 256 個にしなくてはいけません。 この「なんとかして 256 色にする」というのが減色処理で、なるべく元の画像からの変化を分からないようにしながら色を減らしていくためのアルゴリズム実装です。(この記事では減色アルゴリズムについての説明は省略します。) テーブルを作成したら、画像のそれぞれのピクセルを RGB 形式からテーブルの何番目の色を使うかに置き換えます。 上図のように、1 ピクセルあたり 24bit 必要だった画像が 1 ピクセルあたり 8bit になったので、データサイズは大体 1/3 になります。 (パレットのデータに最大 3 Byte * 256 = 768 Byte 必要とか、同じように圧縮されないと

    PNG軽量化の減色と圧縮について | GREE Engineering
  • ImageMagick 改造入門 (その壱) GIFアニメーション | GREE Engineering

    こんにちは。ミドルウェア開発チームのよやです。 今回は、ImageMagick についてお話します。 http://www.imagemagick.org/ ImageMagick は高機能で大変便利な画像処理ツールです。弊社でも利用させて頂いていますが、稀に実サービスにそのまま適用出来ないケースがあります。 そこで、困った時に ImageMagick 自体を改造する際のポイントと、実際の応用例をご紹介します。 ImageMagick のプログラム構造 ImageMagick のプログラムは主に以下のディレクトリに分かれます。(Magick+ ディレクトリ等幾つかは割愛します) utilities/<コマンド名>.c コマンドラインツールの起点(main 関数) wand/〜.c (コマンド共通処理とコマンド毎の処理、Wand API) magick/〜.c (機能モジュール、ユーティリテ

    ImageMagick 改造入門 (その壱) GIFアニメーション | GREE Engineering
  • 本当に結構パーフェクトでした - 書評「パーフェクトPHP」 | GREE Engineering

    最近はWebSocketで遊びたくてしかたがないfujimotoです、こんにちは。今回は、日(2010/11/12)発売されている(はずの)待望の書籍、「パーフェクトPHP」の書評をお届けします。 僕は今週ひと足お先に献をいただいて目を通したのですが、様々なPHP関連の書籍で「こういうことにも言及してほしいなぁ」「このサンプルを鵜呑みにされてしまうと困るかも...」というところをきちんとカバーしていたり、最新版の仕様や、PHPを使い倒しているユーザの考え方が反映されていて、今までにない書籍だな、というのが第一印象で、初心者のかたから上級者のかたまで、全員が買って損はない(少なくとも、書店で手にとってみる価値はある)一冊だと思います。 これは、いずれもPHPのヘビーユーザであり、よいところもわるいところも知り尽くしている著者のかたがたが、執筆するにあたって最初に考えたであろう「既にPHP

    本当に結構パーフェクトでした - 書評「パーフェクトPHP」 | GREE Engineering
  • Gree Fast Processor: PHPを3倍(くらい)速く | GREE Engineering

    ごあいさつエントリだけというのもなんなので、引き続きfujimotoです。実質上1つめのような気がするこのエントリでは、PHPが3倍くらい(少なくとも2倍くらいは...)速くなるGree Fast Processorというのを先月作ってみたのでご紹介です。 すぐわかるまとめ Gree Fast Processorというのを使ってみると、シンプルなsymfonyのプロジェクト(xav.ccで試しました)でも2倍弱、結構複雑なアプリケーションだと7倍くらい速くなったりします。いくつかの制約がありますが、パフォーマンスに飢えているかたはお試しください。 こちらはなんかすごい速くなっている感じのグラフ(一番上が速くなった版のRequests per Second、赤が通常版のRequests per Second): これはさすがにbest caseすぎる気がしますが、普通にやっても2倍弱くらいは

    Gree Fast Processor: PHPを3倍(くらい)速く | GREE Engineering
  • GREE Engineering

    404 お探しのページは見つかりません GREE Engineering トップへ戻る

    GREE Engineering
  • 第1回 サイバーエージェント×グリー合同勉強会 〜合同勉強会の作り方〜 | GREE Engineering

    はじめまして。GREEの開発部の吉川(@tsuyoshikawa)と申します。 普段は内製のソーシャルゲーム開発を中心とした開発業務を行っています。 一ヶ月前くらいの7月27日(水)に、クローズドな開催ではありますが、株式会社サイバーエージェント様(以下敬称略とさせて頂きます)と合同技術勉強会を開催しましたので、レポートさせていただきます。 合同開催に至った経緯やその進め方といった、GREEなりの「合同勉強会の作り方」を公開してみたいと思いますので、ご意見や反響を頂くこと、あわよくば「GREEと合同勉強会やりたい!」という声を頂くことがエントリのねらいでございます。 なお、このエントリはサイバーエージェントエンジニアブログと相互リンクさせて頂いていますので、こちら「あわせて読みたい」ということでよろしくお願いいたします。 ⇒サイバーエージェント 公式エンジニアブログ また、勉強会の当

    第1回 サイバーエージェント×グリー合同勉強会 〜合同勉強会の作り方〜 | GREE Engineering
    n-sega
    n-sega 2011/09/08
    エンジニアっていうくくりで純粋に交流もてるからすごい楽しそう。