作問から公開までの流れ

Latest Author yuki2006yuki2006 /Date 2021-04-16 19:30:41 / Views 13306
19 (Favした一覧ページはユーザーページから)

writer の方が増えてきているようなので作問から公開までの大まかな流れを記しておきます。

作問から公開までの流れ

  1. 問題準備
  2. 問題完成 & 公開待ち
  3. 問題公開
  4. 問題公開後
  5. (おまけ) 他のサイトで公開

0. 必要なもの

競技プログラミングの問題を作るにあたって、最低限必要なものは次の3(4)つです。 まずはこれを自分で用意しましょう。

  • 問題文
  • writer解
  • テストケース
  • ジャッジコード (スペシャルジャッジ / リアクティブ問題のみ)

余裕があれば、これらも用意しましょう。

  • 想定誤解法
  • 解説
  • ジェネレータ

必ず一通り目を通してください。問題のクオリティが上がったり、事故が防げたり、ご利益があります。

1. 問題準備

yukicoder にログインし、右上のユーザーメニューから「問題一覧」のページに行き、「新規問題の追加」を選択します。

空の問題ページが出来るので、これを編集します。

1.1. 問題文

まずは問題名、問題文、その他設定を編集します。

  1. 問題名を入力してください。 既に yukicoder に公開されている問題とは重複しないようにしましょう。
  2. ジャンルやアルゴリズムを入力しておくと、タグ検索が出来るようになります。半角スペース区切りです。
  3. 問題文をHTMLで記述してください。
    使えるタグ/属性はホワイトリスト方式です。使えないものは保存時に取り除かれます。
    画像を使用したい場合、 こちらを参照してください。
  4. 難易度です。星の数が多ければ多いほど、高難易度を表しています。過小評価よりは過大評価の方が好まれます。
  5. 実行時間制限(ミリ秒単位)、メモリ制限(上限512MB) を設定してください。
    想定解を定数倍悪くしたぐらいがいいです。
  6. 通常 / スペシャルジャッジ / リアクティブ から選択します。
    通常問題
    一つの入力に対して一つの答えしかないタイプの問題です。 大体これ。
    スペシャルジャッジ
    一つの入力に対して複数の答えがあり得るタイプの問題です。
    構成ゲー等、 条件を満たすものを一つ出力せよ、といった問題はこちらになります。 例 : No.254 文字列の構成
    出力が条件を満たしているか判定するジャッジコードも書く必要があります。
    リアクティブ
    ジャッジ側と応答を繰り返すタイプの問題です。 ジャッジコードも書く必要があります。 リアクティブ問題一覧
  7. 幾何等、出力が小数になる場合の許容誤差を設定してください。
  8. 公開して大丈夫な状態になったら 問題完成 にします。 やっぱり引っ込めたくなったら 作問中(WIP) に戻すことも可能です。
  9. 通常のコンテストで出題するのに不向きな問題の場合、 その他問題 にします。
    その他問題の出題は、管理者に直接申し出るか、（例年は）エイプリルフールコンテストにまとめて出題されます。

1.2. テストケース

"テスト" タブに切り替えて、テストケースを設定します。

ローカルで作成したテキストファイルをアップロードしてください。 入力側のファイル名と出力側(答え)のファイル名は同じにします。
例えば入力側ファイル名が test_01.txt であった場合、 出力側ファイル名も test_01.txt にしなければなりません。
テストはファイル名順に実行されます。 TLE ノックアウト形式なので、ファイル名が辞書順で小さい方に大きいケースがあると、すぐにノックアウトされてしまう点に注意して下さい。

テストケースのファイル名で使える文字種は以下です。
(これら以外の文字をファイル名に使用するとアップロード時にその文字は消去されます。）

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz._()<>+-*^=0123456789@?

この仕様により

1_sample01.txt
1_sample02.txt
2_small01.txt
5_corner01.txt
9_large01.txt
のようなテストケース名にしていただくといいかもしれません。

また、 テストケース名に evil の文字列が含まれていると、そのケースはジャッジはされますが、最終的な判定には影響されません。ノックアウトもされません。
これは、特定の言語の標準機能ではバグなどの影響により、writerの意図しない難しさになってしまう時などに使う目的です。
ただし、問題によってはこの目的に限らずに使用しても良いです。（意図を解説ページに記載すると良さそうです）。

テストケースを設定して解答コードを提出すると、通常の公開済み問題同様にジャッジされます。 この提出コードは問題が公開されるまでは writer / tester / 管理者 しか確認することができないので安心してください。

想定解のコードを既に提出している場合、 #提出番号 を想定解として出力ケースを生成 にチェックを入れて実行ボタンを押すことで、 出力側のファイルを生成(更新)することもできます。

(生成後)この問題の提出をリジャッジ にチェックを入れて実行ボタンを押すと、全ての提出に対してリジャッジが行われます。

1.3. 解説

左上の "解説" タブ → 右上の "編集" タブ に切り替えると、解説ページの HTML を編集することが出来ます。 こちらも問題ページ表示と同様、ホワイトリスト方式です。
解説を書くかどうかは任意ですが、簡単な方針だけでも書いておくと助かります。
解説以外の事について追記しても構いません。

2. 問題完成 ＆ 公開待ち


"問題完成" に変更したら、twitter の @yukicoder にDMいただければ、空きのコンテストで出題や、すぐに公開なども可能です。

3. テスター・問題公開

誰かに tester の依頼をすることも可能です。 tester が決まったら、管理タブから tester 用リンクを生成し、tester にリンクを踏んでもらいましょう。
自分でtesterを用意する場合、出題の連絡より前にtesterをつけて大丈夫です。
個人的に誰かにお願いしたり、 yukicoder slack で公募することも可能です。 特に指定しなければ(?)募集がかけられることもあります。
作問に慣れないうちは事故が起きる可能性が高いので、testerを親身な強めの人にお願いすると良いです。

準備万端にして公開日を待ちましょう。

3.1. 問題の変更

問題の追加や変更をしたい場合もあると思いますが、

  • コンテストのURL
  • 問題のProblemId（や問題のURL）
をいただければと思います。
「僕のコンテストに問題追加お願いします」だと、運営者がいつの回か探さないといけないためです。（運営者がいつの回か覚えてないのもあれですが）

4. 問題公開後

問題公開後、事故が起きた場合（clarが沢山来た、想定解が間違えていたなど）は

の内容不足も原因だと思いますので、再発防止できそうな部分は追記してもらえると助かります。

問題公開後、Twitterなどでチャレンジケースの追加をコンテスタントからお願いされることもあります。

(おまけ) 他のサイトで公開

他所で出題も一考の余地ありです。

  • 自分でコンテストの設定が可能なサービス
    • HackerRank
      sugim48 さんの UnKoder、 camypaper さんの Saiko~ No Contesuto、 LayCurse さんの lay_contest 等もここで開かれました。
      使い勝手はあまり良くないらしい？
    • Codeforces (Polygon + Mashup Contest)
      Group 限定で非公開。 らしい。
    • コンテストサイト自作
      GCJ みたいに出力を提出するタイプならそんなに非現実的でもない。
  • 学生なら無料らしい AtCoder
  • 他writer料がもらえるサイト
    お金がもらえるレベルの問題はお金がもらえるところへ投げましょう。