Should I learn Blueprints or C++ first in Unreal Engine? 節點式軟體混合程式碼的學習經驗
This article mainly discusses the journey of transitioning from node-based software to coding, and then blending node-based software with coding. 本篇主要是節點式軟體到Coding再混合節點式軟體的心路歷程！(好繞口令)
中文版請往下拉
Before diving in, let me confess—this article has absolutely nothing to do with Blueprints or C++! If you accidentally clicked in, please don’t blame me. Broadly speaking, this is about my learning experiences with node-based software and coding. If you're curious, read on!
Recently, I’ve been working on an automatic building generation system using the Procedural Content Generation Framework in Unreal Engine, which is essentially a node-based system.
Since I couldn’t find any tutorials or guides on certain functionalities, I had to resort to keyword searches, documentation, and experimentation. That’s when I had a sudden epiphany:
"Wow, I can actually read documentation now!"
Engineers might laugh at this revelation, but hold on—coming from an art and design background, reading documentation doesn’t come naturally to most of us.
So, how did this transformation happen?
⛳Background
Time for a little backstory. Let’s rewind to my early encounters with node-based software.
Node-based software is designed around “nodes” that execute program logic or process data. It visualizes workflows through interconnected nodes, allowing users to design systems by dragging, dropping, and connecting them.
My first exposure was Grasshopper, a parametric design tool used in architecture. It enables dynamic design by controlling parameters through visual programming, generating innovative forms and optimizing structures.
Grasshopper was a course elective. Back then, we didn’t have GPT to ask for help, and even Googling required a knack for searching (which I sorely lacked). Some of my classmates were incredibly skilled and have even become engineers now.
At that time, my work barely scratched the surface of the software's capabilities.
Since then, I’ve also explored tools like Max/MSP, Unreal Engine Blueprint, Substance Designer, and Houdini.
Here’s my timeline of learning these tools (rough estimate):
Grasshopper (Years ago; forgot 90%)
Max/MSP/Jitter (Years ago; completely forgotten)
Unreal Engine Blueprint (3 years ago; no practical use, forgot everything)
Substance Designer / Unreal Engine PCG (1 year ago; practical application)
Houdini (6 months ago; practical application)
Despite an early start, my learning was mostly superficial until the rise of AI, which significantly lowered the learning curve for both node-based software and coding.
For instance, when querying Houdini's nodes (SOP) versus its native coding language (VEX), AI's responses for VEX are more accurate, while its node-related suggestions are often wrong.
⛳Why Coding Became Essential
The rise of AI sparked a turning point. While AI tutors have made learning easier (and don’t lose their temper!), they still have limitations. Node-based systems are graphical, and AI—being text-oriented—often provides incorrect or non-existent node-related answers.
So, I started to learn python.
Each node is like an ingredient or a piece of kitchen equipment: pre-cut vegetables, pre-processed meat, or tools like blenders and ovens. You don’t need to know how the vegetables were grown or the internal workings of the blender; you just need to know how to use these "modules" (nodes) to combine and process them into the dish you want.
This is where coding comes in. By learning even basic programming, I was able to:
Speed up research
Write more precise prompts
Solve simple bugs independently
Take the PCG system I mentioned earlier. After half an hour of scouring YouTube and articles for a node to fetch specific attributes from a Data Asset, I began thinking like an engineer:
"What keywords, variables, or class names might I use?"
Sure enough, I found the answer in the documentation, went back to the PCG Graph Node, and implemented it.
Ultimately, I still rely on node-based systems. I’m like a chef who doesn’t know how ingredients are grown or how a blender works but can still use pre-prepared components to whip up a dish.
⛳Why Learn Code? A Creator’s Perspective
Learning to code has helped me think like a creator when using node systems. It’s easier to infer the meaning behind node names and their functionalities.
Currently, coding is a big part of my daily learning. But my projects still heavily rely on nodes, especially in Houdini. (Some Houdini nodes don’t even work in Unreal Engine without coding!)
To summarize: coding allows you to understand the underlying logic of node systems, making you a better user and designer.
⛳Node-Based Systems or Coding First?
If you’re like my younger self:
Lack motivation without tangible results
Get sleepy when reading pure text
Struggle with logical thinking
Are bad at organizing information
Starting with node-based systems might be a good choice. Nodes are visual representations of code and are generally simpler to categorize. Coding, by contrast, involves planning complex system architectures, which can be overwhelming.
That said, if you have the capacity, I’d recommend starting with coding.
With AI’s assistance, coding is no longer an insurmountable challenge. It eases the burden of finding and filtering information. Understanding code provides deeper insights into node systems, and once you pass the initial learning curve (0–1), expanding your knowledge (1–10) will be much faster than starting with nodes.
正文開始前要先自首整篇跟藍圖還有C++完全八竿子打不著邊，如果不小心點進來請不要罵我！廣義上來說，本文討論節點式軟體跟程式碼的學習經驗。如果有興趣的話再往下看。
最近正在製作PCG的自動建築生成系統。(全稱Procedural Content Generation Framework in Unreal Engine) 本身是一個節點系統。
因為有些功能找不到懶人包或是油管教學，開始搜尋關鍵字看文件找做法。我突然意識到：「天啊！我也是會看文件的人了！」工程師看到這邊可能會笑出來。且慢！對於一個藝術設計背景的人(大部分)，這可不是一件容易的事。
這個轉變是怎麼發生的？
⛳背景介紹
講古時間到。得先回溯我的節點式軟體不解之緣。
節點式軟體（Node-based Software）是一種以「節點」為基本構建單位來執行程式邏輯或處理數據的軟體設計模式。這種軟體通常透過視覺化的方式，將程式的邏輯流程呈現為節點之間的連接關係，使使用者可以透過拖放節點和建立連線的方式來設計系統的功能。
我的第一套接觸的節點式軟體是Grasshopper。它是建築參數化設計工具，利用視覺化編程控制參數，快速生成創新形態，實現結構優化與環境分析的動態設計。
Grasshopper是系上的選修課。回想那個年代沒有GPT可以問，就算是網路上查資料也是要有些慧根(理由伯是我)，有些同學很厲害，甚至現在還成為了工程師。
當時的作品，停留在基本的理解。
接下來快速帶過，隨後接觸了Max/MSP、Unreal Engine Blueprint、Substance Designer，以及Houdini等工具。
時間軸(學習起點，運用程度)：
Grasshopper (N年前，忘90%)
Max/MSP/Jitter (N年前，忘光)
UE Blueprint (3年前，十小時課程沒有實際運用過，忘光)
Substance Designer / UE PCG (1年前，有實際產出運用)
Houdini (半年前，有實際產出運用)
雖然接觸的時間早，但過去的學習多停留在基礎，直到AI技術的興起，學習節點式軟體和程式碼的門檻逐漸降低。
這是一個契機，學習的難度變低了，有專屬的Tutor也不用擔心她會發怒。但AI還是有其極限：節點式軟體是圖像化系統。在以文字為主體的AI，詢問節點式相關功能時AI經常錯誤。
比方來說，Houdini中詢問節點(SOP)跟VEX(Houdini原生Coding)功能，VEX的正確度明顯高於詢問節點(SOP)。AI甚至常常回應根本不存在的節點！(氣)
⛳學習程式碼的目的
學程式碼的動力來自AI工具對節點式軟體的錯誤解答。當我嘗試尋找資料時，發現學會基本程式碼可以加速資料查詢，並更有效地使用prompt解決問題。
所以我開始學python
為什麼是python不是本篇的重點，有機會再討論。因為了解了基本的程式碼之後，在搜尋節點式軟體的功能時，變得輕鬆很多！畢竟節點就是封裝後的程式碼。
每個節點就像一道菜的食材或廚具：切好的蔬菜、已經處理過的肉類，或攪拌器、烤箱等。你不需要知道每個食材是如何種植的，或者果汁機的內部構造，只需要知道如何使用這些「模組」（節點）來組合和加工，做出你想要的菜。
我接觸程式碼的時間很短，我的目的有三點：
加速查找資料的時間
精準下prompt
有能力自行解決簡單bug
回到前面第一段PCG系統。就在我翻了半小時油管或文章什麼節點可以取得Data Assest的特定Attribute後。我開始想像如果我是工程師，我可能取什麼關鍵字變數或Class名稱。最後順利的在文件裡找到相關資料，再回去PCG Graph Node。
不過最終還是回到節點系統。畢竟我現在依舊是那個不知道菜怎麼種、果汁機內部構造是什麼的人。但我的大腦神奇地帶我開始使用其他的prompt來引領我找到需要的答案。
⛳持續學習程式碼。但實際產出依舊依靠節點系統。
目前學習程式碼是我生活中很重要的一部份。但實作依舊是節點為主。尤其在使用Houdini上幫助非常多。(甚至有些Houdini節點進到Unreal Engine是無法讀取的，必須使用程式碼。)
這邊想斬釘截鐵地說：學習程式碼是能夠以造物者的角度去思考節點系統，也更容易猜到各個節點的取名背後代表的意義。
⛳先節點？先程式碼？
如果你跟早期的我一樣：
沒有看到實際作品產出會沒有動力的人
看到純文字易睏
對邏輯能力沒有信心
整理東西的能力很弱
那先學節點或許是個好選擇。它具象化了程式碼，在分類上也較為程式簡單。程式的系統架構規劃真的很難。現在也漸漸在寫簡單的程式碼中找到了樂趣。(太難的話我頭頂會物理性頭痛)
但是能力允許的話，我覺得先學程式碼是比較好的選擇。
現在有了AI的輔助，直接學習程式碼不再遙不可及。AI減輕了孤軍奮戰找資料、過濾資料的障礙。而程式碼對理解節點系統的幫助更深遠，若是能夠撐過前期0-1的過程，後面要擴展到1-10會比起先學節點快速很多。
✨今天就紀錄到這裡。下一篇的文章應該是PCG自學資源以及過往使用PCG的內容。
「nnsense」 是 nonsense 和 no sense 的結合。亦是「沒有美學的角落」，帶著積極的意涵的 no sense。
基本上，這裡是我個人的日記空間。但或許你也能意外地找到一些對你有用的資訊，通常是3D相關的。
很高興你來到這個角落閱讀我的文章。
我們下一篇文章見！