1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

1週間UnrealEngine nvimプラグイン群を使ってみた感想

Posted at

Neovimを本物のUnreal Engine IDEにするために、この1週間でしたこと

こんにちは。自作しているNeovimのUnreal Engine用プラグイン群を本格的にドッグフーディングし始めて1週間が経ちました。

今回は、その中で見えてきた課題と、それに対応するために行った改善、そして現在の私の設定を共有したいと思います。

最初の結論:ULG.nvimが使いにくかった

実際に自分で毎日使ってみて、まず突き当たったのがこの感想でした。

ULG.nvimが絶望的に使いにくいし、そもそも機能が足りなかったです。

ログを見るためのプラグインなのに、肝心の機能が不足しており、これでは常用できないと感じました。そこで、この1週間で以下の点を重点的に修正・機能追加しました。

ULG.nvim に加えた改善点

  1. ビルドログのエラー箇所を色分け
    エラーやワーニングの行に色を付けることで、大量のログの中でも問題点を視覚的に素早く把握できるようにしました。

  2. エラーログから該当ソースへジャンプ
    ビルドエラーが出力された行から、ワンタッチで該当のソースファイル・行番号へジャンプできる機能を追加しました。IDEの基本機能であり、必須の改善でした。

  3. Live Coding ログへの対応
    Unreal Editorを起動したままC++コードをコンパイルするLive Codingは、開発サイクルを高速化する重要な機能です。このログをULG.nvimで表示できるように、以下の対応を行いました。

    • ログファイルをリアルタイムで監視する処理(tail)の改善。
    • ランチャー版とソースビルド版のEngineで異なるログパスに両対応。
    • ユーザーが設定でログファイルパスを直接指定できる機能も追加し、特殊な環境にも対応できるようにしました。
  4. stat系コマンドのサポート
    stat fpsstat unit といったコンソールコマンドを、Unreal Editorのログウィンドウ以外からでも直接実行できるように、専用のコマンドを追加しました。

これらの対応によって、ULG.nvimは格段に実用的なツールになったと思います。

現在のlazy.nvim設定とワークフロー

上記の改善を踏まえ、現在私が使っているUEP.nvim関連のlazy.nvim設定は以下のようになっています。Unreal Engine開発に必要なプラグインを一括で管理しています。

-- lua/plugins/unreal.lua

local is_open_ui = false
return {
  -- UEP.nvimは開発中のためローカルパスを指定
  dir = '~/Documents/git/UEP.nvim/',
  dev = true,

  -- C++/Cファイルを開いたときにロード
  ft = { "cpp", "c" },

  -- コマンドでもロードできるようにする
  cmd = { "UEP" },

  -- キーマップでもロードできるようにする
  keys = {
    { '<c-f>', '<cmd>UEP files --all-deps<CR>', mode = 'n' },
  },

  -- 依存プラグイン
  dependencies = {
    "j-hui/fidget.nvim",
    "nvim-telescope/telescope.nvim",
    "taku25/UNL.nvim",
    "taku25/UBT.nvim",
    "taku25/UCM.nvim",
    "taku25/USH.nvim",
  },
  opts = {},
  config = function(_, opts)
    require("UEP").setup(opts)

    -- ヘッダー/ソース切り替え
    vim.keymap.set("n", "<leader>a", function()
      require("UCM.api").switch_file()
    end, { noremap = true, silent = true })

    -- スマートなビルド / ライブコーディング
    vim.keymap.set("n", "<C-s>", function()
      local unl_api = require("UNL.api")
      -- UnrealEditorのプロセスが起動しているかチェック
      unl_api.is_process_running("UnrealEditor", function(is_running)
        if is_running then
          -- 起動中ならLive Codingをトリガー
          require("ULG.api").remote_command("livecoding.compile")
        else
          -- 起動していなければ通常のビルドを実行
          require("UBT.api").build({})
        end
      end)
    end, { noremap = true, silent = true })

    -- IDEライクなUI自動起動
    local open_ui = function()
      if is_open_ui == true then
        return
      end
      local project = require("UNL.api").find_project(vim.loop.cwd())
      if project and project.root then
        require("UEP.api").tree() -- neo-treeでプロジェクトツリー表示
        require("ULG.api").start()  -- ログウィンドウ表示
        is_open_ui = true
      end
    end

    vim.api.nvim_create_autocmd("FileType", {
      pattern = { "cpp", "c" },
      callback = function()
        open_ui()
      end,
    })
    open_ui()
  end,
}

この設定のポイントは以下の通りです。

  • ファイルタイプによる遅延ロード: C++/Cファイルを開いた時に、Unreal Engine関連のプラグインをまとめて読み込んでいます。
  • IDEライクな自動UI起動: .uprojectが存在するディレクトリ内のC++/Cファイルを開くと、自動的にneo-treeのUEPソースとULG.nvimのログウィンドウが起動します。この処理は少し重いですが、IDEを起動するよりはずっと速いので、快適です。
  • ヘッダー/ソース切り替え: <leader>a.cpp.hファイルを瞬時に切り替えられるようにしています。
  • スマートなビルド/ライブコーディング: <C-s>を押すと、Unreal Editorのプロセスが起動しているかを判定し、起動中ならLive Codingを、そうでなければ通常のビルドを実行します。これにより、状況に応じて最適なビルドアクションを一つのキーで行えます。

実際のライブコーディング風景

Unreal Editorが起動している状態で、Neovimから<C-s>を押してLive Codingをトリガーする様子です。
20251003180531_rec_-convert.gif
これで、日々の開発が少しは便利になったかなと思っています。

新展開:USH.nvim の作成

また、最近Redditでushellという公式の対話的シェルがあることを教えてもらい、早速USH.nvimというushellをNeovimから使えるようにするプラグインも新たに作成しました。

これについては、また近いうちに別の記事で紹介したいと思います。

おわりに

まだまだ改善の余地はありますが、NeovimをUnreal Engine開発のメインIDEとして使うための環境が、着実に整ってきました。
では、皆さんも素晴らしい "Unreal Engine on Neovim" ライフを!乾杯!


相も変わらずneovim 用unreal engine用プラグイン群の記事です。
今週もGoogle AI Studioにお世話になっていたのですが、以前は40万トークンくらいまでサクサク動いていたのに今週は10万トークンでも結構重くなってしまったので。この記事とプラグインのお手伝いはgeminiにしてもらました。
一か月くらい前のgeminiと比べるとソースの制度もあがった?という感じでとてもくうれしい反面、ゲーム企画書を書こうとgeminiとブレストしてたらgeminiは課金してもgoogle スライドを直接編集できなくてgoogle workの方にも課金しないとダメなのかなぁーという事実に打ちのめされてます。
gimini, github copilot, jetbrainに課金してるのにまだ課金しないといけないのかぁー思っている著者

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?