zeinstack
بازگشت به وبلاگ
create game with nodejs and threejs and ai

بازی وب با هوش مصنوعی: از نصب Node.js تا اولین بازی قابل‌بازی

راهنمای کامل ساخت بازی مرورگری با Claude Code و Codex: بازی از چه بخش‌هایی ساخته شده، تفاوت Phaser 4 و Three.js، نصب Node.js و راه‌اندازی پروژه، ساختار پوشه‌ی درست، و هفت پرامپت آماده برای گرفتن خروجی تمیز از ایجنت.

28 شهریور 140515 دقیقه مطالعهمحمد زین‌العابدین

بازی وب با هوش مصنوعی: از نصب Node.js تا اولین بازی قابل‌بازی

اگر تا حالا به Claude Code یا Codex گفته‌ای «برام یه بازی بساز» و بعد از دو روز به یک فایل هزارخطی رسیده‌ای که خودت هم جرئت نمی‌کنی بازش کنی، مشکل از هوش مصنوعی نبوده. مشکل این بوده که هیچ‌وقت بهش نگفتی بازی از چی ساخته شده.

این مقاله همان چیزی است که باید قبل از اولین پرامپت بدانی: بازی مرورگری از چه بخش‌هایی تشکیل شده، چطور اجرا می‌شود، کدام موتور به درد کدام کار می‌خورد، چطور محیط کارت را راه بیندازی، و مهم‌تر از همه — دقیقاً چه پرامپت‌هایی بدهی تا خروجی تمیز بگیری. آخر مقاله یک مجموعه پرامپت آماده هست که می‌توانی مستقیم کپی کنی.

Game development


بازی از چی ساخته شده؟

از یه بازی ساده مثل Flappy Bird گرفته تا بازی‌های بزرگی مثل GTA، همه‌شون بر پایه‌ی چند مفهوم و سیستم مشترک ساخته می‌شن.

۱. حلقه‌ی بازی (Game Loop)

قلب ماجرا همین است. یک حلقه که ثانیه‌ای ۶۰ بار تکرار می‌شود و هر بار سه کار می‌کند: ورودی بازیکن را می‌خواند، وضعیت بازی را به‌روز می‌کند، و صحنه را دوباره می‌کشد.

در مرورگر، این حلقه با requestAnimationFrame اجرا می‌شود. تفاوتش با setInterval این است که خودش را با نرخ تازه‌سازی مانیتور هماهنگ می‌کند و وقتی تب مخفی شود متوقف می‌شود — یعنی باتری کاربر را نمی‌خورد.

let last = performance.now();

function loop(now) {
  const dt = (now - last) / 1000; // فاصله‌ی زمانی بر حسب ثانیه
  last = now;

  update(dt);   // منطق بازی
  render();     // کشیدن صحنه

  requestAnimationFrame(loop);
}

requestAnimationFrame(loop);

آن dt مهم‌ترین چیز این تکه کد است. اگر حرکت را با x += 5 بنویسی، بازی روی مانیتور ۱۴۴ هرتز دو برابر سریع‌تر می‌شود. اگر با x += speed * dt بنویسی، روی هر دستگاهی یکسان اجرا می‌شود. نود درصد باگ‌های «چرا رو گوشی من عجیب می‌شه» ریشه‌شان همین‌جاست.

۲. صحنه (Scene)

هر حالت بازی یک صحنه است: منوی اصلی، مرحله‌ی یک، فروشگاه، صفحه‌ی گیم‌اُور. هر صحنه دارایی‌های خودش را لود می‌کند، موجودیت‌های خودش را می‌سازد، و وقتی تمام شد خودش را پاک می‌کند.

جدا کردن صحنه‌ها اولین کاری است که جلوی به‌هم‌ریختگی پروژه را می‌گیرد. اگر منو و مرحله توی یک فایل باشند، تا هفته‌ی سوم دیگر نمی‌فهمی کدام متغیر مال کدام است.

۳. موجودیت‌ها (Entities)

هر چیزی که در صحنه وجود دارد و رفتار دارد: بازیکن، دشمن، گلوله، سکه، پلتفرم متحرک. هر موجودیت معمولاً موقعیت، سرعت، ظاهر و یک تابع update دارد.

۴. ورودی (Input)

کیبورد، ماوس، لمس، گیم‌پد. نکته‌ی مهم: ورودی را مستقیم داخل منطق بازی نخوان. یک لایه‌ی واسط بساز که «کلید راست فشرده شده» را به «بازیکن می‌خواهد به راست برود» ترجمه کند. این‌طوری بعداً اضافه کردن پشتیبانی لمسی یک تغییر کوچک است، نه بازنویسی کامل.

۵. دارایی‌ها (Assets)

تصاویر، صداها، فونت‌ها، نقشه‌ی مراحل. اینها باید قبل از شروع بازی لود شوند، وگرنه اولین فریم بازی خالی است و بازیکن فکر می‌کند بازی خراب است. به همین دلیل تقریباً همه‌ی موتورها یک مرحله‌ی preload دارند.

۶. رندر (Render)

اینجا جایی است که همه‌چیز روی صفحه کشیده می‌شود. در وب، این کار روی یک المنت <canvas> انجام می‌شود و پشت صحنه یکی از این سه راه را می‌رود:

  • Canvas 2D — ساده و همه‌جا کار می‌کند، ولی برای تعداد زیاد شیء کند می‌شود.
  • WebGL / WebGL2 — از کارت گرافیک استفاده می‌کند. استاندارد فعلی و تقریباً روی همه‌ی دستگاه‌ها موجود است.
  • WebGPU — نسل بعدی. دسترسی سطح‌پایین‌تر به GPU، با الگوبرداری از Vulkan و Metal و DirectX 12. بعد از اینکه سافاری پشتیبانی‌اش را اضافه کرد و شکاف‌های اندروید و iOS پر شد، در ۲۰۲۶ به یک استاندارد بین‌مرورگری تبدیل شد.

توصیه‌ی عملی برای امروز: WebGPU را هدف بگیر آنجا که واقعاً کمک می‌کند (تعداد زیاد draw call، ذرات و فیزیک روی GPU) و همیشه fallback به WebGL2 داشته باش. برای صحنه‌های ساده، این دو عملاً تفاوت محسوسی ندارند.

Game loop


موتورها: Phaser 4 و Three.js

این دو تا رقیب هم نیستند. دو ابزار برای دو کار متفاوت‌اند و فرق اصلی‌شان یک چیز است: دوبعدی یا سه‌بعدی.

Phaser 4 — برای بازی دوبعدی

فیزر محبوب‌ترین فریم‌ورک بازی‌سازی HTML5 است و بیش از ده سال است فعالانه توسعه داده می‌شود. نسخه‌ی ۴ در آوریل ۲۰۲۶ منتشر شد و بزرگ‌ترین بازنویسی تاریخ این پروژه بود: رندرر WebGL از صفر بازنویسی شد با یک معماری گرهی جدید، ولی همان API نسخه ۳ حفظ شد. یعنی هزاران آموزش و نمونه‌کد قدیمی هنوز کار می‌کنند.

چی توش هست:

  • سیستم فیلتر یکپارچه — در نسخه ۳، افکت‌ها و ماسک‌ها دو سیستم جدا بودند. حالا یک سیستم فیلتر واحد است که روی هر شیء یا دوربینی اعمال می‌شود، با Blur، Glow، Shadow، Pixelate، Bloom، Vignette، ColorMatrix و چند ده مورد دیگر که آماده می‌آیند.
  • فیزیک داخلی — موتور Arcade برای برخوردهای ساده و سریع (پلتفرمر، رانر، شوتر)، و Matter.js برای فیزیک واقعی‌تر.
  • سیستم صحنه — صحنه‌ها به‌صورت توکار مدیریت می‌شوند، با چرخه‌ی عمر مشخص و امکان اجرای موازی چند صحنه (مثلاً HUD روی مرحله).
  • لودر دارایی — تصویر، اطلس، اسپرایت‌شیت، صدا، فونت بیت‌مپ، نقشه‌ی Tiled.
  • انیمیشن و Tween — سیستم انیمیشن فریم‌به‌فریم و موتور tween برای حرکت‌های نرم.
  • نکته‌ی مهم برای ما: مخزن فیزر ۴ یک پوشه‌ی skills/ دارد با ۲۸ فایل skill که برای ایجنت‌های هوش مصنوعی نوشته شده — هر زیرسیستم فیزر یک فایل دارد، به‌علاوه‌ی یک skill مخصوص مهاجرت از v3 به v4. اگر ایجنتت را به این پوشه وصل کنی، کیفیت خروجی‌اش به‌طرز محسوسی بالا می‌رود.

یک تذکر: فیزر ۴ یک بازنویسی WebGL2 است، نه یک موتور WebGPU. کارهای WebGPU زیرساخت آینده است، نه قابلیت امروز. اگر کسی خلافش را گفت، اشتباه گفته.

برای چی خوب است: پلتفرمر، پازل، مچ‌تری، رانر، شوتر بالاسری، بازی‌های کژوال و پورتالی.

Three.js — برای بازی سه‌بعدی

ثری‌جی‌اس دقیقاً یک موتور بازی نیست؛ یک کتابخانه‌ی رندر سه‌بعدی است. یعنی کارش این است که صحنه‌ی سه‌بعدی را روی صفحه بکشد، و بقیه‌ی چیزها — فیزیک، صدا، منطق بازی — را خودت اضافه می‌کنی. همین باعث می‌شود هم انعطاف‌پذیرتر باشد، هم کار بیشتری بخواهد.

چی توش هست:

  • صحنه، دوربین، رندرر — سه مفهوم پایه. صحنه چیزها را نگه می‌دارد، دوربین تعیین می‌کند از کجا نگاه می‌کنی، رندرر آن را می‌کشد.
  • هندسه و متریال — هندسه شکل است (مکعب، کره، مدل وارداتی)، متریال ظاهر (رنگ، بافت، براقی، شفافیت).
  • نورپردازی و سایه — نور جهت‌دار، نقطه‌ای، محیطی، با سایه‌های بلادرنگ.
  • لود مدل — پشتیبانی از glTF (استاندارد صنعتی وب)، با فشرده‌سازی Draco برای کم کردن حجم.
  • رندرر WebGPU — ثری‌جی‌اس حالا علاوه بر WebGL یک رندرر WebGPU هم دارد. خیلی‌ها هنوز با WebGL شروع می‌کنند و بعداً سوییچ می‌کنند.
  • شیدر — اگر بخواهی وارد GLSL بشوی، راه باز است. اگر نخواهی، متریال‌های آماده کافی‌اند.

برای چی خوب است: رانر سه‌بعدی، نمایشگر محصول، صحنه‌های تعاملی، بازی‌های اول‌شخص ساده، تجربه‌های وب‌سایتی.

کدام را انتخاب کنم؟

معیار Phaser 4 Three.js
نوع بازی دوبعدی سه‌بعدی
فیزیک داخلی (Arcade / Matter) جدا لازم است (مثلاً cannon-es)
مدیریت صحنه توکار خودت می‌نویسی
شیب یادگیری ملایم تندتر
اولین بازی پیشنهاد می‌شود بعد از تجربه

اگر مطمئن نیستی، با فیزر شروع کن. بازی دوبعدی سریع‌تر به نتیجه می‌رسد و نتیجه‌ی زودرس تنها چیزی است که نمی‌گذارد پروژه را رها کنی.

Threejs vs Phaser


سبک هنری را هم از اول انتخاب کن

یک نکته که معمولاً دیر فهمیده می‌شود: بیشتر پروژه‌های شخصی سر آرت می‌میرند، نه سر کد. سبک اشتباه یعنی هفته‌ها گیر کردن پشت کاری که اصلاً برنامه‌نویسی نیست.

  • Pixel Art — کم‌ترین کار، بهترین شروع. با یک شبکه‌ی ۱۶×۱۶ و ده تا رنگ می‌شود چیز قابل‌قبولی درآورد.
  • Flat / Minimal — فقط شکل‌های هندسی و رنگ تخت. برای پازل و کژوال عالی است و عملاً نیازی به مهارت طراحی ندارد.
  • Low-poly 3D — سه‌بعدی بدون مدل‌سازی حرفه‌ای. چند صد مثلث و رنگ تخت، بدون بافت.
  • Hand-drawn — قشنگ‌ترین نتیجه، بیشترین وقت. مگر اینکه خودت طراحی بلد باشی، برای اولین پروژه نه.

قاعده‌ی ساده: سبکی را بردار که بتوانی آرتش را خودت بسازی.


راه‌اندازی محیط کار

قدم ۱: نصب Node.js

Node.js را از nodejs.org دانلود کن و نسخه‌ی LTS را بگیر، نه Current. نسخه‌ی LTS فعلی خط ۲۴ است. خط ۲۶ هم از اواخر اکتبر ۲۰۲۶ وارد LTS می‌شود.

موقع نصب روی ویندوز، تیک گزینه‌ی نصب ابزارهای جانبی را بزن. بعد از نصب، ترمینال را باز کن و تست کن:

node -v
npm -v

اگر هر دو یک شماره‌ی نسخه برگرداندند، آماده‌ای. اگر خطای «command not found» گرفتی، ترمینال را ببند و دوباره باز کن.

nodejs terminal

قدم ۲: ویرایشگر

VS Code یا هر ویرایشگری که باهاش راحتی. اگر قرار است با Claude Code یا Codex کار کنی، افزونه‌ی مربوطه را هم نصب کن یا از ترمینال داخل همان پوشه‌ی پروژه اجرایش کن — مهم است که ایجنت در ریشه‌ی پروژه باشد تا فایل‌های راهنما را ببیند.

قدم ۳-الف: ساخت پروژه‌ی Phaser 4

ساده‌ترین راه، ابزار رسمی خود فیزر است که قالب‌های آماده را برایت پیکربندی می‌کند:

npm create @phaserjs/game@latest

چند سؤال می‌پرسد (قالب، جاوااسکریپت یا تایپ‌اسکریپت، باندلر) و پروژه را می‌سازد. بعدش:

cd نام-پروژه
npm install
npm run dev

اگر می‌خواهی دستی راه بیندازی:

npm create vite@latest my-game -- --template vanilla
cd my-game
npm install
npm install phaser
npm run dev

و یک main.js مینیمال:

import Phaser from 'phaser';

const config = {
  type: Phaser.AUTO,
  width: 800,
  height: 600,
  backgroundColor: '#1d1d2b',
  physics: {
    default: 'arcade',
    arcade: { gravity: { y: 600 } }
  },
  scene: {
    preload() {
      // بارگذاری دارایی‌ها
    },
    create() {
      this.add.text(400, 300, 'سلام دنیا', { fontSize: '32px' })
        .setOrigin(0.5);
    },
    update(time, delta) {
      // منطق هر فریم
    }
  }
};

new Phaser.Game(config);

Phaser.AUTO یعنی اگر WebGL در دسترس بود از آن استفاده کن، وگرنه برو سراغ Canvas. برای تقریباً همه‌ی پروژه‌ها همین درست است.

قدم ۳-ب: ساخت پروژه‌ی Three.js

روش رسمی و پیشنهادی، نصب از npm همراه با یک build tool است. بدون build tool مجبور می‌شوی import map دستی توی index.html بنویسی که دردسر اضافه است.

npm create vite@latest my-3d-game -- --template vanilla
cd my-3d-game
npm install
npm install three
npm run dev

و یک صحنه‌ی حداقلی:

import * as THREE from 'three';

const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(
  75, window.innerWidth / window.innerHeight, 0.1, 1000
);
camera.position.z = 5;

const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(window.innerWidth, window.innerHeight);
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
document.body.appendChild(renderer.domElement);

const cube = new THREE.Mesh(
  new THREE.BoxGeometry(1, 1, 1),
  new THREE.MeshStandardMaterial({ color: 0xff6b35 })
);
scene.add(cube);

scene.add(new THREE.AmbientLight(0xffffff, 0.4));
const light = new THREE.DirectionalLight(0xffffff, 1.2);
light.position.set(3, 5, 2);
scene.add(light);

const clock = new THREE.Clock();

function animate() {
  const dt = clock.getDelta();
  cube.rotation.y += dt;
  renderer.render(scene, camera);
  requestAnimationFrame(animate);
}
animate();

window.addEventListener('resize', () => {
  camera.aspect = window.innerWidth / window.innerHeight;
  camera.updateProjectionMatrix();
  renderer.setSize(window.innerWidth, window.innerHeight);
});

آن setPixelRatio با سقف ۲ یک ترفند مهم است: روی گوشی‌هایی با pixel ratio سه یا چهار، بدون این خط داری سه چهار برابر پیکسل لازم رندر می‌کنی و بی‌دلیل فریم از دست می‌دهی.

قدم ۴: خروجی نهایی

وقتی آماده‌ی انتشار شدی:

npm run build

همه‌چیز کامپایل و بهینه می‌شود و داخل پوشه‌ی dist/ می‌نشیند. محتویات همان پوشه را روی هاست آپلود کن — همین. نیازی به سرور خاصی نیست؛ هر هاست استاتیکی کار می‌کند.

threejs game structure


ساختار پوشه‌ای که باید دیکته کنی

این مهم‌ترین بخش کل مقاله است. ایجنت هوش مصنوعی اگر ساختار نداشته باشد، همه‌چیز را توی یک فایل می‌ریزد — نه از بدجنسی، از این که چیز دیگری بهش نگفته‌ای.

my-game/
├─ public/
│  └─ assets/          تصاویر، صداها، فونت‌ها
├─ src/
│  ├─ main.js          نقطه‌ی ورود، پیکربندی بازی
│  ├─ scenes/          هر صحنه یک فایل
│  │  ├─ BootScene.js
│  │  ├─ MenuScene.js
│  │  ├─ GameScene.js
│  │  └─ GameOverScene.js
│  ├─ entities/        بازیکن، دشمن، آیتم
│  │  ├─ Player.js
│  │  └─ Enemy.js
│  ├─ systems/         ورودی، امتیاز، صدا
│  │  ├─ input.js
│  │  └─ score.js
│  └─ config/          اعداد بازی، جدا از منطق
│     └─ balance.js
├─ index.html
└─ package.json

قانون طلایی: اعداد بازی توی فایل کد نباشند. سرعت بازیکن، ارتفاع پرش، تعداد جان، امتیاز هر سکه — همه بروند توی config/balance.js. دلیلش این است که تنظیم حس بازی یعنی بیست بار عوض کردن همین اعداد، و نمی‌خواهی هر بار دنبالشان بگردی.

// src/config/balance.js
export const PLAYER = {
  speed: 220,
  jumpVelocity: -480,
  maxLives: 3
};

export const SCORING = {
  coin: 10,
  enemyDefeat: 50
};

فایل راهنما برای ایجنت

قبل از اولین پرامپت، یک فایل متنی در ریشه‌ی پروژه بساز. اسمش را بگذار CLAUDE.md (برای Claude Code) یا AGENTS.md (برای Codex). ایجنت این فایل را خودش می‌خواند و رعایت می‌کند.

این فایل کیفیت خروجی را تعیین می‌کند، نه پرامپت تک‌خطی‌ات. هر چیزی که مجبور می‌شوی بارها یادآوری کنی، یک‌بار اینجا بنویس.

# پروژه: [اسم بازی]

## چیستی
یک بازی [ژانر] دوبعدی مرورگری. بازیکن [کار اصلی] انجام می‌دهد.
هدف: [شرط برد]. شکست: [شرط باخت].

## استک
- Phaser 4 (WebGL2) — نه Phaser 3
- JavaScript ماژولار (ESM)، بدون TypeScript
- Vite برای dev و build
- بدون هیچ کتابخانه‌ی اضافه‌ی دیگر

## ساختار پوشه — رعایت اجباری
src/main.js        نقطه‌ی ورود و پیکربندی
src/scenes/        هر صحنه یک فایل
src/entities/      هر موجودیت یک کلاس در فایل خودش
src/systems/       ورودی، امتیاز، صدا
src/config/        فقط اعداد و ثابت‌ها

## قواعد
- هیچ فایلی بیشتر از ۲۰۰ خط نشود. اگر شد، بشکن.
- هیچ عدد جادویی داخل منطق بازی نباشد؛ همه از config بیاید.
- حرکت همیشه با delta time محاسبه شود، نه مقدار ثابت در هر فریم.
- بدون نصب پکیج جدید مگر اینکه اول بپرسی و تأیید بگیرم.
- بدون افزودن قابلیتی که نخواسته‌ام.
- کامنت فقط جایی که «چرا» را توضیح می‌دهد، نه «چه کاری».

## بودجه‌ی پرفورمنس
- هدف ۶۰ فریم بر ثانیه روی موبایل میان‌رده
- حجم بیلد نهایی زیر [عدد] مگابایت
- devicePixelRatio سقف ۲

## وضعیت فعلی
[این بخش را بعد از هر جلسه به‌روز کن: چی ساخته شده، چی مانده]

آن بخش آخر را دست‌کم نگیر. وقتی جلسه‌ی بعد برمی‌گردی، ایجنت هیچ حافظه‌ای از دفعه‌ی قبل ندارد — این فایل تنها حافظه‌اش است.

و یک نکته‌ی اختصاصی فیزر ۴: مخزن رسمی‌اش پوشه‌ای به اسم skills/ دارد با ۲۸ فایل راهنما که مخصوص ایجنت‌های هوش مصنوعی نوشته شده‌اند. اگر آن پوشه را داخل پروژه‌ات کپی کنی و در CLAUDE.md بهش اشاره کنی، ایجنت به‌جای حدس زدن، مستند واقعی فیزر ۴ را می‌خواند.


پرامپت‌های آماده

اینها را به ترتیب استفاده کن. هر کدام یک کار مشخص دارد و بین‌شان تست کن.

۰. ساخت فایل راهنما

می‌خواهم یک بازی [ژانر] دوبعدی با Phaser 4 و Vite بسازم.

قبل از نوشتن هر کدی، فایل CLAUDE.md را در ریشه‌ی پروژه بساز
که شامل این بخش‌ها باشد: توضیح بازی، استک، ساختار پوشه،
قواعد کدنویسی، بودجه‌ی پرفورمنس، و وضعیت فعلی.

هر جا اطلاعات کافی نداری، از من بپرس — حدس نزن.
فقط همین فایل را بساز و متوقف شو.

۱. اسکلت پروژه

بر اساس CLAUDE.md، اسکلت پروژه را بساز:

- ساختار پوشه‌ی مشخص‌شده، با فایل‌های خالی یا حداقلی
- main.js با پیکربندی Phaser و ثبت صحنه‌ها
- BootScene که فقط یک متن "loading" نشان می‌دهد
- GameScene خالی با یک پس‌زمینه‌ی تک‌رنگ
- config/balance.js با مقادیر اولیه

هنوز هیچ مکانیکی پیاده نکن. فقط باید npm run dev اجرا شود
و یک صفحه‌ی خالی بدون خطا ببینم.

۲. حلقه‌ی اصلی بازی

حالا فقط core loop را پیاده کن، هیچ چیز دیگر:

- یک بازیکن که با کلیدهای جهت‌دار حرکت می‌کند
- زمین و برخورد پایه
- حرکت با delta time، اعداد از config/balance.js

بدون منو، بدون صدا، بدون آرت، بدون امتیاز.
می‌خواهم اول ببینم حرکت حس خوبی می‌دهد یا نه.
فایل‌های دیگر را دست نزن.

۳. افزودن یک مکانیک

یک مکانیک اضافه کن: [توضیح دقیق مکانیک].

شرایط:
- در فایل خودش در src/entities یا src/systems
- اعداد جدید به config/balance.js اضافه شود
- هیچ فایل موجودی بازنویسی نشود؛ فقط ویرایش حداقلی

قبل از نوشتن کد، در دو خط بگو چه فایل‌هایی می‌سازی
و چه فایل‌هایی را تغییر می‌دهی.

۴. رفع باگ

این مشکل را دارم: [توضیح دقیق رفتار اشتباه]
رفتار مورد انتظار: [چه باید می‌شد]
مراحل بازتولید: [چطور اتفاق می‌افتد]

اول علت را پیدا کن و توضیح بده چرا این اتفاق می‌افتد.
بعد از تأیید من کد را عوض کن.
کمترین تغییر ممکن — بازنویسی کلی نکن.

۵. پرفورمنس

بازی روی موبایل افت فریم دارد.

پروفایل بگیر و بگو گلوگاه کجاست. بعد فقط مواردی را که
واقعاً اثر دارند اصلاح کن:
- تعداد شیء‌های زنده در هر فریم
- استفاده‌ی مجدد از اشیاء به‌جای ساخت و حذف مداوم
- سقف devicePixelRatio روی ۲
- اندازه و فرمت تصاویر

قبل و بعد را با عدد مقایسه کن. بهینه‌سازی حدسی انجام نده.

۶. آماده‌سازی انتشار

بازی را برای انتشار آماده کن:

- npm run build بدون خطا و بدون warning اجرا شود
- حجم خروجی را گزارش بده و بگو بزرگ‌ترین فایل‌ها کدام‌اند
- تصاویر بهینه شوند
- یک README کوتاه با نحوه‌ی اجرا و بیلد بنویس

چیزی به بازی اضافه نکن.
create game with ai

پنج اشتباهی که پروژه را می‌کشد

  1. شروع با بازی بزرگ. اولین پروژه باید در یک آخر هفته تمام شود. پازل، رانر، یا یک بازی تک‌مکانیکی. نه RPG.
  2. آرت قبل از گیم‌پلی. تا وقتی core loop حال ندهد، هیچ گرافیکی نجاتش نمی‌دهد. با مربع‌های رنگی شروع کن.
  3. پرامپت‌های بزرگ. «کل بازی را بساز» یعنی کدی که نه می‌فهمی‌اش نه می‌توانی درستش کنی. یک قابلیت در هر پرامپت.
  4. نداشتن نسخه‌بندی. قبل از هر تغییر بزرگ commit بزن. وقتی ایجنت چیزی را خراب کرد — و می‌کند — باید بتوانی برگردی.
  5. پرفورمنس به‌عنوان کار آخر. بودجه‌ی فریم و حجم را از روز اول بنویس. «بعداً درستش می‌کنم» معمولاً یعنی «بازنویسی می‌کنم».

بعدش چی؟

وقتی اولین بازی‌ات قابل‌بازی شد، دو کار ارزش دارند. اول اینکه لینکش را بدهی به چند نفر و نگاه کنی چطور بازی می‌کنند — نه اینکه نظرشان را بپرسی، فقط نگاه کن کجا گیر می‌کنند. دوم اینکه روی یکی از پورتال‌های بازی وب مثل itch.io بگذاری‌اش.

و نکته‌ای که پشت این همه هست: کشف بازی از استیم جابه‌جا شده. ایندی‌هایی که نمی‌توانستند دیده‌شدن بخرند رفتند سراغ شبکه‌های اجتماعی، و فرمت مشترک همه‌شان ویدیوی کوتاه با لینک قابل کلیک است. بازی مرورگری دقیقاً به همین دلیل دوباره به یک محصول واقعی تبدیل شد: چیزی که با یک کلیک باز می‌شود، بدون نصب، بدون دانلود.

یعنی همان بازی کوچکی که آخر هفته ساختی، اگر لینکش را درست پخش کنی، می‌تواند بیشتر از یک پروژه‌ی بزرگ نیمه‌تمام برایت بیاورد.


جمع‌بندی

سه تصمیم قبل از اولین پرامپت: موتور (فیزر برای دوبعدی، ثری‌جی‌اس برای سه‌بعدی)، سبک هنری (چیزی که خودت بتوانی بسازی)، و ساختار پوشه (صحنه‌ها، موجودیت‌ها، تنظیمات — جدا).

بعدش فایل راهنما را بنویس، و پرامپت‌ها را یکی‌یکی جلو برو. ابزار هوش مصنوعی سرعتت را چند برابر می‌کند، ولی جهت را تو باید بدهی. سرعت بدون ساختار فقط یعنی سریع‌تر به بن‌بست رسیدن.

اگر سؤالی داشتی یا گیر کردی، زیر همین پست بنویس.

م
درباره نویسندهمحمد زین‌العابدین

توسعه‌دهنده فول‌استک