今月は天災の月であり、私にとってはDelphi７導入、そしてデータベースとの格闘の月でした…(◎-◎)どうもなにがなんだかわからない、マニュアル通りに多分しているはずなのに、うまくいかない、ということが多かったのです(T-T)前回、データベースなのに項目にデータを代入できない謎のエラーが生じたところで止まってしまいました。この間、こいつは何が原因なのか、わけがわからん…と投げ出したくなること、何度か(--;)
まず、データベース自体のエラーは、Delphiのエラーとはちょっと異なっています。Delphiが色々なデータベースを動かすことができるため、エラーもデータベース独自のエラーだったりするのです。そしてそのエラーの説明はヘルプにもマニュアルにもなく、なんじゃこりゃあ！となることが多いのです（￣□￣；）
今回対処中のエラーも、書き込みモードになっていません、というエラーです。書き込みモードとはなんぞいな…？文字通り項目に書き込めるモードです。データベースを触ったことがわかる方は、ああ、あれか、というあれです(^^;エクセルなど表計算ソフトでも同じです。セルカーソルを動かして移動できる閲覧モードと、セルの内容を書き換える編集モードってのがありしたよね。
で、エラーの箇所は多分閲覧モードになってるから、編集モードにする、という命令を付け加えたらいいはずです。で、付け加えたのですが、なぜか、動かない(T-T)まさにバグ。こういう、自分では正しい意図を持って正しい命令を書いているのに動かないという場合、間違っているところがわからないので、途方に暮れます…(T-T)
こういう時はいろいろ設定を変えてみたりして、似たような現象が起きたり、ちゃんと動いたりしてくれればいいんですが…。むむ…？まずもって、先週以来のテスト用の、単純な代入文。これからしていつまでたってもエラーのままです(ToT)しかしこの部分はDelphiの構文上はエラーというわけではない。何が原因なんでしょう………？？？（………(_ _).oＯ………(~O~)(-.-)(_ _)…………）
編集モードと閲覧モード……ん？ああそうか！(@o@)
つまり、こういうことです。私のプログラム上のデータベースの操作は、1)編集モードにする、2)ある項目を検索して移動する、3)代入する、となっていました。確かに1)で編集モードにはなっているんですが、2)で移動させちゃったら、編集モードから閲覧モードになってしまっているのです。改めて3)の前に編集モードにしないといけないのです。もしくは、順番を2)1)3)にしないといけなかったのです( °O °;)
そして本来のエラーの部分は、単純に代入せず、別の部品のところに移動して、そちらで代入させる命令だったんですが、この時、別の部品のところで改めてデータベースの項目を移動させていたのです。古い方法の考え方のまま、単純に命令を書き換えたんですけど、これをデータベースの癖に合わせて変えなければならなかった、これが問題の根源でした(^^;;;
オブジェクト指向では、部品ごとに変数を持ち、同じ名前の変数であっても部品が異なれば違う内容を持ちうるのです。オブジェクト指向に慣れていないと、部品ごとに変数の受け渡しがうまくいかなかったりして迷う部分ではあります。私のプログラムでは、武将データなどすべての部品で使う可能性のある変数があります。武将データ自体はどの部品でも見れるんですが、誰の情報を見ている、という変数の受け渡しをちゃんとしていないと、ちゃんと動きません。そこで旧の方法では、その情報がもしかすると変わっていることを考慮して、部品のはじめにわざわざ改めて、こいつの情報を見ている、と言いなおしていました。
そしてそれをデータベースでもしていたのです。代入する内容を定める部品で、その時に閲覧モードに変えたものですから、また戻っていざ代入しようという時に閲覧モードになっているよ、というエラーだったのです……げげ（￣□￣；）
こういうエラーって、データベースはこういうもんだ、という癖を把握していないと、単にわかったような命令を連ねてもちゃんと動かないんですよね(--;)ただ、データベースだと、オブジェクト指向においてもデータの位置などが各部品ごとにわざわざ指摘しなくてもよい、というメリットがあります(^^;まあ、オブジェクト指向でもちゃんとデータの受け渡しをできていれば問題はありませんが…(^^;;
ということで、あれこれあれこれあれこれ、絶望的になりながらなんとか解決しました(^^;;;いやあ、正しいはず、というその前提が間違っている、というのは間違い探しに非常に時間がかかります。危うく諦めてしまいかねませんでした。危ない危ない(*_*)
その後も、テストデータを使用しているため、探しているデータが見つかりません、という意味のエラーとして、項目の最初にいます、という表示がなされて、なんのことかわからなかったりと、データベース発想の癖に泣かされつつ、ようやく本道に復帰できそうです(^O^)いやあ、Delphi７導入後１か月。データベースが使えるようになって戻って参りました(^^ゞ
データベースのいいところは、大量のデータ操作が簡単にできることです。変数だけだと、単に並び替えるだけでもプログラム上で計算を色々させたりとか、プログラマーがうまくできるように色々考えたりとか、かなり大変な面もあります（-o-;）それがデータベースだとコマンドひとつでできたりします。いやあ便利じゃわ(^O^)
さらに、Delphiの動的配列という仕組みで変数だけでもかなりのことができるんですけども、プログラム実行中、つまりゲーム中に生じる様々な状況を次々記憶させることも、データベースの得意とするところです。それがどういうことかというと、プログラム上、情報量が次々増えるとしても、データの入れ物としての変数を次々用意することができるかどうか、ということにかかってくるのです。
たとえば同盟関係を考えてみましょう。10か国あり、それぞれが１対１で同盟を結ぶとします。これを単純に、ある１国は残り９か国と同盟を結んでいるか、結んでいないかということを元に組み合わせを考えてみます。すると、45通り分、同盟を結んでいる、結んでいない、という情報を保存する変数を用意する必要がありますね。
しかし、これがある国が謀反を起こされたり独立されたりして、12か国に増えたりすると大変です。66通り分でしょうか？さらに16か国、50か国など、状況に応じて変数の必要量が変わってきます。こういう場合、プログラマーとしては、起こりうる最大値を前提に考えます。たとえば城が60あれば60国全部が別々の国になりうると考えるのです。ほっとするのもつかの間、そうして用意した変数は、おそらくほとんど使われません(~_~;)こうしてせっかく最大容量を基礎として考えてはいるものの、ほとんどは無駄になります。だからといって、色々予想して適当なところで手を打ったりすると、それを超えたりするものなのです(T-T)この辺のさじ加減が難しいところではあります。
ところが、必要に応じて変数の量を変えることができるならば、最初から無駄に用意しておく必要がなくなります(^-^)これがDelphiの動的配列であり、データベースです。データベースなんて、そもそもデータをどんどん追加して入れていくものですから、あふれる情報をどんどん貯めていけます。動的配列もその発想で、最初から限界を設けるのではなく、途中で増やすことができるという配列変数です。
最初、そんなに同盟なんて起きるはずもないから同盟関係を５つに制限しようとか考えていました(--;)しかし、ＳＷＧの各種制限同様、おそらくすぐ打ち破られかねない、と。かといって国ごとに用意していく以上、大量に用意するとしても無駄になるな……と色々考えていたのですが、そうだ、同盟関係だけを別にすればいいじゃないか、と(^O^)これもデータベース的発想だからできたものです(^^;
この発想を引き延ばせば、どこかで見たことのある(^^;;敵対関係とか、ライバルとか、仇敵とか、親子関係とか、師弟関係だとか、人間関係も次々思いつくままに設定できます。もちろんそれを途中で変えることもできますね(^O^)
まあもちろん、そういう内容は枝葉の部分でして(^^;;登場人物全部に色々な情報を付け加えていくといつまでたっても本体がリリースできないので(T-T)多分ゲーム中の敵対関係や仇敵関係などに利用したら面白いでしょうね(^-^)さらに、本体はできあがったとしても、いずれそういう人物関係データを差し替えれば、違った雰囲気を楽しめることはできそうです(^o^)
とまあ、このようなゲーム中の追加情報をデータベースならば簡単に追加でき、処理することができます。さらにはプレイヤーやコンピュータの癖もデータベースで追加していき、司馬懿や諸葛亮のような連中はそのデータベースを利用してプレイヤーの戦術の裏をかく、そういうプレイも考えられます(^O^)しかしま、ここまでくるとますます本体のリリースが遅くなりそうですが(T-T)いずれにせよ、データベースを使えば武将達の癖を表現し、プレイヤーの癖をたどって利用できるようなプレイが楽しめる、そんな可能性が広がると考えられるのです(^O^)
｜index｜
このページへのリンクはフリーです。