ロゴ初級者がゲームタイトルロゴを作るアプローチ - デザイン開発誌 #2 -
こんにちは、下原です。
今回はBeyond the filedのタイトルロゴを作った話です。
そうだ、タイトルロゴを作ろう
僕はタイトルロゴをゲームジャムとかでしか作ったことがありません。
つまりズブの素人です。
そんなわけですから、資料集めから始めました。
イメージに近いロゴを集めます。
タイトルロゴに求められること
資料を集めているとタイトルロゴに何が求められるかがなんとなく見えてきました。
作品の世界観が伝わる
- フォントが作品イメージにあっている
- 作品のイメージカラーを表している
- 文字の装飾、背景にその作品に関連するモチーフをあしらう
文字は読みやすく、カッコ良く、リズムよく
- ドロップシャドウやアウトライン・エンボス加工で文字の可読性をあげる
- 塊で見た時のシルエットがかっこいい
- 文字サイズや形状・配置にリズムをつけて目で読む時にテンポを与える
上記のポイントをクリアすると良さそうです。
よっしゃ作るで
まず適当にメモ帳に落書きしてイメージを固めます。
「the」がどうしても余ってしまい、扱いに困りました。
なんとなく雰囲気掴んだのでPhotoshopに行きます。
テキストで打ち込み、いい感じのフォントを探します。
Photoshopには標準で結構な数の英語フォントが入っています。
今回はこの「Cambria Math」というフォントにしました。
大きさを適当に変えたり配置を変えて、リズムをつけていきます。とりあえず頭文字と末尾の文字を大きくして、真ん中の文字を小さくするというドラクエ方式。
背景に模様や、文字に装飾とかつけて一回２パターン 作ってみんなに見せてみました。
「左の案はたしかにおしゃれだけど右の案の方がBeyondの世界観が想像しやすい」というFBを受け、右の案でブラッシュアップ。バランス感とか装飾とか足して記事冒頭のロゴが完成しました。
やってみると意外とできた
ちゃんと資料を集めて狙いを立てて作るとできるもんなんだな、と感じました。なんとなくロゴとかデザインが食わず嫌い的に苦手意識があったのですが、単に真面目に取り組んだことがなかったからなだけでした。
後ろの模様の装飾と、もう少しブラッシュアップしたいなーとは思いますが、やるとことたくさんあるので時間が余った時にやろうかなと思います。
引き続き頑張ります。
【マーケティング戦略 #1】お金を掛けないマーケ戦略！
どうも！
Beyond the field マーケティング担当の鈴木ふみです！
先日はゲームのルール概要紹介もあり、
ゲームリリースに向けて、着々と開発が進んでおります！
皆様、引き続き最新情報を楽しみにお待ち下さい！
今回は、そんなBeyond the fieldを
・皆さんにどう知ってもらうのか？
・いかに多くの人に遊んでもらうか？
・そして、それをいかにお金を掛けずに行うか？
その計画の中でメジャーな手法を紹介して行こうと思います！
1.Twitterアカウントの運用
主に自作ゲーム開発者やTCG関連のフォロワーを集めつつ
開発の進捗やTCG業界のトピックスのツイートなどを行っています！
フォロワー数も順調に伸び、現在400フォロワーを無事突破しました！！
まだフォローしていない方は、是非フォローいただけると幸いです！
ブログには公開しない限定情報なども公開しますので乞うご期待ください！
2.予約トップ10の活用
こちらはお金を懸けずに、何かゲームの宣伝をする方法が無いかと
探していたときに見つけたものです！
ゲームのリリース前に事前告知＆事前予約を出来るサービスで、
サービスの一部がなんと”無料”で使えるようなのです！！
今後Beyond the fieldも公開する予定ですので、
その際は是非、事前予約お願いいたします！
3.クラウドファンディングの利用
自分たちの理想のBeyond the fieldをリリースするためには
資金が必要です。。。。
（BGM、カードイラストの外注費など）
資金を掛けてでも、落としたくないクオリティー部分は
自費制作でも手が抜けないところです！
ただアプリゲームでクラウドファンディングを利用するときの
リターン設定である悩ましい問題が。。。
これについては別記事としてまとめますね！
同じように自作ゲームを作りたい方への参考になると幸いです！
ちなみに自分たちはCAMP FIREを活用する予定です！
4.最後に、本ブログの更新！
はてなブログはSEOに強く、
また記事が拡散される仕組みもある程度分かっており
多くの人に記事を届けれる可能性が高いと思ってます！
その仕組とは、記事に対しての
「はてなブックマーク」の数です！
記事が公開されてから、一定時間以内に以下の
「はてブ数」を集めると・・・
・3『はてブ』：カテゴリ別の新着エントリーに掲載
・10～15『はてブ』：カテゴリ別の人気エントリーに掲載
・20～30『はてブ』：総合カテゴリの下部に掲載
・100『はてブ』：カテゴリ別の人気エントリートップ及び総合カテゴリ上位に掲載
となるらしいです！！！
詳細はこちらの記事を参考にしてみてください！
ということで皆さん本記事の
「はてなブックマーク」を
よろしくお願いいたします！！ｗ
他にも細かいマーケティング計画はありますが
そこらへんの紹介はまた後ほど！
皆様の協力のもと一緒に作り上げていきたいBeyond the fieldです！！
温かい応援を今後共どうぞよろしくお願いいたします！
【CSharp】Taskを0から説明してみる
こんにちは、たかせです。
前回の記事は思い出を書き並べるだけで終わってしまったので、今回はそれとなくエンジニアっぽいことを書こうと思います。
非同期処理は全部Taskで書いているよ！
今どきはUniTaskでしょ...
なにそれ美味しいの
とまぁ、いろいろな方がいるかなぁとは思うんですが、今回は主に初心者向けなお話です。Unityでゲームの開発していてScriptも経験があるが、複雑な実装はちょっと...くらいの方を想定しています。
結論から言うと、UniTaskを使いましょう。まだまだ経験も浅いので大きな事は言えませんが、Taskとほぼほぼ同じ使い方ができ、パフォーマンス面でも優れるUniTaskを使わない理由はありません。強いて言えば、標準のAssetではないのでインポートに一手間かかりますが、AssetStoreで公開されているのでさして問題にはならないでしょう。
もう一つの結論を言うと、たかせの開発しているBeyondTheFieldをフォローしてほしいです。質問も称賛も野次も何でも受付中です。
目次
- Taskって何？
- Taskの特徴をイメージしてみる
- Taskの使い方（基本編）
- Taskの使い方（応用編）
- async / await
Taskって何？
次のような状況において便利なクラスです。
- メインスレッドを動かしたまま、裏で通信を走らせたい
- 複数の処理を同時に実行して、完了までの時間を短縮したい
- 描画には関係ない処理をメインスレッドから追い出して、動作の軽量化を図りたい
Taskの特徴をイメージしてみる
具体的なTaskの使い方に入る前に、Taskの特徴をイメージをしましょう。
「メインスレッドを動かしたまま、裏で通信を走らせたい」という課題が生まれる理由は、スレッドは複数の処理を同時に実行できないからです。例えば、
- BGMを再生する
- 次に再生するBGMをサーバから取得する
という2つの処理を受け取ったスレッドは、データを取得している間、BGMを再生することができません。
これを回避するためには、次に再生するBGMの取得を別のスレッドに依頼して、その完了を待つことが有効ですね。いわゆる非同期処理というやつです。そして、「処理を依頼して完了を待つ」実装に役立つのがTaskです。
つまりこの回避策は、「次に再生するBGMの取得を非同期Taskで行う」と言い換えることができます。
スレッドという4文字がゲシュタルト崩壊してきた方は、人に置き換えてイメージすると良いかもしれません。例えば僕のようなシングルタスクな人間がたくさんのタスクに追われたときは、隣の同僚に手伝ってもらいつつ自分のタスクを終わらせようとするでしょう。ほら、スレッドが人だとすればTaskはタスクとなり、ぴったり一致します。
まとめると、次の2つを念頭に置きつつ読み進めて欲しいな、という節でした。
- Taskには依頼者と実行者がいる
- 先の例では、メインスレッドが依頼し、別スレッドが実行しました
- Taskには完了がある
- 先の例では、「BGMの再生を続ける」処理はTaskに向きません
（それにしてもひどい図ですね）
Taskの使い方（基礎編）
歩くUnityちゃんを作ってみましょう。
using UnityEngine; public class SampleScript : MonoBehaviour { private void Update() { ユニティちゃんを一歩進める(); } private void ユニティちゃんを一歩進める() { //割愛 } }
驚異的な速度で歩くユニティちゃんが完成しました。このユニティちゃんに、定期的な進捗報告をさせるとします。
using System.Threading; using UnityEngine; public class SampleScript : MonoBehaviour { private int 歩数; private void Update() { ユニティちゃんを一歩進める(); if (歩数 % 100 == 0) { 歩数を報告する(); } } private void ユニティちゃんを一歩進める() { 歩数++; //割愛 } private void 歩数を報告する() { Debug.Log("報告しています..."); サーバに歩数を報告する(歩数); Debug.Log("報告しました！"); } }
Updateメソッドの中で報告処理を呼んでしまいました...。このユニティちゃん、報告のたびに足を止める超マイペースなユニティちゃんとなってしまいます。歩きながら報告できるよう、報告処理を非同期Task化しま
using System.Threading; using System.Threading.Tasks; using UnityEngine; public class SampleScript : MonoBehaviour { private int 歩数; private void Update() { ユニティちゃんを一歩進める(); if (歩数 % 100 == 0) { 歩数を報告する(); } } private void ユニティちゃんを一歩進める() { 歩数++; //割愛 } private void 歩数を報告する() { new Task(() => { Debug.Log($"この報告は実行されません"); サーバに歩数を報告する(歩数); Debug.Log("報連相のできないユニティちゃんですね"); }); } }
した！
これだけです。Taskクラスのコンストラクタに非同期化したい処理を渡すだけです。シンプルですね。ただしこのScriptには問題があり、報告処理は実行されません。Taskの開始命令が足りていないのです。次のScriptのように、生成したTaskには開始を命令する必要があります。
using System.Threading; using System.Threading.Tasks; using UnityEngine; public class SampleScript : MonoBehaviour { private int 歩数; private void Update() { ユニティちゃんを一歩進める(); if (歩数 % 100 == 0) { 歩数を報告する(); } } private void ユニティちゃんを一歩進める() { 歩数++; //割愛 } private void 歩数を報告する() { var task = new Task(() => { Debug.Log($"報告しています..."); サーバに歩数を報告する(歩数); Debug.Log("報告しました！"); }); task.Start(); } }
これにて、歩きながら報告のできるユニティちゃんの出来上がりです。
まとめると、Taskを使う手順は次の3つです。
- System.Threading.Tasks.Taskクラスをインスタンス化し、
- 非同期化したい処理を与えてから、
- 開始を命令する
開始を命令しなければTaskは始まらない点、忘れずにいてください。逆に言えば、開始済みのTaskがあるときは必ずどこかに命令処理があります。それは今回と同じStart()であったり、Start()とは全く違う別の書き方であったり、状況に応じて様々でありますが、「Taskは開始を命令しないと始まらない」というルールを覚えておくと後のデバッグで役立ちます。
※Taskを使うには .NET framework 4 以上が必要です。こちら等を参考にバージョンアップをお願いします
Taskの使い方（応用編）
前節では基礎的な使い方を説明しましたが、実際の開発ではもっと別の形でTaskを応用していくことが多いです。例えば、
- いちいち
Start()呼ぶのめんどくね？
とか、
- Taskから戻り値がほしい！
- 複数のTaskを同時に実行したい！
- 1つ目のTaskから戻り値を受け取って2つ目に渡したい！
とかとかとか。
いちいちStart()呼ぶのめんどくね？
個人的にはそこまで面倒に感じませんが、TaskにはStart()を省略できる書き方があります。
//Startを省略して実行する Task.Run(() => { Debug.Log($"報告しています..."); サーバに歩数を報告する(歩数); Debug.Log("報告しました！"); });
省略しないケースと比べると、Runというメソッドが増えた代わりにStartが減っていますね。
//もともとのソース var task = new Task(() => { Debug.Log($"報告しています..."); サーバに歩数を報告する(歩数); Debug.Log("報告しました！"); }); task.Start();
RunからTaskを知ってしまうと、「開始を命令する必要がある」という点が抜けがちなので、そこだけ注意が必要です
Taskから戻り値がほしい！
例えば次にように、非同期通信の結果を変更対象のGameObjectに反映させたいとしましょう。
//エラーになる例 private void Awake() { var task = new Task(() => { gameObject.name = サーバから新しい名前をもらう(); }); task.Start(); }
このスクリプトを実行すると次のエラーが発生し、正しく反映させることができません。
get_gameObject can only be called from the main thread.
非同期Taskはメインスレッドとは別のスレッドで動作することを思い出してください。UnityのGameObjectには別スレッドから変更できないという制約があり、その制約を破ると上記のエラーが発生します。
さて、どうするか。
こうしたくないですか？
//こうやってエラーを回避したい例 private void Awake() { var task = new Task(() => { return サーバから新しい名前をもらう(); }); //タスクを開始し、終了したら戻り値を受け取る var サーバからもらった新しい名前 = task.Start(); gameObject.name = サーバからもらった新しい名前; }
したいでしょう。ぜひしましょう。
ただし、上記のスクリプトをそのまま記述してもコンパイルは通りません。Taskから戻り値を受け取りたいときは次のように書きます。
//回避できる例 private async void Awake() { var task = new Task<string>(() => { return サーバから新しい名前をもらう(); }); task.Start(); //タスクが終了したら戻り値を受け取る var サーバからもらった新しい名前 = await task; //メインスレッドで変更するのでエラーは発生しない！ gameObject.name = サーバからもらった新しい名前; }
新しい要素がどっと増えましたね。一つずつ見ていきましょう。
1. await
async / await と言えば聞いたことがある人も多いんじゃないでしょうか。await演算子を振る舞いで説明すれば、「Taskの完了したら戻り値を受け取って次に進む」です。まぁきっと語弊があるでしょうが今回はこういう説明で。「Taskが完了したら」っていう点がミソで、逆を言えばTaskを完了するまで次の処理は実行されません。
var task = new Task<string>(() => { var x = 3; Thread.Sleep(3 * 60 * 1000) return x; }); task.Start(); var 待った分数 = await task; Debug.Log($"{待った分数}経ったよほらカップラメーン開けて！") }
みたいな。
なお、await演算子を利用するためにはルールがあり、利用するメソッドにasync修飾子をつけなければいけません。図の3番にあるやつです。なぜつけなければいけないか？と疑問を持つ人もいるかも知れませんが、「awaitのための特別なプログラムを書くとかまじめんどい良い感じにコンパイルしてわかるでしょ？」とおねだりしてるくらいに覚えればよいかと。async修飾子のおかげで我々は、息を吐くように async / await を利用できるわけです。
2. new Task<string>
newはクラスをインスタンス化する時の命令、Taskはインスタンス化したいクラスを明示する記述です。
では<string>は？
Taskの戻り値の型を明示する記述となります。先の例では、サーバから新しいGameObjectの名前、つまりstring型の値をもらいましたね。
なぜこんなことを書かなければいけないのか！という疑問に答えるにはいささか長くなりすぎたので、割愛させてください。ここでは、「Taskから戻り値を受け取るときはその型を明示する必要がある」と覚えてほしいです。
3. async
await演算子の説明でも話したように、awaitの利用に必要な記述です。これをつけると、コンパイラがいい感じにプログラムを解釈してくれます。
終わりに
いかがだったでしょうか。
今更感のある説明にはなってしまいましたが、Taskを動作から理解しようとすると何分躓くことも多いだろうなぁとぼんやり思っていたので、今回は必要性から説明するよう心がけてみました。
複数のTaskを連結させる方法とか、同時に実行する方法とか、UniTaskについてとか、今回説明しそこねたいろいろは次回に回したいと思います。
僕自身C#の経験は長くないので、もし誤りなどがあればご指摘いただけると幸いです。
＜第2回 遊戯王アニオリカード ヤバさ考察選手権＞
どうも！Beyond the field 広報のあっつーです。
本日は 「第2回 遊戯王アニオリカード ヤバさ考察選手権 」ということで前回に引き続き、強烈にヤバみのあるカードを紹介していこうと思います！今回もゲストにBeyond the fieldエンジニアのたかせに来ていただいているので、そちらのコメントにも注目して見て欲しいと思います！
それでは参りましょう！！
- 「蜘蛛の糸」
第2回で紹介するカードは、遊戯王デュエルモンスターズ第176話で名もなき王（アテム）が使用した「蜘蛛の糸」というカードです。一見アニメオリジナルではなく、OCGに普通にありそうなカードですね。しかしこのカードもおっそろしいカード効果を持っております。
通常魔法
１ターン前に相手の墓地に送られたカード１枚を自分の手札に加える事ができる。
相手の墓地にあるカードを利用する効果になります。相手依存になるため若干使いづらそうと思うかもしれませんが、「カード1枚」というカードの種類を一切制約していないため、相手が前のターンに使った汎用カードを即返すことが出来ます。例を挙げてみると・・・
- 「ハーピィの羽根箒」
- 「サンダー・ボルト」
- 「幽鬼うさぎ」
- 「灰流うらら」
- 「無限泡影」
- 「強欲で謙虚な壺」
これらのカードの内1枚以上はほぼどのデッキでも採用されるため、簡単に汎用カードを使い回すことが出来ます。さらにシンクロやリンク召喚にも即繋げる力を持っているので非常に汎用性が高いです。弱点としては相手のターンを1回挟まないといけないので、先行1ターン目には発動できない、相手が完全なテーマデッキで専用カードしか採用していない場合は刺さらない点などですかね。しかし汎用性に関しては抜群のカードと言えるでしょう。
このカードについてエンジニアのたかせに感想を聞いてみると、
「実装したくないです。こんな効果をもしプロデューサーの松本が持ってきたら見てみないふりします。（笑）
何が嫌って、「このカードは何ターン前に墓地に送られたか」を実装したくありません。処理自体は単純かもしれませんが、全てのカードに適用可能な仕組みを作る必要があり、その影響範囲はルール変更と同じくらい大きな規模になります。
今後新しいカードを追加していくにあたって、「蜘蛛の糸さえなければもっと楽に実装できるのに…!!!」と松本を恨む未来が僕には見えます。」
とコメントしてくれました。
これは確かになぁと思いますね。デュエルリンクスやタッグフォースをイメージするとわかりやすいかもしれません。「蜘蛛の糸」が仮にゲーム上で実装された場合、タッグフォースだと5,000枚以上のカードに「蜘蛛の糸」の効果処理を施さないといけないことになります。デュエルリンクスにしても新しいカードが追加される度にこの効果を全てのカードに適用するとなると膨大な時間と労力がかかり、更新ペースが遅くなりそうですよね・・・。
運営としても過去のカードのせいで新しいカードに負担が掛かるのは望ましくありません。こういったバランス調整も運営としては重要視しなければならない点ですね。
「第2回 遊戯王アニオリカード ヤバさ考察選手権 」いかがだったでしょうか。今回のカードは前回ほどインパクトはなかったかもしれませんが、ゲームを作る運営側にとっては勘弁してくれ・・・といったものでした。
Beyond the fieldではこういったユーザーではなかなか分からないような内部事情というものも積極的にユーザーに知っていただき、ゲームをプレイしていただく皆さまにもよりカードゲームを好きになってもらいたいと思っています。
そういった意味でもまだまだこの企画を書いていきたいと思います！
それでは第3回のヤバさ考察選手権でお会いしましょう！！
第1回記事も良ければご覧ください！
beyond-the-field-tcg.hatenablog.com
Beyond the fieldの情報はブログとTwitterにて、随時更新していきますので、ブックマークとフォローをよろしくお願いいたします。
Beyond the field－ルールについて
Beyond the fieldの世界へようこそ。
プロジェクトリーダーの松本です。
今回は、Beyond the fieldのルールについて説明いたします。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
【はじめに】
Beyond the fieldとは、あなたが「リーダー（解読者）」となり、魔導書のページに描かれた力を駆使して戦うカードゲームです。
【対戦について】
対戦方式は1対1。
先に相手のライフを0にしたプレイヤーが勝者となります。
【魔導書について】
20枚のページを挟むことができる特別な本です。
モンスターが描かれたページ…「ルブリック」
召喚したり、フィールドを自由に移動させたり、攻撃することができます。
建造物や風景が描かれたページ…「オブジェクト」
ルブリックの移動を制限する障害物となったり、フィールドに配置することでルブリックをサポートすることができます。
魔法が描かれたページ…「フェイント」
相手に見えない形でフィールドに配置され、
特定の条件を満たすことで様々な効果を発揮します。
【フィールドについて】
戦場となるのは、5×7マスの広大なフィールドです。
【布陣について】
バトルを開始する前に、魔導書に加えた5枚までのルブリックをフィールドに配置することができます。魔導書とルブリックの配置の仕方によって、戦術が大きく変わります。
〇圧倒的な力で敵を滅ぼす魔導書
敵陣に近いところに攻撃力の高いルブリックを全て配置し、
自陣がやられるよりも先に攻めきる超攻撃的な戦術。
〇鉄壁の守りとスピードで戦う魔導書
耐久力の高いルブリックで自軍を固めながら、
移動が速いルブリックで相手を翻弄する戦術。
〇遠距離攻撃を生かした魔導書
耐久力の高いルブリックの後ろから、遠くの敵を攻撃することができるルブリックで追い打ちを狙う戦術。
【おわりに】
「魔導書」「広大なフィールド」「布陣」の3つの要素が組み合わさることで、「選択肢」がかなり広がり、毎回違ったドラマを生み出します。
敵の布陣を見て、どこから攻め込むのか、自分の布陣をどうやって守るのかを考えながら戦う戦略性の高いカードゲームです。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
いかがでしたでしょうか。
少しBeyond the fieldについてイメージできましたか。
今回はざっくりと説明させていただきましたので、まだ謎の部分が多いと思います。
なので、「どんな遊びだろう」と色々と想像していただけると嬉しいです。
近いうちに対戦動画をTwitterやYouTubeに投稿する予定ですので、詳しい遊び方についてはそちらでさせていただきます。
それでは、本日はここまでとさせていただきます。
Beyond the fieldの情報はブログとTwitterにて、随時更新していきますので、ブックマークとフォローをよろしくお願いいたします。
＜悲報＞アニメ遊戯王、「サンダー・ボルト」よりもやばいカードを使用していた
どうも！Beyond the field 広報のあっつーです。
今日は遊戯王アニメのオリジナルカードのヤバさについて語っていこうと思います。ただカードの説明をするだけでは面白くないので、我らがBeyond the field のチームメンバーの視点から、なぜこのカードは実装されなかったのか、またはできなかったかについてを考察していただこうと思っております。題して・・・
それでは行きましょう！！
●「虹蛇のエインガナ」
第1回目のカードはアニメＤＭでBIG5の一人、大下 幸之助が使用した「虹蛇のエインガナ」にさせていただきました。というのもこのカード、かなりのエグさを持っています。
「虹蛇のエインガナ」星7 水属性 海竜族 攻2200 / 守2400
このカードが墓地に送られた時、相手フィールド上のモンスターを全て破壊する
4月1日から制限カードに復帰する「サンダー・ボルト」。この「虹蛇のエインガナ」は墓地に送られるだけでその「サンダー・ボルト」が発動するという凶悪すぎる効果を持っています。「フィールドから墓地へ」などの指定もないため手札、デッキ等から墓地に送られても発動してしまいます。さらに極悪なことにこの効果は強制効果であるため、いかなる状況でも墓地にさえ送ってしまえば「サンダー・ボルト」発動、これはアカン。
１番簡単なのは「愚かな埋葬」でデッキから墓地に送るやり方です。これにより、おろまいが実質「サンダー・ボルト」になります（笑）
あとは海竜族を活かして「水精鱗（マーメイル）」に組み込むなど。「海皇の龍騎隊」の効果を使えば簡単にサーチもできるし、「水精鱗—サラキアビス」の効果でデッキから「水精鱗」をサーチしつつ、相手のターン中に「サンダー・ボルト」という展開阻止を行えたりもします。
他にも様々な使い道があると思いますが、これだけ汎用性が高い効果だと極悪コンボも容易に組めそうですね・・・。
ここでBeyond the field のチームメンバーでエンジニア担当のたかせの見解を聞いてみたいと思います。
「素晴らしい効果ですね。エンジニアは単純でわかりやすく、実装しやすい効果を好む傾向にあるので、このカードはエンジニアにとって理想的な一枚と言えます。
実際に実装するときは、チェーンブロックや起動効果と誘発効果の違い、「墓地に送る」と「墓地に捨てる」及び「リリースする」等の区別などのルール調整も合わせて必要なことから一筋縄ではいかなそうですが、他のカードでも必要な仕組みだと考えれば素晴らしいことに違いはありません。Beyondにもこのようなカードをぜひ追加していきたいですね。」
これを聞いて正直驚きを隠せませんでした。僕のようなユーザー側からするとこのカードを見たら「いやいや・・・ないだろ」って思っていたのですが、ゲームを作るエンジニアからするとこんな視点でカードを見ているんだと感心させられました。
今回紹介させていただいた「虹蛇のエインガナ」、いかがだったでしょうか？おそらくこの記事を読んでいただいた大半の人が「いや、こんなモン実装したらイカンって・・・」って気持ちなんじゃないかなと思います。ただ「サンダー・ボルト」も制限に復帰することもあって、1枚程度なら今の環境を大きく動かすことはなかったりするのかな？そう考えると現環境恐ろしすぎる・・・（笑）
Beyond the fieldでは他にも多くのカードゲームについて実際にプレイを行なって分析し、より良い最高のカードゲームを作りたいと思っています。コンセプトは「終わらない楽しみを提供する」ことですからね。その一環として今回このような記事を書かせていただきました。この企画はシリーズ化したいとも思っていますので、皆さんのお暇つぶしに楽しく読んでいただけたらと思っております。
それでは、次回の記事でお会いしましょう！！
Beyond the fieldの情報はブログとTwitterにて、随時更新していきますので、ブックマークとフォローをよろしくお願いいたします。
コンセプトアートを描いた話 - デザイン開発誌 #1 -
こんにちは、下原です。
今回は↓の画像、Beyond the filedコンセプトアートを描いた話をします。
Beyond the field コンセプトアート『起動する世界』
コンセプトアートって言えばなんかカッコイイ響きで、画像検索してもなんか壮大なカッコイイ絵が出てきますよね。
そんなもんだから僕もコンセプトアートがなんなのかもよくわからず就職活動の時に「コンセプトアーティストになりたいです！」とか言ってました。その企業は余裕で落ちましたね。
コンセプトアートってなんやねん
僕の認識では「アートの企画書」です。多分。 漫画でいうとネーム、アニメでいうと絵コンテとかキービジュに近いと思います。どうしてもコンセプトアートは工程上最初に作らないといけないようです。理由としては、
- 世界観を固める
- 「こんなことがやりたい」を形にする
- メンバーで認識を共有する
- 開発メンバーのモチベーションを上げる（重要）
とかとかだと思います。ぶっちゃけた話、「コンセプトアート」とかカッコつけた言い方してるせいで意味が曖昧になってますよね。「イメージボード」とか「コンセプトイラスト」とかの方が僕的にはしっくりきます。
描いてみる
必要なんでとりあえず描いてみます。
iPadProとProCreateを買ったのでそれで超適当にラフを描きました。
なんか色々雑なのがわかりますね。 ゴーレムとか何の資料も見ずに描いたのでよくわからないデザインしてますね。。
まぁけど大体やりたいことがなんとなく自分の中で整理できました。企画考えるときのホワイトボードのメモみたいなヤツです。
- 中心にプレイヤーが居て魔導書の光でルブリックを使役している
- 広大なフィールド（5×7のマス）
- 相対する巨大ルブリック（対戦）
- フォグ感出して壮大に
ここからはちゃんと描いていきます。一回グレースケールで描き切って、上から色を乗っけるよくあるフローです。色塗るのがホント僕苦手で、「いい感じになるまで色を乗せたり引いたりを繰り返す」という力業でいつも色塗りしてます。。。なんかいい方法ないですかね・・・。
ぶっちゃけデッサンとかパースとかどうでもよくね？
僕の結論はコレ↑です。雰囲気でいいんですよ雰囲気で！大事なのは「やりたいことが絵を見た人に伝わること」だと思います。
それではまた。頑張って開発進捗させます。
Beyond the fieldの情報はブログとTwitterにて、随時更新していきますので、ブックマークとフォローをよろしくお願いいたします。
