エロゲーツクール作ってるから要望くれ！
基本的にはなんでも作れるものを目指してるんで、他のスクリプトより作りにくいかも。
しかーし、スクリプト部分は自作可能＆VBSやVB等COMサポート言語から描画エンジン直接呼び出し可能！
ちなみに本開発にあたって競合製品のリサーチは行なっていません。あくまでも独自性を大切にしてます。
とりあえずナイスな要望求む！
あと使ってるプロバイダかからの書き込み規制かかってるので誰か串教えて下さい。
ダッチコントローラーとか。
じゃなくって、スクリプトの仕様とか、描画まわりの機能とか・・・
紙芝居程度なのか、それともアクション、ひいては 3D ゴリゴリまで含むのか等、
どの程度の範囲を考えてるのかが解らない。
紙芝居なら既に色々なスクリプトエンジンがあるので、
相当良く出来た IDE でも作らない限りは利用されないかと。
・乳揺れエンジン
・動的モザイク
・ブッカケエフェクト支援
・自動ネコミミ装着機能
・インバースキネマティクス付き多関節着せ替え人形機能
・デュアルショックコントローラ対応軟体変形機能
・半自動あえぎ声生成ウィザード
・語尾専用リファクタリング機能
モザイク無しは基本な。
・2Dで髪の毛とかふさふさふわってできる機能ほすぃ～
・動画編集はパーツ毎にキーフレームを設定できて個別にリピート可能
・リップシンク
・テキスト読み上げ機能
・シチュエーションを入力したら背景を作ってくれる機能
すいません。説明が適当で。
3Dは知能的に無理やけど、アクションや短編RPGとかは作れるレベルにしたいと思ってます。
作成の目的は自社ツールなんです。もち、フリーとして公開はしますけど。
今までこの手のゲームをあまりした事がないので、どのような機能に需要があるのか教えてほしいんです。
>>6-9
非現実的なものばかりですね。
でもブッカケエフェクト支援とリップシンクは面白いですね。
動くものだせ
それ言ってるのおまいだけじゃね？
必要ない
終了
必要ない
終了
必要な機能なり改善点なりを集めるべきだろう。
とりあえず今週中にVBSで作成したバージョンをアップします。
その時にまたお願いします。
m(__)m
まさかエクセルか何か？
・アウトラインエディタのような文章整理機能
・シーンと素材を結びつける管理ソフト
開発環境としてはこれぐらい欲しい
スクリプトとしてはクラスやコンテナあたりが欲しい
もう関数増やして多機能ですよ、凄いですよってされても
多少のことじゃ驚けない気がする
ライバルはsystem4.0や吉里吉里かと思ってたけど
よくよく読んでみるとHSPやActiveBASICあたりを
狙ってる感じなのかな
RAD強化するならGameMakerになるだろうけど。
WSHです。
VBでも作れますが、あえて簡単なモノをという事で。
あとVC版をスマートポインタを使うサンプルという事でソースで付けます。
>>21
欲しいですねぇ。
携帯からの書き込みは辛いです(;^_^A
>>22
MFCが苦手なんで開発環境の方はあまりまだ考えてないんですが、クラスは確かに欲しいですね。
恐らくクラスというよりは、もっと簡単にして、関数付き構造体みたいにすると思います。
関数の数は他のスクリプトがどれだけ備えてるか知らないけど、たぶん他のより少なくなると思います。
スクリプト解析・実行エンジンはまだ作りはじめたばかりなんですけど、描画エンジン部分はかなり完成してきました。
とりあえず初期化・解放コマンドが完成したんで、今日あたり公開します。
あきらめろ
吉里吉里ちょっと気になるので見てみました。
確かにすごいですね。
コンセプトもなんか似てるし。
もうちょっとゲームを作りやすいGUI環境を用意するんでもいいんじゃない？
イイ事言いますね。
確かに日本人開発者や開発会社って、「他にあるからいいや」みたいな所ありますよね。
開発者はオナニーと言われても、もっと作るべき！
それとも日本は開発者を刺激し合う環境が整ってないんかな？
とりあえず手始めにCodeProjectが日本にも欲しいなぁ。
>>27
よく読んでないけど吉里吉里がGPLライセンスなんで、それも一つの手かもしれませんね。
>>25じゃなくって>>26。
ﾊﾟｲｽﾞﾘでよこせｸｽﾞ
本家ほどレベルが高い物が集まるかなぁ('A`)
GPL or 独自ライセンスだな。
- GPLに準拠
- 吉里吉里のソースを流用したことをそのソフトウェアなどのドキュメントに記述する
- 吉里吉里の作者にソースを流用したことを通知する
のどれか1つを満たせばいいらしい。
ttp://www.ultrasync.net/dee/kr2helps/kr2doc/contents/Copyrights.html
（上記より抜粋。改行位置は俺）
>吉里吉里のソースを流用したいのですが・・・
> 吉里吉里２は GNU GPL と独自のライセンスのデュアルライセンスです。
>GNU GPL に従ってソースを流用することもできます。独自のライセンスの方
> ( license.txt に書いてあります ) にて流用する場合は、吉里吉里のソース
>を流用したことをそのソフトウェアなどのドキュメントに記述するか、あるいは、
>吉里吉里の作者にソースを流用したことを通知しなければなりません。
全てテキストでスクリプトを書くのも面倒、というのが正直な所ですが、
このあたりをうまく繋ぐ事は出来ないですかね。
GUI-IDEで骨組みを作って、必要に応じてソースの直接編集・部分的な追加なんかが出来るような
シーン1つはスクリプトでガリガリ書いたり通常のシーンなら文章だけで可
という流れがいい
YU-NOやチュンのノベルでフローチャートみながらゲームできたけど
ああいうチャートで全体を確かめながら作りたい
スクリプトタイプの欠点は見通しの悪さ（アウトラインエディタを使えといわれそうだけど）
全体に及ぶ細かい修整とか、GUIでやってられね～。
>>33に賛成しとく。
スクリプトの仕様はちゃんと出来てんの？
実装=仕様とか言うと泣くよ？ 実装=仕様はスクリプト周りのツールが作りにくくなるから。
吉里吉里2はflex/bison使ってるらすい。
TJSやSYSTEM4.0のような高機能な言語にするのか、
NScriptorのようなADV特化の簡易言語にするのかによりますね
前者であれば、まず中間言語の仕様策定とVMの製作が必要になりますが…
おう。
NScripterはスクリプトの記述が簡単だけど、仕様=実装だから、ツール類や他OSの移植の
互換性が取りにくく、吉里吉里2はシステムが複雑すぎて、作者以外が手を出しにくい。
個人的には割り切って、かなり簡単なスクリプトと明確な仕様の方向でいって欲しいなー。
SYS4.0のSDKも転載公開されてる模様
1が目指してる方向に近いようなので参考になるかもよ
それってGPLではないですか?
だとしたら吉里吉里では使ってないはずです。
そもそも吉里吉里自体ＧＰＬライセンス
ソースには生成済みのコードも入ってるけど、一応ドキュメントに
>そのほか、perl, bison があると便利です。
とも書いてある。
あと吉里吉里はbisonは使ってるがflexは使ってないはず
機能拡張モジュールを作る時には使うかもしれないけど…
ゲームを作る時に最低限必要な言語仕様って何でしょう？
条件分岐
ループ
画面出力の関数
ver1.24から例外が有効、ver1.25から商用利用可 になったのね。
flexはBSDライセンスだから著作権表示さえすれば商用も問題なし…
bison+flexでも特に問題になることはないって事か
色々なゲームが作れる＝低級言語
という図式になると思ってます。
何かに特化した方が偏った機能実装できるしGUI開発環境を提供しやすいからです。
そう考えれば今回のシステムはやなり低級になるのかもしれません。
今日中にUPしますんで、一度確認してみて下さい。
目指しているモノが分かってもらえると思います。
おー。そうだったか…。
>>38
38が想定してるTJS-KAGの関係ってのがどこまでを指すのがわからないが、
あの関係はあまり使われない汎用性のわりにスクリプト記述や構造を複雑に
するだけだと思う。
TJS2が分かれば細かいとこに手が届くのは嬉しいけどさ。
>>50
低級言語の意味がよく分からん…。すまんが定義教えちくり。
スレの流れから、『言語仕様が簡単』ととれはするけど。
ちなみに一般的には低級言語＝ハードウェアの動きに近い言語って意味な
のだが、これは違うよな？
現段階ではそうですね。
大切な部分ですけどGUIは後回しで考えてます。
>>51
十分高級言語なんだけど、汎用性のある関数しか備えないから、VBよりはCに近いものになるって事です。
高級言語や簡易的なスクリプトしか触った事しかない人にとっては、C++もC#もJAVAも変わらないと思うんですよ。
そういう意味での「低級言語」です。
うーん。我ながら下手な説明…。
で、公開が夜遅くなるかもしれません。
仕様なんかなぁ…
な訳ないよな。
スクリプトがないと話にならないからねぇ
自分でいじれない人は他人の作った拡張を使っていればいいんだしさ。
吉里吉里はすでにそういう使い方のされかたとしては成功してると思う。
ちゃうちゃう。
拡張（プラグイン）の話じゃなくて、スクリプト（TJS2）とそのシステム全体の複雑さ。
GUIツールっていっても、そのGUIツールにとって都合のいい記法に従ったKAG3を埋め込む
くらいしかできないんじゃない？
HTMLとホームページ作成ツールみたいな関係だなあと思ってしまう。
一度、そのツールを使ったら直接スクリプト触れるのは恐い、みたいな。
吉里吉里2は好きだし成功してるとは思うが、周辺開発ツールがこれから発展していくか？
と考えると疑問なわけよ。
だれかが、配付制限のないTJS2&KAG3解析ライブラリでも作ってくれたら分からんがなー。
>>52
ん。なんとなくは分かる。
比較的静的なゲームに必要な基本的な機能しか備えない、って感じかね？
どうやらCOM側の問題で、マルチスレッドが原因だそうです。
MSが公開している回避策があまりにゲームには不向きなんで、対策を後回しにして、とりあえず雰囲気が分かる程度の機能削減バージョンをUPします。
>>56
そうゆう事です。
ゲームに必要なアルゴリズムがある程度分かっている人だけにやさしいツールです。
逆に良く言えば、それさえ分かればゲームが作れるツールです。
>>56じゃなくて>>58です。
携帯カキコ辛い…。
>GUIツールっていっても、そのGUIツールにとって都合のいい記法に従ったKAG3を埋め込む
>くらいしかできないんじゃない？
そのとおりだろうけど、そうじゃないツールって考えられるか？
>HTMLとホームページ作成ツールみたいな関係だなあと思ってしまう。
>一度、そのツールを使ったら直接スクリプト触れるのは恐い、みたいな。
そういうオーサリングツールを使う利点は直接スクリプトとかを弄りたくないから
つかうのであって、スクリプトを弄らなきゃできないことをやる用途に
オーサリングツールはつかわんよ
それのどこに問題があるのかわからん
つまり、TJSとKAGが、Win32SDKとMFCの関係になってしまっている、ということですかね？
SDKで1からアプリケーションを作るのは骨が折れる。
そこでMFCを使えば、それなりのアプリケーションを簡単に作れるようになる。
しかし、自動生成されたコードは複雑・多量すぎて、何をしているのかよく分からない。
こちらが動作を把握していないのに、アプリケーションを作るには不安が残る。
新しいモジュールを追加したくても、内部構造が把握できないからどうすればいいか分からない。
吉里吉里はまさにこんな状況になってしまっている、ということでしょうか。
オーサリングツールどうこうよりも、「KAGをほんの少し改良することすら難しい」
のが問題なのかと思います。
伝わるかどうか分からんが、XML文書とかは1から入力したり、テキストエディタで修整したり
いろんなツールから作成、参照、修整してもXML文書として正しければ問題ない。
そしてツールとスクリプトいじりを併用できないのには問題がある。
…俺がずっとそういう使い方をしたかったからだっ！
>>59-60
あはは、お疲れさま。公開したらいじってみるさー。
>>62
>>58で言ってるのはちょっと違うかも。そういう複雑さはあると思うけど。
KAG3をほんの少し改造するのは、TJS2のソース見ればそんなに難しくないと思う。
内部構造もマニュアル&ソースでそれなりに理解できるし。
>>51で言ってるのは、一番多く使われている『ノベルツール』として見たときに無駄
に複雑な層分け（TJS2層-KAG3層）がされてるなあってこと。
しかもKAG3の中にTJS2を書かないといけないケースが多く、層があいまいになり
複雑さが増している（TJS2的な書き方をしないと、変数の操作ができない等）
閉じた環境として見ると、ものすごいの一言だけどなー。
でもドリームウィーバーが本職の人に人気があるのは、吐くコードがシンプルでソースが触りやすいからですよ。
ATLやMFCが嫌われる最も大きな理由は、恐らく理解が難しい（できない）からですよね？
最初はラクチンでも、ちょっと珍しい処理をしようとするとお手上げ状態になったり。
だからあくまでもスクリプトがメインで、お助けでたGUIってのが理想だと思います。
なるほど…
確かに簡易言語と低級言語（ローレベルな、という意味で）を同時に使うのは混乱の元になりますね。
せっかく吉里吉里には中間言語やVMといった統一表現があるんですから、KAGとTJSを完全に独立させて、
KAGで使うTJSプログラムは、中間言語コンパイル済みモジュールにしてしまえばいいのに、と思ったりもします。
（もちろん手間が増えますから、効率の面では、決していい方法ではないでしょうが）
やはり、簡易言語に一本化してしまうべきなんでしょうかねえ。
ちょっと使い込みたい人からしてみれば、システムを直にいじれるような
受け皿もあった方がいいと思いますが。
アップしました。
全然機能がなくって恥ずかしい状態ですが、一度見てみて下さいな。
ちなみにまだスクリプトエンジンは動いてません。描画部分のみです。
慣れたら便利やけど、感覚つかみにくいと思うし。
いちいちくそつーるであげんな
くそすれたてんな
いちいちくそつーるであげんな
くそすれたてんな
デバッグとの振り分けとか？
まぁない方がシンプルやし、作るのもラクなんですけど、
でもCで言うincludeと、外部スクリプト実行関数は分けれた方がいいしなぁ。
自作？ツールで作成？
ちなみにツールって何ですか？
文法を定義するとソース解析（パース）までは自動生成してくれるから、
後はそれを元に構文木を作ったり、コードを出力したり。
何か理由つけて逃げる
間違いない
否定はできん。
取っつきやすさ？言語の柔軟さ？強力なカスタマイズ機能？
考え始めるときりがありません。
時間計算機能が加わり、フルスクリーン切り替えも自由自在です。
ttp://www.geocities.jp/rimowa_silverintegral/testprogram2.zip
見た目以上に中身は結構複雑なんで、どんどん更新ペースが悪くなると思いますが勘弁して下さい。
>>79
よろしくお願いします。
完成したらバンバン作ってくださいな。
>>80
そうですね。
やはり柔軟さは大切でしょうね。
あとゲームなら、ソースの見やすさかな。
クラスじゃないけど、簡単に特定の単位で分けれて管理をできるような機能があればうれしいでしょうね。
ゲームを作る事自体が一つのフラグゲーム遊びみたいになっちゃうし。
逆に専門性と簡便性が本当に使えるツールに必要だと思う
なぜか。仮に>>1が吉里吉里と同等の機能を持つスクリプトを開発したとする
それだけで凄い事だからこの板に伝説の1として歴史に残ると思う
でも普及しない。わざわざ新しい文法を覚えるのにコストが掛かるし
プラグインや解説やバグ報告や知名度や諸々の使用実績の差があるから
「なんでも作れる」けど「他のスクリプトより作りにくい」ものは使う動機がない
反対に簡単に一つのものが作れて「競合製品」が少ない方が成功すると思う
例えば「ブッカケエフェクト」みたいなのは既にあって、これはスクリプトじゃなくて
液体を描くだけの単体ツールだけどもざっと5000本売れて400万位売り上げてる
描画エンジンとかは完全にブラックボックスだけど回想モードが標準で使えるとか
カスタマイズ指向よりパッケージ指向の方が制作者に喜ばれるはず
もしTJSを隠蔽して吉里吉里のみを配布しても皆さほど困らないと思うけど
逆にポンとTJSだけあって吉里吉里／KAGを自力で組む状況を想像してみよう
たぶん百分の一くらいにユーザーが激減する
じゃあ、>>65がちょろっと触れてるように、ローレベルな言語は完全にパッケージとして隠蔽してしまって
豊富なパッケージを用意すればいいんでないかい？
本当に自分だけのパッケージを作りたい人は作ればいいし、
作らなくてもいい人は既存のパッケージだけを使ってればいい。
それに拡張性が不要というのは疑問かな。
使っていれば、当然それなりに不満点が出てくるわけで（言語機能や仕様に）
それを自分で改良して追加、もしくは他人が改良したものを追加できるだけの
拡張性は必要だと思う
他人による拡張なんて現実的にありえない。
例えばトランジションの追加とか、セピア調フィルタとか、そういう拡張は
（もちろん初めから入っていた方がいいけれど）可能にした方がいいんじゃない？
っていうことです。
最近Nｽｸスレでスクロールバーを作った人がいてちょっとにぎわったけど
あれぐらいの拡張が標準で出来ない方が不自然なんじゃないかな、と。
もちろん普通の利用者から見たらブラックボックスで。
そんなに珍しいものでもありませんし。
ただ、スクリプトエンジンがうまく作成できたら公開したいですね。
「こうすればスクリプトエンジンを追加できるよ」みたいな。
恐らくうまく作れないから、サンプル添付になると思うけど…。
スクリプトの変更がRADに反映されてRADの変更がスクリプトに反映されるような・・・
C風の構文にすると1つ終カッコが抜けるだけで解析不可能になりそうやしなぁ。
とりあえずはVCやアクロバットの左の部分みたいなのを付けてスクリプトを見やすくしようとは思ってます。
ってか、まだ分からないってのが本音ですね。
「たろたろそーす」でぐくれ。Photoshopのスタンプツールに
毛の生えたような代物らしい。精液ハンコとでもいおうか……
バリエーションが決まり切っているのであまり表現力豊かとは言えない模様。
作者がKAGを作って公開してからやっとブームになった。
つまりユーザーのニーズってのは高機能かどうかじゃなくて
使いやすさ・とっつきやすさも含めた総合的な評価が高いもの
ってこと。
機能が豊富ならそれでいいというものでもない。
まあ、>>1では
機能も使いやすさも中途半端なものしかできんだろうが。
道程の憧れなんだからそっとしといてやれ
あれだけいい感じに汁描けるならいいソフトだなーと。
100～のスレッドの続きを読む
