約 185,122 件
https://w.atwiki.jp/teitoku_bbs/pages/6422.html
885: 弥次郎 :2020/09/25(金) 23 01 03 HOST p1537109-ipngn14201hodogaya.kanagawa.ocn.ne.jp 憂鬱SRW 未来編鉄血世界 証言録「いかにして彼女は王座に座したか」 「残念です、アリウムさん。あなたとはここでお別れのようです」 「こ、この、小娘が…!売女…!火星を売り渡す気か!商人なんぞに!誰がお前を引き上げたと思って……!」 「……考えや立場が違うと分かったのはお互いにとって幸運でしたね。それでは」 クーデリア、恩師であり恩人ともいえるアリウムと決別。具体案のないままに企業連に反発するアリウムを見限った。 「では、行ってまいります、お母様」 「……ええ、気を付けて。あの人のところへは?」 「娘を売った父に、何を話せばいいのですか?哀れみを見せればよいのでしょうか?」 「…そうでしたね」 母である朋巳・バーンスタインとの出発前の別れ。屋敷の外を知らぬ母でさえ、状況の、娘の立場の変化は知るところとなった。 「ノブリス・ゴルドンとはすでに話はついています。さあ、行きましょう」 「は、はい……しかし、どうやって?」 「知らないほうがいいわ、フミタン」 すでにノブリスが書類上の存在となったことを知らぬフミタンと、それを知るクーデリア。 「え、アンジェラ、あなたMSを動かせるの?」 「一通りの技能についてはインストール済みです。クィン・マンサ・メスラムタエアとイシス・ヴィルゴーの両方とも。 ドライバーはお任せくださいませ」 「まるで車の運転手をやるように気軽に言うのね…」 「恐れ入ります」 クーデリア専用MSのドライバーは、アンドロイドのアンジェラに一任されることに。この後無茶苦茶訓練した。 「火星連合首相にはクーデリア・藍那・バーンスタイン君が選出されました」 「皆さん、どうかよろしくお願いしますね?」 火星連合暫定議会にて、火星連合首相に任じられるクーデリア。半ば出来レースであったが、彼女は火星の代表者となった。 「名刺がすごいことになったわね……」 「お嬢様が、それだけ重要人物になったということかと」 「フミタン、そんな他人事みたいに…」 「私としては、とても遠いところに来てしまったような気がしてなりません……」 用意された名刺に並ぶ膨大な肩書をみて、フミタンとクーデリアの会話。 「実務に集中したいのに……!」 最高権力者となったクーデリアへは火に集まる虫のごとく、猟官やら陳情やら賄賂やら様々な人間が接近してきて、さすがのクーデリアも怒りを隠せず。 886: 弥次郎 :2020/09/25(金) 23 02 03 HOST p1537109-ipngn14201hodogaya.kanagawa.ocn.ne.jp 「彼女、ちょっと覚悟が決まりすぎているんじゃないかしら…」 「もともとそれだけの器の持ち主だから、不思議はない」 「すごいなぁ」 セントエルモスのリンクスたち、火星連合暫定議会でのクーデリアの所信表明演説を聞きながら。 「……つまり、単なる独立運動家じゃなくて、火星のトップってわけか」 「火星で一番権力を持つ乙女ってもう噂になっているね」 「おいおい……仕事がでかくなりすぎじゃねぇか」 「やることは変わんないでしょ、オルガ?」 「そ、そうだな……(胃がいてぇ……)」 鉄華団の面々の会話。最初の依頼からクーデリアの立場は飛躍的に変化していた。オルガはこの後胃薬をもらいに行ったという。 「社長、またです」 「おいおい、ここは単なるPMCだぞぉ…クーデリアへの取次はやってないって伝えてくれよ」 「一向に聞いてくれないのです」 「しょうがねぇ…脅していい、追い払え!こっちの営業妨害をしているんじゃねぇってな!」 どこから情報が漏れたのか、クリュセのCGSにはクーデリアに会いたいという陳情の列が出来上がることに。 「気心地はいいけれど……」 「はい。最先端の要人用のドレスとなっております。仕様書はこちらに…」 「……これ、戦争に使うわけじゃないのよね?」 「もちろんでございます。ですが、何を使ってくるかわかりませんので」 アルゼブラからクーデリアに贈られたプロテクトドレスをみてクーデリア。外見こそ美しいが、戦闘用そのものであった。 「いいスーツだな…」 「団長、これ全員にあるの?」 「当たり前だろ?下手な恰好じゃ示しがつかねぇ。 ちゃんと手入れの仕方も着こなしも教えてもらって来いよ」 「はーい…」 鉄華団にも支給されるSP用のプロテクトスーツ。年少組から年長組まで数着ずつ支給されることに。 「遊び道具にするなよー」 「わかってまーす!」 「……ま、無理だよなぁ」 「痛い目に合うのも子供の特権だ。遊びでも慣れてくれればそれでいいさ」 宇宙での無重力区画移動用のワイヤーガンを支給された年少組と、エウクレイデスの大人たちの会話。 887: 弥次郎 :2020/09/25(金) 23 02 38 HOST p1537109-ipngn14201hodogaya.kanagawa.ocn.ne.jp 以上、wiki転載はご自由に。 出てきた用語とかは後々解説しますね。
https://w.atwiki.jp/wiki11_sirokuma/pages/38.html
達人プログラマー―システム開発の職人から名匠への道 達人の哲学 割れた窓を放置しておかないこと 悪い設計、間違った意思決定、質の悪いコードを放置すると、そこから崩壊していく。 大きな構想を忘れないようにすること 小さな変化から崩壊が始まる。 品質要求を明確にすること 十分によいソフトウェアを作る。やりすぎない。 伝達しよう 聞き手を理解するための合言葉 WISDOM W what 聞き手に何を知ってほしいのか I interest 言いたいことの中の聞き手の興味は何か S sophisticate 言いたいことはどれくらい洗練されているか D detail 聞き手はどの程度詳細を知りたがっているのか O own 誰に知ってもらいたいのか M motivate 聞いてもらうためにはどうするのか 達人のアプローチ 二重化の過ち DRY Don t Repeat Yourself 繰り返しを避けること 再利用しやすいようにしておくこと 直交性 関係のないもの同士の影響を排除する → コンポーネント間の依存度を下げる 可逆性 DRY原則、結合度の最小化、メタデータの使用ーによって可逆性が高まる 曳光弾 まず最小限度のすべての機能が動作するコードを作成し、修正、肉付けを行う プロトタイプ 特定の機能についての詳細を作成する 専用の言語 ユーザーの問題領域に近いところでプログラミングを行う。 ミニ言語を作成する。 見積もり システムをモデル化する → コンポーネントに分割する → コンポーネントを見積もる コーディングによりスケジューリングを繰り返す 基本的なツール プレーンテキスト データはプレーンテキストに保存すること シェル遊び コマンドシェルの力を使うこと パワーエディット ひとつのエディタを熟知すること ソースコード管理 常にソースコード管理を使用すること デバッグ 非難しないこと パニックに陥らないこと "select"はおかしくない 仮定せずに、証明すること テキスト操作 テキスト操作言語を学ぶこと コードジェネレータ コードを生成するコードを作成すること 妄想の達人 あなたは完璧なソフトウェアを作ることはできない 契約による設計 Design by Contract(DBC) 事前条件、事後条件、クラス不変表明ーにより、ルーチンの設計を行う DBCをチェックする → C言語による実装? 死んだプログラムは嘘を付かない 早めにクラッシュさせること トラッシュ(めちゃくちゃにする)ではなくクラッシュ(停止) 表明プログラミング 起こり得ないことは表明によりチェックする assertなどを用いる いつ例外を使用するか 例外は例外的な場合のみに使用すること リソースのバランス方法 始めたことは終わらせること → リソースを確保した人が解放する 曲げるか壊すか 柔軟性の高いコードを記述する 結合の最小化とデメテルの法則 デメテルの法則により、結合の最小化を実現する 機能に対するデメテルの法則 オブジェクト中のすべてのメソッドは、以下のいずれかに属するメソッドのみを呼び出すべきである ・自分自身 ・メソッドに渡されたパラメータ ・自身が生成したオブジェクト ・直接保持しているコンポーネントオブジェクト メタプログラミング 設定できるものを統合しないこと → システム設定を動的に変更できるようにする 抽象概念はコード上に、詳細はメタデータ上に置くこと 時間的な結合 ワークフローを分析し、並列実行可能なアクションを明記すること サービス(一貫性のあるインタフェースを持ち、独立した並列オブジェクト)を使って設計を行うこと 常に並列性を意識した設計を行うこと 単なる見かけ モデルからビューを分離すること コーディング段階 偶発的プログラミングを行わない 常に何をやっているのかを意識する 完全に理解していないことをしようとしない 明確なプランを持ってすすめる 信頼のおけるものだけを前提とする 仮定をドキュメント化する → 契約による設計を行う 仮定が正しいことをテストする → 表明によるプログラミングを行う 作業に優先順位をつけ、重要なことに時間を使う 過去のしがらみにとらわれない → リファクタリングを行う アルゴリズムのスピード アルゴリズムの処理速度を見積もり、見積の検証を行う リファクタリング リファクタリングを早めに、こまめに行うこと リファクタリングのタイミング ・二重化の解消 ・直交性の確保 ・変更した要求の修正 ・パフォーマンスの向上 リファクタリングと機能の追加を同時に行ってはならない 小さな修正を行う 頻繁にテストを行う テストしやすいコード 契約による設計とし、契約に対するテストを行うこと テストコードを作成すること 邪悪なウィザード 理解できないウィザードのコードを使用しないこと プロジェクトを始める前に 要求の落とし穴 要求は拾い集めるものではなく、掘り起こすものである 要求をドキュメント化する 抽象は詳細より息が長いものである プロジェクトの用語集を作ること 不可能なパズルを解く 制約条件にとらわれずに考えるのではなく、本当の制約条件を見つけ出すこと 準備ができるまでは 心の声に耳を傾け、準備ができてから開始すること 仕様の罠 解説しないほうが良い場合もある → 過剰な仕様書を書かない 丸と矢印 形式的方法論にとらわれない 達人のプロジェクト 達人チーム システムの機能ごとにチームを編成する どこでも自動化 手作業は危険である ・プロジェクトのコンパイル ・ビルドの自動化 ・最終ビルド ・管理の自動化 容赦ないテスト 早見にテスト、何度もテスト、自動でテスト テストが全て終わるまでコーディングは終わらない コードのカバレージではなく、状態のカバレージをテストすること 複数のバグを一度にみつけること すべてはドキュメント ドキュメントは組み込むものである 大きな期待 ユーザーの期待をやや上回ること 誇りと愛着 あなたの作品に署名すること
https://w.atwiki.jp/dojin_ikusei/pages/13.html
遊女育成シュミレーション「祇園少女(仮)」仕様書 ●コンセプト 愛のみを糧に生きる少女。 親としての愛、男としての愛、ただ美しいものにひれ伏す愛。 そんな多種多様な愛を受け、少女をこの世に二つとない美しき「蝶」となる。 ●ゲーム概要 プレイヤーは貧しい学者の男となって、江戸時代の小さな屋敷に居を構えそこで二人の少女と共に娼館を営む。 ゲームは一日単位で時間経過する。一日は以下のパートで構成されている。 選択パート…その日の行動を決定する。 イベントパート…行動に沿ったイベントが展開する。選択肢がでることもある。 夜伽パート…少女に付ける客を選ぶ(夜伽パートを行わずイベントを起こす事もできる) 自動発生イベント…フラグを踏むと自動的に発生。回避はできない。 一定期間経過後にエンディング。そのときの愛情パラメーターによってEDが変化。 ●物語 (例) 主人公は貧しい学者の青年。ある日、長らく連絡を取っていなかった祖父から呼び出される。主人公が彼の住む屋敷に行ってみると、そこには病床に付した祖父と彼を甲斐甲斐しく世話をする二人の少女がいた。 祖父が言うにはこの二人の少女は一見人間のようだが、実はある特別な蝶の化身だという。 彼女らは男の愛情と精を糧にして生きているという。そのため祖父は彼女らを遊女として娼館を営んでいたらしい。 自分の寿命を悟った祖父はその役目を主人公に引き継ぎたいという。 そうして彼女らが「成虫」となるまで残り三ヶ月、彼らの奇妙な蜜月の日々が始まった。 ●ゲームの流れ 一日の流れは以下の四つのパートを繰り返す。 基本そのパートを終了すれば次のパートへと進む。 ○選択パート 基本的にその日の日中に行うことを決める。 行動は大きく分けて三種類 イベント行動 愛情を与える行動。行ったイベントによって与える愛情の種類は変わっていく。 選べる少女は一行動につき一回。選んだ少女への愛情しかあがらないが、イベントにもう片方が登場しないわけではない。 イベント内でランダム的に少女の能力が増減することもあり。 アイテム行動 所持金から「アイテム」を少女に買い与える。買い与えるアイテムによって少女の能力と愛情が増。 この行動に限り一行動中に何度でも選択可。 少女によって与えられるアイテムの種類が違う。 訓練行動 自分の意図する少女の能力が増。愛情は場合によって減。 この行動に限り二人纏めてパラメーターをあげられる。 所持金を払うことによってより効果の高い訓練をさせることもできる。 選べる行動の種類は各パラメーター、シナリオ進行度等により変化する。 ○イベントパート エロゲによくあるADV形式の会話パート。 基本読み進めていくだけだが、場合により選択肢が出てそれにより「能力」の増減等の現象が起こる。 EDを迎えるためのフラグはここに設定。 ○夜伽パート 少女たちが励むパート。その日少女に付ける客を選ぶ事ができる。 基本的数値のやり取りだけだが、場合によって短いイベントを挟むこともあり。 少女たちのパラメーターにより選択できない客もいる。 少女それぞれに設定可。二人それぞれに客を付けることもできるし、一人の客に二人つけることもできる。 夜伽自体選択しないことも可。その場合夜限定のイベントを選択することもできる。そのイベントは内容以外は昼のときと仕様は同じ。 客の種類により「養分」が回復、「所持金」・「評判」増。 複数回同じ客を選ぶことで「能力」増のボーナスあり。 少女たちの「能力」により選べない客もいる。二人で補完しあい条件を満たした場合は選択可。 ○自動発生イベント 条件を満たしていた場合、夜伽パート終了後に発生。 多くの場合EDに関わる。いわゆるメインシナリオ。 ED条件 キーとなるイベントをこなせば一定期間(3ヶ月?)経ったあと自動的にEDを迎える。 稀に一定期間立たなくてもそのイベントをみたら発生するEDもあり。 ●パラメーター ○「愛情」 半可視パラメーター。EDに影響。自動発生イベントのフラグにもなる。 起こしたイベント、イベント内の選択肢によって増減。 この数値により少女の髪の色が変わる。これでプレイヤーはある程度判断できる。 髪の色はそのとき受けている愛情のうち最も数値の大きいものに反映する。 喜…少女のためを思うイベントを起こすと増える。親の愛情。 怒…自分本位のイベントを起こすと増える。エゴの愛情。 哀…レアな愛情。特定のイベントを起こすと増える。憂鬱の愛情。 楽…エロいイベントを起こすと増える。肉欲の愛情。 ○「能力」 可視パラメーター。イベント、客の種類に影響。 起こしたイベント、イベント内の選択肢で変化。与えるプレゼントでも増減する。 愛嬌 知性 美貌 技巧 ○養分 可視パラメーター。日数を減るごとに徐々に減っていく。一定数を切ると強制ED。 夜伽パートでのみ回復。客の質により回復量が違う。 ○所持金 可視パラメーター。少女へのプレゼント、特殊イベントの発生に使える。訓練でも使用可。 夜伽パートで得ることができる。客の質により得る量が違う。 ○評判 可視パラメーター。これが増えることで客の種類が変わってくる。 夜伽パートの回数をこなすことで増。 ●呉服屋 服やアクセサリ、消費アイテムなどが買える。 ○服 身につけるとパラメータや立ち絵に変化。 ○アクセサリ 身につけるとパラメータや立ち絵に変化。 ○消費アイテム 使うとパラメータに変化。 使用後なくなる。 ●部屋 ヒロインはそれぞれ違う部屋にいて、コマンド選択はそれぞれの部屋で1人ずつ行う。 ●配布方法 ダウンロード販売(DLSite.com等)
https://w.atwiki.jp/kylico/pages/20.html
2012/11/29 作業ログに書いていたような内容をブログに記載することにした。 2012/11/24 OSのバージョン確認 # cat /etc/redhat-release Scientific Linux release 6.3 (Carbon) 2012/11/18 リポジトリを指定してyum yum --enablerepo= リポジトリ コマンド アプリ yum --enablerepo=epel install sl 指定できるリポジトリは、以下を参照。 /etc/yum.repos.d/ 2012/11/08 メモ:Raspberry Pi 日本語フォントのインストール sudo apt-get install ttf-kochi-gothic ttf-kochi-mincho xfonts-intl-japanese xfonts-intl-japanese-big xfonts-kaname ユーザー追加 sudo useradd -m -g グループ ユーザー -m:ホームディレクトリを自動作成 -g:グループ指定 パスワード設定 sudo passwd ユーザー ラズベリーパイ用コンフィグ画面 sudo raspi-config エディタ変更 sudo update-alternatives --config editor 2012/09/19 メモ:ssh -X -C ユーザー名 @ ホスト名 -X:X11 forwarding. -C:圧縮オプション 2010/06/10 CentOSに鞍替えすることを決めたものの、Fedora12をずっと使っていた。 しかし、Fedora13にアップグレードしてから動作が不安定になったので、CentOSに入れ替えました。 しかし、問題点が。 起動に時間が掛かる。うちのマシンだと、1~2分必要。 Fedoraだと1分以内にはログオンできていたので、残念。 なにしろデスクトップが主な使用用途だから。 2010/03/28 これからの方向性が決定した。 Linuxマシンで、Java勉強用マシンを作成する。 Linuxマシンでも、Windowsマシンでも開発できるように、VNCとか色々やってみようと思う。 実際のマシンで実験した結果を纏めるつもり。 で、ディストリビューションなんだけどCentOSに鞍替えすることに決定。 2010/03/26 情報の再構築を行うために、色々と手をつけ始めた。 なので、情報がひっちゃかめっちゃか。 2010/01/11 ファイル共有のために、Sambaの設定を追加。 2009/10/14 OracleMasterBronzeに付属するDVDのデモスクリプトを動かすと、所々でエラーが出る。 Oracle11gの付録DVDのスクリプトなのにOracle10gXEで実行しているからか? 調べてみると半分正解(Oracle10gXEで実行しているから)。 Oracle10gXEのデフォルト文字コードはUTF8なのに、VARCHAR2(10)に漢字4文字を設定しようとしている。 EUCだと4×2=8バイトで十分な領域なのだが、UTF8だと4×3=12バイト必要になる。 だからNGなのだ。 こうなったらCREATE TABLEのサイズを1.5倍に置換するしかないな・・・。 2009/10/07 Linuxマシンにメモリ増設。(1024MB+1024MB DDR2 240Pin PC-4200 CL4) マシンの仕様書を見る限りではPC2-3200なのだが、生産量が少なく手に入らない。 なので、互換性のあるPC-4200のメモリを購入してきて増設。 恐る恐る差してみたら認識したので、ガッツポーズ!! 2.5GBのメモリになったので、Oracleを立ち上げても快適。 2009/10/02 CygwinのvimでBSが使用できなかったので、改善方法を記載。 2009/09/05 Oracleインストールを記述。 失敗だったのは、インストールをGUIで実施してしまったこと。 コマンドラインでの実行結果が残せないという残念な結果に。 今回は、インストール後の設定ログのみを残すことに。 なにしろ調子が悪くなったらOSの再インストールを実施しているから、またOracleも再インストールする時がくるよ。 きっと、すぐに。。。 2009/09/03 何故か?Linux機がネットに接続できなくなってしまった。 yumが使えない・・・。 またインストールしなおすかな。 どうもFedoraは苦手なので、CentOSに乗り換えようかなっと。 2009/09/02 ようやく静的アドレスの割り当てまで完了。 結構手間取った。何度か本体でしか操作できなくなったりしたので。 2009/08/31 なにやら設定がおかしくなってしまったので、再インストールすることに。 今の私には原因追求は無理です。 さてやっか。 2009/08/27 『リモート接続』を書き始めたのだが、眠くなってきたので途中にて終わり。 どうも作業が遅々としていかん。 2009/08/26 ディストリビューション選定 …選定理由について記載。 インストール …インストールコマンド4種類を洗い上げたのみ。コマンドの詳細は未調査・未記入。 シェル設定 ….cshrcについて未記載。 2009/08/25 『プログラミング関係で勉強した内容を一箇所に集約して纏めたい。』そう思ってこのページを作成。 USBメモリで管理するのもいいかと思ったけど、こっちのが便利かと思って。 トップページに記載した勉強用マシンが両方ともHPなのは単なる偶然。
https://w.atwiki.jp/deadspace2/pages/34.html
武器情報 コスト 1,1000 credits 入手場所 チャプター2開始地点のストア 仕様書 ダメージ 50 (100 最大) 弾薬サイズ 400 credits for 2 Javelin Spears 最大弾数 5 (10 最大) ファイアレート 中 射程距離 遠距離 セカンダリモード Electrification/Detonation 弾消費 1(+1事前打ち込み) プライマリ スピアを射出する セカンダリ 最後に射出された杭から電流を流し、一定範囲を攻撃し続ける SPECIAL セカンダリの放電後、杭が爆発するようになる 情報 細長い杭を高速で射出する工具。 プライマリは攻撃力が高く、単体への射撃能力は高い。例えるならライフル銃のような使い勝手。 連射力は低め。また、杭による攻撃という点攻撃のため、狙いをつけるのが非常に難しい。 撃った杭はオブジェクトとして残り、セカンダリを発動させるための起点となる。 セカンダリは杭から電撃を発生させることで周囲の敵にダメージを与え続ける。 事前にプライマリで杭を打ち出しておかないと使用できない。オレンジ色に点滅する杭が発動する目印。 持続力を持つ範囲攻撃のため、ラッシュ時における足止めと攻撃を兼用できる。 また、持続によって死骸を追撃するため、死骸消滅によるアイテム損失を回避できる。 だが、プライマリに比べると威力は若干低め。小型NMの駆除には非常に効果的だが、中型のNMにフルで当て続けても電撃だけで倒すのは厳しい。 セカンダリは自爆の危険性があることに注意。発動する杭が近すぎれば電撃で感電する。 SPECIALを適用すると、電撃を流し終わった杭が爆発するようになる。 この爆発もまた高威力の範囲攻撃であるため、総合ダメージが大きく跳ね上がる。 なお、セカンダリ発動中にプライマリを撃つか、エイムボタンを離すとSPECIAL適用前では放電が止むだけだが、SPECIAL適用後では即起爆させることができる。 しかしながら、この爆発も当然自爆の危険性があるので重ねて注意すること。 初期弾倉は5発と少ない。そしてリロード速度もかなり遅い。 強化を進めていけばそれなりに改善されるが、プライマリ+セカンダリを使用するとあっという間に2発消費するので、リロードタイミングには注意。 弾薬そのものは非常に安いが、ドロップする弾薬数が少ない。 加えてセカンダリ使用には2発1セットが必要となるため、弾薬効率の面で言うとかなり悪い部類に入る。 高難易度では手に入る弾薬の少なさも相まって普通に使っていくと間違いなく弾薬が足りなくなる。 ショップを見かけたら常に弾薬を補充しておくのが吉。 用途 スペック上はプライマリで単体への高火力、セカンダリで範囲攻撃とオールラウンドな性能を持つ。 弾薬も安価のため、上手く命中させることが出来れば高い費用対効果を生むことが可能。 初弾をどのように当てるかが運用の肝となっている。 ただし、次に説明する通り強化が進んでいない状態ではいろいろな面で力不足が目立つため、主力として使うならすみやかに強化を施したい。 この工具は強化前と強化後で劇的に使い勝手が変化する。 強化前ではそれなりに高威力とは言え、プライマリを胴体に叩き込んで即死させることは難しい。 さらに点攻撃による狙いのつけづらさと連射力が低めであるため、ミスショットするとリスクが大きい。 セカンダリによる範囲攻撃は入手時期が早いため非常に頼りになるが、準備・発動で2発必要なうえ、初期状態で5発という少ない弾倉、遅いリロード時間がネックとなる。 このように初期状態ではいろいろな面で運用の厳しさが目立つ構造となっている。 強化の段階を踏むに従って驚異的に強化されていく。 攻撃力と連射力の向上で、たとえ中型以上のSuper系NMでも少ない弾数で素早く処理出来るようになるほか、Lurkerなども弱点を意識せずに撃破できる。Bruteなどの大型種にも致命傷を与える。 装弾数とリロード速度の強化によって、セカンダリを容易に発動しやすくなり、ラッシュ時の安定性が生まれる。 SPECIALを取得すると、セカンダリに杭の爆発が付与され、ジャベリンガンの真の性能が開花する。 Super Slahserを胴体撃ちからセカンダリに繋ぐことで、即死させるほどの威力を発揮するようになり、非常に強力な兵器として運用していける。 このように早急な強化を求められる武器といえる。 プライマリによって敵を撃破した場合、状況によってはセカンダリが効果的に機能しないことがあることに注意。 電撃は最後に射出された杭から起動するが、プライマリによって死亡した敵は大きく吹き飛ばされる仕様となっているため、命中によって最後の杭が飛んで行ってしまうという状況が発生しやすい。 ラッシュ処理のためにセカンダリを使用する場合は、プライマリの射出場所に注意を払おう。 また、プライマリ後、即セカンダリで固い敵の必殺を狙う場合も、手足に当てると千切れて失敗することがある。 そういった場合は胴体を狙うことを推奨。 長所 高火力 持続的な範囲攻撃 セカンダリによるアイテムドロップの確保 弾薬の価格の安さ 遠距離戦可能 入手時期の早さ ラッシュへのそこそこの対応力 短所 点攻撃によるエイミングの難易度 改造前のリロード速度・装弾数 弾薬効率の悪さ セカンダリによる自爆・誤爆の危険性 武器強化効果 DAMAGE 威力増加 +12.5 pts CAPACITY 容量増加 +1 pts RELOAD リロード速度上昇 -0.25 sec ALT FIRE セカンダリ威力増加 +1.5 pts SPEED 発射間隔短縮 -0.2 sec SPACIAL 放電後スピアが爆発 フルアップグレードに必要なノード数:25 参考動画 関連実績・トロフィー +Shock Therapy Shock Therapy ジャベリンガンを使用し敵を突き刺し同時に3体の敵を倒す //
https://w.atwiki.jp/bokuyo/pages/109.html
プロジェクトのディレクトリ構成 ゲームを作り慣れていないぼくは普段ディレクトリ構成について何も考えません. しかし、ゲームが完成にせまるにつれて、ちょっとしたミニゲームでさえ、ファイルの管理が面倒になってきます。 VC++のデフォルトのソリューション/プロジェクトディレクトリの構成はとても見にくいです。 ファイルがどこにあるのかわけがわからなくなるのを防ぐために、ぼく用ディレクトリ構成のルールをまとめていきたいと思います。 このことについて指摘している本は「ゲームコーディング・コンプリート(著 マイク・マクシャフリー)」(pp.87-90)です。本の中で紹介されている内容をもとに小・中規模ゲームで使いやすそうな感じで考察してみます。 なおwikiの都合上、「\」が「円マーク」ではなく、「バックスラッシュ」で表示されてるかもしれません。Windows 環境を想定して書いているので円マークでおっけーです。Mac OSX, Linux 環境でもディレクトリ構成はそのまま適用できるかと思います。 Visual C++ 2010 Express 対象のページです。 追記:今見返すと、このページの内容は古いですね…。機会を見て新しく書き直します。(2013/03/26)Data じゃなくて Assets ディレクトリとかどうでしょう? (Source ディレクトリに Obj があるのもなんだか気持ち悪いですね。ごめんなさい。) マイク・マクシャフリーさんが提案するディレクトリ構成 Docs Media Source ObjDebug Releace BinData TestData それぞれディレクトリの中身の説明 Docs 仕様書・設計書 参考資料 Media 未加工のグラフィックス・オーディオ・サウンドファイル Source ソリューションファイル ソースコード Obj Debugビルド・Releaseビルド VC++のdefaultの設定だとプロジェクトファイル内に含まれてるので変更する必要あり。 Bin ゲームデータ、構成ファイル全て。 Releaseビルドと.DLLを入れ、Dataディレクトリ以下にスクリプトからグラフィックス・サウンドまでを入れる。 これを配布すればいい。 Test テスト用のBinディレクトリ。 テストデータやログ、動作を見てない生まれたてのReleaseビルドもすべてここにいれてテストを行う。 じゃあ実際に、Visual C++ 2010でゲームを作るときのディレクトリ構成って? 日本語版ゲームコーディング・コンプリートでは、Visual Studio 2005 環境となってる。 ぼくは「Visual C++ 2010 Express」を使ってるので、その環境で実際にディレクトリ構成を考えるなら?…ということで。 ゲームを作る人(プログラマ・グラフィッカ・その他もろもろ)にとって理想的な共有ディレクトリとは? Sourceディレクトリをコピペですぐに移動できる。ソースファイルを移動してもたいして問題ない。VC++2010にとって、便利だけどくそみたいにデカブツなインテリセンスデータベースをSourceディレクトリ外に置く。 ソリューションはSourceディレクトリ内にあるべきか、ルートディレクトリに置くべきか。プロジェクトファイルを頻繁に入れ替えたりすることはめったにない。 ルートディレクトリに置いておくと、すぐにソースを開ける。 ソリューション自体はそこまで重要じゃない。基本プロジェクトファイルが全権握ってるようなもの。気にしなくていい気がする。 ってことはやっぱりルートディレクトリ? うーん、でも、グラフィッカがソリューションを開くことはないから、普通にSourceで良い気がする。Sourceディレクトリをコピペしただけでプログラムを移動できるんだから、ソリューションファイルもSourceディレクトリ内に。 インテリセンスデータベースはルートディレクトリ?Sourceディレクトリ?それともルートディレクトリ外に置くべき?Sourceディレクトリに置くと、Sourceディレクトリをコピペしたりするのが厄介になる。 ルートディレクトリ外に置くと、管理がめんどくさくなるかも? ルートディレクトリに、Intellisenseディレクトリを作って、そこに置くようにするとか。共有するときは、Intellisenseディレクトリを削除すればいい。 .objファイルは誰が持つの?プロジェクトファイルが複数なることも予想すると。Source>Project名>Debug/Releaseでもたせておいたほうがいいかも。 で、ぼくの結論!Visual C++ 2010 でゲームを作るときのディレクトリ構成! (太字はディレクトリ名, 斜体はファイル名, 括弧内はディレクトリ内の説明) BinData (Binディレクトリごと配布する. ) Docs(設定資料とか仕様書とか) Media(未加工のリソースファイル) ObjDebug Releace (ビルドした実行ファイルはここに生成される. ここが出力ディレクトリとなる. ) Source SolutionName .sln ProjectName ProjectName .vcxproj ObjDebug Release (中間コードは各 ProjectName ディレクトリ内のObjディレクトリが持つ. ここが中間ディレクトリとなる. ) TestData (デバッグはここで行う. ここが作業ディレクトリとなる. ) Visual C++ 2010 上で実際に設定してみる プロジェクトファイルの各ディレクトリのパスを設定 出力ディレクトリ $(SolutionDir)..\Obj\$(Configuration)\ 中間ディレクトリ $(ProjectDir)Obj\$(Configuration)\ 作業ディレクトリ $(SolutionDir)..\Test\ これでビルドのパスはおっけー。 ソリューションのインテリセンス周りを設定 ちなみにインテリセンスの設定はソリューションごとの設定ではなくVisual C++の環境設定みたいです。詳しく知らないのであとで調べときます。 VC++2010のインテリセンス周りのデータはでかいので、マイドキュメント内にあるVC++2010のデフォルトフォルダにでも置くことにします。 イメージ図 My DocumentsVisual Studio 2010IntelliSense SolutionName -(16進数が8つ) SolutionName .sdf ipch ProjectName .ipch (VC++2010の入力補完機能「インテリセンス」関連のデータベースはここに置きます. ) 具体的な設定手順 ツール オプション テキストエディタ C/C++ 詳細 フォールバック位置 常にフォールバック位置を使用 Trueを選択 フォールバック位置の使用を警告しない Trueを選択 フォールバック位置 C \Users\Owner\Documents\Visual Studio 2010\IntelliSense\ Visual Studio 2010のデフォルトフォルダ内に わざわざフォルダを作らずとも、指定しておけば勝手にVC++さんがフォルダを作ってくれるので場所だけ指定でおっけー。毎回ソリューションを開くたびに「適切なフォールバック位置使っちゃうよ」ってVC++さんが訊いてくるようになるから、「警告しない」をTrueにする. 以下のような感じで、マクロと、相対パスは上手く使えるかちょっと不明。 フォールバック位置 $(SolutionDir)..\Intellisense\ 相対パス使えない??もしくはマクロ使えない??ソリューションごとではなく、VisualStudioのエディタさんごとの環境設定だから?? ちなみに、フォールバック位置が不適切だったら、VC++さんが上手くしてくれる。基本は指定したフォールバック位置のディレクトリ内にちゃんとしたディレクトリを作ってくれる. 指定したフォールバック位置が正しくなかったら、C \user名\AppData\Local\Temp\VC++\内にインテリセンスデータベースが作られる ディレクトリのパスの設定をして以下の警告が出たら 1 C \Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(298,5) warning MSB8004 Intermediate ディレクトリの末尾がスラッシュではありません。Intermediate ディレクトリが適切に評価されるようにするために、このビルド インスタンスによってスラッシュが追加されます。 1 C \Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(299,5) warning MSB8004 Output ディレクトリの末尾がスラッシュではありません。Output ディレクトリが適切に評価されるようにするために、このビルド インスタンスによってスラッシュが追加されます。 出力ディレクトリ・中間ディレクトリの設定の場合、ディレクトリパスの最後に「\(円マーク)」をつけなければならない。例:「..\Bin」ではなく「..\Bin\」 余談ですが、ゲームコーディング・コンプリート p.92では、末尾に「\(円マークもしくはバックスラッシュ)」が入ってません。VC++2005の仕様かな? Visual C++ 2010 (ちなみにぼくが使ってるのは"Express")の設定関連について。 VC++2010で設定できるディレクトリ ディレクトリ名 どこのこと言ってるの? デフォルト設定 出力ディレクトリ 実行ファイル(.exe)を出力する場所 $(SolutionDir)$(Configuration)\ 中間ディレクトリ 中間ファイル(.obj)を出力するところ $(Configuration)\ 作業ディレクトリ VC++内でデバッグするときに、リソースをどこから読み込んでくるか? $(ProjectDir) それぞれの設定方法は、プロジェクトのプロパティ 構成プロパティ 全般orデバッグ作業ディレクトリの設定だけ、「プロジェクトのプロパティ 構成プロパティ デバッグ」 プロパティシートで作業ディレクトリの設定とかできるのかな? Visual C++ ディレクトリ設定マクロ $(SolutionDir) .slnファイルが置いてるところに~ $(Configuration) "Debug"もしくは"Release"という名前のフォルダ。ビルド時の構成で切り替えてくれる。 $(ProjectDir) .vcxprojファイルが置いてるところに~ インテリセンス(IntelliSense) クラス名やメソッド名、メンバ変数などの候補を即座に出してくれるのは、この機能のおかげ。 .sdf形式のやつがそれ。 VC++2010ではインテリセンス機能がかなり進化して、今までよりも補完がかなり利くようになったらしい。ヘッダをプロジェクト読み込んだ瞬間に解析してるため、作業中スムーズに補完が行われる。GUIの下部で「インクルードファイルを解析しています。」と出ているのがそれ。 ただしそのせいで、インテリセンスのデータベースはサイズがでかくなっている。余裕で50MBは超えるという恐ろしい時代。 インテリセンス関連のファイルを別に保存させる ツール オプション テキストエディタ C/C++ 詳細 フォールバック位置 ソリューションを開いたときに警告が出る 参照データベースと IntelliSense ファイルに適切な場所が見つかりました Visual C++ でソリューション "C \[Solution名]\Source\○○.sln" の参照データベースおよび IntelliSense ファイルを格納する適切な場所が見つかりました。 C++ 詳細オプションで フォールバック位置 が指定されなかったため、Visual C++ は一時ディレクトリの使用を試みています。 Visual C++ でフォルダー "C \Users\Owner\AppData\Local\Temp\VC++\○○-4efddb37" が検証されました。以下の理由により、このフォルダーは適切です ディレクトリがローカル ドライブ上にあります。 フォールバック位置 は C++ 詳細オプションで構成できます。 この場所を使用するには、[OK] をクリックします。 このセッションで C++ 参照情報と IntelliSense を無効にするには、[キャンセル] をクリックします。 ツール オプション テキストエディタ C/C++ 詳細 フォールバック位置の使用を警告しない TRUE 以上の設定で警告は出なくなります。ですが根本的な解決にはなってないような…。どうなんでしょう? Visual C++ 2010 的な関係図 ファイル構成 ソリューション(.sln)プロジェクト(.vcxproj) プロジェクト(.vcxproj) … 具体的なディレクトリ構成 ソリューション(.sln) プロジェクトAディレクトリA.vcxproj プロジェクトBディレクトリB.vcxproj … Ogre 3D を参考にしてみる CMake Docsapi licenses manual src Components PlugIns Maininclude src objDebug Release RenderSystemsDirect3D9include src Direct3D10 Direct3D11 GL GLES Samplesサンプルの数々とその実装コード Tests単体テスト用コードはここに入れる Maininclude src ToolsMaya, 3dsmax, Blender 間のファイルのエクスポート用ツール、あるいはXMLコンバータなど入れておくとこ、 ReadMe いろいろメモ書き include と src でヘッダとインプリメントファイルを分けている。(src には.cppファイルが、include には.hファイルが) Main (Ogre3D では OgreMain ディレクトリとなっている)のほうには数学ライブラリから例外処理、メッシュからライティングまでいろいろ入ってる。 それに対して、RenderSystems のほうで実際に使用するデバイス周りのクラスが定義されてる。 参考文献 ゲームコーディング・コンプリート(著 マイク・マクシャフリー)(pp.87-90)大変参考になります。おすすめの一冊です。 MSDN Advanced, C/C++, Text Editor, Options Dialog Box
https://w.atwiki.jp/ohden/pages/50.html
イ 【IFB】 Invitation For Bids 【RFI】 Request For Information 情報提供依頼書 / 情報要求書 企業が調達や業務委託を行う際、自社の要求を取りまとめるための基礎資料として、外部業者に情報の提供を要請すること。 あるいはその要請をまとめた文書をいう。 一般にRFPを作成するために発行される。 最新技術の調達や普段は取り引きのない業者への発注を検討する場合、一般の公開情報だけでは調達条件や選定条件を取りまとめることができないことがある。 こうしたときに、調達先・依頼先候補の事業者に必要情報の提供を求める文書がRFIである。 RFIの目的は、知りたい情報を文書として明確化することで、相手からセールストークなどのあいまいな言葉ではなく、明快な回答を確実に得ることである。 複数業者の回答を比較する場合も同一の質問に対する答えであれば、検討しやすい。 RFIの発行は、提案や見積もりといった交渉の前段階で行われるもので、数多くの外部事業者から、自社が求める能力を持ち、交渉に足る相手を絞り込むといったことも狙いとなる。 この場合、RFI発行先が必ずRFP発行先・発注先になるわけではない。 ハイテクを対象としたRFIでは、自社が知らない新製品・新技術に関する知見を得ることも目的となる。 IT調達におけるRFIはITベンダの技術要件を確認するもので、どのような技術を保有しているか、どのような経験があるかなどを確認するものとなる。 【RFP】 Request For Proposal 提案依頼書 / 提案要請書 / 入札依頼書 企業が情報システムやITサービスなどを調達する際に、発注先となるITベンダに具体的なシステム提案を行うよう要求すること、またはその調達要件などを取りまとめたシステム仕様書を指す。 日本語では「提案依頼(書)」「提案要請(書)」「提案要求(書)」「提案要望(書)」「提案募集(書)」「入札依頼(書)」「見積依頼(書)」「提案書提出要請(書)」など、さまざまな訳が使われる。 ITベンダ側はRFPに基づいて大まかなシステム設計を行って提案書を作成し、ユーザー企業に提出する。 ユーザー企業はその提案書を評価して、調達先の決定や契約の締結などを行うことになる。 RFPには決まった書式はないが、システムの「概要と目的」「必要な機能」「求められるシステム条件」「サービスレベル」「予算」「納期」「契約条件」「評価プロセスと評価基準」「調達方針」「環境」など具体的な要求を盛り込む必要がある。 さらに各要求に優先度を付け、システム導入にあたってゆずれない条件を明記することもポイントだ。 またベンダに対して、「提案書の形式」「提出期限」「提出先」「提出方法」などを指定する。 RFP作成については、まずユーザー企業内で対象となる部門スタッフ(エンドユーザー)へヒアリングを行い、現状の業務やシステムに対する改善要望を洗い出すことから始まる。 この作業を担当するのは主にユーザー企業の情報システム部門だが、場合によってはシステム導入の対象部署から担当者が任命されることもある。 いずれにしても、業界特有のビジネス用語をできるだけ排除することが重要だ。 このヒアリング結果を受け、具体的な機能要件に落とし込む。 RFPの作成は、ベンダへの情報提供のほかに、事前にシステム要件を明らかにすることで、開発フェイズに入ってからの混乱を未然に防止することが期待される。 とはいえ、実際に開発作業に着手すると、エンドユーザーからの要求が変更される可能性もある。 特に最近のプロジェクトでは、機能を少しずつ追加してエンドユーザーに検証してもらいながら開発を進めるスパイラル型開発が主流なので、出来上がったシステムを見てさらに高度な要求を突き付けるエンドユーザーも少なくない。 また最初のRFPはあいまいで開発工程に入ってから、詳細な要求が決まるというパターンも多い。 こうしたリスクを防ぐには、エンドユーザーの要望を初期段階で引き出すテクニックが必要となる。 こうした声に応えるため、ユーザー企業のRFP作成を支援するコンサルティングファームも増えてきた。 【RFQ】 Request For Quotation 見積もり依頼書 調達先・業務委託先(候補)に対して、価格およびその内訳を示す見積もりを作成するように依頼すること、あるいはそうした依頼を示した文書をいう。 システム開発では、どのようなものをどのようなレベルで作成するかが決まらないと価格見積もりを行うことができない。 そこでRFQに先立ってRFIやRFPを発行し、システムの概略を決める必要がある。 小規模システムではRFPとRFQが1つに集約されるケースもある。 eコマースなどでは、売り手が公開している価格を買い手が比較・考量して発注する方法以外に、買い手が提出するRFQに対して売り手が入札すること、買い手は取引先企業の発掘を容易にする仕組みが用意されているところもある。 更新日: 2009年12月18日 (金) 20時04分56秒
https://w.atwiki.jp/vipparty/pages/125.html
まだよく分かっていない仕様や転職条件などを報告してください。 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/aias-closurecompiler/pages/30.html
トップページ よくある質問 このページは公式サイトの以下のページを元に作成しました。http //code.google.com/p/closure-compiler/wiki/FAQ http //code.google.com/closure/compiler/faq.html 目次 そもそも... Closure Compilerとは何ですか?それを使うべき理由は? Closure Compilerはその他のJavaScript圧縮ツールとどう違うのですか? Closure Compilerを使うにはWeb開発の知識がどの程度必要ですか? Compilerにとって、アプリケーションの実行速度とコードサイズの間には何らかのトレードオフがあるのでは? Compilerは処理速度を最適化しますか? Closure Compilerの使い方 Closure CompilerはHTMLに埋め込まれたJavaScriptをコンパイルできますか? Closure Compilerを別の縮小ツールと一緒に使うことはできますか? Closure CompilerをCajaと一緒に使うことはできますか? コンパイルできるファイルのサイズには制限がありますか? Closure Compilerは全てのプラットフォームで使用できますか? Closure Compilerは文法的に正しければどんなJavaScriptでも処理できますか? Closure CompilerはClosure Libraryとどのように連携しますか? 私はソースコードに必ず表記しなければならない著作権やライセンスの項目を持っています。これらをClosure Compilerが行うテキストの除去から守るにはどうしたらよいですか? 私の変数がページ上の他のスクリプトと確実に衝突しないようにするにはどうしたらよいですか? Closure CompilerをJava APIから呼び出すにはどうすればよいですか? Externファイルをどう書いたらよいのでしょう? 予想外の結果 ADVANCED_OPTIMIZATIONSでコンパイルするとコードが動かなくなるか、Compilerがエラーを出力します。なぜでしょう? Compilerが次のようなエラーを出してクラッシュしてしまいました:Exception in thread "main" java.lang.UnsupportedClassVersionError Bad version number in .class file "Trailing comma is not legal"というエラーを受け取りましたが、そのコードはFirefoxで動いています。 "Unsupported syntax"というエラーを受け取りましたが、そのコードはFirefoxで動いています。 Closure Compilerが文字列をインライン化したため、コードサイズが大きくなってしまいました。なぜこんなことをするのでしょう? Closure Compilerの設計について なぜコンパイルされたコードはランダムに改行されているのですか? JSDocの型言語の仕様書はありますか? 別な○○という構文をJSDocの型言語に追加してもらえませんか? 私はFirefoxのエクステンションを書いています。それは最新版のFirefoxでさえ動作すればよく、他のブラウザで動かなくても問題はありません。JavaScript 1.7で導入されているカッコいい機能を利用できるよう、--platform=FIREFOXオプションを追加できませんか? そもそも... Closure Compilerとは何ですか?それを使うべき理由は? Closure CompilerはJavaScriptのダウンロードと実行の速度を上げるためのツールです。あなたはClosure Compilerを使うことであなたのJavaScriptファイルのサイズを小さくでき、そしてコードはより効率的になります。 Closure Compilerはその他のJavaScript圧縮ツールとどう違うのですか? 一般的にClosure Compilerは他の縮小ツールと同等かそれ以上の圧縮率を達成しており、あなたのWebアプリケーションのダウンロード時間を改善することができます。加えて、Closure Compilerは文法エラーを開発中に(テスト中ではなく)発見すること、バグのパターンにはまる可能性のあるコードを見分けることを助けてくれます。 SIMPLE_OPTIMIZATIONS レベルの場合、Compilerはより一層のコードサイズ縮小を図るためにコンパイラ的なコード解析を行い、他のツールよりも優れた結果を実現します。Closure Compilerが行うことの例としては、数回しか出現しない関数のインライン化、変数名の再利用、定数式の事前計算があります。 ADVANCED_OPTIMIZATIONS レベルの場合、Closure Compilerはあなたが追加したデータ型に関するアノテーションも使って、目立たないバグを見つけ出します。 Closure Compilerを使うにはWeb開発の知識がどの程度必要ですか? Closure CompilerはJavaScript開発のためのツールですので、Compilerを使うにはJavaScriptのプログラミングの知識が必須です。しかしJavaScriptを使う者なら誰でも、Closure Compilerを使うことで利益を得ることができます。 Compilerにとって、アプリケーションの実行速度とコードサイズの間には何らかのトレードオフがあるのでは? はい。どんな最適化ツールにおいてもトレードオフは存在します。サイズ最適化は処理速度のオーバーヘッドをもたらすことがあります。しかしClosure Compilerの開発者は実行時間を大きく増加させないよう注意を払っており、むしろCompilerの行ういくつかの最適化処理は実行時間を短縮してさえいます。(次の質問を参照してください) Compilerは処理速度を最適化しますか? Webアプリケーションにおいて通常ダウンロード時間は処理速度の最も重要な要因ですので、ほとんどの場合、より小さいコードはより速いコードといえます。同様に、冗長性を減少させる最適化はコードの実行速度を向上させます。 Closure Compilerの使い方 Closure CompilerはHTMLに埋め込まれたJavaScriptをコンパイルできますか? いいえ。Closure Compilerが処理できるのはJavaScriptだけを含むファイルに限定されます。 Closure Compilerを別の縮小ツールと一緒に使うことはできますか? はい。Closure Compilerは正常なJavaScriptであればどんなものでも読み込みますし、自身も正常なJavaScirptを生成します。従って他の縮小ツールが出力したコードをCompilerに扱わせることも、逆にCompilerが出力したコードを他のツールに扱わせることも可能です。 Closure Compilerも他のツールも、入力されるコードについてある種の前提を置いている可能性があることを忘れないでください。例えばあるツールが削除したコメントの中には、他のツールが必要としているライセンス情報やアノテーションが含まれているかもしれません。 Closure CompilerをCajaと一緒に使うことはできますか? Closure CompilerチームとCajaチームはClosure Compilerの SIMPLE_OPTIMIZATIONS レベルにおいてCajaのセマンティクスと安全性が確保できるように努力しています。しかし我々がそのゴールに到達したと保証できるまでには、更なるテストが必要です。もしあなたが SIMPLE_OPTIMIZATIONS レベルでの処理後にCajaのセマンティクスと安全性を保全できなくなるようなケースを見つけた場合、それをClosure Compilerのバグとして記録してください。そしてもしあなたが検証作業を手伝うことに興味があるなら、Cajaチーム(google-caja-discussグループへどうぞ)かClosure Compilerチーム(closure-compiler-discussグループへどうぞ)へ連絡をお願いします。 コンパイルできるファイルのサイズには制限がありますか? Webサービス版(Closure Compiler Service UIとClosure Compiler Service API)のコンパイルにはファイルサイズの最大値がありますが、スタンドアロン版(Closure Compiler Application)のアプリケーションには制限はありません。 Closure Compilerは全てのプラットフォームで使用できますか? CompilerはJavaで書かれているので、Javaが動作すればどこででも使用できます。 Closure Compilerは文法的に正しければどんなJavaScriptでも処理できますか? 大部分は。 eval() 、 with() のようなJavaScriptの言語構造のいくつかは、Compilerの変換処理が基づいている仮定を無効化します。 Closure CompilerはClosure Libraryとどのように連携しますか? Closure CompilerはClosure Libraryを使用するコードに対して特別なチェックと最適化を行ないます。加えてClosure Compiler Service APIはClosure Libraryのファイルを自動的にインクルードする機能を持っています。Closure Compiler Service APIとClosure Libraryを一緒に使うための情報はAPIリファレンスを参照してください。Closure Compiler ApplicationとClosure Libraryを一緒に使うには、まずClosure Libraryをダウンロードしてください。Closure Compiler ApplicationのClosure Libraryサポートはデフォルトで有効になっています。 Finding Your Way around ClosureにはClosure Libraryのパーツの宣言方法が説明されています。 私はソースコードに必ず表記しなければならない著作権やライセンスの項目を持っています。これらをClosure Compilerが行うテキストの除去から守るにはどうしたらよいですか? Closure CompilerはJSDocの @license タグをサポートしています。 @license タグを含む全てのJSDocコメントは、Compilerの出力の中で保護されます。より詳しい情報はアノテーションによる型定義を参照してください。 私の変数がページ上の他のスクリプトと確実に衝突しないようにするにはどうしたらよいですか? まさにその目的のために、Closure Compilerは--output_wrapperオプションを持っています。それは次のように呼び出されます: --output_wrapper "(function() {%output%})();" こうするとコンパイルされたコードは無名関数にラップされるため、グローバルスコープを汚染することはありません。 Closure CompilerをJava APIから呼び出すにはどうすればよいですか? Java APIのための正式なチュートリアルはまだありません。このブログの中の短いコードスニペットは、我々のみるところ、その方法を示す素晴らしく簡潔なデモであると思います。 もしあなたがClosure Compilerのソースコードを見たのであれば、AbstractCommandLineRunner.javaとCommandLineRunner.javaがコマンドラインオプションをJava APIの呼出しに変換するために大きな役割を果たしているのが分かったはずです。そして何かピンとくるものがあったのではないでしょうか。Java APIの包括的なリファレンスとしては、参照しやすいようにJavaDocがSVNにチェックインされています。JavaDocには常にその時点のtrunkの状態が反映されています。 Closure Compilerがスレッドを使用する点に注意してください。多くのJavaの実装(例えばGoogle App Engineのような)はスレッドをサポートしていないため、あなたはdisableThreadsメソッドをコールする必要があるかもしれません。 Externファイルをどう書いたらよいのでしょう? externファイルにはあなたのコードの外側にある(あるいは"external"な)APIを定義します。そこにはあなたがやりとりしたいと思っている外部の変数、型、プロパティが全て定義されているべきです。例えばClosure CompilerはwindowやDOMを扱うためのブラウザAPIについて何も知りませんが、代わりに我々はブラウザAPIを定義したデフォルトのexternファイルをClosure Compilerに搭載しました。このデフォルトセットはおそらくexternファイルの書き方についての最良のサンプルでしょう。見てのとおり、そこでは window のようなグローバル変数、 Range のようなデータ型、 Window.prototype.alert のようなプロパティなどが定義されています。 http //code.google.com/p/closure-compiler/source/browse/#svn/trunk/externs もしあなたが一般に広く知られているAPI(Google Maps APIのような)のexternファイルを必要としているなら、先ずclosure-compiler-discussで誰かが既にそれを書いていないか尋ねてみてください。externファイルのさらに詳しい情報はこのページでみることができます。 予想外の結果 ADVANCED_OPTIMIZATIONSでコンパイルするとコードが動かなくなるか、Compilerがエラーを出力します。なぜでしょう? ADVANCED_OPTIMIZATIONS を導入する場合、通常いくつかの準備とコードの書き換えが必要になります。Compilerが求めるコーディングルールには、あなたのコードを ADVANCED_OPTIMIZATIONS レベルで動作させるにはどうしたらよいかが説明されています。 Compilerが次のようなエラーを出してクラッシュしてしまいました: Exception in thread "main" java.lang.UnsupportedClassVersionError Bad version number in .class file Closure CompilerはJava 6を必要とします。これはJavaのバージョンをアップグレードするように促すJava流の表現です。 " Trailing comma is not legal "というエラーを受け取りましたが、そのコードはFirefoxで動いています。 しかしInternet Explorerではそうではありません。 IEでは、オブジェクトリテラル {key value,} はエラーです。 配列リテラル [1,] はエラーにはなりませんが、その解釈はForefoxとは異なります: [1,].length = 1 (on Firefox) = 2 (on IE) この違いはバグにつながる可能性が非常に高いため、明確に禁止しています。 " Unsupported syntax "というエラーを受け取りましたが、そのコードはFirefoxで動いています。 FirefoxにはJavaScript 1.5以後のクールな新機能が盛り込まれています。Closure CompilerはJS1.5と後方互換性を持たないいかなる仕様もサポートしません。それらには次のものも含まれます: const キーワード getter と setter 分割代入 Closure Compilerが文字列をインライン化したため、コードサイズが大きくなってしまいました。なぜこんなことをするのでしょう? ほとんどの人は圧縮されていないJavaScriptファイルを並べてコードサイズの大小を比較します。しかしこれはコードサイズの見方をミスリードするものです。なぜならあなたのJavaScriptファイルはgzip圧縮された状態で配信されるはずだからです。 Closure Compilerはあなたがgzip圧縮を使用していることを想定しています。もしそうでないなら、そうすべきです:コードのgzip圧縮は、考えられる内で最も効果的でしかも簡単な最適化手法のひとつです。 gzipのアルゴリズムはバイトシーケンスを最善の方法で別名に置き換えようとします。手動で文字列を別名にまとめるとほとんどの場合圧縮したときのコードサイズはかえって大きくなりますが、これはその作業がgzip自身の別名化アルゴリズムの効果を覆すものだからです。つまりClosure Compilerが(ほとんど)常に可能な限りの文字列をインライン化しようとするのは、圧縮されたときにコードがより小さくなるようにするためなのです。 Closure Compilerの設計について なぜコンパイルされたコードはランダムに改行されているのですか? Closure Compilerは約500文字ごとに意図的に改行を挿入します。ファイアウォールやプロキシは時々1行が非常に長いJavaScriptファイルを破損したり無視したりすることがあり、500文字ごとの改行はそれを防止するためのものです。改行を削除してもスクリプトのセマンティクスには影響がありません。ただ改行がコードサイズに与えるインパクトは小さく、またCompilerはファイルをgzip圧縮したときに悪影響がより小さくなるよう、改行の位置を最適化しています。 JSDocの型言語の仕様書はありますか? Closure Compilerの型言語はEcmaScript 4 draft spec(ここには型言語の厳格な文法と、それが意図するセマンティクスが説明されています)に可能な限り準拠しようとしています。 もっとくだけたチュートリアルもこちらのページにあります。 Closure Libraryを眺めていると、実際のタイプアノテーションの構文が仕様書と異なっていることに気づくかもしれません。しかしそれらは正しく解釈されており、通常、意図的なものです。我々が実装したEcmaScript 4 draftの仕様は流動的で、我々がサポートしているいくつかの文法は既に過去のものになっています。(それらの大部分は、型の結合に用いられる特定の演算子の順序に関するものです) 別な○○という構文をJSDocの型言語に追加してもらえませんか? もし〇〇が以前はできなかった何かを可能にするのであれば、先ずあなたのアイデアをclosure-compiler-discussに提案してください。 もし〇〇が他の方法で実現可能なのであれば、99%答えはノーです。 我々のJSDocの型言語をパースしているツールは既に多く存在します。新しい構文を追加した場合、それはそれらのツール全てがアップデートの必要に迫られることを意味します。ドキュメントの更新も必要ですし、JavaScript開発者はそれを学ばなければなりません。型言語はより複雑化するため、新しいツールの作成は困難になります。 新しい構文が本当の価値をそこに加えるのでなければ、我々はこのようなコストを正当化できません。 私はFirefoxのエクステンションを書いています。それは最新版のFirefoxでさえ動作すればよく、他のブラウザで動かなくても問題はありません。JavaScript 1.7で導入されているカッコいい機能を利用できるよう、 --platform=FIREFOX オプションを追加できませんか? 概ね、ノーです。理由は2つあります。 第1に、我々は怠け者です。かつてClosure Compilerの処理系は主にGoogleエンジニアのボランティアによって書かれていて、その頃の開発サイクルといえばこんな感じでした:"やあ!今のアプリの動作は遅いけど、この最適化処理を加えればもっと速くなるよ。午後にそのコードを書いて、それから通常業務に戻るとしよう。" ほとんどの開発者はJavaScriptのエキスパートではありません。従ってJavaScriptの2種類のバリエーションを理解しなくてよいことは、開発者達が新しい処理系を書くことを容易にするという点で我々にはとても重要だったのです。 第2に、我々はコードを共有することが好きです。私が自分のFirefoxエクステンションのためのJavaScriptクラスを書き、そこではFirefoxだけで有効なキーワードが使われているとしましょう。2ヶ月後、友人のKushalがそれを気に入り、彼のWebアプリに組み込もうとします。彼のWebアプリはInternet Explorer上で動作する必要があります。しかし全てのgetterとsetterの書き換え はあまりに手間のかかる作業で、自分で最初からコードを書いたほうが早いと気づいた彼は組み込みを諦めてしまいました。これは私にも彼にも不幸です。そして分かったのは、コードがクロスブラウザで動作し、共有がしやすければ、誰もがより幸せになれるということです。
https://w.atwiki.jp/yaruhara/pages/49.html
がんばれ!菜月さん!モジュール仕様書 ソースファイル がんばれ!菜月さん! Ver1.11(コメント付きソース) http //dij7.fc2web.com/alpha/data/natuki.zip ソースファイルはD.Kが作成したものですが、自由に使用してかまいません。 概要 過去に作成したソフトを含めたプログラムの構成をまとめる。 構成は大きくは同じため、ここでは「がんばれ!菜月さん!」についての構成を記述する。 ソフト作成に使用しているツールは「YGS2000」使用している。以下「YGS」と記述。 製作者のホームページ:http //yaneurao.hp.infoseek.co.jp/ygs/ 使用ツールについて YGSは独自のスクリプト言語となっている。 しかし書式はCに近く自由度も高い。Cプログラムが可能ならゲームソフト以外のWindowsのソフトも作成可能となっている。 DirctXを利用するためのクラスが全てラッピングされ、ユーザはDirectXを意識することなくC言語の感覚でDirectX利用したコードを記述できるため使用している。 設計概要 YGSでは1スクリプトファイル内に1つのmain関数をもたせることができる。 スクリプトジャンプ機能が用意されており、スクリプトから別スクリプトへ移行することが可能となっている。 別スクリプトへジャンプすると、現在の動作しているコードは開放される。 ジャンプ先のスクリプトファイルがコンパイルされオブジェクトがスタック領域へ作成されmain関数が実行される。 ジャンプ前の変数、関数は開放されるため参照は出来ない。 スクリプトファイルを画面単位で作成し、この機能を使用することで各画面が独立したクラスに近いイメージで作成することが可能となる。 これにより画面の追加、削除時に発生する作業量は少量となり、別ソフトで作成した資産をそのままスクリプトファイルの入れ替えで組み込むことが可能となるため、コードの再利用性も高くなる。 スクリプト間で参照できる共通のグローバル変数はgameflag[512]だけとなっている。 各画面スクリプトファイルはここに次の画面遷移状態を保存し、画面管理スクリプトへジャンプを行う。 各画面スクリプトファイルはgameflagの情報のみを参照して現在の状態へ初期化を行えばよい。そのためgameflagをインターフェースとして前に表示していた画面がどの画面であるかを意識したコードを書く必要が無くなり、完全に独立した形で各画面の作成作業を。行うことができる。画面遷移の変更がも容易となる。 またgameflagを保存する事で、そのままプレイヤーのセーブデータとすることが出来る。 gameflagバッファにファイルを読み込むことで、各画面は必要な状態に初期化を行い表示されるため、セーブ機能の追加が容易となる。 前画面を意識させない設計によってステージデータの書き換えを実現している。 初期化処理を統一することで、初期化漏れなどの潜在的不具合の発生を防止する。 以下に概要を示す。 ステージファイル読み込み処理フロー 以下にスクリプトファイルの関連を示す。 スクリプトファイル関連図 画面スクリプトファイル 画面スクリプトファイルで行う処理は、全ての画面で同じとなる。 以下に画面スクリプトファイルの処理フローを記述する。 画面スクリプトファイルの処理フロー 画面スクリプトファイル内でのシーン管理 gamemain.cでは内部でさらにシーン管理を行っている。 スクリプトファイルをジャンプしてしまうと、以前のスクリプトファイルの情報を参照することは出来ないため、スクリプトファイル内の情報が必要な画面遷移は内部にシーン管理が可能な設計とする。 以下にシーンを示す。 シーン関連図 シーン管理は描画処理とキー入力処理を、それぞれのシーン用に作成することで実現する。 以下にgamemain.cのシーン管理部フローを示す。 シーン管理部フロー シーンに合わせた描画処理とキー入力処理を作成することで、シーンの追加ができ 描画処理、キー処理をやめることでシーンの削除を行う事が出来る。 シーン追加時に作成するべき処理を具体的にすることができる。 表示オブジェクト プレイヤー、プレイヤー、アイテム、敵、破片など画面に表示され、独立して動作を行う。 各オブジェクトで使用するメモリ領域 メモリ領域はグローバル変数として全て静的に確保する。 使用するメモリ空間を明確にし、メモリリークやメモリ不足、想定外のキャラクター数による不具合などの潜在的不具合を防ぐ事を目的とする。 YGSでは構造体が使用できないため、全て1次元の配列として取得している。 1次元の配列を構造体に見立てて参照する。オブジェクト変数へのインターフェース関数を用意しオブジェクトポインタ(=オブジェクトインデックス)を引数として参照を行う事とする。 オブジェクトの生成 各オブジェクト用の変数にそれぞれにオブジェクトを作成するインターフェース関数を用意する。 引数は、種類、初期位置などを渡す。 空きバッファを検索し、見つかった場合にはオブジェクトはバッファ内に生成され、以降消滅までオブジェクトが自動的に動作を行う。 空きバッファが存在しない場合、生成は行わない。 オブジェクトの表示、動作 各オブジェクトの表示関数を用意する。表示関数は描画処理関数で呼び出される。 オブジェクト変数を検索し、生成されているオブジェクトが発見された場合、パラメータから表示と、動作を行う。 当たり判定を行う場合は存在数の少ないオブジェクトが、存在数の多いオブジェクトを検索し当たり判定を行う。