約 2,546,648 件
https://w.atwiki.jp/yuyasaito623/pages/16.html
第1章 ゼロの物語 ゼロは実質的な量はもたないが、桁を埋める役割を果たし、ゼロのおかげでシンプルな位取り記数法が可能となる。 この穴埋めをプレースホルダー（placeholder）といい、プレースホルダーはパターンを生み、パターンはシンプルなルールを生む。 第2章 論理 論理は「あいまいさ」を無くす道具である。 網羅的で排他的に分割することで、大きな問題を小さく分割して考えることができる。(ミッシー？) 網羅的・・・漏れがない。 排他的・・・かぶりがない。 含意・・・AならばB ド・モルガンの法則（双対性） 「Aでない」または「Bでない」は、「AかつB」ではないに等しい。 「Aでない」かつ「Bでない」は、「AまたはB」ではないに等しい。 カルノー図 1.青いランプが消えていて、黄色いランプも消えていて、赤いランプも消えている。 2.黄色いランプは消えているが、赤いランプは光っている。 3.青いランプは消えているが、黄色いランプは光っている。 4.青いランプも黄色いランプも赤いランプも光っている。 ・命題A「青いランプは光っている」 ・命題B「黄色いランプは光っている」 ・命題C「赤いランプは光っている」
https://w.atwiki.jp/drip122/pages/34.html
暗号化後のバイト配列が16進数だとわからずにStringにして、ファイル出力しててはまった。 そもそも、ファイルに文字化けした暗号文が保存された時点で対策を打つべきだった。 文字化けしてる時点で、非可逆になることは想定できたはず。 *Java暗号・復号プログラム Blowfish方式の暗号・復号サンプルを示す。 import javax.crypto.spec.*; import java.security.*; import java.io.*; import org.apache.commons.codec.binary.Hex; public class Blowfish { /** * 暗号化するメソッドです。 * @param key 鍵です * @param text 暗号化したい文字列です */ public static String encrypt(String key, String text) throws IllegalBlockSizeException,InvalidKeyException,NoSuchAlgorithmException, UnsupportedEncodingException,BadPaddingException,NoSuchPaddingException { SecretKeySpec sksSpec = new SecretKeySpec(key.getBytes(), "Blowfish"); Cipher cipher = Cipher.getInstance("Blowfish"); cipher.init(Cipher.ENCRYPT_MODE, sksSpec); byte[] encrypted = cipher.doFinal(text.getBytes()); return new String(Hex.encodeHex(encrypted)); } /** * 複合化するメソッドです。 * @param key 鍵です * @param text 複合化したい文字列です */ public static String decrypt(String key, String text) throws IllegalBlockSizeException,InvalidKeyException,NoSuchAlgorithmException, UnsupportedEncodingException,BadPaddingException,NoSuchPaddingException { byte[] encrypted = null; try { encrypted=Hex.decodeHex(text.toCharArray()); }catch(Exception e){ e.printStackTrace(); } SecretKeySpec sksSpec = new SecretKeySpec(key.getBytes(), "Blowfish"); Cipher cipher = Cipher.getInstance("Blowfish"); cipher.init(Cipher.DECRYPT_MODE, sksSpec); byte[] decrypted = cipher.doFinal(encrypted); return new String(decrypted); } } -参考URL --http //pinoki.la.coocan.jp/wiki/?cmd=read page=Java%2F%B0%C5%B9%E6%B2%BD%2FBlowfish%CA%FD%BC%B0
https://w.atwiki.jp/yonryuu/pages/2.html
メニュー トップページ 戦国 Android リンク @wiki 四流プログラマが苦しむ日記 ここを編集
https://w.atwiki.jp/silphy1001/pages/2.html
訪問者数 合計： - 今日： - 昨日： - トップページの合計： - タグ テスト駆動 テスト駆動開発による組み込みプログラミング Linux TDD C プログラム プログラマ LFS Linux for Scratch C/C++ NVIDIA GeForce GTX CUDA テスト駆動開発 ソート Codeanywhere SE POSIX拡張 URL 正規表現 qsort Qt ソーティング 値渡し CDB 設定 ツールチェイン C++ 一時オブジェクト 参照渡し Visual Studio 文字列 VS ユニットテストフレームワーク 単体テスト ユニットテスト C言語 マルチバイト VC ワイド 直近の更新 取得中です。 メニュー トップページ プラグイン紹介 まとめサイト作成支援ツール リンク @wiki @wikiご利用ガイド 他のサービス 無料ホームページ作成 無料ブログ作成 2ch型掲示板レンタル 無料掲示板レンタル お絵かきレンタル 無料ソーシャルプロフ ここを編集
https://w.atwiki.jp/charolles/pages/23.html
ゲームプログラマになる前に覚えておきたい技術 著 平山尚 参考サイト http //watery.dip.jp/slash/archives/1296
https://w.atwiki.jp/sinapusu2002/pages/187.html
フリーのプログラマを目指そうかと考えている。 しかしフリーというのは全て自己責任、守ってくれる組織もなければ他人もいない。 リスク管理から考えるのは当然だろう。 そこでリスク管理について少し考えてみる。 1 損害賠償請求の危険性 納品を繰り返せば確率上いつかは不具合で先方に迷惑をかける危険性がある。 場合によっては損害賠償請求されるだろう。 法律は会社のほうが詳しいし、フリープログラマに味方はおらず、裁判に当たって提出される資料は会社側のコントロール下にある。 すると身を護るすべも勝ち目もない。（こちらにあるのは先方に損害を与えたという負い目だけだ） 契約書を精読するとか、不良品を納品しないとか、会話を録音しておくとか少しでも身を護るすべを考えなくてはいけないだろう。 （フリーなんて会社から見れば替えのきく赤の他人、返済地獄で苦しんでも痛くも痒くもないはずだ。） ２ ヒアリング不足 ソフトの仕様を決めるにあたって担当者からのヒアリングをしっかりしないといけないと考える。 でないと後から想像していたのと違う、バグで損害が出たなどといわれると困る。 困るのは企業先の担当者がソフトについて思い違いをしていたり、ソフトや仕事上のバグにつながる重要な話を知らない場合である。 こちらは聞いた通り完璧に納品したのに、担当者が何かを思い違いをしていたせいでソフトに不具合があると怒られたり訴えられてはたまらない。 渡された使用書に構造的バグがある場合、それをフリーの立場から指摘すべきかどうかも問題である。 ３ 赤字地獄 ランサーズなどでは5000～50000円でソフトを作ってほしいという依頼が平気で飛んでいる。 その予算の中でソフトを納品するため先方の指定した特殊で値段の高いソフトを買ってそれを使ってソフトを作ったら赤字になるかもしれない またサーバを会社に設置しに行くだけでも利益がかなり削られる可能性が高い。 レンタルサーバの形で納品しようとしても結局コンペで他の人が採用されればサーバ代が無駄になる（安い仕事ではそれでも響く、最悪赤字になる） そしてその値段を提示する人がまともな保守費用を払うとは思えない。 保守だと確実に最初の5000円～50000円より安いだろう。 守秘義務があるため大阪の会社まで毎日来てくださいといわれていってみたら、こまごました仕事が追加されて交通費だけで予算オーバー赤字。 赤字だからって仕事を放り投げる奴だなんて評判が立つわけにはいかないだろうし、赤字でも泣く泣く仕事を続けなくてはいけないかもしれない。 仕事を引き受けるときはよく考えないといけない。 4 保守業務の集中 仕事が一時にドカッと集中した場合。 保守の納期に間に合わない仕事が出るかもしれない。 するとどれかを断る必要があるかもしれないが、これは評判にかかわる。 どうしたものだろうか？ 体は一つ頭も一つしかない。 平謝りしかないのかもしれない。 契約によっては、納期を守れずで損失補てんを要求される可能性もある。 （企業から見れば、ありがたい人員に見える時もあるだろうけど、フリーなんて使い捨てのティッシュペーパーのような扱いにもなりうる）
https://w.atwiki.jp/c21coterie/pages/78.html
作業中 ここではオタピッタンのプログラマ向け仕様書を提案する。 主に盤面や選ぶ君でのデータ的な処理を行い、画像関係には一切手を触れず、データの操作のみに関わる処理である。 画面周りはここで作成したオブジェクトを元に作成することになる。 非常に多くのギミックを実装することになるので、一通り下記のギミック一覧を参照すること。 ギミック一覧 http //www14.atwiki.jp/c21coterie/pages/74.html 仕様書についてはイラスト入りで丁寧に解説を行っているので順番に読み、何度か読み返せば確実に分かるように作ったつもりである。 抜けがあるかもしれないので説明の分かりにくい部分、記述の不十分な部分などを見つけた場合積極的に質問して欲しい。 連絡先 sin-horie@mvd.biglobe.ne.jp 非常に細かく説明を作ったが、これには以下の理由がある。 プログラマが何らかの理由で交代する時、引継ぎの手間を軽減する。 将来ステージ製作者が参加したとき、必ず新しい視点からの新しい要求やギミックが提案される、その時整然と追加機能をつけられるよう、最初のうちから丁寧に記述する必要がある。 別チームがこの企画に興味を持ち派生版を作成したくなった時、楽に引き継げるようにする このゲームの開発記録を元に初心者向けゲーム製作本「オタピッタンで覚えるゲーム製作」等を作成し小金をもうける予定である。このとき流用しやすいように作る必要がある。もちろん作成するのはプログラムに詳しくない初心者向けの本であり、本にする時にはより丁寧できちんとした順番で説明を行う 等の理由から丁寧につづっている。 まだ説明は作りかけであり、各ギミックの細かい仕様については後日記述する。 以下仕様書本文。 序文 用語の定義 始めにオブジェクトの一覧を表す。 Stageオブジェクト stageを現す Stage.map 文字を置いていく盤面を現す n行ｍ列の配列でＭａｓｕオブジェクトへの参照を持つ Masu オブジェクト 一つのマスを現し多種類のギミックを持ち多様な種類がある。 mozi オブジェクト 盤面においていく文字、最初は選ぶ君に入っていてこれも多種類あり、実装する必要がある。 stage.erabukun 選ぶ君をあらわす。 図で説明する。 例えば上記盤面ではstage.mapは５行１１列の配列で それぞれのマスにマスオブジェクトが参照されている。 この盤面で赤丸部分に文字を入れたとすると、"あいこう"や"眼光"など色々な単語が出来て得点が入るが、この処理を"文字列探索・得点処理"と命名する。 マスオブジェクトは非常に豊富なギミックを持つためたくさんのプロパティを持ち Mapオブジェクトはマスオブジェの操作を行うためのメソッドを持つ。 詳細については別ページに用意した。 裏企画_オブジェクトのプロパティメソッド一覧要印刷 裏企画_プログラム定数一覧表要印刷 両方とも現在準備中。 文字を置いた時のフロー。 #ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (zyobun3.jpg) まず文字の種類（巨大文字やギミック文字）とマスの種類から、そのマスに文字を置けるかを決定する。 置けたら、適切な順番でギミック毎に処理を行う。 "文字列探索・得点処理"を行うかどうかはギミックの種類次第となる。 ちなみに右に書いてあるのはギミックが効果を表すタイミングである。 最後の処理は、毎ターン自動実行されるギミックである。 文字の探索方法とギミックの種類 ここでは文字の探索方法を説明する。 上記のような盤面で赤丸に文字を置いた時どう処理すればよいかを説明する。 図A 上記のように全経路探索を行うことになる。 赤丸から出発して全ての全経路探索をし、最後に左側、真ん中、右側の文字列を組み合わせることになる。 全経路探索には亀のたとえ話を使う。 亀は、左向きＬと右向きＲの２種類。 亀は、マスにはいるたびに文字と、通ったマスオブジェクトを覚えながら（バッファに溜め込みながら）ヒトマスずつすすむ。 ２*２マスなどの分岐のできるマスにたどり着くと、そこで片方の道を選び進む。 先が進めない行き止まりになるか、覚えた文字が８文字になると、そこで進んだマスのリストと文字を記録してから、引き返して手前の分岐点まで戻り、また文字を覚えながら分かれ道を進む。 亀はこれを繰り返しながら、再帰による全経路探索を行うことになる。 次の行き先が提示されたら、次のマスが進入可能か調べ、進入可能なら進み、不可なら戻るだけである。 全ての経路を通るまでこれを繰り返し、全ての経路を調べたら２匹の亀の集めた文字列 と、真ん中の文字列を組み合わせを調べ、単語になっているかのチェックを行い得点を計算する。 文字列の組み合わせ方法。 下図にあるように全ての組み合わせを求めることになる。 亀には左向きと右向きいる。 左向きはユーターンマスを通れないが、右向きは通れるという違いがある。 例では左右の場合のみを提示したが上下でも同じである。 亀が巨大マスに入った場合について説明する。 上図では亀が右向きで巨大ますに入ってきた場合rightCol+1列目（ここでは7列目）の4,5,6行目が亀の次に進む道になる。 注 rightCol="マスオブジェのプロパティでマスの右端列を現す整数型" ここで5行目は先がないので亀は進まない。 また巨大マス例2のように、先行きが同じ場合もあるので、亀の行き先を提示する前に重複した行き先を削除すること。 右向きの場合について説明したが,上図で亀が左向きならleftCol-1列目(3列目)の4,5,6行目となるし、上下でも基本的な処理は同じである。 注 leftCol="マスオブジェのプロパティでマスの右端列を現す整数型" Ｕターンマスの実装についても同じのりとなっている。 Ｕターンマスの特徴は右向きに入ったら下向きに出るなどの単純な対応が存在することであり、その対応表を力技で作成することで作成することが出来る。 ユータンマス参考図 上図Aでは左や下や右からマスにはいろうとしても入れないが、上からなら入れる。 よって亀が次のマスに進めるか判断する時には上から以外拒否し、上からなら次に右のマスを示せばよい。 Bでは複雑な形のユータンマスの作り方を示している。 ユータンマスには色々なパターンがあるが、分岐のあるマスも存在する。 その場合は巨大マスと同じ分かれ道として扱う。 参考画像準備中 ユータンマスの詳細なリストについてはこちらを参考にして欲しい。 ユータンマス種類一覧準備中 ユーターンマスを導入すると亀が同じ場所をループする場合がある。 それを防ぐために、亀に条件判断を付け加える。 亀は同じ順番で同じ場所を通ったら探索をやめて引き返す。 一定マス以上進んだら引き返す。 等の条件判断を付け加えることでこれを回避する。 概論について説明が終わったので次は詳細なギミックについて解説する。 ギミック一覧 ここから先は各ギミックについて詳細に解説する。 種類ごとに分けて紹介しているので実装においてはそんなに困らないはずである。 文字系ギミック 得点処理が起こらない文字ギミック ここで紹介するのはえらぶ君から選んで盤面に使用することで、効果を発揮するギミック群である。 消しゴム文字 回収文字 ギミック文字 ギミック回収文字 の４種類となる。 得点処理が行われないので、シンプルに記述できるものばかり、肩慣らしと思って良い。 #ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (mutokutenGimkku) 0 消しゴム文字。 適用する升目のマスオブジェクトの文字を空白文字にして、あとは処理終了だけの単純な文字である。 消しゴム処理後は"自動実行ギミック"まで処理を飛ばす。 消しゴム文字はプロパティをType=0 mogi=""として普通の文字同様に扱い、マスに文字があるならその文字を""にして終了する。 文字が無いマス、文字を置けないマス(マスオブジェのmoziOKフラグがFalse)に対しては適用できない。 具体的な処理は、マスに文字を置く"文字置き時イベント"に、消しゴム文字専用の分岐処理をつけて行う。 フローチャート 適用がコピー枡の場合、白紙へのコピーは起こらないとし、適用したマスの文字だけが消える。 1 回収文字 文字オブジェクトのプロパティをtype=1 mogi=""として扱う。 適用マスに文字があるなら、その文字を盤面から回収して白紙マスにもどし、文字をえらぶくんにもどす。 基本的な処理は消しゴムと同じ、回収した文字をえらぶ君に追加するAddMoziメソッドが増えているだけである。 Copyマスに回収を適用した場合、関係するCopyマスを白紙にする必要はない。 CopyマスのCopyが発動するのは文字が置かれた時のみとなる。 2 ギミック文字 盤面にギミックを置き、上書きできる。 #ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (gimikkumozi.JPG) 具体的な処理について。 文字オブジェクトのプロパティをtype=2 mogi=""として扱う。 基本の文字オブジェクトに、マスオブジェクトを保持するためのmasuプロパティを追加する。 マスに適用するときは、升目の参照している升オブジェクトへの参照を削除し、文字オブジェクトのマスオブジェクトを参照させる処理を行う。 ６行８列目のマスを変更する例。 mm=mozi.masu smm=stage.map(6)(8).masu mm.itiCopy(smm)//先頭行や最下端行などの位置情報やマスオブジェを参照している升目をコピーする。 stage.setMasu(mm) 置き換える メソッドの詳細については裏企画_オブジェクトのプロパティメソッド一覧要印刷で紹介する。 置き換え後は"文字列探索・得点処理"を行わず、"毎ターン自動実行ギミック"まで処理を飛ばすのは消しゴム文字と同様である。 ギミック文字に使用できるギミックの種類と、巨大マスへの適用時の詳細は後日記述する。 ギミックマス適用時の詳細な定義づけはリンク先で行う。 裏企画_ギミック文字適用時詳細準備中 3 ギミック回収文字 回収文字が文字を回収するように、盤面からギミックを回収する事が可能。 回収したギミックはギミック文字とし、addMoziメソッドを使用してえらぶ君に追加する。 改修先のマスは白紙マスに戻す。 巨大マスに適用する場合。 追加時の注意としては回収先のマスが巨大マスの場合、大きさは無視し、1*1マスのギミック文字としてえらぶ君に追加する。 回収先のマスは単なる白紙の巨大マスとする。 回収できるギミックについてはギミック文字で使用できるものと同様とする。 具体的にはマス種類を現すType(実数)に基づいて回収可能かどうかを判断する。 処理終了後は、"毎ターン自動実行ギミック"まで処理を飛ばす。 文字系ギミック２ 得点処理が起こる文字ギミック 上書き文字 引っ張り文字 繋がり文字 巨大文字 フローを示す。 #ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (tokutenGimkku.jpg) ここまでのギミックとの違いは得点処理がつく点である。 上書き文字 mozi.type=4 文字を上書きする。 そのマスに空文字もしくは文字が存在し、マスオブジェのmoziOKフラグがＴｒｕｅ の時に限り文字を上書きし、その後は普通に文字を置いた時と同じ処理とする。 参考画像。 引っ張り文字 上下左右にある文字を引っ張り集めるギミック。 図で説明する。 A点に引っ張り文字が置かれた時のイメージ。 青線が引っ張り先。 巨大マスを通る場合同じ行同じ列が優先される。 引っ張り後。 文字が引っ張られていることを確認して欲しい。 注目すべきは２つ、巨大マスに入った時の引っ張りは同じ行列優先となっている事。 もう一つはユーターンマスを超えて文字が移動できないので止まってる文字と、ユータンマスを順当に移動できるのでAマスの隣まで引っ張られる文字がある。 "あ"はユータンマスを逆走できずに止まっている。 "い"は引っ張りの手前まで、"う"は引っ張られたがユータンマスの上が文字置き禁止なので手前で止まっている。 "" また、文字置き不可のマスには文字を置けないので手前で止まっている文字があることを確認して欲しい。 引っ張り処理を亀で説明する。 亀が上図で説明された効果を起こすために、一つずつ文字をひっぱて全部の文字を引っ張てくる。 亀はルールに従い、経路探索を行い、文字を引っ張る順番を決めて文字を引っ張る。 1 巨大マスには行った時同じ行列を通る。 2 ユータンマスでは文字を持って帰るとき、ユータンマスを超えれず、そのマスに文字を置いて、文字を置いた枡を出発点にまた文字を詰めていく 亀がA点でひっぱている場合の処理。 亀は自分の通ったマスのリストを覚える。 そして右側の文字から順に右端に詰めていくわけである。 より詳細な使用 引っ張り文字の効果によってCopyマスの効果が発動する時は、最後に亀が置いた文字となる。 ユータンマスによって複雑な引張りが起こり、複数の方向からの引っ張りが生まれた場合、引っ張り文字からの升目数が少ない方を優先する。 同じ場合、先にひっぱた方を優先する。 ユータンマスの出口が一つしかない場合、そちらの方向を引っ張る。 ユータンマスの出口が２つ以上あるときは、まっすぐを優先する。 T字路の場合、止まる。 巨大マスのユータンがある場合、近い方を優先する。 (ただし巨大マス+ユータンマス+引っ張り文字の組み合わせは非推奨とする) 繋がり文字。 "文字の探索方法とギミックの種類"で紹介した亀を必要な数だけ用意し７文字か８文字探索させることで整合性を取る。 参考図。 #ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (tunagarimozi.jpg) 上手の場合青方向に７文字まで調べる亀を２匹で１セット、赤と緑方向に８文字まで調べる亀を１セットずつの計３セットで順番に探索を行う。 もちろん２文字のどちらかが文字を置けないマスにかかる場合当然のことながら繋がり文字は置けない。 巨大マスに置く時は、マスのmoziプロパティを変更するだけでよい。 長方形の巨大マスが乱雑に入り組んだステージではユーザーインターフェイスの作成が困難となるが（どのマスに埋め込むかの操作を簡単にすることが困難）、ここではそこまで踏み込まない。 巨大文字 2*2や1*3などいろいろな形があり意外と厄介な問題を控えている。 解決策は３種類ある。 どれがいいか決定するために、プログラマはぜひとも３種類作って欲しい。 タイプ１ 文字より大きなマスの中にしか置けない。 ２*２マス文字なら3*3や2*2や2*3等には置けても、1*3や1*1などには置けない。 タイプ２ 下にあるマスのフラグがmoziOK=trueかつ、２＊２マスなどを半端にさえぎってない限りは文字を置ける。 参考画像準備中。 タイプ３ 問答無用で下にあるマスを無視して置き換える。 巨大マスを切っておいた場合、切られたマスは白紙の1*1マスとして処理する。 参考画像準備中 升目ギミック１ 文字の探索に関わるギミック ユーターンマス 壁 ラウンドマップ お邪魔ブロック フロー画像準備中 ユーターン枡 最初の"文字の探索方法とギミックの種類"で説明したので飛ばす。 壁 ユーターンマスと同じように対応表を用意すればよい。 壁の場合、一工夫して壁の立っている向きをデータで持たせて、亀（文字の探索方法とギミックの種類で説明した比喩キャラ）が壁の立っているほうからマスを出ようとしたり入ろうとしたら、その進行は不可だと亀に伝えることで処理をする。 壁の立っている向き UP,Down,Right,Leftを u,d,r,lとする. データ例。 masu.kabe="u,r" マスの上と右に壁が立っている。 masu.kabe="d" マスの下に壁が立っている このkabeプロパティのデータに従い、壁のあるマスへの進入可不可をより分け亀に伝える。 ラウンドマップ ユーターンマスと同じように、次のマス座標を指し示すだけでよい。 亀がワープするだけである。 参考画像準備中 ただし、ワープ先は、亀が通るたびに逐次探索し、同じ行の一番左にあるマスへワープさせること。 これは、ただ単に升目の激しい移動が行われるステージに対応するためだけである。 お邪魔ブロック 升目の上を閉路巡回し、下のマスを隠す邪魔なブロック。 閉路巡回については、巡回先の座標をリストとして持つ。 お邪魔ブロックはstage.ozyama[]の配列に、ozyamaオブジェクトとして格納する。 ozymaのプロパティは以下のとおりである。 one=stage.ozyama[0]//複数いるお邪魔ブロックの一つを取り出す one.root 道順を現す。絶対座標で複数のリストを持つ。 one.masu マスオブジェクト、このマスオブジェクトで下にあるマスを置き換える。 ブロック同士が同じマスにブッキングした場合 配列の添え字の大きい方が上にかぶさるとするが、基本的にはルートが被らないのが望ましい。 ブロックの移動は、毎ターン自動実行ギミックの時に行う。 裏設定であるがお邪魔ブロックの正体は、盤面を歩き回る虫で背中にマスを背負っている。 色々と種類があり、豊富な要素を持つとする。 またこの設定に基づいた、追加ギミックも考えている。 升目ギミック２ 升目に変化を与えるギミック A群 くぼ地マス 爆弾マス B群 めんこマス くぼ地マス 名前のとおり普通より深いマスで深さ分だけ文字を置ける。 白紙マスを元に、文字を置ける回数をカウントする変数を追加しただけで, 文字が置かれるたびに、この変数を減らすだけである。 基本的な処理は白紙マスと同じである。 爆弾マス イメージはそのままボンバ○マン。 時限爆弾タイプで、"毎ターン自動実行ギミック"処理のたびにカウントされ、爆発すると爆発先の文字が吹っ飛ぶ。 爆発の形はボンバーマンそのままとする。 爆弾の破壊力も設定され、数字が大きいほど被害を受ける範囲が広くなる。 ステージ開始時に爆発の範囲を表示する必要があるので、爆発の影響範囲のリストにいつでもアクセスできるようにしておくこと。 爆発範囲に巨大マスがある時は、同じ行同じ列を保って爆発を直進させることとする。 また、ユータンマスでは爆発の方向を曲げることが可能とする。 参考画像。 爆弾の影響範囲は４マスまでの場合を示す。 赤いラインが爆弾の影響範囲であり、このラインが通ったマスの文字が消える。 爆発範囲を求めるには引っ張り文字で説明された、引っ張り亀と同じ探索を行う。 めんこマス 白紙マスに裏面のマスを現すMassオブジェクトと、今表か裏かを保持する変数を追加するだけでよい。 メンコマスは文字置き時に、マスの表裏がひっくり返るので、文字を置くたびにチェックが要る。 文字置き時、周囲のマスに面子マスがないかを確認し、あればメンコをひっくり返せばよい。 コードが汚くなるギミックなので、チェックとひっくり返し処理はメソッドとすること。 魅力度低のギミックなので最後に実装してよい。 升目ギミック３ マス移動に関わるギミック 平行移動 回転移動 巨大マスとやたらと相性が悪いギミックである。 元祖"もじぴったん"でも巨大マスへの回転や平行移動の処理は基本的に行われていない。 下図イラストに代表されるように定義困難な状況が多数発生するので、巨大マスへの回転・平行移動適用はステージ製作者の自己責任とする。 しかし巨大マスへの回転・平行移動も可能な場合があるので一応定義しておくとする。 基本的な考え方。 平行移動については、頻繁に行われるわけでないことから実装はシンプルに行う。 基本的な考え方はシンプルである。 移動しないマス一覧＝盤面のマスの存在する部分のリスト-平行移動するマスのリスト 移動後位置＝移動するマスの座標を平行移動させる 移動しないマス一覧 と 移動後位置に重なりがなければ移動可能とする。 でなければ移動させないとする。 参考画像準備中 回転についても、基本は同様である。 元祖もじぴったんでは60度120度60度120度で一周するなどの変わった回転が存在するが、これについては後述する。 回転については２種類の方法を用意する。 1 基本回転 指定地点を中心とした90度の回転行列とする。 回転行列だけでよいのでバグも特に出ず実装が容易となる。 ２ リスト形式 回転するマスのリストを保持する。 この場合リストをマスオブジェクトへの参照とするもよし、絶対座標とするもよしである。 両方をサポートしたメソッドとプロパティを用意して欲しい。 回転後定義不可能状態になる場合、回転を行わない。 これは元祖"もじぴったん"において、移動先が詰まってた場合平行移動が行われないのと同じである。 次のギミックに移る。 盤面に文字が置かれるたびに無条件に効果が発動するギミック 毎ターン自動実行ギミック。 盤面に文字が置かれるたびに、無条件に自動実行されるギミック。 風化マス、コンベアマス、幽霊マス 風化マス マスに置いた文字がターンが立つごとにだんだん風化して一定ターン過ぎると文字が完全に消える。 文字が消えるまでの時間は任意で設定可能とする。 風化マスに文字が置かれているなら、カウントして変数が0になったら文字を消すだけの簡単な処理とする。 コンベアマス 文字が置かれるたびに、コンベアが動き上に置かれた文字を運ぶ。 現実のコンベアと同じように移動先がつまってたら文字は移動しない。 参考図。 コンベアマスは一連の繋がった升目のリスト形式で保持される。 コンベアマスの上に置かれた文字は、毎ターン移動し、リストの順番どおりに移動させる。 stage.conbea[]の配列から参照される。 参考画像準備中。 コンベアマスには端っこが切れたタイプと周回するタイプの2種類ある。 端切れタイプはコンベアの先端から文字を動かすことで、コンベア詰りを正確に表現する。 周回タイプは文字が周回するだけである。 画像準備中 コンベアについてはコンベア管理専用の小さなオブジェクトを作ることで解決する。 注意点。 コンベアマスには絶対に平行移動や回転などを適用してはいけない。 定義困難な状況が生まれるからである。 その為にmoveOkフラグをマスオブジェクトに用意してあり、これにFalseと設定してあるならそのマスを動かしてはいけないとすることで実現する。 幽霊マス メンコマスの裏面をNullマスとして設定する。 メンコとの違いは盤面のどこに文字がおかれようが自動実行させること。 メンコマスと同じく魅力が低いので最後でよい。 2行3列や４行2列などの巨大マスがもたらす問題。 ここでは、巨大マスのもたらす問題について説明する。 巨大マスはありとあらゆる種類のギミックと相性が悪い。 1*1マスのみでやっている限り問題ないのに巨大マスを導入すると、恣意的な処理が無数に発生する。 それは足し算引き算だけの世界に割り算が導入されて0除算エラーが生まれるが如しである。 参考画像 詳細については後日記述する。
https://w.atwiki.jp/denpaprog/pages/12.html
電波プログラミングとは何か？ 電波プログラミングとは、「超計算機的なロジックによって構成されたプログラム」である。超計算機的とはその原語meta-computational の意味する通り、メタ的な意味において計算機を超越した論理に基づいて計算機プログラミングを行うことに他ならない。 超計算機の概念を説明するために、その対極の概念である「計算機的」プログラミングを例示しよう。 例として偶数かどうかを判定するプログラムを思考する。多くの計算機的プログラマは以下のように実装を行うだろう。(コード例はCである） bool IsEven(int number){ if( number % 2 == 0){ /* %2の剰余が0であるかを判定 */ return true; }else{ return false; } } %は言うまでもなく剰余を求める演算子である。この部分はあるいは以下のように書き換えることができるだろう。 if(number 1 == 0){ /* 最下位ビットが1であるかそうでないかを判定する */ 質のいいコンパイラを使えば前者のプログラムと後者のプログラムはほぼ等価のアセンブリコードとなることが容易に推察できる。つまり、我々の通常の思考するプログラムとは「偶数かそうでないか」という自然科学的なロジックを「最下位ビットが0であるかそうでないか」という計算機的なロジックに変更することによって成り立っていると言える。 対して、電波プログラミングはある概念を超計算機的なロジックによって実装することになる。 const static bool even_check[]={true,false,true,false, true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false, true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false, true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false, true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false, true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false,true,false, 省略 }; /* 可能な限り記述 */ bool IsEven(int number){ assert(size_of(even_check) number || number 0); return even_check[number]; } このプログラムの最も着目すべき点は 最初にeven_check配列に偶数であるかそうでないかを代入しておくところにある。つまりこのプログラムを作成したプログラマはeven_check配列を通じて「偶数は0から一個とびにある数字である」または「偶数と奇数は交互に繰り返す」という内的ロジック＝超計算機的ロジックを、そのままの形で実装していることになる。（さらに言えば、非常に大きな数－例えば一億五千八九四のような数字、またはマイナスの数字に関しては、それが偶数であるかそうでないかは当然不明である、というプログラマの論理的限界そのものも記述できていることに注目すべきであろう） こうしておくことによってIsEven関数は実際に配列内の真偽値（＝プログラマの内的論理の写像）を読み取って返すだけの単純明快な形となり、また、変数の最下位ビットがどうなっているかなどという全くもって直感的でない計算機的な思考の呪縛を逃れることができるわけである。 c.f 電波プログラミング入門 計算機的プログラミングの危険性 電波プログラミングが計算機的プログラミングのアンチテーゼであることは前項で説明した。では計算機的プログラミングの何が問題であるのか？ここでは計算機的プログラミングの危険性について説明しておきたい。 計算機的プログラミングの限界 近代計算機の全ての祖であるアラン・チューリングによるチューリングマシンが、ゲーデルの不完全性定理を証明するために思考されたことを知っている読者は多いだろう。この事実はしかし逆説的に以下の事実を指し示している。 その機械がチューリング完全である限り、不完全性定理を無視することはできない つまり、計算機的プログラミングとは、不完全性定理の束縛（無矛盾であれば、自身の無矛盾性を証明できない）を常に受けることになるわけである。 数学的素養のない読者のためにチューリングマシンに話を戻すと、これは停止性問題に帰結する。すなわち、 チューリング機械（≒プログラム、アルゴリズム）Aに入力xを入れたら有限時間で停止するか という問題をチューリングマシンは解決できないことが示されている。これは言い換えると「そのプログラムが停止するかどうかは実行してみないとわからない」ということである。考えてみればいい、今まで計算機的プログラマが「絶対大丈夫」といったプログラムが全く問題なく動いた試しがあるだろうか！？ そう、これはプログラマ個々の問題ではなく、計算機的プログラムの限界であったのである。 これまで我々が依拠していた計算機的プログラミングのなんと脆弱なことか！この一点をもってしても計算機的プログラミングがいかに脆く、危険に満ちた物であるかということがおわかりいただけたかと思う。 計算機からの自由 前節の例をあげるまでもなく、計算機的プログラマは業務や概念を以下に計算機のロジックに置き換えるか？ということを思考し続けなければならない。 ここでは、注文をオブジェクト化するであるとか、顧客の状態を定数で表すなどという非人間的で不可解なメタファーがまかり通っており、プログラマはこの常識離れした概念を、あたかも自然なものとして考えることを強いられている。 このようなことが長く続く筈はなく、事実この業界では鬱病あるいはノイローゼを患ってしまうプログラマが後を絶たない。言わば彼らは計算機の奴隷となりはて、人間性を失ってしまったわけである。 しかしながら電波プログラミングは超計算機的な概念をそのまま実装し、計算させることを主眼にしている。すなわち計算機に使われるのではなく、電波プログラムを行うそれぞれ個々の人間性に基づいて計算機に計算させることができるわけである。計算機と人間のあるべき姿としてどちらが正常といえるかは、もはや言うまでもないことだろう。 最も高度で自然なプログラミング技法 電波プログラミングは言うまでもなく最も高度なプログラム技法である。この世界では計算機的プログラミングのあらゆるセオリーが通用しない。熟練したプログラマであっても、電波プログラミングに習熟するには3年ないしは5年の期間が必要とされる（デスマーチ中など、強いストレス化と過剰労働状態に一定期間おかれることよってそれまでの計算機的プログラミングに慣れた脳がリセットされ、偶発的に電波プログラミングが可能になる場合もあるが、このようなケースはごくまれである） また旧来のプログラミング技法のパラダイム（OOP,AOPなど）では、基本的にセミナーであったり解説書を読むことによって学習が可能であるが、電波プログラムにおいては、そのような形での学習はほぼ不可能である。 Don t Think. Feel!（考えるな、感じろ！）こそが電波プログラミングの真骨頂であり、それがために個々人の才能が最も試される分野でもある。 また、たまに新入社員やバイトで入ったプログラミング未経験な若者が、最初に書くプログラムが電波プログラムである場合がある。これこそ電波プログラミングが人間のリビドーによって生み出されている自然なプログラミングスタイルである証拠といえるのであるが、そのようなスタイルが旧来の価値観に縛られた環境によってスポイルされ、やがて、典型的な計算機プログラマとして虚勢されていく現状は問題視すべきであろう。 神秘主義と電波プログラミング （執筆中） 神は計算機の中に存在する （執筆中） 電波プログラミングで実装されている例 計算機的プログラムでは実現できないことを、電波プログラミングで実現できる例も多い。電波プログラミングによって作成された著名なアプリケーションを例示する。電波プログラミングの威力が実感できるものである。 新メモリ最適化ツール(compJapan製） 悪魔召還プログラム Pyramid倶楽部 マインドシーカー(ナムコ） JAPH 電波プログラミングではない例 最後に練習問題として、電波プログラミングのようで、そうでないものの典型的な例をあげていく。ここまで読まれた読者諸兄においては、これらが電波プログラミングでない理由はおわかりいただけるかと思う。 Perl詩perlインタプリタが実行可能なソースの形式で詩を書くというのがPerl詩である。ソースを一見すると電波プログラミングの一例であるかのようだが、アプリケーションとして見た場合、実際には実行される結果は詩と何の関連性もない場合が多い。つまり手段と目的が倒錯している意味以上のものはここにはなく、よって電波プログラミングではないと言える。仮にプログラマーが求めるアプリケーションの要件が存在し、その要件を満たすために詩を書く必要があるのだとすれば、それは電波プログラムと言ってよいだろう。 関数型言語 lisp
https://w.atwiki.jp/zensensyu/pages/2684.html
ゲームプログラマー 652 名前：水先案名無い人：2009/09/16(水) 13 52 08 ID /w0fxm6JP 光成「ゲームプログラマになりたいかーーーーッ」 観客「オーーーーーーーーーーーーーー！！！！」 光成「ワシもじゃ ワシもじゃみんな！！」 幼き日の夢は生きていた!!更なる自己分析を積み将来の夢が蘇った!! 「ゲームプログラマになりたい」だァ――――!!! コンパイラはすでに我々が完成している! VisualStudioインストールだァ――――!!! C言語勉強次第標準出力しまくってやる!! プログラム入門代表 Hello,World! だァッ!!! 簡単なゲームなら我々の歴史がものを言う!! 素手の石並べ 三目並べ!!! セーブデータを知らしめたい!! ファイルIOだァ!!! データ表現は３階級制覇だが難易度なら全階級オレのものだ!! 初心者殺し ポインタだ!!! データ構造は完璧だ!! struct 構造体!!!! 全ゲームプログラミングのベスト・チョイスは私の中にある!! メモリ操作もできる高級言語の神様が来たッ C++!!! プログラムのパッケージ化なら絶対に敗けん!! オブジェクト指向のプログラミング見せたる クラスと継承だ!!! バーリ・トゥード（なんでもあり）ならこいつが怖い!! C言語プリプロセッサー マクロだ!!! 標準ライブラリからアホの子AIが上陸だ!! 乱数生成 rand()!!! ビジュアルに訴え掛けるプログラミングがしたいからゲームプログラマーになったのだ!! GUIのゲームを見せてやる!! Windowsプログラミング!!! めい土の土産に終了通知イベントとはよく言ったもの!! GUIベースプログラミングの奥義が今 実戦でバクハツする!! イベントドリブンだ―――!!! 3Dゲームこそが地上最強の代名詞だ!! これは抑えておかないとッッ DirectX!!! とりあえずゲーム作りたいからここまできたッ 難しい知識一切不要!!!! スペース（宇宙）ファイター 2Dシューティングゲームだ!!! オレたちはメタプログラミング最強ではないプログラミングで最強なのだ!! 御存知ジェネリック template テンプレート!!! ライブラリの本場は今やテンプレートにある!! オレを驚かせる奴はいないのか!! スタンダード・テンプレート・ライブラリ（STL）だ!!! 面倒臭ァァァァァいッ説明不要!! 微分積分!!! 行列!!! 数学だ!!! ふるまいの切り替えは動的に使えてナンボのモン!!! 超実戦多態性!! 本家オブジェクト指向からポリモーフィズムの登場だ!!! ゲームデータはオレのもの 構成するファイルは思い切りまとめ思い切り圧縮するだけ!! リソースデータ統一ツール ゲームリソースのアーカイブ化 自分を試しに標準化委員会へきたッ!! 先進ライブラリ集合体 Boost!!! 見た目のリッチさに更なる磨きをかけ ”アニメーション”メッシュアニメが帰ってきたァ!!! 今の自分に死角はないッッ!! ゲームコントローラ DirectInput!!! 有限状態マシンの拳技が今ベールを脱ぐ!! オートマトンから AIだ!!! ファンの前でならオレはいつでも全盛期だ!! すぐ死ぬゲーム ローグライク 俺手作りで登場だ!!! 動的リンケージの仕事はどーしたッ ライブラリの炎 未だ消えずッ!! 繋ぐも放すも思いのまま!! DLLプログラミングだ!!! 特に理由はないッ 音声が必要なのは当たりまえ!! winmm.libも一緒に使ってる事はないしょだ!!! 日の下開山! DirectSoundがきてくれた―――!!! 企業対企業ビジネスで磨いた実戦データ形式!! eコマースのスタンダード・ファイル XMLだ!!! 実戦だったらこの人を外せない!! リビジョン管理ツールだ!!! 超一流ゲームプログラマーの超一流の書籍だ!! 生で拝んでオドロキやがれッ アメリカのゲーム本!! Game Proguraming Gems!!! 就職作品はこいつが完成させた!! 俺の切り札!! 俺俺ライブラリ バージョン5だ!!! 選考結果メールが帰ってきたッ 何を選考していたんだ 待ちわびたよッッ 俺達は君を待っていたッッッ内定通知メールの到着だ――――――――ッ 加えてスキルアップに備え超豪華なリザーバーを4名用意致しました！ 低級言語 アセンブリプログラミング!! 伝統派分散処理 マルチスレッドプログラミング!! 通信の巨人！ネットワークプログラミング！ ……ッッ どーやら技術革新は続いているようですが、登場次第ッ皆様にご紹介致しますッッ 関連レス 657 名前：水先案名無い人：2009/09/16(水) 14 01 09 ID nBRNzIjM0 652 「オメデトオオッ」 「オメデトォ～～～～～」 「サイコーだ～～～～」 「オメデトオオッ」 俺も小学校の卒業の作文はプログラマになりたいだったが そんなのは当の昔ですよｱﾋｬﾋｬﾋｬﾋｬ 最近ハックロムを作りたくなったんだが即挫折したよｗ 658 名前：水先案名無い人：2009/09/16(水) 20 25 46 ID kms92IQ40 652 最高 乙 コメント 名前
https://w.atwiki.jp/c21coterie/pages/555.html
プログラマを題材にしたジョークゲームの原案 ジョークTRPGとかがいいかもしれんｗ コードを書くことで魔法が発動しそれをぶつけ合って戦うとかそんなイメージ。 カード perl使い Perl使いは、情報戦の達人。 彼らの書いた本人にしかわからないコードが相手に送られると相手のコードが攪乱されます。 粗雑な命令系統しか持たないスクリプター、命令系統が荒れやすいC、記述時に高度な精神集中を必要とするLisperに対して強力な攪乱効果を発揮します。 そこそこ組織化されたC++に対してはあまり効果がなく、鉄壁の構文を持つCobol、強固な組織を持つJavaに対してはほとんど効果がないのが特徴です。 Perl使い同士の戦いは難読化されたコードのやり取りによって本人たち以外には理解できない諜報戦が繰り広げられます。 カード コボラー コボラーは銃火器などの原始的だが頼りになる武器を使いどこでも安定して実力を発揮します。 レーザーやビームは信頼しない実弾至上主義者です。 しかし物質文明至上主義の国で生まれた派閥であるため幽霊精霊系統は苦手。 偶にインディアンの血を引くコボラーが引けた時はそれら非物質系に対してつよいことがあります。 カード チームjava Javaは正規の訓練を受けた大部隊で物量で攻めてくるチーム戦のプロ。 豊富な兵器をそろえ低コストで召喚できるという利点があります。 カード C++ C++陣営もJavaに負けないチーム力とJava以上の兵器を持ちますが運営コストや召喚コストが馬鹿に高いという欠点を持ちます。 Cは個々人の能力は高いのですがチーム力が低い少数精鋭ですね。 カード Lisper Lisperはカッコを複雑に組み立てて魔法を発動する魔法使いで彼らの実力は未知数。 幻の理想的チューリングマシンによるパワー無限大の道を模索する求道者です。 常に自分の限界を超えようとする向上心の持ち主で複雑で強力な魔法を唱えようとしたがります。 が実戦でもそれを行うためにカッコを書き間違えて魔法の不発でよく敗退します。 カード SQL使い SQL使いは広域殲滅魔法は得意ですが対個人には弱いです。 Java部隊を殲滅したSQL使いがたった一人のコボラースナイパーに負けたという事例もよくあります。 カード 組織名 スクリプター スクリプターは粗製乱造された兵士を大量に擁しています。 偶に驚くべき精鋭もいますが大体は弱めです、安いのが利点です。 カード アルゴリズマー アルゴリズマーは補助系で活躍の場が滅多にありませんが、はまると連続強化により部隊を最強まで仕上げてくれます。 カード 新人 新人カードは、組織の能力を低下させますが保持しておくと研修、実務経験カードがそろった後で実務経験者に昇格します。 トレード、組織強化どちらに使うか貴方次第。 カード 下請け 下請けは下請けの能力と今の貴方の能力を比べて大きい方で上書きする効果があります。 カード トップコダー １流SE トップコダー、一流SE選ばれたエリートであり組織全体の能力を上昇させます。 カード Fortran士族 Fortran士族は科学計算のプロフェッショナル。 組織の技術力が上昇します。 昔はどの組織もFortran士族を奪い合ってましたが、若者の理科離れで人手不足が深刻化。 各組織が独自の科学計算ライブラリを持つようになってからは影響力も落ちいまでは弱小勢力になっています。 しかし一流の人材を輩出していることは確か。 この士族のカードを引き当てたら貴方の組織は大幅に強化されるでしょう。 カード ハッカー ハッカーは神出鬼没のゲリラ屋や傭兵です。 元ネタ ９０年代に粗製乱造されたＴＲＰＧの色々な作品のテンプレぽい物を類すしてそこからパクッてきました。