सारांश
- कोड संरचना (strategy·factory pattern, file separation,
.cursorrulesव्यवस्थित करना) को एक लाइन के प्रॉम्प्ट से refactor करने के बाद, वही feature-addition प्रॉम्प्ट चलाने पर AI token usage में बड़ी कमी आई—ऐसी एक प्रयोग रिपोर्ट (Zero-context, N=5)। प्रयोग में इस्तेमाल किए गए प्रॉम्प्ट और source सार्वजनिक हैं, इसलिए इसे दोहराया जा सकता है।
मुख्य डेटा
-
Claude-4 Sonnet: औसत 390,159 → 242,265 tokens (−37.91%)
-
GPT-5: औसत 315,839 → 233,634 tokens (−26.03%)
-
मानक: Cursor द्वारा दिखाए गए Total Tokens। मॉडलों के बीच absolute values की तुलना सार्थक नहीं है (मॉडल-वार aggregation में अंतर)।
सेटिंग्स (संक्षेप)
-
IDE Cursor 1.6.6, मॉडल GPT-5 / Claude-4 Sonnet
-
सभी प्रॉम्प्ट Zero-context, हर राउंड में editor पूरी तरह restart
-
सफलता का मानदंड: single prompt से requirements implement होने पर उसे success माना गया
यह क्यों महत्वपूर्ण है
-
“अच्छी code structure” सिर्फ इंसानों के लिए पढ़ने में आसान नहीं होती, बल्कि AI के token, cost और time पर भी असर डालती है—इसका मात्रात्मक प्रमाण
-
प्रॉम्प्ट और repository सार्वजनिक होने से reproducibility सुनिश्चित होती है (व्यावहारिक उपयोग और आगे के experiments में तुरंत लागू किया जा सकता है)
व्यक्तिगत राय
- Cursor उपयोगकर्ता के रूप में, यह cost savings के लिए एक अहम methodology देने वाला शानदार प्रस्ताव लगता है।
- जैसा कि मुख्य लेख में भी है, sample size पर्याप्त न होना थोड़ी कमी लगती है।
34 टिप्पणियां
लगता है आपने हेडलाइन लिखने की ट्रेनिंग ली है..
प्रयोग बहुत दिलचस्प था, अच्छी तरह देखा।
धन्यवाद।
मुझे लगता है कि सामग्री से अलग, सिर्फ़ "एक लाइन के prompt" वाले शीर्षक की वजह से मैं कुछ और देखने आया था, इसलिए लेख की सामग्री और अपेक्षा के बीच का फर्क ज़्यादा महसूस हुआ।
हाँ, मैं भी यही सोचता/सोचती हूँ. T_T
माफ़ कीजिए;;
इस लेख में इतनी रुचि दिखाने के लिए धन्यवाद। चूँकि इसका मुख्य उद्देश्य overseas distribution था, इसलिए लेख अंग्रेज़ी में लिखा गया था, और लगता है कि इसके कारण तरह-तरह की समस्याएँ पैदा हो रही हैं.
इसीलिए, मैं इसका कोरियाई में व्यवस्थित किया गया पोस्ट साझा कर रहा हूँ.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
इसके अलावा, इस्तेमाल किए गए प्रॉम्प्ट से जुड़ी बातों का सार साझा कर रहा/रही हूँ.
किसी भी हालत में, डेवलपर्स के लिए structure improvement वाले प्रॉम्प्ट लिखना ज्यादा फायदेमंद रहता है. हर प्रोग्राम की प्रकृति अलग होती है, इसलिए high-efficiency improvement के लिए कुछ हद तक development knowledge की जरूरत होती है.
लेकिन इसका मतलब यह नहीं है कि non-developer vibe coders इस तरीके का इस्तेमाल नहीं कर सकते. efficiency में फर्क हो सकता है, लेकिन
프로젝트 코드 정리좀 해줘. 사용하지 않는 코드들은 제거해.जैसी simple command से भी AI files और classes को अलग करके व्यवस्थित करने जैसा काम करता है.हालांकि, structure improvement की detail में अंतर efficiency में अंतर पैदा कर सकता है, इसलिए संदर्भ सामग्री देखते समय सावधानी जरूरी है.
क्या मतलब यह है कि prompt में सिर्फ़ ज़रूरी बातें ही तार्किक तरीके से जोड़नी चाहिए? यानी prompt में जितनी ज़्यादा इधर-उधर की बातें जोड़ेंगे, उतना noise बढ़ेगा, और नतीजे में आने वाला code भी उतना ही ज़्यादा जटिल और noisy हो जाएगा?
मुख्य बात यह है कि AI को code structure refactoring करने का निर्देश देने के बाद खपत होने वाले tokens की मात्रा कम हो गई।
इसके उलट, यह भी कहा जा सकता है कि अगर code में structural defects की स्थिति में ही commands देते रहें, तो token usage बढ़ जाता है।
संक्षेप में, बात source code की structure improvement होने की है; इसका मतलब यह नहीं है कि prompt में सिर्फ़ मुख्य बातें ही तार्किक ढंग से रखनी चाहिए।
मुझे भी यह परिचय और मूल लेख इतने ज़्यादा लंबे-चौड़े और ऐसे लगे जैसे किसी ऐसे व्यक्ति ने लिखे हों जो लिखने में बहुत अच्छा न हो, इसलिए पढ़ते समय दिक्कत हुई।
सार यह है
"टोकन कम करने वाली संरचनात्मक बाधाएँ शामिल करने वाला एक एक-पंक्ति निर्देश जोड़ें"
इतना कहा जा सकता है।
यह लेख 'प्रयोग' शोध के अधिक करीब है,
इसलिए, इस लेख में शामिल सभी संख्यात्मक आँकड़े इस बात पर केंद्रित हैं कि इसे पढ़ने वाला हर व्यक्ति 'पुनरुत्पादन' कर सके।
इसी कारण, इस्तेमाल किया गया मूल source code और परीक्षण में उपयोग की गई सभी प्रक्रियाएँ पूरी तरह दर्ज की गई हैं,
ताकि सभी प्रयोगकर्ताओं को समान परिणाम मिल सकें, और सामग्री का फोकस इसी जानकारी को देने पर है।
टिप्पणियों का माहौल देखकर मुझे लगता है कि,
आगे से शायद 3-पंक्ति सारांश वाले एक लेख और,
विस्तार जानना चाहने वालों के लिए अलग लेख — इस तरह दो लेख लिखने चाहिए।
अगर आप बता दें कि इस लेख का कौन-सा हिस्सा जरूरत से ज्यादा जटिल या बहुत लंबा लगा,
तो आगे लेख लिखने में मुझे बहुत मदद मिलेगी।
मुझे भी कुछ हद तक ऐसा ही लगा।
लेखक की मंशा क्या थी, यह मैं समझ सकता हूँ, लेकिन जो किया गया है उसकी तुलना में लेख कुछ ज़्यादा ही जटिल लगता है।
शायद आप प्रयोग में इस्तेमाल किए गए details को ज़्यादा से ज़्यादा लेख में शामिल करना चाहते थे, इसलिए इसे इस तरह लिखा गया होगा।
लेकिन अगर आप सिर्फ़ मुख्य बिंदुओं को संक्षेप में चुनकर लिखें, तो इस विषय में रुचि रखने वाले लोग शायद आसानी से समझ सकेंगे।
अगर आप बेझिझक details कम करके सिर्फ़ सार रखें, तो शायद यह और बेहतर होगा।
मुझे लेखक की मंशा और परिणाम, दोनों अपने आप में दिलचस्प लगे।
मुख्य तर्क शायद यह है कि बेहतर source code कम token खपत की ओर ले जाता है,
और उसी से संबंधित experiment design करके उसे चलाया गया लगता है।
जहाँ तक मैंने प्रयोग को समझा है, उसे इस तरह सूचीबद्ध कर सकता हूँ:
शायद यही प्रक्रिया थी।
और अगर मेरी समझ सही है, तो निष्कर्ष यह लगता है कि prompt से pre-process किया गया source code आम तौर पर कम token खर्च करता है।
निष्कर्ष दिलचस्प है, लेकिन experiment पर मेरी राय इस प्रकार है।
यह निष्पक्ष तुलना नहीं है
संख्याओं में कमी दिखती है, लेकिन तुलना source code को process करने में लगे कुल tokens के आधार पर होनी चाहिए।
दूसरे शब्दों में, pre-processing के लिए इस्तेमाल हुए tokens की संख्या भी ध्यान में रखी जानी चाहिए।
अगर pre-processing में इस्तेमाल tokens बहुत ज़्यादा थे, तो वास्तव में कुल token खपत बढ़ गई होगी और यह निष्कर्ष अर्थहीन हो सकता है; और अगर वे कम भी हों, तब भी वास्तविक token खपत का अंतर लेख में दिख रहे अंतर से काफ़ी कम हो सकता है।
pre-processing से पहले और बाद के source code की तुलना करना ज़रूरी है
अगर pre-processing में इस्तेमाल हुए tokens को अलग रख दें, तो query के समय token खपत में कमी अर्थपूर्ण लगती है।
लेकिन source code में ठीक कौन-सा अंतर इस कमी का कारण बना, इसका विश्लेषण किया जाए तो लेख का महत्व और बढ़ सकता है।
क्योंकि इसका मतलब होगा कि उस अंतर को अधिकतम करने के लिए pre-processing prompt optimization संभव है।
लेखक कहते हैं कि code structure refactoring से यह परिणाम आया, लेकिन मैं इससे सहमत नहीं हूँ; मेरा मानना है कि अभी यह निश्चित रूप से नहीं कहा जा सकता।
क्योंकि यह भी संभव है कि AI से refactoring के अलावा किसी और हिस्से में सुधार करवाने पर भी token खपत घटे।
और अधिक विविध प्रयोगों की ज़रूरत है
मेरा मानना है कि मौजूदा code के अलावा दूसरे codebase पर भी यही experiment चलाना चाहिए।
तभी यह तय किया जा सकेगा कि यह परिणाम लगातार अच्छा आता है या नहीं।
हालाँकि व्यावहारिक रूप से यह test करना कठिन हो सकता है, इसलिए इसे अभी सिर्फ़ संदर्भ के तौर पर लेना बेहतर होगा।
मैं पूरी तरह सहमत हूँ। इस तरह की आलोचना का मैं दिल से स्वागत करता हूँ।
दुनिया में कोई अकेला नहीं जीता, और हर व्यक्ति की क्षमता या परिस्थिति अलग होती है।
मैं भी आखिरकार सिर्फ एक डेवलपर हूँ, और अपनी व्यक्तिगत लागत से सभी टेस्ट नहीं कर सकता।
मेरी आशा है कि यह लेख एक बीज बने, बहुत से लोगों पर अच्छा प्रभाव डाले, और आगे होने वाले अनेक शोधों के लिए एक शुरुआती बिंदु बने।
सबटाइटल सामग्री के साथ पूरी तरह मेल नहीं खाता। अगर इसे फिर से व्यवस्थित करें, तो 'टोकन में कमी लाने वाले अधिक स्पष्ट कारकों के विश्लेषण की ज़रूरत है' सबटाइटल के रूप में अधिक उपयुक्त लगता है.
इस बात के कई हिस्सों से मैं सहमत हूँ। हालांकि, इस लेख की प्रकृति में 'इस लेख को पढ़ने वालों के लिए व्यावहारिक लागू करने के तरीके सुझाना' वाला तत्व भी शामिल है.
पहले से ही, इस लेख पर लगे कमेंट्स को देखकर माहौल का अंदाज़ा लगाया जा सकता है। मुझे भी हाल ही में पता चला, लेकिन ऐसा अनुमान है कि AI उपयोगकर्ताओं में non-developer vibe coders भी काफ़ी हैं.
अगर AI के बिना, लेखक द्वारा सीधे समायोजित किए गए code से शानदार परिणाम निकलते हैं,
तो इसे आसानी से ऐसे देखा जा सकता है कि लेखक अपनी development skill का प्रदर्शन कर रहा है और AI की क्षमता को कम करके दिखा रहा है.
इसीलिए, मैंने ऐसे उदाहरण को लिया जिसे कोई भी महसूस कर सके, और उसका माध्यम 'prompt' जैसा तत्व बनाया जिसे आम vibe coders भी इस्तेमाल कर सकें.
आशा है कि इस शोध के बाद, AI token usage को प्रभावित करने वाले कारकों को और अधिक बारीकी से विभाजित करने वाले शोध आगे जारी रहेंगे.
अगर 1 बार के structural revision के ज़रिए n बार के prompt की token consumption rate को कम करने का प्रभाव मिलता है, तो token reduction की मात्रा उसी तरह किए जाने वाले n बार में परिलक्षित होगी।
n एक ऐसा मान है जो project के उद्देश्य, features की संख्या, और इसके लिए आवश्यक code की मात्रा व जटिलता से तय होता है,
और हाल में cursor / claude code agent भी infinite repetition या AI के अनियंत्रित token उपयोग की समस्या को हल करने के लिए execution unit को छोटा रखने वाले updates ला रहे हैं,
इसलिए मेरा मानना है कि project complexity से जुड़े n मान पर शोध अलग से किया जाना उचित है।
यहाँ जो बात नहीं छूटनी चाहिए, वह यह है कि structure में improvement, code development से पूरी तरह स्वतंत्र होकर होने वाली क्रिया बिल्कुल नहीं है।
यह शुरुआती prompt, या AI ruleset (
.cursorrules) जैसी constraints के माध्यम से base context के रूप में प्रभाव डाल सकता है,और project development cycle के दौरान 1 बार का structural improvement हर समस्या का समाधान नहीं कर सकता।
अर्थात, तय अंतराल पर code improvement की योजना बनाने की बजाय base context के रूप में सही structure guidance देना बेहतर दिशा है।
साथ ही, base context के रूप में structure-guiding prompt rules होने और न होने की स्थितियों पर शोध भी अलग से किया जाना उचित लगता है।
बिंदु 1 को संक्षेप में कहें तो,
इसलिए यह कहना कि 1 बार के structural improvement prompt command की token usage को जोड़कर गणना करनी चाहिए, उचित नहीं है।
मुझे ठीक से समझ नहीं आ रहा कि आप कमेंट में क्या कहना चाह रहे हैं। मेरी टिप्पणी यह थी कि अगर दोनों तरीकों की निष्पक्ष तुलना करनी है, तो कुल खर्च हुए tokens की संख्या की तुलना नहीं करनी चाहिए क्या? क्या refactoring में भी tokens खर्च नहीं होते?
इसके अलावा, आपने जो जवाब दिया है वह न तो लेख में लिखा हुआ लगता है और न ही ऐसा लगता है कि उस पर कोई experiment किया गया है। मेरा समझना है कि आप यह कह रहे हैं कि per-query token comparison की बजाय, कई बार query करने पर refactoring overhead कम हो जाता है और हर query पर अपेक्षित tokens की संख्या घटने से कुल token count में फायदा होगा। लेकिन यह बात तभी सही होगी जब कई queries के दौरान भी, जैसा आप सोच रहे हैं, cost down बना रहे। यह मुझे बहुत ideal स्थिति मानकर कही गई बात लगती है। इस बात की कोई गारंटी नहीं दी जा सकती कि refactoring से होने वाला cost down अगली queries की संख्या से स्वतंत्र होकर बना रहेगा, और बिना experiment के इसे मान भी नहीं लेना चाहिए। अगर आप अपनी मंशा के मुताबिक यह दावा करना चाहते हैं, तो 1 से अधिक queries पर होने वाले cost down को experiment से दिखाना चाहिए। लेकिन क्या आपने experiment सिर्फ 1 बार ही किया और उसी की तुलना की है?
साथ ही, यह सिर्फ मेरी एक धारणा है, लेकिन अगर एक ही लक्ष्य (ideal final output) के लिए queries को अनंत बार दोहराया जाए, तो ideal स्थिति में refactoring हो या न हो, code को अंततः एक ही रूप में converge करना चाहिए। (ideal final output अद्वितीय है)
अगर यह एक उचित धारणा है, तो queries दोहराए जाने के साथ refactoring होने या न होने का अंतर कम होता जाएगा, इसलिए token cost down का लाभ भी धीरे-धीरे कम होगा। इसलिए macro स्तर पर सोचें, तो अगर इस cost down का लाभ पर्याप्त समय तक बना नहीं रहता, तो queries में इस्तेमाल होने वाले कुल tokens की संख्या का अंतर शायद meaningful न भी हो सकता है, क्या ऐसा नहीं है?
और, आपने prompt chaining की संख्या वाले प्रयोग के बारे में भी पूछा था।
असल में, उलटे तौर पर देखें तो यह लेखक के लिए बोलचाल की भाषा में कहें तो धोखा देने का एक अच्छा तत्व भी बन सकता है।
development की प्रक्रिया में आगे बढ़ने के लिए अपने-आप में बहुत सारे विकल्प होते हैं, और अगर prompts को इस तरह जमा कर दिया जाए कि token usage ज्यादा बढ़ने लगे, तो वह आंकड़ा snowball की तरह और भी बड़ा होता जाएगा।
शोध में 'Cumulative Science' नाम की एक दर्शन-धारा है।
कम-से-कम मेरे मानदंड के अनुसार, मुझे अब तक एक बार के command में token usage पर कोई शोध कभी नहीं मिला,
इसलिए तुरंत N बार का शोध करने के बजाय, मैंने एक निश्चित single-run test और उसके निष्कर्ष पर ध्यान केंद्रित किया,
और N बार वाला शोध इस प्रयोग के बाद आगे की कड़ी के रूप में जारी रखा जा सकता है।
साथ ही, एक दूसरी पोस्ट में मैंने codebase के अंतर के अनुसार AI के व्यवहार में आने वाले फर्क पर भी बात की थी.
(यह भी GeekNews में परिचित कराया गया था: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
संक्षेप में कहें तो, इसमें यह test और उसके नतीजे शामिल हैं कि AI को input के रूप में दिए जाने वाले codebase के अनुसार output की quality बदल जाती है.
शुरुआती codebase की quality और दिशा के आधार पर, आगे बनने वाले code की quality बनी रह सकती है, या लगातार खराब भी हो सकती है.
यानी, project के शुरुआती चरण में refactoring की cost और काफी आगे बढ़ चुके project में refactoring की cost में बहुत बड़ा अंतर हो सकता है.
अगर प्रश्न पूछने वाले डेवलपर हैं, तो हो सकता है आपने 'पाल-नाव पर विमानवाहक पोत' जैसी अभिव्यक्ति कभी सुनी हो.
Refactoring किस समय की जानी चाहिए, या project की शुरुआती philosophy और design के अनुसार इसकी लागत कितनी बदल सकती है, यह एक गहन विषय है.
इसे एक variable के रूप में शामिल करके निष्कर्ष को अस्थिर बनाने के बजाय,
मैंने ऐसा test किया जिसे कम-से-कम इस निष्कर्ष के साथ साफ़ तौर पर समझाया जा सके कि 'अच्छी codebase quality होने पर token usage कम हो जाता है'.
मैं फिर से समझाने की कोशिश करता हूँ.
Vibe coding करने वालों का दायरा non-developers से लेकर अनुभवी developers तक बहुत व्यापक है. उनके पास मौजूद ज्ञान के स्तर के अनुसार, इस लेख की सामग्री से पूरी तरह अलग रहते हुए भी output की quality में बहुत बड़ा अंतर हो सकता है.
किसी के मामले में Cursor इस्तेमाल करने की शर्त पर
.cursorrulesमें बुनियादी OOP नियम और class/method separation के नियम शामिल करके इसे ऐसे चलाया जा सकता है कि refactoring की लगभग ज़रूरत ही न पड़े,जबकि किसी और के मामले में बुनियादी और महत्वपूर्ण बातों की समझ की कमी के कारण low-level code की भरमार हो सकती है.
यहाँ तक कि, project rules सेट करके code quality को अच्छी बनाए रखने के बारे में लिखे गए लेख और अनुभव पहले से ही बहुत हैं.
यह इस संभावना की ओर इशारा करता है कि कुछ लोग बिना explicit refactoring के भी token usage के लिहाज़ से लाभ देख रहे हो सकते हैं.
हालाँकि, ऊपर के मामलों में उन rules की परिभाषा के ज़रिए प्रति execution unit token usage में कितनी स्पष्ट कमी आती है, यह व्यवस्थित रूप से नहीं बताया गया है. इसलिए इस लेख में codebase quality के अनुसार token usage के अंतर का परीक्षण करके उसके परिणामों को संक्षेप में प्रस्तुत किया गया है.
अर्थात, उपयोगकर्ता के अनुसार explicit refactoring की संख्या स्वयं फिर से 0~n बार तक एक variable बन जाती है,
और इस लेख का मूल उद्देश्य शायद यह समझाना है कि 'अच्छी quality के codebase पर ध्यान देना क्यों अच्छा है?'
मैं लेखक हूँ। फ़ीडबैक के लिए धन्यवाद। अगला लेख लिखते समय इसे ध्यान में रखूँगा।
क्या इसका मतलब है कि यह prompt साथ में जोड़ने पर लागत कम हो गई? मुझे ठीक से समझ नहीं आ रहा कि मैंने इसका सार सही समझा है या नहीं।
एक बात और जोड़ूँ तो, कोड की संरचना को उस प्रोजेक्ट के अनुरूप मॉडल के हिसाब से बेहतर बनाया जाना चाहिए। नीचे दिए गए उत्तर की तरह, अगर आप AI से संरचना सुधार के बारे में पूछेंगे, तो वह उस प्रोजेक्ट के लिए उपयुक्त संरचना सुधार के तरीके बता देता है.
मेरी व्यक्तिगत सिफारिश यह है कि AI को सीधे संरचना सुधार का आदेश देने के बजाय, पहले उससे सुझाव देने को कहें। वह जवाब देगा, और बातचीत करते हुए जब आप पर्याप्त रूप से प्रभावी सुझाव तक पहुँच जाएँ, तब उसे लागू करने के लिए कहें — इस तरह का flow रखना बेहतर है.
एक अतिरिक्त टिप यह है कि जहाँ तक संभव हो, context summarization (कॉन्टेक्स्ट बफर initialization) होने से पहले काम पूरा कर लेना बेहतर है। और अगर context buffer initialization टालना संभव न हो, तो पहले से .cursorrules में सुधार के नियम जोड़ने के लिए कहना अच्छा रहता है। काम के बीच में context reset हो जाए, तो AI से गलती होने की संभावना बढ़ जाती है.
संदर्भ के लिए, यह एक अच्छी तरह से जाना-पहचाना और स्पष्ट तथ्य है कि इनपुट source का आकार जितना छोटा होगा, उतने ही कम tokens खर्च होंगे। इसी वजह से
.cursorignoreफ़ाइल बनाई गई थी।आम तौर पर जब AI से structure improve कराया जाता है, तो ज़्यादातर मामलों में source code की मात्रा कम होने की प्रवृत्ति होती है। इसलिए किसी भी वजह से code को organize करने पर cost कम होती है, यह दावा काफ़ी विश्वसनीय लगता है।
इस लेख में बस यह अतिरिक्त दावा जोड़ा गया है कि बेहतर structure guide करके token usage में अतिरिक्त कमी हासिल की जा सकती है।
सही है। जैसा कि मुख्य लेख में भी बताया गया है, कोड सुधार के बाद प्रोजेक्ट कोड का आकार कम हुआ है, यह सच है.
हालांकि, इस उदाहरण में character count के आधार पर लगभग 10% की कमी हुई, लेकिन केवल इससे token usage में 37.91% की कमी को समझाया नहीं जा सकता.
मुख्य लेख में source repository का लिंक है, और कोई भी इसे पुनरुत्पादित करके टेस्ट कर सकता है.
मैंने खुद इस तरह से टेस्ट नहीं किया है,
लेकिन मुझे लगता है कि यह प्रॉम्प्ट भी काम कर सकता है:
'मौजूदा कोड का विश्लेषण करो, और उसे इस तरह से restructure करो कि तुम्हारे लिए उसे manage करना आसान हो जाए'
सटीक बात यह है कि AI को सिर्फ़ functional requirements देना ही नहीं, बल्कि उसे उपयुक्त और सही structure की ओर अच्छी तरह guide करना भी cost कम करने में मददगार हो सकता है।
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
क्या यह DeepRAGGallactic मोड आपने खुद बनाया है?
क्या यह भी vibe coding से किया था?
नमस्ते। मैं इस ब्लॉग का मालिक हूं।
हाँ, यह सही है कि DeepRAGGall मोड मैंने खुद बनाया है, और फिलहाल इसे एक निजी सर्वर के ज़रिए सर्विस किया जा रहा है। (
chzzkOAuth authentication की वजह से इसकी ज़रूरत है)इस मोड में Unreal Engine के जरिए development शामिल है, लेकिन अफ़सोस की बात है कि Unreal Engine की तरफ़ vibe coding करना मुश्किल है।
इसके बजाय, क्योंकि mod development का तरीका खुद इतना मुश्किल नहीं है, अगर आपकी रुचि हो तो आप mod development guide (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/) के जरिए इसे आसानी से सीख सकते हैं।
मैंने किसी दूसरे कम्युनिटी में आपको वह मॉड पोस्ट करते देखा था, और सच में वह उसी व्यक्ति की लिखी हुई पोस्ट थी जिसने वह मॉड बनाया था।
मुझे नहीं पता था कि आपने Blueprint मॉड पर ट्यूटोरियल पोस्ट भी लिखी है, धन्यवाद।
आप तो पहले से ही बेहतरीन डेवलपर थे!
आह, तो आपने किसी दूसरे कम्युनिटी में मेरा मोड देखा था।
मैंने जो पोस्ट लिखी हैं उनमें कई कमियाँ हैं, लेकिन अगर वे मददगार हो सकें तो मुझे खुशी होगी।
आह, कितना झुंझलाने वाला है
कृपया बताइए कि आपको किस हिस्से से असुविधा हुई, मैं विनम्रता से जवाब दूँगा।
कृपया साइट उपयोग विधि में टिप्पणी लिखने वाले अनुभाग को देखें।
कृपया विनम्र और शिष्ट तरीके से बात करें।
यदि कोई आपत्ति है, तो केवल वही बात लिखें।