開発のトレーニング

こんにちは mtj です。

ゲームをよくする手前 購入した人にダメージをあたえる いわゆるクソゲーとなるものを購入する頻度は高い

購入したお金はもうどうしようもないが そこから友達と何故これが産まれたかを話し合うのはとても面白い
またプロジェクトで自分がこういう物を作らないようにするためのトレーニングにもなります。

ゲームは様々な要素が組み合わさってできています
・コントローラーでの操作性
・UI等のデザイン(配置等も含む)
・ゲームとして面白さ
・シナリオとして面白さ
・3D等グラフィック
それ以外にもジャンルによっては様々ありますが ゲームの内容によって何が足りないか
何故足りなくなったがだいたい想像できます

そういった要素ごとに色々考えながらマネージメントの本を読むとマネージメント力が上がると思います
また、ここからどうやったら面白くなる、改善案等も考えることでそのような製品開発のトレーニングにもなります。

是非マネージメントをやったことが無い人はクソゲーをクリアしてトレーニングしてみてください。
いい勉強代になると思います。

PGの作りが良いか

こんにちは mtj です。

PGの作りが良いか悪いかこれがわかるようになるかは勉強するだけではわからないことが多いと思います。
実際に良い作りがわかるのはそのソフトを改造、保守する、別の誰かが改造するときにわかりやすいものです。

改造、保守等がしやすいなら基本良いプログラムだと思われます。

コードを書くだけであれば現状のコードをコピペしたり、メソッド等に分けずに書いた方が早い場合があります。
メソッドに分けるために頭を使わないのでその時は速くなります。
コピペも現状の動作が繰り返されるならそれで問題もなくなります。

しかし上記のコピペ等にバグ、変更等を行った場合 コピペした箇所を全部探したり
メソッド分けもされていないような長いコードを読んで影響範囲を調査したり不都合な事が多く発生します。

PGは本を読んでの座学だけでなくアウトプットが必要という話がよくあるのは作らないとわかないことが多いためだと思います。
新しい事を学んだら頭の中でも仮想でもいいのでアウトプットすることを心がけるとPGのレベルアップが早くなるかもしれませんね。

プログラミングのゲーム

こんにちは mtjです。

色々とSwitchのゲームを見ていると割とプログラム系のゲームが多い

”つくってわかる はじめてゲームプログラミング”とかを見てもよくできていると思うし
こういうものからPGに入ったほうがプログラミングの楽しさがわかると思う。

自分はPGの教材を最近は読みませんが、昔に読んだ記憶では ループをさせて 標準出力に1,2等を表示するような例が多かったと思う
正直上の例ではPGはわかるがPGの楽しさは全く無いと感じる。

そういう意味ではSwitchのプログラミング系のゲームは動きを見ながら調整でき 自分で作り変えている感がすごい出ていると思う。

正直コンソールでの勉強はもう古いように感じる、せめてフォーム、画面を出しての動作か Webブラウザ上で勉強する系のプログラムのほうが覚えやすく、楽しいんじゃないかと感じた。

今年初めに実家に戻った時福井の雪を久しぶりに見ました。
自分の子供の時より少なく 10cmぐらい積もった程度でした。

雪国で暮らしていると雪で一面白くならないと冬が来た感じがしません
最近は福井でも12月はあまり降らなくなっているのでいいものが見れたと思います。

子供のときから雪を見ていると雪が降ってきても冬だなー程度しか思うことはなく
考えることといえば明日自転車で学校いけるのか 電車が止まって帰れないんじゃないかになります。
電車が止まる、自転車通学できなくなれば何十分も真っ白で一直線の農道を歩くことになります。
雪で歩きにくく、寒いので割と苦行でした。

自作PC

こんにちは mtjです

今回自分の使用しているPCをAMDからintel12世代にしました。
CPUの交換は約3年ぶり IntelCpuは10年ぶりぐらいになります。
DDR5+intel12世代で色々と快適になりました。

久しぶりのCPU交換だったので色々失敗
AMDCPUは交換時にすっぽんしてしまったのでマザボにダメージがあるかもしれません。
CDドライブの電源コネクタにエアーをしなかったので内部でショートしたのかCDドライブも動かなくなりました。

CDドライブはだめになりましたが intelCpuもCPUクーラーも簡易水冷にしましたが問題なく動いています。
消費電力は高負荷時で約500Wぐらいでした。
PCは満足な状態になったのでいい買い物だったと思います。

簡易水冷をつけて思いましたがPCケースが大分狭いと感じました。
時代の流れでグラボ等色々巨大化してるので10年前のPCケースではもうそろそろ限界かもしれません。
今度大きい変更のときにPCケースも新しくするべきかもしれません。

カーネルレベル

こんにちは mtjです。

最近カーネルレベルで対策を行うアンチチートソフトが話題になっている。
カーネルとは と思う方はリングプロテクションで調べてみると早いと思う。

今までの権限では監視しきれないから 低層で動かし広い権限で監視を行おうということだと思う。

昔ならばDirectXをフックして色々するチートが合った気がする
アンチチートソフトがバイナリパターンとかの監視をしているので それなら直接DirectXの動作を書き換えてしまおうという感じなのかもしれない。
現代ではそのレベルでなく デバイスドライバレベル、どこかでUEFI BIOSレベルで動いているという記事も見た気がする。
UEFI BIOSならばリング-2か-3のはずなので 本当にカーネルレベルのリング0だと検知できない気がする

そういったチート対策の記事を見てPCが高度化したことにより解析、脆弱性を突く方法もどんどん高度化しているんだなと感じる
コンピューターセキュリティは本当終わりがなさそう

そして、チートは別としてプログラマーとしてはそういった低層で動くプログラムをどういう風に作り どういう風に導入しているか気になる。

プログラムの勉強について

こんにちはmtjです。

プログラムの勉強について プログラムを勉強しようとして本を読むと大体挫折してしまうと思います。
IF文、For文という文章を読んだとしても分岐、繰り返し処理をするものだとわかってもそれを使う場面が想像できないと只詰め込むだけになってしまうためです。

プログラムの勉強はインプットとアウトプットが合わさって初めて物になると自分は思います。
繰り返し、分岐の話もそれを元に何が作れるかを考えると勉強も捗ると思います。

例えば繰り返しで簡単な時計を作ろうとします。
Forループでは固定回数しか動かせないので時計は途中で止まってしまいます。
そこでWhile等の無限ループを覚え、無限ループをするとメインスレッドが止まってしまうので別スレッドの動き等を学んだりします。

上記のように何かを作ろうとすれば付随していろいろな事も勉強できます。

プログラムを教える人達(主に学校で)がそういう意識を持つことでもっとプログラムの面白さ、簡単さを伝えられるのではないのかなと思いました。
プログラムの難しさはプログラム自体じゃなく勉強の仕方自体にあると自分は思います。

プログラマーの必要性

こんにちはmtjです。

現代の小さくて安いAIカメラ等を見て思いますが 最近はプログラムレスで面白い機能があるサービス、商品が大量にあります。
その商品自体はプログラムで組まれておりますが 使う側はプログラムがほとんど必要ありません。

昔に比べてプログラムですべて作るより、プログラムで使える面白いサービス、商品にアンテナを貼り
それらを上手に使用する能力のほうが現代では必要ではないかと思います。

特にクラウドサービス類は1から作るとしたらとんでもない労力になります
作り方を知っている、想像できるまではあってもよいのですがそれらシステムを実際に作る必要がある人は一部の人でしょう。
大半の人はそれらを上手に使用する方法を覚えたほうが物になります。

今後の展示会等でもそういった物を覚えていけたら良いなと思いました。

リモート環境の変化

こんにちは、mtjです。

最近リモートでライブ映像がリアルタイムで見れる等色々なものが遠隔でおこなるようになっています。
ネット環境の進化もありますが一番はクラウド環境でしょう。

昔であればストリーミングであれば想定人数に耐えれるだけのサーバーを用意してそれ用にネットワークを構築して等ハード面で様々な準備が必要でした。
現在はボタン1つで1日もせずにサーバーを増やせます。
足りなくなったら即増やし、不要になったら即破棄できサービスの運用もそういう意味では簡単に作って、破棄というのができるようになり便利になったような気がします。
今後はそのようなサービスに対してフットワークが軽い人が人気になるのではないのかと感じました
便利なサービスが出た場合に提案、対応しさらにクラウド環境を便利にしていく そういう時代になっていくのかなと感じました。

.Net Dictionaryの速度

先日大量のデータを処理集計するために Dictionaryに格納していたのですが
10万件を超えたあたりで急に速度が落ちることがありました。

Dictionaryのキーを任意作成のStructにしておりましたが 別にテストで作成したものでは1万、10万、100万はDictionaryの個数に比例して増加しておりました。
(1万件が80msecならば 10万件は800msecのような状態)

今回のデータ処理用に作成したものは10000件で100msec程度だったので 30万で3秒前後だと考えておりましたが実際には7時間でした。
遅い原因を調べるために.Netのソースを確認し結果的にはStructのHashCodeが重複しやすい物の場合は今回の様な結果になるのではないかと思いました。

DictionaryのContainKeyの内部で使用している部分

        public bool TryGetValue(TKey key, out TValue value)
        {
            if (key == null) throw new ArgumentNullException("key");
 
            int bucketNo, lockNoUnused;
 
            // We must capture the m_buckets field in a local variable. It is set to a new table on each table resize.
            Tables tables = m_tables;
            IEqualityComparer comparer = tables.m_comparer;
            GetBucketAndLockNo(comparer.GetHashCode(key), out bucketNo, out lockNoUnused, tables.m_buckets.Length, tables.m_locks.Length);
 
            // We can get away w/out a lock here.
            // The Volatile.Read ensures that the load of the fields of 'n' doesn't move before the load from buckets[i].
            Node n = Volatile.Read(ref tables.m_buckets[bucketNo]);
 
            while (n != null)
            {
                if (comparer.Equals(n.m_key, key))
                {
                    value = n.m_value;
                    return true;
                }
                n = n.m_next;
            }
 
            value = default(TValue);
            return false;
        }

GetBucketAndLockNoはこの通り

        private void GetBucketAndLockNo(
                int hashcode, out int bucketNo, out int lockNo, int bucketCount, int lockCount)
        {
            bucketNo = (hashcode & 0x7fffffff) % bucketCount;
            lockNo = bucketNo % lockCount;
 
            Assert(bucketNo >= 0 && bucketNo = 0 && lockNo < lockCount);
        }

上記Nodeの取り出しのバケットNoがhashcodeを使用しているのでカスタムのKeyを使用する場合はHashCode十分に分散するか考えて作成していかないといけないのかもしれません。
遅い原因はチェック中なのでHashCodeの件は間違っているかもしれません進展があれば再び書きたいと思います。

ちなみにコードはこちらで確認できます。