忍者ブログ

RPG製作ソフト「Role Paint」を作っていくぜ!ツクールのようなRPG製作ソフト「Role Paint」を作っていくブログ。 相互リンク募集中

プログラミング言語の自作か、それともRubyによるDSLか

ビジュアルプログラミングの仕組みがある程度完成した(構想も含めて長かった・・・)ので実際に動く言語の中身の実装をやり始めた。その中で軽い問題が発生

「速さを求めてプログラミング言語を自作するか?それとも遅くてもいいから開発の高速化とか拡張性を求めてDSLにするか?」である。

まず、プログラミング言語の自作。これはツクールのスクリプトのような簡易的な作り方ではなく、関数も実装できる一般的なプログラミング言語の自作である。この方法は問題点がいくつかある。

一つ目はプログラミング言語の自作に時間がかなりかかる事。まぁ、別にこれは大した問題ではない。どうしてもやりたければ時間をかけてやるだけである(その分、待っているユーザーに迷惑がかかるが・・・・)

二つ目はMRubyとの連携が取りづらい事。2つの言語間を連携する形になるため、かなりやりづらい。

三つ目はユーザーの手による拡張が殆ど不可能に成る事。要するに「こういう文法やイベントコマンドを入れたい」という事がかなり難しくなる。一番痛いのはこれである。

そこでもう一つの方法も視野にいれる事にした。DSL(Domain Specific Language)である。難しい名前だが要は「ツクールのイベントコマンドやSQLのような、その環境専用の言語を作る」という意味で、Rubyのような高機能なスクリプト言語はこの作成を得意とする。Role Paintの場合はScratchのようにC言語並に汎用性の高い物になるだろう。また、スクリプト上で作るのでユーザーによる拡張が簡単に出来るようになる。

問題点としては動きが遅い事。本来CやC++で済ませば良い物をRubyで動かすのだから当然である。

どちらにすべきかは2~3日ぐらい考えてやるとする。開発の期限で6月にかなり迫ってしまっているが、まぁ仕方がない。

拍手[2回]

PR

イベントコマンドをどこまで複雑化すべきか?

延々とビジュアルプログラミングの動きを進めているが、ここで重大な問題が発生している。

それはどこまでビジュアルプログラミングを複雑化すべきか?というもの。
作っていくとイベントコマンドの仕様が普通のプログラミング言語並みに複雑化していっているのである。それをどうするべきか?

・変数

これは別にツクールやウディタでも使われている概念だから問題はないだろう

・配列、For文

プログラミングには欠かせない物だが、ツクールやウディタには搭載されていない。配列とは「変数をエクセル表のように一繋ぎにした物」なので分かりやすいと思うが、For文は結構ややこしい。「1つの変数を操作しながらループする機能」といえば分かるのだろうか?

For文を理解できない人は普通の繰り返しを使えばいいとも言えるが・・・。

・関数の引数と返り値

関数に変数を渡し、結果を返してもらうという事だが、これは初心者に理解できるのだろうか?
引数無し、返り値なしの関数はツクールではコモンイベントという形で実装されている。またウディタでは引数に近い概念は実装されているが・・・。

・構造体

一番の問題はここから。C言語を使える人なら常識だが、構造体というのは、平たく言えば変数の型を幾つか組み合わせて新しい型にした物である。

まず名前を表す変数を電話番号を表す変数、住所を表す変数があったとする。これら三つを一纏めにして個人情報という変数という扱いにする。これが構造体である。

大抵のゲームのキャラのデータはこの構造体によって表される。例えば敵キャラのデータはHP、MP、攻撃力等のパラメータ(変数)を一纏めにした構造体である。

初心者はこれを理解できるのだろうか?例えばツクールでイベントコマンドで主人公のHPを回復させる場合、専用のイベントコマンドを呼んで

HPの増減:[主人公,] +30

とやるが、これは下記のように書き直せる

主人公の中にある変数、HP←主人公の中にある変数、HP+20

通常のプログラミングだとこうなる

主人公.HP=主人公.HP+20

後者二つのほうがわざわざ関数を作る必要もなく、非常に楽なのだが、これは初心者にとって壁となりうるか否か?

・関数ポインタ

これもC言語を扱っている人には常識的だと思うが、関数そのものを変数として扱うという物。
つまり、ツクールのイベントコマンドでいえばコモンイベントを変数として扱うのだ

・・・おそらくツクールやウディタのイベントコマンドしかやってない人はどういうことだ?と思われても仕方がないだろう。が、私の文章力ではこれ以上の説明のしようがない。

・構造体と関数ポインタが理解できたら?

もし関数ポインタと構造体を初心者が理解できると分かった場合、個人的には大分楽になる。

この二つの概念を理解できればオブジェクト指向なんてすぐに理解可能である。早い話、オブジェクト指向とは「後で一定の範囲内ならば改造可能な構造体」であり、「その構造体には関数ポインタが基本的に使用される」ような物である。この二つを理解できればオブジェクト指向はすぐであろう。

拍手[1回]

一万円のパソコンは作れるか

昨日の記事で思い出したが、一万円のノートPCを考えていた事がある。

最近、「日本のPC教育は遅れている」というニュースが何度か流れた。これをどうにかするには、と考えたわけだ。「国がノートPCやタブレットPCを全国に配れば済む」なんて単純に考える人もいるだろうが、お金で解決できたら苦労などしない。もしそういう人がいたら「その分の税金をお前は払ってくれるのか?」と聞きたい物だ。おそらく大多数の人が払おうとしないだろう。

ではどうするのか、というとやはりパソコンを格安で簡単に買えるようにする事に限るだろう。そして、その手の技術はだいぶ固まっている。

値段的には、おそらく一万円ぐらいが目安になるだろうか。
(一万円も払えない家庭があると言われた場合・・・正直、その家庭はパソコンを買う云々以前の問題があると私は思う。)

実際に似たような事をしたNPOのプロジェクトがある。ご存じの方も多いかもしれないがOLPCという物だ。が、1万円の値段に抑えるつもりがが2万円になってしまい、その後もプロジェクトが続いているようだが少なくとも日本国内ではあまり話を聞かない。おそらく上手く行ってないのだろう。

wikipediaのOLPCの記事


「NPOで無理なら、どんな組織がやっても不可能だろ」と思われるかもしれないが、このプロジェクト、wikipediaを見るに明らかに安く作る気があるのか疑わしい点が多く、もっと上手くやれる可能性はかなり高い。

・手回し充電器の搭載
(アフリカの奥地の村でも太陽光パネル等を使って電気を作れる時代である。流石に電気そのものがない国は紛争地帯か食料にすら困っていてPC教育どころではない国では?)
・消費電力(確かに電力が不足しがちな発展途上国に配りたいのは分かるが、それに拘って値段が上がったらどうする?)
・かっこいいデザインを追求(論外)

実際に任天堂は超高性能タブレットPCとも言えるニンテンドースイッチをたった3万円で売っている。この値段はユーザーが5千円以上するゲームを2,3本以上買ってもらう前提での値段なので一概には言えないが、性能を削れるだけ削れば1万円PCは可能となるはずである。

・個人で可能か?

さて、気になるのは個人で可能かどうかである。ゲーム機は不可能だったが、教育用格安パソコンではどうなる?

結論から言えば「条件付きで不可能でもないが、現実的にはやる価値はない」である。

まず、CPUやメモリと行ったコンピュータ本体。ラズベリーパイ辺りを使う事になるだろうが、これは5千円ぐらい。

OSはLinuxかAndroidを使えばいいだろう。これは無料である。オフィスソフトも今ならLibre Officeを使えばいい。これは無料で使えるオフィスソフトである。ラズベリーパイ上でも動くし、教育には十二分すぎる動きを果たしてくれるだろう。ウェブブラウザも無料で手に入れられるが、そもそもネットは子供の教育に悪いので入れる必要もないだろう。

キーボードはノートPCのような持ち運べる物でも千円から2千円ぐらいのがあるのでそれを繋いで動くようにすればいいだろう。他の部品は前のゲーム機の記事で見たようにそこまでお金がかからなくて済む。バッテリーも持ち運ばないのなら要らないので、もっと安く済む。

ここまでは順調だが、最大の問題が起きる。液晶がやたら高いのだ。何年前の物か分からないぐらい古いジャンク品の液晶でもない限り、普通に数万円してしまう。個人の電子工作用ですら、高い物は一万円ぐらいする。千円から2千円ぐらいの安いのもあるが携帯電話並みに小さくなってしまう。

が、この問題、一応避ける方法がある。テレビの液晶を繋いで使えるようにすればいいのだ。いくらテレビ離れが激しい昨今とは言え、テレビがない家庭はそうそうないだろう。HDMIのコストの問題があるものの、こうして液晶の問題も解決できる。

しかし、最近のテレビは極一部の小さい奴を除いてPCとして使うには大きすぎるので不便でしょうがないだろう。それとテレビのモニターをPC代わりにするのなら、スティックPCを使ったほうが明らかに早い。スティックPCはキーボードも液晶もないがその代わりに安い物で大体一万円ぐらいの値段である

とりあえず、個人でも教育用の格安パソコンを作って売ることは不可能でもないが、スティックPCの方が遥かに良くて現実的ではないというわけだ。

ただ、販売費などを計算に入れていないものの、理論上は個人でここまで出来るのであれば小さな会社でも出来る可能性は相当高いと見て良さそうである。何処かの会社がやって欲しいところだ。

ちなみにPi-topという実際にラズベリーパイを使ったノートPCがある。が、これは3万円ぐらいである。一体何処にコストがかかっているのは不明。

追記:

コメント欄でKanoという格安ノートPCが紹介された。ラズベリーパイを使ったPCで液晶がない物で約1万5千円、あるもので約3万円である。

https://kano.me/


私が考えた理想通りの教育用PCだが、やはり液晶がネックになるようである。

モノクロ液晶なら、値段は安く出来るのだろうか。ネットで調べた分では情報が出てこなかった。モノクロ液晶を作っている会社に直接聞かないと駄目なようである。

さらに追記:

今、改めて調べてみたら7インチ程度なら2千円ほどの格安で済むようである。

http://akizukidenshi.com/catalog/c/cglcd/


ニンテンドースイッチを持っている方なら共感してもらえると思うが、スイッチの液晶の大きさは6.2インチであり、ノートPCとしてギリギリ成り立つぐらいの大きさである。
(本当は7インチのAmazon Kindle Fireの方が例として正しいのだろうが、私はそれを持ってない)

つまり、個人で一万円の教育用格安PCは作れる。

実際に売って商売にするとなる販売費やら流通にかかるコストやらで話はまた別になってくるが・・・・

拍手[1回]

携帯ゲーム機のアイディア

最近、馬鹿な事を考えている。それは携帯ゲーム機のアイディア。

もし5千円から6千円ぐらいのインディーズゲーム専用のゲーム機があれば売れるのでは?と考えている。そして、それがあればインディーズゲームはもっと発展するのでは?と考えているわけだ。実際任天堂が6千円ぐらいのミニファミコンを売ってかなりの売上を記録したのでいける可能性はあるだろう。多分。

・必要な要素

5千円となると、かなり機能が絞られるが必要最低限必要なのはこの4つだろう。

・ボタン
・CPUやGPU(ツクールACE製ゲームがギリギリ動くぐらい)
・タッチパネル式液晶
・ローカル通信用のLAN

何故タッチパネルなのかといえば、そうすればスマホのゲームを比較的移植しやすいし、何より最近の子供はタッチパネルがついたゲーム機しか触れてないので、もしそうでなかったら違和感を覚えるだろう。

・ゲームの自動販売機

問題はソフトを販売する方法だが、あるアイディアがある。昔からソフトベンダーTAKERU等であったアイディアだが、ゲームの自動販売機である。

DLゲームの購入が面倒臭いと考えた事はないだろうか?基本的にプリペイドカードやクレジットカードが必要で面倒臭い。かといってお店でソフトを購入する形だと、そもそもソフトをお店においてもらえるか分からない。

それが自動販売機ならお店で置くより遥かにやりやすくなるし、何よりジュースの自動販売機が示しているようにゲーム機をNFCやUSBで繋いでお金をちょっと入れるだけで簡単に買えるようになる。電子書籍などにもこのアイディアは使えるだろう。

・個人で作って売れるのか

あまりにも気になりすぎて、個人で作って同人誌みたいに商売になるのか調べた。

結論から言えば「作れはするがコストの問題で売れない」である。

携帯ゲーム機とスマホのアーキテクチャが似ている。なので個人で作ったスマホのコストから携帯ゲーム機にかかる大まかなコストを計算できる。

そして、かのラズベリーパイを用いて個人でスマホを作った人がいる。が、その人のブログによれば

ラズベリーパイ・・・40$
タッチスクリーン液晶・・・35$
バッテリー・・・15$
携帯電話用アンテナ・・・48$
コンセントに使う部品・・・10$
ボタンなどその他諸々・・・10$

合計・・・158$

(ソース:http://www.davidhunt.ie/piphone-a-raspberry-pi-based-smartphone/


・・・明らかに原価だけで3DSの値段を超えてしまっている。おまけにこれは基盤むき出しのため、外枠の値段を入れてない。(3Dプリンタを使えば安く作れるかもしれないが)さらに人件費やら何やらを足すともっとかかる。ついでに言うと日本には電波を扱う製品の法律もあるので、それも高い壁になる。

おそらく、売れるほど安くするには最低でも中国や台湾に行ってファブレスメーカーから注文を受けている会社とやり取りする必要がある(実際そうやって家電を作っている中小企業は世間のイメージより遥かに多い)が、そこまで行ったら個人ではなく企業である。

よって個人がゲーム機を作るのは現実的に不可能である。残念無念

拍手[3回]

二転三転。クラスの視覚化で初心者でもオブジェクト指向を使いこなせるようになるか?

二転三転。昨日、「イベントコマンドでメニューや戦闘といった根幹の部分を作る事は不可能
と書いたが、どうにかなりそうなアイディアを思いついた。(この場合は「思いついてしまった」というべきなのだろうか・・・・悪い意味で)

その方法はクラスの視覚化と子クラスから親クラスを作成する方法を作る事。

・オブジェクト指向の分かり辛さ

オブジェクト指向最大の問題はプログラムに触れた事のない人にとって、全く理解不能であるという事である。例えばプログラムのうち、関数の説明は分かりやすい。

「関数とはプログラムのコード(イベントコマンド)を一纏めにした物です。例えば「xという変数に好きな数字を足す」というプログラム(イベントコマンド)と「xが2の時のみ絵を表示する」というプログラム(イベントコマンド)があります。これら二つを組み合わせて「xに好きな数字を足し、その結果が2の時のみ絵を表示する」という命令を作ることが出来ます。このオリジナルのプログラム(イベントコマンド)が関数です。」

失礼かもしれないが、これを理解できない人はそこまでいないだろう。実際にツクールでもコモンイベントという形で関数の仕組みは搭載されている。理由はプログラムとプログラムを組み合わせて新しいプログラムを作るという考えは直感的で理解しやすいからだ。ここまでは問題にならない。

が、オブジェクト指向の説明は関数と比べ物にならない程一気に意味不明になる。

「オブジェクト指向とはプログラムの処理を物として捉える手法です。」

よく使われている説明だが、初心者やプログラムの素養がない人には意味不明そのものだろう。
そもそも命令を物として捉えるというのは人間から見て非直感的である。「歩くという行為を物として見ろ」と言っているような物だ。

・オブジェクトの視覚化

だが、この説明ならどうなるだろうか?

「これはアイテムの設定画面というオブジェクトです。」



「このアイテムの設定画面を改造して武器の設定画面にする事を継承と言います。」


これで相当分かりやすくなったはずである。(なっていないかもしれないが・・・。)

このようにオブジェクト指向の視覚化を繰り返していけば、初心者でもオブジェクト指向を必要最低限に使いこなせると考えられる。

問題はどこまで視覚化可能というか、という事。例えば「バトルの戦闘の順番を視覚化する」となると、かなり難しいだろう。

・子クラスから親クラスを作る機能

また、初心者に対する強力な補助として幾つかの子クラスから親クラスを作るという手法も考えられる。

オブジェクト指向の基本となるクラスの継承という概念を説明するとこうなる。

「クラスの継承とは元となるクラスから新しいクラスを作る事です。例えば戦闘参加キャラというクラスを元にして味方キャラと敵キャラというクラスを作ります。これが継承です。」

あえて、やや分かりづらい例えをしたが、この説明を理解できるかどうかがプログラマの素養がある人と出来ない人の違いとなるだろう。
要するに「元となる概念から派生物を作る」という考え方が結構非直感的なのだ。「車という概念の派生にトラックやF1カーがある」なら良いが、そうではない非直感的な派生はかなり多い。

さらにプログラムに触れていない人なら「敵キャラと味方キャラに共通事項があり、その共通事項となる物に新しい名前をつける」という発想が中々思いつかない、説明されても分からない可能性が高い。

これの支援を行うため、幾つかの子クラスから共通事項を抽出して親クラスを作る仕組みを作る。親クラスから子クラスを作ったほうが遥かに手っ取り早いが、初心者から見てみれば質の良い物を作る助けになるはずだ。

・時間がない

ただ、正直、これをやろうと思ったら、もう時間がない。

こんな事をいうのもあれだが、正直、早く作り終えてRole Paintの開発から解放されたい。さらにこれを実装しようとしたら、本当にいつまで経っても完成しないという事になりかねない。

また、これ以上完成度を高めようとしても、おそらくあまり意味がない。すでにユーザーが求めているであろう必要最低限のアイディアの詰め込みとそのアイディアが実現可能かどうかの実験は終えたと考えている。さらに初心者でも上級者でも簡単かつ高速に作れる仕組み作りを延々と考えたせいで一ヶ月以上時間を無駄にしてしまった。

なので、このアイディアの実現は一旦諦めようと考えている。

・Visual Basic化の懸念

仮にだが、このシステムを作った場合、懸念すべきことがある。それは「初心者にとって、あまりに簡単に作れすぎて分かりづらいコードが大量発生するのでないか?」という物。この問題が噴出しているのがVisual Basicである。あまりに初心者にとって簡単すぎるせいで読みづらい、改造しづらい、バグが有っても取りづらいコードが多発、却って多くのプログラマが苦労する事になってしまった。これと同じことが起きかねない。

かといって初心者に読みやすく改造しやすいコードを書け、を強制しようとすると初心者にとって意味不明なコードになって敬遠されるのだが・・・。どうしたものか

2017/5/10追記

どうやら、このアイディアはダメそうである

拍手[0回]