第8回 筋道を立てよう − フローチャート − 「6.プログラム化しよう」

8−6 プログラム化しよう

フローチャートができあがっていれば、あとの作業は比較的楽です。
なぜなら、フローチャートなどを作る時に使う「日本語」に比べて、BASICコマンドは種類が限られているからです。
それに、類義語はあまりありませんので、もう、各処理に合わせて当てはめるだけです。(ちょっと無責任か?)
では、項目別に見ていきましょう。

[変数の宣言]
これは、もうそのままですね。必要な変数は6つ、表示用にX1とY1を、消去用にX2とY2を、そして、移動量用にDXとDYにしましょう。
そうすると、次のようになります。
      Global X1 as Integer
      Global Y1 as Integer
      Global X2 as Integer
      Global Y2 as Integer
      Global DX as Integer
      Global DY as Integer
[表示座標を乱数で作成]
表示用の座標は、通常のPalmデバイスなら、160x160ピクセルですが、単純に0〜159の乱数にすると、ボールの大きさ(6x6)が考慮されませんし、もしかしたら、いきなり壁の真横に表示される可能性があります。したがって、そう言う場合は、安全圏に初期値を設定するのが無難です。
      X1=Rand()*100+30
      Y1=Rand()*100+30
こうすれば、30〜130の値になるので、無難な初期値になるのではないでしょうか?

[消去用に表示座標を代入]
特に説明不要でしょうか。
      X2=X1
      Y2=Y1
[ボール移動量を乱数で作成]
ボールの移動量はボールの大きさである、6ピクセルとすると、それぞれの初期値が、+6 か -6 であればOKです。
+1と−1のどちらかを乱数で出すには、
      0 ≦ Rand() < 1
      0 ≦ Rand()*2 < 2
となりますので、これを整数化すれば、
      Int(Rand()*2) = 0 or 1
となります、そして、これを2倍して1を引けば、
      2*Int(Rand()*2) = 0 or 2
      2*Int(Rand()*2)-1 = -1 or 1
となり、-1か +1が得られる乱数になります。そして、これを移動量に合わせて6倍すればよいですね。
      DX= 6*(2*Int(Rand()*2)-1)
      DY= 6*(2*Int(Rand()*2)-1)
こんな難しいことしなくても、初期値は絶対に「右下移動」とか、ちょっとした乱数で、
      If Rand()>.5 Then
          Dx=6
      Else
          Dx=-6
      End if
でも良いかも知れません。

[ボールの消去][ボールの表示][座標の保存]
これは、そのままですね。
1つ前の位置にボールを消去する「空白画像」(1006)を表示して、新しい位置にボール画像(1005)を表示すればよいです。
座標の保存は、代入するだけです。
      DrawBitmap 1006,X2,Y2
      DrawBitmap 1005,X1,Y1
      X2=X1
      Y2=Y1
[縦:移動量を加える][縦:壁に衝突][縦:座標を戻す][縦:方向を変える]
縦方向に移動量を加えますので、
      Y1=Y1+DY
そして、この座標が壁を超えたかどうか判定しますので、
      If Y1<0 or Y1>153 Then
と言う条件になります。上の方は 0で良いのですが、下を座標の最大値159にすると、ボールの大きさがあるため、はみ出してしまいます。したがってボールの大きさ分を引いた 153になっています。 この条件が満たされた場合は、
          Y1=Y2
として、保存した座標を戻してあげればよいですね。 そして、方向を反転しますから、
          DY=-DY
として、符号を反転させますが、まれに、このような表記を許可しないBASICがありますので、その場合は、
          DY=-1*DY
とでもすればよいでしょう。

[横]
横方向の処理は、縦方向の場合と同様ですので特に掲載はしませんが、よろしいですよね?

[繰り返し]
そして、繰り返しの処理です。
繰り返しは、[ボールの消去]〜[横方向の処理]の間ですので、この区間を Do〜Loopでくくれば良いですが、なにかイベントが起きたら終了しますので、条件を入れておきます。
      Do until SysEventAvailable()=1


      Loop

どうでしょうか?
ある程度細かなフローができていれば、BASICに「翻訳」する作業はそれほど難しくないような印象を受けませんか?
どちらの作業も知っていなければならないことが多くありますが、印象的にはフローを作るほうが難しく感じたのではないでしょうか? 今回のサンプルでもそうですが、漠然とした動作や画面のイメージから1つの道筋を作るのは、なかなか難しいものです。
このフローを作る作業では、作る対象となる事柄や完成イメージ、途中の動作など、全体をイメージできていて、かつ、プログラム的に楽になるフローを考えなければなりません。

ただ、こういう難易度をそのまま解釈して、一般的な解説書などでは、フローを作る設計作業と、BASICに翻訳する作業を比較して、後者の方をレベルの低い作業だと言っているものが見うけられますが、実際はそうとは思いません。
まず、フローがいくら完璧でも、通常は、それをそのままBASICに翻訳できるほど詳細なフローを作ることはしません。もし、そうしていれば、そのフローを元に、自動的にプログラムに変換してくれるツールが一般的に多く出回っているはずです。しかし、実際はそうではなく、基本的にBASICに翻訳するときに、フロー図に欠けている使い勝手が盛り込まれることが多く、ここが1つの腕の見せ所かもしれません。良いプログラマの条件とは、知識より、こういう使い勝手に配慮がまわる人ではないかと思いますので、是非、色々なプログラムを作って発表し、多くの人の目に触れるようにするのが良いでしょう。

さて、ちょっと話がカタくなりましたが、フローをつくって、BASICに翻訳する一連の手順はどうだったでしょうか?
この手順に完璧な正解はありませんので、各自でアレンジして、色々作ってみてください。

一方、フローをつくって、BASICにするなんて面倒臭いや、と思う方もみえるかもしれません。
確かに面倒ですが、紙に書くか、頭にあるか、どんな方法かはわかりませんが、結局、フローがないとプログラムにはなりません。
できるだけ形にしてフローなどの設計書を残しておくことを、経験からオススメします。

前へ     目次へ

第8回 筋道を立てよう − フローチャート − 「6.プログラム化しよう」