這是一個大佬使用 C/OpenGL/Cmake 復刻 MineCraft 的項目。在某些方面，它做得挺屎，比如它會在單個 main.c 文件裏堆上30來個函數，這些函數之間相互關聯，難以解耦（也可能是大佬想把它快快做完，好趕去玩別的～）。但另一方面，它在目錄規劃上挺值得借鑒（ 你甚至還可以學一學它的 CMakeLists.txt 文件的寫法... ）

抄到合適的項目格式後，可以先停頓一下，拿這個項目框架，去編寫幾個小工具。在實踐中，加深對項目格式的理解。不出所料的話，你很可能會遭遇 編譯鏈接 方面的問題，這其實也是一個暗坑：

鏈接（Linking）著名三不管地區～ 語法書們覺得這玩意兒不屬於語法，所以不講。環境庫的書覺得這種東西你應該懂，所以也不講。再加上它本來就有點神祕，如果之前的你都是在幾個很小的 .h .cpp 文件裏堆代碼。相信我，當遭遇鏈接問題時，你會一臉懵逼。

這種時刻，最好的辦法就是看書查資料，比如《深入理解計算機系統》(3th) 中的第七章。或者：

當然，如果你為了跨平臺而投奔 cmake，那將是另一段磨難... (鑒於知乎 cmake大佬太多，而我在這方面又特菜，就不擺弄了...

最後的最後，如果你特別懶，並不想去琢磨別人的項目到底是怎麼搭出來的，不妨去 GitHub 搜索關鍵詞：「cpp empty project」(或類似的詞)。其實 已經存在很多現成的模板。在這裡，我也提供一份我自己的：

（夾帶私貨時間～）

這是一個 基於 cmake/C++17 的跨平臺空項目。從上面那個遊戲項目 tprpix 整理抽取而來。你可以在這個空項目基礎上，搭建出你自己的跨平臺程序。（具體食用方式已經寫在項目中，在此略過...

2.選擇圖形庫

遊戲的一個核心模塊就是 畫面呈現。你可以直接使用功能便捷的圖形界面框架，比如 QT。或者底層的圖形庫，比如 OpenGL, DirectX。不管選擇哪一種，這些圖形庫的使用方式，都會影響你的 主函數，主循環的編寫格式。

所以，請在項目開始的第一階段，確定好自己使用的圖形庫。

在這裡，我以 OpenGL 為例。你可以直接根據這個教程來入門圖形學。順帶學習如何搭建一個 OpenGL 視覺交互程序：

圖形庫方面的代碼有個特點，就是它們的編寫格式往往是固定的。直白地說就是：你在項目前期勞煩下，把這些代碼理解透，然後封裝進你自己寫的模塊中、排布進你的遊戲主循環中，然後就不大需要改動它們了（唯一需要開放出來，以便時刻添新的就是 shader 代碼了）。也許，未來某天，當你領悟了更好的設計方法，你會回來重構。但整體上，你應該在遊戲製作的前期，就把這些東西確定下來。

如果你希望你的遊戲有驚人的畫面表現，也許你該停下來，深入挖掘下圖形學方面的知識。不過，做出一個遊戲需要投入的的方面有很多，視覺只是它的一部分。

3.主函數 和 主循環

遊戲的本質就是一個 時刻等待玩家輸入的交互程序：

遊戲程序啟動，優先執行各個模塊的初始化。然後跌入一個巨型的 while 循環中，以每秒60幀（或更多）的速度，反覆執行 while 體內的代碼。直到某一刻，玩家的某個輸入觸發exit事件。然後正式退出 while 循環。在執行一系列收尾工作後，徹底關閉遊戲進程。

這麼一看，一旦搞定了 主函數 和 主循環。遊戲框架似乎就出來了。我的建議是，項目前期請使用最簡單粗暴的方式來實現，比如：

int main( int argc, char* argv[] ){

// &
// init modules
// ...

// &
// Main Loop
while( !exit() ){
//...
}

// &
// end everything
// ...

}

要麼照著圖形庫教程傳授你的格式去搭，也是完全夠用了。或者說，這也許是更值得推薦的方法。如果你真的跟著那些圖形庫教程一路走下去，你會發現，它們已經教會你如何去搭建一個合格的 視覺交互程序。在這個交互程序的基礎上，再往前多走兩步，將它塑造成一款遊戲，是件自然而然的事。

回到 主函數 和 主循環。如果你想把這部分做得更考究的話，不妨閱讀下這兩篇文章：

4.遊戲模塊

一個遊戲，到底該被劃分成哪些模塊呢？

此時不妨去看看 正經的遊戲引擎是怎麼設計的，比如 unity3D。你可以借鑒一下它的設計思路，結合自己的遊戲內容，設計一組功能相似的模塊。（可以是簡化版，合併版，只要能滿足你的遊戲就行～）

好吧，這一段我講得有點敷衍。但怎麼講呢：為自己的遊戲，親手實現一些功能性模塊，其實是非常快樂的過程。如果說，在處理上文提及的圖形渲染方面的代碼時，你還有點畏手畏腳的話（畢竟大家都是第一次）。那麼現在，當你開始寫功能性代碼時，你就可以像對待一個純粹的程序那樣，去組織，去實現它了。用上你在 C++ 和其他書裏學到的所有知識：放開腦洞，埋頭填坑，停下總結，然後再翻工重寫...

5.在實踐的過程中強化 「bypass」 思維

好吧我承認，這個概念是我自己編的。若有發現更專業的描述，還請告訴我...

當你正式開工，並且推進了一段時間後。你可能會失落地發現，有些模塊的製作工期實在太長了。有些模塊則相互依賴，在所有依賴模塊都完成之前，你就是無法看見你的程序運行的樣子。這種體驗使人沮喪，在你撐到最後一刻之前，你的意志力已經被消費光了。我的建議就是：搭建微型的 旁路系統（bypass）

怎麼講呢，假設你正在寫一個模塊 A，而 A 還依賴於另一個模塊 B。而這個 B，你其實一行代碼都沒寫呢。傳統的方法當然是把兩個都寫完整後再跑。但這個依賴關係可能很長，不只是 A 和 B 這麼簡單。 此時的你不妨嘗試：搭建一個空架子的 B，它暫時什麼也不幹。但它的一些介面函數，切切實實聯通到了大流程中。（就像原初設計的那樣） 然後就拿著這個看起來像是被故意短路了的程序，去測一測跑一跑了。（當然，並不是真的短路到沒法運行，而是功能上的短路）

隨時隨地的反饋是很有必要的，它是你堅持下去的動力源

當然，以上只是一個很簡陋的例子。放大了講，萬物皆可被 bypass。以各種靈活的方式。

6."能跑的輪子就是好輪子"

(註：沒有對輪子哥的不敬，輪子哥是我偶像～)

這其實也是 bypass 思維的一個變種：一個簡陋的，但能正常運行的模塊，就是好模塊。不要擔心第一套方案設計得不夠完善。隨著項目的推進，經驗的積累，你還可以回來重寫嘛～（捂臉）

（廢話先到這裡，未來再來補充....）

這個簡單啊。

你既然問C++了，那我問你，現在，我有一個Student類。C++怎麼創建一個學生類的對象？

// 嗯我會！有兩種方式：
Student s;
Student *s2 = new Student("張三");


那好，現在這學生的行為有：喫飯，睡覺，上網課。現在你執行個上網課的行為，怎麼做？

// 簡單啊
s2-&>upNetworkClass();


通過對象調用成員函數不就成了麼。

嗯，上面的代碼在學校裏都寫過吧？有這個基礎就夠了。

那遊戲是啥？無非是一堆圖形堆疊唄，把上面的Student類換成窗體類，換成控制項類，換成遊戲中不同的元素類，然後再組合起來不就完了麼。

吶現在，我告訴你，有一個窗體類，叫QWidget，它有一個行為叫show，可以顯示窗體。你給我生成一個窗體並顯示出來。那就照葫蘆畫瓢唄：

QWidget *w = new QWidget();
w-&>show();


來我們看看效果：

呀，有點意思哈？但是這距離遊戲還差遠呢啊。 你這窗體也太醜了不是。

沒事，窗體醜不要緊，我們給她美化一下！

TDWidget * w = new TDWidget(":/img/welcome.png");
w-&>show();


QWidget換成了TDWidget，構造函數裏傳了一張圖片，沒超綱吧。再看看效果：

誒？事情好像開始變的有趣了起來？

但還是不夠，我這是遊戲，要交互的！你這一張死圖能幹啥。

交互嘛！加個按鈕不完了？我給你一個按鈕類，這個類有一個move()行為，可以把自己移動到畫面的任何地方。你知道你想要的按鈕怎麼來了嗎？

QPushButton * btn = new QPushButton("按鈕",w); //第二個參數代表它屬於哪個窗體，如果不寫，它就會生成在屏幕上而不是窗體裏
btn-&>move(330,450);


瞅瞅：

em.......你這按鈕，有是有，畫風有點突兀了吧。

沒事，再美化一下嘛：

TDPushButton *btn = new TDPushButton(
":/img/begin_normal.png", // 常規圖片
":/img/begin_hover.png", // 滑鼠懸停的圖片
":/img/begin_press.png", // 滑鼠按下的圖片
w); // 父控制項
btn-&>move(330,450);


效果：

呀 可以啊。 快快快，然後呢，點開始遊戲，進入遊戲界面！這個咋做？

嗯.....其實界面切換你自己已經會了。

你這個界面不就是一個窗體，想切換界面的話.....你把這個窗體關了，再換張圖片開一個新的不就完了。

新的窗體用一張傳新的圖片做背景，我再順手給加上四個按鈕，代碼不貼了，就是上面的代碼複製粘貼改改坐標，改改圖片：

接下來就是遊戲的主體部分了，也巨簡單，有圖就行：

TDMenuButton *btn1 = new TDMenuButton(":/img/1_normal.png",":/img/1_hover.png",":/img/1_selected.png",this);
btn1-&>move(100,100);
TDMenuButton *btn2 = new TDMenuButton(":/img/1_normal.png",":/img/1_hover.png",":/img/1_selected.png",this);
btn2-&>move(165,100);
TDMenuButton *btn3 = new TDMenuButton(":/img/1_normal.png",":/img/1_hover.png",":/img/1_selected.png",this);
btn3-&>move(100,165);


三個按鈕，和上面的TDPushButton沒區別，就是換成了TDMenuButton對不對，沒超綱吧。

只要你的圖片夠美，就能生成這樣：

一個按鈕會寫，三個按鈕自然也會寫，既然學了點C++都想做遊戲了，循環總會寫吧：

for(int i = 0; i &< 11 ; i++) { for(int j = 0; j &< 6; j++) { TDMenuButton * btn = new TDMenuButton(":/img/1_normal.png",":/img/1_hover.png",":/img/1_selected.png",this); btn-&>move(100+i*65,100+j*65);
}
}


效果：

多空幾行，密恐福利：

這.....怎麼還有點一言難盡呢......

循環會寫，隨機數會寫嗎？ 隨機個頭像行嗎？

嗯......這下終於像點樣了。

最後再加億點點核心邏輯：點擊兩個相同的圖片，判斷它能不能連通，如果能連通，就把這兩個按鈕直接delete掉，效果就是醬紫：

就是這樣咯，從你學過的C++基礎語法，結合現有的框架控制項，就可以擼這樣一個簡單的連連看。

當然了，為了點燃你題目裏想要的學習熱情，我故意避開一些以你現有知識可能聽不懂的部分，還有一些邏輯比較繞的部分。比如：

避開了註冊按鈕的回調，

避開了隨機生成圖片的時候要保證成對出現的演算法，

避開了把這些按鈕和數據做關聯，

避開瞭如何通過數據計算兩點能否連通，

等等

但這都不重要，不妨礙你簡單體驗一下C++是如何從代碼到遊戲的這個過程。

從圖片素材上你們也看出來了，這代碼是兩三年前的，那個時候還在做培訓機構的輔導老師，學生們愛打遊戲，不好好上課，就做的這個上課帶她們寫。

王者榮耀風格的連連看?

github.com

因為本身我不打榮耀，所以裡面的頭像確實一個也不認識，都是那時候為了勾引學生好好上課，現在遊戲裏的頭像應該有不少都更新好幾茬兒了。

這個玩意兒是用Qt C++寫的。因為本身對幀率沒什麼要求，所以基於Qt就可以搞。如果要玩一些真正的遊戲（畫面需要幀率級別的刷新的），一定要上遊戲引擎寫的。cocos2d unity3d 什麼的。

當然，我上面說「遊戲無非是一堆圖形堆疊唄」只是為了講解故意壓低一下難度，真正的遊戲開發是非常複雜龐大的。

這個小項目確實像上面寫的一樣，用了大量的TD開頭的控制項。這個源自於我的一個開源框架叫做TD-Framework

TD框架使用手冊?

www.threedog.top

因為我叫三級狗（ThreeDog）所以控制項普遍用TD開頭。Qt本身沒有提供這種直接用圖片構造控制項的方法，所以就自己造了一些。

寫下它的時候還是大四剛畢業，那時候我還把這玩意兒叫框架，現在... 我覺得還是叫玩具更合適些：跨平臺編譯不過，函數指針強轉有問題，代碼也寫的亂七八糟....

---

其實你題目上的這個困惑：（到現在為止，老師也只會教你如何寫代碼）大家都是一樣的，而且很遺憾的告訴你，不只是到現在為止，一直到你畢業，你在學校上課學的東西可能也僅限於黑框框裡面列印點東西。至少用C++只能這樣。

我大學的時候和你一樣，我比你還急，語法沒看利索就去摸cocos2d了，對著視頻吭哧癟肚地搭環境，把視頻暫停下來抄代碼，有一個地方有出入就跑不起來，對著報錯一難過就是一整天。

那時候寫代碼僅限於：這麼寫可以實現這個功能，然後我照著這一句改吧改吧實現我的功能。

一開始都是這麼過來的。

回過頭來看這個過程還是收穫挺大的，硬著頭皮折騰了這些東西，回過頭再學基礎的時候發現理解多少會有點不一樣。

這幾天我在研究函數指針和std::function的時候又翻到了cocos2d的源碼。突然發現不光網上的小遊戲的代碼，cocos2d框架本身的源碼對我而言也已經不再是天書，很多地方我已經能看懂了。

突然就明白當年為什麼那樣寫可以實現函數調用。也突然就知道menuselector和CC_CALLBACK都是什麼東西 。說句沒出息的，這個發現幾乎成了我這幾天的快樂源泉。畢竟實打實的看到了自己在編程道路上的成長。

不管怎樣愛折騰絕對是好事兒，當然，大學教的那點黑框框裏的東西真的是非常非常重要的。

加油吧

---

就用我做的這個第一人沙盒遊戲（半成品）來舉例吧

這個項目最主要的部分基於irrlicht，bullet，raknet這三個庫，還使用了一些零碎的小庫，比如說leveldb,cjson這些。

整個項目就是把各種第三方庫像搭積木一樣，組合成了一個大項目。

源碼已經放到github上了

https://github.com/SingingRivulet/Smoothly?

github.com

---

很難用一篇回答說明怎樣從C++代碼一路寫出遊戲，中間涉及的知識和技術太多了。

但是換一個角度看，從基本的C++代碼開始寫出任何東西都不至於難到無法理解的程度，任何複雜的軟體都是有跡可循的。

連操作系統都能一步一步做出來，那麼像遊戲這樣並不算超大規模軟體的東西，也應該不至於難到哪裡去。

1、關鍵思想是分而治之

相比傳統工業和硬體工業的發展，軟體工業的發展極為迅速，甚至可以說神速。這表明其實大型軟體的開發相比工業而言並不那麼難，那麼軟體開發相對簡單在哪裡呢？

我認為一是編碼和試錯成本低，二是軟體可以把複雜問題分解為各種模塊，模塊之間定義好介面，每個模塊又可以繼續細分，直到分解為很容易實現的地步為止。相比之下，傳統工業受材料、重力、加工技術、磨損等現實因素影響，小問題也變得十分棘手。

假設一個人已經掌握了C++編程技術，應該如何分解模塊？簡單來說：

1. 渲染模塊。能夠在屏幕上顯示圖形。
2. 輸入模塊。能夠實時讀取鍵盤、滑鼠或手柄的輸入。
3. 主循環框架。由於大部分遊戲是實時輸入輸出的，每秒需要處理並顯示10幀以上的畫面，所以每一幀都要進行讀取輸入、遊戲邏輯、渲染三步操作，不斷循環。

想來想去，必要的模塊其實就這麼三個。從本質看遊戲就是這麼簡單。

2、從頭開始寫遊戲的困難之處

從0開始寫遊戲，對初學者來說第一個障礙就是渲染問題。如果從最底層的DirectX或OpenGL出發，需要寫好大一坨代碼，才能顯示出一個基本的三角面：

https://blog.csdn.net/fox64194167/article/details/8032551?

blog.csdn.net

有了三角面還要渲染貼圖，或者讀取3D模型數據。如果從這個層次出發，估計很多人會望而生畏吧。

所以還是靠譜一些，從封裝好的庫出發。2D遊戲相對簡單一些，C/C++常用的輕量化2D圖形庫推薦使用SDL，作為學慣用挺不錯的。

如果題主熟悉Windows窗口開發，完全可以直接用GDI繪製遊戲畫面，雖然效率很低只能做一些畫面不複雜的遊戲， 但也是簡單可行的。至少做一些俄羅斯方塊、貪食蛇或「魔塔」之類的遊戲不是問題。

當然，從顯示圖片到顯示動畫確實需要動一番腦筋。而從顯示動畫到可以控制角色移動的動畫，又更費一番功夫啦。不過這些東西確實都是用最基本的代碼拼出來的，在熟悉C++編程的基礎上都可以做到。

3、從控制檯遊戲開始

除了直接製作圖形化的遊戲，也可以考慮用彩色字元拼出好玩的遊戲——控制檯遊戲。這個時候又可以擡出咱們的專欄文章了：

皮皮關：學習編程的好方法——控制檯遊戲?

zhuanlan.zhihu.com

Linux下控制檯的操作比較容易，例如刷新、定位、顯示彩色文字都不難。而Windows下稍微麻煩一些，但把遊戲邏輯做出來還是不難的。

---

評論區有老哥覺得回答欠妥，很小心眼的懟了他並且扒了一下他的回答和點贊，編輯一下發表一些個人看法。

很多回答，扯模塊化的，扯OGL的，扯DX的，各種各樣的都有。說實話，說得都很好，都在理，都沒錯。但是你們仔細看看題，題主他能看懂嗎？回答真的切題嗎？當年懵懂的我，也是看著這樣的炫技，感嘆著大佬好強大佬好厲害！但是話說回來，這真的有營養嗎？看完能有概念嗎？

說實在的，很多回答反反覆復重複的這些東西，有點經驗的從業者有誰人不懂？在座入職的，誰不懂分而治之？誰不懂模塊化？誰不會點渲染API？？？？？？但是題主他看得懂嗎！？說人話，把頂點送顯卡渲染，小白也能聽懂，這不好嗎？？

我不懂dx嗎？我不知道vk嗎？三個現代API我全都會，gfx我都迭代寫了三版了！但是這真的是科普文短回答該有的東西嗎？堆砌這些概念來炫技，搞一堆神神叨叨的長篇大論來勸退，這就是對待新人小白的態度？這就是內卷？

答這個問題，恰恰就是因為看到題主就像看到了當年的自己。對遊戲製作對軟體開發，有興趣，沒概念，更不知道如何去做。所以從最本質的角度，隔離了一切的技術實現細節，仔細組織完善之後寫了這篇回答。

我自認為我的這篇回答，不說多麼高深精妙，清晰易懂是不過分的。但是要問我如何從int a變成模型，對不起，我實在無法作答。數據類型都驢頭不讀馬嘴，浮點的3維向量坐標你要我如何從int a講起？

非常厭惡知乎的這種風氣。戾氣很重，還請看官見諒了。

不針對分享實際工程進程里程碑的答主，我個人非常敬佩腳踏實地做東西的人，更感激他們的燈塔精神。對於題主而言，包括對於我而言，這樣的Roadmap分享非常寶貴。

---

先不要糾結於C++，找個商業引擎，摸索摸索，過一遍遊戲製作的流程。

很多回答說的很深很複雜，對於題主所說的"不可描述的技術"這點我來做個解疑。

對於遊戲來說，業務代碼不是主體，是背後各種各樣素材和數據的呈現。

不是代碼變成了遊戲，而是代碼被大量的數據（比如數值/策劃打的excel）驅動著，組織起各種各樣的美術資源（比如貼圖，模型等），在你眼前的一種展現。

---

說來可能抽象, 為了具象一點說一個實際的例子。例如呈現在你面前的這個小房子, 遊戲用到的的白模通常在建模軟體中被製作(不過這個小房子的模型應該是掃描生成的), 經由一個通用格式被導出, 文件中用你熟悉的原子類型(字元串, 浮點)描述。

它被導出為obj(一種通用格式), 內部是這樣編碼表示的:

這些一行一行前綴為v的, 就是表示模型表面頂點的位置。離散的頂點被連接成三角形, 所有的這些巨大多的三角形渲染出來就組成了你看到的這樣一個小房子。貼圖之類, 也是類似的道理。

運行時這樣一個小房子的數據被載入, 在遊戲裏經過一些額外的處置, 例如計算位置和縮放, 就可以和貼圖一起送往顯卡進行一系列空間變換和渲染了, 最終呈現到你面前。把位置和玩家的輸入關聯, 它也就可以移動了, 這也就算是一個最簡單的遊戲了。

---

不只是遊戲這樣，各種各樣的程序/軟體，本質都是處理信息，接受輸入，呈現輸出。在這點上遊戲和你的控制檯程序是並無二異的，遊戲不過是接受更為複雜的輸入（包括前面說的素材，以及玩家的控制輸入），並且多媒體輸出較多罷了。

---

推薦閱讀：