6 महीने, 3 गेम प्रोजेक्ट, 0 शिप
मैंने full-time job के साथ-साथ 6 महीने game developer बनने की कोशिश की। मैंने तीन projects बनाए, 684 commits लिखे, और ठीक zero games ship किए। यह कहानी है कि क्या हुआ, मैंने क्या सीखा, और कुछ भी ship क्यों नहीं हुआ।
मैं यह post कुछ हफ्ते पहले लिखना चाहता था। लेकिन मुझे लगता है कि मैं अभी भी उम्मीद कर रहा था कि जब तक मैं लिखने बैठूंगा, जिन तीन games पर काम कर रहा था उनमें से कम से कम एक तो पूरा हो जाएगा।
कोई भी पूरा नहीं हुआ।
तो स्थिति यह है: छह महीनों में तीन projects पर 684 commits, और ऐसा कुछ भी नहीं जिसे आप download कर सकें, खेल सकें, या किसी दोस्त को भेज सकें। अगर आपने कभी full-time job के बाहर कुछ सच में नया सीखा है — कुछ मुश्किल, कुछ जिसमें आप पहले से अच्छे नहीं थे — तो आप शायद यह feeling समझते हैं।
फिर भी मैं यह लिख रहा हूं, क्योंकि मुझे लगता है कि कुछ ship क्यों नहीं हुआ, इसकी कहानी किसी polished launch announcement से ज्यादा उपयोगी है।
शुरुआती संदर्भ
18 साल तक मैंने advertising में काम किया। यह अच्छा काम है, challenging है, और मुझे इसे करना आता है। मैंने campaigns ship किए हैं, teams बनाई हैं, books लिखी हैं, stages पर बोला है। उस दुनिया में मुझे पता है कि "done" कैसा दिखता है।
फिर 2025 के आखिर में मैंने तय किया कि मुझे game development सीखना है। Game marketing नहीं। Game strategy नहीं। सचमुच games बनाना — code, art, systems, और screen पर character move करने का feel।
मुझे game engines का कोई experience नहीं था। मैंने कभी 3D model rig नहीं किया था। Animation के context में state machine क्या होती है, यह नहीं पता था। मैं कुछ साल से coding कर रहा हूं, ज्यादातर web apps और AI products, लेकिन games बिल्कुल अलग discipline हैं। (अगर मैं इनमें से किसी चीज़ पर गलत हूं, तो कृपया correct करें — मैं अभी सीख रहा हूं।)
पहली चीज़ जो मैंने सीखी: game ship करना मुश्किल है। दूसरी चीज़: आप document से सोच-विचार करके अच्छे game loop तक नहीं पहुंच सकते।
आपको उसे move करते हुए देखना पड़ता है। आपको उसे खेलना पड़ता है, या कम से कम Godot runtime में चलाकर देखना पड़ता है कि character, camera, controls, और feedback सच में कोई feeling बना रहे हैं या नहीं। फिर आपको build, delete, cut, और rebuild करने के लिए तैयार रहना पड़ता है, जब तक कुछ interesting न दिखे।
यह हुआ।
Project 1: The AI Pet Sanctuary (288 commits)
December 2025 – February 2026
पहला project एक simple idea से शुरू हुआ: क्या हो अगर आपके computer पर रहने वाला एक pet हो, जो AI के ज़रिए आपसे बात कर सके? Pet avatar वाला chatbot नहीं — बल्कि behaviors, habitat, और personality वाला actual pet।
मैंने full-stack web application बनाया। Frontend पर React, backend पर FastAPI, database के लिए Supabase। Conversations के लिए Gemini और video के लिए Cloudflare Stream इस्तेमाल किया।
Ambitious हिस्सा animation system था। मैं 18 pet types चाहता था, छह broad categories में — dogs, cats, birds, small animals, fish, reptiles। हर एक को move करना, blink करना, और alive महसूस होना था।
मैंने Rive animations से शुरुआत की। इस use case के लिए वे काम नहीं आए। इसलिए मैंने उन्हें CSS और JavaScript pet animations से replace किया। फिर मैंने Google Veo 3.1 का उपयोग करके animation content generate करने की pipeline बनाई — pet movements के लिए AI video generation। यह चला, लेकिन brittle था। API fail हो जाती, lighting inconsistent होती, scale generations के बीच shift हो जाता। मैं actual pet experience design करने से ज्यादा generation pipeline से लड़ रहा था।
मैंने full-screen immersive environments वाला habitat system भी बनाया — "The Study" नाम का room जहां pet रहता था। Care screens. Memory screens. Conversation integration. बीच में पूरा "Quiet Luxury" redesign भी किया क्योंकि पहला version prototype जैसा दिखता था। (क्योंकि वह था।)
फिर मैंने pivot किया।
288 commits के बाद मैंने तय किया कि web app गलत platform है और native iOS version की planning शुरू की। मुझे अभी भी नहीं पता कि यह सही call था या strategy के भेष में boredom। मेरा एक हिस्सा मानता है कि phone पर pet browser से ज्यादा intimate है। मेरा दूसरा हिस्सा सोचता है कि मैं बस React से थक गया था।
लेकिन अगर मैं honest हूं, तो इसे कभी ship न करने की असली वजह ज्यादा simple थी: यह boring था। मैंने यह सब बनाया — habitats, animation system, conversation integration — और जब सच में बैठकर pet से interact करने का समय आया, तो दो मिनट में interest चला गया। ऐसा कुछ नहीं था जो मेरी attention रोक सके। मैं secondary school से games खेलता आया हूं, इसलिए उस first reaction पर भरोसा करता हूं, भले ही मुझे अभी हमेशा पता न हो कि उसे कैसे fix करना है। मैं अब भी family के साथ Mobile Legends खेलता हूं और आमतौर पर Mystic तक climb करता हूं। वह passive comfort के लिए खेला जाने वाला game नहीं है — वह skill और attention मांगता है। यह pet sanctuary दोनों में से कुछ नहीं मांगता था।
मैं खुद से कहता रहा कि platform समस्या है। Web app वह immersive experience नहीं दे सकती जो मैं चाहता था। शायद iOS अलग होगा। लेकिन अंदर से मुझे पता था कि problem React नहीं था — design था। कोई platform switch एक uninteresting game loop को exciting नहीं बना सकता था।
क्या गलत हुआ
Repo को देखकर मुझे नहीं लगता कि सही lesson यह है कि "288 commits बिना release के bad हैं." अगर core loop engaging नहीं है, तो उसे जल्दी ship करना सिर्फ boring चीज़ को जल्दी ship करना है।
असली problem यह थी कि मैंने loop prove करने से पहले container बदलना जारी रखा। Project merge/order mechanics से pure companion, फिर immersive habitats, फिर iOS तक गया। हर pivot की वजह थी। लेकिन जो सवाल मैंने साफ़ जवाब नहीं दिया, वह simple था: क्या मैं इसे हर दिन खोलना चाहूंगा?
मैं इसे एक pet, एक room, एक conversation, और एक care/play interaction से validate कर सकता था। इसके बजाय मैंने 6 animal categories में 18 pet types और पूरा habitat system बना दिया, इससे पहले कि मेरे पास सबसे ज़रूरी सवाल का runtime answer हो: क्या यह pet वापस आने लायक interesting है?
AI-generated animation powerful है, लेकिन brittle है। जब यह काम करता है, तो amazing होता है। जब नहीं करता, तो आप product के बजाय prompts और API failures debug कर रहे होते हैं। आपको fallback pipeline चाहिए, और मैंने उसे जल्दी नहीं बनाया।
मैंने क्या सीखा
पहला काम scope cut करना नहीं है। पहला काम interesting part ढूंढना है। कभी-कभी इसका मतलब है और build करना। कभी-कभी इसका मतलब है अभी बनाई चीज़ delete करना। गलती exploration नहीं थी। गलती यह थी कि मैं playable proof के बिना बहुत लंबे समय तक explore करता रहा, जो बताता कि core experience में life है या नहीं।
Project 2: वह fox जो stepping stone बन गया (35 commits)
April 17 – May 12, 2026
Pet sanctuary के iOS की तरफ pivot करने के बाद, मैंने Godot 4.6 में नया project शुरू किया। इस बार मैं real game engine में scratch से game बनाना चाहता था, web app नहीं जो game बनने का दिखावा करे।
Initial concept: Spirit Fox Kit Sanctuary Sim। एक छोटा fox cozy room में रहता है, और आप उसकी देखभाल करते हैं। Simple, warm, contained।
मैंने Godot project setup किया। मैंने fox character design करने की कोशिश की, hidden tense silhouettes, faster twitch animations, और stillness के micro-signals के साथ।
लेकिन यह sentence prototype को असल से ज्यादा legible बनाता है। Screen पर fox, fox जैसा नहीं पढ़ता था। वह एक छोटी mass की गेंद जैसा था। मुझे usable shape नहीं दिख रही थी, कमरे के बाकी visuals judge करना तो दूर की बात थी।
मैंने GUT test coverage के साथ draft room loop बनाया। Placeholder audio. Interactables के लिए hover cues. Room scene layout. Cold-start playtest harness ताकि मैं सच में इसे खेल सकूं।
और फिर मैंने इसे खेला।
ईमानदार सच visual था, philosophical कम: fox first read में fail हो गया। Room prototype में mechanically verified path था, और repo placeholder-art build के लिए abbreviated solo gate pass भी record करता है। Stillness, emergence beat, touch distinction, और room problem उस stage के लिए acceptable थे।
लेकिन छोटे authored beat के लिए acceptable होना, full game carry करने के लिए visually strong होना नहीं है। यह project fox पर depend करता था कि वही experience उठाए। अगर मैं उसकी shape, posture, और appeal नहीं देख सकता, तो sanctuary loop के पास अभी chance नहीं था।
इसलिए April 20 को — शुरू करने के सिर्फ तीन दिन बाद — मैंने full pivot spec लिखा। Fox sanctuary sim कुछ बिल्कुल अलग बन गया: warm safehouse और hostile territory explore करने वाला landscape action-adventure। मैंने fox-first plans pause किए और नई direction design करनी शुरू की।
35 commits. एक validated beat. एक pivot. कुछ भी ship नहीं।
क्या गलत हुआ
असली problem यह थी कि मैंने animation signals को ऐसे treat किया जैसे वे unreadable base shape की भरपाई कर सकते हैं। वे नहीं कर सकते। अगर नीचे का body silhouette नहीं देता, तो twitch मायने नहीं रखता।
Pivot इस बात का proof नहीं था कि पहला काम waste था। उसने पहले काम को foundation बना दिया। जो मेरे पास अभी भी नहीं था: evidence कि larger Hearthkeeper direction काम करेगा, या मैं उसके core character को इतना readable बना सकता हूं कि player care करे।
मैंने क्या सीखा
Early playtesting बताता है कि prototype असल में क्या prove कर रहा है। Room prototype ने tone, pacing, और relationship beat prove किया। उसने पूरा game prove नहीं किया, और उसने तुरंत visual readability problem दिखा दी। यह useful information है, लेकिन अलग next step की तरफ इशारा करती है: character read solve करो और fox polish करने से पहले सबसे छोटा safehouse -> run -> return loop बनाओ।
Game 1 ने मुझे सिखाया कि technically complete loop भी boring हो सकता है। Game 2 ने सिखाया कि documented, tested character concept भी seconds में visually fail कर सकता है। ये दोनों failures इसलिए भी ज़रूरी हैं कि Game 3 में ज्यादा real progress हुआ: मैं readability, motion, weapon feel, और playable slice screen पर काम करता है या नहीं, इस पर ज्यादा ध्यान दे रहा हूं।
Evidence से pivot करना drifting से अलग है। Fox runtime में readable नहीं था, इसलिए direction change automatically discipline failure नहीं था। मुझे feedback loop improve करना है: सबसे risky visual या gameplay question को जल्दी screen पर लाओ, फिर concept mode में रहने के बजाय evidence से decide करो।
Project 3: जहां pipeline काम करने लगी (361 commits)
April 21 – May 13, 2026
यह वह project है जिस पर मैं अभी भी काम कर रहा हूं। यही वह project भी है जहां पहले दो projects से सीखा हुआ finally compound होने लगा।
यह mech tactics game है। आप combat में mechs की squad control करते हैं, और हर battle के बाद एक LLM analyze करता है कि क्या हुआ और debrief देता है। Post-match analysis सोचिए, लेकिन AI द्वारा लिखा हुआ, जिसके पास पूरे game state का access है।
Repo में तीन tracks हैं, लेकिन अब वे equal नहीं हैं:
Track A — The LLM Debrief System: यह early AI validation track था। इसने structured debriefs test करने में मदद की, लेकिन अब main product path नहीं है।
Track B — The 2D Phone Prototype: यहीं मुझे पहली बार relatively immersive 2D player experience के लिए workable pipeline मिली। Actual Godot runtime में lane-match combat loop, touch joystick, shop/modules, hero XP, ability cooldowns, phone-readable VFX motifs, enemy punish zones, neutral relay objective, HUD feedback, और iOS export/testing flow है। Art pipeline भी काम करने लगी: Nano Banana 2 (Gemini 3.1 Flash Image) ने usable initial hero और character images generate किए, फिर MCP-based pixel cleanup workflow और Aseprite ने curated candidates को cleaned sprites, animation frames, और Godot-ready sheets में बदला। यह finished game नहीं है, और phone acceptance अभी pending है, लेकिन यह पहले दो projects की तुलना में "यह game जैसा feel होता है" के बहुत करीब है।
Track C — The Campaign and 3D Path: यही current product direction है। यह Track B की useful lessons रखता है, campaign memory loop जोड़ता है, और production combat को 3D/2.5D की ओर ले जाता है। यह 2D pipeline से कहीं ज्यादा कठिन problem है। 2D में मैं sprite sheets, HUD tuning, procedural VFX, और phone captures से readability control कर सकता हूं। 3D में हर decision modeling, rigging, animation, camera, lighting, GLB export, weapon sockets, hit anchors, action timing, और runtime performance को छूता है।
मैंने custom rigging work के लिए Blender integrate किया, locomotion के लिए Rokoko mocap data लाया, और full rig, animation tree, और weapon socket integration वाला hero mech character बनाया।
तीन हफ्तों में 361 commits. एक real 2D pipeline. एक बहुत कठिन 3D experiment. अभी भी prototype territory.
क्या गलत हुआ
यह बात मुझे माननी होगी: 2D pipeline काम करने लगी है, लेकिन अगर मैं ध्यान न रखूं तो 3D pipeline पूरे project को निगल सकती है।
Track B में pipeline work fake progress नहीं था। Nano Banana 2 -> Aseprite workflow, touch controls, HUD, readable ability motifs, module feedback, phone captures, और export loop product को ज्यादा playable बना रहे थे। उस work ने मुझे सिखाया कि player को moment to moment क्या देखना और महसूस करना चाहिए।
अब risk अलग है। Track C में 3D को किसी भी चीज़ जैसा feel होने से पहले बहुत pipeline चाहिए: model import, rig quality, animation names, weapon attachment, muzzle position, hit center, camera angle, lighting, movement, jump timing, attack timing, VFX, और runtime inspection। ये optional details नहीं हैं। अगर character readable नहीं है, तो पूरी scene seconds में fail हो जाती है।
लेकिन playable encounter को lead करना ही होगा। वरना मैं hero mech के weapon fit, jump compression, left-hand IK, और mocap cleanup सुधारने में weeks लगा सकता हूं, बिना simple player question का जवाब दिए: क्या इसे control करना fun है?
मैंने क्या सीखा
Pipeline work तभी useful है जब वह playable slice की service करे। Track B ने सिखाया कि सही pipeline ज्यादा immersive 2D experience बना सकती है। Track C सिखा रहा है कि 3D हर improvement की cost बढ़ा देता है। मुझे acceptance gate concrete रखना होगा: क्या player hero mech को read कर सकता है, move कर सकता है, aim कर सकता है, fire कर सकता है, hit समझ सकता है, और फिर करना चाहता है?
Tracks को gates चाहिए। Track A ने अपना काम किया। Track B ने reusable 2D game feel और presentation lessons दिए। Track C current bet है। Problem यह नहीं कि मैंने multiple paths explore किए। Problem यह है कि उन्हें clear runtime question और clear decision rule के बिना फिर से खोलना।
3D game development बहुत बड़ा skill gap है। Rigging, animation, mocap data, asset budgets, weapon sockets, camera framing, और readable motion ऐसी disciplines हैं जिनमें मेरी zero professional experience है। मैं इन्हें Godot, game design, और campaign architecture के साथ-साथ सीख रहा हूं। Learning curve steep नहीं है — vertical है। मुझे लगता है यही सबसे surprising था। Web development में मैं एक दिन में functional चीज़ बना सकता हूं। 3D game dev में मैंने एक पूरी evening character का arm सही bend कराने में लगा दी। (यह ऐसा sentence है जिसे मैं छह महीने पहले समझ नहीं पाता।)
इन तीन projects में common क्या है
अगर मैं अपने साथ honest हूं — और यह post तभी काम करता है जब मैं honest हूं — pattern "scope creep" नहीं है। यह बहुत आसान जवाब है, और इस case में मुझे लगता है गलत है।
मुझे नहीं लगता games business decks की तरह काम करते हैं — कम से कम इन तीन projects ने मुझे यही सिखाया। कोई idea काम करेगा या नहीं, यह premise अच्छा लगने से पता नहीं चलता। यह तब पता चलता है जब आप उसे खेल सकते हैं, या कम से कम engine में चलते देख सकते हैं और feel कर सकते हैं कि character, camera, interaction, और feedback कुछ कर रहे हैं या नहीं।
1. Runtime सच है
Pet sanctuary अच्छा लगता था जब तक मैंने pet से interact किया और bored हो गया। Fox अच्छा लगता था जब तक मैंने उसे Godot में देखा और shape read नहीं कर पाया। Track B इसलिए काम करने लगा क्योंकि loop phone-like runtime में आया: touch controls, HUD, VFX, shop, XP, readable motifs, और capture feedback।
यही real pattern है। Useful truth तब ही आई जब idea visible और playable हुआ।
2. Exploration जरूरी है, लेकिन evidence चाहिए
मुझे नहीं लगता सही lesson "चीज़ें जोड़ना बंद करो" है। Game development को exploration चाहिए। आप build करते हैं, try करते हैं, delete करते हैं, cut करते हैं, rebuild करते हैं, और फिर try करते हैं क्योंकि आप interesting part ढूंढ रहे हैं।
Discipline जिस चीज़ को चाहिए, वह काम की मात्रा नहीं है। वह evidence loop है। हर piece of work को एक सवाल का जवाब देना चाहिए: क्या यह game को ज्यादा readable, ज्यादा engaging, ज्यादा controllable, ज्यादा replay-worthy बना रहा है?
3. Pipelines अच्छी हैं जब वे game को ज्यादा playable बनाती हैं
Nano Banana 2 -> MCP cleanup -> Aseprite workflow distraction नहीं था। उसने मुझे बेहतर 2D characters और animation game में लाने में मदद की। Track B का HUD और VFX work भी fake progress नहीं था। उसने runtime को clear बनाया।
Risk तब है जब pipeline player-facing question का जवाब देना बंद कर देती है। Track C में 3D tooling जरूरी है, लेकिन उसे हमेशा एक बात पर लौटना होगा: क्या player hero mech को read कर सकता है, move कर सकता है, weapon fire कर सकता है, hit समझ सकता है, और फिर करना चाहता है?
4. Gap coding skill नहीं है। Gap playable judgment है।
मैं Supabase, FastAPI, और React से full-stack application बना सकता हूं। मैं 3D model rig कर सकता हूं, GUT tests लिख सकता हूं, और custom debugging tools बना सकता हूं। जो मैं अभी सीख रहा हूं वह है यह judge करना कि कोई चीज़ game के रूप में सच में interesting है या नहीं। Track B ने मुझे 2D में करीब लाया। Track C दिखा रहा है कि motion, camera, lighting, weapons, और animation को साथ काम करना हो तो यह कितना मुश्किल हो जाता है।
मुझे लगता है यह सबसे important lesson है। Code वह part है जिसमें मैं अच्छा हूं। Difficult part है decide करना कि game असल में है क्या, उसे interesting बनाना, और फिर इतना discipline रखना कि runtime evidence पर लौटते रहो जब तक वह ship करने लायक न हो।
कुल मिलाकर मैंने क्या सीखा
अगर मैं छह महीनों को कुछ useful में distill करूं — अपने लिए, या किसी भी reader के लिए जो इसी position में है — तो यह वह चीजें हैं जो मुझे लगता है अब पता हैं और December में नहीं पता थीं:
-
पहला version runtime में सबसे risky question का जवाब दे। मेरे pet sanctuary को एक pet interaction चाहिए था जो मुझे वापस बुलाए। मेरे fox game को blank room में readable silhouette चाहिए था, micro-signals से पहले। मेरा mech game Track B के जरिए करीब आया क्योंकि मैं screen पर loop देख और feel कर सकता था।
-
Playtesting optional नहीं है, और runtime review count करता है। जिस moment मैंने fox को shapeless mass के रूप में देखा, मुझे पता था project अभी काम नहीं कर रहा। वह पूरे project के सबसे valuable 30 minutes थे। मुझे उस visual truth तक पहले पहुंचना चाहिए था।
-
Learning valid outcome है, भले ही planned outcome न हो। मैं games बनाने निकला था। मैंने games ship नहीं किए। लेकिन मैंने Godot, LLM prompt engineering, Nano Banana 2 for character ideation, Aseprite animation cleanup, 2D phone readability, HUD and VFX feedback, animation pipelines, 3D rigging, mocap data, game feel, camera systems, visual readability, और tools बनाने और products बनाने का फर्क सीखा। यह nothing नहीं है। यही वजह है कि Game 3, Game 1 और Game 2 से बेहतर है, भले ही अभी ship नहीं हुआ।
-
मुझे अभी honest finish line define करनी है। मेरा एक हिस्सा इस project को completion तक push करना चाहता है ताकि कह सकूं कि मैंने game ship किया। मेरा दूसरा हिस्सा सोचता है कि learning ही product था और मुझे उसे accept करना चाहिए। दोनों honest answers हैं। मुझे लगता है सच बीच में है: zero से फिर start करने के बजाय ऐसा focused slice ship करना जो सीखे हुए का सम्मान करे।
आगे क्या
मैं अभी भी mech tactics project पर काम कर रहा हूं। LLM debrief concept interesting है, और मुझे लगता है AI-powered post-match analysis for a tactics game में सचमुच कुछ नया है।
लेकिन मैं approach बदलने की कोशिश कर रहा हूं: runtime proof पहले, polish बाद में, और कुछ तभी ship करना जब playable slice के पास exist करने की वजह हो। पहले दो projects waste नहीं थे। उन्होंने बदला कि मैं Game 3 में क्या देखता हूं: क्या character read होता है, क्या motion अच्छा feel होता है, क्या weapon सही feel होता है, और क्या कोई person architecture समझाए बिना encounter समझ सकता है?
अगर मैं आज नया game शुरू करता, तो बड़े architecture plan से शुरू नहीं करता। मैं सबसे तेज runtime proof से शुरू करता जो उस question का जवाब दे जिसे मैं सच में care करता हूं। Game 3 के लिए अब वही discipline project के अंदर लागू होनी है: एक character, एक weapon, एक encounter, एक clear acceptance test।
मुझे अभी नहीं पता कि मैं इनमें से किसी project को completion तक push करूंगा या मान लूंगा कि learning ही product था। मैं timeline पर गलत हो सकता हूं, लेकिन मुझे लगता है pattern किसी भी single project से ज्यादा important है।
आपसे एक सवाल
मैं सच में पूछना चाहता हूं, rhetorical नहीं: क्या आप कभी यहां रहे हैं? (मुझे शक है कि ज़्यादा builders यहां रहे हैं, जितना हम आमतौर पर स्वीकार करते हैं।)
क्या आपने महीनों तक ऐसा कुछ बनाया है जो कभी ship नहीं हुआ? क्या आपने आखिर में उसे finish किया, या walk away किया? और अगर walk away किया — क्या वह सही call था, या आप अभी भी उसके बारे में सोचते हैं?
मैंने अपने career में चीज़ें ship की हैं। Campaigns, platforms, products। लेकिन वे उस domain में थे जहां मेरे पास 18 years of experience था। Game development नया है, और "मैं इसे technically बना सकता हूं" और "यह अच्छा game है" के बीच gap मेरी उम्मीद से कहीं बड़ा है।
अगर आपने यह gap पार किया है, तो मैं सच में जानना चाहूंगा कि किस चीज़ ने आपको फिर pivot away करने से रोका। LinkedIn पर reply करें या directly note भेजें — मैं सच में curious हूं।
मेरी तरफ से बस इतना। मैं आपके thoughts सुनना चाहूंगा — खासकर अगर आप भी इसी अनुभव से गुज़रे हैं। आप LinkedIn पर reach out कर सकते हैं या सीधे note भेज सकते हैं.
शुभकामनाओं सहित,
Chandler
