お休み中にLinuxを入れようとして苦戦しただけのお話

とある、休みの日の出来事です…

webアプリの勉強しようかなぁ

前、同僚の方にRuby On Railsの書籍が無料で分かりやすいよと教えてもらったので
よしやってみよう…

どうせやるならDockerでやりたいなぁ

古いPCあるから、Docker用PCにしようかな?

とりあえず、軽量Linuxを入れよう

Arch Linuxって自分でカスタマイズできるのか…面白そう

インストールできました♪ でも、ここからどう設定すればいいんだろう…

このままだと埒が明かないから、TiniCoreLinuxに切り替えよう…

よし、TinyCoreLinuxインストール出来た…
でもDockerだけ使うならCLIだけで十分だよね?
デスクトップ画面いらないなぁ…

CLIだけも入ったぞ…ん?Dockerどうやって入れるんだろ?

…なんかうまく行かないからOS変えてみよう…

おや?Docker用にカスタマイズされたOSがあるらしい?
とりあえず、軽量な Bargeを入れてみよう…

無線LANが繋がらない…どうしよう…
ええい、RhancherOSだ、こっちを入れてみよう…

こっちも無線LANが…軽量なOSを選んだ弊害かなぁ…

と、四苦八苦して、Installに失敗し、
結局別の日にXubuntuを入れてお終いになりました。

やりたい事は全然できませんでしたが、
その代わりに色々な経験を得ることが出来ました♪

・1日にOSを4種類もインストールしました~人生初です~
・軽量なLinux、Docker用のOSでどんなものかのさわりは分かった気がします~
・RhancherOSに付随して、k3sとかRhancherというものがあることも知りました~

WEBアプリの知識は得られませんでしたが、
失敗してもただでは転ばないcacaponなのです(笑)

とりあえず、なんかやってみたら何かしら得るものがある
っていうのを経験できてよかったなぁと思うcacaponなのでした~
でも、次はWebアプリの勉強したいです~

cacaponがゲームを考える時に考えていること

今日のテーマはゲームを作る時に何を考えているのか?です~
cacaponは正直ゲーム開発始めました♪くらいのレベルですけど、
だからこその視点があるかもしれないので書いていきたいと思います~

cacaponがゲームを考える時、
大きく分けて二つの段階があるなぁと考えてます~

一つが、ゲームのアイデアを出す段階
もう一つが、イデアを現実に落とし込むです~
それでは、それぞれ詳しくcacaponの自論を書いていきますね~


①ゲームのアイデアを出す段階

人によっては難しいところかなと思いますが、
cacaponとしては一つだけルールを決めて考えてます~

それは「自分がそれをやってみて面白そうかどうか」です~
それがOKだったら即採用ですね~

それだけ決めて、あとは自由に想像してみると良いです~
何かと何かを組み合わせてみたり、
何かの要素をピックアップしてみたり、
「こうだと便利だなぁ」を実現してみたりですかね?

cacapon的には、寝起きに考えると良いと思います~
理知的な部分が若干ブロックされているので、
へんてこな事でもすんなり思いつきやすいので~

因みに、この段階では実現できそうかは考えていません~
それを考えてしまうとアイデアの幅が狭まってしまうので~

②アイデアを現実に落とし込む

そんな感じで思いついたものは、まだ頭の中の世界にとどまっている形になります。
頭の中だと水を得た魚のように生き生き動いているんですけど、
現実世界に水揚げしたとたん、死んだ魚のように動かなくなっちゃうんですよね~

なので、現実世界でも生きられるように、
論理でアイデアを落としこむ段階が必要になってきます~
それはもう徹底的に落とし込みます~
あいまいな部分はゲームにできませんからね~

ある荷物を所定の位置に運ぶゲーム(倉庫番ってゲームですね)」という
イデアが出たとしたら、
「プレイヤーが荷物を運ぶには?」
「動かした先に荷物があったらどうする?」
「動かした先が壁だったら?」
「どうやったらステージクリアになるの?」
「そもそもステージにはどんな要素があるの?」
といったことを考える必要がありますし…

その後のパワーアップすることも考えると
「ステージ増やすにはどうしたらいい?」
「追加したステージがクリアできるかどう判断すればいいの?」
「プレイヤーが走れるようになったけど、今までのステージで遊んでも大丈夫?」
とか、
「チームで開発するんだったら道具は何を使うの?」
「どうやって情報を共有すればいいのかな?」
とかゲーム以外の部分も考えていかないといけなくなります~大変です~

でも、そこまでできないとゲームは作れないと思います~
そして、技術的な部分とか時間とかいろいろと制約があるので、
イデアの一部をあきらめなきゃいけない部分も出てきます~

cacaponが一人で作る場合は、主に映像面とBGMが犠牲になります~
あと、大きなゲームを作る技術力もまだないのでミニゲームどまりになりますね~
なので、だいたいファミコン初期の2Dか
ゲームエンジンの〇とか□とかを使ったゲームになることが多いです~

そもそも頭の中身を表現する道具が分からず断念したアイデアもありますね~
現実は厳しいのです~
でも、そこを乗り越えてゲームを作れたら嬉しさも人一倍強いのです♪
だからゲーム作りは面白いですね♪


終わりに

cacaponが考えていることはどうでしょうか?
もっと経験が増えてきたら変わってくるのかもしれませんけど、
何かしら参考になったらうれしいです~

それではまた次のブログで会いましょう~

なんでも許可なしにやるっていけないですよね?(できませんでしたけど…)

先日書いたそろばんの分析のやつを見たら、
星をつけてくれた方がいらっしゃいました~
ありがとです~うれしいです~

 

cacapon's diary って結構いろいろ話題が飛ぶから見づらいブログだと思いますけど、
これからもよろしくお願いします♪

 

さて、今日のブログですが…今日はそろばんじゃないです~
Githubのお話を書いていきます~

 

Githubでプルリクエストをしてもらった後、
何も設定していないとApprove(許可って意味らしいです~)をもらわない状態で
masterにマージできたりしちゃうんです。

 

これって、やっべぇのがメインのプログラムに入っちゃう可能性があるので、
結構まずいなぁと思うcacaponなのです~

 

んで、調べてみたところ、
なんと、「何人許可もらったらマージできるか設定できる」らしいのですよ♪

https://help.github.com/ja/github/administering-a-repository/enabling-required-reviews-for-pull-requests

 

よし、では設定しま…

f:id:cacapon:20191213162903p:plain

なんと、リッチなコースか公開しているリポジトリじゃないと使えないようなのです!

…cacaponは恥ずかしがりやなので基本プライベートなリポジトリなのです~
しかもお金払ってないフリーな奴です~ 使えないのです…

Github使っている皆さんはどうなのですかね?Publicでやっているのかな?
それともランクの高いコース使っているのかな…

そんな方でしたら使えますので、

⚙Settingsを開いて~
Branchesを選択して~
Branch protection rulesのところにあるadd ruleを押して~
Branch name pattern に master と入れて~
Require pull request reviews before merging にチェックを入れれば…

ちゃんと制限されるはずです~
まずい対応を入れないためにも、試してみる価値はあると思います~

 cacaponみたいにフリーでプライベートで少人数で運用している人は
ルール作りをして、やっべぇやつを入れないようにお互い気をつけてく感じになるのでしょうか… 

UE4で自動でAdmobのテスト広告と本番広告を切り替えるやり方(Android編)

備忘録で残しておきます~

GoogleAdmobを使うときは自分で押しちゃダメなので、
自動で開発中と本番を切り替えられるようにしたいですよね?

UE4Android用の対応はできましたのでそれを残しておきます~

 

1.広告IDを設定する。

f:id:cacapon:20191206130310p:plain

プロジェクト設定から

Ad Mob Ad Init IDsにエレメントを追加して、
0番に本番のID、1番にテスト用のIDを設定します~
因みに、写真のIDは写真用にテスト広告のIDを貼り付けただけです~

2.表示させる箇所に写真のようにブループリントを組む

f:id:cacapon:20191206130622p:plain

Is Packaged For Distributionがキモ

Is Packaged for Disribution は
shippingでパッケージ化したときだけtrue」になりますので、
それで、呼び出す広告IDを変えています~

…あ、AdIndexは自前のinteger変数です~

これでおしまいです~
意外と簡単に設定できました♪

そろばんビギナーのcacaponが、初心者なりにそろばんの足し算を分析してみるお話

最近、自分の能力をもっと高めたいと思っているcacaponなのですが…

どうすればいいのかな?と考えて

「やっぱ勉強でしょ」となりまして

どうせなら基礎的な所からしっかりとと考え

勉強の基礎と言えば「読み書きそろばん」と思い至り…

読み書きはともかくそろばん分かんねぇ…となりまして…

 

そろばんをやってみることにしました(笑)

 

まったく、そろばんもイロハも分からないcacaponですが、
とりあえず、4桁の足し算、引き算、見取り算くらいは
難なくできるくらいにはなってきたのです♪

掛け算割り算?そんなもんは分からんのです。

ただ、どうしてもやっているとうまく不思議に思うことや、
他はすんなりいくのに、ここはちょっと頭使う…
みたいなところがちょいちょいぶつかりまして…

今日はそのあたりの話をまとめられたらなぁと思います~

1.引っかかっているところ

cacaponが引っ掛かっているのはある足し算をしているときですね~
例えば8+3。これ暗算でやると11ってすぐ出るんですけど…

f:id:cacapon:20191129235042p:plain


そろばんの操作を分解すると上のような図になります~
cacaponが引っ掛かるのは④の部分。

8+3だと2つ球を下ろしたり、5の玉を上に戻したりするんですけど、
8と3の計算なのに、5とか2とかが出てくるんですよね。不思議ですよね?
ともかく、そういうのが発生すると詰まる傾向があるのです~

詰まると計算速度とか下がるのでまずいなぁと思い、
他にもないか調べてみました~

0+0から9+9まで100通り、
cacapon的難易度設定をしてみたのがこちら~

f:id:cacapon:20191130002439p:plain

Aは簡単、特に考えなくていいやってところ~
Bもそこまで深く考えなくてもできます~
Cが問題の所で、玉を動かすときに頭を使ってしまうところです~

こうやってみるとちょいちょいありますね~
よくよく見たところ、Cにはある共通点が…

そう、Cに共通しているのは繰り上がりがあるのです~

「3+3とか繰り上がってないじゃん」とか思われるかもしれませんが、
桁が上がらなくても、5の玉の操作があるのですよ…
cacaponは勝手に5玉の繰り上がりって呼んでます~
(※たぶん正式名称ではないのでご注意です~)

cacaponの感触ではそろばんって、
5進数と10進数の複合的な計算ツールみたいなイメージなのですよ~

因みに、なんで繰り上がりがある場合だと詰まってしまうのかなのですが、
5玉の繰り上がりや桁の繰り上がりが発生すると、
そろばんでは「補数で引き算を行う」という操作が出てきます~

補数っていうのは、10進法の場合、
ある数が足して10ⁿになる場合の足す数の事を言います~
例えば…
ある数が6だったら補数は4
ある数が、34だったら、補数は66のような数字の事です~

…cacaponは補数の知識はむしろ聞きかじり程度なので
あまり詳しくはないのですが…

と、ともかく、そろばんでは繰り上がりが起きた場合、
5玉の繰り上がりの時は、足して5になる数字を、
桁の繰り上がりの時は、足して10になる数字を
そのまま引き算として使うことが多いようなのです~

最初の図を見てみると分かりやすいと思います~

f:id:cacapon:20191129235042p:plain


8+3の動きですね~
この時④の一桁目の動きに注目すると、
3に対して、補数に当たる7で引き算しているのが分かりますでしょうか?
こんな感じで使っているのです~

ただ、ここにぶち当たると、計算が遅くなってしまうので、
自分が納得できる理論なり考え方をできないと、
ちょっとまずいかなと思います~

プログラミングでいうと、
再帰関数とかfor文の中にバグがあって、
そこを呼ばれる度にweitが発生しているような感じなので、
桁が増えるたびに処理に悩まされる可能性が高くなるのです…
どうにか出来ないかなぁ…

 

終わりに

今日は、そろばんで詰まっているところを深堀してみました~
はたから見たら大したことない部分かもしれませんが、
こういったことにもプログラミングや日々の生活に
役立てる知見が見つかるなぁとこの頃思うcacaponです~

 

今回の分析とは少し話がずれちゃいますが、
そろばんやり始めて最近気づいたことは、
繰り返し同じことをしているとだんだんと効率化するように
頭を働かせているんだなぁというのがだんだん実感できるようになりました。

今回のもその一つかなと思ってます~

こういったことの積み重ねってイノベーションとかに繋がるのかな
ともふと思いました~

ちっちゃいゲームでも開発しまくっていたら、
ある日こんなのがいいんじゃない?
みたいなのが思いつくのかな??
ちょっとワクワクしますね♪

 

UE4 セーブロードの作り方

UE4のセーブとロードに関してです~
備忘録として残しておきます~

 

 

準備
まずSaveGameクラスを作成します~
新規ブループリントから作成できるんですけど、
ボタンの所にはないので検索して見つけます~

f:id:cacapon:20191122140507p:plain


作り終わったらブループリントを開いて、
その中に保存したい変数を定義します~

f:id:cacapon:20191122140335p:plain

今回は単純にクリックしたカウントを保存したかったので
S Countという変数にしました~

セーブとロード

f:id:cacapon:20191122140115p:plain


今回は確認したかっただけなのでレベルブループリントに書いちゃいましたが、
多分どこに書いても大丈夫です~

セーブの作り方は以下のような感じです

  1. Create Save GameObject を作って、
    先ほど作ったSaveGame のブループリントを SaveGameClassに設定します
  2. SaveGame のブループリントの変数に保存する値をセットします
  3. Save Game to Slotを使って保存します。
    保存する名前とIndexも設定しましょう~

ロードするときは以下のような感じでした。

  1. Load Game to Slotで名前とIndexを指定します。
  2. 作ったSaveGameのブループリントをCastしてきます。
  3. セーブした変数を本番の使いたい変数にセットします。

便利な機能?

f:id:cacapon:20191122141709p:plain

これはセーブデータがあるかないかを判定するノードです~
bool型の値が返り値になります~

「セーブデータが無かったらセーブして、無かったらロードする」
みたいな処理をしたいときに使えるかなと思います♪

cacaponはこの後ろの判定をミスっててセーブできない…出来ない…
と2日ほど悩んでました…

 

ぱっとまとめると結構簡単に取り扱えそうに見えますが、
cacaponみたいにBP初心者が作ると良く分からんところではまったりします~

早く慣れたいですね~

あえて作ったバッドなプログラムを修正してみただけのおはなし

突然ですが問題です~
これは何をしているプログラムでしょうか?(pythonのプログラムです)

 

これは何でしょう?

 

正解は…fizzbuzzのプログラムでした~

なんでこれを作ったのかと言いますと、
プログラムって色々ルールがあったり、
きれいにみせるためのHowtoとかいろいろあるじゃないですか?
例えばこの本とか…

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

じゃあ、逆に分かりづらく書いたらどうなるかな?と思いまして、
作ったのが先ほどのプログラムになります~
ポイントとしては

  • 意味のない名前できたグローバル変数

  • 揃っていない行間・空白

  • 不要なコメントをつけ、必要なコメントを付けない

を意識した結果になります~
ホントはもっと分かりにくく作りたかったけど、
cacaponとしてはこのくらいしか思いつきませんでした… 

さて、作ってみた結果ですが…
ん~まだ読めるかなって感じですかね?
ただ、これは二十数行のコードだから読めますけど、
これが1000とか2000とか増えて
こんな感じだったらと思うと...恐ろしいですね。

これに複数個所で編集できちゃう変数tmpとか
マリアナ海溝並みに深いネストとか
他にもきっと私が知らないトンデモプログラムが世の中にはあるのでしょう… 

 

これを作っただけでも「きれいに書きましょう」
というのは必要だなぁというのは再認識できました~

でも、このままで終わりはちょっともったいないかなと思いまして、
折角だからこれを修正してみましょうか~

 

修正1:名前をしっかり付けてみる

まず目につくのがfuncとvarですね。
皆さん、書くときにそんな名前つけてませんか?

命名するときはその役割をちゃんと意識した名前にする必要が
あると思うんです。

そんなわけで英語が苦手なcacaponがうんうん唸った結果…

修正1

 

 こんな感じになりました~
fizz_buzzの使う単語、何番目かを表示するためのcount、
後は冒頭で何番目から何番目までを表示するか指定できるようにもしました~

名前を整えた時に不要な変数を消したり、処理も一部すっきりさせたので、
これだけでもだいぶすっきりした見た目になったかなぁと思います~

修正2:適切なコメントに切り替える

 

皆さんプログラムにコメントってつけてますか?
私はなるべくつけてます~

でも、意味のないコメントつけてませんか?
今回のだと、「指定した数値その1からその2まで繰り返す」とか
「countが3だったら」とか
プログラム見たら分かることを書いているんですよ。
それだと意味ないですよね?

という訳で修正したのがこちら

修正2

私がコメントを付けるときに意識しているのは、
「こういう風に実装したんだ」という思考のメモと
後で見返したときに分かりにくそうだなと思ったところ、
ここを直しておきたいなぁというところにコメントを入れてます~
あとは、この関数は何をする関数か?ってところですかね?

TODO:とかの書き方とかはリーダブルコードを参考にしています。
意味としては、後で手を付ける、って感じですね~

 


修正3:体裁を整える

 


今回わざと、文字間隔を揃えてなかったりしたのですが、
これをするだけでもだいぶ見やすくなります。
この辺に関しては、pythonだとpep8があったり、
社内ルールでコーディング規約があったりするので、
それを確認して順守すると良いかなぁと思います~

パブリックなコーディング規約だったりすると
自動で体裁を整えてくれるツール(例:pythonだとautopep8)
とかもありますので、探してみるといいかも。らくちんですし…

そんなわけで整えたのがこちら

修正3

 

最初と比べるとだいぶ見違えたかなと思います~

余談ですが、体裁を整えるのはコーディングよりも、
GUIのプログラミングの方が比重が大きいかなと考えています~

UE4のBluePrintのように、パーツを組み合わせて
ロジックを組み立てるプログラミングを使っている人などは
特に意識したほうが良いんじゃないでしょうか?



修正4:TODOにした機能を追加してみる

 

これは一通り終わった後の話ですが、
折角TODOが出てきたので直してみました。

修正4

 

作った後で思ったのですが、これは悪い例だと思います。

何故なら、最初のTODO以外の対応も入っているからです~

 

なんでこうなったかというと、

とりあえず数字を変えられるようにしたいなと思いまして、
数字用の配列を用意しました。

その後、「ん?どうせなら紐づけられるといいんじゃない?」
と思い、辞書型に変更し、
辞書型に「fizz,buzz,fizzbuzzって入れたところあとで変えたいなぁ」
と思ったところ、wordの配列の値を辞書型に入れるようにしました。

その後、冒頭で変えられるように…


とかなんとかやっていくうちに先ほどの形になっちゃいました…

直していくとどんどんいろんなところに目が行くので、
色々修正したくなっちゃいますが、
直す場合は一つの機能に絞りましょう~
それが終わったら別の機能に取り掛かりましょう~
 

そして分かりやすさに関してですが、
汎用性が上がった分、分かりにくさは上がったかなと思います~
「"fizz"が3の時」より「単語Aが数値Bの時」の方が
抽象的で分かりにくいですよね?

この辺はトレードオフな部分になるのかなと思いますので、
作る時に何を重視するのかを頭の片隅に置いていくと
良いのかもしれません~

さて、まだまだいろいろ出てきそうですが、終わりがなさそうなので、
一旦これで区切りたいと思います♪

汚いコードからきれい?なコードにしていくのをやってみて
改めてきれいなコードを心がけるのは、
後々の見やすさや修正のしやすさを考えると
大事だなというか基礎中の基礎みたいな感じなんだろうなというのが
cacaponの感想です~

疲れてきたり、修正に重なる修正があると
汚いコードになりがちですが、意識してきれいなコードを
保てるようにしたいなぁと思う、今日この頃のcacaponなのでした~