プログラマ専用SNS ミクプラ

http://detail.chiebukuro.yahoo.co.jp/qa ... 1057045270

リンク先質問なのですが、きちんとした答えができているかポカミスや考えミスがないか不安です。
どなたかアドバイスお願いします。

内容の前に「メモカ探索」と言う検索に引っかからない用語を一般用語の様に使っているのがまず気になります。
あと思考過程をそのまま回答者に提示しても回答者も困ると思うんですが（こんな考え方もあるよってお気持ちなのかも知れませんが）。

メモカでなくメモ化ですね。
なおしときます。

思考過程があるほうがわかりやすいと思ったのですが？
うーんわかりにくいですかね？

それなら「メモ化 再帰」と書かないと検索しようがないと思います。
あと、アルゴリズムマスターではない私からの意見ですがどうやっても全パターンを求めるには時間がかかる処理だと思われますので解を１つ最短時間で見つける手法に絞ったほうが良い様に思います。

思考過程でなく、案１と案２とか書かれたらどうでしょうか？それぞれのメリットとデメリットを添え書きして。
実装してみないと所要時間が出ない問題なら、そう書くしか無いと思いますが。[補記]あくまでも私の意見なのでご自分の考えを尊重してください。

【雑談】
お答えいただかなくても良いのですが、前からアルゴリズ関係の質問をされていますが何か実用アプリやゲームは作られていないのでしょうか？
それともアルゴリズムを極めるのが目的でしょうか？
アルゴリズムを極めないと実用アプリは作れなと思われていたら勿体無いと言うか残念なので老婆心ながらお尋ねしました。

素直に「ナップザック問題に帰着させる。」でいいのでは
この様子だと10000以上もあり得るのでメモリに状態を保存させるのは向いてないと思いますしそもそも自信がないなら答えないほうがいいんじゃないですかね

>softyaさん
競技プログラミングじゃないですかね
TopCoderとかありますし

うーん、自分ではまだ３流プログラマって感覚なんです。

プログラムの練習問題は解いてますが、練習問題というのは現実を極限まで単純化したものに過ぎず、実務で扱うデータは次元が増えたり高度な数学を使ったり、複数の部品を複雑に組み合わせたりしてもっとハイレベル何だろうなあという感じで。

３流高卒のアルバイタ人生なので雇ってくれる人もいませんし。

本なんかで実務では何千次元や何万次元のデータセットを扱うが、本ではそこまで高度な内容には立ち入らず、理解しやすい２次元データで学習を済ます。
とかこういう記述を見つけるたびに、実務に行く勇気が縮小していくわけです。

４次元よりも複雑な内容は線形代数以外よくわかりませんし。

堀江伸一 さんが書きました:うーん、自分ではまだ３流プログラマって感覚なんです。
プログラムの練習問題は解いてますが、練習問題というのは現実を極限まで単純化したものに過ぎず、実務で扱うデータは次元が増えたり高度な数学を使ったり、複数の部品を複雑に組み合わせたりしてもっとハイレベル何だろうなあという感じで。
３流高卒のアルバイタ人生なので雇ってくれる人もいませんし。
本なんかで実務では何千次元や何万次元のデータセットを扱うが、本ではそこまで高度な内容には立ち入らず、理解しやすい２次元データで学習を済ます。
とかこういう記述を見つけるたびに、実務に行く勇気が縮小していくわけです。
４次元よりも複雑な内容は線形代数以外よくわかりませんし。

じゃあ別に競技プログラミングが趣味な訳ではないのですか？
極端に言えばプログラムなんてのは所定時間内に間違いの無い動作をしてくれれば問題ない訳で、分析力・設計力・構成力があれば多少アルゴリズム力が無くても大抵のものは作れます。アルゴリズムは大事ですが、泥臭いアルゴリズムでもソースコードが分かりやすくて実用上問題なければそれはOKなんです。
※　仕事上で使ったアルゴリズムガ高度過ぎると他の人がメンテナンス出来ない自体も考えられます。これは仕事の業務コードとしてNGなんです。
さじ加減は実用・実務アプリを作っていて始めて分かってくることなので、作る前の段階でアルゴリズムばかり勉強していても実用・実務に耐えられるプログラマにはなかなか成れないと私は思うんですよ。特にゲームなんて、まっとうな解き方よりも速度の関係上らしく見えるアルゴリズムばかり求められますので、アルゴリズムをまっとうに突き詰めるよりひねった考え方が欲しいところです。
以上、私なりの見解でした。他の人では意見が違う部分もあると思います。

>何千次元や何万次元のデータセット
多次元データ解析をしている業務分野のほうが少ない気がしますが、統計や分析分野のプログラマーを目指されているんでしょうか？

>所定時間内に間違いの無い動作をしてくれれば問題ない訳

組み合わせやグラフや探索の問題なんか、練習問題だとかなりシンプルですよね。
実際基本のダイクストラ法とか程度なら私でも解けます。

http://rose.u-aizu.ac.jp/onlinejudge/Pr ... 08&lang=jp
それが、リンク先問題みたいに基本問題から少し複雑になっただけで私はお手上げ。
自分で考えて解けない。
調べ方も分からない。

でもこれ、練習問題だから現実の問題に比べたら遥かに簡単なんですよね？
これが実務だと、グラフの辺に設定されるパラメータが重みだけじゃなく複数の変数に増えたり、コストの評価も複数の評価関数がはいったり、計算途中でグラフの重みが変化したりグラフのつながりが変化したり、グラフ上の移動中特定の条件を満たす移動しかしてはいけないと条件が付いたり。
時には複数のポインタがグラフ上を移動し、ポインタが移動するたびにグラフや構造体の状態が変化する。
そんな色々な問題が出てくるわけですよね？

ナップザック問題だったら練習問題では重さと値段だったりしますが、実務なら重さと値段以外にパラメータの数が増えてN次元になったり実数がはいってきたりするわけですよね？

で、組み合わせや探索なんか、賢い方法を極めないとあっという間に数兆*数兆*、、、なんて組み合わせ数になる。

パラメータの数が少ないと初心者向け教科書レベルの解き方でいいけど、パラメータの種類が増えたらお手上げ。
で、私は簡単な練習問題しか解けない。
結局私は実務を単純化した簡単な問題のなかでも特に簡単な問題しか解けない3流プログラマ？

という風に考えてしまいます。

とりあえず、一言で言うと「考えすぎ」だと私は思います。
そういう仕事もありますが、ここまで数学的なのは一部の分野です。
大半の仕事はもっと違う泥臭い処理の積み重ねです。

作りたいアプリケーションが、そこまで数学的なものを要求するなら別ですが何かアプリやゲームを作ることから始められてはどうですか？
アルゴリズム問題では出てこないアプリを作らなければ学べないことも沢山あります。

で、組み合わせや探索なんか、賢い方法を極めないとあっという間に数兆*数兆*、、、なんて組み合わせ数になる。

ゲームなんかでは、まともに組み合わせ問題に成らないように超絶に手抜きする方法が取られます。
ＦＰＳ（ファースト・パーソン・シューティング）ゲームでＮＰＣがよく物に引っかかっているのは経路探索のポイントをすごく少なく間引いているからですね。
私も得意とは言えませんが、必要なのは柔軟な発想では無いでしょうか？

http://rose.u-aizu.ac.jp/onlinejudge/Pr ... 08&lang=jp
それが、リンク先問題みたいに基本問題から少し複雑になっただけで私はお手上げ。
自分で考えて解けない。
調べ方も分からない。

検索したら解答例はすぐ見つかりましたので、検索キーワードに問題があるかと。

スーパープログラマやアルゴリズムマスターを目指すなら別ですが、現実のプログラマはもっと泥臭い方法でプログラムを作っています。
「C言語によるアルゴリズム辞典」の丸写しコードなんてよく有る事です。
そのレベルさえ要求されないことがほとんどなのでは無いでしょうか。
「Amazon.co.jp： プログラマの数学: 結城 浩: 本」

このぐらいで十分かと。上を見るとキリがないですからね。

解答例がある場合はいいのです。
解答例がない問題にぶち当たった時のための訓練。
そういう感じで問題に挑戦しています。

実力上昇のためできるだけ回答を見ずに自力で解きたいと考えています。
調べ物をするとしても直接の回答は見ずに、関係ありそうな技術を探して問題を解く感じです。
学習法としては駄目で効率が悪いかもしれませんが、ぼちぼちやってます。


＞泥くさいプログラム。
私でもプログラマになれる可能性があるということでしょうか？
練習問題は現実を極端に簡単にしたもので、現実のプログラムはもっと難しいというのは思い込みでしょうか？



あ、今解けずに困ってる問題があります。
アドバイスお願いします。
http://www14.atwiki.jp/c21coterie/pages/425.html

堀江伸一 さんが書きました:解答例がある場合はいいのです。
解答例がない問題にぶち当たった時のための訓練。
そういう感じで問題に挑戦しています。
実力上昇のためできるだけ回答を見ずに自力で解きたいと考えています。
調べ物をするとしても直接の回答は見ずに、関係ありそうな技術を探して問題を解く感じです。
学習法としては駄目で効率が悪いかもしれませんが、ぼちぼちやってます。

どうしても解のない問題と言うか処理時間的に無理で諦める事はあります。
私なら、そんな場合は代案・仕様変更を含めて考え直します。

[追記]
会津ジャッジで出てくるアルゴリズム問題は大半実際のプログラミングで簡単に応用できない頭の体操のためのパズルのためのパズル問題だと私は思っています。これも必要なことではありますが、実務となると話は違います。
なんと言うか、英語を勉強していて文法ばかりに目が行って実際外国人と話せない日本の英語教育みたいな物だと思うのです。分からないと仰っている「Problem I: Aaron と Bruce」の問題にしても現実問題どんなアプリを作るときに応用できるとお考えですか？文字通り、このルールのゲームを作るなんてのは無しですよ。
何が言いたいかというと、どれだけ深くやっても実際あんまり応用できる場面は少ないと思うので、ほどほどにして実際のアプリを作るほうが学べることはありますよって事ですね。既に、そのための準備は十分出来ていると思います。
[追記の追記]
どうしてもアルゴリズムを必要だと思うのなら、少なくともアルゴリズムだけでなくアプリ開発との両軸で進めることを考えてみたらどうでしょう。
既に数ヶ月程度かかる様なアプリを書かれていたら差し出がましい事を言って申し訳なかったと思います。

堀江伸一 さんが書きました: ＞泥くさいプログラム。
私でもプログラマになれる可能性があるということでしょうか？
練習問題は現実を極端に簡単にしたもので、現実のプログラムはもっと難しいというのは思い込みでしょうか？

アプリを作り始めた上でアプリを作る上でのアルゴリズム問題に突き当たってから考えれば良いと思います。
例えば堀江さんが使っているソフトやvectorなどに登録されているフリーウェアやシェアウェアで難解なアルゴリズムを使っていると思われるソフトがどの位あるかです。
「Vector： ソフトライブラリ＆PCショップ - 国内最大級の フリーソフト ダウンロードサイト」
http://www.vector.co.jp/
堀江さんが実際難しそうだと感じるソフトの具体例を教えてください。

堀江伸一 さんが書きました:あ、今解けずに困ってる問題があります。
アドバイスお願いします。
http://www14.atwiki.jp/c21coterie/pages/425.html

検索したときに答えを見てしまったので答えは知っています。
今のでうまく解けないなら、検索で見つけた答えの方法がベストなんだと思いますが書いてしまって良いのでしょうか？

> ＞泥くさいプログラム。
> 私でもプログラマになれる可能性があるということでしょうか？
> 練習問題は現実を極端に簡単にしたもので、
> 現実のプログラムはもっと難しいというのは思い込みでしょうか？

特定の分野でなければ嫌だということがなければ技術的には可能でしょう。
現実の業務のプログラムでは、高度なアルゴリズムを必要とすることは極めて稀です。

練習問題よりも現実のプログラム作成の方が難しいとは思いますが、
それはアリゴリズムではありません。プロとしての難しい点は、
短納期・可読性・バグの少なさ・見積もりの正確さ等が求められる事と、
既存のプログラムを解析して最小の変更で機能追加や修正を行う必要がある事などです。
解析の必要な既存のプログラムの大半は泥臭いものです。
それに最小限の変更を加えた自分のプログラムも泥臭くなりがちです。


今回に限らず一連の投稿を見ての判断ですが、
プログラマになるのに必要で堀江さんに足りない物は、
コミュニケーションの能力ではないでしょうか。プログラマに限りませんが。
この様な指摘は不快に思うでしょうが、自分でも感じていませんか？
アルゴリズムの勉強は無駄な事とは思いませんが、現実逃避だと思います。

フォローになるか判りませんが、堀江さんが質問しているような問題は、
プロのプログラマの大半は解けないし、解こうと思ったことすらないと思います。

コミュニケーション能力。
これは私低いです、自覚しています。
最低でも業務に必要な会話くらいは積極的に取ろうとは考えていますけど。
コミュ力低、単純肉体労働以外経験なし、プログラム能力3流、3流高卒なので雇ってくれる人いない。
実力をつける以外に単純肉体労度王から脱却する道があるかな？という気分です。

私の作ったアプリといえばまだこのレベル。
http://www.geocities.jp/sinapusu2002/pu ... dume4.html
高校生が片手間で作りましたといっても誰でも信じそうなレベルで、こんな簡単なの作るのに10時間もかかったりしてます。
まだまだ高校生レベル、レベルアップが必要、そんな気分です。

ベクターのサイトについてはちょっと見てみます。
最近はどんなソフトがあるんだろ？

堀江伸一 さんが書きました: 私の作ったアプリといえばまだこのレベル。
http://www.geocities.jp/sinapusu2002/pu ... dume4.html
高校生が片手間で作りましたといっても誰でも信じそうなレベルで、こんな簡単なの作るのに10時間もかかったりしてます。
まだまだ高校生レベル、レベルアップが必要、そんな気分です。

とりあえず、前の「学習法辞典」の話が出たときにやたらアルゴリズムに偏っていた理由がなんとなく分かりました。
実際にアプリを作ると言う事をしたことがないので分からないんですね。
作成時間をやたら気にしてますが作ることが大事なので、まず時間がかかっても幾つもの規模の大きめなプログラムを組み立てることです。
例えば、このサイトの講座コンテンツである龍神録ですが、サンプルを見ずに動画を見ただけで同じようなものを構築できるそうですか？これは難度の高いアルゴリズムの問題(弾幕にセンスは必要ですが)ではないので、なんども書いてる分析力・設計力・構築力が必要でアルゴリズムをどれだけ極めても身につかない類の能力が必要です。
[追記]別に龍神録を作れと言っているわけではなく、全く違うたぐいのアプリでも構いません。
最初は電卓でもエディタでもそれ専用のサンプルや講座を見ずに構築出来れば実力が付いていきます。それから、どんどん規模を広げていけば良いんです。

ちなみに提示されたURLのコードはIE8やFirefox6では動かない様です(エラーが出ます)。

うーん、コミュニケーション能力が低いのを自覚しているのに、
業務に必要な会話以外は積極的に取ろうとしてないんですね。

コミュニケーションって業務上以外でも積極的にとっていたほうが、いざ業務上でコミュニケーションを取るときに
活きてくるものだと思うのですよね。
普段コミュニケーションを取ろうとしない人が業務のときだけコミュニケーションが取れるとは思えませんので。
(個人的には「コミュ力低」などの自分用語の多用もコミュニケーションを取る上で障害になるかなと思います)

堀江伸一 さんが書きました: 私の作ったアプリといえばまだこのレベル。
http://www.geocities.jp/sinapusu2002/pu ... dume4.html
高校生が片手間で作りましたといっても誰でも信じそうなレベルで、こんな簡単なの作るのに10時間もかかったりしてます。
まだまだ高校生レベル、レベルアップが必要、そんな気分です。

ページを見ましたが文章がちょろっとあるだけなので、想像上でしかわかりませんでした。
#矢印の方向にボールが動くってあるから落ち物系かと思いきや、箱に詰めるような説明がありますし。

堀江さんの考えるレベルアップって何ができたら達成なのでしょうか？
漠然とレベルを上げないとと言われると、ゴールが決まっていないのに延々と走ることになる気がします。
---
あとjavaの掲示板にも質問を立ててません？

>>asdさん
>あとjavaの掲示板にも質問を立ててません？
別に同じ内容の質問でなければOKですよ。

>softya（ソフト屋)さん

softya（ソフト屋) さんが書きました:>>asdさん
>あとjavaの掲示板にも質問を立ててません？
別に同じ内容の質問でなければOKですよ。

舌足らずで失礼しました。
マルチポストを指摘しているわけではなくて、C言語以外にもあれもこれもと欲張っちゃうと
本当に必要なものがわからなくなってしまうのではないかなぁと思った次第です。
誤解を招くような記述で申し訳ないです。

asd さんが書きました:>softya（ソフト屋)さん
舌足らずで失礼しました。
マルチポストを指摘しているわけではなくて、C言語以外にもあれもこれもと欲張っちゃうと
本当に必要なものがわからなくなってしまうのではないかなぁと思った次第です。
誤解を招くような記述で申し訳ないです。

あっ、そういう事ですね。
私も今大事なのは、アルゴリズムでもなく、オブジェクト指向を論じる事ことでもなく、どれか１つの言語でアプリを構築する修行を積むことだと思います。

むか～しの内容ですが、堀江さんのアルゴリズム以外の切り口になるのでと思い参考まで。
「Ｃプログラミング診断室」
http://www.pro.or.jp/~fuji/mybooks/cdia ... tml#mokuji

3流ってのは、何ができて何ができないのですかね？

Ｃプログラミング診断室読みました。
実はちょっとだけプログラムのバイトに入った経験があり、それだけの自分なので数千行や数万行のプログラムとか書かれてもイメージ難しいです。
感覚的な範囲では数百行くらいまでのプログラムしかイメージができませんが、多人数開発する時守るべき細かいルールが多いんだろうなという印象は受けました。
ＧＵＩ開発の今から見るとＣＵＩの話なのでちょっと古いかなというのが印象です？

人間関係が広いプログラマほど実力があるとページにありましたがこれは独学なうえ、出遅れ学習の私にはつらい現実です。
プログラムの話ができる人が周りに一人もおらず書籍とネット以外頼るものがないので辛さ３倍です。

ベクターのソフトはいろいろありますね。

ゲーム作りですか？
まず設計図から引いてみないとだめですよね？
ＤｉｒｅｃｔＸを勉強して、設計図を引いて、具体的に部品をくみ上げて？
なんだか大変そうです。

http://dixq.net/rp/

いいですね。
なんだかすごく解説が丁寧だし、レベルの高いところまで学習できそうだし、自分でアプリを作るといっても、設計図の引き方なんて知らないしで
一度練習してみたかったのです。

アプリを作るということを練習できそうでなんだかとてもいい感じに思えます。

一度頑張ってみます。
まずは、斜め読みして全体の構成を学習して、それからＤｉｒｅｃｔＸの本も買って、必要な技術も調べて。
頑張ってみます。

　

!	メッセージ from: softya（ソフト屋)
	たしか大分前に書きましたが、特定の質問や回答以外に答えを返さないのは失礼ですので出来るだけ回答する様にしてくださいね。 気づいていないかも知れませんがasdさんとISLeさんをわざと無視している様にも見えます。

堀江伸一 さんが書きました:Ｃプログラミング診断室読みました。
実はちょっとだけプログラムのバイトに入った経験があり、それだけの自分なので数千行や数万行のプログラムとか書かれてもイメージ難しいです。
感覚的な範囲では数百行くらいまでのプログラムしかイメージができませんが、多人数開発する時守るべき細かいルールが多いんだろうなという印象は受けました。
ＧＵＩ開発の今から見るとＣＵＩの話なのでちょっと古いかなというのが印象です？

ええ、「むか～し」と断りました。
新しい古いの問題ではなく、あのページで書かれていることが実感できたり何故修正する必要あるのか共感できるかが問題です。
少なくともアルゴリズムをどんだけ学んでも、あそこの問題点解決の糸口は見えてこないと思いませんか？

堀江伸一 さんが書きました: 人間関係が広いプログラマほど実力があるとページにありましたがこれは独学なうえ、出遅れ学習の私にはつらい現実です。
プログラムの話ができる人が周りに一人もおらず書籍とネット以外頼るものがないので辛さ３倍です。

ネットも人間関係のうちですよ。

堀江伸一 さんが書きました: ベクターのソフトはいろいろありますね。

で、アルゴリズムに関してはどう思われたのですか？
大半は難しいアルゴリズムを使っていると思われましたか？

堀江伸一 さんが書きました: ゲーム作りですか？
まず設計図から引いてみないとだめですよね？
ＤｉｒｅｃｔＸを勉強して、設計図を引いて、具体的に部品をくみ上げて？
なんだか大変そうです。

別に難しかったらDXライブラリでも、Win32APIでも、Javaの２Dライブラリでも良いのです。
ソースコードを参考にしない＆自分で独自に設計するって事が大事なのです。
[修正]最初はソースコード丸写しでもクラス化しての組み換えでも構わないですが、二回目はDXライブラリ他（描画API）のリファレンス以外は見てはいけません。

>なんだか大変そうです。
それをしないとゲームやアプリは作れません。
苦労して自分で工夫する術を覚えないと作れないです。

>まずは、斜め読みして全体の構成を学習して、それからＤｉｒｅｃｔＸの本も買って、必要な技術も調べて。
そこでDirectXに走るのは間違っていますよ。そこは手抜きして良いんです。
目的はプログラムを作れるようになることでライブラリを覚えることではありません。
[追記]すでに使える描画ライブラリがあるなら、それが一番です。DXライブラリ、OpenGL、Win32APIなど経験のあるものを使うことを優先してください。
作るときにDirectXが良く分からないのか、構築がうまくできないのか混乱すると思うからです。

ベクターですが
http://www.vector.co.jp/magazine/softne ... ml?ref=top
こういうソフトなんかすごく高度な内容に思えます。
データが壊れるというのは壊れ方のパタン数が多くものすごく大きな写像なのに、壊れる前のデータは一つしかない。
1対ｎ写像を復元する？
こういうのはやっぱり高度な数学を使ってるんじゃないかなと。

Movie Pro
映像データを切り貼りするというのは、複雑なデータ構造を入れ替えて組み立てるのでとても複雑そうなイメージです。

六角大王Super6WinDL版
３D関係なんて法線がどうの、頂点データの補完による滑らかなつなぎがどうの、それをアニメーションさせるとか高度なイメージはあります。
GPSなんか26もの位置情報の精度向上方法があって。精度を上げたりしてますが、相互関連する難しい数学ばかりでこういうのも高度そうかなと思ったりします。

後、多人数が関係を持つブラウザゲームなんか無数の条件分岐を細かく作ってあるのが大変そうだなというイメージはあります。

ベクターはソフトが多いので難しそうなのは

私もいつかは実力を上げてアプリを作ってみたいですね。

ご紹介のシューティングゲーム制作講座でゲーム作りになれたらこんなゲームを作ろうと考えています。

自作ゲーム要綱

1　３Dアクションゲーム
2　簡単そうなキャラを操作するレース系
3　キャラの移動パタンを決定する関数は下記のとおりとする

ユーザーの操作に応じ、以下の関数が自キャラに適用される。

3-1　UP関数　操作に対するキャラの移動が不安定になる。(移動操作後のキャラの位置と向き、速度と向き、加速度とその向きの振れ幅が大きくなる)
3-2　maintain　キャラの移動はそのまま
3-3　down関数　キャラの移動が安定し予測しやすくなる。

UP関数は、飛行機でいえば、前進翼機に近い不安定な動きが起こるようになり、down関数は操作後のキャラの移動が鈍重な大型旅客機に近くなるイメージ。
スキーやスノボでいえば、downは移動後の旋回半径が小さくなったり、急激なターンやジャンプができなくなる。
UPは急激なターンや大ジャンプなどができるようになる。

数学的に言えば、速度や加速度や移動後の位置などでｎ次元をとり、移動前を原点にとる。
Downは安定した移動ができる範囲に操作結果が偏在する。
UPは複雑な穴ぼこだらけの範囲に移動後の結果が散らばる。

UP関数はゆっくりと間隔をおいて上昇する。
Down関数はミスやDown操作によって急激に聞く。


また、ユーザーの操作(ドリフトや空中ドリフト)等の任意の操作で上がるが、UP関数はゲーム内で上手いテクニックを行うと自然に上がる。。

UP関数が多数適用された状態では、高得点やトリッキーで高度な技に挑戦できるようになる。
そのかわり難しい。
Down関数は低得点だが安定した動きを目指せる。


地上でのレースの場合、UPやDownは地形による影響を受ける。
(スキー、スノボー、ローラースケート等のイメージのゲームでは、斜面になったコーナーなどではUP状態に近づき、平坦な路面ではDown状態に近付くなどが理想。

空中ではUPとDownは地形の影響を受けない。

まだイメージが固まらなくてこういうイメージのゲームしか考えていません。

まずゲーム作りに慣れるためにご紹介頂いたゲームを完成させて微改造する所から始めようかと考えています。

堀江伸一 さんが書きました:ベクターですが
http://www.vector.co.jp/magazine/softne ... ml?ref=top
こういうソフトなんかすごく高度な内容に思えます。
データが壊れるというのは壊れ方のパタン数が多くものすごく大きな写像なのに、壊れる前のデータは一つしかない。
1対ｎ写像を復元する？
こういうのはやっぱり高度な数学を使ってるんじゃないかなと。

勘違いされているようですが、これは壊れたデータを復元するソフトではなくて
削除やディスクエラーによって不可視状態になっているファイルを可視状態に戻すソフトです。

本当にデータが壊れていた場合は元通りに修復することはできません。

復元するデータに一定の規則性があることが分かっていれば統計的に元のデータの復元もできるでしょうが、
少なくともこのような汎用的なデータ復元ソフトでは、そのようなアルゴリズムは使われていません。

追記：

堀江伸一 さんが書きました: Movie Pro
映像データを切り貼りするというのは、複雑なデータ構造を入れ替えて組み立てるのでとても複雑そうなイメージです。

後、多人数が関係を持つブラウザゲームなんか無数の条件分岐を細かく作ってあるのが大変そうだなというイメージはあります。

データ構造が複雑だとか、条件分岐が多いというのは単にコードが長いとか複雑なだけであって、
そこに高度なアルゴリズムが使われているかどうかはまた別の話ですよ。

「自作ゲーム要綱」についてもとりあえず気づいたことを書かせていただきます。

◆まず、「関数」の意味を間違っていませんか？
「関数が自キャラに適用される」
「UP関数が多数適用された状態」
というような「関数の適用」という言い回しの意味が分からないのですが、具体的にどのような実装になるのでしょうか？
[hr]

堀江伸一 さんが書きました: 3-1　UP関数　操作に対するキャラの移動が不安定になる。(移動操作後のキャラの位置と向き、速度と向き、加速度とその向きの振れ幅が大きくなる)
3-2　maintain　キャラの移動はそのまま
3-3　down関数　キャラの移動が安定し予測しやすくなる。

◆実際に操作したときのことを想定すれば分かると思いますが、
プレーヤーがキャラの移動を一番予測しやすいのは「キャラの移動はそのまま」という状態のはずです。
操作したとおりにキャラが動くのですから。
それ以上に「キャラの移動が安定し予測しやすくなる」状態が存在するのでしょうか？

キャラの移動に何らかの補正をかけて安定させた場合、
それはプレーヤーの操作通りにならないため「予測しやすくなる」とは思えませんが。
[hr]

堀江伸一 さんが書きました: down関数は操作後のキャラの移動が鈍重な大型旅客機に近くなるイメージ。
スキーやスノボでいえば、downは移動後の旋回半径が小さくなったり、急激なターンやジャンプができなくなる。

◆このような挙動はレーズゲームで言えば「ハンドリングが悪い」という状態であり、
プレーヤーはむしろ操作しづらくなるのではないでしょうか？
「キャラの移動が安定し予測しやすくなる」とはちょっと違うと思います。
[hr]

堀江伸一 さんが書きました: 数学的に言えば、速度や加速度や移動後の位置などでｎ次元をとり、移動前を原点にとる。
Downは安定した移動ができる範囲に操作結果が偏在する。
UPは複雑な穴ぼこだらけの範囲に移動後の結果が散らばる。

◆このような記述は問題をよけい難しくするだけだと思います。
数学的と言いつつ小難しい言葉を使っているだけですし、
「安定した移動ができる範囲」、「複雑な穴ぼこだらけ」といった曖昧な表現では、
実際にどうプログラムを実装するかという所に結びつきません。

例えば「複雑な穴ぼこだらけの範囲に散らばる」よりも、

「プレイヤーの操縦を難しくする」　　　　　　　　　　　　　　←ゲームとしての挙動
「加速度や向きの数値に乱数によってノイズを加える」　←具体的な方法

などといった書き方のほうがはるかに実際のプログラムを組むということを意識しています。

「複雑な穴ぼこだらけの範囲に散らばる」では、ゲームとしての動作もよく分からないし、
かと言ってプログラミングするときの具体的な実装を言っている訳でもないので、意味がありせん。

どうもすいません。
特に返事を書くべき内容だともおもわなかったもので。


>それに最小限の変更を加えた自分のプログラムも泥臭くなりがちです。
実感としては分かりませんが理解です。

>C言語以外にもあれもこれもと欲張っちゃうと
面接に行った時一つの言語しかできない。
というのでは不利かと思いまして、Java、PHP、C++を同時並行で勉強しています。

>3流ってのは、何ができて何ができないのですかね？
まだ私低レベルプログラマなのでよくわからないです。

うーん、ゲーム設計の指摘ありがとうございます。
すいません、3流高卒なうえ、プログラム勉強中の身なので用語の使い方が出鱈目なんです、私。
関数についてはトライアンドエラーで色々な関数を自分で試そうと考えてます。


ゲームなのですが、普通は私の考えと逆、ですよね？
レースゲームなら、ニトロやドリフトを一つの写像と見ると、写像適用後の車の位置の結果が制限される。
(ニトロなら旋回が制限されるという意味でニトロ適用後の結果が制限されるし、ドリフトなら奇麗なコース取りであるかぎり狭いルートになる)
速度が上がると、旋回半径が大きくなり、まっすぐに近づき移動が単純になる。

結果が制限され大きくなる特殊な操作(ニトロならしばらくまっすぐ進むと制限されたりする)操作。
普通にタイヤ転がす安定した操作、これの順列としてレースゲームが成立する。
これが普通のゲーム。
私が考えてみたゲームと大抵のゲームは逆の構造なんですよね？

マリオカートの場合は少し特殊で、ミニターボとドリフトの単位時間頭使用回数が増えるとカートの軌道はカオスアトラクターに近付く。
だから飽きない、飽きにくい？
なんて仮説をたてたりはしてます。

これを越えるゲームと考えたいのですが、まあ始めたばかりの3流プログラマなので長い目でお願いします。

今回は少し厳しく書かせていただきました。
思い込みがこれで少しでも解消されることを望んでやみません。

はっきり書きますが、数学的アルゴリズム至上主義的な考え方に凝り固まっているとしか思えません。
全ての問題を数学的に解決することは困難で、かつ効率が悪いこともあります。

ベクターですが
http://www.vector.co.jp/magazine/softne ... ml?ref=top
こういうソフトなんかすごく高度な内容に思えます。
データが壊れるというのは壊れ方のパタン数が多くものすごく大きな写像なのに、壊れる前のデータは一つしかない。
1対ｎ写像を復元する？
こういうのはやっぱり高度な数学を使ってるんじゃないかなと。

数学的に解決しようとしても時間が掛かるだけで問題は解決しません。
ファイル構造やファイル管理システムの仕組みなどを理解すればファイルを復元する方法は分かると思います。
アルゴリズムばかり勉強されているみたいなので、ソフトウェア理論に関して余りにも不勉強だと思います。

Movie Pro
映像データを切り貼りするというのは、複雑なデータ構造を入れ替えて組み立てるのでとても複雑そうなイメージです。

実際問題mpeg圧縮の理論は複雑ですが、映像フレームデータ自体の構造はさほどでもありません。
切り貼りは、映像フレームやブロックデータ単位で行うので専門家以外でも手を出せるレベルです。

六角大王Super6WinDL版
３D関係なんて法線がどうの、頂点データの補完による滑らかなつなぎがどうの、それをアニメーションさせるとか高度なイメージはあります。
GPSなんか26もの位置情報の精度向上方法があって。精度を上げたりしてますが、相互関連する難しい数学ばかりでこういうのも高度そうかなと思ったりします。

ＧＰＳの方が難しいです。
３Ｄも難しいとは思いますが、ここまでなら高校数学レベルです。

後、多人数が関係を持つブラウザゲームなんか無数の条件分岐を細かく作ってあるのが大変そうだなというイメージはあります。

それは状態遷移などの問題ですね。
とても知識に偏りを感じるご意見です。

自作ゲーム要綱

1　３Dアクションゲーム
2　簡単そうなキャラを操作するレース系
3　キャラの移動パタンを決定する関数は下記のとおりとする

ユーザーの操作に応じ、以下の関数が自キャラに適用される。

3-1　UP関数　操作に対するキャラの移動が不安定になる。(移動操作後のキャラの位置と向き、速度と向き、加速度とその向きの振れ幅が大きくなる)
3-2　maintain　キャラの移動はそのまま
3-3　down関数　キャラの移動が安定し予測しやすくなる。

UP関数は、飛行機でいえば、前進翼機に近い不安定な動きが起こるようになり、down関数は操作後のキャラの移動が鈍重な大型旅客機に近くなるイメージ。
スキーやスノボでいえば、downは移動後の旋回半径が小さくなったり、急激なターンやジャンプができなくなる。
UPは急激なターンや大ジャンプなどができるようになる。

数学的に言えば、速度や加速度や移動後の位置などでｎ次元をとり、移動前を原点にとる。
Downは安定した移動ができる範囲に操作結果が偏在する。
UPは複雑な穴ぼこだらけの範囲に移動後の結果が散らばる。

UP関数はゆっくりと間隔をおいて上昇する。
Down関数はミスやDown操作によって急激に聞く。

また、ユーザーの操作(ドリフトや空中ドリフト)等の任意の操作で上がるが、UP関数はゲーム内で上手いテクニックを行うと自然に上がる。。

UP関数が多数適用された状態では、高得点やトリッキーで高度な技に挑戦できるようになる。
そのかわり難しい。
Down関数は低得点だが安定した動きを目指せる。


地上でのレースの場合、UPやDownは地形による影響を受ける。
(スキー、スノボー、ローラースケート等のイメージのゲームでは、斜面になったコーナーなどではUP状態に近づき、平坦な路面ではDown状態に近付くなどが理想。

空中ではUPとDownは地形の影響を受けない。

まだイメージが固まらなくてこういうイメージのゲームしか考えていません。

とりあえずオブジェクト指向レベル設計とも言えません。
UP/DOWNと言う簡単な問題でもありません。
操作と実際の設計を混同されていると思います。

うーん、ゲーム設計の指摘ありがとうございます。
すいません、3流高卒なうえ、プログラム勉強中の身なので用語の使い方が出鱈目なんです、私。
関数についてはトライアンドエラーで色々な関数を自分で試そうと考えてます。

最初から設計→プログラム作成→失敗→再設計→プログラム作成・・・
と言う方針で行かれたほうが力が付きます。
それと、なんども学歴に付いて書かれてますがプログラマは今の実力が全てです。
学歴は書いても仕方有りません。

ゲームなのですが、普通は私の考えと逆、ですよね？
レースゲームなら、ニトロやドリフトを一つの写像と見ると、写像適用後の車の位置の結果が制限される。
(ニトロなら旋回が制限されるという意味でニトロ適用後の結果が制限されるし、ドリフトなら奇麗なコース取りであるかぎり狭いルートになる)
速度が上がると、旋回半径が大きくなり、まっすぐに近づき移動が単純になる。

結果が制限され大きくなる特殊な操作(ニトロならしばらくまっすぐ進むと制限されたりする)操作。
普通にタイヤ転がす安定した操作、これの順列としてレースゲームが成立する。
これが普通のゲーム。
私が考えてみたゲームと大抵のゲームは逆の構造なんですよね？

マリオカートの場合は少し特殊で、ミニターボとドリフトの単位時間頭使用回数が増えるとカートの軌道はカオスアトラクターに近付く。
だから飽きない、飽きにくい？
なんて仮説をたてたりはしてます。

これを越えるゲームと考えたいのですが、まあ始めたばかりの3流プログラマなので長い目でお願いします。

少なくてもこの理論でレースゲームを構築することは不可能だと思います。
単位時間毎の道路を走行する物体のシミュレーションを積み重ねているだけですので、何らかの関数式に載せようとすること自体が嘘くさい挙動になります。運動ベクトル、慣性、慣性モーメント、摩擦あたり計算の積み重ねです。ゲームですから小細工はしてますが逆に面倒なるようなことはしてません。

> はっきり書きますが、数学的アルゴリズム至上主義的な考え方に凝り固まっているとしか思えません。

残念ながら、その数学もアルゴリズムもろくに理解していないようですね。

少し脱線しますが、ここで「理解」という言葉を考えてみて下さい。
色々な定義がありますが、私が大切にしている定義の1つは、
「ある概念について自分の言葉で他者に説明できる段階」
というものです。

この定義によると、私の書いたことが判ってもらえたとしたら、
それは私が「理解」という言葉を理解していることを表します。
私の文章を読んでなるほどと思ったとしても、
第三者にうまく説明できないならば、理解したことにはなりません。

説明する能力という物は非常に重要なのですよ。
他人にうまく説明できない人は、自分にもうまく説明できない。
「うまく説明できないけど、ちゃんと判っている」と言う人は、
ごく少数の例外を除いて理解していません。

この事を踏まえて、過去の自分の投稿を読み返してください。
他人にうまく伝わっていると思いますか？
自分の書いていることを自分が理解していると思いますか？


最後にもう一度、コミュニケーションの能力と就職について書きます。
コミュニケーションの能力が低くて、どうやって実力をアピールできるのですか？
もしも実力を認めてもらえたとしても、実力はあるけれど使えない人物ですよ。

# 私の書いたものは別に返事を必要とする内容ではないですよ。
# 答えを聞きたいのではなく、問いかけたかったのです。

プログラム初心者の僕が言うのもなんですが、ほんとにみなさんの言うとおりだとおもいます。

正直、僕も3ヶ月しかプログラムに触れていないような入門者です。
なので、堀江さんの気持ちが痛いほどわかります。
僕も最初はあせりましたよ。こんなことしてて力がつくのだろうか？とか
それこそ堀江さんとおなじようにアルゴリズムを勉強したほうがいいのかも。
という考えでいました。
アルゴリズムは確かに便利（？）ですし、使いこなせればコーディングのとき助けになるとおもいます。
でも、アルゴリズムができるからすごいものが作れるというわけでもなく、アルゴリズムをあまり理解していなくてもなにかと作れるとおもいます。
むしろ、アルゴリズムを勉強するのは、自分でいろいろ作れるようになってからでいいかとおもいますよ。
僕もいまゲーム作ってますが、バブルソートすら完全に理解していません。説明しろといわれても無理だとおもいます。
でも、作れますよ。意外と。最初のころおもってたことがあほらしくなるぐらいね。
あれもやっとかないと、とかおもうのは当然です。いまでも僕はおもってますよ。というか僕が入門者過ぎるからかとおもいますが（笑）

堀江さんは、何か作りたい！という意識が高いようですので勉強しだいでは結構なレベルになるかとおもいますよ。
本当に僕が言うのもなんですけどね・・・ｗ

でも、僕と似ている考え方ですので、最初はサンプルコードでいいから打ってみる。
つぎに内容をなんとなく理解。そのあと自分で同じようなものを組んでみる。わからなかったら調べる。
これの繰り返しじゃないですかね。いつまでもサンプルコード見てたらだめですけど、
最初のころから何もなしはきついとおもうので（現に自分がきつかった）
一応僕はこのやり方でやってきました。意外とできるもんですよ。しかも組めるようになってくるとうれしくなって、意欲高まりますし。
好循環でいいとおもってます。いろいろ考え方はあるとおもいますけどね。

堀江さんの考えがまちがっているとはいいませんが、せっかくやる気があるようですし、いろいろ組んでみるのがいいかとおもいます。
以上、現入門者のアドバイスでした。日本語おかしかったりするかもしれませんが、お許しをｗ

ここらは本当にいろいろ考え方があるとおもいますので、僕の考えが気に食わない人もいるかもしれませんが、
こういう考えもあるんだなぁって頭の片隅にでも置いていただければとおもいます。

コミュニケーションのほうですが、これは自分でつけるしかないですね。いろんな人と会話したりするのがいいかと。
どんな内容でもかまいませんし。人と実際に話すことが一番ではないでしょうか。
掲示板などで、こんなふうにコメントうったりしてとるのもありですが、やっぱり直に話したほうがいいとおもいます。
ぼくもあんまり得意じゃありませんが、努力はしてますｗ

では、がんばってください！！

何か劣等感のようなものを感じてしまう文章が多いように思いました。
そんなに気にしなくてもやる気さえあれば現実はどうにでもなりますよ。
もっと気分を楽にして大丈夫だと思います。

私は特に学歴は高くないですし、数学的知識も別に高くありませんが、ゲームやアプリは沢山作りました。
その品質や設計効率は悪いかもしれませんが、やる気さえあれば続けられますよ。
プログラムは書いてナンボですから、沢山プログラムを書いているうちに効率的な設計ができるようになったり、
レアなバグを回避できるスキルが身に付いたりしていくものだと思います。

私は新米プログラマーですが、朝から晩までプログラムと接しているので、自然に日々勉強できていると思います。
プログラムスキルを上げるのは学力でもなんでもなく、書いた量だと思います。
確かに数学的な知識が無い為に計算効率を向上させることができない場合もありますが、
回り道はいくらでもあるので、効率に捉われなければ（専門的なことでなければ）大抵のことは出来ると思います。

プログラムに必要な数学ってかなり限られているので、必要な時に調べていく程度で全く問題なく補えると思いますよ。
（3Dプログラムやシミュレータ関連に手を出すなら少し勉強が必要かもしれませんが）

＞３流高卒のアルバイタ人生なので雇ってくれる人もいませんし。

私の知り合いのプログラマーはかなり高卒の人多いですよ。
大企業だと新卒しかとらないってことあるかもしれませんが、学歴だけで判断する企業ほどダメな企業だとよく言われます。
はっきりいって学歴関係無いと思います。

就活の時にも思いましたし、実際に就職して仕事してても思いますが、やはりみんなで仕事する時に一番大事なのはコミュニケーション能力だと思います。
意見も言わずに黙っていたり、問題が起きても誰にも相談しないような人ばっかりの集団ではとても一緒に仕事出来ません。
なので、自分のスキルを伸ばすことも大事ですが、コミュニケーション能力を伸ばすことは非常に大事です。
逆に言えばスキルがいくら高くてもコミュニケーションが取れ無さそうな人はまず企業は採用しないでしょう。
ですから

＞コミュ力低、単純肉体労働以外経験なし、プログラム能力3流、3流高卒なので雇ってくれる人いない。
＞実力をつける以外に単純肉体労度王から脱却する道があるかな？という気分です。

コミュニケーション能力の向上についてもう諦めるような姿勢ではいくらスキルを付けてもダメだと思います。
友達を呼んでホームパーティ開くとか、何か旅行とか計画するとか、もし近くに友達がいなければ趣味の合う人が集うオフ会に参加するとか、サークルを探すとか、習い事に参加するとか、
積極的に人と接することでコミュニケーション能力を向上させてはいかがでしょう。

世の中の99%のプログラムはバッチ処理ですよ。
それでもFizz-Buzzをスラスラ書けない職業プログラマがたくさんいます。
プログラム言語の関数はサブルーチンを記述するための構文です。

何ができるか答えられないと自分をアピールすることができないですね。


わたしも高卒です。
数学と物理は赤点続きで卒業が危ぶまれるほどでした。

堀江伸一 さんが書きました:どうもすいません。
特に返事を書くべき内容だともおもわなかったもので。

(；´д｀)あぁ、大した内容じゃなくてすみませんでしたね。
#堀江さんにそのつもりはないかもしれませんが、私は上のように受け取りました。
#コミュニケーションって難しいですね

堀江伸一 さんが書きました: >C言語以外にもあれもこれもと欲張っちゃうと
面接に行った時一つの言語しかできない。
というのでは不利かと思いまして、Java、PHP、C++を同時並行で勉強しています。

では以下の2人の内、堀江さんはどちらのプログラマの方がよいと思いますか？

Aさん：私はC言語しかできません。しかしC言語であればアプリケーションを完璧に設計、作成できます
Bさん：私はC言語、Java言語、Prolog言語、Haskell言語、C++言語、C#言語とたくさんの言語を使えます。
　　　　しかしそれぞれの言語で出来ることはHello,Worldを表示することだけです。

広く浅くやるよりも一点集中で一つのことを完璧にこなしてから他の言語を勉強されたほうがよいのではないでしょうか？
正直言って、一つの言語で一通りのことが出来てしまえば、他の言語を覚えるのは意外と簡単にできます。
(文法が似通っていることが多く、その言語固有の記述を少し活用するだけで、大抵は応用が利きます)

二兎を追うもの一兎をも得ずという言葉もあります。
まずは一つの言語を極めてみてはいかがでしょうか？

Dixqさんたちの言うとおりですね。僕も正直気合だけですすんできましたしね・・・。
ちょうどいまも簡単な処理に結構考えてたりしてます。考えるのが一番かなとおもいますねやっぱり。
だから、迷ってないで突き進めばいいかとおもいます。実践あるのみです。
応用はある程度基礎を固めるだけでいいとおもいます。そのうち慣れます。
応用に進むの怖がって、基礎ばっかりやってたんじゃいつまでたってもできないですよ。
たとえば、分数の計算するためにと普通の整数の足し算ばっかりやってても一生できないのとおなじです。
完璧なプログラマなんて絶対いませんし。

まあゲーム作りの場合、現実に制約される必要があるのか疑問です。
現実のスポーツグッズの場合、少しでも面白い動きができるようにと色々工夫があると思うのです。

例えばジェットエンジンを背中に背負ってそのパワーで滑る、Jetpack on Skisだったり
http://labaq.com/archives/51409808.html
リンク先のような空飛ぶホバーだったり。


ウィンドサーフィンだったり。

http://www.monogocoro.jp/category/sports
Waimea River
リンク先のようにサーフィンができる水の流れを皆で作ったり。
これ結構魅力的な光景ですが、現実だとマップ作りに制約が大きいです。

ゲームなら、リンク先みたいな流れや波を自由にマップに配置できるわけです。
波や流れが多数設定されたコースを作り、サーフボードに重さ0のエンジンをつけてレースするとか楽しいかも？
とか考えたりします。
XGamesみたいに見せるプレイも生まれると思います。
現実的な水の流れを無視してご都合主義の水の流れや波を設定したマップです。

他に陸でサーフィンに近い感覚で練習ができるTボードだったり。
色々あるわけです。

でもリンク先は全部現実という制約を受けてるわけですよね。
ゲームなら現実ではちょっと無理な動きが色々試せるわけです。
現実という制約のない、ゲームでしかできない動きを試したレースを作ってみたい。
そんなことを考えています。

例えば空飛ぶホバークラフトだったらエンジンパワーを現実では不可能な大きな値に設定してレースゲームに仕立てたり。
サーフィンならボタン一つでボードの摩擦係数を変化できるとか、ボードのフィンを可動式にできるカットのパタンを変更できるとか、ボードに力積を発生できるとか、非現実的なターンができるとか
、重さ0体積0のエンジンをつけたり色々現実ではできないことをゲームで追加できたら楽しいかなと考えたりします。

まあ、私4流(良く考えたらまともなアプリも作ったことない私の実力は4流)プログラマの言うことですので、作れるようになるのは多分数年先の話です。
気長な話です。

Youtubeより妄想快楽理論です
あるおえらい坊さんの言葉です
「妄想は快楽」

[youtube][/youtube]

プレイしたゲームがつまらなかったときに、こうすれば面白くなったのに、とか、俺ならもっとマシなもの作れる、とか思うひとはごまんといるはずですけど、ただそういうふうに思うだけのひとをクリエイターとは呼ばないですよね。

非現実的な動きはある程度現実的な動きのパラメータを弄ることで作り出すことができるものです。
非現実は現実の上に成り立っています。
現実が無ければ非現実もあり得ません。
現実の制約を受けたくないなら非現実ではなく現実との接点を持たないものを考えましょう。
いままでにないまったく新しいパズルゲームとか。
すべてのものを極限まで記号化してみる方向で。
知識も経験もない段階で、既存のものに何かを加えるようなアイデアを考えたってどうしようもありません。

プログラミングの力を付けたいなら何でも良いからお手本通りにやってみるのが良いと思います。
というかそういう気持ちが必要です。
現実の制約なのかどうか分かりませんが、とりあえず水面を表示するプログラムを作ってみては？
それができたらホバークラフトやサーフボードを水面に浮かべるプログラムを作ってみましょう。
プログラムで水面を扱うのはかなりの高難度です。
作れるようになるのが数年先とか言ってる場合ではなくて、いまからやり始めて数年後にできるようになるレベルの難易度だと思います。

まあゲーム作りの場合、現実に制約される必要があるのか疑問です。
現実のスポーツグッズの場合、少しでも面白い動きができるようにと色々工夫があると思うのです。

ゲームを作る側が、そのことを考えないはずがありません。じゃぁ、なぜ少ないのかって事を考えてみてください。日本人は比較的保守的ですが、欧米人が面白いことを見逃すと思いますか？
どちらにしてもISLeさんの言われるとおり、ちゃんと物理挙動のプログラムが作れる人が踏み出せる領分なので、まずちゃんとした物理挙動の出来るプログラムを作れるようになってください。

まあ、私4流(良く考えたらまともなアプリも作ったことない私の実力は4流)プログラマの言うことですので、作れるようになるのは多分数年先の話です。
気長な話です。

他人にとってよく分からない自己評価である３流、４流なんて実際どうでも良いんです。
よく分からないから踏みとどまるのか、良く分からなくても簡単なところから始めるの人なのかどっちかしか無いんです。
もちろん、将来完成する望みのあるのは今足を踏み出した人だけです。踏みとどまっていても何も生まれません。
私には自分で自分を縛っているとしか思えません。

私はこの掲示板このトピを見て、つくずく考えさせられます。
私は皆さんのプログラムの能力の高さに何時も驚き、どうしてあんなやややこしいものを、覚えられるのか不思議です。
要するに私みたいにボンクラでは、プログラマーは勤まらないと思いました。
プログラマーは理解力、、、これに尽きると思い、私の尤も苦手の分野です。
私は研究開発の実験室レベル、一段上がってベンチプラントレベル、パイロットプラントレベル、、そして分業化されての実用プラント。
この過程をつぶさに見てきた。
パイロットプラントまでは計算機もソフトもあったモンじゃない。手動操作、プラント運転は試行錯誤の連続です。
だからプログラムの発注なんかない。プラント設計者、オペレータ自らプログラムを組んでいました。
私の作った滅茶苦茶なソフトであったが結構使い物になった。そのソフトで毎日機械を動かしていた。そして内容を見ながら改造変更。
だからメーカに発注するより自分で作るほうが早く、打ち合わせなどの会議も不要。
メーカの人がソフトを見て感心していた。
なぜかと言えば、そのソフトを造った我々が一番プラントの事を知っているから。
そして実証段階が終わってからソフトを発注していました。
神は人を不公平に造っていない。一流であろうと三流であろうと総じて見れば差が少ないことが多い。

ここはゲーム関係の人が多い。ゲームが好きでないと、いいプログラムが造れないと思う。
余り難しい理論はどうかと思う。
私の尊敬している知人のエンジニヤで町工場の、もの造りの最前線の人がラジコン飛行機のプロレベルで、実際小型航空機の操縦もする。
マイクロソフト？のフライトシュミュレータで遊んでいた。私が操縦したら全て墜落。
彼が言うには操縦経験が無いとソフトは組めないと、、、、

関係のないことを長々書きましたが、ゲームなら何も物が壊れるわけではなく、若い人は能力さえあれば、お金も余り要せず無限の可能性があると思う。
腕を磨く絶好の機会かと、、、そして幅広い知識も得られるように思います。
時々私もソフトについて幼稚な質問もしたく思う。

堀江伸一 さんが書きました: まあ、私4流(良く考えたらまともなアプリも作ったことない私の実力は4流)プログラマの言うことですので、作れるようになるのは多分数年先の話です。
気長な話です。

一つ下がって四流ですか・・・
ぶっちゃけ何流でもいいのですが、自分を卑下するのだけはやめません？
卑下したところに何かが生まれるのであれば良いですが、結局自分の内側にネガティブな感情を作ってしまうのですごく人生を含め損をする気がします・・・

三郎さんありがとうございます。
私の場合は、単純肉体労働以外雇ってもらったことがないのでその線で仕事になるのは当面ないです。

softya（ソフト屋) さんどうもです。

私の場合通信制高校時分寝たきりひきこもりだったもので物理学の授業を満足に受けたことがなく物理学で物事を解決するのは難しそうです。
そこで数学だけで解決できる写像の概念だけでゲームを作れたらなあと妄想してしまいます。

＞プレーヤーがキャラの移動を一番予測しやすいのは「キャラの移動はそのまま」という状態のはずです。
車の場合、操作の結果がばらつく度合が大きくなる＝ハンドリングが悪いで、これは悪いことです。
でも逆のスポーツもあるんです。

サーフィンの場合車と逆ですね。
サーフィンでは最初のうち、浜に向かってまっすぐ波に乗るという世界です。

上手くなってくるとだんだんと操作に対し、結果がとても複雑な動きをするようになってきます。
ほんのちょっとの操作の違いで大きく結果が違ってくるようになる。
上手くなるほど操作に対する結果の空間がでかくなります。
操作に対する結果の多様性と鋭敏性が生まれてくるわけです。

そして、その多様な結果から適切なカッコいい動きを選択するというテクが賞賛されます。
車ゲームで言えばハンドリングが悪くなるという悪いものが、サーフィンでは結果の多様性という良いものになる。
この多様性が魅力になる。

じゃあ、このサーフィンの持つ構造。
上手くなるほど、多様で複雑な結果に結び付く動きができるようになるという構造。

この、上手くなるほど結果の多様性が増えることで生まれる魅力を何とか陸や空のレースゲームに導入できないか。
シミュレートをする時、繰り込み群としての特性を中核に何か作ってみたい。

なんて考えたりするわけです。
でもまあ、気の長い話です。

力学の勉強は手始めに構造計算の本を独学で学習してるレベルなので
動的な力学を考えるのはまだ先の話なので数年後の話なんですけどね。
まあ気長に頑張ってます。

＞一つ下がって四流ですか・・・
でもやっぱり世間を見渡すと、最新ゲームとかデータ解析とかニューロネットとか自然言語処理とか数億*数億の数値データを行列で解くとか、レベルの高いプログラムばかりに見えて、自分は4流だなというのが実感です。
最低レベルから脱出するために精進あるのみ。
自分を卑下するというよりも、回りの凄さに圧倒されてひたすらレベルアップを目指すというやる気の感覚に結び付きます。

もういいや、何を書いても完全に無視されるし(；´д｀)

堀江伸一 さんが書きました: >3流ってのは、何ができて何ができないのですかね？
まだ私低レベルプログラマなのでよくわからないです。

3流の基準も分からないのに今度は4流なんですね。
よく分からないけどとりあえず4流って言われても説得力ないです。
これだと卑下し放題ですね。
自分の中でだけ卑下するのは勝手ですが、公共の場で卑下する書き込みをされると
不快に思う方がいますので、そういう方のことを考えてはいかがでしょうか？

といっても私の書き込みは無視されるのでしょうけど(´・ω・｀)

>構造計算の本
いや、高校物理でそんなの習いませんよ。建築学の分野ですし、物理シミュレーションで役立つ訳でもないでしょう。
高校物理の本やサイトを読んでみれば分かります。

「わかりやすい高校物理の部屋」
http://www.wakariyasui.sakura.ne.jp/

なぜ、そんなに面倒な考え方をするのか私には分かりません。

水をさすようで悪いですが質問内容と全く別のものになっているので他で立ててやったほうがいいのでは

roxion1377 さんが書きました:水をさすようで悪いですが質問内容と全く別のものになっているので他で立ててやったほうがいいのでは

roxion1377さんに同意します。
質問ではなくて、雑談と言うか自分語りのようになってしまっていますので
別トピ立てるか、日記かブログで書べきかと思います。

回答者が今の話をしているのに対して、堀江さんが遠い先の話をしているので話が噛み合わないですね。
既に回答者に対する返答では無くなっているので、これ以上私たちのアドバイスが必要なければこれトピックは終了する時期かと思いますが、今やることについて助言がほしいと思われるなら続けてもらって構わないと思います。

私のシューティングの弾の軌道の計算です これだけでゲームが成り立っています
複雑な物理の計算もないし、y座標を-16してｘ座標を±5するだけです
現実の物理の計算式を導入すれば、現実っぽい動きをするのは予想できますが
それが、かならずしもおもしろいとは限らないのはゲームをしたことがあるなら自明ですよね
ファイナルファンタジーシリーズのどれか忘れましたが、ゲームスタートと同時にいきなり
ラスボスと対戦という、完全に理不尽な環境というのもゲームの要素だと思いました
これは、必ずしも y = x + 1 のように右上がりの直線の現実ではなく
まったく予想のつかない現実を反映しているように私はうけとめました
それと同時に厳密な計算されたグラフィックの美しさも知りました

何がいいたいのかというと、高度な技術を使えば高度なものができるということは
ゲームにおいて成り立っていないと私は思っています

あと、日記やブログなどで色々思ったことを公開すると、共感された方がくるかもしれません
気をつけて欲しいのは、どこまでをネットに公開するのかということです
あまり個人を特定できるほどの情報をネットに公開すると、どこの誰かもしれない方からメールがきたり
いたずら目的だったりいろいろやっかいです

返信は期待してませんが、私からのメッセージでした

遅い気もしますが、勉強もできなければプログラマーでもない4流以下のただの高校生から言わせてもらいます。
論点がずれているかも、言葉も汚いです。すいません。

数学はプログラミングにおいて置き換えれば何でもできる魔法のツールのように捕らえている気がします。
ですが、プログラムはどう「動かすか」が問題ではなく、どう「動くようにする」かが問題だと思うのです。
紙の上にいくら設計を書いて計算式を並べたところでそれらは動きませんし、机上の空論にしかなりません。
他人の設計を眺めても同じことです。
プログラムを打ちバグを取り除き、動くようになって初めてスタートです。
複雑な動きや面白いゲームシステムなどの機能は、あとからいくらでも付け足せます。

逆にものすごく画期的なアルゴリズムを見つけたとしても、ゲームをやっているユーザーなんかが、
「このゲームのアルゴリズムすごい！」なんていうことは絶対にありませんし、普通のプログラマーなら評価されないそんなマゾな分野は探求しません。
でも「教科書に載るようなアルゴリズムが作れるような1流（？）にあこがれる！」というのなら止めはしませんが違いますよね？

その道のプロという人のほとんどは生まれながらにしてその領域に達しているわけではありません。
才能という言葉はありますが、堀江さんが見てきた人や物はそういう類の人を指しているようには思えません。
上達に違いがあるにしても、そこにあるのは経験以外の何ものでもないと思うのです。
ネット上にある素晴らしいプログラムを作りたいと思っているのであれば、口やペンよりキーボードに向かってみてはと思うのです。

余計ですが、回答者さんの何人かは堀江さんが課した問題に、
具体的なプログラムやアルゴリズムを書いて、説明している方が何人かいらっしゃいますが、
余計ややこしくしているだけの気がします。

プログラマの能力というものに関しては、プロとアマの違いはほとんどありませんね。
儲かるように企画を考え納期に間に合うように作るのがプロです。

今回も見事にスルーされたので書いても無駄かもしれませんが…。
自動車レースは何もしないと真っ直ぐ走れないところを真っ直ぐ走るのが目標。
サーフィンは何もしないと真っ直ぐ進んでしまうところをさまざまなアクションをして見せるのが目標。
目標が真逆ですよ。

下手なひとが自動車レースゲームをするとスピンしてクラッシュしたりしますが、そういうのが楽しい方向に持って行きたいのでしょうか。
残念なことに、日本ではほとんど見かけませんが、海外ではその手のぶっ飛んだレースゲームは腐るほどあります。
ジェットコースターのような上下左右に曲がりくねったコースを超高速でぶっ飛ばし、クラッシュ上等といった感じのものですけど、わずかですが日本向けに移植されたものもありましたよ。

Wii Sports Resortが出た当時、ウエイクボードの波の表現がすごいとゲームプログラマの間で話題になりました。
研究のためにプレイしてみてはいかがですか？

多くのお返事ありがとうございます。
1スレッドにすぎないこのスレにこんなにたくさんのレス、閲覧数も増えるとは思いませんでした。

＞海外ではその手のぶっ飛んだレースゲームは腐るほどあります。
うーん、私の勉強不足ですね、私の発想は海外風だったのか。
皆さんに簡単な場合から始めるようにと言われたので、できるだけ簡単なアイディアの車ゲームを考えてみました。
操作系はPS3コントローラーイメージです。
L1ボタン押し中、車の摩擦係数を急激に減らす、L2ボタンはタイヤの摩擦係数増加、L1,L2を押してない時は摩擦は急速に標準値に戻る。
R1ボタンを押すと、車の向きと車の進行方向が分離する、R2ボタンはアクセル車の今の向きに力積が発生する。
R1ボタンを離すと車の向きと進行方向が一致する方向に戻り始める。
R1ボタンを押してない時は、車の向きと進行方向は一致する？
ってこれじゃスケボーに近いですかね、操作も複雑になりすぎかな？
とも考えますがどうでしょうか？
アイディアだしもまだ不慣れで、物理ゲームの本質なんてのも良くわかってない低レベルのアイディアですが、頑張って考えてみました。

＞Wii Sports Resort
購入して試してみます。

>これだけでゲームが成り立っています
作るなら面白いものを作りたい、そう考えてついつい難しい方に向いてしまいます。
当面は、簡単なものを作る。
で行こうかと考え直しました。

＞物理シミュレーションで役立つ訳でもない
簡単そうな静的な場合を学習してから難しそうな動的な場合と考えましたが学習方法間違えてたかな私。

＞応用に進むの怖がって、基礎ばっかりやってたんじゃいつまでたってもできないですよ。
うーんそんなもんですかね。

＞現実の制約を受けたくないなら非現実ではなく現実との接点を持たないものを考えましょう。
私の今の実力だと、パズルでもいいのかも。
物理ゲームは数年先を目指して、簡単なものをこつこつ作ることから始めてみます。
日々のLVUP大事ですね。

＞将来完成する望みのあるのは今足を踏み出した人だけです
ありがとうございます。
毎日少しずつレベルアップ、目指してます、頑張ります。
＞自分の中でだけ卑下するのは勝手ですが、
すいません、卑下してるつもりはないんです、客観的にみたら4流分類されるんじゃないかなと感じてるだけで主観です。
＞三郎さん
どうもです。

コミュニケーションについても日々のレベルアップしかないと思うのでこの面も頑張ってみようかとおもいます。
みなさん励ましやアドバイス本当にありがとうございます。