नमस्ते। हाल ही में मैंने अकेले Sumbi नाम का एक मोबाइल गेम बनाया है। यह Jeju की haenyeo गोताखोरों की समुद्री आजीविका से प्रेरित एक portrait roguelike है। एक ही सांस में समुद्र में उतरकर seafood इकट्ठा करना, और फिर यह तय करना कि थोड़ा और लालच करें या अभी लौट आएँ — यही इस गेम का मूल है।
2 जुलाई को डिज़ाइन शुरू किया, 9 जुलाई को Google Play पर पहला build अपलोड किया, और खेलते हुए जो हिस्से कमजोर लगे उन्हें लगातार सुधारते हुए 19 जुलाई तक v1.1 build भी production में अपलोड कर दिया।
शुरू से मेरी जिज्ञासा सिर्फ यह नहीं थी कि “AI कितना तेज़ कोड लिख सकता है।” मैं यह आज़माना चाहता था कि अगर कई AI models को अलग-अलग भूमिकाएँ देकर एक development team की तरह चलाया जाए, तो वे मिलकर वास्तव में रिलीज़ करने लायक गेम कहाँ तक बना सकते हैं।
यह कैसा गेम है
Sumbi नाम haenyeo गोताखोरों के गोता पूरा करके सतह पर लौटने के बाद निकलने वाली सीटी जैसी सांस, sumbi-sori, से लिया गया है।
एक run लगभग 10–30 सेकंड की होती है। एक हाथ से haenyeo को चलाकर आप और गहराई में जा सकते हैं या आसपास का seafood इकट्ठा कर सकते हैं। लेकिन इकट्ठा की हुई चीजें पूरी तरह तभी मिलती हैं जब आप सुरक्षित सतह तक वापस पहुँचें, इसलिए हर बार तौलना पड़ता है कि थोड़ा और लालच करें या अभी लौट जाएँ। ऊपर आने पर आप इकट्ठा की हुई चीजों का हिसाब करते हैं, फिर lung capacity, fins, net basket, और observation बढ़ाकर दोबारा dive करते हैं।
हर run में तीन abilities में से एक चुनने वाला roguelike draft, 60 प्रकार की seafood encyclopedia, equipment और growth tree, haenyeo rank promotion, और 100m तक जाने वाली underwater route डाली है। Controls को सरल रखा, लेकिन बार-बार dive करने पर आपके target records और builds बदलते रहें — ऐसा बनाया।
मैंने AI को एक सर्वगुणसंपन्न developer की तरह इस्तेमाल नहीं किया
अगर एक ही model डिज़ाइन से लेकर implementation और self-review तक सब कुछ संभाले, तो उसके लिए अपनी ही मान्यताओं को सही उत्तर मान लेना आसान हो जाता है। इसलिए मैंने भूमिकाएँ इस तरह बाँटीं।
- Fable 5: गेम structure और feature spec, economy balance goals, completion conditions का डिज़ाइन
- Opus 4.8: Flutter·Flame implementation, tests लिखना, debugging
- Fable 5: शुरुआती spec और implementation results का दोबारा मिलान, omissions और regressions की जाँच
- Codex GPT-5.5: code और changes का स्वतंत्र review, और edge cases की पहचान
काम का क्रम मोटे तौर पर डिज़ाइन → implementation → मूल डिज़ाइनर द्वारा पुनः सत्यापन → स्वतंत्र code review → automated tests और hands-on play था।
यह करते हुए महसूस हुआ कि prompt को आकर्षक ढंग से लिखने से ज़्यादा ज़रूरी पहले ऐसे completion conditions तय करना था जिन्हें verify किया जा सके। “growth feel अच्छा बना दो” कहने के बजाय मैंने शुरुआती 10 मिनट में purchases की संख्या, पहली promotion तक लगने वाला समय, और क्या growth के किसी चरण में ऐसा लंबा समय आता है जब खिलाड़ी कुछ भी खरीद न सके — जैसी चीजें संख्याओं में तय कीं। फिर उन्हें economy simulator और tests से जाँचा।
फिलहाल automated tests 627 हैं और सभी pass करते हैं। Flutter static analysis भी app code, tests, और tools scope में बिना किसी error के pass होता है।
AI के भरोसेमंद दिखने वाले लेकिन गलत जवाबों के उदाहरण
पहला डिज़ाइन तुरंत मज़ेदार गेम नहीं बन गया था।
शुरुआती version में एक run में इकट्ठा करने लायक targets सिर्फ 5–9 थे। इकट्ठा करने का गेम होते हुए भी समुद्र खाली-खाली लगता था। खुद खेलकर मैंने यह structure छोड़ दिया। बाद में इसे ऐसा बदला कि growth के साथ field अधिक समृद्ध लगे, और जहाँ से चीजें इकट्ठा की गई हों वहाँ फिर से seafood उग आए। कुछ खास growth builds में एक run में लगभग 40 तक चीजें इकट्ठा की जा सकती हैं।
growth tree में भी यही समस्या थी। Nodes 290 थे, लेकिन असली gameplay लगभग सीधी रेखा जैसा था। AI ने “290 nodes” की requirement पूरी कर दी, लेकिन चुनने का मज़ा नहीं बनाया। आखिरकार मैंने इसे फिर से बाँटकर तीन specialization paths और permanent nodes की structure बनाई।
AI बहुत सारा code तेज़ी से बना सकता है, लेकिन वह मज़ा और priorities की गारंटी नहीं देता। खुद खेलते हुए “यह मज़ेदार नहीं है” या “features बहुत हैं, लेकिन अगला goal दिख नहीं रहा” जैसी साफ़ बात कहना अभी भी इंसान का काम था।
images और sound के लिए भी मैंने खुद pipeline बनाई
haenyeo character, seafood, equipment, और card icons जैसे मुख्य image assets मैंने GPT image generation API से बनाए। बने हुए sheets को सीधे इस्तेमाल नहीं किया; पहले उन्हें correction pipeline से गुज़ारा, जिसमें chroma key removal, frame alignment, size normalization, और pixel quantization शामिल थे, फिर verify किया। Background, bubbles, light rays जैसी चीजें ज़्यादातर code से draw कीं।
sound के लिए बाहर से assets इकट्ठा करने के बजाय मैंने Dart code से WAV synthesize किया। dive के अंत में सुनाई देने वाली sumbi-sori को मैंने गेम के नाम और एक run के अंत को जोड़ने वाली मुख्य sound के रूप में रखा।
इसे बनाने के बाद मेरी सोच कैसे बदली
अक्सर कहा जाता है, “AI को सही निर्देश दो, तो वह अच्छा काम करता है।” इस बार मैंने इससे भी ज़्यादा यह सीखा कि “जब AI गलत हो, तब उसे पकड़ने की structure होनी चाहिए।”
मैंने designer, implementer, और reviewer को अलग रखा, और अलग-अलग models से plan और code को आक्रामक ढंग से जँचवाया। अंतिम फैसला numbers, tests, और real play पर छोड़ा। यह तरीका, एक ही model के साथ लंबी बातचीत जारी रखकर सब कुछ उसी से करवाने की तुलना में, कहीं अधिक stable था।
AI तेज़ हो जाने पर भी solo development की bottlenecks खत्म नहीं हुईं। बल्कि bottleneck की जगह coding से हटकर judgment पर आ गई। क्या रखना है, क्या हटाना है, और अभी मज़ा क्यों नहीं आ रहा — यह तय करना सबसे ज़्यादा समय लेने वाला काम था।
Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi
यह अभी भी मेरे द्वारा अकेले बनाया गया गेम है, इसलिए इसमें कमियाँ बहुत हैं। मैं यह जानना चाहता हूँ कि यह मज़ेदार नहीं लग रहा, या growth menu ज़रूरत से ज़्यादा जटिल तो नहीं है। development process या model-wise role division पर भी आप बेझिझक सवाल छोड़ सकते हैं।
अभी कोई टिप्पणी नहीं है.