ラベル レイユウサイ の投稿を表示しています。 すべての投稿を表示
ラベル レイユウサイ の投稿を表示しています。 すべての投稿を表示

2023年2月26日日曜日

【レイユウサイ・ケルリート】魔物の命名背景を少し紹介

 2月がブログを書かないまま終わってしまいそうなことに気がついたので、書きます。

タイトルにもあるとおり、『レイユウサイ』や『ケルリート-Littlewitch of Kelritos-』、もちろん次回作（仮称：『イルシェラート』）に登場する魔物たちの命名の背景でも書いてみようかな、と思い立って、夜ごはんの準備もまだなのに書き始めてます。

■魔物の名前って何語なん？

細かい話をする前に触れておきます。
『レイユウサイ』から続く作品の世界には、その世界で普段話されている言語（作品内呼称：現代語）と、かつては日常的に使用されたが現在は呪文の詠唱にしか使っていない言語（作品内呼称：古語、古い言葉）があります。
現代語が何語やねんというのはさておき（一部キャラを除くメインキャラの名前で察しはある程度つくよね）、問題は古語です。

古語はいわゆる架空言語です。
文法がどうとかは、正直なところそういう方面に明るくないので語れませんが、ある程度の単語生成ルールにのっとって、魔物の名前をはじめ、数名のキャラの名前や町の名前などがつけられています。肝心の単語の生成ルールはほぼ秘密だけど。
例えば、『レイユウサイ』のサブイベントで触れていますが、町の名前「ケルリート」は、その町付近に群生する霊木（といわれている樹木）の名前「Kelri」に、町を意味する接尾語「-tos」がついて、「Kelritos」となっています。直訳したらケルリの町ですね。

■魔物の名前

例1：ルーエン/イルーエン/アルルーエン
見た目は緑スライム、青スライム、赤スライムの魔物ですが、後の2つはなんか名前の頭についてます。
「ルーエン」はアルファベット表記で「Ruen」と書きますが、これは古語で「世界中にいるヤツ」みたいなニュアンスになります。そのへんの草が魔物になった（どうして魔物になるのか、という話は長くなるので省きます）、という成り立ちの魔物なので、草さえ生えてりゃ場所を選ばないってワケですね。

では、イルーエンとアルルーエンはどうか。
「イルーエン」は「IlRuen」と書きます。「水」の影響を多分に受けていることを示す接頭語「il」がついてます。水ルーエンってことですね。ゲーム中でも氷飛ばしてますが、そういうことです。
「アルルーエン」は「AlRuen」と書きます。「火」の影響を多分に受けていることを示す接頭語「al」がついてます。要は火ルーエン。倒すと火吹き草を落としますが、そういうことですね。
ここで、なんで「イルーエン」は「イルルーエン」じゃないの？　と思うはずですが、これは自分もわからない。
現地の人の気まぐれロマンティックでしょう。
ここだけの話ですが「i」は滴る雫を、「a」はたき火の火を指してます。ここに注目すると、あいつは水属性くせえぞ、とかわかるわけですね。例外はあるけど。

例2：フォルテム/フォルトカイト 等、フォル○○系
「フォル」が頭についてる魔物は、いわゆるアンデッド系です。ゲームのデータを持っている人は図鑑を見てね。
「フォル」は「fol」と書きますが、これは直訳すると「光は完全に破壊された」。超意訳で陽の下で生きられない、すなわちこの世のものではない状態ということになってます。ちょっと無理やり感はあるけど。
ちなみに「フォルテム」は「Foltem」、古語では「苦痛を受け死んだ者」の意になります。
作中では強敵だった「フォルトカイト」は「Foltkeit」と書きますが、これは図鑑テキストにもある通り「死をもたらす者」。魔物としての成立が他の魔物と違う（次回作で書いたのでぜひよんでね）のもあって、冠の「fol」のとらえ方が違います。


他にも取り上げていくとキリがない（夜ごはんも作らないといけないし）ので2つだけにしますが、こんな感じなんだ～～というふうに思ってもらえれば、うれしいです。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2019年5月16日木曜日

【レイユウサイ】装備できるスキル数が4つの理由

今さらな話ですが、今作っている次回作も同じ仕様なので、話をしておこうと思います。

ウディコンで寄せられたコメントのうち、
「セットできるスキル数が4つじゃ足りない」
というコメントがそこそこありました。

理由は2つ。
①快適に操作できるキー数の問題
②プレイヤーに要求する脳内メモリの問題

①は2つの考えにもとづいています。
1)とっつきやすさを考えるとウディタ基本システムの操作に可能な限り近いほうがよい
2)キーボード上で手の位置をほとんど動かさず操作可能な配置

 ここからキー数と装備できるスキル数を、システム作りながらテストプレイして考えたところ、
「4キー＋カーソルキーなら快適さとスキル装備数を両立できる」という結論にいたりました。

 4つのキーをどう割り振るかは、
決定キー……どのゲームでもよく押すはずだから攻撃
キャンセルキー……ウディタ基本システムではメニュー起動とキャンセルなので同じ機能
サブキー……もう一つ攻撃ボタンほしいので攻撃
4つ目のキー……攻撃に割り当てるとスキルは3つしか装備できないが、切り替えボタンにするなら装備数を4つに増やせるから、セット切替
こんな感じの流れで決まりました。フワフワした感じですが、キーボードの配置を考えても、これがベターな解答だと思ってます。

よんでね.txtをよんでくれた方はご存知かと思いますが、
キーボード操作の場合、決定キーは「Z」、キャンセルキーは「X」、サブキーは「左Shift」、4つ目のキーは「A」です。
戦闘中は左Shift、Z、Aキーにそれぞれ薬指、人差し指、中指を置き、メニュー起動したいときは人差し指を右にスライドするだけで操作が完結します。

ゲームパッドでも右側の親指で操作するボタンはたいてい4つなので、4つに収めると操作しやすいはずです。

余談ですがウディコン開催中のバージョンでは4つ目のキーの反応が悪かったせいか、切り替えを使わずに遊んだ人が結構いたように思います……。
（キーレスポンスの調整の重要性がよくわかりました）

②は個人差あると思いますが、
個人的にはどのキーにどの技をセットしたか覚えていられる限界が4つだったので、それに合わせています。
おれは6つでも8つでもいけるぜというオクタコア脳みその持ち主も大勢いるかもしれませんが、自分のゲームなので自分に基準をもってきました。


レイユウサイの話はここまでにして、次回作で使うキー数の話もしておきます。
次回作は、5キー＋カーソルキー操作です。
「見下ろし2Dのマップでジャンプできたらおもろいし、魔物の包囲から脱出したり地形を超えられたりしたらきっとおもしろいぞ」
など思いながら実装したジャンプスキルをもっとゲームに組み込んでいこうという考えから、ジャンプキーを追加しました。
ただ、1キー増えることによる操作難易度の上昇は無視できなくて、レイユウサイに比べてキーボード操作はつらくなりました。
キャンセルキー以外全部に指を常駐させたい場合は小指まで使うことになります。

ゲームパッドではRボタンやらRトリガーあたりに当ててもらう想定です。


さらに1キー増やせば、セット切り替え無しで4つスキル装備できるので試してみたのですが、キーボード操作でもゲームパッド操作でも操作性が苦痛だったのでボツにしました。
全員が箱コンで遊んでくれる、とかならまだやりようはあるかもしれませんが……。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2018年8月18日土曜日

【ウディコン】レイユウサイに届いたコメント・得点について

第8回参加の「自由落下」の作者さんの一人がやっていたのを見て、自分もやってみた。

ウディコン参加者が得点について知ることができるのは、ウディコン投票締め切り後に届く「コメントつきの投票」メールと、結果発表しかないため、
コメントなしの得点を参加者が知ることはできません。
細かく分析してみる場合は、コメント付きの投票分でおこなうことになります。

なおレイユウサイに届いたコメント付きの投票のうち、得点のついているものは70件です。
これを用いて話を進めます。

まずは参加した第9回での順位と得点から。
【9位】『レイユウサイ』(エントリー番号【7】/ 総ポイント129.8点)
熱中 36.8点(3位)+斬新 14.4点(17位)+物語性 22.8点(11位)+画像音声 18.6点(11位)+遊びやすさ 30.7点(7位)+その他 6.5点(--)

投票者全体でみると、熱中度と遊びやすさが高く、物語性と画像音声はそこそこ、斬新さは一歩下がるといったぐあいでしょうか。
ウディコンでは過去の傾向を見ても熱中度の高さが重視されていますから、熱中度3位はかなり良い評価といえると思います。

合計得点
〇最高得点
熱中10-斬新10-物語10-画像音声10-遊びやすさ10-その他+10（合計60）
〇最低得点
熱中2-斬新1-物語2-画像音声1-遊びやすさ2-その他0（合計8）

こういうものなんだろうと思いますが、上下の差は大きいですね。
ちなみに60点をつけた方はコメントでも「今回で一番楽しめた」と書いていたので高得点なのもわかるのですが、
操作面にしか言及せず最低得点つけたのはよくわからないですね。もう少し理由が知りたかった。

平均値：33.1点　中央値：33点

得点分布
熱中度 平均値：7.43 中央値：8
斬新さ 平均値：5.50 中央値：6
物語性 平均値：5.87 中央値：6
画像音 平均値：6.25 中央値：6
遊び易 平均値：6.63 中央値：7


評価の高い熱中度は右肩上がり、遊びやすさは突き抜けこそしないがおおむね高評価。
斬新さ・物語性・画像音声はどれも6点を頂点にした山型分布。
物語性のみ幅がありますね。

コメント傾向
主観でざっくりカテゴリー分けしました。
〇戦闘システムに関して：技能習得等キャラ強化や操作面を除く戦闘に関わる内容
システムに関しては、ほぼ好評でした。
難易度は総じて「良くも悪くも低い」。

〇育成・強化システム：技能習得・付与呪文・キャラ自体の成長システム等に関わる内容
おおむね好評でした。
課題点は、成長率強化スキルの仕様のせいで心理的に他へ手を伸ばしづらい、付与呪文のデメリットが気になって使いづらい等。

〇シナリオ・キャラクター・世界観：シナリオ進行に関係するシステムへの言及を含む
シナリオに関しては、「消化不良」との指摘が数件。
サブイベントの豊富さに関しては好評価でした。
キャラ・世界観に関してはあまり言及がありませんでした。一晩の祭りを舞台にした設定がよいとの評価はありました。
ここで一番不評を買ったのは「時間制限システム」。シナリオ設定に合わせていれたものでしたが、心理的にのんびり遊べないということなのだと思います。

〇UI・操作面：戦闘での操作含む
言及された件数だけで見れば賛否両論でした。
好評だったのは、少ないキー数で操作を完結させていること、操作が簡単であること。
不評だったのは、2×2キー操作である必要性が理解できない旨のコメントがほぼすべて。

意見が真逆で読んでいて混乱してくる部分です。

〇バグがあったよ
ギリギリ片手で収まらないくらいの件数ありました。

〇他
素材が良い
チュートリアルが丁寧
ちょっとしたテキストがいい
等……

なかには「さてはコントローラー買ったばかりだな？」と勘繰りたくなるコメントもありました。
ゲームのReadmeもそうだけど、説明書くらい読んでください……。

結果発表時の得点との比較
〇熱中度
コメ有 平均値：7.43 中央値：8
最終値 平均値：6.86 中央値：7

〇斬新さ
コメ有 平均値：5.50 中央値：6
最終値 平均値：5.61 中央値：6

〇物語性
コメ有 平均値：5.87 中央値：6
最終値 平均値：5.79 中央値：6

〇画像音声
コメ有 平均値：6.25 中央値：6
最終値 平均値：6.24 中央値：6

〇遊びやすさ
コメ有 平均値：6.63 中央値：7
最終値 平均値：6.16 中央値：6

過去参加者いわく、コメントありの得点は高めで、コメントなしのものをあわせるといくらか下がるらしいです。

その法則が発動したのか、熱中度と遊びやすさはずいぶんと下がりました。
しかし物語性や画像音声はほとんどぶれず。
なぜか斬新さは上がっています。

数値はよくわからないですね。

個人や少人数で作る限り、数値よりも何よりも次の作品に生かせるのはコメントですから、なにかあればどんどんコメント入れたほうがいいと思います。
少なくとも自分の場合はかなり役に立っています。

追記：
第八回ウディコン参加作品「電子ゲームブック　自由落下」の作者さんの記事です。
過去のウディコンでもらった投票コメントをなんとなく集計してみた

こちらを参考に、今回の記事を書きました。
たぶんこの記事読んでいる人はこちらも読んでいるような気がしますが、読んでいない方はぜひ。
投稿者 時刻: 0 件のコメント:
ラベル: ,

2018年1月8日月曜日

レイユウサイができるまで

気が向いたので書いていきます。

原案作成が2016年の10月上旬なので、制作期間はそこを起点にします。

1か月目～3か月目
・原案をつくる
基本システム+α（自作システム）で1作RPG作ってVer1.00を公開したあと、またRPG作りたいな～と思い原案を考えました。この段階でシナリオの大筋が先にできて、次にゲームシステムをどうしようか検討することに。
基本システムの戦闘システムをベースに一対一のパズルチックなバランスの戦闘の案が浮かんだものの、シナリオとの相性やゲームのテンポを考えて、ボツとなりました。「暗い森を一歩ずつ踏みしめながら進む」みたいなコンセプトだったら合うかもしれませんが……。
最終的に一番条件に合いそうなのがアクションRPG形式だったので、それを採用することになりました。当時ゲーム歴10年に届くか届かないかくらいでアクションRPGも「よるのないくに」程度しかやったことがない（フリーのものも全く遊んでいない）という、ゲームやらないヤツがゲーム作るみたいな感じだったのに、よく止めなかったなと思います……。
戦闘システム以外のシステムもこの段階で固めてしまっています。メニュー式の町や育成要素などは前作（MoebirinAdventure）のものを改良して引き継ぐことで、システム作りで失敗が少なくなるように意識しています。自分好みなのも大きい。

・基幹システムを作る
アクションRPGのプレイ経験は少ない、制作経験は皆無ということで、ネット上の講座を漁り、なんとかアクションRPGの基幹システムを作成。ついでに入れたいシステムを組みこんだり講座の通りにやるとバグる部分の修正をしたり、汎用性を高める改良などを実施して、自分用に作り変えました。ベースはおおよそ1か月くらいで完成。そのなかでもAIの処理はかなり苦戦していて、心折れそうになりながら1度か2度作り直しています。
初期の戦闘システムでは「攻撃キー×2」のみでしたが、テストプレイしてみると明らかに足りないことがわかりました。攻撃キーをそのまま増やすか切替キー導入で増やすかで考えた結果、操作キーが少なくとっつきやすいと思う、切替キー導入で増やすことに。
メニュー画面とそこから呼び出す機能は1か月くらいで完成。メニュー起動受付は基本システムを流用&改造したものを使い、その上に自作のメニュー画面を乗せるかたちをとりました。
前作から改良して持ってくるはずだったシステムは、もとの処理やDBの作りが絶望的にひどかったので大部分を作り直しました。
そして、いつまでもテストマップには居られないと思い、仮のチュートリアルを作成。

ここまでやって12月中旬。

・付与呪文システムを思いつく
仮のチュートリアルを作って何回か遊ぶうちにまた物足りなさを感じて「なんかもうひと味ほしいぞ！！」となったので「基本の技に任意で付与効果をつけるシステム」を考え、一晩でやりたいことをまとめて年末年始はひたすら付与呪文システムの実装作業をしていました。（後になって知ったことですが、似たようなシステムを搭載したゲームはそこそこあるようですね）
「なんでスキルと付与呪文のセット画面が別なん？」と思われた方もいたと思いますが、後から追加したシステムなのと、低難易度で習得済み技能をメニューから選んで使えるシステムを用意していた（最新版では削除済み）のが理由で統合できませんでした。

・データの仮入力
全スキルのデータとモンスターデータ、付与呪文のデータを全部入力。

4か月目～6か月目
・ひたすらマップを描く／敵とイベント配置
白螺子屋さんのところのマップチップを使いましたが、自分の感覚と仕様が合うので楽しく描けました。ただ、アクションRPG経験の貧弱さが悪さしてマップの広さはアクションRPGにしてはちょっと狭めだったかもしれない（ちょうどいいというコメントも狭いというコメントもある）。ダッシュがいらない広さかつアクションRPGらしいマップ作りと見栄えのバランスをうまく取るのが今後の自分の課題でしょう。ちなみにサルダーム山とティオライ氷穴の2マップ目以降は遊んでいて面白くなかったので、7か月目以降で全面描き直しをしています。

・ひたすらテキストを書く
自分でいうのもなんですが、結構な遅筆なうえセリフ回しが大の苦手だったので、この工程は文章量に対してすさまじく時間がかかりました。txtでテキスト表示システムの制御ができるようにしたおかげで、デフォルトのままよりは執筆速度がマシになったはずなのですが……。この工程が最後まで足を引っ張り、完成は4月上旬になりました。

・バランス調整
戦闘バランス調整はアクションRPGらしい調整が全くわからずほぼ手探り。「Excelで作ったダメージ計算機に数値入れてデータ調整→テストプレイ」をひたすら繰り返しました。思えばアクションRPGにすると決めた段階でフリーのアクションRPGを漁ればよかったのかもしれませんが、全くやらなかったので良くも悪くも他からあまり影響を受けずに作ってしまいました。
最終的には「主人公は低HP・高防御」「モンスターは高HP・低防御」「エリアが変わるごとに要素を足す」の3点を意識したものとなりました。主人公は女の子でしかもマッチョではないが魔法が使えるということから、打たれ弱さを低HPで、被弾時に一応受け身取ったり魔法で防壁を張ったり服になんか防護効果があるという設定（？）で高防御にしています。モンスターはプレイ感覚的な問題でそうなりました。「要素を足す」というのはこんな感じです：ケルリート大洞窟「近接攻撃のみ」→イトバの森「中距離攻撃（火の玉）、回復技追加」→サルダーム山「遠隔攻撃（氷魔法）追加、攻撃力アップ」→ティオライ氷穴／エハルト地下墓地「対集団戦闘になりやすい配置、耐久力アップ」→フェンミの洞窟「ダンジョンギミックが強く影響するマップ」
初期版の戦闘バランス・システム周りはある意味で作者の趣味が色濃く表れたものとなっています。

ここまでで4月上旬、ひとまずの完成となったのですが、ここでウディコンの存在を思い出して、そこまで温めておくことに。

7か月目～9か月目
・ひたすら遊んで、個人的に欲しい機能を追加
いろいろ追加したので記憶が怪しいですが、なんかいろいろ追加しました。技能セット／付与呪文セット画面の下にある小窓で装備中の付与呪文／技能が見える機能や、タイトル画面からキーコンフィグが適用される機能なんかはこの頃に追加しています。一度見たイベントの選択肢が青字になる機能は実装時期もう少し早かったような気もしますが、これも途中で追加した機能。

・その他のシステムを作る
個人的にほしかったモンスター図鑑と、サウンドテストを追加。前作でモンスター図鑑を作ろうとして挫折した経験があるのですが、いつの間にかおやつ感覚で作れるようになっていました。バグはあったけども。

・シナリオの大規模工事
　実はここでルートをひとつ削除しています。ルート1つ・エンディング2つの削除で（現在の）Aエンド・Bエンドのみになってしまったところへダンカン差分の追加で3エンドになりました。他にもルート削除で減った代わりのイベントを追加しています。ルート削除のきっかけは「超説明不足だから」でした。かといって理解できるくらいイベントを増やすと本編を食ってしまうので、削除となりました。フラグ管理ミスの多くは追加したイベント部分で起こっています。デバッグ能力がアレなのに期間ギリギリでシナリオの工事をしてはいけない……。

（この頃はレイユウサイ制作を通して機能向上した汎用システムを前作に逆移植するアップデートも地味におこなっていました）

レイユウサイの制作期間は6か月+3か月で9か月でした。ゲームの長さから言えば制作スピードは遅いほうだと思います。

ここまで作業したあと、最終データをVer1.00として7月23日から開催された第9回ウディコンに初日から参加。フラグ管理ミスの修正やら不便・不親切という指摘のあった部分のフォローなどで連日連夜作業して更新しましたが、デスマーチ状態というよりは完全にハイになってて一人お祭り状態でしたね……。あと、仮眠取っているとバグ報告がくる夢を見ることがあるんですが、そういうときに起きあがってバグ報告掲示板見るとバグ報告が本当にあるんですよね（前作も同じことがあった）。これはフリーゲーム作者あるあるなのかな？
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2017年8月24日木曜日

【ARPG】"レイユウサイ"を公開しました

第9回ウディコンに参加した作品です。

2枠×2セットの技能で戦っていく2D見下ろし型アクションRPGです。
レベル+スキル制の成長・強化システム、技能に追加効果を付与できるシステムを搭載。
プレイ時間目安は、1～2時間程度です。
かんたんな攻略情報をこの記事の下部に折りたたみで記載しています。

最新版（Ver1.25、2018/7/21更新）のDLはこちら。


戦闘システム
2枠×2セットの技能で戦っていく2D見下ろし型アクションRPGです。
使用するボタンは4つのキーとカーソルキーのみで、同時押しや連打の必要がない簡単操作。
成長システム
魔物などを倒すことで得られる経験値でレベルアップし、能力が上昇します。
レベルアップ時に獲得するポイントの割振りで、
ステータスのさらなる強化や、技能の習得ができます。
付与呪文システム
技能に追加効果を付与するシステムを搭載しています。
セットした技能に対応する装備枠に装備することで自動発動します。
装備次第で戦闘を有利に進めることができます。
時間経過
町の外から戻る、町の中で移動する、会話イベントの実行などで時間が経過します。
たとえ町の外で延々と魔物を狩っても、町に戻りさえしなければ時間は経過しません。
そのほか
・ゲームパッド対応、キーコンフィグ搭載
・固定戦闘以外はどこでもセーブ可能
・テキストスキップ、バックログ機能搭載
・難易度は2段階

旧バージョン
最新版までに改善されている不具合等が含まれています。
旧バージョンで遊んでみたい方向けになりますので、そうでない方は最新版でプレイしていただきますようお願いします。
もし最新版でも直っていないバグがありましたら、本記事のコメント欄にてご報告ください。最新版の更新にて対応します。
Ver1.03a：最初期バージョンを遊びたい方向け。
Ver1.07：時間経過設定の変更前バージョンです。町へ戻るごとに1時間経過します。
Ver1.12：ロード後に敵が全復活する最後のバージョンです。移動しながら技能を使ったときの当たり判定が改善されています。


かんたんな攻略情報（クリックで展開）

投稿者 時刻: 1 件のコメント:
ラベル: , ,

2017年4月9日日曜日

【ウディタ】自作メニュー画面をつくる

正確には過去形ですが。

メニュー画面のつくりでも書いておく予定だったはずなので書いていきます。


ウディタ基本システムの雰囲気を踏襲した処理を組んでいます。見た目はこんな感じ。
左端に選択肢を表示、右側に主人公の情報を表示するタイプです。
選択肢表示は自作ではなく、公式サイトで配布されているコモンイベントを使用しています。
背景は白螺子屋（http://hi79.web.fc2.com/）さんの素材を使っています。

参考までに基本システムのままの表示も貼っときます。

メニュー画面にほしいもの・必須なものとして
・「装備」とか「アイテム」とかの一覧を開ける選択肢の表示
・パーティにいるキャラクターのHP（必要があれば他のステータスも）の表示

これだけあればとりあえずメニュー画面を名乗れると思うので、レイアウトさえ決まれば見た目はなんとかなるとおもいます。
あと、ゲーム内容に合わせた背景を表示すると雰囲気出るので、背景表示がゲーム進行の妨げにならないゲームならやったほうがいいと思います。基本システムでもちょっと改造するだけで背景表示は簡単にできます。

メニュー画面の表示処理は
常時並列でキー入力受付（基本システム流用・一部改造でじゅうぶん）
↓
メニュー画面の初期表示をするコモン呼び出し・初期表示をする
初期表示では、「装備」とか「アイテム」とかの一覧を開ける選択肢の表示を行うのと、パーティ情報を表示するコモンを呼び出しています。パーティ情報の表示・消去はメニュー画面で頻繁に使うので、ひとつのコモンにわけておいたほうが便利。
↓
選択肢キー入力受付
↓
決定キーが押された位置に対応するコモンの呼出
↓
キャンセルキーが押されたら選択肢消去・パーティ情報消去

こんな感じ。ただ、自分は借り物のコモンで選択肢表示をしているので、選択肢処理をちょっと省力化してます
他にオプションで現在地出したいとか、操作説明出したいとか思ったら、それ用にコモンを作って、ふさわしい位置で呼び出して表示するだけ。
基本的に描画処理は「それらしい」「使いづらさを感じない」「見づらさを感じない」の3点さえおさえられるようにすればテキトーでもわりとなんとかなります。システムグラフィック作成能力に乏しい自分のような人の場合は、お手軽ウィンドウの機能や図形表示機能を使うことになると思うんですが、それっぽさを考えて配置するとそれっぽくなります。

ウディタ基本システムのメニューではピクチャ番号をコモンセルフ変数で操作してますが、メニュー画面に限らずあらゆるピクチャは変数で番号指定しないと修正が面倒すぎて何時間あっても終わらないので、変数で管理するといい感じ。
ユーザーDBでピクチャ番号を設定しておくデータを作っておいて、コモン内では対応する項目を指定して番号を取ってくるようにすると管理が楽。

あと、個人的な感覚ですが縦にコマンドが並ぶメニューは6個までが操作性の面でいい感じ、それを超えるとちょっとよくないかなと思っています
今作は7個になってしまいました。システムは滅多に開かないので別のところにどかしたほうがいいかもしれないですね。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2017年3月17日金曜日

【ウディタ】ARPG制作の進捗②

メニューについての話をしたいんですが、追加システムを実装する方向でいるので結局後回しに……。

前回から3週間近く経ったので、つなぎで進捗でも書いていきます。

システム部分は9割くらい完成。
前回から新たにシステム設定・キーコンフィグを実装しました。重要なシステムですね。ARPGの操作性は重要ということでゲームパッド向けの設定も用意しましたが、確認できる機材がないので不具合修正のサポート対象外になりそう。ゲームパッド持っている人にテストプレイお願いしたほうがいいかもしれない。
あと、なぜか未実装だった難易度の違いによる処理を追加したり、バグ修正したりしていました。
それで前回から2割も進んだのか？ と聞かれそうですが……ようやくシステム完成のめどがついてきたから進捗も修正した、といった感じですね。

テキストは3～4割くらい完成。
実装も済ませて、すでにテストプレイで表示も確認済み。ただ、正直なところゲーム開始から15～20分間、1回戦闘のチュートリアルやったあとひたすら会話イベントを踏みまくるかダンジョンの出入りを繰り返すか寝るかして時間を経過させないと本番のフィールド探索&戦闘に移行できないのは正直言って苦痛すぎるので、時系列をもっと圧縮する必要がありそうです。
以前作った「Moebirin Adventure」ではテキスト量が最低限しかなかったので、ゲーム始めてから長くても5分でもう自由の身でした。もうちょっとイベント経たほうがいいんじゃないかと思いもしましたが、なんだかんだでよかったかなと思っています。
今作はARPGのジャンルで、かつ自作戦闘なのでチュートリアルパートを仕込んでおく必要があった関係上、自由になるまで若干時間がかかりますが、それを含めても開始から5分くらいで本番のフィールド探索に行けるようにしたいですね。
一応試作バージョンを経るごとにシナリオ上は短縮されているのですが、それでもやっぱり本番までが長い。
昼食食べてるNPCのイベントを夕食食べてるNPCのイベントに置き換えるくらいの気持ちでいいかもしれない。

マップ描きは今の予定分では、9割くらい完成。
通常のフィールドが4つ、ミニフィールドが1つ、チュートリアル用が1つ。
残り1割はエンディング分岐した先のラスボスがいるマップのぶんです。ARPGということもあって、微妙に勝手がわからず、とりあえずやや単純なマップにしています。最後のフィールドも、以前作った「Moebirin Adventure」のラストより迷わないであろうと思われるくらい単純。遊んでいる人の性格によっては今作のほうがドツボにはまってしまうかもしれないけれど……。

データベース入力は町での会話イベントくらいしか入力やってません。モンスターも仮入力の段階…。
ここは3週間経っても進捗ダメですね。
まあ、ラスボスのイベントを仮設置してからでも遅くないくらいデータベース入力は制作プロセスで後ろの方なんですよね。たぶん。

なんか先月はよくわからない制作の段取りを書いてた気がしますが、どう考えてもデータベース入力は後ですよね。思い出せば以前作った「Moebirin Adventure」もバランス調整しながらやってました。
まあ、マップ描きとシステム作成は大半が終わったので、次はテキストってところなのですが、ここの進捗は着実に進みはしてますが微妙に遅いですね。
1日5%くらい進めたいと思っていたのが、実際は2、3日で5%ですからね。時系列を圧縮して、イベント数もただの会話は厳選して減らしていく方向になるでしょうね。クエストシステムは今回入れないつもりなので、それに代わるような遊べるイベントを入れたいところです。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2017年2月25日土曜日

【ウディタ】アクションRPG制作の進捗

アクションRPG作る構想をぶちあげてから数か月経ったし、ブログの更新頻度が月1回を下回るのは個人的なこだわりで避けたいので、進捗状況でも書きます。

「ウディコンに間に合えば出そうかな」くらいのことは考えていますが、休みの日にブーストをかけていかないと、普段のペースからして明らかに間に合わないので、がんばっていきたいところ。

それで、自分で作る部分に関しての進捗ですが……

システム部分は7割完了といったところ。
戦闘システムはほぼ完成しているつもりではあるものの、ボス戦とか作ったら演出用に機能追加したくなるかもしれない。雑魚戦に関してはすでにダンジョン1つ作ってテストして、機能面でおおむね問題ない感じになっています。
ゲームの基幹となるシステムは、システムの設定機能が未作成。
育成関連のシステムですが、こちらは戦闘システムと並行して作成したので、こちらもおおむね完成……と言いたいところですが、システムを追加する予定があるので7割といったところ。バランス調整の段階に入る前に実装するか決めます

テキスト部分は1割完了といったところ。
案はメモ帳やExcelに書き連ねてあるので、あとはこれをきちんとした形式で書き起こすだけなのですが、分量に不安がありますね……。

マップ描きは4割完了。
いちおう、ゲーム内で踏破することが要求されるダンジョンが3つあって、そのうち2つは描き終わっています。
そして、おまけのダンジョンとして大小合わせて3つになるのですが、こちらは小さいダンジョン1つが完成しているだけです。
前回から変わらず、ダンジョン歩いて魔物をボコボコにするのがメイン要素のひとつなので、それを考えると少ない気もしますが、長編RPGは途中で力尽きる自信があるので、短編レベルの長さでいいと思っています。
今月中には描き終えることを一応の目標にはしていましたが、おまけのダンジョンは無理かもしれない。

データベース入力はまだ仮入力の段階。
今作はシナリオの都合上装備システムがないため入力の作業量は前より少ないので、それほど時間はかからないとは思います。
アイテムもないんですけどね。
さすがにカスタマイズ要素というか、「強敵との戦闘に向けて準備をする」という作業に乏しいゲームになりそうなので、そのあたりを補えるシステムを搭載したいと思っています。それが育成関連のシステム進捗で書いた追加システムになります。このシステムを実装したら、前回のゲームのアイテム並みにはデータベースを入力することになりそうです。

BGMや効果音、グラフィック関連はフリー素材を使います。
グラフィック素材で自作しているのなんてウィンドウ画像とタイトルロゴくらいなものです。今作はUIのパーツを少し追加で自作しましたが、どれもシンプルで、簡単に作れるものです。タイトルロゴは無謀な冒険ですね。言葉にならないような微妙さが逆に"らしい"かもなーと考えることにしてそのままにしています。まあ、作らずにタイトルメニューだけ出すってのも手ではあるのですが、たいていのゲームにはあるしね……。

進捗はこんなところです。
とりあえず今はマップ描き→システム構築→データベース入力→テキスト→バランス調整 の順でやる予定でいます。3月末までにはデータベース入力までほとんど終わらせることを目標にがんばっていきたいところですね。
実際は気分が向いたらテキストを書いたりもするので、順番なんて実際はいい加減だったりもしますが……。

あと、戦闘処理の改造に伴って出てきたバグの修正をするなど地味ながらも重要な修正を入れながら続けています。
最近の画面に反映されるような修正といえば、NPCにレベル表示をするようにしたことくらいでしょうか。
同じ魔物でもレベルが異なるものが登場するシステムなので、わりと重要でしたね。レベル表示は結構ちっちゃいので、少し大きくすることも検討したほうがいいかも。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2017年1月28日土曜日

【ウディタ】ARPGの戦闘システムをつくる（4）戦闘情報表示

実装自体はそれほど難しくないけど、レイアウトやら表示する情報量やらを考えると頭が痛くなるやつです。

あるといいと思ったものとしては、
・ダメージ表示
・操作キャラのHP・SP
・NPCのHP

最低限この3つはないと遊びづらいですよね。システムにもよるだろうけど…。

で、他にもこーいうの表示したいな、などと考えた結果がこんな感じ。
なにげにこのブログで今作っているゲームのスクリーンショットを公開するのは初めてですね

まあ、まだ作成中なので、表示が増えたり減ったりするかもしれませんが、基本はこんな感じです。

ひとつひとつ見ながら説明を入れていくことにします。

まず一番上に表示されている「時刻・マップ名表示」ですが、これは町のなかでも表示されます。ぶっちゃけあってもなくてもいいけど、消したり出したりするのが面倒なので、出しっぱなしにしています。ただそこまで邪魔なものでもないし、なかったらなかったで画面のバランスも悪くなるので、これでいいかなと。
Moebirin Adventureでも同様のシステムを積んでいましたが、あちらはダンジョンいっぱいに設置されているランダムエンカウントシステムのなかに組みこまれていました（つまり歩くたびに呼び出されていました）。今回はARPGということで同じ手が使えないため、システム単体で独立させておいて、必要になったらその都度呼び出すようにしてあります。

画面下端に表示されている「スコア表示」ですが、これはモンスターぶっ倒すと増えるやつです。ひとつのダンジョン内で完結せず、複数のダンジョンにわたって蓄積されるゲーム通してのスコアです。これに関しては、まだ周辺システムができていないので、詳細はまた後日書くことにします。

左下に表示されている女の子は主人公（操作キャラ）です。ウディタ公式サイトの素材集に上がっていた高解像度向けのグラフィック合成器用素材を使って作成しています。残りHP%に応じて表情が変化するおまけ付き。
その脇にはHPとSPのバーなどプレイヤー情報を表示。スクリーンショットだとわかりませんが、下地に薄暗いピクチャを表示しています。ここはどのゲームでも同じような感じになっていますよね。このゲームは今のところバーの外枠表示がありませんが……。数値表示ですが、残りHP・SPのほうの文字サイズを地味に大きくしています。
主人公のレベルを表示している通り、このゲームはレベルの概念があります。普通ですね。ダンジョンを出入りしてもレベルがリセットされることはありません。レベルの概念があるなら表示したほうがいいんじゃないかなと思って表示しています。
プレイヤー情報の最下部には、現在のスキルセットと装備中のスキルが表示されています。あんまり見ることもないだろうけど、なに装備してたかわかんなくなると困るので表示しています。

画面の中央付近にはモンスターが3体と主人公が表示されています。モンスターグラフィックの上部に赤いバーが表示されていますが、これが「NPCのHP表示」です。味方NPCだと緑色のバーになります。
ダメージは食らったキャラの上半身あたりのどこかに表示されます。操作キャラも小っちゃいので普通ですね。表示はウディタ基本システムのフロントビュー戦闘にならって、ちょい上から落ちる感じの表示になっています。まあ、不完全すぎる再現ですが。

「むにむにの攻撃！」と表示されていますが、これは仮のものです。たぶん正式版ではスキル使用メッセージなんて出さないと思います。今も通常攻撃しか表示していないしね。地味に1メッセージで複数行表示が可能です。ただ画面が狭いので、NPC用の枠と主人公用の枠の合計2枠しかメッセージを表示できません。まあ、気になるほどメッセージは表示しないでしょう。たぶん……。

投稿者 時刻: 0 件のコメント:
ラベル: , ,

2016年12月25日日曜日

【ウディタ】ARPGの戦闘システムをつくる（3）技の仕様

ようやく全部の仕様が思い通りに動くようになって舞い上がってます。
作った仕様と、こんなのできるよということを書き連ねているだけですが……。

技の挙動
・エフェクトの動作
（1）発動者に隣接する場所にエフェクトが発生する
文字通り。いわゆる近接攻撃です

（2）エフェクトが前進していき、到達する地点に当たり判定が発生する
いわゆる遠隔攻撃です。内部の処理は（1）と同じで、（1）では前進する移動量に0を入れているだけです

（3）範囲内にいる、距離的な意味で発動者に最も近い対象者のいる地点でエフェクトが発生する
回復スキルとか、雷落とすようなやつです。見た目的に前進させたくないやつに使います。
必中だと強すぎなので、発生地点が若干ぶれるようにしています

・当たり判定
エフェクトそのものに当たり判定をつけているわけではなく、別に当たり判定を発生させています。
その関係上、前進するタイプの技能が移動しているところにぶつかってもダメージを受けません。これはもう、どうしようもないね。
当たり判定には、「当たり判定が発生するまでのフレーム数」と「当たり判定が再度発生するまでのフレーム数」を設定することができ、これによって「判定の出が遅いけど高火力」「回復エリアを発生させ、じっとしていれば何回も効果を受けられる」といった性質を持った技能を作成可能になりました（これを今日ようやく実装できた）。

・技能を食らったとき
食らったら、技能ごとに設定された無敵時間が発生します。
自身を対象とした回復スキルでも設定すれば無敵時間が発生するので、やろうと思えば「使えば一定時間無敵になれるバリアを発生させる」みたいなこともできるわけですが、無敵時間を削る技能はあいにく作れないので、そんなひっでえ技能作らないと思います
あと、一部スキルを除き、食らったときのリアクションが発生します。NPCはノックバック、主人公はその場で飛び跳ねます。

・コスト
発動には技能ごとに設定されたぶん以上のSP（MPとかTPとかで表記するゲームもある）を必要とします。
技能を使用した後は、技能ごとに設定された再詠唱時間が発生し、すべての技能が使用不可になります。

技の発動
（1）キーの入力（2種×2セット）
技能は通常攻撃も含め、装備することでキー入力による発動ができるようになります。
2つの技能を登録できるスキルセットが2つあるので、キー入力で使用できる技能は実質4種類になります。
セット切り替えは戦闘中にAキー入力で実行できるようにしました（攻撃は左Shift／Zキー）。

（2）メニューから使用（習得済みの全種類の技能／再詠唱時間にペナルティあり）
難易度選択機能をもし実装したら、イージーモード限定にすると思うような、やさしい機能。
習得済みならすべての技能が使えます。効果が及ぶ目安範囲まで表示するようにしたよ。
ただ、全技能使えるという超性能なので、次に技能が使えるまでの時間（再詠唱時間）にはペナルティをつけるようにしてあります。


基礎は講座を参考にしたとはいえ、初めての自作戦闘で、ここまで実装するのはすごく大変でした……。
ただ、おかげでテストプレイ中に戦闘するのはすごく楽しくなりました。
前回の記事から今回の記事を投稿するまで、戦闘の画面表示とかメニュー画面とか作っていたので、それについての記事も空いた時間に書いていこうと思います。

システム関連で未作成なのは、コンフィグと一部の補助的なもののみとなったので、あとは中身を詰めていく作業になります。
まあ、ウディタはこの作業がスッゲーしんどいわけですが……。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2016年11月6日日曜日

【ウディタ】ARPGの戦闘システムをつくる（2）NPCのAI

前回の記事を書いたあと、NPCのAIづくりをやっていました。
やたら重かったり、使い勝手が悪かったりしたのと、最終的に落ち着いたもののバグ取りに時間がかかって、結局5日ほどを費やしてしまいました。

処理の方法ですが、
確率行動+特定条件下で指定された行動をする
という形に落ち着きました。細かい条件指定とかはできないですが、まあターン制のバトルじゃないので、ある程度ゆるいAIでないとうまくいかないでしょう、きっと。負荷もきついしね。

個人的な要件としては、
味方属性のNPCの存在を考慮すること（シナリオ上の理由から）。
敵属性の仲間同士で補助ができるような処理をつくること。
RPGらしく一定HP切ったら本気モードとかできるようにしたい。
ある程度NPCが手加減できる仕様を入れること。
状況に応じて多少戦い方を変えられるとなおよし
…こんな感じ。まあ、以前クエストシステムとか作っていたときよりはざっくりとしたところから形にしています。大丈夫かよって感じもするでしょうが、実際ほぼ期待通りの動作ができているので、いいんじゃないでしょうか。期待通りの動作をするまでにいくつかバグ出たので潰したりもしましたし…。

仕様

NPCが使用できる技は基本3種類まで。あとは特殊行動用に+3種類があります
また、行動処理と移動処理には、キャンセル率を設定できます。移動はランダム移動時にそれっぽく見せるため、行動処理は、技が撃てるときに必ず撃つようにすると鬼畜難易度になってしまうためです。
ぎゃくにいえば、キャンセル率を調整することで難易度調整できるということでもあります。雑魚敵は高めに、ボスは低めにといった感じ。重要ですね。

特殊行動
特定条件を満たしたとき、必ず実行する行動
条件は、
①自身の残りHP%が、指定%以上または以下のとき
②行動（攻撃/回復）した回数が指定回数目のとき
③敵または味方との距離が、指定範囲の内または外にいるとき
で、「または」を挟んでいる要素はどちらか選択する形になるので、実質的には7種類の条件が存在します

この条件を満たしたとき、
AIを切り替えるか、指定された技を使うことができます。
AI切り替えは何度でもできますが、指定された技は一度しか使えません。技が一度しか撃てないのは、節目ごとに大技を放つような使い方を想定しているため。

これでなにができるかというと、たとえば
・敵が離れたところにいるとき、自己強化に特化したAIに切り替えて待ち構える
・敵が近距離戦闘タイプだったので、自身も近距離戦闘のAIに切り替えて応戦。間合いが取れたら遠距離攻撃のAIに戻す
・HPが減ってきたので大技をぶっ放す/本気モードのAIに切り替える

みたいな感じ。1キャラ1AIではなく、複数種のNPCが1つのAIを使えるようなつくりにしたことで、AI切り替えが実装できました
わりと重要なシステムです。

行動
指定された範囲内に敵または味方がいたとき、攻撃または回復を確率で選択し、確率で最も高威力または最も低コストの技を選択して、技を発動する処理。
当たり判定の範囲を考慮すると、どうあがいても処理がめっちゃ増えるので考慮してません。

走査
指定された範囲内にいる、最も残りHP%の低い敵味方、最も近い敵味方と走査しているキャラとの距離と見つけた敵味方のイベント番号をデータベースに保存する処理。
主人公だけ探すのではなく、敵同士とか、味方同士の情報も探せるので、敵が弱っている仲間を回復しに向かう行動なんかができます。

ウディタ関連のサイトでこういう走査処理について扱っているところは少ないと思うのですが、数少ないそのサイトでは、この処理走査をする処理はどうあがいてもスッゲー重くなると書かれていました。主人公だけ探すなら楽らしいけど。
ちなみに自分は負荷対策で、生きている戦闘可能キャラかつ画面内にいるNPCのみ処理するようにしています。画面外からひっそり近づいてくるNPCは今のところ作れないというわけです

移動
確率で敵か味方に、
指定範囲内に対象がいるときだけ、
確率で残りHP%が最も減っているやつか最も近いやつに接近する処理です。
敵か味方を確率で選択する処理は実質死んでいるようなもので、実際は敵100%か味方100%にしないと、NPCが敵と味方の間を右往左往し始めて使い物にならなくなります
範囲内に誰もいなかったらランダムに移動します。

まだ経路探索処理という、障害物を回避できるようなかしこい処理が未実装なので、これから重くなる処理です。それさえできればもうAI処理の処理部分はできあがりとなるはず…。
さっきウディタ公式のコモン集を見たらちょうど経路探索処理をしてくれるコモンがあったので、組みこめそうな処理だったら組み込むかもしれません。無理だったら自分で組みます。


そんなわけでおおむねAI処理ができたので、画面処理を作っているのですが、これもむずかしい…。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2016年10月31日月曜日

【ウディタ】ARPGの戦闘システムをつくる（1）基本的な処理

講座でもなんでもねえ、ただの制作日記です。
ちょっと前置きが続きます。

まえおき
現在公開中のRPG「Moebirin Adventure」を公開してからは、「作るのは大変だったけど、経験が生かせるように次の作品もRPGにしよう」と思っていたのですが、
「RPGを作るといっても前作の戦闘や育成システムはそのまま流用するのではなく、強化していかないとやっぱ面白くないよなー」と考えるのは、ゲ制以外の創作をやっていても当然のことながら似たようなことはあるわけで、
その当然の流れから、ほしい機能でウディタ公式にないものをなんとか自作しようと奮闘することになったのでした。

しかし、基本システムの改造は場所によってその難易度が大きく異なり、単体である程度独立しているコモン（例えばコモン164番の単体処理とかね）はわりと容易に改造できてしまいますが、一方万能ウィンドウが絡んでくる描画系コモンなんかは結構めんどくさくて、ものによっては大量の「一時変数」が飛び交う魔境だったりして、処理を理解するところまでで気力を使い果たすレベルでした。

あと、やろうとしていたゲームのシナリオ的にも、フロントビューのコマンド式バトルよりも、アクションRPG的な、プレイヤーの操作がよく反映されるゲームのほうが合っていそうだったので、システムの流用&改造は少しやったところで取りやめて、ARPGで作ることにしたのでした。

本題
ここから本題。

じゃあ、ARPGにするとして、どういう処理が必要で、どういう情報をデータベースに入れておく必要があるかという知識は、考えればある程度は出てきますが、前提としてARPGのプレイ経験がさほどでもないので、とりあえずネット上にあるARPGの制作講座を探しました。
でまあ、参考になったのがこれ。ニコニコ動画に上がっていた実況講座。変数の概念がある程度わかっていればかなりわかりやすい講座なので、個人的にはかなりおすすめ。
アクションRPG編の1～4を順番にやっていくことで、アクションRPGの戦闘処理の土台である

・対応するキーを押すと攻撃エフェクトが出る
・敵に当たるとダメージを与えることができる

この二つと、それに関連した処理をある程度揃えることができます。ここまでのハードルがめちゃめちゃ下がるのは自分みたいなへっぽこにとってはすごくありがたいですね。
ただ、最低限の機能のみなので、ある程度は自力で工夫する必要があります。また、不便な仕様や不具合もまったく無いわけではないので、こちらも自力でなんとかする必要があります。ただ、そういう自力での工夫という工程は動画見ながらサッサと作ってしまったので、対応する処理の案なんかを取り上げることは残念ながらできません。
工夫のコツは、システムは違うものの基本システムの戦闘処理の流れを理解すれば掴めると思います。コモン188番の「X◆戦闘処理」なんかが特に参考になるはず…。ダメージを与える処理はコモン164番の「単体処理」が参考になります。
基本システムの描画や一部の内部処理は難解なのであんまり参考にできないのですが、コモン単体で処理がある程度まとまっているものは大いに参考になります。

それで、結局講座とその関連で組んだコモンやDBの内訳がこんな感じ。
主人公操作：攻撃キーの受付をするコモン。
NPC：敵キャラの動作を指定するコモン。まだ主人公に近づいて、一定時間ごとに攻撃してくるだけ。AIはこれから組んでいく予定…。
攻撃：発動者と技能に応じたエフェクトを表示するコモン。
向き→角度：指定キャラの向いている方向から角度を算出するコモン。動画のまんま。
当たり判定：技能の性質（相手に当てる技か自分に使う技か）を見てから当たり判定を発生させるコモン。当たればダメージ処理とリアクションを発生させる。
ダメージ計算：ダメージ計算をして、対象にダメージを与えるコモン。
状態判定：とりあえずダメージ計算のあとに呼び出して、対象のHPが0以下なら死んだとみなす処理をしているコモン。
主人公DB→戦闘DB：主人公のデータを戦闘用DBにコピペするコモン。
敵DB→戦闘DB：敵のデータを戦闘用DBにコピペするコモン。

DBは基本システムのものを削ったり増やしたりしただけ。
主人公データ：項目名の変更だけ。
戦闘用DB：主人公と敵のステータスを一時保存しておくDB。
敵キャラ：敵キャラのステータスを入れとくDB。
技能：大量に項目をいじったので基本システムとは別物に近いかも。ただ、RPGなのでベースは共通（コストや威力）
アニメーション：ほぼ基本システムのまんま。効果音をシステムDB管理に変更したくらい。

まあ、なんていうか、講座以外で新しく自分で作った部分はまだ他人さまに見せられるような中身でもないので、こんな感じで…。
投稿者 時刻: 0 件のコメント:
ラベル: , ,
登録: 投稿 (Atom)