簡(jiǎn)介ecosim 是一款運(yùn)行于 GNU/Linux 的交互式生態(tài)系統(tǒng)與進(jìn)化模擬器采用 C 與 OpenGL 編寫(xiě)融合 boids 群體行為、遺傳算法與生態(tài)演化思想可通過(guò)可視化窗口實(shí)時(shí)觀察生態(tài)系統(tǒng)的動(dòng)態(tài)演化適合對(duì)生命模擬、AI 演化和實(shí)時(shí)圖形編程感興趣的開(kāi)發(fā)者學(xué)習(xí)研究。整個(gè)資源壓縮包共 24 個(gè)文件大小僅約 14.32MB主體為 7 個(gè) C 源文件和 7 個(gè)頭文件覆蓋模擬核心、圖形渲染、四叉樹(shù)空間查詢與日志記錄等模塊C 代碼負(fù)責(zé)核心邏輯2 個(gè) Python 腳本用于日志分析和結(jié)果繪圖另有 Makefile、PNG/WAV 資源、README 和 LICENSE能夠支持從編譯、運(yùn)行到數(shù)據(jù)可視化的完整流程。目前已有 168 人學(xué)習(xí)瀏覽項(xiàng)目結(jié)構(gòu)清晰配置、智能體、圖形、日志等職責(zé)劃分明確體現(xiàn)了較規(guī)范的 C 工程組織方式。通過(guò)閱讀源碼讀者不僅可掌握 OpenGL 基礎(chǔ)用法和遺傳算法的落地方式還能觀察不同初始參數(shù)下的演化走向并借鑒其模塊劃分與構(gòu)建思路為自身模擬或圖形項(xiàng)目提供可復(fù)用的工程參考。 上周四晚上我在終端里敲下make ./ecosim屏幕亮起兩千多個(gè)白色小方塊開(kāi)始在暗色世界里游蕩、追逐、吞噬、分裂。那一刻我意識(shí)到用 C 和 OpenGL 在 GNU/Linux 上從零寫(xiě)一個(gè)交互式生態(tài)系統(tǒng)模擬器這個(gè)決定雖然反潮流但值了。很多人一聽(tīng)生態(tài)模擬器第一反應(yīng)是用 Python Pygame 或者干脆上個(gè) Unity 引擎。但我偏偏選了 C 和 OpenGL。原因很簡(jiǎn)單生態(tài)模擬的核心是個(gè)體數(shù)量爆炸我需要每幀處理幾千個(gè)生物體的行為邏輯和渲染Python 的解釋器開(kāi)銷(xiāo)和游戲引擎的龐大抽象層在我這里都是負(fù)擔(dān)。C 讓我能精確控制每一塊內(nèi)存OpenGL 讓我把兩千個(gè)個(gè)體壓進(jìn)一次繪制調(diào)用GNU/Linux 上的 GCC、Makefile、Valgrind 則給了我從底層調(diào)試到性能剖析的完整工具鏈。這篇文章不打算寫(xiě)成一個(gè)面面俱到的教程而是分享 ecosim 在設(shè)計(jì)和實(shí)現(xiàn)過(guò)程中的關(guān)鍵決策、核心數(shù)據(jù)結(jié)構(gòu)、渲染思路以及我踩過(guò)的幾個(gè)能讓人崩潰的坑。如果你也想在 Linux 上寫(xiě)一個(gè)類似的實(shí)時(shí)模擬項(xiàng)目這篇文章應(yīng)該能幫你省下幾個(gè)通宵。1. ecosim 到底在模擬什么一套能自我演化的生命規(guī)則1.1 從生物三要素出發(fā)定義世界生態(tài)模擬最忌諱一上來(lái)就堆砌復(fù)雜規(guī)則。我一開(kāi)始只定義了三個(gè)核心要素能量、基因、捕食關(guān)系。每個(gè)個(gè)體是一個(gè) (2D) 平面上的圓點(diǎn)攜帶一維 float 數(shù)組作為基因。基因不是用來(lái)畫(huà)畫(huà)的它直接決定行為參數(shù)最大移動(dòng)速度、感知半徑、攻擊力、代謝率每幀消耗的能量、繁殖閾值、以及捕食傾向0 表示純草食1 表示純?nèi)馐场ＤM主循環(huán)每幀做四件事移動(dòng)、進(jìn)食、繁殖、死亡。看似簡(jiǎn)單但這套規(guī)則在宏觀層面會(huì)涌現(xiàn)出復(fù)雜行為——草食動(dòng)物會(huì)聚集在食物資源附近肉食動(dòng)物會(huì)追蹤感知半徑內(nèi)的獵物當(dāng)食物匱乏時(shí)整個(gè)種群數(shù)量會(huì)劇烈震蕩。我沒(méi)有寫(xiě)過(guò)任何一行讓動(dòng)物聚群的代碼這個(gè)行為完全是基因和能量規(guī)則自組織出來(lái)的。1.2 演進(jìn)Evolution到底怎么發(fā)生演進(jìn)的核心是帶變異的繁殖。當(dāng)一個(gè)個(gè)體能量超過(guò)繁殖閾值它就會(huì)分裂出一個(gè)子代。子代的基因以 5% 的概率發(fā)生變異——某一個(gè)基因位點(diǎn)加上一個(gè)隨機(jī)偏移。剛開(kāi)始所有個(gè)體長(zhǎng)得一樣、動(dòng)得一樣但幾十代之后你會(huì)發(fā)現(xiàn)有些個(gè)體移動(dòng)更快但壽命更短有些個(gè)體感知半徑很大但代謝負(fù)擔(dān)重有些食肉動(dòng)物學(xué)會(huì)了伏擊策略其實(shí)只是攻擊力高、速度適中。這就是自然選擇在起作用環(huán)境會(huì)懲罰不合適的基因組合比如食物分布稀疏時(shí)高代謝率的個(gè)體會(huì)先餓死資源豐富時(shí)高感知半徑的個(gè)體會(huì)迅速繁殖并主導(dǎo)種群。這里有一個(gè)關(guān)鍵設(shè)計(jì)所有個(gè)體共享同一個(gè)基因數(shù)組長(zhǎng)度但不同基因位點(diǎn)的解釋方式隨物種類型而變。這樣既保持了遺傳算法的簡(jiǎn)潔性又讓肉食和草食動(dòng)物在同一個(gè)基因空間里共存。提示演進(jìn)模擬最怕的是假穩(wěn)定——所有個(gè)體快速收斂到同一個(gè)最優(yōu)解然后系統(tǒng)死水一潭。解決辦法是給變異率一個(gè)動(dòng)態(tài)范圍并在地圖上設(shè)置毒區(qū)紅色區(qū)域作為環(huán)境壓力?；蛑杏袑?duì)毒區(qū)敏感的位點(diǎn)戴上了這個(gè)負(fù)性狀的個(gè)體必須繞路走這就打破了收斂停滯。1.3 地圖和資源再生策略地圖是 (1000 \times 1000) 的虛擬空間但窗口只有 (1280 \times 720)。我沒(méi)有用簡(jiǎn)單的屏幕坐標(biāo)系而是建立了一個(gè)獨(dú)立的世界坐標(biāo)系相機(jī)視口可以在世界里平移縮放。食物資源用若干個(gè)資源熱點(diǎn)表示每個(gè)熱點(diǎn)周?chē)鷷?huì)持續(xù)長(zhǎng)出新資源。資源再生的速度是全局參數(shù)可以在運(yùn)行時(shí)通過(guò)按鍵調(diào)整。毒區(qū)用偽隨機(jī)噪聲函數(shù)生成幾塊固定區(qū)域視覺(jué)上用半透明紅色疊加層表示。2. 技術(shù)棧的取舍為什么是 C 和 OpenGL 這種老組合2.1 不用游戲引擎的理由如果你只是想做一個(gè)小 demo用 Unity 或者 Godot 確實(shí)更快。但 ecosim 的目標(biāo)不是做游戲而是研究大量個(gè)體的實(shí)時(shí)行為。游戲引擎的組件系統(tǒng)、場(chǎng)景樹(shù)、物理引擎在這里全是冗余——我不需要碰撞檢測(cè)的精細(xì)幾何計(jì)算個(gè)體之間用距離判斷就夠了也不需要華麗的粒子系統(tǒng)OpenGL 頂點(diǎn)數(shù)組足夠。更重要的是引擎會(huì)替我管理生命周期和渲染狀態(tài)但模擬器的性能瓶頸恰恰在我自己的算法上空間哈希的構(gòu)建、基因變異的隨機(jī)數(shù)生成、個(gè)體狀態(tài)的批量更新。這些邏輯用 C 寫(xiě)性能是可控的、可預(yù)期的。2.2 OpenGL 版本和庫(kù)的選擇我使用 OpenGL 3.3 Core Profile并搭配 GLFW 管理窗口和輸入、GLEW 加載擴(kuò)展。選 3.3 是因?yàn)樗銐颥F(xiàn)代有 VAO/VBO、GLSL 330又不像 4.x 那樣需要較新的顯卡驅(qū)動(dòng)。GLFW 比 GLUT 好用太多——窗口創(chuàng)建、鍵盤(pán)鼠標(biāo)回調(diào)、OpenGL 上下文創(chuàng)建一氣呵成而且它是原生 C 庫(kù)正好和 C 項(xiàng)目無(wú)縫銜接。2.3 為什么不用 C這個(gè)問(wèn)題被問(wèn)了無(wú)數(shù)次。我的回答是項(xiàng)目規(guī)模決定的。ecosim 的完整代碼在 3000 行左右嚴(yán)格 C99/C11 足夠組織好struct加函數(shù)指針可以實(shí)現(xiàn)輕量級(jí)的面向?qū)ο蠖苊饬?C 的編譯時(shí)間、模板展開(kāi)和隱式拷貝帶來(lái)的心智負(fù)擔(dān)。當(dāng)然C 在現(xiàn)代 OpenGL 項(xiàng)目中更常見(jiàn)因?yàn)橘Y源管理可以用 RAII。但在我這里個(gè)體和網(wǎng)格是連續(xù)內(nèi)存塊用malloc一次性分配手工free反而簡(jiǎn)單直接。C 的笨讓我每一步都清楚內(nèi)存在哪、生命周期多長(zhǎng)。3. 數(shù)據(jù)結(jié)構(gòu)先行個(gè)體、基因和空間網(wǎng)格的設(shè)計(jì)3.1 個(gè)體結(jié)構(gòu)體連續(xù)內(nèi)存比鏈表快一個(gè)量級(jí)直接定義typedef struct { float x, y; // 世界坐標(biāo) float vx, vy; // 速度分量 float energy; // 當(dāng)前能量 float age, lifespan; // 年齡和壽命 float genome[GENOME_SIZE]; // 基因數(shù)組 float perception; // 緩存感知半徑避免每幀從基因重算 unsigned char r, g, b; // 顏色由物種類型和基因決定 int species_id; // 0草食, 1肉食 int alive; // 0/1 } Creature;所有個(gè)體存在一個(gè)動(dòng)態(tài)數(shù)組Creature *creatures里而不是鏈表。原因很簡(jiǎn)單每幀都要遍歷所有個(gè)體、排序按 x 坐標(biāo)建立空間索引連續(xù)內(nèi)存對(duì) CPU 緩存極其友好。我在測(cè)試時(shí)對(duì)比過(guò)鏈表版本同樣個(gè)體數(shù)量下幀率掉 40% 以上。3.2 空間哈希把 O(n2) 優(yōu)化成 O(n)最樸素的個(gè)體間交互是雙重循環(huán)——每對(duì)個(gè)體都檢查距離復(fù)雜度 (O(n^2))。當(dāng)個(gè)體數(shù)超過(guò) 1000 時(shí)這個(gè)循環(huán)直接拖垮 CPU。我的優(yōu)化是在每幀構(gòu)建一個(gè)空間網(wǎng)格uniform grid#define GRID_CELL_SIZE 60.0f typedef struct { int count; int capacity; int *indices; // 存儲(chǔ)個(gè)體在 creatures 數(shù)組中的下標(biāo) } GridCell;遍歷每個(gè)個(gè)體根據(jù)坐標(biāo)算出它落在哪個(gè)格子(gx, gy)把下標(biāo)追加到對(duì)應(yīng)格子的動(dòng)態(tài)數(shù)組里。之后任意一個(gè)個(gè)體想知道周?chē)袥](méi)有鄰居只需要檢查它所在格子和相鄰 8 個(gè)格子里的個(gè)體即可。因?yàn)閭€(gè)體感知半徑最大也只有 30 個(gè)單位GRID_CELL_SIZE60保證不會(huì)漏掉鄰居。3.3 動(dòng)態(tài)數(shù)組擴(kuò)容不想每次 realloc 崩潰C 的realloc用不好就是懸空指針災(zāi)難。我寫(xiě)了一個(gè)簡(jiǎn)單的 macro 來(lái)安全擴(kuò)容#define DA_APPEND(arr, cap, val) do { \ if ((arr##_count) (cap)) { \ (cap) (cap) ? (cap) * 2 : 16; \ (arr) realloc((arr), (cap) * sizeof(*(arr))); \ } \ (arr)[(arr##_count)] (val); \ } while (0)每次容量翻倍均攤下來(lái)append是 (O(1))。死亡個(gè)體不立即刪除而是通過(guò)alive字段標(biāo)記為 0每 300 幀做一次壓縮清理把尾部存活的個(gè)體搬進(jìn)空位避免頻繁memmove。我的經(jīng)驗(yàn)是在模擬器里減少內(nèi)存分配次數(shù)比優(yōu)化算法本身更立竿見(jiàn)影。幾百次malloc本身不慢但它會(huì)打亂緩存連續(xù)性。4. 渲染層的核心思路兩千個(gè)生物只用一次繪制調(diào)用4.1 從一個(gè)個(gè)體一個(gè) glDrawArrays到批量 VBO初學(xué)者最容易寫(xiě)出的渲染循環(huán)是for (int i 0; i n; i) { glBindVertexArray(vao[i]); glDrawArrays(GL_TRIANGLES, 0, 6); // 每個(gè)個(gè)體一個(gè)四邊形 }這套代碼在 200 個(gè)個(gè)體時(shí)還好上了 800 個(gè)就開(kāi)始掉幀2000 個(gè)基本卡成幻燈片。原因很明確每次glDrawArrays都要做一次狀態(tài)切換和驅(qū)動(dòng)層調(diào)用CPU 成了瓶頸。正確做法是把所有個(gè)體的頂點(diǎn)數(shù)據(jù)拼進(jìn)一個(gè)大 VBO一次繪制。我預(yù)先分配了一個(gè)固定大小的緩沖區(qū)每幀把所有存活的個(gè)體展開(kāi)成兩個(gè)三角形6 個(gè)頂點(diǎn)然后glBufferSubData更新整個(gè) VBO最后一次glDrawArrays。// 每幀構(gòu)建頂點(diǎn)數(shù)據(jù) static float *vertex_buf; static size_t vertex_buf_size 0; void push_quad(float *buf, int *idx, float cx, float cy, float size, unsigned char r, unsigned char g, unsigned char b) { // 兩個(gè)三角形組成一個(gè)以 (cx,cy) 為中心的正方形 float h size / 2.0f; float quad[] { cx - h, cy - h, cx h, cy - h, cx h, cy h, cx - h, cy - h, cx h, cy h, cx - h, cy h }; for (int i 0; i 12; i) buf[(*idx)] quad[i]; // 顏色每幀也寫(xiě)入用 VertexAttribPointer 按 stride 取 }// 頂點(diǎn)著色器 (vertex.glsl) #version 330 core layout (location 0) in vec2 aPos; layout (location 1) in vec3 aColor; uniform vec2 uOffset; // 相機(jī)平移 uniform float uScale; // 相機(jī)縮放 out vec3 vColor; void main() { vec2 world_pos (aPos * uScale) uOffset; vec2 ndc world_pos / vec2(1280.0, 720.0) * 2.0 - 1.0; gl_Position vec4(ndc, 0.0, 1.0); vColor aColor; }這樣無(wú)論個(gè)體數(shù)是 1000 還是 3000渲染調(diào)用始終只有一次瓶頸重新回到模擬計(jì)算而這正是 C 最擅長(zhǎng)的地方。4.2 攝像機(jī)平移和縮放的數(shù)學(xué)攝像機(jī)是 2D 的中間坐標(biāo)系轉(zhuǎn)換。世界坐標(biāo) (P_w) 轉(zhuǎn)屏幕坐標(biāo) (P_s)[ P_s (P_w \times scale) offset ]逆運(yùn)算鼠標(biāo)在屏幕上的坐標(biāo)轉(zhuǎn)為世界坐標(biāo)是[ P_w (P_s - offset) / scale ]鼠標(biāo)滾輪改變scale鼠標(biāo)中鍵拖拽改變offset。我需要確?？s放時(shí)以鼠標(biāo)指向的位置為錨點(diǎn)否則縮放會(huì)漂移處理方式是縮放前后保持鼠標(biāo)指向的世界坐標(biāo)不變void zoom_at(float mx, float my, float factor) { // mx, my 是鼠標(biāo)在屏幕上的位置 float wx (mx - offset_x) / scale; float wy (my - offset_y) / scale; scale * factor; offset_x mx - wx * scale; offset_y my - wy * scale; }這套變換在 30 分鐘內(nèi)就能實(shí)現(xiàn)但配合上千個(gè)移動(dòng)粒子觀眾會(huì)覺(jué)得整個(gè)模擬世界活了。5. 踩坑記錄渲染和模擬層的幾個(gè)難纏問(wèn)題5.1 OpenGL 初始化順序glGenVertexArrays 一調(diào)用就崩這是新手最常見(jiàn)的崩潰點(diǎn)。癥狀是glGenVertexArrays調(diào)用時(shí)直接段錯(cuò)誤或者glBufferData報(bào)GL_INVALID_OPERATION。原因是 GLFW 窗口創(chuàng)建和 OpenGL 上下文激活的先后順序出了問(wèn)題。GLFW 中正確的是glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); GLFWwindow *win glfwCreateWindow(1280, 720, ecosim, NULL, NULL); glfwMakeContextCurrent(win); // 必須在所有 gl 調(diào)用之前 glewExperimental GL_TRUE; glewInit();我的代碼曾經(jīng)在glewInit()之前就調(diào)用了glViewport結(jié)果一切看起來(lái)正常但第一個(gè) VBO 創(chuàng)建后驅(qū)動(dòng)就進(jìn)入混亂狀態(tài)。規(guī)則只有一條窗口和上下文必須在任何 GL 調(diào)用之前創(chuàng)建完畢。5.2 高 DPI 屏幕上的模糊和坐標(biāo)偏移我最初用glfwGetFramebufferSize獲取窗口大小但在 macOS 和部分 Linux 高 DPI 環(huán)境上這個(gè)值和glfwGetWindowSize返回的不一樣。如果glViewport用窗口大小而 actual framebuffer 更大整個(gè)畫(huà)面會(huì)糊掉而且鼠標(biāo)坐標(biāo)和渲染位置對(duì)不上。修復(fù)方式是int fb_width, fb_height; glfwGetFramebufferSize(window, fb_width, fb_height); glViewport(0, 0, fb_width, fb_height);鼠標(biāo)坐標(biāo)仍用窗口大小但在做 NDC 換算時(shí)除以 framebuffer size。這個(gè)坑不嚴(yán)重但排查起來(lái)很氣人。5.3 NaN 病毒一個(gè)個(gè)體變成 NaN整個(gè)世界開(kāi)始抖動(dòng)模擬運(yùn)行到某一幀屏幕上所有個(gè)體突然消失緊接著整個(gè)空間坐標(biāo)全變成-nan。排查了很久最終定位到捕食邏輯一個(gè)能量值為 0 的個(gè)體仍被標(biāo)記為可捕食捕食者把它的能量按比例加到自己身上時(shí)分母是 0產(chǎn)生 NaN。NaN 通過(guò)下一次繁殖又傳給了子代最終污染整個(gè)種群。修復(fù)很干脆任何個(gè)體能量低于 0.01 就立刻死亡并跳過(guò)捕食/繁殖分支。if (creature.energy 0.01f || creature.age creature.lifespan) { creature.alive 0; continue; // 不再參與本幀任何交互 }經(jīng)驗(yàn)教訓(xùn)模擬類程序里防 NaN 的防御性檢查一定要放在最前面。遇到所有數(shù)字全變成 nan先查哪一步產(chǎn)生了除零或sqrt(負(fù)數(shù))。5.4 隨機(jī)數(shù)種子導(dǎo)致每次運(yùn)行結(jié)果完全一致我一開(kāi)始用srand(time(NULL))初始化rand()但同一秒內(nèi)多次運(yùn)行時(shí)結(jié)果一模一樣。后來(lái)?yè)Q了clock_gettime的高精度納秒來(lái)播種同時(shí)因?yàn)橐С种刂媚M功能我封裝了自己的隨機(jī)函數(shù)并允許通過(guò)命令行參數(shù)傳遞種子這樣既能復(fù)現(xiàn)某一局又能保證默認(rèn)運(yùn)行隨機(jī)unsigned long long seed 0; void init_rng(unsigned long long s) { seed s; } float randf() { // xorshift64比 libc rand 快且分布均勻 seed ^ seed 13; seed ^ seed 7; seed ^ seed 17; return (float)(seed 0xFFFFFFFF) / (float)0xFFFFFFFF; }6. 構(gòu)建與運(yùn)行從安裝依賴到看見(jiàn)第一群生物6.1 依賴安裝Debian/Ubuntu 系sudo apt install build-essential libglfw3-dev libglew-dev不需要額外裝 OpenGL 開(kāi)發(fā)包libgl-dev已經(jīng)是build-essential的依賴。檢查一下/usr/include/GLFW/glfw3.h和/usr/include/GL/glew.h是否存在即可。6.2 Makefile一個(gè)足夠好用的版本CC gcc CFLAGS -stdc11 -O2 -Wall -Wextra -Wpedantic -marchnative LDFLAGS -lglfw -lGLEW -lGL -lm SRC main.c simulation.c render.c input.c OBJ $(SRC:.c.o) ecosim: $(OBJ) $(CC) -o $ $^ $(LDFLAGS) %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: rm -f $(OBJ) ecosim run: ecosim ./ecosim注意-marchnative可能造成在不同機(jī)器上無(wú)法復(fù)制二進(jìn)制但這只是源碼分發(fā)項(xiàng)目自己跑沒(méi)問(wèn)題。6.3 啟動(dòng)參數(shù)和交互控制我的程序支持幾個(gè)命令行參數(shù)./ecosim --seed 42 --creatures 2000 --herbivores 0.7運(yùn)行時(shí)控制鼠標(biāo)中鍵拖拽平移視角滾輪縮放空格暫停/繼續(xù)R重置模擬上下方向鍵調(diào)整變異率實(shí)時(shí)生效左右方向鍵調(diào)整繁殖閾值F切換顯示模式正常/能量視圖/基因視圖調(diào)參實(shí)時(shí)生效這個(gè)功能非常關(guān)鍵因?yàn)樯鷳B(tài)系統(tǒng)的動(dòng)態(tài)平衡往往只在某個(gè)參數(shù)區(qū)間內(nèi)出現(xiàn)手動(dòng)試探比改代碼重編譯快得多。7. 進(jìn)一步擴(kuò)展的方向和后記ecosim 目前的版本只是個(gè)起點(diǎn)。我在代碼里預(yù)留了幾個(gè)擴(kuò)展點(diǎn)多地圖類型可以在啟動(dòng)時(shí)加載不同噪聲參數(shù)的地圖比如島嶼、走廊、雙熱點(diǎn)地形。物種分化可視化按基因相似度聚類用不同顏色帶顯示物種樹(shù)的實(shí)時(shí)變化。這個(gè)功能技術(shù)上不難只要每幀用臨時(shí)數(shù)組做一次簡(jiǎn)單聚類。統(tǒng)計(jì)輸出把每幀的種群數(shù)量、平均速度、基因多樣性指數(shù)寫(xiě)進(jìn) CSV模擬結(jié)束后用 Python 畫(huà)圖分析。這是觀察演進(jìn)趨勢(shì)最直觀的方法。如果你要復(fù)刻這個(gè)項(xiàng)目我建議從最小的循環(huán)開(kāi)始先讓 200 個(gè)個(gè)體隨機(jī)游走并繪制出來(lái)再逐步加入能量、食物、繁殖、捕食。不要一上來(lái)就寫(xiě)完整的遺傳算法和空間網(wǎng)格否則你會(huì)花大量時(shí)間調(diào)試一個(gè)你根本沒(méi)想清楚的系統(tǒng)。我在實(shí)際運(yùn)行中最驚喜的時(shí)刻是有一次把變異率調(diào)到 15%然后去泡了杯咖啡回來(lái)發(fā)現(xiàn)屏幕上出現(xiàn)了一小群高速種——它們移動(dòng)極快、壽命很短、幾乎不停頓卻牢牢占據(jù)著地圖右下角的一大片資源區(qū)。這些生物的行為完全不是我的代碼直接定義的它們只是遵循了最簡(jiǎn)單的能量法則在隨機(jī)變異和自然選擇中自己走出來(lái)的。這正是 ecosim 這一類人工生命項(xiàng)目最讓人著迷的地方你寫(xiě)下的是規(guī)則但看得到的是演化。本文還有配套的精品資源點(diǎn)擊獲取