エロゲーツクール作ってるから要望くれ!
■ このスレッドは過去ログ倉庫に格納されています
エロゲー用ライブラリ&スクリプト作成中!
基本的にはなんでも作れるものを目指してるんで、他のスクリプトより作りにくいかも。
しかーし、スクリプト部分は自作可能&VBSやVB等COMサポート言語から描画エンジン直接呼び出し可能!
ちなみに本開発にあたって競合製品のリサーチは行なっていません。あくまでも独自性を大切にしてます。
とりあえずナイスな要望求む!
あと使ってるプロバイダかからの書き込み規制かかってるので誰か串教えて下さい。 俺も考えた事ある。
ダッチコントローラーとか。
じゃなくって、スクリプトの仕様とか、描画まわりの機能とか・・・ 44Ko44Ot44Gv5biw44Gj44Gm5a+d44KNDeOBneOCk+OBp+atu+OBrQ3mrbvjga0N5q2744GtDQ== エロゲー用と言いつつ「なんでも作れるもの」と言うのがひっかかる。
紙芝居程度なのか、それともアクション、ひいては 3D ゴリゴリまで含むのか等、
どの程度の範囲を考えてるのかが解らない。
紙芝居なら既に色々なスクリプトエンジンがあるので、
相当良く出来た IDE でも作らない限りは利用されないかと。 >>1
・乳揺れエンジン
・動的モザイク
・ブッカケエフェクト支援
・自動ネコミミ装着機能
・インバースキネマティクス付き多関節着せ替え人形機能
・デュアルショックコントローラ対応軟体変形機能
・半自動あえぎ声生成ウィザード
・語尾専用リファクタリング機能 >>1
・2Dで髪の毛とかふさふさふわってできる機能ほすぃ〜
・動画編集はパーツ毎にキーフレームを設定できて個別にリピート可能
・リップシンク
・テキスト読み上げ機能
・シチュエーションを入力したら背景を作ってくれる機能 ディスプレイから女の子が出てくる電影少女機能キボンヌ。 >>5
すいません。説明が適当で。
3Dは知能的に無理やけど、アクションや短編RPGとかは作れるレベルにしたいと思ってます。
作成の目的は自社ツールなんです。もち、フリーとして公開はしますけど。
今までこの手のゲームをあまりした事がないので、どのような機能に需要があるのか教えてほしいんです。
>>6-9
非現実的なものばかりですね。
でもブッカケエフェクト支援とリップシンクは面白いですね。 誰も言わないのでこの板のあるべきセリフを。
動くものだせ 要望が欲しいのなら、少なくともサンプルなりを出した上で、
必要な機能なり改善点なりを集めるべきだろう。 皆さんすいませんでした。
とりあえず今週中にVBSで作成したバージョンをアップします。
その時にまたお願いします。
m(__)m ・フラグ管理、入力補完、リファクタリング、RADなどIDEならでは支援
・アウトラインエディタのような文章整理機能
・シーンと素材を結びつける管理ソフト
開発環境としてはこれぐらい欲しい
スクリプトとしてはクラスやコンテナあたりが欲しい
もう関数増やして多機能ですよ、凄いですよってされても
多少のことじゃ驚けない気がする
ライバルはsystem4.0や吉里吉里かと思ってたけど
よくよく読んでみるとHSPやActiveBASICあたりを
狙ってる感じなのかな
RAD強化するならGameMakerになるだろうけど。 >>19-20
WSHです。
VBでも作れますが、あえて簡単なモノをという事で。
あとVC版をスマートポインタを使うサンプルという事でソースで付けます。
>>21
欲しいですねぇ。
携帯からの書き込みは辛いです(;^_^A
>>22
MFCが苦手なんで開発環境の方はあまりまだ考えてないんですが、クラスは確かに欲しいですね。
恐らくクラスというよりは、もっと簡単にして、関数付き構造体みたいにすると思います。
関数の数は他のスクリプトがどれだけ備えてるか知らないけど、たぶん他のより少なくなると思います。
スクリプト解析・実行エンジンはまだ作りはじめたばかりなんですけど、描画エンジン部分はかなり完成してきました。
とりあえず初期化・解放コマンドが完成したんで、今日あたり公開します。
そこらの凡人がつくったって吉里吉里にはまず追いつけないよ
あきらめろ >>24
吉里吉里ちょっと気になるので見てみました。
確かにすごいですね。
コンセプトもなんか似てるし。
いっそTJS2を組み込みで利用させて貰って
もうちょっとゲームを作りやすいGUI環境を用意するんでもいいんじゃない? >>25
イイ事言いますね。
確かに日本人開発者や開発会社って、「他にあるからいいや」みたいな所ありますよね。
開発者はオナニーと言われても、もっと作るべき!
それとも日本は開発者を刺激し合う環境が整ってないんかな?
とりあえず手始めにCodeProjectが日本にも欲しいなぁ。
>>27
よく読んでないけど吉里吉里がGPLライセンスなんで、それも一つの手かもしれませんね。
20 名前:名前は開発中のものです。 :05/01/03 23:47:36 ID:L6H4YwOk
パイズリでよこせクズ
CodeProject-jpがあったら面白そうだけど…
本家ほどレベルが高い物が集まるかなぁ('A`) >>28
GPL or 独自ライセンスだな。
- GPLに準拠
- 吉里吉里のソースを流用したことをそのソフトウェアなどのドキュメントに記述する
- 吉里吉里の作者にソースを流用したことを通知する
のどれか1つを満たせばいいらしい。
ttp://www.ultrasync.net/dee/kr2helps/kr2doc/contents/Copyrights.html
(上記より抜粋。改行位置は俺)
>吉里吉里のソースを流用したいのですが・・・
> 吉里吉里2は GNU GPL と独自のライセンスのデュアルライセンスです。
>GNU GPL に従ってソースを流用することもできます。独自のライセンスの方
> ( license.txt に書いてあります ) にて流用する場合は、吉里吉里のソース
>を流用したことをそのソフトウェアなどのドキュメントに記述するか、あるいは、
>吉里吉里の作者にソースを流用したことを通知しなければなりません。 完全GUIベース(LiveMaker)なのも使いにくいし、かといって
全てテキストでスクリプトを書くのも面倒、というのが正直な所ですが、
このあたりをうまく繋ぐ事は出来ないですかね。
GUI-IDEで骨組みを作って、必要に応じてソースの直接編集・部分的な追加なんかが出来るような 流れ制御はフローチャートで繋げていってチップ1つがシーン1つになっているぐらいの粒度
シーン1つはスクリプトでガリガリ書いたり通常のシーンなら文章だけで可
という流れがいい
YU-NOやチュンのノベルでフローチャートみながらゲームできたけど
ああいうチャートで全体を確かめながら作りたい
スクリプトタイプの欠点は見通しの悪さ(アウトラインエディタを使えといわれそうだけど) まあ、完全スクリプト記述の方がPerlとかで調整しやすいってのはあるな。
全体に及ぶ細かい修整とか、GUIでやってられね〜。
>>33に賛成しとく。
スクリプトの仕様はちゃんと出来てんの?
実装=仕様とか言うと泣くよ? 実装=仕様はスクリプト周りのツールが作りにくくなるから。
吉里吉里2はflex/bison使ってるらすい。 >>35
TJSやSYSTEM4.0のような高機能な言語にするのか、
NScriptorのようなADV特化の簡易言語にするのかによりますね
前者であれば、まず中間言語の仕様策定とVMの製作が必要になりますが… >>36
おう。
NScripterはスクリプトの記述が簡単だけど、仕様=実装だから、ツール類や他OSの移植の
互換性が取りにくく、吉里吉里2はシステムが複雑すぎて、作者以外が手を出しにくい。
個人的には割り切って、かなり簡単なスクリプトと明確な仕様の方向でいって欲しいなー。 それを考えるとTJS-KAGのような関係にするのもアリかも ttp://sugesugo.sakura.ne.jp/sdk_mirror.html
SYS4.0のSDKも転載公開されてる模様
1が目指してる方向に近いようなので参考になるかもよ >吉里吉里2はflex/bison使ってるらすい。
それってGPLではないですか?
だとしたら吉里吉里では使ってないはずです。
いや吉里吉里はTJSのパーサ生成にbison使ってるよ
そもそも吉里吉里自体GPLライセンス
ソースには生成済みのコードも入ってるけど、一応ドキュメントに
>そのほか、perl, bison があると便利です。
とも書いてある。 bisonが生成したparserは例外付きのGPLだ。ググって調べれ。
あと吉里吉里はbisonは使ってるがflexは使ってないはず さすがにゲーム作る時にクラスは使わないよなぁ。
機能拡張モジュールを作る時には使うかもしれないけど…
ゲームを作る時に最低限必要な言語仕様って何でしょう? >>44
ver1.24から例外が有効、ver1.25から商用利用可 になったのね。
flexはBSDライセンスだから著作権表示さえすれば商用も問題なし…
bison+flexでも特に問題になることはないって事か スレタイはツクール作ってるって書いてるのにスクリプトを作るのか? 皆さん色々ありがとうございます。
色々なゲームが作れる=低級言語
という図式になると思ってます。
何かに特化した方が偏った機能実装できるしGUI開発環境を提供しやすいからです。
そう考えれば今回のシステムはやなり低級になるのかもしれません。
今日中にUPしますんで、一度確認してみて下さい。
目指しているモノが分かってもらえると思います。
>>42
おー。そうだったか…。
>>38
38が想定してるTJS-KAGの関係ってのがどこまでを指すのがわからないが、
あの関係はあまり使われない汎用性のわりにスクリプト記述や構造を複雑に
するだけだと思う。
TJS2が分かれば細かいとこに手が届くのは嬉しいけどさ。
>>50
低級言語の意味がよく分からん…。すまんが定義教えちくり。
スレの流れから、『言語仕様が簡単』ととれはするけど。
ちなみに一般的には低級言語=ハードウェアの動きに近い言語って意味な
のだが、これは違うよな? >>49
現段階ではそうですね。
大切な部分ですけどGUIは後回しで考えてます。
>>51
十分高級言語なんだけど、汎用性のある関数しか備えないから、VBよりはCに近いものになるって事です。
高級言語や簡易的なスクリプトしか触った事しかない人にとっては、C++もC#もJAVAも変わらないと思うんですよ。
そういう意味での「低級言語」です。
うーん。我ながら下手な説明…。 えーっと、なぜか引数付きのイベントをWSHが拾ってくれません。
で、公開が夜遅くなるかもしれません。
仕様なんかなぁ…
な訳ないよな。
吉里吉里/KAGのプラグインなんて至る所で配布されてるぜ。別に構造が難しいわけでもないし。
自分でいじれない人は他人の作った拡張を使っていればいいんだしさ。
吉里吉里はすでにそういう使い方のされかたとしては成功してると思う。 >>56
ちゃうちゃう。
拡張(プラグイン)の話じゃなくて、スクリプト(TJS2)とそのシステム全体の複雑さ。
GUIツールっていっても、そのGUIツールにとって都合のいい記法に従ったKAG3を埋め込む
くらいしかできないんじゃない?
HTMLとホームページ作成ツールみたいな関係だなあと思ってしまう。
一度、そのツールを使ったら直接スクリプト触れるのは恐い、みたいな。
吉里吉里2は好きだし成功してるとは思うが、周辺開発ツールがこれから発展していくか?
と考えると疑問なわけよ。
だれかが、配付制限のないTJS2&KAG3解析ライブラリでも作ってくれたら分からんがなー。
>>52
ん。なんとなくは分かる。
比較的静的なゲームに必要な基本的な機能しか備えない、って感じかね? WSHでイベントが受けれない理由が判明しました。
どうやらCOM側の問題で、マルチスレッドが原因だそうです。
MSが公開している回避策があまりにゲームには不向きなんで、対策を後回しにして、とりあえず雰囲気が分かる程度の機能削減バージョンをUPします。
>>56
そうゆう事です。
ゲームに必要なアルゴリズムがある程度分かっている人だけにやさしいツールです。
逆に良く言えば、それさえ分かればゲームが作れるツールです。
あ、またミスった。
>>56じゃなくて>>58です。
携帯カキコ辛い…。 >58
>GUIツールっていっても、そのGUIツールにとって都合のいい記法に従ったKAG3を埋め込む
>くらいしかできないんじゃない?
そのとおりだろうけど、そうじゃないツールって考えられるか?
>HTMLとホームページ作成ツールみたいな関係だなあと思ってしまう。
>一度、そのツールを使ったら直接スクリプト触れるのは恐い、みたいな。
そういうオーサリングツールを使う利点は直接スクリプトとかを弄りたくないから
つかうのであって、スクリプトを弄らなきゃできないことをやる用途に
オーサリングツールはつかわんよ
それのどこに問題があるのかわからん
>>58
つまり、TJSとKAGが、Win32SDKとMFCの関係になってしまっている、ということですかね?
SDKで1からアプリケーションを作るのは骨が折れる。
そこでMFCを使えば、それなりのアプリケーションを簡単に作れるようになる。
しかし、自動生成されたコードは複雑・多量すぎて、何をしているのかよく分からない。
こちらが動作を把握していないのに、アプリケーションを作るには不安が残る。
新しいモジュールを追加したくても、内部構造が把握できないからどうすればいいか分からない。
吉里吉里はまさにこんな状況になってしまっている、ということでしょうか。
オーサリングツールどうこうよりも、「KAGをほんの少し改良することすら難しい」
のが問題なのかと思います。 >>61
伝わるかどうか分からんが、XML文書とかは1から入力したり、テキストエディタで修整したり
いろんなツールから作成、参照、修整してもXML文書として正しければ問題ない。
そしてツールとスクリプトいじりを併用できないのには問題がある。
…俺がずっとそういう使い方をしたかったからだっ!
>>59-60
あはは、お疲れさま。公開したらいじってみるさー。
>>62
>>58で言ってるのはちょっと違うかも。そういう複雑さはあると思うけど。
KAG3をほんの少し改造するのは、TJS2のソース見ればそんなに難しくないと思う。
内部構造もマニュアル&ソースでそれなりに理解できるし。
>>51で言ってるのは、一番多く使われている『ノベルツール』として見たときに無駄
に複雑な層分け(TJS2層-KAG3層)がされてるなあってこと。
しかもKAG3の中にTJS2を書かないといけないケースが多く、層があいまいになり
複雑さが増している(TJS2的な書き方をしないと、変数の操作ができない等)
閉じた環境として見ると、ものすごいの一言だけどなー。 >>61
でもドリームウィーバーが本職の人に人気があるのは、吐くコードがシンプルでソースが触りやすいからですよ。
ATLやMFCが嫌われる最も大きな理由は、恐らく理解が難しい(できない)からですよね?
最初はラクチンでも、ちょっと珍しい処理をしようとするとお手上げ状態になったり。
だからあくまでもスクリプトがメインで、お助けでたGUIってのが理想だと思います。
>>63
なるほど…
確かに簡易言語と低級言語(ローレベルな、という意味で)を同時に使うのは混乱の元になりますね。
せっかく吉里吉里には中間言語やVMといった統一表現があるんですから、KAGとTJSを完全に独立させて、
KAGで使うTJSプログラムは、中間言語コンパイル済みモジュールにしてしまえばいいのに、と思ったりもします。
(もちろん手間が増えますから、効率の面では、決していい方法ではないでしょうが)
やはり、簡易言語に一本化してしまうべきなんでしょうかねえ。
ちょっと使い込みたい人からしてみれば、システムを直にいじれるような
受け皿もあった方がいいと思いますが。 ■ このスレッドは過去ログ倉庫に格納されています