🤟🏻 🧚🏾 🛢️ एक मोबाइल गेम को प्रोटोटाइप करना, कहां से शुरू करना है, और कैसे करना है। भाग 1 📊 👨🏾‍🎓 ⚓️

ऐसा हुआ कि मैं अक्सर प्रोटोटाइप बनाता हूं (काम के लिए और व्यक्तिगत परियोजनाओं के लिए)
और मैं अपना अनुभव साझा करना चाहता हूं। मैं एक लेख लिखना चाहूंगा जो खुद को पढ़ने के लिए दिलचस्प होगा, और सबसे पहले मुझे आश्चर्य होता है कि एक व्यक्ति को क्या निर्देशित किया जाता है जब वह परियोजना के कार्यान्वयन में यह या वह निर्णय लेता है कि वह परियोजना कैसे शुरू करता है, यह अक्सर शुरू करना सबसे मुश्किल होता है।

एक ताजा उदाहरण जो मैं आपके साथ विचार करना चाहता हूं वह एक आकस्मिक भौतिकी-आधारित पहेली की अवधारणा है। कभी-कभी मैं शुरुआती लोगों के लिए विषय का विस्तार करने के लिए सुपर स्पष्ट चीजों का उल्लेख करूंगा।

आइडिया कुछ इस तरह दिखता है

भाग २
भाग 3

हम खेल के मैदान पर विभिन्न मॉडिफ़ायर की व्यवस्था करते हैं, जो रॉकेट की दिशा को बदलते हैं, आकर्षित करते हैं, तेज करते हैं, पीछे हटाते हैं, और इसी तरह। यह कार्य सितारों के बीच अगले ग्रह की जरूरत है, जो हमें चाहिए। जीतना ग्रह के ट्रेस के उतरने / छूने पर विचार किया जाता है। खेल का मैदान ऊर्ध्वाधर है, कई स्क्रीन ऊपर हैं, एक धारणा है कि प्रक्षेपवक्र बाएं / दाएं स्क्रीन के तल पर कब्जा कर सकता है। हार - यदि आप गंतव्य ग्रह से चूक गए, तो दूसरे ग्रह से टकराकर, ज़ोन से बहुत आगे निकल गया।

और मुझे आशा है कि हम सभी समझते हैं कि विकास में टूटने और हमारी योजनाओं को लागू करने से पहले, हमें पहले एक प्रोटोटाइप बनाना होगा - एक बहुत ही क्रूड और तेज़ उत्पाद जो आपको मूल मैकेनिक्स को जल्दी से आज़माने और गेमप्ले का एक विचार प्राप्त करने की अनुमति देगा। प्रोटोटाइप किस लिए बनाए जाते हैं? हमारे सिर में और व्यवहार में खेल प्रक्रिया बहुत अलग चीजें हैं, जो हमें शांत लगती हैं, दूसरों के लिए यह पूरी तरह से डरावनी होगी, साथ ही अक्सर परियोजना में विवादास्पद क्षण होते हैं - प्रबंधन, खेल के नियम, खेल की गतिशीलता, आदि। और इसी तरह। प्रोटोटाइप चरण को छोड़ना, वास्तुकला के माध्यम से काम करना, ग्राफिक्स को वितरित करना, स्तरों को समायोजित करना और अंत में पता लगाना कि खेल बकवास है। जीवन से - एक खेल में मिनी-गेम थे, लगभग 10 टुकड़े, प्रोटोटाइप के बाद यह पता चला कि वे बहुत उबाऊ थे, आधे बाहर फेंक दिए गए थे, आधे फिर से तैयार किए गए थे।

टिप - मूल यांत्रिकी के अलावा, विवादास्पद स्थानों को अलग करें, प्रोटोटाइप से विशिष्ट अपेक्षाएं लिखें। यह मुश्किल क्षणों पर पुनः लोड करने के लिए किया जाता है। उदाहरण के लिए, इस प्रोटोटाइप का सामना करने वाले कार्यों में से एक कितना सुविधाजनक और समझ में आता था कि खेल के मैदान में कई स्क्रीन होते हैं और उन्हें घाव होने की आवश्यकता होती है। योजना A - svayp को लागू करना आवश्यक था। प्लान बी - खेल मैदान को ज़ूम करने की क्षमता (यदि आवश्यक हो)। मॉडिफायर्स के लिए भी कई विकल्प थे। पहला विचार स्क्रीनशॉट में दिखाई देता है - हम संशोधक और इसके प्रभाव की दिशा को उजागर करते हैं। नतीजतन, मॉडिफ़र्स को केवल उन गोले के साथ बदल दिया गया, जो गोला को छूने पर रॉकेट की दिशा बदल देते हैं। हमने तय किया कि यह अधिक आकस्मिक रूप से, बिना प्रक्षेपवक्र आदि होगा।

सामान्य कार्यक्षमता जिसे हम लागू करते हैं:

आप रॉकेट के प्रारंभिक प्रक्षेपवक्र सेट कर सकते हैं, लंबवत से विचलन की डिग्री सीमित होने के कारण (रॉकेट को एक डिग्री से अधिक की ओर नहीं किया जा सकता है)
एक स्टार्ट बटन होना चाहिए, जिससे हम रॉकेट को सड़क पर भेजते हैं
संशोधन करते समय स्क्रीन को स्क्रॉल करना (शुरू करना)
खिलाड़ी के पीछे कैमरा आंदोलन (शुरुआत के बाद)
इंटरफ़ेस पैनल जिसके साथ खींचें और ड्रॉप संशोधक को क्षेत्र पर लागू किया जाएगा
प्रोटोटाइप में दो संशोधक होने चाहिए - प्रतिकर्षण और त्वरण
जब आप स्पर्श करते हैं तो आपके पास जो ग्रह होते हैं वे मर जाते हैं
जब आप जीतते हैं तो एक ग्रह होना चाहिए

आर्किटेक्चर

एक बहुत महत्वपूर्ण बिंदु, बड़े विकास में यह माना जाता है कि प्रोटोटाइप को जितना संभव हो उतना भयानक लिखा जाता है, फिर परियोजना को केवल खरोंच से लिखा जाता है। कई परियोजनाओं की कठोर वास्तविकता में, पैर प्रोटोटाइप से बाहर निकलते हैं, जो बड़े विकास के लिए खराब है - वक्र वास्तुकला, विरासत कोड, तकनीकी ऋण, रिफैक्टरिंग के लिए अतिरिक्त समय। खैर, और इंडी डेवलपमेंट पूरे सुचारू रूप से प्रोटोटाइप से बीटा में प्रवाहित होता है। मैं क्यों हूं? वास्तुकला को एक प्रोटोटाइप में रखना आवश्यक है, भले ही वह आदिम हो, ताकि आप बाद में रोएं नहीं, या सहकर्मियों के सामने ब्लश न करें।

ठोस, KISS, सूखा, YAGNI - किसी भी शुरू हमेशा दोहराने से पहले। चुंबन और YAGNI बारे में भी अनुभवी प्रोग्रामर भूलना)।

मैं किस बुनियादी ढांचे से चिपकता हूं

इसी टैग के साथ दृश्य में एक खाली गेमबजेक्ट गेमकंट्रोलर है, इस पर घटक / मोनो-बाइक लटके हुए हैं, इसे बेहतर बनाने के लिए इसे प्रीफ़ैब बनाया जाता है, फिर प्रीफ़ैब के लिए आवश्यक के रूप में घटकों को जोड़ें:

GameController - (खेल की स्थिति के लिए जिम्मेदार, सीधे तर्क के लिए) (जीता, हारा, कितना जीवन, आदि)
InputController - खिलाड़ी प्रबंधन से संबंधित सब कुछ, ट्रैकिंग टाकी, क्लिक, किसने क्लिक किया, नियंत्रण स्थिति, आदि।
TransformManager - खेलों में आपको अक्सर यह जानना होता है कि कौन कहाँ है, खिलाड़ी / दुश्मनों की स्थिति से संबंधित विभिन्न डेटा। उदाहरण के लिए, यदि हम ग्रह के ऊपर से उड़ान भरते हैं, तो खिलाड़ी हार जाता है, इसके लिए गेम कंट्रोलर जिम्मेदार है, लेकिन उसे खिलाड़ी की स्थिति का पता होना चाहिए। ट्रांसफ़ॉर्म मैनेजर बिल्कुल सार है जो चीजों के बारे में जानता है
AudioController - यहाँ यह स्पष्ट है, यह ध्वनियों के बारे में है
InterfacesController - और यहाँ यह स्पष्ट है, यह UI के बारे में है

समग्र चित्र उभरता है - प्रत्येक समझने योग्य कार्यों के लिए, एक नियंत्रक / इकाई बनाई जाती है जो इन समस्याओं को हल करती है, यह Google जैसी वस्तुओं से बचने की अनुमति देगा, यह समझ देता है कि कहां खोदना है, हम नियंत्रकों से डेटा देते हैं, हम हमेशा प्राप्त डेटा के कार्यान्वयन को बदल सकते हैं। सार्वजनिक क्षेत्रों की अनुमति नहीं है, हम केवल सार्वजनिक गुणों / विधियों के माध्यम से डेटा देते हैं। हम स्थानीय रूप से डेटा की गणना / परिवर्तन करते हैं।

कभी-कभी ऐसा होता है कि गेमकंट्रोलर को विभिन्न विशिष्ट तर्क और गणनाओं के कारण फुलाया जाता है। अगर हमें डेटा संसाधित करने की आवश्यकता है - इसके लिए एक अलग वर्ग GameControllerModel बनाना और वहां करना बेहतर है।

और इसलिए कोड शुरू हुआ

रॉकेट के लिए बेस क्लास

using GlobalEventAggregator; using UnityEngine; using UnityEngine.Assertions; namespace PlayerRocket { public enum RocketState { WAITFORSTART = 0, MOVE = 1, STOP = 2, COMPLETESTOP = 3, } [RequireComponent(typeof(Rigidbody))] public abstract class PlayerRocketBase : MonoBehaviour, IUseForces, IPlayerHelper { [SerializeField] protected RocketConfig config; protected Rigidbody rigidbody; protected InputController inputController; protected RocketHolder rocketHolder; protected RocketState rocketState; public Transform Transform => transform; public Rigidbody RigidbodyForForce => rigidbody; RocketState IPlayerHelper.RocketState => rocketState; protected ForceModel<IUseForces> forceModel; protected virtual void Awake() { Injections(); EventAggregator.AddListener<ButtonStartPressed>(this, StartEventReact); EventAggregator.AddListener<EndGameEvent>(this, EndGameReact); EventAggregator.AddListener<CollideWithPlanetEvent>(this, DestroyRocket); rigidbody = GetComponent<Rigidbody>(); Assert.IsNotNull(rigidbody, "    " + gameObject.name); forceModel = new ForceModel<IUseForces>(this); } protected virtual void Start() { Injections(); } private void DestroyRocket(CollideWithPlanetEvent obj) { Destroy(gameObject); } private void EndGameReact(EndGameEvent obj) { Debug.Log("     "); rocketState = RocketState.STOP; } private void Injections() { EventAggregator.Invoke(new InjectEvent<InputController> { inject = (InputController obj) => inputController = obj}); EventAggregator.Invoke(new InjectEvent<RocketHolder> { inject = (RocketHolder holder) => rocketHolder = holder }); } protected abstract void StartEventReact(ButtonStartPressed buttonStartPressed); } public interface IPlayerHelper { Transform Transform { get; } RocketState RocketState { get; } } }

कक्षा में जाने दें :

  [RequireComponent(typeof(Rigidbody))] public abstract class PlayerRocketBase : MonoBehaviour, IUseForces, IPlayerHelper

पहला, वर्ग अमूर्त क्यों है? हमें नहीं पता कि हमारे पास किस तरह के रॉकेट होंगे, वे कैसे आगे बढ़ेंगे, वे कैसे एनिमेटेड होंगे, गेमप्ले की कौन सी सुविधाएँ उपलब्ध होंगी (उदाहरण के लिए, रॉकेट के किनारे की तरफ उछलने की संभावना)। इसलिए, हम बेस क्लास को अमूर्त बनाते हैं, वहां मानक डेटा रखते हैं, और एब्स्ट्रैक्ट के तरीकों को रखते हैं, जिसके कार्यान्वयन के लिए विशिष्ट मिसाइल अलग-अलग हो सकती हैं।

यह भी देखा जा सकता है कि वर्ग में पहले से ही इंटरफेस का कार्यान्वयन है और एक विशेषता है जो गेमप्ले पर वांछित घटक को लटकाती है जिसके बिना रॉकेट रॉकेट नहीं है।

 [SerializeField] protected RocketConfig config;

यह विशेषता हमें बताती है कि इंस्पेक्टर के पास एक सीरियल करने योग्य क्षेत्र है जहाँ ऑब्जेक्ट को क्रमित किया जाता है, एकता सहित अधिकांश पाठों में, इन क्षेत्रों को सार्वजनिक किया जाता है, यदि आप एक इंडी डेवलपर हैं, तो ऐसा न करें। निजी फ़ील्ड और इस विशेषता का उपयोग करें। यहाँ पर मैं थोड़ा ध्यान देना चाहता हूँ कि यह वर्ग क्या है और यह क्या करता है।

RocketConfig

 using UnityEngine; namespace PlayerRocket { [CreateAssetMenu(fileName = "RocketConfig", menuName = "Configs/RocketConfigs", order = 1)] public class RocketConfig : ScriptableObject { [SerializeField] private float speed; [SerializeField] private float fuel; public float Speed => speed; public float Fuel => fuel; } }

यह एक ScriptableObject है जो रॉकेट सेटिंग्स को स्टोर करता है। यह डेटा पूल लेता है जो खेल डिजाइनरों की जरूरत है - वर्ग से परे। इस प्रकार, गेम डिजाइनरों को गड़बड़ करने और एक विशिष्ट रॉकेट के साथ एक विशिष्ट गेम प्रोजेक्ट स्थापित करने की आवश्यकता नहीं है, वे केवल इस कॉन्फ़िगरेशन को ठीक कर सकते हैं, जो एक अलग संपत्ति / फ़ाइल में संग्रहीत है। वे रनटाइम कॉन्फ़िगरेशन को कॉन्फ़िगर कर सकते हैं और इसे सहेजा जाएगा, यह भी संभव है अगर रॉकेट के लिए अलग-अलग खाल खरीदना संभव होगा, और पैरामीटर समान हैं - कॉन्फ़िगरेशन बस भटकता है जहां यह होना चाहिए। यह दृष्टिकोण अच्छी तरह से विस्तार कर रहा है - आप किसी भी डेटा को जोड़ सकते हैं, कस्टम संपादकों को लिख सकते हैं, आदि।

 protected ForceModel<IUseForces> forceModel;

मैं इस पर भी ध्यान देना चाहता हूं, यह किसी वस्तु में संशोधक लगाने के लिए एक सामान्य वर्ग है।

ForceModel

 using System.Collections.Generic; using System.Linq; using UnityEngine; public enum TypeOfForce { Push = 0, AddSpeed = 1, } public class ForceModel<T> where T : IUseForces { readonly private T forceUser; private List<SpaceForces> forces = new List<SpaceForces>(); protected bool IsHaveAdditionalForces; public ForceModel(T user) { GlobalEventAggregator.EventAggregator.AddListener<SpaceForces>(this, ChangeModificatorsList); forceUser = user; } private void ChangeModificatorsList(SpaceForces obj) { if (obj.IsAdded) forces.Add(obj); else forces.Remove(forces.FirstOrDefault(x => x.CenterOfObject == obj.CenterOfObject)); if (forces.Count > 0) IsHaveAdditionalForces = true; else IsHaveAdditionalForces = false; } public void AddModificator() { if (!IsHaveAdditionalForces) return; foreach (var f in forces) { switch (f.TypeOfForce) { case TypeOfForce.Push: AddDirectionForce(f); break; case TypeOfForce.AddSpeed: forceUser.RigidbodyForForce.AddRelativeForce(Vector3.up*f.Force); break; } } } private void AddDirectionForce(SpaceForces spaceForces) { //Debug.Log(""); //var t = AngleDir(forceUser.TransformForForce.position, spaceForces.CenterOfObject); forceUser.RigidbodyForForce.AddForce(Push(spaceForces)); } private Vector3 Push(SpaceForces spaceForces) { var dist = Vector2.Distance(forceUser.Transform.position, spaceForces.CenterOfObject); var coeff = 1 - (spaceForces.ColliderBound / dist); if (forceUser.Transform.position.x > spaceForces.CenterOfObject.x) return (Vector3.right * spaceForces.Force) * coeff; else return (-Vector3.right * spaceForces.Force) * coeff; } public static float AngleDir(Vector2 A, Vector2 B) { return -Ax * By + Ay * Bx; } } public interface IUseForces { Transform Transform { get; } Rigidbody RigidbodyForForce { get; } } public struct SpaceForces { public TypeOfForce TypeOfForce; public Vector3 CenterOfObject; public Vector3 Direction; public float Force; public float ColliderBound; public bool IsAdded; }

यह मैंने ऊपर लिखा है - यदि आपको किसी प्रकार की संगणना / जटिल तर्क करने की आवश्यकता है, तो इसे एक अलग वर्ग में रखें। एक बहुत ही सरल तर्क है - एक रॉकेट पर लागू बलों की एक सूची है। हम सूची को पुनरावृत्त करते हैं, यह देखते हैं कि यह किस प्रकार की शक्ति है और एक विशिष्ट विधि लागू करें। सूची को घटनाओं से अद्यतन किया जाता है, घटनाओं को संशोधक क्षेत्र में प्रवेश / बाहर निकलते समय होता है। प्रणाली काफी लचीली है, सबसे पहले यह एक इंटरफेस (हाय एनकैप्सुलेशन) के साथ काम करता है, संशोधक के उपयोगकर्ता न केवल रॉकेट / खिलाड़ी हो सकते हैं। दूसरे, सामान्य - आप जरूरतों / प्रयोगों के लिए विभिन्न वंशजों के साथ IUseForces का विस्तार कर सकते हैं, और अभी भी इस वर्ग / मॉडल का उपयोग कर सकते हैं।

पहले भाग के लिए पर्याप्त। दूसरे भाग में, हम घटनाओं की एक प्रणाली, निर्भरता इंजेक्शन, एक इनपुट नियंत्रक, एक रॉकेट क्लास खुद पर विचार करेंगे और इसे लॉन्च करने का प्रयास करेंगे।

एक मोबाइल गेम को प्रोटोटाइप करना, कहां से शुरू करना है, और कैसे करना है। भाग 1

आइडिया कुछ इस तरह दिखता है

आर्किटेक्चर

और इसलिए कोड शुरू हुआ

More articles: