LLM के बिना गेम बनाने में 3 महीने, LLM के साथ सिर्फ 3 दिन

• 15 साल के अनुभव वाले एक software engineer ने बचपन के एक card game को Go भाषा में बनाने का अनुभव साझा किया
• LLM (Large Language Model) के बिना “Truco” बनाते समय UI design और serverless deployment जैसी हर समस्या को हाथ से हल करना पड़ा और इसमें 3 महीने लगे
• “Escoba” बनाते समय LLM का उपयोग करके backend code conversion और implementation speed को बहुत तेज़ किया गया, और सिर्फ एक prompt में ज़्यादातर चीज़ें काम करने लगीं
• लेख के बाद के हिस्से में Tic-Tac-Toe उदाहरण के साथ Go backend, WASM conversion, और React integration के जरिए कोई भी अपना गेम बना सके, इसके लिए step-by-step guide दी गई है
• लेकिन React frontend और WASM-आधारित game state management अब भी सीधे debug और implement करना पड़ता है

---

परिचय

• 15 साल के अनुभव वाले एक software engineer को एहसास हुआ कि उन्होंने कभी सच में कोई गेम बनाकर deploy नहीं किया था
• उन्होंने तय किया कि बचपन में Argentina में दोस्तों के साथ खेले गए card games में से एक को Go भाषा में बनाया जाए

Truco: LLM के बिना 3 महीने

• 18 जून 2024 से Truco नाम के card game का विकास Go backend के साथ शुरू किया गया। React की केवल बुनियादी जानकारी के आधार पर frontend लिखा गया
• UI implementation सबसे बड़ी चुनौती थी, और server उपलब्ध न कराना पड़े इसलिए TinyGo का उपयोग करके इसे WASM (WebAssembly) में transpile किया गया, फिर static files को GitHub Pages पर deploy किया गया
• उस समय LLM उपलब्ध नहीं था, इसलिए हर बारीकी को खुद समझना, खोजना और कई trial-and-error के बाद लगभग 3 महीने में काम पूरा हुआ
• इसका मकसद विज्ञापन या कमाई नहीं, बल्कि सिर्फ गेम को पूरा करना था, और रिलीज़ के 1 साल बाद भी यह लगातार खेला जा रहा है
  • Truco खेलें: https://marianogappa.github.io/truco-argentino
  • backend (Golang): https://github.com/marianogappa/truco
  • frontend (React): https://github.com/marianogappa/truco-argentino

Escoba: LLM के साथ 3 दिन

• 1 साल बाद, परिवार से मिलने Argentina की यात्रा के दौरान उन्होंने अपने भतीजे को Escoba नाम का दूसरा सबसे लोकप्रिय card game सिखाया
• इस बार LLM (Claude) का उपयोग किया गया। Truco के backend को copy करने के बाद Escoba के rules prompt में समझाए गए और code refactoring करने को कहा गया
• पहले ही prompt में लगभग पूरा implementation सही हो गया, और केवल कुछ छोटे bugs और अतिरिक्त features को हाथ से ठीक करना पड़ा
• frontend में कई दिनों तक खुद implementation/debugging करनी पड़ी। LLM की सीमाएँ, React skills, और WASM में game state manage करने जैसा असामान्य environment—ये सब चुनौती बने रहे
  • Escoba खेलें: https://marianogappa.github.io/escoba-de-15
  • backend (Golang): https://github.com/marianogappa/escoba
  • frontend (React): https://github.com/marianogappa/escoba-de-15

चरण-दर-चरण: अपना गेम कैसे बनाएं

• ताकि कोई भी खुद game development आज़मा सके, इसके लिए न्यूनतम hands-on guide और example code पेश किए गए हैं
• Tic-Tac-Toe का example repository दिया गया है, जिसे fork करके शुरुआत की जा सकती है
  • backend: https://github.com/marianogappa/tictactoe-backend
  • frontend: https://github.com/marianogappa/tictactoe-frontend
  • demo: https://marianogappa.github.io/tictactoe-frontend/

backend development

• turn-based backend में functionality को काफ़ी स्पष्ट रूप से design किया जा सकता है
• serverless structure बनाए रखना, और इंसानों के बीच खेल वाले ढांचे से बचना, यदि commercial server उपलब्ध न हो, तो एक व्यावहारिक विकल्प है

frontend development

• frontend में निम्नलिखित काम करने होते हैं
  • backend से नया GameState बनाने का अनुरोध
  • UI में state दिखाना
  • valid actions चुनने के लिए interface देना
  • action लागू होने पर backend को command भेजना
  • अगर bot की बारी हो, तो backend से अनुरोध करना

backend को WASM में बदलना

• Go code को WASM में build करने के लिए GOARCH=wasm GOOS=js go build का उपयोग किया जाता है
• binary size बड़ा होने की समस्या आ सकती है, इसलिए TinyGo से size कम किया गया
• frontend से जोड़ने वाली functions export करने के लिए Go में अलग entry point (जैसे main_wasm.go) लिखा गया और build के समय branching की गई
• main function में select {} से blocking रखनी पड़ती है ताकि program तुरंत बंद न हो जाए

backend-frontend data integration

• Go के flexible struct जैसे GameState को WASM में सीधे serialize/deserialize नहीं किया जा सकता
• सारा data JSON format में exchange करना पड़ता है
• TinyGo के documentation के अनुसार input और output दोनों को JSON serialization के जरिए आदान-प्रदान किया जाता है

frontend-backend interface

• frontend से backend functions को सीधे call किया जाता है
• GameState केवल WASM के अंदर manage होता है, frontend उसमें mutation नहीं कर सकता; backend ही हमेशा source of truth है
• WASM को दोबारा compile करने के बाद files बदलनी पड़ती हैं, और इसके automation के लिए Makefile का उदाहरण दिया गया है

WASM runtime environment

• इसे चलाने के लिए wasm_exec.js को head में include करना होता है, और उसी script की मदद से instance बनाकर execute किया जाता है

निष्कर्ष

• गेम बनाना एक आनंददायक अनुभव था, और Go, WASM, React का संयोजन ऐसा तरीका है जिसे कोई भी आज़मा सकता है
• LLM की मदद से productivity बहुत बढ़ गई, लेकिन frontend skills और debugging experience अब भी बहुत महत्वपूर्ण हैं
• इस architecture के साथ कोई भी खुद गेम development आज़मा सकता है, इसलिए इसे एक बार ज़रूर आज़माना चाहिए

[codong]

अगर React में document.getElementById इस्तेमाल करने वाला code जनरेट हुआ है, तो पता नहीं कौन-सा LLM इस्तेमाल किया गया होगा....

[onetoday]

लगभग clickbait भड़काऊ टाइटल जैसा लग रहा है..
"अगर शुरुआत से बनाओ तो 3 महीने, और वैसा ही कुछ फिर से बनाओ तो 3 दिन"

[savvykang]

लगता है मूल लेखक को ही पता नहीं कि वह आम तौर पर क्या करता है।

[GN⁺]

Hacker News राय

• मुझे इस पोस्ट की जो बात अच्छी लगी, वह यह है कि इसने उस तथ्य की ओर इशारा किया है जिसे बहुत से डेवलपर्स नज़रअंदाज़ कर देते हैं। गेम डेवलपमेंट में कोडिंग खुद बहुत कम ही bottleneck रही है। अकेले काम करने वाला डेवलपर भी AI के बिना mechanics जल्दी बना सकता है। असली मुश्किल ऊपर की वे कई अदृश्य layers हैं, जैसे game loop balancing, difficulty tuning, बिना अटपटापन वाले assets बनाना, और ऐसा polishing करना जो user की रुचि 5 मिनट से ज़्यादा बनाए रख सके। यही वजह है कि LLM के बाद भी Steam बेहतरीन games से नहीं भर गया। टेक्नोलॉजी ने एक barrier ज़रूर कम किया है, लेकिन बड़े barriers अभी भी वैसे के वैसे हैं। 2010s में Unity के उभार के समय भी यही हुआ था। Engine ने game development को लोकतांत्रिक बनाया, लेकिन अच्छे games की विस्फोटक बढ़ोतरी के बजाय सिर्फ कोशिशों की संख्या बढ़ी। LLM code में, और image models art में, यही असर ला रहे हैं, लेकिन कौन-सा game सच में मज़ेदार है यह ये tools नहीं बता सकते। मेरे लिए दिलचस्प सवाल यह है कि अगर AI implementation ही नहीं बल्कि playtesting भी करे तो क्या होगा। यानी अगर वह हज़ारों बार loop चलाकर बता सके कि कौन-से mechanics simulated players को लंबे समय तक बाँधे रखते हैं, तो उसका रोल productivity hack से बढ़कर design partner तक पहुँच जाएगा। हम अभी उस stage पर नहीं हैं, लेकिन यह पोस्ट उस दिशा में जाते शुरुआती data point जैसी लगती है

  • AI अगर सिर्फ implementation नहीं बल्कि playtesting भी करे, हज़ारों loops चलाकर यह समझे कि players को कितना immerse रखा जा सकता है, तो भविष्य कैसा होगा—इस राय पर यह जिज्ञासा होती है कि AI players को simulate कैसे कर सकता है और वह यह सही तरह क्यों समझ पाएगा कि असली इंसान किस चीज़ में डूबेंगे

  • Unity के 2010s उभार वाले उदाहरण में इस बात पर आपत्ति उठानी है कि सच में अच्छे games इतने ज़्यादा नहीं थे। दरअसल XBLA दौर की तुलना में आज हमारे पास जो games की भारी मात्रा है, वह Unity, Godot, Gamemaker, Renpy, RPG Maker जैसे tools के बिना संभव नहीं होती। यानी सिर्फ quality में नहीं, quantity में भी साफ़ तौर पर जबरदस्त बढ़ोतरी हुई है

  • मेरे लिए generative AI की litmus test यह है कि वह 2D pixel art action game के लिए पूरा spritesheet बना सके। मसलन tank या main character की movement ही सही, उसे बिल्कुल सही निकालना लक्ष्य था, लेकिन अब तक मैंने कोई सफल उदाहरण नहीं देखा

  • मुझे लगता है कि "AI आपको यह नहीं बता सकती कि आपका game वास्तव में मज़ेदार है या नहीं" यही मुख्य insight है। AI इंसानों की तरह किसी game का अनुभव नहीं कर सकती, या किसी और अनुभव का भी नहीं। वह बस मिलते-जुलते games पर उपलब्ध human evaluation data देखकर कुछ हद तक अनुमान लगा सकती है। यानी AI आपके game का आनंद नहीं ले सकती। यही बुनियादी सच आगे AI युग में लोगों की भूमिका को परिभाषित करेगा। AI documents या code जैसी चीज़ें पुराने data के आधार पर कुछ हद तक इंसानों जैसी लिख सकती है, लेकिन अर्थपूर्ण integration और अनुभव ऐसे हैं जो सिर्फ इंसान ही कर सकते हैं। इंसानों की एक ऐसी value है जिसे बदला नहीं जा सकता, बस हमें उस value को देखने का नज़रिया बदलना होगा

  • यह pattern game development के बाहर दूसरे क्षेत्रों पर भी लागू होता है। जैसा सब उम्मीद करते हैं, agent-based coding में भी जबरदस्त संभावना है, लेकिन कुछ tasks (तेज़ webapp demos, छोटे libraries को जोड़ना आदि) ही अभी असाधारण रूप से तेज़ हुए हैं, जबकि असली बड़े software पर इसका उपयोग अभी भी कमज़ोर है। Model के training का तरीका हो या हमारा इस्तेमाल करने का know-how, दोनों अभी अधूरे हैं। यह हैरान करने वाली बात नहीं है। git भी आने के बाद 5 साल तक सिर्फ elite कंपनियों में ठीक से अपनाया गया था, और आम होने में 5 साल और लगे। अंततः आज हम उससे बहुत परिचित हैं, लेकिन मेरे हिसाब से LLM को git से भी ज़्यादा ठीक से इस्तेमाल करना मुश्किल है। अगर हर product, OSS, blog post के साथ "अब सब खत्म, सब कुछ बदल गया" जैसी अतिशयोक्ति थोड़ी कम होती, तो शायद प्रगति और तेज़ होती। हम अभी भी trial-and-error और experiments के दौर में हैं, और इसमें समय लगेगा। बहुत जल्दी फैसला नहीं करना चाहिए। अगर सचमुच सब हल हो चुका होता, तो कम-से-कम हम कहीं बेहतर software में दबे पड़े होते; लेकिन अभी तो हम मुश्किल से संतुलन बना रहे हैं। फिर भी, किसी नई टेक्नोलॉजी के आने के सिर्फ 1–2 साल में यह काफ़ी प्रभावशाली उपलब्धि है

• LLM की 3 महीने की बढ़त इस बात पर टिकी थी कि उसके पास code था, उसने पिछले game को template की तरह इस्तेमाल किया, और सबसे बढ़कर hand-coding के दौरान जमा हुआ सारा अनुभव और की गई गलतियाँ उसके पीछे थीं

  • पहले लगा था कि यह एक सनसनीखेज शीर्षक होगा, लेकिन असल में "Truco backend को clone करके Claude को Escoba के rules लंबाई से समझाए और फिर उससे code refactor कराया" वाला हिस्सा चौंकाने वाला था। सोचता हूँ कि अगर कोई इंसान खुद refactor करे तो कितना समय लगेगा। शायद 3 दिनों से ज़्यादा लगे, लेकिन शायद नहीं भी

  • एक और बात, यह महत्वपूर्ण है कि यह game प्रतिभागी का पहला game था। यानी पहली कोशिश में आपको ढेरों अनजान variables से जूझना पड़ता है, लेकिन अगर आपने एक बार यह अनुभव ले लिया और उससे insight और know-how हासिल कर लिया, तो दोबारा शुरू करने पर LLM के बिना भी 3 महीनों से बहुत कम समय में बनाया जा सकता है

  • दरअसल मैंने खुद अनुभव किया है कि एक ही project को दूसरी या तीसरी बार दोहराने पर जो काम पहली बार कुछ महीने लेता है, वह अगली बार लगभग 1/3 समय में हो जाता है

• <i>खँखार</i> मैंने 24 घंटे के अंदर भी development करके देखा है, nordicgamejam.com पर उदाहरण हैं। मैं सिर्फ यह कहना चाहता हूँ कि LLM, GenAI, और Unity से पहले के दौर में Microsoft XNA और C# ही सबसे अच्छा विकल्प थे। Art भी ज़्यादातर Paint में बने हाथ के rough drawings जैसी होती थी। फिर भी हर साल पर्याप्त मज़ेदार games बनते थे, और Baba is You, Braid जैसे कुछ cases तो आम लोगों तक भी पहुँचे। Coding bottleneck नहीं थी; मेरे हिसाब से असली bottleneck टीम के सदस्यों के बीच communication था

  • टीम के भीतर communication एक महत्वपूर्ण bottleneck है—इस बात में जोड़ना चाहूँगा कि अपने ही मन के भीतर की 'communication' भी कई बार हैरान कर देने वाली हद तक मुश्किल होती है

• इस comment thread को देखकर लगता है कि यहाँ कई लोग ऐसे हैं जिन्हें game development का अनुभव नहीं है। सच तो यह है कि जिन projects में LLM इस्तेमाल हो रही है, वे पहले से training data में बहुत मिलते हैं। उदाहरण के लिए, यह programming intro courses में मिलने वाला project type भी है, और दक्षिणी यूरोप के देशों में इस blog post में बताए गए card game जैसे games सचमुच बहुत हैं। मैंने भी college के पहले साल में बिना किसी अनुभव के Moon Patrol को Python में scratch से बनाया था, जिसमें 2–3 महीने लगे और हफ़्ते में 3 रातें जागकर coding करनी पड़ी। Card game बनाना तो उससे भी आसान है। LLM ज़रूर कुछ हिस्सों में उपयोगी है, लेकिन ऐसे सरल उदाहरण LLM की coding productivity या utility को benchmark करने के लिए उपयुक्त नहीं हैं

• मैंने LLM के साथ कई दिनों में थोड़ा-थोड़ा समय देकर ऐसा काम किया था: stacky। असल में कुल मिलाकर लगभग दो दिन काम किया। शुरुआत में ground-up development था, बाद में brownfield शैली में लिखा, और शुरू में इसे बहुत गंभीरता से पूरा करने का इरादा भी नहीं था। लेकिन जैसे-जैसे details और features जोड़ता गया, ideas बढ़ते गए (super rotation, DAS आदि)। अभी भी यह पूरे game का सिर्फ 10–20% है और अधूरा है। WebGL version भी चल रहा है। लेकिन अगर मैं बहुत ultimate Tetris बनाने की कोशिश करता, तो शायद मुझ पर मुकदमा हो जाता, और वैसे license fees देने की हैसियत भी नहीं है, इसलिए रुक गया। अंत में हाथ क्या आया—confidence और experience। हाल में HN पर parametric functions के बारे में एक link देखकर मैंने 1–2 घंटे में playground graphy भी बना डाला। वहाँ भी details पर बहुत समय लगने लगा। अगर आपको साफ़ पता हो कि आप क्या चाहते हैं, तो LLM के साथ इस तरह का काम काफ़ी मज़ेदार हो सकता है

  • Tetris की यह reimagination शानदार है। बस जानकारी के लिए: नए MacBook Pro M4 Max और Firefox के combination पर cores 100% usage तक पहुँच जाते हैं और fan बहुत तेज़ चलने लगता है

• मैं काफ़ी समय से एक निश्चित स्तर से ऊपर hobby game development लगातार करता रहा हूँ और कई games पूरे भी किए हैं। लेकिन इस पूरी comment thread में लगता है कि असली game development का अनुभव बहुत कम है। मैं इस बात से सहमत नहीं हो सकता कि game development में coding आसान हिस्सा है। ताज़ा idea या genre variation mechanics सोचना बल्कि आसान लगता है, जबकि उन्हें असल में code में उतारना कहीं ज़्यादा मुश्किल है। उदाहरण के लिए, multiplayer Vampire Survivors में BattleMech customization जोड़ने की कल्पना करना आसान है, लेकिन सिर्फ LLM के सहारे उसे implement करना लगभग असंभव है। इस बार का मामला पहले से पूरी तरह ज्ञात card game rules का है, इसलिए यह snake game जितना ही सरल है। यह post लिखने वाले पर हमला नहीं है; बस यह कहना है कि बहुत से लोग बिना वास्तविक game development अनुभव के development पर राय दे रहे हैं

  • मैं इस दावे से सहमत नहीं हूँ कि coding game development का कठिन हिस्सा है। मुश्किल तो हो सकती है, लेकिन असली कठिनाई नए और मज़ेदार ideas सोचने में है। अगर आपके पास अच्छा idea है, तो उसे छोटे हिस्सों में तोड़कर दोहराते हुए अंततः implement किया जा सकता है। असली बाधा वह क्षण है जब आप खाली पन्ने के सामने तय करते हैं कि बनाना क्या है। टहलने निकलना, तरह-तरह के प्रयोग करना—यह कला में हज़ारों सालों से दोहराई जाती रही समस्या है। दूसरी ओर coding आखिरकार एक engineering task है। मैं भी हाल में game development सीख रहा हूँ और साथ में maths भी पढ़ रहा हूँ, लेकिन vector maths या quaternions सीखना "मैं किस तरह का game बनाना चाहता हूँ?" यह तय करने से कहीं आसान लगा

  • मूल रूप से सहमत हूँ, लेकिन मेरे लिए तो उल्टा रहा है: नए ideas सोचना या creative experiments करना हमेशा ज़्यादा कठिन रहा। लगभग किसी भी game mechanic को code कर सकता हूँ, लेकिन writing/creativity वाला हिस्सा बहुत कठिन लगता है। अगर किसी के लिए वह आसान है, तो वह सचमुच भाग्यशाली है। यह सबके लिए स्वाभाविक नहीं होता

• अगर आप पूरी तरह client-side game बनाने वाले हैं, तो फिर इसे ऐसे क्यों लिखा जा रहा है जैसे "backend" ज़रूरी हो, और पूरे app के बजाय सिर्फ backend के लिए अलग tech stack क्यों इस्तेमाल हो रही है—यह समझ नहीं आता

• मुझे लगता है कि software industry में वह क्षेत्र लगभग खत्म हो चुका है जहाँ ideas को जल्दी और आसानी से साकार किया जा सकता था। अब competition इतना तीव्र है कि चाहे आप कितना भी छोटा market पकड़ें, आपका मुकाबला global VC और global AI से होता है। पहले कम-से-कम ऐसी niche मिल जाती थी जिसमें बड़ी कंपनियों की दिलचस्पी नहीं होती। अब चाहे बड़ा VC-backed क्षेत्र हो या niche, हर हाल में पूरी दुनिया से मुकाबला करना पड़ता है। नतीजतन अब सिर्फ दो तरह की जगहें बचती हैं: या तो छोटे market जहाँ बेहद जटिल tech चाहिए, या फिर कम मुनाफ़े वाले, ज़्यादा failure risk वाले, छोटे lifecycle वाले क्षेत्र (और ज़्यादातर games इसी में आते हैं)। पहले मामले में आपको जाकर-जा कर product समझाने जैसी marketing करनी पड़ती है। Game industry के अनुभव से कहूँ तो development stage में घुसने से पहले ही बड़ी सफलता का मतलब होता है "दस लाख views मिलना और 6 महीने बाद पूरी तरह ठंडा पड़ जाना"। Recurring revenue लगभग न होने की वजह से शुरुआत करना ही बहुत demotivating है। Minecraft जैसा game बनाना लगभग lottery जैसा है। लेकिन game industry कम-से-कम दूसरे software sectors की तुलना में meritocratic है। Quality और fun का adoption से कुछ-न-कुछ संबंध होता है। दूसरी industries regulation, network effects से बने monopolies, या government control जैसी भूलभुलैया हैं। कभी-कभी लगता है, काश सरकार शुरुआत में ही बता दे कि "यह क्षेत्र तो पहले से इस कंपनी के कब्ज़े में है, startup मत करो, कहीं और जाओ", ताकि लोग 1 साल बर्बाद न करें

• सोचता हूँ, लोग कब समझेंगे कि greenfield (पूरी तरह नया) project agent coding skills को benchmark करने के लिए सबसे खराब case है

• मुझे LLM इसलिए पसंद हैं क्योंकि वे code को उस तरीके से handle करने में मदद करते हैं जो मेरे दिमाग में programs की abstraction के ज़्यादा करीब है। मैं code पढ़ते समय उसे मानो AST की तरह समझता हूँ—functions और calls को input और output वाले abstract nodes में बदलकर। LLM की वजह से इसका उल्टा करके उसे code में उतारना बेहद आसान हो गया है। अब ideas के हिसाब से code examples ढूँढते फिरने या याददाश्त पर ज़ोर डालने की ज़रूरत नहीं; बस LLM से कहो कि WiFi initialization जैसा boilerplate code लिख दे। नतीजतन मैं Lego blocks की तरह programs assemble कर पाता हूँ। LLM से पहले भी यह तरीका संभव था, लेकिन बहुत ज़्यादा मेहनत लगती थी। इसी वजह से आजकल मैं अलग-अलग languages के बीच आसानी से development कर रहा हूँ। मैं शायद language की internal structure या syntax बहुत नहीं सीख पाता, लेकिन यही तो मूल बात है। Language और syntax program के logical flow की तुलना में द्वितीयक details हैं। जैसे machine code से assembly, फिर C और फिर धीरे-धीरे higher-level languages तक विकास हुआ, वैसे ही अब हम coding नहीं बल्कि 'programming' के और क़रीब जाते जाएँगे। इसका अंतिम रूप क्या होगा यह कोई नहीं जानता, लेकिन इतना तय है कि समय के साथ 'लिखने' में कम और 'programming' में ज़्यादा समय जाएगा

  • सहमत हूँ। पहले भी कुछ लोग चिंतित होते होंगे कि अगर कोई C में लिखेगा तो assembly level को सच में नहीं समझ पाएगा और कभी बड़ी मुसीबत में फँस जाएगा, लेकिन हक़ीक़त डेवलपर productivity tools की प्रगति रही। AI का सबसे बड़ा फ़ायदा भी यही है कि वह डेवलपर्स से बहुत obvious repetitive work हटा देती है। पहले C में memory leaks और segmentation faults पकड़ने में समय बर्बाद होता था। अब modern languages में उसकी ज़रूरत कम हो गई है, और उसी तरह implementation details के छोटे examples या documentation ढूँढने का काम भी धीरे-धीरे घटेगा। आखिरकार डेवलपर्स ज़्यादा creative हिस्सों पर ध्यान दे पाएँगे