Swiftで行列を鑑みた多次元配列を宣言、生成する

プログラムに配列は欠かせず、 iPhoneアプリのゲーム開発に於いても其れは変わらず、 併せてゲーム内のデータ保持に行列を用いたいとなれば必須事項ですが、 型に厳格な言語 Swift 上の話でもあれば、 実行しようと思うもなかなかに難儀で、 エラーを頻発させるも諦める訳にも行かず、 何とか形になった経緯を本記事に記しおくものです。

アプリあちこち食堂(仮題)に於ける多次元配列を可視化した開発画面
アプリあちこち食堂(仮題)に於ける多次元配列を可視化した開発画面

求める2次元配列の形

自らの策定した仕様の要請に依れば手始めに 以下の如き2次元の行列を鑑みた Bool型の2次元配列を生成したくあります。

10000000000001
10000000000001
10000000000001
10000000000001
10000000000001
10000000000001
10000000000001
10000000000001
10000000000001
10000000000001
11111111111111

処が先ず以て、 Xcode は此の宣言さえ許してくれません。 下手に宣言すればビルドは通るものの、 走らせると配列forループでお馴染みのエラー Fatal error: Index out of range が吐き出されて止まってしまいます。

どうもネットを繰るとteratailに以下の様な遣り取りが見付かり…

"Swiftで行列を鑑みた多次元配列を宣言、生成する" の続きを読む

NTTドコモのdポイントとdカード

現在でも総務省から突き上げられている様に 顧客への還元のない姿勢から少し前は随分と酷評していたドコモのサービスですが、 故意に分かり難く設定されたとも思える各プランは其の儘なるも、 どうも金融・決済サービスの一環として、 dポイント と結び付けられた dカード の登場と共に風向きが変わって来た様に感じられます。

ドコモ社のiTunesギフトカード割引販売お知らせメールに添付された画像
ドコモ社のiTunesギフトカード割引販売お知らせメールに添付された画像

先日は連休中、2018年5月2日にNTTドコモ社から届いたお知らせのメールの App Store & iTunesギフトカード初回限定10%OFF!さらに2%dポイントプレゼント はiTunesストアに補充の必要を感じていた折も折、 なかなかお得な内容に感じられれば、 渡りに船よと、 受け取ったメールの内容をiPhoneで確認した其の場、寝そべった其の姿勢で iTunesギフトカード10000円分を購入、 其の儘App Storeに登録して思ったのは、 思い付いた儘、寝た儘、此の様に買い物が出来るのでは 小売が厳しいと言われるのも無理はない、と言う世評が肯んぜられるものでした。

dカードの前身とも考えられる iDカード は明確に失敗だと断じて宜しいかと考えます。 何となればドコモが懸命に売り込んだに関わらず遂には普及には至らなかったからで、 具体的な例としては此の春にリニューアルされたドコモの契約者をランク付ける dポイントクラブステージ の最上位決定の条件からはiDカード契約が外されています。 iDカードは キャッシュを燃やす様な経営との批判を下方修正を余儀なくされた株主総会で受けた 際、 インターネット通販で失敗 し、 コンテンツ・メディア事業でも失敗 し、共に失敗した当時、ドコモが本業以外の事業多角化の一つとした 金融・決済 事業の中核を担うサービスでしたが矢張りドコモの思惑通りには運ばなかった訳です。 本ブログにも遡ること7年、2011年の12月24日の記事にドコモの金融、決済サービスを酷評しています。

"NTTドコモのdポイントとdカード" の続きを読む

スマホ画面でのみタブで表組みの縦列を切り替えるJavaScript

現在一般的なレスポンシブWebデザインでは、 基本的にパソコン画面と同様のHTMLソースをスマホ画面でも表示させます。 其の際、スタイルシートを駆使しますが、 一般的に縦長画面で閲覧されるスマホ画面では工夫が必要になります。

パソコン画面で横に広く表示させていたコンテンツも スマホ画面では縦長にならざるを得ないため、 例えば横に並列して並べていたコンテンツを故意にカラム落ちさせ、 縦表示させるテクニックはごくごく基本的な手法です。

処がコンテンツによっては其の基本的な手法が適切でない場合もあります。 其の様なケースではスマホ画面の場合にはタブ切り替えは屡々採用されるテクニックです。 ネットで検索しても有用な情報が多く見付けられます。 例えばQiitaにも2017年8月6日付けで以下の情報が寄せられています。

jQueryとCSSでシンプルなタブ切り替え

記載されるコードは散見される同様な情報が上手くまとめられたように、 簡便さに加え汎用性も考慮され書かれています。 基本的には切り替えボタン用のタブを構成するタグと、切り替えられるコンテンツを表示させるタグが同数用意され、 初期に表示される以外のコンテンツを含むタグには非表示属性、 display: none; がスタイルシートで付与されており、 クリックされたタブと同じ、先頭から数えた数のコンテンツタグ以外に非表示属性が与えられるように jQuery で処理される、当該機能の定番的な構成が取られています。

レスポンシブWebデザインで扱い難い表組み(tableタグ)データ
レスポンシブWebデザインで扱い難い表組み(tableタグ)データ

処でレスポンシブWebデザインで扱い難いデータに表組み(tableタグ)があります。 一般的にパソコンの広い画面では一覧性に富み、 表組みも全体を表示させられる余裕がありますが…

"スマホ画面でのみタブで表組みの縦列を切り替えるJavaScript" の続きを読む

Xcode開発に於けるfloat型やdouble型の値の余剰

ゲームの代表的存在でもある任天堂社のスーパーマリオブラザーズを始めとして、 特にレトロな2D横スクロールアクションゲームでは無限スクロールは必須の機能です。 本ブログにも横スクロールの実装について記事を幾つか配信しもしました。

ゲームうさ犬が行く開発中画面
ゲームうさ犬が行く開発中画面

XcodeでiPhoneアプリでも2Dゲームを開発するに当たって 有用なのがアップル社謹製フレームワーク SpriteKit です。 このフレームワークには様々なゲーム実装に関する機能が搭載されていますが、 座標もその一つです。 SpriteKitの座標に関してはUIViewと座標系が異なるため、 困惑する場合も多いのですが2D画面を構成するには欠かせません。

手元の開発iPhoneゲームで いつものようにSpriteKitの提供する座標系 SKView を用いている途中、気付いた点がありました。

"Xcode開発に於けるfloat型やdouble型の値の余剰" の続きを読む

WordPressのアイキャッチ画像は英語でfeatured image

以前に良く見掛けた、 タイトルで言い切った 、的なエントリーです。 知ってる向きには何を今更、と言った処にて、 以下読む必要はありません。

featured image アイキャッチ画像

上にリンクを貼り置いた Standing on the Shoulder of Linus ブログの2010年4月8日の記事では、 WordPressのバージョン2.9に於いて 投稿サムネイル機能 が追加され、バージョンが3.0に上がると其れは Featured Image と命名されたそうで、其の和訳こそ今WordPressユーザーに一般に流通する アイキャッチ画像 なのでしたが、日本語の決まっていないベータ版で訳が割り振られたそうなのです。

浜松市鴨江寺仁王門阿吽像
浜松市鴨江寺仁王門阿吽像

恥ずかしながら此の事実に気付かされたのは…

"WordPressのアイキャッチ画像は英語でfeatured image" の続きを読む

CSSのみでフォントは不透過でその背景色のみを乗算でそのまた背景の画像に重ねる

仕上がりイメージは斯うです。

先ずは最下層に背景画像があります。 上の例では神社の写真が其れに当たります。 其の上に帯がのり、其の上、左方に白のアイコン、右方に白のフォント文字が乗ります。 アイコンとフォント文字を包含した帯は元は紺色ですが、 乗算で其のまた背景画像に重ねられており、 唯に単色の不透過色の場合とは異なる深みを感じさせるイメージを醸し出しています。 此れを皆、CSSのみで実現したく試行錯誤しました。

参考のために唯に単色の不透過の紺色の帯の場合を下に貼り置きましょう。 随分イメージが異なるのがはっきりします。

"CSSのみでフォントは不透過でその背景色のみを乗算でそのまた背景の画像に重ねる" の続きを読む

EdgeでFlexboxの高さ指定の単位にパーセントが使えない問題

Webデザインとレスポンシブの現況

CSS3 から追加されたプロパティ Flexbox は其のレイアウトの柔軟さ故に現在主流の レスポンシブ (Webデザイン)と相性が良く、 行列のグリッド配置を扱わねばならない場合、 Floatプロパティに代わり頻繁に用いられるようになりました。 端末幅に応じて横5つ並びのアイテムが 4つ、3つと減じても見た目に違和感は抱かれない塩梅となっています。

処でレスポンシブに於いてはプロパティの値の単位に 百分率も頻繁に用いられる処です。 従来PCでの閲覧に限られて考えられていたデザインに於いては サイズは固定で主に単位としてピクセルが用いられていましたが、 閲覧者の環境に応じて多くのサイズが考えられるデバイスの 横幅にピタリと合わせる為には其れでは間に合わず パーセンテージの採用されるに至りました。

また主流の座からは滑り落ちたものの Microsoft社製のブラウザもまだまだ残念ながら健在です。 世の中のデファクトスタンダードにも総意とも言える標準にも従わぬ、 Windows独占時代の残滓の如き路線たるオレオレ詐欺ならぬオレオレ仕様から 忌み嫌われたブラウザはインターネットエクスプローラ(IE)から今では Edge(エッジ)へと装いを改められていますが、其の中身はどうでしょうか。

今回、Edgeに特有に発生するFlexboxプロパティで パーセンテージを単位に使った場合に問題が発生するのを端無くも発見しましたので 本記事に共有するものです。

"EdgeでFlexboxの高さ指定の単位にパーセントが使えない問題" の続きを読む

Google Bloggerが漸く独自ドメインでHTTPS化

恐らくは世の中で最も遅いセキュアサーバー化ではないでしょうか。 Google社が提供するブログサービス Blogger (ブロガー)の独自ドメイン(カスタムドメイン)に於いてです。

セキュアサーバー化とはホームページデータを保存しているサーバーをSSL化することで 表示のリクエストを送ったユーザーのブラウザとの間で其の通信が暗号化されるようにすることを言います。 セキュアサーバー化されたホームページにアクセスすると アドレスバーのドメインの前のお馴染みの HTTP の表示がHTTPSと変化します。 此の S はセキュアのSを表しています。 こうすることで通信の途中経路で通信内容を傍受されても内容が漏れ難くなりますから 早くからパスワード入力やメールフォーム、ネットショップのカートでは必須のものとされ、 現在では其れがWebサイト全体に敷衍されるに至ったのでした。

古くはコンピュータの処理能力も低く 通信毎に暗号化と複合化をホスト、ブラウザ共に繰り返すのは好まれない面もありましたが、 現在ではコンピュータの能力は数桁単位で向上しています。 また暗号化と言うからには信頼できるものが必要で 其のための第三者機関からのSSL証明書発行には多額の経済的負担もあり Webマスター連から厭われる理由でもありましたが現在では其の負担も低減しています。 従って現在ではセキュアサーバー化は推奨されこそすれ決して拒まれる理由はない訳です。

およそ検索エンジン最大手たるGoogle社が推し進めており 検索結果の順位上もHTTPS化は優遇されるとの情報もあって 多くのWebマスターは挙って自ら運営するWebサイトのセキュアサーバー化を推し進めました。 しかし当のGoogle社が提供するBloggerサービスでは今の今迄 遂にHTTPS化は提供されるには至りませんでした。

"Google Bloggerが漸く独自ドメインでHTTPS化" の続きを読む

Spritekitを利用したゲームAIの実装改

ディープラーンングなどは及びもつかないものの、 iPhoneアプリにゲームとしてユーザーをもてなす以上、 規模は小さいながらもユーザーの入力に対する反応を返すアルゴリズムを用意すべし、 とて此れを ゲームAI として手元の開発ゲーム バルーンズ・オキュパイ への実装の取っ掛かりを記した記事が2017年10月6日に本ブログに配信した以下の記事でした。

Spritekitを利用したゲームAIもどきの実装

本記事には此の前記事に紹介したコードを今一歩進めた考察を記す処です。 其の要件としては前記事に於いては キャラクターの出現ポイント検出の処理と移動の処理を任意単位時間、2秒に1回 としており、 此れを同時に処理していたのでユーザーの待ち時間が多くてゲームとして成り立たないので 此れを解決したい、と言うものです。 従って任意単位時間の取り扱いについて考える必要があります。 本ブログには此れに関して2017年10月24日に以下の記事を配信しています。

"Spritekitを利用したゲームAIの実装改" の続きを読む

iPadで表示の崩れる原因となるviewport出力を他端末と切り分ける

アップル社からiPadがローンチされて以来すっかりタブレットは市民権を得た感があります。 従って今でもiPadはタブレットの代表として世の中に認知される所となっていると言って過言ではないでしょう。 PCよりお手軽に起動出来、ソファに腰掛けて利用可能ながら、 スマートフォンより表示領域が大きいタブレットは、 電子書籍閲覧や、動画サイト閲覧などに威力を発揮しますが、 矢張りWebサイト閲覧は其れ等の中でも最も利用頻度の高いものでしょう。 iPadでは標準装備のWebブラウザ Safari が大いに用いられる処です。

2010年にアップル社から発売された初代iPad

さて現在Webサイト実装の主流として台頭して来ている手法が レスポンシブWebデザイン です。 昔風に言えばリキッドデザインと言えば通りが良いかも知れません。 リキッドデザインが現代風に進化して一つのHTMLファイルで 様々な表示領域の端末に対応可能としたのがレスポンシブWebデザインで、 一般に「レスポンシブ」と言えば其れを指す程普及した様に思います。

処で此のレスポンシブWebデザインをタブレットの代表格たるiPadで表示すると多くの場合、 表示崩れなど問題が生じる様です。 共に現在の主流たる手法と端末が相性が悪いのは由々しき事態です。 願わくばW3Cなど規格制定組織やアップル社など大企業の対応が進み 何の考えもなく問題なく表示されるのが最も宜しい解決法でしょうが、 現時点ではどうも其の様な方向に進んではいないらしいので、 どうしてもWebサイト制作側で其々対応が必要となります。 折角の表示領域の広いiPadであれば是非情報の一覧性の優れたPC版の表示を求めたく、 本記事ではiPadでレスポンシブWebデザインの表示崩れを防ぎPC版の表示を目論見ます。

"iPadで表示の崩れる原因となるviewport出力を他端末と切り分ける" の続きを読む