1 पॉइंट द्वारा GN⁺ 2024-12-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • CobolCraft COBOL में लागू किया गया Minecraft सर्वर है, जो लिखे जाने के समय के नवीनतम संस्करण Minecraft 1.21.4 को सपोर्ट करता है
  • इसमें पहले से ही infinite terrain generation, dynamic chunk loading, world और player data को disk पर save करना, मौजूदा worlds import करना, multiplayer, server status display, block तोड़ना और रखना, inventory, crafting, item उठाना, chat, commands आदि लागू हैं
  • कई states, directions और interactions वाले blocks के व्यवहार को सही तरह लागू करने के लिए काफी dedicated code की जरूरत होती है, और अभी कई blocks सपोर्टेड नहीं हैं
  • इसे Linux x86_64 या arm64 पर GnuCOBOL के साथ डेवलप किया गया है, और Docker के जरिए deploy भी किया जा सकता है, लेकिन Windows जैसे दूसरे operating systems का support test नहीं किया गया है
  • Minecraft के default datapack और official server/client .jar से JSON data निकालकर compile time पर COBOL code generation और runtime data loading में इस्तेमाल किया जाता है

CobolCraft द्वारा लागू किए गए Minecraft server features

  • CobolCraft COBOL में लिखा गया Minecraft server है और Minecraft 1.21.4 को सपोर्ट करता है
  • लागू किए गए features में ये शामिल हैं
    • infinite terrain generation और dynamic chunk loading
    • world और player data का disk storage
    • Minecraft file formats का support और मौजूदा worlds import करना
    • एक साथ जुड़ने वाले players की संख्या configure कर सकने वाला multiplayer
    • server list में online दिखाने वाला ping/server status
    • block तोड़ना और रखना, auto-generated loot table code
    • right-click आधारित block interaction
    • player inventory
    • 2x2 और 3x3 crafting
    • item entities और item pickup
    • chat
    • in-game commands और interactive console commands
    • server.properties आधारित configuration
    • whitelist.json में store होने वाला persistent whitelist
    • बहुत basic block/player collisions और entity physics
    • fall damage, void damage, death, respawn

Block support का दायरा और सीमाएं

  • जिन blocks में कई states, directions और interactions होते हैं, उनके सही behavior के लिए बहुत सारा specialized code चाहिए
  • अभी कई blocks सपोर्टेड नहीं हैं
  • काम करने वाले blocks में ये शामिल हैं
    • torches
    • slabs
    • stairs
    • logs जैसे rotated pillars
    • non-interactive buttons
    • doors
    • trapdoors
    • beds
    • signs

Build और runtime environment

  • CobolCraft को GnuCOBOL के साथ डेवलप किया गया है और इसे Linux पर चलाने का लक्ष्य है
    • target architectures x86_64 और arm64 हैं
    • Windows जैसे दूसरे operating systems का support test नहीं किया गया है
    • Docker का इस्तेमाल करने पर platform-independent deployment संभव है
  • Linux distribution के लिए जरूरी चीजें इस प्रकार हैं
    • GnuCOBOL 3.1.2 या उससे ऊपर
    • performance के लिए GnuCOBOL 3.2 या उससे ऊपर recommended
    • make
    • gcc, g++
    • zlib
    • official server .jar download करने के लिए curl
    • server .jar से data extract करने के लिए Java 21 या उससे ऊपर
  • Build और run commands इस प्रकार हैं
make --jobs=$(nproc)
make run
  • Docker Hub image का इस्तेमाल किया जा सकता है, या खुद build करके चलाया जा सकता है
docker pull meyfa/cobolcraft:latest

git clone https://github.com/meyfa/CobolCraft.git cobolcraft && cd cobolcraft
docker build --tag meyfa/cobolcraft .

Server settings और network access

  • Server settings server.properties file को edit करके की जाती हैं
  • पहली बार चलाने पर यह file supported सभी options के default values के साथ अपने-आप generate होती है
    • server-port: default value 25565
    • level-name: default value "world"
    • white-list: default value false
    • motd: default value "CobolCraft"
    • max-players: default value 10, maximum 100
  • By default server केवल अपने system से localhost:25565 के जरिए access किया जा सकता है
  • local network, VPN, port forwarding, rented server आदि के जरिए बाहर से access संभव बनाने के लिए Docker चलाते समय port को 0.0.0.0:25565:25565 से bind किया जा सकता है
docker run --rm -it -p 0.0.0.0:25565:25565 meyfa/cobolcraft

COBOL में Minecraft server बनाने की वजह

  • Developer को पहले COBOL का कोई अनुभव नहीं था, लेकिन COBOL के बारे में अफवाहें और stigma देखकर वे भाषा को और समझना चाहते थे
  • भाषा सीखने के सबसे अच्छे तरीके के रूप में उन्होंने कुछ खुद लिखने का रास्ता चुना
  • Minecraft code की complexity और scale के कारण COBOL में Minecraft server लिखने का चुनाव अच्छा भी था और खराब idea भी, ऐसा वे मानते हैं
  • दूसरे languages में आसान लगने वाले कामों को शुरू से बनाना पड़ा
    • JSON parsing और encoding
    • कई तरह के binary data को handle करना
    • real-time multiplayer networking
    • object-oriented Minecraft systems को procedural language में ले जाना
  • तेज learning curve ने उन्हें COBOL और उसके concepts को गहराई से खोजने और समझने के लिए प्रेरित किया, और उन्होंने बताया कि यह प्रक्रिया rewarding रही
  • COBOL पहली बार इस्तेमाल करने वालों के लिए वे GnuCOBOL Programmer's Guide recommend करते हैं
  • Minecraft protocol सीखने के resource के रूप में wiki.vg documentation देखी जा सकती है
  • कुछ मामलों में Wireguard जैसे tools से actual server traffic देखना भी information flow समझने में मददगार हो सकता है

Source structure और executable binary

  • COBOL source code मुख्य रूप से src/ directory में है
    • src/main.cob entry point है
    • src/server.cob में server startup code और game logic है
  • codegen/ directory में COBOL में लिखा गया code generator है
    • यह Minecraft default datapack जैसे JSON data से extra source code generate करता है
  • cpp/ directory में उन operating system integrations के लिए C++ source है जिन्हें COBOL में handle करना मुश्किल है
    • low-level TCP socket management
    • precise timing
    • process signal handling
  • सभी COBOL और C++ sources एक ही cobolcraft binary में compile होते हैं

Minecraft data extraction और JSON processing

  • official Minecraft Java Edition server और client applications में बहुत सारा data होता है
    • blocks, items, entity types
    • biomes
    • packet protocol ID
    • pickaxe से mine किए जा सकने वाले blocks जैसे tags
    • recipes
    • loot tables, जो बताते हैं कि block तोड़ने पर किन conditions में कौन-सा item drop होगा
  • CobolCraft के Makefile में official .jar download करने और data को JSON में extract करने के targets हैं
  • Extract किया गया JSON data दो तरीकों से इस्तेमाल होता है
    • compile time पर block loot tables जैसे COBOL code को automatically generate करना
    • runtime पर data को memory में load करना
  • दोनों काम COBOL में लिखे और unit-tested general-purpose JSON parser का इस्तेमाल करते हैं

Tests और updates

  • Unit tests tests/ directory में हैं
  • Tests copybook-based custom test framework का इस्तेमाल करते हैं
    • test suites, units और assertions को track करता है
    • run के अंत में summary देता है
  • Tests चलाने की command make test है
  • Tests का मुख्य लक्ष्य उन areas को validate करना है जिन्हें debug करना मुश्किल है, जैसे JSON और binary data encoding/decoding
  • Game logic itself की testing को उतना महत्वपूर्ण नहीं माना गया है
  • Server को नए Minecraft version में update करने की प्रक्रिया और test steps Updating.md में हैं

License और trademark

  • CobolCraft MIT License के तहत distribute किया जाता है
  • “Minecraft” Mojang Synergies AB का trademark है
  • CobolCraft Mojang से affiliated project नहीं है और न ही इसे Mojang ने endorse किया है

1 टिप्पणियां

 
GN⁺ 2024-12-27
Hacker News टिप्पणियाँ
  • COBOL को लेकर बहुत सी अफवाहें और बदनामी जुड़ी हुई हैं, इसलिए अच्छा होगा अगर आप लिखें कि आपको वास्तव में कौन-सी समझ मिली
    मैंने भी अब तक ऐसी ही बातें सुनी हैं, और यह जानने में दिलचस्पी है कि एक COBOL शुरुआती ने काफ़ी जटिल पहले प्रोजेक्ट को बनाते समय क्या-क्या देखा

    • COBOL के object-oriented रूप को लेकर मज़ाक में एक बदनामी है कि उसका नाम ADD ONE TO COBOL YIELDING COBOL जैसा असुविधाजनक है
      फिर भी, पुराने FORTRAN की तरह यह spaces को नज़रअंदाज़ नहीं करता था, इसलिए DO 10 I=1.10 को loop syntax error की जगह चुपचाप DO10I = 1.10 assignment statement की तरह compile नहीं कर देता था. असल में इरादा शायद DO 10 I=1,10 लिखने का था
    • इस तरह की समझ अच्छी लगती है
      अगर दिलचस्पी हो, तो COBOL से C# compiler बनाते समय मिली बातें यहाँ हैं: https://github.com/otterkit/otterkit-cobol/issues/40
      अब मुझे यक़ीन हो गया है कि COBOL बस एक high-level assembler है
  • यह सच में शानदार है
    मैंने अपने हाई स्कूल graduation project के लिए football betting odds को automate करने वाला पूरा COBOL system बनाया था. तकनीक तब तक पुरानी पड़ चुकी थी, लेकिन स्कूल अभी भी समय से पीछे था
    यह बेहूदा ढंग से बेमेल था, फिर भी हर लाइन अच्छी लगती थी. ऐसी भाषा में कुछ अजीब तरह की तसल्ली है जो टाइप करते समय हर बार जैसे फुसफुसाती हो, “punch cards याद हैं?”

    • हाई स्कूल प्रोजेक्ट में ALL CAPS COBOL का इस्तेमाल करना सच में उस दौर के हिसाब से बिल्कुल फिट बैठता है. लगता है यह बढ़िया हाई स्कूल याद बन गई होगी. उम्मीद है कि सारे variable names ग्रीक देवताओं के नाम पर रखे गए होंगे
  • शायद यह मेरा भ्रम हो, लेकिन लगता है कि C या यहाँ वाले COBOL जैसी सीधी-सादी, साधारण भाषाओं में लिखे छोटे लेकिन असरदार side projects काफ़ी बार दिख जाते हैं
    इसके उलट, वैसे ही Rust projects अक्सर code lines में 10 गुना बड़े होते हैं और फिर भी मुश्किल से काम करते दिखते हैं
    मेरी परिकल्पना यह है कि सरल भाषाएँ किसी idea को blueprint की तरह जल्दी पकड़ लेने और गंदे codebase के साथ भी पहले कुछ चलाने में आसान होती हैं. जबकि आधुनिक भाषाएँ आपको ज़्यादा टिकाऊ code लिखने के लिए मजबूर करती हैं. या शायद आधुनिक भाषाएँ ही कहीं न कहीं कुछ ग़लत कर रही हैं

    • Minecraft server को ठीक-ठीक कहें तो छोटा side project नहीं माना जा सकता
      कुछ servers 3-5 साल से development में हैं और अब भी पूरे नहीं हुए, और https://github.com/MCHPR/MCHPRS जैसे कुछ सिर्फ़ redstone showcase के लिए खास features पर केंद्रित हैं
      इस COBOL server में अभी lighting handling implement नहीं हुई है, और mob spawning उसी पर निर्भर करता है, इसलिए यह सबसे कठिन हिस्सों में से एक है. कुछ blocks भी अभी पूरी तरह implement नहीं हुए हैं. Minecraft server पूरा करने में सालों लगते हैं, इसलिए जल्दी कुछ बना लेना हमेशा सबसे अच्छा रास्ता नहीं होता
    • मुझे नहीं लगता कि यह पूरी तरह भ्रम है
      मैं Rust में 2 games पर काम कर रहा हूँ, और सही engine चुनने पर बहुत न्यूनतम gameplay prototype बनाना काफ़ी आसान था. लेकिन features बढ़ते गए तो code बहुत फैल गया, और singleplayer से multiplayer में बदलने की प्रक्रिया पूरी अव्यवस्था थी. trend के पीछे भागकर बाद में चीज़ें हटाने में भी समय बर्बाद हुआ
      Rust को game objects का जटिल रूप से जुड़े graph structure सच में पसंद नहीं है. जब भी एक game event कई types के updates की ओर ले जाता है, वहाँ friction पैदा होता है. एक विकल्प था इसे स्वीकार करके थोड़ा और code लिखना, और दूसरा था शुरुआत में ज़्यादा code लिखकर बाद में समय बचाने वाला कोई व्यवस्थित समाधान ढूँढना
      मैंने दूसरा रास्ता चुना और कुछ प्रयोग किए, लेकिन ऐसा लगा कि break-even point 1 व्यक्ति वाले छोटे project के लिए बहुत दूर है
      एक ही भाषा के भीतर भी अंतर एक अंक से ज़्यादा हो सकता है. Rust में 3D engines के 2 अच्छे विकल्प हैं; एक मशहूर है, उसके contributors भी बहुत हैं, और उसे इतना funding मिलता है कि Bay Area salary की भरपाई जैसी लगे. दूसरा लगभग एक ही व्यक्ति बना रहा है, जो कभी अपनी savings पर और कभी full-time job के सहारे चलता है
      लेकिन पहला engine प्रचार पर बहुत ध्यान देता है, सालों से कई features का वादा करता आ रहा है, पर दिखाने के लिए कम है; दूसरा feature count और implementation quality दोनों में आगे है
      आख़िरकार मुझे लगता है कि यह रवैये का फ़र्क है. कुछ लोग मज़े के लिए code करते हैं, कुछ साफ़ लक्ष्य रखकर उसे हासिल करने पर ध्यान देते हैं, कुछ पैसे के लिए करते हैं, और कुछ सार्वजनिक पहचान की ओर खिंचते हैं. गंदा codebase ज़रूरी नहीं, लेकिन एक उत्पादक बीच का क्षेत्र होता है. जो लोग दिखावे पर ज़्यादा केंद्रित होते हैं, वे trend और चमकदार architecture के पीछे भागने की ज़्यादा संभावना रखते हैं
    • Rust को game development में breakthrough पाने के लिए काफ़ी संघर्ष करना पड़ा है
      Rust का मुख्य आधार यह है कि वह development speed और flexibility के बदले memory safety देता है, लेकिन game development में यह साफ़ हो जाता है कि development speed और flexibility memory safety से कहीं ज़्यादा महत्वपूर्ण हैं
      अगर आपके पास पहले से पूरी detail तक तय किया हुआ formally specified microkernel है, तो Rust शानदार विकल्प हो सकता है. लेकिन अगर आपको यह देखने के लिए तेज़ी से दीवार पर कीचड़ फेंकना है कि मज़ेदार gameplay बनता क्या है, तो Rust लगभग किसी भी भाषा से ज़्यादा उस प्रक्रिया को कठिन बना देता है, और उसके फ़ायदे भी स्पष्ट नहीं हैं. बस इतना कि आपने जो तेज़ लेकिन गंदा gameplay टुकड़ा बनाने में ज़्यादा समय लिया, वह थोड़ा अधिक memory-safe है
      Rust में game development आज़माने के बाद इस उपयोग से साफ़ तौर पर दूर चले जाने वाला मैं अकेला नहीं हूँ. उदाहरण के लिए “Leaving Rust gamedev after 3 years” [0] है, जो अब तक Rust पर Hacker News की सबसे ज़्यादा चर्चा और पसंद की गई पोस्टों में से एक है
      और व्यापक रूप से देखें तो यह साफ़ है कि Rust को Cobol की तुलना में बहुत ज़्यादा बढ़ा-चढ़ाकर ध्यान मिलता है. इसलिए अतिशयोक्ति भरी लहरों के प्रति संवेदनशील developers, आम तौर पर उत्साही beginners, Rust में open source या hobby projects पर बहादुरी से हाथ आज़माते दिखते हैं. दूसरी ओर, Cobol में Minecraft server लिखने के लिए थोड़ी ज़्यादा सनक और हिम्मत चाहिए, और यह आम तौर पर अधिक अनुभव से जुड़ी होती है
      [0] https://news.ycombinator.com/item?id=40172033
    • आख़िर में यह शायद सरल भाषाओं को पसंद करने वाले उन असल hackers™ और ताज़ा trend के पीछे भागने वाले code monkeys के बीच का फ़र्क है, जो जो भी दे दो उससे पूरा ब्रह्मांड बना देते हैं
      वैसे, मैं खुद को दूसरी श्रेणी में रखता हूँ
    • जो लोग काम पूरा कर देते हैं, वे आम तौर पर code quality की बहुत ज़्यादा परवाह नहीं करते
      मैं भी कभी लंबे समय तक टिकने वाला code लिखने की कोशिश करते-करते उस हालत में पहुँच गया था जहाँ कुछ भी पूरा नहीं हो पाता था. सालों में मैंने संतुलन सीखा, यह समझा कि बेकार code को बार-बार सुधारते रहो तो वह अंततः ठीक-ठाक बन जाता है, और तब से मैं वही कर रहा हूँ
  • https://raw.githubusercontent.com/meyfa/CobolCraft/main/src/...
    जिन लोगों की पृष्ठभूमि procedural languages में है, उनके लिए इसे समझना वास्तव में इतना मुश्किल नहीं है, और इससे लगभग 20 साल पहले देखे गए VB में लिखे गेम सर्वर थोड़े याद आ गए

  • 1978 में COBOL का इस्तेमाल छोड़ने के बाद से मैंने कभी यह दावा भी नहीं किया कि मैं इस भाषा को जानता हूँ
    मैं प्रार्थना करता हूँ कि मुझे यह कोड न देखना पड़े, और अब एक गाढ़ी कॉफी पीने जा रहा हूँ :-)
    फिर भी, यह कर दिखाना प्रभावशाली है

  • मज़ाक उड़ाना ठीक है, लेकिन कोड काफ़ी readable है
    इसकी तुलना कुछ आधुनिक भाषाओं से होती है, जहाँ क्या हो रहा है यह समझने के लिए कई मिनट तक घूरना पड़ता है

    • एक समय मैं FAANG कंपनी में काम करता था और दुनिया-स्तरीय C++ विशेषज्ञों तक पहुँच थी। उनमें से कुछ अंतरराष्ट्रीय language standards committee के सदस्य थे
      मैंने internal C++ list पर पूछा कि क्या कोड की एक खास line memory leak पैदा करेगी; वह कोड सिर्फ STL templates और type conversions का इस्तेमाल करता था। लेकिन विशेषज्ञ इस बात पर सहमत नहीं हो सके कि मैं सही कर रहा था या नहीं। कुछ का मानना था कि leak होगा, कुछ का नहीं
      यह छोटी-सी सच्ची घटना C++ के बारे में बहुत कुछ कहती है। JavaScript भी ऐसी चीज़ों से भरी पड़ी है
    • यही COBOL की ताकत थी
      मैंने 1976 में programming शुरू की, COBOL और ICL PLAN सीखा, और पंच कार्ड इस्तेमाल करने के बाद प्रशिक्षण पूरा होने पर terminals पर काम किया
      प्रोग्राम 100% batch programs थे
      इस बात की बहुत मजबूत पक्षधरता थी कि कोई भी source code पढ़कर समझ सके। हालांकि, जब प्रोग्राम fail होता था तो उससे बनने वाले core dump को पढ़कर समझना पड़ता था, और यह उस readability को कुछ हद तक कम कर देता था। बहुत हुआ तो failure को किसी खास code line तक trace कर पाते थे, इसलिए दिमाग में प्रोग्राम को चलाकर देखने की आदत पड़ गई
      जब मैंने सरकारी संस्थान छोड़कर commercial programming में कदम रखा, तब भी 80 के दशक की शुरुआत तक COBOL और batch programs ही थे। मैंने 3 साल तक night support किया, और वहीं COBOL की कीमत समझ आई। पहली बार देखी गई listings और core dumps उठाकर भी मैं आम तौर पर काफ़ी जल्दी fix कर पाता था। हाँ, यह शर्त हमेशा रहती थी कि सुधार tactical fix ही होगा
    • इसी वजह से मुझे Ada और VHDL पसंद हैं
      वे कुछ हद तक verbose हो सकती हैं, लेकिन ज़्यादा “modern” भाषाओं की तुलना में पढ़ने में कहीं आसान हैं
    • COBOL को इस तरह डिज़ाइन किया गया था कि non-programmers भी इसे लिख और पढ़ सकें
      कम से कम सिद्धांत रूप में तो ऐसा ही था
    • MOVE FUNCTION MIN(BLOCK-ENTRY-MINIMUM-STATE-ID(LK-BLOCK), STATE-ID) TO BLOCK-ENTRY-MINIMUM-STATE-ID(LK-BLOCK)
  • हाई स्कूल में पाकिस्तान के एक छोटे शहर में मैंने थोड़ा COBOL सीखा था
    बुरा नहीं था, और मैंने financial statement की नकल करने वाला एक project किया था। इसमें कुछ अजीब हिस्से थे, लेकिन ज़्यादातर इंसानों, यानी non-programmers, को कोई भी programming language काफ़ी अजीब लगेगी, इसलिए COBOL पर लगा यह stigma मुझे ठीक से समझ नहीं आता
    उसी समय C भी सीखी थी, और वही आगे तक साथ रही :-)

  • मैं हमेशा सुनता हूँ कि Cobol programmers बहुत कम हैं, इसलिए उन्हें ऊँची salary मिलती है
    सोचता हूँ इस project की वजह से क्या job offers की बाढ़ आ गई होगी

    • दुर्लभ Cobol programmers नहीं, बल्कि वे लोग हैं जो business logic समझते हैं
      Cobol का इस्तेमाल अक्सर बहुत जटिल business operations में होता है
    • जैसा दूसरों ने कहा, असली बात existing business logic की जटिलता और आम तौर पर उस mainframe system की समझ है जिस पर वह कोड चलता है
      अगर ऐसा न होता, तो बस एक cross compiler बना लेते और काम ख़त्म हो जाता
    • ऐसे लोगों की क़ीमत उनकी programming skill से ज़्यादा इसलिए होती है क्योंकि वे बेहद जटिल, और अक्सर बिना documentation वाले systems तथा उनके business context को समझते हैं
  • COBOL सच में काफ़ी शानदार भाषा लगती है
    कोड भी वास्तव में बहुत अच्छी तरह व्यवस्थित है

  • इसमें unit tests हैं, यह बात मुझे पसंद आई