https://virgool.io/feed/@fassihi از اعضای فن‌افزار fa 2026-06-16 08:17:34 https://files.virgool.io/upload/users/29388/avatar/avatar.png?height=120&width=120 https://virgool.io/@fassihi https://virgool.io/@fassihi/%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D8%AF%D8%B1-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%A8%D8%A7%D8%B2%DB%8C-gtrhqphxhyxl «طراحی بازی در برنامه‌نویسی، هنر یا صدا نیست. در تولید مهره‌های بازی یا رنگ کردن زمین بازی نیست. طراحی بازی به معنی ایجاد قوانینی است که آن مهره‌ها را زنده کند.»متن بالا از کتاب Designing Games, A Guide to Engineering Experiences است که توسط Tynan Sylvester در سال ۲۰۱۳ نوشته شده. این کتاب تولید یک بازی رو به صورت ساخت یک تجربه بررسی می‌کنه. تجربه‌ای که قراره مخاطب خودش رو درگیر عواطف متعددی کنه. تجربه‌ای که به مخاطبش نقش فعال می‌ده. بر خلاف کتاب یا سینما، هدف اصلی در طراحی بازی ساخت موتوری است که تجربه ایجاد کنه. این موضوع باعث می‌شه که ساخت بازی‌های ویدیویی چالش‌های بسیار ویژه خودشون رو داشته باشن که راه‌حلی برای اونا تا حالا در سایر صنایع دیده نشده. معمولا در مورد این‌ که ساخت بازی چه چیز‌هایی رو شامل می‌شه و یا اینکه چگونه انجام می‌شه زیاد صحبت شده. تمرکز این کتاب بیشتر روی چرایی انجام این کارهاست. اگر دلایل لازم برای ساخت این تجربه‌ها رو خوب بدونیم، راه‌حل‌های متعددی ممکنه انتخاب کنیم. این موضوع این روزها بیشتر از قدیم خودشون رو نمایان کرده. انواع بازی در سبک‌های مختلف و در اندازه‌های مختلف ساخته می‌شه که می‌تونه برای مخاطبان جذاب باشه. حتی خیلی از بازی‌های نیازی به لذت‌بخش بودن (fun) هم ندارن. هدف اصلی این کتاب جستجوی دلایل جذابیت بازی‌هاست. انگار بار دیگه و با نگاهی دیگه به مقوله بازی‌های ویدیویی فکر می‌شه.معمولا رشته مطالعات بازی‌ها (Game Studies) به فلسفه بازی‌های ویدیویی می‌پردازه. این کتاب ولی خیلی عملی‌تره. به نظر من جذابیت این کتاب در اینه که پلی بین مفاهیم فلسفی و عملی ساخت بازی ایجاد می‌کنه. نه خیلی سطح بالا و انتزاعی و نه خیلی تکنیکی و در مورد پیاده سازی‌های خاص. با مطالعه این کتاب تصمیم گرفتم دوره‌ای طراحی کنم که با کسانی که علاقمند هستن بیشتر بشه در موردش صحبت کرد و تعامل داشت. خوندن مطالب فقط می‌تونه مقدمه یک مسیر طولانی باشه. گفتگو و به اشتراک گذاشتن تجربه انواع کسانی که در صنعت تولید بازی‌ مشغول هستند به فهم مطالب به صورت واقعی خیلی کمک می‌کنه. به نظرم ارزش اصلی دوره‌ها در این بخشه. گام اول این دوره هفته آینده شروع می‌شه. لینک جزییات دوره و ثبت نام:https://evnd.co/ZM5El امیرحسین فصیحی امیرحسین فصیحی Fri, 01 Nov 2024 22:50:56 +0330 https://virgool.io/@fassihi/%D8%AC%D9%84%D8%B3%D9%87-%D8%A7%D9%88%D9%84-%DA%A9%D8%A7%D8%B1%DA%AF%D8%B1%D8%AF%D8%A7%D9%86-%DA%A9%D8%A7%D8%B1%D8%A2%D9%81%D8%B1%DB%8C%D9%86-a2vjce0jhak7 کارگاه آنلاین کارگردان کارآفرین را اخیرا برگزار کردم. هدف این کارگاه بررسی نقش کسانی بود که هم رهبری ساخت یک بازی را بر عهده می‌گیرند و هم به تشکیل تیم می‌پردازند. ویژگی‌های این افراد را بررسی کردیم و از چالش‌های متعدد آن صحبت کردی.لینک ویدیوی یوتیوب جلسه اول:https://youtu.be/VUWeT2wdl_Iلینک به اسلایدها:https://www.slideshare.net/slideshow/founder-game-director-workshop-session-1/269411401 امیرحسین فصیحی امیرحسین فصیحی Thu, 30 May 2024 03:44:00 +0330 https://virgool.io/@fassihi/%DA%A9%D8%A7%D8%B1%DA%AF%D8%B1%D8%AF%D8%A7%D9%86-%DA%A9%D8%A7%D8%B1%D8%A2%D9%81%D8%B1%DB%8C%D9%86-gaefilcv32gb از کودکی و نوجوانی، بسیاری از ما رویای ساخت یک بازی ویدیویی را در سر پرورانده‌ایم. شور و هیجان تجربه دنیای مجازی و خلاقیت برانگیخته شده توسط بازی‌ها، ما را به تصور اینکه روزی خودمان بازی بسازیم سوق داده است. برای بسیاری، این رویا همچون بسیاری دیگر از رویاها به فراموشی سپرده می‌شود. عده‌ای با تخصص یافتن در زمینه‌های مرتبط با بازی‌سازی، خود را به آن رویا نزدیک‌تر می‌کنند. تعداد کمی هم هستند که این رویا را در ذهن خود زنده نگه می‌دارند و در نهایت به تحقق بخشیدن به آن اقدام می‌کنند. این افراد باید شجاع باشند، باید بر دانش و تجربه خود بیفزایند و به دانشجویان دائمی عرصه بازی‌سازی تبدیل شوند. آن‌ها باید بهترین‌ها را شناسایی کرده و آن‌ها را برای همراهی در این مسیر پیچیده دعوت کنند. این افراد، کارگردانان کارآفرینی هستند که با تمام وجود به سمت چشم‌اندازی که برای بازی خود در ذهن دارند، حرکت می‌کنند و با تشکیل تیم‌های بازی‌سازی و رهبری آن‌ها، ارزش آفرینی می‌کنند.چگونه می‌توان در مسیر ساخت بازی‌های ویدیویی پیش رفت؟ آیا تنها علاقه کافی است؟ بازی‌سازی فرایندی است که به دانش فنی مانند برنامه‌نویسی و تخصص‌های هنری مختلف نیاز دارد؛ از جمله مدل‌سازی سه‌بعدی شخصیت‌ها و محیط‌ها، انیمیشن، صداگذاری و موسیقی. علاوه بر این، طراحی چالش‌های بازی و روایت نیز بخش مهمی از فرآیند است. آیا لازم است که یک کارگردان کارآفرین در تمامی این حوزه‌ها مهارت داشته باشد؟ دانش و مسئولیت‌های روزانه یک کارگردان بازی‌ساز چیست؟با جمع‌آوری متخصصان از رشته‌های گوناگون، تشکیل تیم چندرشته‌ای ضروری است. اما چگونه یک کارگردان می‌تواند این متخصصان را به‌گونه‌ای هدایت کند که نتیجه کار، محصولی منسجم و با کیفیت باشد؟ آیا باید شرکت‌داری بیاموزد؟ آیا مهارت‌های مدیریتی او نقش کلیدی دارند؟ تفاوت نقش او با کارآفرینان در سایر حوزه‌ها چیست؟آیا کارگردان کارآفرین بودن در ایران، کشوری که پایه‌های صنعت بازی‌سازی را ندارد، دشوارتر است؟هفته آینده کارگاهی را تدارک دیده‌ام که در آن به تبادل تجربیات خود در زمینه بازی‌سازی با شرکت‌کنندگان خواهم پرداخت و پرسش‌های بالا را مورد بررسی قرار خواهیم داد. هدف من این است که خلاصه‌ای از تجربه‌ام را به اشتراک گذاشته و درس‌های کلیدی و مهمی که آموخته‌ام را به کسانی که مایل به ورود به این حرفه هستند منتقل کنم. امیدوارم که این کارگاه به آن‌ها کمک کند تا با خطاهای کمتری نسبت به آن‌چه من مرتکب شدم مواجه شوند و مسیری روان‌تر را تجربه کنند.این کارگاه در سه جلسه و به صورت آنلاین برگزار می‌شود.لینک ثبت نام در کارگاه:https://evand.com/events/entrepreneur-director امیرحسین فصیحی امیرحسین فصیحی Fri, 12 Apr 2024 05:45:21 +0330 https://virgool.io/@fassihi/%DA%A9%D8%A7%D8%B1%DA%AF%D8%A7%D9%87-%DA%86%D8%B4%D9%85-%D8%A7%D9%86%D8%AF%D8%A7%D8%B2-fxlvjc0xm5cf در راستای مطلب قبلی در خصوص چشم‌انداز و نقشه راه برای تیم‌های بازی‌سازی، یک کارگاه آنلاین برگزار کردم.در این کارگاه در مورد اهمیت چشمانداز و نقشه راه و همینطور روش ترسیم آن‌ها صحبت شد. نیمه دوم کارگاه، پاسخ به پرسش‌های شرکت کنندگان و صحبت در مورد تجربیات حرفه‌ای آنان است.لینک ویدیوی کارگاه: https://youtu.be/TnGGmug5VIo لینک اسلاید‌ها: https://www.slideshare.net/amirhfassihi/ss-258900482/amirhfassihi/ss-258900482 اثر هنری اسلاید آخر کاری است از بهزاد نجف‌پور: https://www.instagram.com/behzad_najafpoor/?hl=enفونت فارسی استفاده شده در پوستر کارگاه «وزیر» است که توسط صابر راستی‌کردار ساخته شده است. برای حمایت از این متخصص عزیز به این صفحه رجوع کنید: https://rastikerdar.github.io امیرحسین فصیحی امیرحسین فصیحی Wed, 05 Jul 2023 18:04:57 +0330 https://virgool.io/@fassihi/%D8%A2%DB%8C%D8%A7-%D8%AF%D8%B1-%D9%85%D8%B3%DB%8C%D8%B1-%D8%AF%D8%B1%D8%B3%D8%AA%DB%8C-%D9%82%D8%B1%D8%A7%D8%B1-%D8%AF%D8%A7%D8%B1%DB%8C%D9%85-dazrnqpsuven «از کجا آمده‌ام آمدنم بهر چه بود؟ به کجا می‌روم آخر ننمایی وطنم»از اصلی‌ترین دغدغه‌های هر تیم خلاق این است که بداند آیا در مسیر درستی قرار دارد یا خیر؟ در این نوشتار، تلاش خواهم کرد از زاویه‌های مختلف این موضوع را بررسی کنم و به این بپردازم که آیا اصلا ممکن است بتوان به این پرسش پاسخ داد؟آيا در مسیر درستی قرار داریم؟پاسخ به این سوال در خود سوال نهفته است؛ «مسیر». تنها اگر مسیرمان را بشناسیم، می‌توانیم قضاوت کنیم که در مسیر درستی قرار داریم یا خیر. دقیقا مشابه داشتن یک نقشه راهنما. با نقشه فیزیکی می‌توانیم نسبتا متوجه شویم که در مسیر درست قرار داریم یا خیر و با نقشه‌ای دیجیتال و داشتن مکان‌یاب، دقیقا می‌توانیم بدانیم که کجا هستیم. در ادامه، این موضوع را به همراه مثال‌هایی برای یک تیم بازی‌ساز بیشتر تشریح خواهم کرد.پرسش اول: مسیر درست کدام است؟همانطور که در هر نقشه‌ای مسیرهای متعددی وجود دارد، برای فعالیت تیم ما نیز مسیرهای گوناگونی وجود دارد که هر کدام ما را به مقصدی هدایت می‌کند. مسیر درست کدام است؟ فرض کنید یک شخص از خارج از کشور به ایران بیاید و با داشتن نقشه‌ای در دست، از شما بپرسد کدام مسیر برای من مناسب است؟ طبیعتا اولین پرسش شما این است که: «خب، شما دوست داری به چه نوع مناطقی بروی؟ کنار دریا، مکانی تاریخی، صحرا، کوهستان، برف یا شهری شلوغ؟» شخص خارجی به شما می‌گوید: «علاقمندم به کنار دریا بروم.» سپس شما چند مسیر را به او پیشنهاد می‌دهید.در تعامل بالا، در واقع شما ابتدا از چشم‌انداز شروع کردید. رسیدن به مکانی کنار دریا یک چشم‌انداز، که اولین گام برای مشخص کردن نقشه راه است.چشم‌اندازچشم‌انداز به نوعی آرمان تیم است. چشم‌انداز شما برای تیم‌تان چیست؟ خوب است که حداقل در مورد ده سال آینده فکر کنیم و از الان بتوانیم تا حدی به پرسش‌های زیر پاسخ دهیم:چه جایگاهی برای آینده تیم متصور هستیم؟روی چه پلتفرم‌هایی بازی تولید خواهیم کرد؟تیم ما چه اندازه خواهد بود؟ویژگی‌های اصلی و برتری تیم ما در چه خواهد بود؟نفرات کلیدی تیم ما چه نوع کسانی خواهند بود؟هویت تیم ما چه خواهد بود؟تفاوت چشم‌انداز با هدف آن است که چشم‌انداز کلی‌تر است و لزوما قابل دسترسی نیست ولی هدف خیلی مشخص است و حتما باید بتوان به آن رسید. به عنوان مثال، ساخت یک بازی برای پلتفرم رایانه و فروش یک میلیون نسخه، یک هدف است. تبدیل شدن به یکی از بهترین بازی‌سازان مستقل پلتفرم رایانه، یک چشم‌انداز است.آیا می‌توان کیفیت چشم‌انداز را بررسی کرد؟چشم انداز از خواست و توانایی یک یا چند نفر تعریف می‌شود و خیلی شخصی یا تیمی است. به همین دلیل در مورد کیفیت آن به راحتی نمی‌توان قضاوت کرد. اما به صورت کلی می‌توانیم به موارد زیر اشاره کنیم:چشم‌انداز رویاپردازانه نیست.ممکن است برای آینده خود خیلی رویاپردازانه فکر نکنیم و در اثر این کار، اهداف بلند‌مدت ساده‌تری را به اشتباه چشم‌انداز قلمداد کنیم. طبیعتا با اهداف کوچک‌تر و قابل دسترس‌تر، تیم‌ ما هم رشد و موفقیت کمتری خواهد داشت.چشم‌انداز بیش از حد رویا پردازانه است.صحبت در مورد درستی و غلطی این کار، بسیار دشوار است. همواره شاهد این بوده‌ایم که تیم‌هایی با چشم‌اندازهای جاه‌طلبانه توانسته‌اند معجزه‌وار مسیر رشد را طی کنند و بسیار موفق شوند. فعلا همین را داشته باشید تا در مرحله بعد از چشم‌انداز، در نقشه راه، بهتر می‌توانیم در این خصوص نظر دهیم.چشم‌انداز مناسب ما نیست.چگونه می‌توانیم رویایی در سر داشته باشیم که برای ما مناسب نباشد؟ به نظر عجیب می‌آید، ولی؛ - چشم‌انداز در مورد وضعیتی در آینده است که ما هیچ‌گاه تجربه نکرده‌ایم. ممکن است آن وضعیت را واقعا دوست نداشته باشیم و فقط تصور کنیم که وضعیت خوبی است. مثلا شخصی که تاکنون کنار دریا نرفته، شاید با رفتن کنار دریا متوجه شود که اصلا علاقه‌ای به آن‌جا ندارد. آیا ممکن است ما تصور کنیم که تمایل داریم یکی از بهترین بازی‌سازان دنیا باشیم و بازی‌های شوتر اول شخص برای کنسول بسازیم، در حالی‌که واقعا این وضعیت را دوست نداشته باشیم؟ متاسفانه ممکن است. چرا؟ نکته مهم این است که چشم‌انداز در مورد «بودن» است و نه خروجی‌های فرعی آن. همه دوست دارند که به عنوان آن بازی‌ساز موفق مورد تشویق قرار گیرند و شهرت داشته باشند و از نظر مالی هم قله‌های کسب درآمد را فتح کرده باشند. اما سوال اصلی این است که آیا هر روز در آن نقش بودن را هم دوست داریم؟ آيا می‌دانیم زندگی ما به عنوان مدیر یک استودیو موفق بازی‌ساز کنسول در سبک شوتر اول شخص هر روز چگونه خواهد بود؟ ممکن است برای ما رویایی و یا عذاب‌آور باشد. بنابراین خوب است تلاش کنیم و چشم‌انداز خود را محک بزنیم. روش این محک زدن شناخت وضعیت آن چشم‌انداز و شناخت بیشتر خود و تیم است.- مسیرهای متعددی ما را به سمت چشم‌انداز می‌برد. ممکن است این مسیرها برای ما مناسب نباشد. این موضوع مشابه مورد قبل است با این تفاوت که اینجا در مورد بودن در مسیری که ما را به چشم‌انداز می‌رساند صحبت می‌کنیم و نه تجربه بودن در چشم‌انداز. به عنوان مثال، برای تبدیل شدن به یک تیم ۶۰ نفره، لازم است که یک برنامه‌نویس کارآفرین که با تیمی ۵ نفره کارش را آغاز می‌کند، به تدریج برنامه‌نویسی نکند و همچنین با مسایل مالی و سرمایه‌گذاری آشنا شود. آیا این مسیر برای آن برنامه‌نویس جذاب است؟ ممکن است باشد یا نباشد. چشم‌انداز یک تیم مستقل موفق ۱۰ نفره به او اجازه می‌دهد که از توانایی‌های فنی خود بیشتر استفاده کند و در خدمت تیم باشد. بنابراین به دلیل مسیرهای گوناگون، می‌توان در مورد چشم‌اندازهای متعدد هم قضاوت کرد.وقتی چشم‌انداز مشخص شد چه کنیم؟با مشخص شدن چشم‌انداز، نوبت یافتن مسیرهایی است که ما ره با آن می‌رساند. سندی که این مسیر را مشخص می‌کند نقشه راه (Roadmap) نام دارد که در واقع راهبرد (Strategy) تیم ما را نیز مشخص می‌کند.نقشه راهبا مشخص کردن نقطه‌های میانی در مسیری که ما را به سمت چشم‌اندازمان می‌برد، نقشه راه ما مشخص می‌شود. این نقطه‌های میانی ممکن است اهداف یک ساله یا شش ماهه ما باشند. نقشه راه ده ساله شامل ده هدف است که در مسیر چشم‌انداز ما قرار دارند. اگر هر کدام از این اهداف ما را به اندازه مشخصی به چالش بکشند، در یک مسیر رشد پیوسته قرار خواهیم گرفت. هدفی که خیلی با حقیقت فاصله داشته باشد باعث ناامیدی ما و اهداف ساده نیز باعث درجا زدن تیم ما می‌شوند.کدام هدف مناسب است؟برای مشخص کردن اهداف نقشه راه، پرسش اول این است که هدف چه ویژگی‌ای باید داشته باشد؟ مهمترین نکته این است که این هدف باید قابل تعریف و اندازه‌گیری باشد. باید بتوانیم در پایان سال، به صورت دقیق بررسی کنیم که به هدف نزدیک شده‌ایم یا خیر. برای سنجش نزدیک شدن به هدف عموما از شاخص‌های کلیدی عملکرد (KPI) استفاده می‌شود.شاخص‌های کلیدی عملکرد اهداف ما چیست؟یکی از اولین شاخص‌هایی که معمولا به عنوان شاخص کلیدی عملکرد هدف تیم انتخاب می‌شود، میزان درآمد حاصل از فروش بازی است. به عنوان مثال ممکن است هدف یک تیم در پایان سال، انتشار یک بازی با درآمد صد هزار دلار باشد. گاهی نیز شاخص‌های مرتبط به عملکرد بازی به عنوان هدف قرار می‌گیرند که به صورت غیر مستقیم به فروش مرتبط هستند؛ مانند تعداد دانلود، نرخ ماندگاری کاربرها، کاربران فعال و غیره. این شاخص‌ها خروجی‌محور هستند، به این معنی که اندازه‌گیری آن روی دستاورد تیم قرار گرفته است و نه لزوما ورودی تیم که همان اعضا و فرآیندهای کاری آن‌هاست. انتخاب اینگونه شاخص‌ها تا حدی خطرناک است. خطرناک؟ چرا؟ ما هر روز با این دست شاخص‌ها سروکله می‌زنیم!بله خطرناک، به این دلیل که سرنوشت محصولات خلاق، مانند بازی‌های ویدیویی، در بازار به عوامل درونی و بیرونی مرتبط است. عوامل درونی به تیم ما و فرآیند تولید مرتبط می‌شود و عوامل بیرونی به وضعیت صنعت و بازار. دلیل موفقیت یک محصول هم عامل درونی دارد و هم عامل بیرونی. متاسفانه فقط عوامل درونی در کنترل ما هستند و عوامل بیرونی به صورت تصادفی روی سرنوشت محصول ما تاثیر می‌گذارد. علاوه بر این، خروجی تیم ما لزوما نسبت خطی با ورودی تیم ما ندارد.این دو مورد را در زیر توضیح می‌دهم.آیا ما تاس می‌اندازیم؟چگونه ممکن است که عوامل بیرونی به صورت تصادفی روی موفقیت ما تاثیر بگذارند؟ برای پاسخ، چند مثال را بررسی می‌کنم:۱ - از میان دو مکانیک پیشنهادی برای بازی، یکی را انتخاب کردیم در صورتی که مکانیک رد شده برای گیمرها بسیار جذاب‌تر بود.۲ - ناشری که انتخاب کردیم به تعهد‌هایش عمل نکرد.۳ - تاریخ انتشار بازی همزمان شد با فصل شلوغ نشر بازی‌ها.۴ - قبل از عرضه‌ی بازی ما، یک بازی مشابه در همین سبک منتشر شد و بسیار موفق بود.۵ - ژانری که انتخاب کرده بودیم در طول فرآیند ساخت به تدریج محبوبیتش را بین گیمرها از دست داد.۶ - یکی از افراد کلیدی تیم خود را به صورت موقتی از دست دادیم.۷ - عواملی روی صنعت بازی تاثیر گذاشت و فروش همه بازی‌ها کم شد. مثلا راه‌اندازی یک شبکه جدید سریال‌های تلویزیونی.بنابراین بعضی از دلایل +عدم موفقیت به تلاش‌های تیم ما مربوط نمی‌شوند.نسبت غیر خطی بین ورودی و خروجی تیمدستاورد یک تیم، به عنوان مثال میزان فروش یک بازی‌ ویدیویی تولید شده، لزوما با انرژی و تلاش آن تیم نسبت مستقیم ندارد. به این معنی که نمی‌توان گفت اگر یک تیم بعد از دو سال تلاش، یک بازی بسازد که ۱۰۰ هزار نسخه فروش داشته باشد، بعد از چهار سال تلاش، بازی‌ای خواهد ساخت که ۲۰۰ هزار نسخه فروش برود. به احتمال زیاد، موفقیت خروجی تیم به صورت نمایی بالا خواهد رفت. این دومین دلیلی است که انتخاب شاخص‌های خروجی‌محور را به عنوان معیار در نقشه راه چالش‌برانگیز می‌کند.چه چیزی را اندازه گیری کنیم؟به نظر من، بهترین شاخص‌های اندازه‌گیری، آنهایی‌اند که تا حد خوبی در کنترل تیم ما و افراد تیم‌مان هستند. چهار شاخص مناسب برای اندازه‌گیری را در زیر توضیح می‌دهم:ماندگاری اعضای کلیدی تیم (بودن)یکی از مهمترین شاخص‌ها برای سنجش موفقیت یک تیم، در کنار هم ماندن اعضای کلیدی است. اعضای کلیدی یارانی‌اند که در تصمیم‌‌گیری‌های مهم تیم دخیل هستند. این تصمیم‌گیری‌ها به صورت کلی به موارد مربوط به خود بازی و یا خارج آن و استودیو مربوط می‌شود.رشد اعضای کلیدی تیم (شدن)قوی‌تر شدن نفرات کلیدی تیم از مهم‌ترین شاخص‌ها و عموما پنهان است. این رشد را هم در موارد فنی و هم غیرفنی می‌توان سنجید. بالا رفتن کیفیت برنامه نویسی یک نمونه از رشد فنی و بهتر شدن در توضیح یک مساله برای هم تیمی، یک نمونه از رشد غیر فنی است. پرسش مرکزی این شاخص آن است که چه کاری انجام می‌دهیم که باعث رشد اعضای تیم می‌شود؟ در مورد اهمیت نفرات کلیدی و رشد آن‌ها در ادامه توضیح خواهم داد.انتخاب پروژه و مطابقت آن با تیم (تیم - پروژه)این‌ موضوع که تیم روی چه پروژه‌ای کار می‌کند، یکی از مهمترین موارد سنجش در نقشه راه تیم است. یکی از بهترین روش‌های انتخاب پروژه که تاکنون شنیده‌ام این است که کاری را باید برگزید که سه ويژگی مهم زیر را داشته باشد:اعضای تیم به آن کار خیلی علاقمند باشند.اعضای تیم توانایی لازم برای اجرای با کیفیت آن پروژه را داشته باشند.محصول نهایی برای مخاطب ارزشمند باشد.بنابراین موردی را که می‌سنجیم آن است که آیا پروژه مناسبی انتخاب کرده‌ایم که مناسب مخاطب و تیم ما باشد؟مطابقت اندازه و ساختار تیم با نفرات کلیدی (نفر - تیم)توانمندی‌های خاص هر عضو تیم مشخص می‌کند که او مناسب چه جایگاهی دار تیم است. برخی از نفرات در حل مسایل فنی توانمندتراند و عده‌ای در مدیریت فرآیندها. ساختار کلی تیم و اندازه آن تابعی از قرارگیری اعضای کلیدی در جایگاه مناسب است. ما همواره می‌توانیم مناسب بودن ساختار تیم را با توجه به اعضای کلیدی تیم بسنجیم. در ادامه بیشتر در اینباره توضیح می‌دهم.اندازه‌گیری این شاخص‌ها دشوار استطبیعتا اندازه‌گیری اینگونه شاخص‌های درونی تیم دشوار است و سنجش تعداد دانلود یک بازی بسیار ساده‌تر از این شاخص‌هاست. دقیقا به همین دلیل است که تولید و ساخت بازی‌های مستقل بیشتر شبیه به جادوگری‌ست و سرمایه‌گذاران فن‌آوری معمولا با چالش بسیاری در این حوزه مواجه می‌شوند. همین مشکل، باعث از بین رفتن فرصت‌های طلایی و ادامه حیات بسیاری از تیم‌های خلاق شده است.روش مشخص کردن نقشه راه شاخص‌های خروجیبرای ترسیم اینگونه نقشه راه معمولا به صورت بازگشتی، از انتها به ابتدا برنامه‌ریزی می‌شود. به عنوان مثال تیم هدف خود را در پایان سال دهم، عرضه‌ی بازی با ۵ میلیون دانلود برای پلتفرم رایانه‌های شخصی قرار می‌دهد و بر این اساس، سال هشتم ساخت بازی با ۳ میلیون دانلود و به همین ترتیب، سال دوم ساخت بازی با ۵۰۰ هزار دانلود.مشکل اول اینگونه ترسیم نقشه راه این است که تمامی این آن اعداد آرزوهای نسبتا بی‌پایه هستند. حتی ممکن است که خروجی تیم ما بسیار بیشتر از آن باشد. مشکل جدی بعدی آن است که اتصال آن معیارها به واقعیت تیم و پتانسیل اعضا، همان‌طور که در بالا توضیح دادم، ناممکن است. به راحتی ممکن است در پایان سال دوم، بازی ساخته باشیم که فقط ۵ هزار نسخه فروش داشته ولی تیم ما در وضعیتی باشد که دو پروژه بعد آن بسیار موفق شود. تلاش برای سنجش معیارهای درونی به ما کمک می‌کند که بدانیم در مسیر موفقیت قرار داریم یا خیر؟نقشه راه خروجی‌محور خشک و بدون تغییر است. همواره مقصدهایی را به ما نشان می‌دهد که هرگز به آن‌ها نخواهیم رسید. این نقشه راه تابلویی برای سوگواری دایمی تیم است.البته هر نوع هدف‌گذاری می‌تواند جنبه‌های مثبت نیز داشته باشد. متحد کردن تیم و تلاش همه برای رسیدن به هدف می‌تواند یکی از جنبه‌های مثبت هدف‌گذاری با معیارهای بیرونی باشد. مشکل آن‌جاست که معمولا این اهداف با واقعیت فاصله‌ دارند و این موضوع باعث دلسرد شدن تیم می‌شود.روش مشخص کردن نقشه راه شاخص‌های ورودیدر این روش از وضعیت فعلی شروع می‌کنیم و تلاش می‌کنیم تا آینده را پیش‌بینی کنیم. به عنوان مثال، از امروز تا یک سال آینده:۱ - برنامه‌ریزی برای ماندگاری اعضای اصلی می‌شود.۲ - برنامه رشد شخصی هر عضو کلیدی مشخص می‌شود.۳ - مناسب بودن اهداف پروژه بررسی می‌شود.۴ - رشد ساختار تیم بررسی می‌شود.سپس این پیش‌بینی برای سالهای بعدی ادامه پیدا می‌کند تا مسیری بلند‌مدت ترسیم شود. در این روش در حقیقت از نقشه راه به سمت چشم‌انداز حرکت می‌کنیم. برای مثال یک نقشه راه ده ساله را بررسی می‌کنیم که در آن تولید ۵ بازی در نظر گرفته شده است.با در نظر گرفتن این موارد، می‌توان در مورد پروژه و تیم پیش‌بینی‌هایی داشت. به عنوان مثال، یک نمونه پیش‌بینی آینده یک تیم به قرار زیر است:۱ - بازی پلتفرمر دو بعدی ساده، زمان تولید ۱ سال (طراح - برنامه نویس - آرتیست)اندازه تیم: ۳۲ - پازل پلتفرمر سه‌بعدی، زمان تولید ۱.۵ سال (طراح - برنامه نویس - آرتیست - مدل‌ساز محیط - مدل‌ساز کاراکتر - انیماتور)اندازه تیم: ۶۳ - بازی مترویدوانیا ساید اسکرول سه‌بعدی، زمان تولید ۲ سال (طراح ارشد - طراح مرحله - برنامه‌نویس ارشد - برنامه‌نویس * ۲ - آرتیست ارشد - مدل‌ساز محیط - مدل‌سازی کاراکتر - انیماتور)اندازه تیم: ۹۴ - بازی اکشن ادونچر هک اند اسلش ایزومتریک سه‌بعدی، زمان تولید ۲.۵ سال (طراح ارشد - طراح مرحله - طراح مبارزه - نویسنده و طراح روایت - برنامه‌نویس ارشد - برنامه نویس *۲ - برنامه نویس ابزار - آرتیست ارشد - مدل ساز محیط - مدل‌ساز کاراکتر - انیماتور - طراح صدا و موسیقی)اندازه تیم: ۱۴۵ - اکشن ادونچر هک اند اسلش سوم‌شخص، زمان تولید ۳ سال (کارگردان - طراح ارشد - طراح مرحله - طراح مبارزه - طراح سیستم - طراح روایت - نویسنده - کارگردان هنری - رهبر بخش سه بعدی - رهبر دو بعدی - کانسپت آرتیست - طراح واسط کاربری - مدل‌ساز کاراکتر - مدل‌ساز محیط - متخصص جلوه‌های ویژه - انیماتور * ۲ - رهبر صدا - آهنگ‌ساز - کارگردان فنی - برنامه‌نویس رهبرگیم‌پلی - برنامه‌نویس رهبر سیستم - برنامه‌نویس * ۴ - برنامه‌نویس ابزار - مدیر کنترل کیفیت - تستر * ۲ - پرودوسر - دستیار پرودوسر برون‌سپاری هنری)اندازه تیم: ۳۲بررسی دنبال کردن نقشه راههر سال، با توجه به شاخص‌های قابل اندازه‌گیری، وضعیت تیم را نسبت به نقشه راه را می‌سنجیم. در ادامه، نمونه‌ای از این سنجش‌ها را با هم بررسی کنیم.پایان سال ۱: عرضه‌ی بازی پلتفرمر دوبعدی سادهشاخص اول: آیا اعضای کلیدی در تیم هستند؟ بله.شاخص دوم: آیا اعضای کلیدی در مسیر رشد قرار دارند؟ برنامه‌نویس با ساخت بازی در موتور یونیتی تجربه‌ی خوبی بدست آورده، آرتیست تجربه‌‌ای در فرآیندهای تولید آرت برای بازی کسب کرده، طراح تجربه‌های عملی طراحی مرحله پایه و همچنین سایر نیازهای طراحی بازی ساده را کسب کرده است.شاخص سوم: آیا پروژه‌ی مناسبی انتخاب شده است؟پروژه مورد علاقه تیم بود.پروژه توسط تیم قابل انجام بود.از پروژه در بازار استقبال اندکی شد. فاصله داشتن با هر مقصد در نقشه راه فرصتی برای تحلیل و یادگیری از خطاهاست.شاخص چهارم: آیا ساختار تیم مناسب است؟ساختار تیم همان سه نفر اول است و برای تولید صدا و موسیقی با شخصی خارج از تیم همکاری شد. هر سه نفر نیازمند تقویت توانمندی‌های فنی و همچنین آشنا شدن بیشتر با یکدیگر بوده‌اند.پایان سال ۲: اواخر فاز تولید بازی پازل پلتفرمر سه بعدیشاخص اول: سه عضو اصلی همچنان در تیم هستند. ۳ آرتیست جدید ممکن است به اعضای کلیدی تبدیل شوند.شاخص دوم: هر سه عضو تجربه‌ی نشر یک بازی را کسب کرده‌اند. چالش‌های جدی‌تری برای هر کدام‌شان در حوزه‌ی خودشان وجود دارد. سه عضو جدید مشغول رشد و یادگیری در حوزه‌ی خود هستند.شاخص سوم: آیا پروژه‌ی مناسبی انتخاب شده است؟هر یک از اعضا به پروژه علاقمند هستند.کارهای صورت‌گرفته مطابق با توانایی‌های تیم است.برش عمودی بازی برای ناشران ارسال شد و بازخوردهای مثبتی از آن‌ها دریافت شد.شاخص چهارم: آیا ساختار تیم مناسب است؟آرتیست پروژه در نقش رهبر قرار گرفته است و مدل‌ساز محیط، مدل‌ساز کاراکتر و انیماتور به او کمک می‌کنند.این چهار شاخص را می‌توان در پایان هر سال اندازه‌گیری نمود و جایگاه تیم را با توجه به نقشه راه اولیه و چشم‌انداز سنجید.یک نمونه دیگر از این سنجش را بررسی می‌کنیم.پایان سال ۵: فاز پیش تولید بازی اکشن ادونچر هک اند اسلش ایزومتریکشاخص اول: آیا اعضای کلیدی در تیم هستند؟سه بنیان‌گذار تیم همچنان در تیم حضور دارند.شاخص دوم: آیا اعضای اصلی در مسیر رشد قرار دارند؟هر سه بنیان‌گذار مشغول کسب تجربه در زمینه‌های رهبری هستند.شاخص سوم: آیا پروژه مناسبی انتخاب شده است؟پروژه مطابق با علاقمندی همه اعضای اصلی تیم است.توانایی رهبری در اعضای اصلی و توانایی‌های فنی در سایر نفرات اجرایی وجود دارد.سند معرفی اولیه بازی و پیچ بازی، مورد استقبال ناشران قرار گرفته است.شاخص چهارم: آيا ساختار تیم مناسب است؟با توجه به استعداد نفرات کلیدی در رهبری و مسوولیت‌پذیری، تیم ساختار مناسبی دارد. بنیان‌گذار اول در نقش کارگردان بازی قرار دارد. او دانش خوبی از سه حوزه طراحی، فنی و هنری کسب کرده است و امکان تعریف صورت مساله‌ها و همچنین بررسی کیفیت راه‌حل‌ها را در این زمینه‌ها کسب کرده است. او علاوه بر دانش فنی، از نظر شناخت فرآیندها و روابط فردی نیز توانایی خوبی دارد. بنیان‌گذار دوم، در نقش رهبر تیم برنامه‌نویسی، هدایت یک تیم سه نفره را بر عهده گرفته است و بنیان‌گذار سوم، به عنوان رهبر تیم هنری، مشغول هدایت یک تیم چهار نفره است. طراح مرحله‌ای که در پروژه قبل همکاری می‌کرد، در این پروژه به عنوان یکی از نفرات کلیدی، هدایت تیم طرحی‌بازی را بر عهده دارد. در مورد ارتباط یک عضو تیم و ساختار تیم در آینده مطلبی می‌نویسم.با در دست داشتن نقشه راه، تیم را می‌توانیم هر سال مورد ارزیابی قرار دهیم و بسنجیم که آیا در مسیر درستی قرار داریم یا خیر.نکات مهمدو نکته مهم در مورد نقشه راه و چشم‌انداز وجود دارد.تغییر نقشه راهبا کشف حقایق جدید در مورد تیم و بستری که در آن قرار دارد، ممکن است نقشه راه تغییر کند. نقشه‌های متعددی ما را به سمت چشم‌اندازمان هدایت می‌کنند. علاوه بر آن گاهی ممکن است چشم‌انداز ما تغییر کند.چشم‌انداز مناسبچشم‌انداز مناسب آن دورنمایی است که نقشه راه مناسب ما به آن‌سو می‌رود. نقشه راه مناسب ما آن اهدافی است که حرکت‌های مناسب اعضای کلیدی ما به آن‌سو می‌رود. حرکت‌های مناسب اعضای کلیدی ما آن چیزی است به آن علاقه دارند، به خوبی انجام می‌دهند، موجب رشد آن‌ها می‌شود و دستاورد آن برای مخاطبان مناسب است. به این صورت چشم‌انداز ما از درون ما آغاز می‌شود و شناخت کامل آن مستلزم شناخت کامل خودمان و تیم‌مان است.نتیجه‌گیریموفقیت تیم‌های خلاق بسیار دشوار است و اینگونه تیم‌ها با مسائل متعددی برای حل کردن مواجه هستند و کارشان نیازمند تصمیم‌گیری‌های متعدد است. تصمیم‌گیری‌هایی که هر بار تازه‌اند و نمونه‌های پیشین ندارند. موفقیت این تیم‌ها نیز ارتباط ساده‌ و مشخصی با خروجی آن‌ها و استقبال از محصولاتشان ندارد. در چنین شرایطی، وجود معیارهایی برای سنجش وضعیت تیم بسیار مهم است. یکی از این معیارها نقشه راه تیم است که مسیری از امروز تا چندین سال آینده را در راستای چشم‌انداز تیم مشخص می‌کند. تیم می‌تواند در هر لحظه از زمان، با رجوع به نقشه راه، وضعیت خودش را ارزیابی کند و در صورت نیاز، تصمیم‌های راهبردی جدیدی بگیرد.برای شناخت مسیر صحیح و ترسیم آینده، لازم است ابتدا به دلیل وجودی تیم بیاندیشیم، دقیقا مانند ترتیب پرسش‌ها در این بیت؛که بنظر من اگر می‌خواهم بفهمم که «به کجا می‌روم؟» باید قبلش بفهمم که «از کجا آمده‌ام؟» و «آمدنم بهر چه بود؟»«از کجا آمده‌ام آمدنم بهر چه بود؟ به کجا می‌روم آخر ننمایی وطنم»با تشکر از متین ایزدی برای یاری‌رسانی در تکمیل این مطلب. امیرحسین فصیحی امیرحسین فصیحی Wed, 24 May 2023 04:05:31 +0330 https://virgool.io/@fassihi/%D8%A7%D9%86%D8%AF%D8%B1-%D9%85%D8%B4%D9%82%D8%A7%D8%AA-%D8%A7%DB%8C%D9%85%DB%8C%D9%84-%DA%AF%D9%88%DA%AF%D9%84-%D9%BE%D9%84%DB%8C-lly197mn8fpc اخیرا اتفاق جالبی رخ داد که تصمیم گرفتم چند سطری در مورد اون بنویسم. از طریق یکی از دوستان متوجه شدیم که یکی از فروشگاه‌های اپ‌های اندروید، بازی شمشیر تاریکی رو بدون اجازه ما منتشر کرده و در توضیحات هم نام ناشر آمریکایی بازی رو نوشته. معمولا ارايه نسخه‌های بازی رو در سایت‌های کرک و دانلود غیر مجاز زیاد دیده بودیم ولی این اتفاق از طرف این پلتفرم که یکی از فروشگاه‌های رسمیه خیلی عجیب بود. جالبه که این بازی رو چند سالی در این فروشگاه عرضه می‌کردیم و به تازگی انتشار اون رو متوقف کرده بودیم.پس از پیگیری‌های متعدد و تماس و نامه نگاری بیشمار، در نهایت پاسخی از طرف پشتیبانی آن‌ها دریافت کردیم که اصلا کی گفته آقا جان این بازی مال شماست. این بازی طرفدار زیاد داره و برای اینکه اونا ناراحت نشن ما بازی رو منتشر کردیم. حالا ما بالا برو پایین بیا که والا این بازی ماست و در نهایت با کمال اقتدار شنیدیم که هر موقع اون ایمیلی که تو صفحه گوگل پلی بازی نوشته شده به ما ایمیل بزنه ما حذف می‌کنیم وگرنه شما کی هستید! خدمت شما بگم که اون ایمیل هم چیزی نیست جز ناشر آمریکایی بازی که حق نشر در گوگل پلی رو به او سپرده‌ایم. با توجه به این‌که این فروشگاه (و فروشگاه‌های دیگه) تصور می‌کنن که به راحتی می‌تونن بازی‌های گوگل پلی رو بر دارن و روی فروشگاه خودشون منتشر کنن، لازم دیدم این چند سطر رو بنویسم. سوال دقیقا اینه:انتشار مجدد و بدون مجوز بازی‌های گوگل پلی چه مشکلاتی دارد؟۱ - نشر مجدد بازی‌های گوگل پلی در هر پلتفرم دیگری غیر قانونی است. (مشکل قانونی)اساسا شما هیچ‌گاه اجازه قرار دادن هر محصولی که حقوق معنوی اون متعلق به کس دیگری باشه رو ندارید، چه رایگان و چه پولی. چه عکس یک شخص و چه محصول یک تیم. اگر قرار دادن فایل روی اینترنت آسونه به معنی مجاز بودن اون نیست. حالا حتما این فروشگاه می‌گه که کی تو ایران حقوق معنوی رعایت می‌کنه که ما بکنیم، اصلا مگه فیلیمو و نماوا و غیره و غیره تا حالا حقوق کسی رو رعایت کردن که ما دومی باشیم. البته همه این دوستان می‌دونن که حقوق معنوی سازندگان ایرانی رو باید رعایت کنن ولی فعلا فرضشون اینه که بازی ایرانی که در خارج از ایران منتشر شده هم که اصلا ایرانی نیست. کی گفته هست؟ مگه ایمیل رو نمی‌بینی تو گوگل پلی خارجیه! جالبه که اگه اون ایمیل گوگل پلی یه روزی به این مارکت‌ها ایمیل بزنه حتما از راهکارهای حقوقی که برای شکایت دنبالش خواهد رفت می‌گه. قانون رو اگه کاری نداری بریم سراغ مورد بعدی.۲ - اصلا حقوق معنوی بازی مال کیه؟ (مشکل معنوی)دوستان تصور می‌کنن که چون گوگل پلی نوشته فلان شرکت پس حتما فلان شرکت صاحب کل اثره. حقیقت اینه که سازندگان با ناشران متعدد برای منتشر کردن بازی صحبت می‌کنن. خیلی وقتا حقوق نشر روی پلتفرم‌های مختلف رو به ناشران مختلف می‌دن. از قضا قصه بازی شمشیر تاریکی ما هم همینه. حقوق نشر روی گوگل پلی و اپ استور رو به ناشر آمریکایی دادیم و حق نشر روی بقیه پلتفرم‌ها برای خودمون محفوظه. به همین دلیل هم به صورت مستقل روی استورهای داخلی تا همین اواخر منتشر کرده بودیم. حالا این دوستان صحبتشون اینه که نخیر، دیگه چون یکی تو گوگل پلی منتشر کرده پس حتما حق نشر تمام دنیا رو داره! استورجان این رو هم نمی‌پذیری؟ بسیار خب، بریم مورد بعدی.۳ - ناشر اصلی به سازنده چی می‌گه وقتی می‌بینه روی استور جدید منتشر شده؟ (مشکل اخلاقی)خیلی وقتا ولی اتفاقا بازی ساز حق نشر رو به ناشر برای تمام دنیا می‌ده. آخ آخ تو این حالت که دیگه خیلی بد می‌شه. ناشر از خواب پا می‌شه می‌بینه بازی روی یک پلتفرمی که اصلا روحشم خبر نداره منتشر شده. تلفن رو بر می‌داره زنگ می‌زنه به بازی ساز، می‌گه فلان فلان شده حالا دیگه زیرآبی می‌ری برای من؟ همین الان برم شکایت کنم ازت که پدرتو در بیارن؟ بازی‌ساز بیچاره هم از همه جا بی‌خبر می‌گه کی؟ چی؟ کجا؟ بعد ناشر لینک رو براش می‌فرسته. گوگل کروم هم اول بهشون پیشنهاد می‌کنه که محتوای فارسی رو به زبانشون ترجمه کنه و اونا هم دکمه رو با ترس و لرز می‌زنن و می‌بینن که بعله! بازیشون خیلی قشنگ داره منتشر می‌شه روی یک فروشگاه جدید. بازی‌ساز می‌گه آقا به خدا (یا اون چیزایی که قبول داره، حداقل تو مواقع ترس) ما اصلا نمی‌دونیم قضیه چیه! ناشر هم می‌گه آره جون خودت، حالا بهت نشون می‌دم. یه ایمیلی هم شاید این وسط بازی‌ساز به این استور ایرانی بزنه و اونا هم چند تای اول رو جواب نمی‌دن و بعد می‌گن تو کی هستی اصلا بابا جون! وات د هل! خب اینم یه ایراد اخلاقی، ولی خب باز می‌شه گفت که یه فروشگاه، یه بیزنس عظیمه و نباید نگران مشکلات اخلاقی بین توسعه دهندگان و ناشران خارجی باشه. خب بریم پله بعدی.۴ - آقا اصلا نمی‌خوام دیگه بازیم باشه. (مشکل هنری)این‌که یک بازی‌ساز بخواد بازیش رو دیگه منتشر نکنه خیلی رایجه. انواع و اقسام دلایل رو هم می‌تونه داشته باشه، خیلی وقتا حقوقی، خیلی وقتا به دلایل هنری و کیفی و موارد دیگه. بازی‌ساز یک روز بازیش رو از حالت انتشار در میاره ولی می‌بینه که عه، چرا هنوز رو یه استورهایی هست؟ هر کاری می‌کنه، بازیش تا ابد اونجا می‌مونه و رویایی حذف بازیش از استورها رو به گور می‌بره، متاسفانه. آخه شاید دیگه ایمیل گوگل پلی ناشرش هم کار نکنه و یه استورهایی هیچ جوره جوابش رو ندن. بازی ساز جان دست به مهره بازیه، وقتی ساختی دیگه مال خودت نیست و رو یه فروشگاههایی حالا حالا خواهد بود!۵ - مشکل بازی‌ساز داخلی (مشکل ایرانی)موارد بالا با فرض اینه که بازی‌ساز و ناشر خارجی هستن و می‌شه اینطور گفت که آقا ما فعلا به فکر داخل مرزای خودمون باشیم و این خارجیا رو بیخیال. مشکلات قانونی، تجاری، فرهنگی و اخلاقی هم که براشون با این کارامون بوجود میاد اصلا کاری نداریم. ما فقط به فکر جونای مملکت خودمون هستیم. اصلا ما هستیم چون اونا نخواستن ما باشیم پس ما هستیم! قصه بازی‌ساز داخلی اینه که در داخل به بازیش گیر می‌دن و می‌گن بازی ستاره‌دار ساختی و باید بری دادگاه، بعد هم چندین بهانه عجیب و غریب میارن و مجوز نشر دیگه بهش نمی‌دن. بازی‌سازم می‌گه آقا اصلا نخواستم و بازی رو منتشر نمی‌کنم چون خیلی وقت و حوصله این گیرا رو هم ندارم. بعد از یه مدتی میاد و می‌بینه که به به، بازی چه قشنگ داره در فروشگاه‌های وطنی منتشر می‌شه. می‌گه آقا بیار پایین الان دردسر درست می‌کنی و فروشگاه‌ هم می‌گه قبلا این بازی مال تو بود، الان دیگه فرض می‌کنیم این بازی مال خارجیاست و ما می‌ذاریم چون مخاطب ما دوست داره. تو هم برو واسه خودت. بازی‌ساز ایرانی می‌گه ببین این دفعه برم دادگاه تو میای اونجا جواب بدی و بگی که سرخود بازی رو منتشر کردی؟ اصلا مگه قاضی قبول می‌کنه همچین چیزیو، مطمینم اولین چیزی که می‌گه اینه که شما در مورد ناموست هم همینجوری رفتار می‌کنی؟ می‌ذاری ببرنش بعد می‌گی من کاره‌ای نبودم اونا بردن؟ فروشگاه کمی به فکر فرو می‌ره و یه چیزایی از کنار وجدانش رد می‌شه ولی سریع همه رو کنار می‌زنه و می‌گه هر موقع از ایمیل گوگل پلی به من ایمیل زدی، من جوابتون می‌دم! ملاک من فقط و فقط گوگل پلیه! اصلا هر چی بیل گیتس بگه! بازی سازه نگاهی می‌کنه ولی می‌گه الان بیل گیتس رو بگم بحث به بیراهه می‌ره، به جاش می‌گه مگه اون موقع که بازی رو از رو گوگل پلی برداشتی گذاشتی بالا با ایمیل گوگل پلی مکاتبه کردی؟ کردی یا نکردی؟ اصلا روح اون ایمیل‌های گوگل پلی خبر داره که بازیاشون رو بر می‌داری می‌ذاری رو فروشگات؟ اما جوابی نمیاد. نمیاد که نمیاد. بازی ساز در حالی که متحیره که چطور در احضار به دادگاه همه اون رو می‌شناسن و همه چیزشو می‌دونن ولی موقعی که بازیش رو دزدی می‌ذارن تو فروشگاه هیچ کس اونو نمی شناسه، در تاریکی شب قدم می‌زنه و با خودش می‌گه‌، این نیز بگذرد...یه روزی همه اینا می‌گذره و همه با هم به این روزا می‌خندیم، همونطوری که امروز به خیلی از اتفاقای گذشته می‌خندیم. حالا خیلی دیر شد هم ما نمی‌خندیم ولی بقیه می‌خندن، ما هم با خنده اونا از الان می‌تونیم شاد باشیم. امیرحسین فصیحی امیرحسین فصیحی Wed, 15 Dec 2021 23:40:39 +0330 https://virgool.io/@fassihi/%DA%A9%D8%A7%D8%B1-%D9%86%DB%8C%D9%85%D9%87-%DA%A9%D8%A7%D8%B1%D9%87-m8e7zbrmbdmc یکی از دشواری‌های انجام کارهای نوآور و با کیفیت این است که زمانی نسبتا طولانی باید بگذرد تا مشخص شود کیفیت خروجی کار چطور است. قبل از این‌که این زمان به صورت کامل طی شود، با محصولی نیمه‌کاره طرف هستیم و تشخیص این‌که آیا این محصولی ارزشمند خواهد شد یا خیر کاری است دشوار. این مساله‌ای است که بارها در بازی‌سازی تجربه می‌شود و تیم ما هم همواره درگیر آن بوده است. اخیرا پال گراهام مقاله‌ای در این خصوص نوشته است که این موضوع را بسیار زیبا تحلیل می‌کند. از آن‌جا که تفکر در این خصوص و تلاش برای پیدا کردن راه‌حلهای گوناگون برای جامعه ما نیز بسیار مهم است، تصمیم گرفتم این مقاله را به فارسی ترجمه کنم.این متن ترجمه مقاله Paul Graham با عنوان ٍEarly Work است.لینک مقاله اصلی:http://www.paulgraham.com/early.htmlکار نیمه کاره۲۰ اکتبر ۲۰۲۰ترس از ساختن چیزی بی ارزش یکی از بزرگترین بازدارنده‌های هر کسی است زمانی که به انجام کاری بزرگ و عالی فکر می‌کند. این ترس خیلی هم غیر منطقی نیست. خیلی از پروژه‌ها در اوایل کار وارد مرحله‌ای می‌شوند که خیلی جذاب به نظر نمی‌رسند، حتی برای خود سازنده‌ها. برای رسیدن به کار خوبی که پس از آن قرار دارد،‌ لازم است که از این مرحله عبور کنید. اما خیلی‌ها موفق نمی‌شوند. خیلی از مردم حتی به مرحله‌ای که چیزی بسازند که از آن شرمنده باشند هم نمی‌رسند، چه برسد به عبور از آن. ترس زیاد به آن‌ها اجازه شروع کار را نمی‌دهد. تصور کنید اگر می‌توانستیم ترس از ساختن کاری بی ارزش را در خود از بین ببریم. تصور کنید چه کارهای بیشتری می‌کردیم.آیا امیدی وجود دارد که بتوانیم این ترس را خاموش کنیم؟ فکر می‌کنم می‌شود. تصور من این است که عادت‌هایی که باعث ترس ما می‌شوند، خیلی ریشه عمیقی ندارند.ساختن محصولات جدید خود برای گونه انسان کاری است نو. همیشه وجود داشته است ولی تا همین قرن‌های اخیر آنقدر سرعت آن پایین بوده است که تقریبا حس نمی‌شده است. ما انسان‌ها قواعدی را برای برخورد با ایده‌های جدید نیاز نداشتیم و چیزی هم ایجاد نکردیم.ما تجربه کافی در برخورد با نسخه‌های اولیه پروژه‌های بلند‌پروازانه نداریم و نمی‌دانیم چگونه باید در مقابل آنها تصمیم بگیریم. روش قضاوت ما در مورد آنها همانگونه است که در مورد پروژه‌های نهایی شده و یا پروژه‌هایی که کمتر بلندپروازانه اند نظر می‌دهیم. متوجه نیستیم که این‌ها حالت‌های خاص هستند.یا حداقل می‌توان گفت که اکثر ما متوجه نیستیم. یکی از دلایلی که من مطمینم راه‌حل بهتری وجود دارد این است که این اتفاق در جاهایی شروع شده است. مکان‌هایی وجود دارد که در حال حاضر از این نظر گویی در زمان آینده قرار دارند. یکی از آن‌ها دره سیلیکونی است، یک انسان ناشناس که روی یک پروژه به نظر عجیب کار می‌کند به صورت خودکار ترد نمی‌شود، شاید آن‌گونه که در کشور خودش با او رفتار می‌شود. در دره سیلیکونی مردم یاد گرفته‌اند که ترد ایده‌های نو چقدر می‌تواند خطرناک باشد.روش درست مواجهه با ایده‌های نو این است که آن‌ها را به عنوان یک چالش ذهنی برای خود در نظر بگیرید. نه این‌که فقط استاندارد پایین‌تری داشته باشید، بلکه به صورت کلی تغییر نگرش بدهید، از اشاره به تمام حالت‌هایی که ایده موفق نمی‌شود به در نظر گرفتن تمام حالت‌هایی که ممکن است موفق شود. این کاری است که من وقتی که افرادی با ایده‌های نو را می‌بینم انجام می‌دهم. در این کار نسبتا مهارت پیدا کردم ولی با تمرین بسیار. شریک بودن در Y Combinator به معنی غرق شدن در ایده‌های عجیب و غریبی است که توسط آدم‌های ناشناس مطرح می‌شوند. هر شش ماه، هزاران ایده نو به سمت شما هجوم می‌آورد و شما باید در آن‌ها جستجو کنید و بدانید که در جهانی که خروجی پروژه‌ها به صورت تصاعدی متفاوت است، اگر سوزن را در کاه پیدا نکنید،‌ به صورت دردناکی واضح خواهد بود. خوش‌بینی ضروری می‌شود. امید من این است که با گذشت زمان، اینگونه خوش‌بینی به اندازه‌ای همگانی شود که تبدیل به یک سنت عمومی شود، نه فقط یک توانایی برای عده‌ کمی از متخصصان. در هر صورت این توانایی بسیار سودمند است و معمولا اینگونه توانایی‌ها به سرعت منتشر می‌شوند. طبعا کم تجربه بودن تنها دلیل سخت گیری مردم نسبت به نسخه‌های اولیه پروژه‌های بلند‌پروازانه نیست. این کار را برای باهوش جلوه دادن هم انجام می‌دهند. در رشته‌ای که ایده‌های نو ریسک بالایی دارند، مانند استارتاپ‌ها، آن‌هایی که ایده را رد می‌کنند به احتمال زیادی درست خواهند بود. هر چند نه وقتی که پیش‌بینی آن‌ها بر اساس خروجی وزن بگیرد. اما یک دلیل شیطانی دیگر هم برای رد ایده‌های جدید وجود دارد. اگر شما بخواهید کاری بلند‌پروازانه انجام دهید، خیلی از دوروبری‌‌های شما، چه آگاهانه و چه ناخودآگاه، آرزو می‌کنند شکست بخورید. آن‌ها نگرانند که اگر شما موفق شوید، بالاتر از آنان قرار ‌بگیرید. در برخی کشورها این فقط یک شکست شخصی نیست، بلکه بخشی از فرهنگ ملی است. ادعای من این نیست که آدم‌ها در دره سیلیکونی برتری اخلاقی دارند که باعث می‌شود بر این تکانه‌ها غلبه ‌کنند. دلیل اینکه خیلی‌ها امیدوارند شما موفق شوید این است که امیدوارند با شما رشد کنند. برای سرمایه‌گذاران این انگیزه مشخص است. امیدوارند شما موفق شوید و در نتیجه آن، آن‌ها هم ثروتمند شوند. ولی بسیاری دیگر هستند که امیدوارند از موفقیت شما به نحوی سود ببرند. حداقل این است که وقتی شما معروف شوید، آن‌ها می‌گویند که شما را خیلی وقت است می‌شناسند. حتی اگر ریشه این نگرش دلگرم کننده در دره سیلیکونی در نفع شخصی باشد، به مرور زمان به نوعی رفتار خیرخواهانه تبدیل شده است. دلگرمی دادن به استارتاپ‌ها به قدری تمرین شده که به صورت یک رسم درآمده است. الان دیگر رفتار عادی با یک استارتاپ اینگونه است. شاید دره سیلیکونی زیادی خوشبین است. شاید به راحتی گول متقلبان را می‌خورد. این نظر اهالی رسانه‌ای کمتر خوشبین است. اما متقلبانی که به آن اشاره می‌کنند خیلی کم هستند. اگر از نظر درآمدزایی بررسی کنیم، خوش‌بینی دره سیلیکونی به نظر اوضاع بهتری نسبت به بقیه دنیا دارد. چون نتیجه می‌دهد، پخش می‌شود. البته مقوله ایده‌های نو بسیار فراتر از استارتاپ‌ها است. در بسیاری از رشته‌ها، ترس ساخت چیزی کم ارزش باعث عدم حرکت مردم می‌شود. مثال دره سیلیکونی نشان می‌دهد که رسم‌ها چقدر سریع می‌توانند تکامل پیدا کنند تا از ایده‌های نو حمایت کنند. و این موضوع همچنان نشان می‌دهد که رد ایده‌های نو در طبیعت انسان ریشه عمیقی ندارد و می‌توان آن را به عنوان یک رسم بد فراموش کرد. متاسفانه برای انجام کارهای نو، علاوه بر بدبینی بقیه، نیروی قوی‌تری هم در مقابل شما وجود دارد: بدبینی خود شما. خود شما هم بسیار سخت‌گیرانه در مورد کار نیمه‌کاره خود قضاوت خواهید کرد. چگونه می‌توانید با آن مقابله کنید؟این مساله دشواری است، زیرا شما نمی‌خواهید به کلی ترس ساختن چیزی بی ارزش را در خود از بین ببرید. آن ترس چیزی است که شما را به سمت انجام کار خوب هدایت می‌کند. شما فقط می‌خواهید که موقتا آن را خاموش کنید، همانطور که یک مسکن موقتا درد را خاموش می‌کند.مردم راههای متعددی برای این موضوع پیدا کرده‌اند. ّهاردی در کتاب «پوزش یک ریاضی‌دان» دو مورد را بیان می‌کند.«کار خوب توسط انسان‌های فروتن انجام نمی‌شود. به عنوان مثال، از اولین وظایف یک استاد دانشگاه این است که، در هر رشته‌ای، در رابطه با موضوعش و اهمیت خودش در آن، اغراق کند.»اگر شما در اهمیت کاری که انجام می‌دهید غلو کنید، بخشی از سخت‌گیری شدید شما در مورد نتیاج اولیه جبران خواهد شد. اگر به چیزی که ۲۰ درصد از یک هدفی با ارزش ۱۰۰ را طی کرده است نگاه کنید و تصور کنید که ۱۰ درصد از یک هدف با ارزش ۲۰۰ طی شده است، تخمین شما از ارزش تولید شده درست است، هرچند که هر دو مولفه غلط هستند. همانطور که هاردی می‌گوید، اندکی اعتماد به نفس اضافه می‌تواند کمک کند. در خیلی از رشته‌ها مشاهده‌ کرده‌ام که موفق‌ترین آدم‌ها اندکی اعتماد به نفس اضافه دارند. این موضوع در ظاهر غیر قابل تصور است. مسلما تخمین دقیق از توانایی‌های یک نفر کار بهینه‌ای است. اشتباه کردن در این خصوص چطور ممکن است برتری داشته باشد؟ دلیل این است که این خطا، خطاهای دیگر درجهت‌های مخالف را جبران می‌کند: اندکی اعتماد به نفس بیشتر داشتن سپری است در مقابل بدبینی دیگران و حتی خود شما.نادانی هم تاثیر مشابهی دارد. اگر شما توانایی قضاوت دقیق محصول نهایی را نداشته باشید، خیلی اشکالی ندارد که در مورد محصول نیمه‌کاره مانند محصول نهایی قضاوت کنید. بعید می‌دانم که اینگونه نادانی را بتوان ترویج داد، ولی از نظر تجربی این یک برتری واقعی است، به خصوص برای جوانان. یک راه دیگر برای عبور از مرحله زشت بودن کار بلندپروازانه این است که در کنار افراد مناسب باشید - برای ایجاد گردابی در جریان باد مخالف اجتماعی. ولی همیشه جمع کردن آدم‌های دلگرم‌کننده کافی نیست. شما یاد می‌گیرید که به آنان توجه نکنید. شما همکارانی لازم دارید که دقیقا بتوانند یک جوجه اردک زشت را از یک جوجه‌ی قو تشخیص دهند. بهترین افراد برای این کار کسانی هستند که خودشان هم روی پروژه‌های مشابهی کار می‌کنند، این یکی از دلایلی است که دپارتمان‌های دانشگاهی و آزمایشگاه‌های تحقیقات فن‌آوری خیلی خوب نتیجه می‌گیرند. لازم نیست یک سازمان داشته باشید تا همکاران خوب بگیرید. در صورتی که فرصتی باشد، به صورت طبیعی به شما می‌پیوندند. ولی حتما ارزشش را دارد که با جستجو برای افرادی که تلاش می‌کنند کارهای نو انجام دهند، به این فرآیند شتاب دهید. معلمان در عمل نوع خاصی از همکاران هستند. دیدن پتانسیل کارهای نیمه‌کاره و دلگرمی دادن برای ادامه مسیر از کارهای معلمان است. ولی متاسفانه معلمانی که در این زمینه خوب هستند بسیار نادرند، بنابراین اگر فرصت یادگیری از یکی را دارید، دم را غنیمت شمارید. شاید انضباط یک راهکار مفید برای بعضی باشد: این‌که به خود بگویید که هر طور شده باید از این مرحله زشت عبور کنید و دلسرد نشوید. ولی این کار مشابه خیلی «فقط به خودت بگو»های دیگر، در عمل بسیار سخت‌ است. با بالا رفتن سن شما، این مورد سخت‌تر هم می‌شود، زیرا استانداردهای شما بالا می‌رود. هرچند که بالا رفتن سن یک مزیت جبران کننده هم دارد: داشتن تجربه عبور از این مرحله.اگر تمرکزتان را بیشتر از جایی که هستید، به نرخ تغییرات ببرید بهتر است. وقتی بهتر شدن یک کار بد را ببینید، خیلی نگران آن نخواهید بود. مشخصا هر چقدر سریع‌تر بهبود یابد بهتر است. بنابراین خیلی خوب است اگر زمان زیادی را برای انجام کار نو بتوانید تخصیص دهید. این یکی دیگر از مزایای جوان بودن است: معمولا زمان آزاد پیوسته بیشتری دارید.یک راهکار رایج دیگر این است که در نظر بگیرید کار نو از جنسی متفاوت و غیردقیق‌تر است. مثلا در شروع یک نقاشی می‌توانید فرض کنید که فقط یک اسکچ است، یا یک نرم‌افزار جدید را فرض کنید که یک هک سریع است. در آن صورت نتایج اولیه را با استاندارد پایین‌تری قضاوت خواهید کرد. زمانی که پروژه روی غلتک افتاد، یواشکی آن را تبدیل به چیزی بزرگتر کنید.اگر از مدیومی استفاده کنید که به شما امکان انجام کار سریع می‌دهد و هزینه زیادی برای شروع ندارد،‌ کار شما ساده تر است. این‌که به خود بگویید روی یک اسکچ کار می‌کنید خیلی راحت‌تر خواهد بود اگر در یک دفتر طراحی کار کنید در مقایسه با اینکه روی سنگ حکاکی کنید. علاوه بر آن زودتر هم به نتایج می‌رسید.اگر به انجام یک پروژه با ریسک بالا به عنوان یک راه یادگیری نگاه کنید و نه به عنوان تولید محصول، کار شما ساده‌تر می‌شود. در آن صورت حتی اگر شکست بخورید، شما اندوخته‌ای دارید. اگر مساله به خوبی تعریف شده باشد، شکست هم نوعی کسب دانش است: اگر مشخص شود که قضیه‌ای که تلاش می‌کنید ثابت کنید غلط است، یا از عضو سازه‌ای استفاده کنید که زیر تنش بشکند، شما چیزی یاد گرفته‌اید، حتی اگر متفاوت با آن چیزی باشد که در ابتدا می‌خواستید یاد بگیرید.یکی از انگیزه‌هایی که برای من شخصا خیلی خوب کار می‌کند کنجکاوی است. من دوست دارم کارهای جدید انجام دهم که ببینم نتیجه چه می‌شود. شروع کار Y Combinator با همین روحیه بود و همینطور این عامل ادامه دادن من بود زمانی که روی Bel کار می‌کردم. بعد از تجربه زیاد کار کردن با انواع گویش‌های زبان Lisp، خیلی کنجکاو بودم بدانم که شکل ذاتی آن چه بوده: اگر روش بدیهی را تا انتها دنبال کنیم به چه چیزی می‌رسیم. ولی این نکته که حتما لازم است با خود بازی‌های ذهنی انجام دهیم تا با دیدن نتایج زشت کارهای نیمه‌کاره دلسرد نشویم کمی عجیب است. چیزی که تلاش می‌کنیم خود را گول بزنیم و به آن باور کنیم در واقع خود حقیقت است. نسخه اولیه زشت یک پروژه بلند‌پروازانه واقعا با ارزش‌تر است از آنچه به نظر می‌آید. شاید راه‌حل نهایی یاد دادن این موضوع به خود باشد.یک راه خوب دیگر می‌تواند مطالعه در مورد افرادی باشد که کارهای عالی انجام داده‌اند. اوایل کار دقیقا چه فکری می‌کردند؟ اولین کاری که کردند چه بود؟ گاهی یافتن جواب دقیق برای این پرسش دشوار است زیرا معمولا آدم‌ها از نمایش نسخه‌های اولیه کارشان شرم دارند و آن‌ها را منتشر نمی‌کنند. (آن‌ها هم اشتباه قضاوت می‌کنند.) اگر بتوانید تصویر دقیقی از قدم‌های اولیه یک نفر در مسیر یک پروژه عالی ببینید، خواهید دید که معمولا قدم‌هایی ضعیف هستند. شاید اگر به اندازه کافی اینگونه تجربه‌ها را مطالعه کنید، بتوانید به خود آموزش دهید که چطور قاضی بهتری برای کارهای اولیه باشید. در آن صورت در مقابل بدبینی دیگران و ترس خود از ساخت چیزی زشت ایمن خواهید شد. کار نیمه کاره را همانگونه که هست می‌بینید. جالب است که راه حل برای مشکل قضاوت سخت‌گیرانه کارهای نیمه‌کاره این است که باید متوجه شویم که خود نگرش ما هم نیمه‌کاره است. از همه چیز انتظار یک استاندارد را داشتن، یک نسخه خام اولیه است. در حال تکامل یافتن و پیدا کردن رسوم جدید هستیم و همین الان هم مشخص شده که این تغییر نگرش چه دستاوردهای بزرگی می‌تواند داشته باشد. امیرحسین فصیحی امیرحسین فصیحی Fri, 08 Jan 2021 20:00:33 +0330 https://virgool.io/@fassihi/%DA%A9%D8%A7%D9%86%D8%A7%D9%84-%D8%AA%D9%84%DA%AF%D8%B1%D8%A7%D9%85-%D8%B9%D9%85%D9%88%D9%85%DB%8C-%D8%AF%D9%88%D8%B1%D9%87-%DA%A9%D8%B3%D8%A8%D9%88%DA%A9%D8%A7%D8%B1-%D8%A8%D8%A7%D8%B2%DB%8C%D9%87%D8%A7%DB%8C-%D9%88%DB%8C%D8%AF%DB%8C%D9%88%DB%8C%DB%8C-mhrg2sormwig با توجه به استقبال دوستان از ایده دوره کسب‌و‌کار بازی‌های ویدیویی و با توجه به محدودیت کلاس آنلاین، تصمیم گرفتم فایل‌های صوتی کلاس و اسلاید‌ها را در یک کانال تلگرام قرار بدم:آدرس کانال تلگرام کسب‌و‌کار بازی‌های ویدیویی این است:https://t.me/businessofvideogamesدوره ۱۲ جلسه است و فایل‌ها روزهای شنبه و دوشنبه در کانال قرار می‌گیرند. امیرحسین فصیحی امیرحسین فصیحی Thu, 19 Mar 2020 23:25:10 +0330 https://virgool.io/cafegame/%D8%AF%D9%88%D8%B1%D9%87-%DA%A9%D8%B3%D8%A8%D9%88%DA%A9%D8%A7%D8%B1-%D8%A8%D8%A7%D8%B2%DB%8C%D9%87%D8%A7%DB%8C-%D9%88%DB%8C%D8%AF%DB%8C%D9%88%DB%8C%DB%8C-%D8%A2%D9%86%D9%84%D8%A7%DB%8C%D9%86-fyhvwhwmsoo1 توضیح دوره:آیا به بازی سازی به عنوان یک کسب‌و‌کار جدی نگاه می‌کنید؟ آیا در مورد تمام چالش‌هایی که در کنار ساخت یک بازی خواهید داشت کنجکاو هستید؟ هدف این دوره تحلیل و بررسی عناصری است که کسب و کار بازی‌های ویدیویی را تشکیل می‌دهند. مواردی که از برنامه ریزی برای حضور در صنعت و تولید محصول آغاز می‌شود و در نهایت با عرضه در بازار و برنامه ریزی برای ادامه حضور در صنعت منتهی می‌شود. سرفصل‌های اصلی که در این کارگاه بررسی می‌شوند عبارتند از:شناخت چالش‌های بازی‌سازی به عنوان کسب‌و‌کار پایدار در صنعتمدیریت تولیدمدیریت و رهبری در تولید بازی های ویدیویینقش تهیه کننده (Producer)فرآیند‌های تولید بازی و فازبندی ساختویژگی‌های تیم بازی‌سازمدیریت خلاقیتبازاریابیاجزای بازاریابی برای بازی‌های ویدیوییروش‌های بازاریابی بر اساس بستر (موبایل، PC و کنسول)رویدادهای بین‌المللیتبلیغاتفروش و پشتیبانیبازی به عنوان سرویسمدیریت طرفدارانموارد قانونیقراردادهامحدودیت‌های قانونیتوسعه کسب و کار در بازی‌سازیارتباط با ناشرانتعامل رسانه‌ایارتباط با بسترها (Sony, Microsoft, Steam, …)همکاری استراتژیکسرمایه‌گذاری در بازی‌سازیسرمایه‌گذاری در پروژه‌سرمایه‌گذاری در شرکت‌راهکارهای جذب سرمایهتمرکز اصلی این دوره بر وضعیت فعلی بازی‌سازی در ایران می‌باشد و بحث و گفتگو در مورد تجربیات شرکت‌کنندگان و همچنین به اشتراک گذاشتن تجربیات شرکت فن‌افزار در تولید بازی‌های گرشاسپ، شمشیر تاریکی و فرزندان مورتا از بخش‌های اصلی خواهد بود.مخاطبان دوره: این دوره برای علاقمندان به شناخت چرخه کلی بازی‌سازی مناسب است. افرادی که بخواهند در تیم خود به مواردی که فراتر از ساخت یک بازی است فکر کنند، موارد راهبردی و مواردی که معمولا پنهان می‌باشند. همچنین این دوره برای کسانی که تمایل داشته باشند استودیو بازی‌سازی خود را راه‌اندازی کنند مناسب می‌باشد.اگر دغدغه شما فراتر از تولید یک بازی و ایجاد آن چیزی است که باعث تولید بازی‌های متعدد می‌شود، این دوره برای شما مناسب است.توضیح در مورد دوره آنلاین:این دوره به صورت آنلاین برگزار می‌شود. فایل صوتی از قبل ضبط شده است و به همراه اسلاید‌ها در هر جلسه در اختیار شما قرار می‌گیرد (دو بار در هفته) و یک جلسه پرسش و پاسخ نیر در هر هفته برگزار می‌شود. کلاس در نرم‌افزار Discord برگزار خواهد شد. طول دوره: ۱۸ ساعت، ۱۲ جلسهزمان برگزاری: فایل صوتی و اسلایدها روزهای شنبه و سه‌شنبه در اختیار شما قرار می‌گیرد. پنج‌شنبه جلسه پرسش و پاسخ به صورت آنلاین برگزار می‌شود. زمان این جلسه متعاقبا اعلام می‌گردد.تاریخ آغاز دوره: ۲ فروردین ۱۳۹۹ الی ۱۱ اردیبهشتمکان برگزاری: آنلاین در Discordهزینه دوره: رایگان (گزینش از بین متقاضیان شرکت در دوره صورت می‌گیرد)فرم پیش‌ثبت‌نام:https://forms.gle/mwm7dyXudyAeJcU97 امیرحسین فصیحی امیرحسین فصیحی Mon, 16 Mar 2020 00:17:27 +0330 https://virgool.io/@fassihi/%D8%AE%D8%B7%D8%A7%D9%86%D8%A7%D9%85%D9%87-%DB%B8-%D8%B1%D9%88%D8%B4-%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7-%D8%AF%D8%B1-%D8%AA%DB%8C%D9%85-p1oewdgknlbq ارتباطات (Communication) اعضای یک تیم، تار و پود وجودی آن تیم است و کیفیت این ارتباطات به صورت مستقیم روی کیفیت خروجی تیم موثر است. عوامل بسیاری در کیفیت ارتباطات می‌توانند تاثیرگذار باشند، به عنوان مثال، بسامد (فرکانس) ارتباط، خطوط ارتباطی بین اعضا (چه کسی با چه کسی ارتباط برقرار می‌کند)، روش ارتباط از نظر مدیومی که استفاده می‌شود (حضوری، ایمیل، چت، ...)، نسبت سیگنال به نویز در ارتباط و بسیاری موارد دیگر از جمله مواردی هستند که بر کیفیت تاثیر می‌گذارند. این متن در مورد یک مشکل خاص است که در واقع به‌صورت غیر مستقیم از نوع خاصی از ارتباط در تیم بوجود می‌آید. مشکلی که ارتباط حضوری بدون ساختار مسبب آن است. در حالی‌که در محل شرکت مشغول کار خود هستید، به مشکلی بر می‌خورید و نیازمند به صحبت با هم تیمی خود برای رفع آن می‌شوید. از مزیت‌های حضور هم‌زمان اعضای تیم در یک مکان این است که شما می‌توانید به صورت حضوری با هم تیمی خود صحبت کنید و این روش از خیلی از جنبه‌ها، بهینه‌تر از روش‌های ارتباطی دیگر است. اما مشکل اصلی اینجاست که احتمال زیادی دارد که هم‌تیمی شما در وسط یک تفکر عمیق برای حل مساله‌ای باشد و صحبت با او باعث می‌شود تا از اعماق تفکر خودش خارج شود و به سخن شما توجه کند. حتی اگر این گفتگو کوتاه باشد و شما سریع پاسخ خود را دریافت کنید، او برای بازگشت به وضعیت قبلی تفکرش و رسیدن به عمق اندیشه‌اش نیازمند گذراندن زمان زیادی خواهد بود و گاهی نیز هرگز به همان نقطه قبلی تفکر ممکن است نرسد. در یک حالت بد حتی احتمال دارد زمانی که مجددا به همان نقطه فکری رسید، شخص دیگری به او سر بزند و او را درگیر مکالمه‌ای کند که مجددا موجب شود از اعماق اندیشه‌اش به بیرون پرتاب شود. این مساله که مشابه مشکل Context Switch در کامپیوتر است، برای هر یک از اعضای تیم ممکن است رخ دهد ولی شاید بتوان گفت که برای برنامه‌نویسان خطرناک‌تر است. ایجاد وقفه در فرآیند فکری یک برنامه‌نویس ممکن است تا ۴۵ دقیقه در کار او تاخیر ایجاد کند. این یکی از مشکلات جدی در فرآیند ساخت بازی فرزندان مورتا بود و برای حل آن تلاش‌های متعددی کردیم. یک راه‌حل استفاده از ابزار چت آنلاین به جای ارتباط حضوری بود، این موضوع برای هر نوع ارتباطی مناسب نبود. راه‌حلی دیگر تعریف برنامه زمانی خاصی بود برای ارتباط برقرار کردن و وجود ساعت‌های ممنوع. مثلا سوال کردن از برنامه‌نویسان فقط در ساعت ۲ تا ۴ بعد‌از‌ظهر مجاز باشد. به دلایلی این راه هم خیلی برای ما موفقیت آمیز نبود. پیشنهادی دیگر استفاده از هدفون برای برنامه‌نویس به عنوان نشان ورود ممنوع بود که این راهکار هم خیلی مفید واقع نشد. گاهی نیز به شدیدترین راه‌حل متوسل شدیم و آن کار از راه دور در روزهای خاص بود که خب این موضوع هم نکات منفی خود را داشت و لزوما راه‌حل مناسب نبود. پیچیدگی موضوع اینجاست که اینگونه ارتباطات حضوری در تیم جنبه‌های مثبت بیشماری دارد ولی همانطور که اشاره شد، ضررهایی هم می‌تواند داشته باشد، تصمیم قطعی در مورد ارزش آن خیلی کار ساده‌ای نیست. در نهایت ما روی کاغذ برای حل این مشکل راهکارهایی داشتیم ولی در عمل هیچ‌کدام به عنوان برترین گزینه انتخاب نشد و به نحوی تا آخر پروژه با این مشکل دست‌و‌پنجه نرم کردیم.شما چطور؟ آیا اینچنین مشکلی در تیم خود دارید؟ آیا به راهکاری مناسب برای مقابله با آن رسیده‌اید؟ امیرحسین فصیحی امیرحسین فصیحی Fri, 01 Nov 2019 23:09:00 +0330 https://virgool.io/@fassihi/%D8%AE%D8%B7%D8%A7%D9%86%D8%A7%D9%85%D9%87-%DB%B7-%D8%A7%D9%87%D9%85%DB%8C%D8%AA-%D8%AC%D9%84%D8%B3%D9%87%D9%87%D8%A7%DB%8C-%D9%85%D8%B1%D9%88%D8%B1-%D9%88-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87%D8%B1%DB%8C%D8%B2%DB%8C-ki1iwf9mj3sj فرآیندهای تولید چابک (Agile Methodologies) در تیم‌های بازی‌سازی نیز نهادینه شده‌اند و بیشتر سازندگان بازی، این روزها، از نوعی خاص از SCRUM پیروی می‌کنند. همه ما می‌دانیم که در این‌گونه از متدولوژی‌ها، کارهای لازم برای یک دوره یا اسپرینت (Sprint)، تعریف می‌شوند. در انتهای این دوره، لازم است که کارهای انجام شده بررسی شوند و سپس برنامه‌ریزی برای دوره بعدی انجام شود.این فعالیت بسیار ساده، یعنی بررسی کارهای یک دوره و برنامه‌ریزی دوره بعدی، به راحتی ممکن است با کیفیت لازم انجام نشود و مشکلات زیادی را در روند اجرای پروژه بوجود آورد. در تجربه ساخت بازی فرزندان مورتا نیز ما بارها دچار این خطا شدیم. دو بخش این فعالیت، بررسی کارهای انجام شده و برنامه‌ریزی برای دوره بعد، ممکن است در یک جلسه انجام شود ولی روش بهتر آن است که در دو جلسه مجزا انجام شوند. نکته مهم این است که در تیم‌هایی که ساختار سلسله مراتبی ندارند، حضور تمام اعضای تیم در این جلسه‌ها لازم است.جلسه مرور دوره قبلدر این جلسه تمام کارهای انجام شده باید بررسی شوند و دلایل ناقص ماندن کارها به‌صورت دقیق بررسی شود به نحوی که در آینده بتوان برنامه‌ریزی بهتری داشت. در کل، کیفیت بالای این جلسه باعث می‌شود که برنامه‌ریزی ما در هر دوره دقیق‌تر شود. برخی از چالش‌هایی که در این جلسه مرور ممکن است پیش بیایند (که ما هم بسیار تجربه کردیم) به قرار زیر است:۱ - نبودن تمام اعضای تیم در جلسهطبیعتا عدم حضور شخص مسوول یک کار (Task)، باعث می‌شود که هم از آخرین وضعیت آن کار مطلع نشویم و هم از دلیل کامل نشدن آن. این کار در وضعیت نامشخصی روی تخته (Board) نرم‌افزاری و یا فیزیکی باقی خواهد ماند و مشخص نخواهد بود که چه زمانی باید بررسی شود.۲ - انجام شدن کار ولی نیاز به تست و بررسی بیشترکل فرآیند بازی‌سازی چرخشی و تکراری (iterative) است و خیلی سخت است که بگوییم یک کار کاملا تمام شده است. به عنوان مثال ممکن است رفتار حرکت کاراکتر دشمن و تمام انیمیشن‌های آن پیاده‌سازی شده باشد ولی نیاز به تست و بررسی بیشتر باشد تا کارهای بیشتر روی آن مشخص شود. در این‌گونه موارد خیلی راحت نمی‌توان یک کار (Task) را انجام شده دانست. در واقع شاید بتوان مشکل این اتفاق را از عدم انجام جلسه برنامه‌ریزی با کیفیت دانست که در ادامه در مورد آن صحبت می‌کنیم.۳ - عدم امکان تشخیص تمام شدن کارگاهی غیر ممکن است که بتوانیم بگوییم کاری تمام شده است. دلیلی اصلی این موضوع ممکن است این باشد که کار خیلی کلی تعریف شده باشد. به عنوان مثال: اقلام هنری لازم برای مرحله سوم. در این‌صورت این فعالیت ممکن است در طی ۵ دوره انجام شود و این کار در تخته برنامه‌ریزی ما لازم باشد که برای چند دوره بماند که اصلا کار مناسبی نیست و پشنهاد صریح SCRUM این است که واحد کار برای یک دوره حتما به نحوی باشد که در آن دوره بتواند تمام شود و قابل اندازه‌گیری دقیق باشد. در صورتی‌که زمان لازم و انرژی کافی را برای جلسه مرور دوره قبل نگذاریم، مشکلاتی مانند موارد بالا برطرف نمی‌شوند و ادامه برنامه‌ریزی را برای ما دشوار می‌کنند. هدف این بوده است که هر جلسه ما را در برنامه‌ریزی قوی ‌تر کند و اطلاعات بهتری از تیم خود داشته باشیم در صورتی‌که بد انجام دادن این جلسه باعث ضعیف شدن برنامه‌ریزی و همچنین کم توجهی و بی اعتمادی اعضای تیم به کل فرآیند و متدولوژی می‌شود.با توجه به تجربه‌ای که داشتیم، حتی تخصیص نیمی از روز به این فعالیت می‌تواند بسیار ارزشمند باشد. معمولا تصور می‌کنیم که زودتر باید این جلسات تمام شوند تا به اصل کار (انجام دادن کارها) بپردازیم، غافل از این‌که چقدر این مرور دقیق کارها می‌تواند به ما کمک کند که بهینه‌تر کار کنیم.جلسه برنامه‌ریزی برای دوره بعدبلافاصله پس از بررسی دوره قبل، لازم است که برای دوره بعدی برنامه‌ریزی کنیم. دوره‌هایی که ما انتخاب می‌کردیم عموما دو هفته‌ای و یا یک هفته‌ای بودند. عدم تخصیص زمان و انرژی لازم به این جلسه نیز مشکلات بسیاری را بوجود می‌آورد. برخی از چالش‌های این جلسه نیز به قرار زیر است:۱ - عدم مشورت با اعضای تیم برای تخصیص کارحتما لازم است که با تک تک اعضای تیم که درگیر یک کار خواهند شد صحبت کنیم تا مطمین شویم این کار هم از نظر فنی و هم از نظر زمانی شدنی است. اگر اعضای تیم در این جلسه حضور نداشته باشند و یا به دلیل زمان‌بر شدن، این کار را نکنیم، برنامه‌ریزی دقیقی برای دوره نخواهیم داشت. تخصیص عدد انرژی کار برای هر شخص هم کمک می‌کند که به یک عضو تیم بیش از اندازه کار ندهیم و هم دید خوبی از وضعیت انجام کارها (مثلا با Burn-down Chart) به ما می‌دهد. مشاهده این عددها برای برنامه‌ریزی آینده هم بسیار لازم است. ۲ - عدم بررسی دقیق پیش‌نیازهای کاریکارها به هم وابسته‌اند و در بسیاری از مواقع ما امکان انجام کار خود را نداریم به این دلیل که پیش‌نیاز آن باید توسط شخص دیگری در تیم انجام شود. بررسی دقیق این موضوع ممکن است زمان‌گیر باشد ولی حتما در این جلسه بسیار مهم باید انجام شود.۳ - فراموش کردن اولویت‌هامهم‌ترین موضوعی که پس از تعریف یک کار باید بدانیم آن است که اولویت آن در پروژه در کجا قرار می‌گیرد؟ با توجه به هزاران نیازی که در پروژه وجود دارد و کارهایی که همه اعضای تیم درگیر آن هستند، شناخت اولویت کارهای جدید نیازمند توجه و تمرکز ویژه‌ای است. در بسیاری از مواقع برای برنامه‌ریزی سریع، از میان لیستی از کارهای لازم که شاید همان Backlog پروژه باشد، مقداری کار را برای دوره بعدی انتخاب می‌کنیم در صورتی‌که توجه نکردن به اولویت‌ها به راحتی باعث هدر رفتن وقت و انرژی تیم و عقب افتادن پروژه می‌شود. مفید کار کردن تیم بدون در نظر گرفتن اولویت‌ها بی‌‌فایده‌ است.انواع چالشی که برای برنامه‌ریزی وجود دارد که در بالا به چند نمونه از آن اشاره شد باعث می‌شود که جلسه برنامه‌ریزی نیازمند صرف وقت و انرژی جدی باشد. متقاعد کردن همه اعضای تیم برای فعالیت موثر در این جلسه کار ساده‌ای نیست ولی بسیار حیاتی است.شاید بتوان این دو جلسه را نوعی سرمایه‌گذاری در پروژه دانست. نخست به نظر می‌رسد که این جلسات زمان‌گیر هستند و وقت تیم را تلف می‌کنند ولی این هزینه‌ای است که باعث می‌شود در روزهای دیگر، همه تیم راحت‌تر کارهایشان را انجام دهند و هماهنگ‌تر باشند. در انتهای دوره‌ نیز تیم احساس مفید بودن خواهد کرد و به جای از دست دادن باورشان به متدولوژی و برنامه‌ریزی‌ها، خود نقش فعال‌تری در اجرای فرآیند خواهند داشت و برنامه‌ریزی هم تبدیل به مهمترین ابزار تیم خواهد شد.استواری این جلسات نیز با اهمیت است. ممکن است گاهی ضعیف برگزار شوند و یا انجام نشوند، ولی همواره باید بازگشت و مجددا این جلسات را قوی برگزار کرد. امیرحسین فصیحی امیرحسین فصیحی Sat, 19 Oct 2019 22:11:13 +0330 https://virgool.io/@fassihi/%D9%88%DB%8C%D8%AF%DB%8C%D9%88%DB%8C-%DA%A9%D8%A7%D8%B1%DA%AF%D8%A7%D9%87-%D8%B3%D9%81%D8%B1-%D8%A8%D8%A7%D8%B2%DB%8C%D8%B3%D8%A7%D8%B2-%D9%82%D8%B3%D9%85%D8%AA-%D9%BE%D8%A7%DB%8C%D8%A7%D9%86%DB%8C-zt9cy2p4lbhw کارگاه سفر بازی‌ساز نگاهی اسطوره‌شناختی و روان‌شناسانه به فرآیند بازی‌سازی دارد. هدف این دوره این است که راهبردهایی را از کهن‌الگوهای روان قهرمانان قصه‌ها بیابد، به نحوی که برای بازی‌سازان مفید باشد و به شناخت بهتر آنان از خودشان و تیم آن‌ها کمک کند.ویدیوی قسمت دوم کارگاه سفر بازی‌ساز:https://youtu.be/DfBnyUq_X04تاریخ برگزار شده: شهریور ۱۳۹۸لینک اسلایدهای کارگاه:https://www.slideshare.net/amirhfassihi/ss-171934421توضیح کارگاه: http://vrgl.ir/ggzwz امیرحسین فصیحی امیرحسین فصیحی Thu, 10 Oct 2019 19:13:01 +0330 https://virgool.io/@fassihi/%D8%AE%D8%B7%D8%A7%D9%86%D8%A7%D9%85%D9%87-%DB%B6-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%BE%DB%8C%DA%A9%D8%B1%D8%A8%D9%86%D8%AF%DB%8C-lyyxehpvm5o7 یکی از فعالیت‌های مهم در مهندسی نرم‌افزار، مدیریت پیکربندی (Configuration Management) است. تجربه شخصی من پیش از ورود به فعالیت‌های بازی‌سازی این بود که این فعالیت معمولا در شرکت‌های نرم‌افزاری کمتر مورد توجه قرار می‌گیرد. مدیریت پیکربندی برای پروژه‌های بازی‌سازی نیز بسیار مهم است و عدم برنامه‌ریزی و اجرای مناسب آن در پروژه ما نیز مشکلات متعددی را به‌وجود آورد.تعریف ویکی‌پدیا از مدیریت پیکربندی اینگونه است:مدیریت پیکربندی عبارت است از هماهنگ‌سازی توسعه نرم‌افزار برای کاهش سردرگمی. مشخص نمودن، سازمان‌دهی و کنترل اصلاحات نرم‌افزاری که توسط تیم برنامه‌ساز با هدف بیشینه‌سازی قابلیت تولید ضمن کمینه‌سازی اشتباهات انجام می‌پذیرد پیکربندی نرم‌افزار نامیده می‌شود. به این ترتیب یکپارچگی محصول طی دورهای مختلف چرخهٔ عمر نرم‌افزار حفظ می‌شود.همانطور که از تعریف مشخص می‌شود، کارهای مختلفی زیر چتر مدیریت پیکربندی قرار می‌گیرند. مهمترین این موارد که در تجربه ساخت فرزندان مورتا برای ما مهم شدند، و چالش برانگیز بودند، به قرار زیر است:۱ - مدیریت شاخه‌های منابع کد (Source Code Branches)در فرآیند تولید پروژه، برای مدیریت نسخه‌های منابع برنامه، از نرم‌افزار Git استفاده می‌کنیم. این نرم‌افزار به شما اجازه می‌دهد که برای کار کردن روی امکانات خاص و یا ساخت نمونه‌های آزمایشی از برنامه، برای خود شاخه‌ای جدا (Branch) درست کنید تا کارهای نیمه تمام شما مشکلی در نسخه اصلی برنامه ایجاد نکند. تا این جای کار همه چیز بسیار مرتب است و اعضای مختلف تیم هر کدام می‌توانند در شاخه‌های خود به سعی و خطا و آزمایش بپردازند. مشکل از جایی آغاز می‌شود که شما تصمیم می‌گیرید نتایج این کارهای موازی را با هم ادغام (Merge) کنید. بسیاری از فایل‌های Unity به راحتی و به ‌صورت خودکار ادغام نمی‌شوند و این موضوع ممکن است باعث از بین رفتن بخشی از کارهای شما شود.معمولا در زمان‌هایی که نسخه‌های دمو از بازی لازم باشد، مثلا برای ارایه در نمایشگاه‌ها، یک شاخه در نرم‌افزار Git برای آن در نظر گرفته می‌شود. شاخه‌ای دیگر مربوط به نسخه‌ای خواهد بود که آخرین تغییرات تولید در آن قرار دارد و انواع شاخه دیگر مرتبط با کارهای جدید طراحان بازی و یا برنامه نویسان. پیدا کردن یک مشکل (Bug) در شاخه نسخه دمو، و برطرف کردن آن، نیازمند آن است که مشکل در سایر شاخه‌ها نیز برطرف شود و این موضوع همواره به راحتی صورت نمی‌گیرد، معمولا به دلیل وجود تضاد‌هایی (Conflict) که به راحتی قابل اصلاح نیستند.۲ - مدیریت نسخه‌های قابل بازی (Builds)وجود نسخه قابل بازی به‌صورت پیوسته یکی از اهداف مهم پروژه‌های بازی‌سازی است. فرزندان مورتا نیز از اوایل پروژه همواره یک نسخه قابل بازی داشت. با افزایش پلتفرم‌های هدف، مدیریت این نسخه‌ها نیز چالش‌ برانگیز شد. در یک سوم پایانی فرآیند ساخت بازی، نسخه‌هایی برای ۵ پلتفرم لازم بود که عبارت بودند از: ویندوز، مک، PS4، Xbox و Nintendo Switch. در اواخر پروژه حتی، نسخه‌های قابل اجرای بازی برای این پلتفرم‌ها به‌صورت روزانه لازم بود و علاوه بر نسخه‌های معمولی، خروجی با امکان Cheat و بدون آن (برای تست راحت‌تر توسط تیم کنترل کیفیت) و همینطور نسخه‌هایی با امکانات Debug و بدون آن لازم بود که این موضوع باعث می‌شد تعداد نسخه قابل بازی لازم قابل توجه شود. اتوماسیون این موضوع و استفاده از Continuous Integration Systems تا حدی به فرآیند کمک می‌کند ولی مدیریت دقیق این مساله نیازمند تمرکز ویژه و برنامه‌ریزی‌های جدی بود.با توجه به این‌که تیم کنترل کیفیت خارج از ایران حضور داشت، ارسال نسخه‌های قابل بازی نیازمند آپلود آن‌ها در سرورهای اینترنتی بود و سرعت اینترنت نامناسب ایران هم کمکی به این موضوع نمی‌کرد. یکی از راه‌حل‌های این مشکل، استفاده از Build Server در خارج از ایران بود. ۳ - مدیریت نسخه‌های مختلف کتابخانه‌ها و ابزاردر بسیار از موارد، تغییر در نسخه استفاده شده یکی از نرم‌افزارهای شما مستلزم تغییر در بسیاری دیگر از کتابخانه‌ها و نرم‌افزارهای شما می‌باشد. به عنوان مثال، با تغییر نسخه یونیتی، کتابخانه‌های Fmod که برای استفاده در کنسول‌ها لازم است نیز باید عوض شوند. استفاده بیشتر از نرم‌افزارها و کتابخانه‌های جنبی، چالش این موضوع را بیشتر می‌کند. گاهی ممکن است نسخه‌های لازم یک کتابخانه هنوز آماده نشده باشد و شما مجبور می‌شوید مجددا به نسخه‌های قبلی سایر نرم‌افزارها بازگردید. ۴ - مدیریت نسخه‌های فایل‌های ترجمه شده (Localization Files)بازی فرزندان مورتا به ۹ زبان ترجمه شده است (زبان دهم، فارسی عزیز،‌ هم در راه است، لطفا سوال نفرمایید). فرآیند ترجمه نسبتا طولانی است و این موضوع مستلزم این است که چند ماه قبل از عرضه بازی، فایل‌های بازی برای ترجمه به شرکت بومی‌سازی ارسال شوند. در صورتی‌که حتی یک کلمه پس از آن تغییر کند، لازم است که آن کلمه مجددا برای ترجمه به شرکت بومی سازی ارسال شود. این موضوع بارها برای پروژه ما اتفاق افتاد و بارها فایل‌های جدیدی (که گاهی متن‌های جدید بودند و گاهی تغییر در متن‌های قبلی) برای ترجمه مجدد ارسال شدند و نتایج ترجمه نیز در زمان‌های مختلف به ما باز می‌گشت. تلاش برای منظم کردن و استفاده صحیح از تمام این متون و نسخه‌های آن‌ها، زمان و دقت زیادی می‌طلبید. راهکار چیست؟با توجه به اهمیت مدیریت پیکر‌بندی که در بالا به چند نمونه از نیازهای آن در بازی‌سازی اشاره شد، به نظر می‌رسد که حتما لازم است این نقش در تیم بازی‌سازی جدی گرفته شود و در صورتی‌که اندازه پروژه‌ کمی بزرگ شود، حتی بهتر است یک شخص به‌صورت تمام وقت به انواع موضوعات و چالش‌های پیکربندی فکر کند، برای آن برنامه‌ریزی کند و آن‌ها را اجرا کند. این نیاز از جمله نیازهای پنهان تیم‌های بازی‌سازی است و معمولا بازی‌سازان تمایلی برای انجام این‌ کارها ندارند. شخص خاصی با روحیه‌ خاصی برای این مسوولیت لازم است. مسوولیتی اما بسیار با اهمیت. امیرحسین فصیحی امیرحسین فصیحی Mon, 07 Oct 2019 23:45:29 +0330 https://virgool.io/@fassihi/%D9%88%DB%8C%D8%AF%DB%8C%D9%88%DB%8C-%DA%A9%D8%A7%D8%B1%DA%AF%D8%A7%D9%87-%D8%B3%D9%81%D8%B1-%D8%A8%D8%A7%D8%B2%DB%8C%D8%B3%D8%A7%D8%B2-%D9%82%D8%B3%D9%85%D8%AA-%D8%B3%D9%88%D9%85-ve0nmsmfzzry کارگاه سفر بازی‌ساز نگاهی اسطوره‌شناختی و روان‌شناسانه به فرآیند بازی‌سازی دارد. هدف این دوره این است که راهبردهایی را از کهن‌الگوهای روان قهرمانان قصه‌ها بیابد، به نحوی که برای بازی‌سازان مفید باشد و به شناخت بهتر آنان از خودشان و تیم آن‌ها کمک کند.ویدیوی قسمت دوم کارگاه سفر بازی‌ساز:https://youtu.be/wB8o6KuXiZcتاریخ برگزار شده: شهریور ۱۳۹۸لینک اسلایدهای کارگاه:https://www.slideshare.net/amirhfassihi/ss-171934421توضیح کارگاه: http://vrgl.ir/ggzwz امیرحسین فصیحی امیرحسین فصیحی Tue, 01 Oct 2019 14:32:35 +0330 https://virgool.io/@fassihi/%D9%88%DB%8C%D8%AF%DB%8C%D9%88%DB%8C-%DA%A9%D8%A7%D8%B1%DA%AF%D8%A7%D9%87-%D8%B3%D9%81%D8%B1-%D8%A8%D8%A7%D8%B2%DB%8C%D8%B3%D8%A7%D8%B2-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-phtv54p1eifb کارگاه سفر بازی‌ساز نگاهی اسطوره‌شناختی و روان‌شناسانه به فرآیند بازی‌سازی دارد. هدف این دوره این است که راهبردهایی را از کهن‌الگوهای روان قهرمانان قصه‌ها بیابد، به نحوی که برای بازی‌سازان مفید باشد و به شناخت بهتر آنان از خودشان و تیم آن‌ها کمک کند.ویدیوی قسمت دوم کارگاه سفر بازی‌ساز:https://youtu.be/NNcRjs-iF0sتاریخ برگزار شده: شهریور ۱۳۹۸لینک اسلایدهای کارگاه:https://www.slideshare.net/amirhfassihi/ss-171934421توضیح کارگاه: http://vrgl.ir/ggzwz امیرحسین فصیحی امیرحسین فصیحی Wed, 25 Sep 2019 22:49:40 +0330 https://virgool.io/@fassihi/%D8%AE%D8%B7%D8%A7%D9%86%D8%A7%D9%85%D9%87-%DB%B5-%D8%AB%D8%A8%D8%AA-%D8%AA%D8%A7%D8%B1%DB%8C%D8%AE%DA%86%D9%87-%D8%AA%D8%B5%D9%85%DB%8C%D9%85%D8%A7%D8%AA-%D9%BE%D8%B1%D9%88%DA%98%D9%87-p5y5tgjnvajq یکی از مهمترین بخش‌های هر پروژه‌ای، تصمیماتی است که در زمان انجام پروژه گرفته می‌شود. گاهی دامنه تاثیر این تصمیمات کوچک است و گاهی بسیار بزرگ. شاید بتوان گفت که موفقیت و یا شکست هر پروژه تا حد زیادی به کیفیت تصمیم‌گیری‌ها در طول پروژه مرتبط است. هر تصمیم راه‌حلی است برای مشکلی که ناگهان نمایان می‌شود و در فرآیند تولید بازی‌های ویدیویی، این قبیل مشکلات فراوان می‌باشند.نکته مهم این است که هر تصمیمی باید اجرا شود و گاهی اوقات زمان بین تصمیم‌گیری و اجرای آن قابل توجه می‌شود. در این حالت دو مشکل ممکن است روی دهد:۱ - فراموش کردن تصمیمبه راحتی ممکن است در آشوب یک پروژه بازی‌سازی، تصمیماتی که می‌گیریم فراموش شوند. این مشکل به صورت خاص در جلسه‌های تصمیم‌گیری نیز ایجاد می‌شود. شاید دلیل آن مطرح شدن مشکلات زیاد در یک جلسه و تصمیم‌گیری زیاد در زمان کم باشد، و البته ثبت نکردن دقیق مشکل و تصمیم‌ گرفته شده در جلسه. برخورد با یک مساله‌ای که قبلا برای آن تصمیمی گرفته بودیم ولی فراموش شده بود، بار‌ها در طی پروژه برای ما اتفاق افتاد. راه حل سازمانی و کهن برای حل این مشکل گزارش جلسه است که توسط منشی جلسه ثبت می‌شود و پس از پایان جلسه برای همه حاضرین ارسال می‌شود. بروکراسی این مدل کار کردن کمی باعث کندی تیم‌های بازی‌ساز می‌شود. بهترین راه‌حلی که ما به آن در اواخر پروژه رسیده بودیم، ثبت روی وایت برد و عکس گرفتن از آن بود. به نظر می‌رسد که هر تیمی با توجه به نفرات خود و بسامد تصمیمات، لازم است که راه‌حل مناسبی برای این مشکل بیابد.۲ - فراموش کردن دلیل تصمیمگاهی تصمیم گرفته شده را به خاطر داریم ولی دلیل آن را فراموش می‌کنیم. معمولا زنجیره‌ای از تحلیل و بررسی برای رسیدن به یک تصمیم و راه‌حل وجود دارد. عدم ثبت این دلیل‌ها باعث می‌شود که در شرایطی که مجددا با مشکلی مشابه برخورد کردیم، نتوانیم به سرعت به راه‌حل مناسب برسیم. این مورد هم از مواردی بود که بارها برای ما مشکل ساز شد. به احتمال قوی، ثبت دقیق و مناسب این فرآیند تصمیم‌گیری و تاریخچه پروژه می‌تواند کاری مفید باشد ولی با توجه به حجم بالای تصمیمات، این مورد هم نیازمند یک روال مستحکم مدیریت اسناد و به‌روزرسانی آن‌ها است که در تیم‌های کوچک‌تر کم‌تر شدنی است. این مقاله از Forbes عنوان کرده است که مشکلات اینچنینی در فرآیند تصمیم‌گیری در حدود ۲۰ درصد از کارایی مدیران می‌کاهد و حدود ۵۰ درصد از انگیزه کارکنان شرکت را کم می‌کند. مقاله، پیشنهادهایی برای حل این‌گونه مشکلات و یک قالب برای Excel هم دارد.Avoid Decision-Making Mistakes - Start A Decision Log امیرحسین فصیحی امیرحسین فصیحی Wed, 25 Sep 2019 22:29:17 +0330 https://virgool.io/@fassihi/%D9%88%DB%8C%D8%AF%DB%8C%D9%88%DB%8C-%DA%A9%D8%A7%D8%B1%DA%AF%D8%A7%D9%87-%D8%B3%D9%81%D8%B1-%D8%A8%D8%A7%D8%B2%DB%8C%D8%B3%D8%A7%D8%B2-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-sg6x1cz6bf06 کارگاه سفر بازی‌ساز نگاهی اسطوره‌شناختی و روان‌شناسانه به فرآیند بازی‌سازی دارد. هدف این دوره این است که راهبردهایی را از کهن‌الگوهای روان قهرمانان قصه‌ها بیابد، به نحوی که برای بازی‌سازان مفید باشد و به شناخت بهتر آنان از خودشان و تیم آن‌ها کمک کند.ویدیوی جلسه اول کارگاه سفر بازی‌ساز:https://youtu.be/0hJ6X_86UvQتاریخ برگزار شده: شهریور ۱۳۹۸ لینک اسلایدهای کارگاه: https://www.slideshare.net/amirhfassihi/ss-171934421توضیح کارگاه: http://vrgl.ir/ggzwz امیرحسین فصیحی امیرحسین فصیحی Fri, 20 Sep 2019 21:59:38 +0430 https://virgool.io/@fassihi/%D8%AE%D8%B7%D8%A7%D9%86%D8%A7%D9%85%D9%87-%DB%B4-%D8%B9%D8%AF%D9%85-%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%AF%D9%82%DB%8C%D9%82-%D8%AF%D9%84%DB%8C%D9%84-%D8%AA%D8%B9%D9%88%DB%8C%D9%82-%DA%A9%D8%A7%D8%B1-vxbafxwrt8ai در طول پروژه، برنامه‌ریزی می‌کنیم، کار می‌کنیم، برنامه‌ریزی می‌کنیم، کار می‌کنیم و این چرخه همواره ادامه خواهد داشت. گاهی برنامه‌ریزی کلان است و برای کل پروژه و گاهی جزیی است و برای یک Sprint تک هفته‌ای از فرآیند چابکی که دنبال می‌کنیم. حقیقت این است که معمولا هر آن‌چه را که برنامه‌ریزی می‌کنیم انجام نمی‌دهیم یا بهتر بگوییم نمی‌رسیم که انجام دهیم. در بهترین شرایط، بررسی می‌کنیم که چقدر از کار انجام نشده است و آن‌ها را برای دور بعدی برنامه‌ریزی در نظر می‌گیریم. اما، دلایل متعددی برای انجام نشدن کارها در زمان مقرر می‌تواند وجود داشته باشد که بعضی از آن‌ها می‌توانند بسیار با اهمیت باشند. ساده عبور کردن از کنار آن‌ها، می‌تواند باعث از بین رفتن اطلاعات زیادی از پروژه و تیم بشود. حقایقی که دود می‌شود و به آسمان می‌رود.در ادامه به نمونه‌هایی از این اطلاعات می‌پردازیم.کارها ممکن است در موعد مقرر انجام نشود به دلیل آن‌ که:۱ - برنامه‌ریزی از ابتدا دقیق نبوده است.چه کسی برنامه‌ریزی را انجام داده است؟ آیا مدیر تیم بوده است؟ خود شخصی که مسوول کار بوده است؟ یا شخص producer؟ در هر صورت هر که برنامه ریزی را انجام داده است، ممکن است با خطای زیادی این کار را انجام داده باشد. مثلا زمان تخمین دو روز قرار داده شده، در حالی‌که در حقیقت ۸ روز زمان لازم بوده است. در این شرایط خوب است که خیلی دقیق موضوع بین مسوول کار و مسوول برنامه‌ریزی بررسی شود تا به تدریج برنامه‌ریز‌ی‌های دقیق‌تری برای پروژه انجام شود. طبیعی است که در این شرایط اعتماد طرفین به یکدیگر جز ارکان اساسی است. ۲ - مشکلات جدیدی در حین انجام کار پدید آمده است.این موضوع در واقع به میزان ریسک موجود در پروژه مرتبط است. زمانی‌که نیازی مطرح می‌شود، این نیاز به یک شخص واگذار می‌شود تا راه‌حلی برای آن پیدا کند، این در واقع فرآیند طراحی (Design) است. پس از مشخص شدن راه‌حل، کارهایی به اعضای تیم تخصیص داده می‌شود تا آن راه‌حل اجرا شود. این مرحله در واقع فرآیند ساخت (Construction) است. هر چقدر مرحله طراحی دارای ریسک‌های بیشتری باشد، ساخت با عدم قطعیت بالاتری مواجه است. در صورت وقوع این مشکل، حتما باید با شخص طراح راه‌حل موضوع بررسی شود و دلیل ندیدن ریسک مشخص شود. کنکاش در این موضوع می‌تواند باعث بهبود فرآیند کار و پایین آمدن ریسک در پروژه در ادامه مسیر شود. این اتفاق در فاز پیش‌تولید قابل انتظار است ولی در فاز تولید بهتر است روی ندهد. شاید بتوان گفت که انجام پیش‌تولید مناسب مهمترین عامل برای جلوگیری از این مشکل است.۳ - انگیزه شخص مسوول برای کار پایین است.تحقیقات متعددی ثابت کرده است که انگیزه عامل مهمی در کارایی افراد تیم است. (به عنوان مثال این تحقیق و یا این مطلب) زمانی که انگیزه شخص برای انجام یک کار خاص بالا باشد، سرعت انجام کار او چندین برابر می‌شود. اگر این مورد دلیل اصلی تاخیر در کار باشد، صحبت دقیق با شخص مسوول لازم است و یا با توضیح در مورد وضعیت پروژه و آینده، انگیزه شخص بالا می‌رود و یا با تغییر در تخصیص کارها، او مسوول کارهایی خواهد شد که برای انجام آن‌ها انگیزه بالایی دارد. در هر صورت این موضوع نیز نیازمند تحلیل و موشکافی دقیق توسط مدیران میانی و افراد مسوول ساخت است.گاهی نیز دلیل پایین بودن انگیزه همسو نبودن شخص با چشم‌انداز (Vision) تیم است. به اشتراک گذاشتن چشم‌انداز تیم و یادآوری آن باید همواره توسط رهبران تیم صورت بگیرد.۴ - توانایی شخص مسوول برای آن کار مشخص پایین است.ممکن است مهارت شخص به آن اندازه که تصور شده بود، نباشد. شناخت این موضوع باعث می‌شود که یا در تخصیص کارها در آینده تغییری صورت گیرد و یا برای رشد و یادگیری شخص نیز زمانی را در نظر بگیریم. عدم شناخت این موضوع باعث می‌شود تا در برنامه‌ریزی‌های آینده نیز همچنان دچار مشکل باشیم.نکته جالب تناقض ضمنی این مورد با مورد قبلی (انگیزه) است. گاهی انگیزه افراد تیم برای کاری که در آن خیلی مهارت ندارند بالاتر است. در این موراد پیدا کردن نقطه تعادل بین کاری که در آن یادگیری بالایی وجود دارد و کاری که در آن شخص توانایی بالایی دارد مهم می‌شود.۵ - مشکلات تیمی و ارتباطیدر بسیاری از مواقع، مشکل درون یک شخص نیست و در ارتباط بین چند نفر ایجاد می‌شود. کارها در تیم معمولا دارای وابستگی می‌باشند و در اکثر مواقع ورودی کار ما خروجی کار شخصی دیگر است و خروجی کار ما ورودی کار هم‌تیمی ما. مشکلات ارتباطی می‌تواند باعث ایجاد خلل در انجام اینگونه کارهای تیمی شود. تحلیل دقیق اینگونه موارد باعث می‌شود که ریشه مشکل ارتباطی را بدانیم. این ریشه گاهی مشکلات شخصی است، گاهی وجود اختلاف در تیپ‌های شخصیتی و گاهی نیز عدم استفاده از ابزارهای ارتباطی مناسب. آگاه شدن به این موارد برای عدم تکرار آن‌ها بسیار حایز اهمیت است.موارد بالا صرفا بعضی از انواع دلایلی است که برای به موقع انجام نشدن کارها ممکن است وجود داشته باشد. دلایل متعدد دیگری نیز وجود دارد. در این‌جا هدف تاکید روی این موضوع است که اعضای تیم و به ‌خصوص تصمیم‌گیرندگان کلیدی باید در انتهای هر فاز برنامه‌ریزی، حتما به‌صورت دقیق و مشخص زمانی را به بررسی دلایل انجام نشدن کارها تخصیص دهند. این فرآیندی است دشوار زیرا بسیاری از حقایقی که مواجه شدن با آن‌ها ساده نیست، پدیدار می‌شوند. عدم توجه به این دلایل باعث می‌شود تا اطلاعات بسیار ازرشمندی در خصوص تیم و پروژه در کل نادیده گرفته شود و کیفیت برنامه‌ریزی روز‌به‌روز بهتر نشود.این مورد نیز از مواردی بود که در طول این پروژه باید بیشتر به آن دقت می‌کردیم. اجرای یک فرآیند تحلیل دلایل انجام نشدن کار می‌تواند بخشی از فرهنگ تیم شود و این موضوع نه فقط برای مدیر تیم، بلکه توسط همه اعضا می‌تواند پیگیری شود و همه به بهبود برنامه‌ریزی‌ها کمک کنند. برنامه‌ریزی کردن و سپس به اهداف برنامه نرسیدن نیز خود بخشی از فرهنگ منفی می‌تواند باشد. ما هم در طول پروژه در مواقع زیادی دچار این مشکل شده بودیم. امیرحسین فصیحی امیرحسین فصیحی Thu, 12 Sep 2019 00:14:10 +0430 https://virgool.io/@fassihi/%D8%AE%D8%B7%D8%A7%D9%86%D8%A7%D9%85%D9%87-%DB%B3-%D8%B4%D9%86%D8%A7%D8%B3%D8%A7%DB%8C%DB%8C-%D8%A7%D8%AB%D8%B1-%D8%AA%D8%B9%D8%B1%DB%8C%D9%81-%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%AC%D8%AF%DB%8C%D8%AF-%D8%B1%D9%88%DB%8C-%D9%BE%D8%B1%D9%88%DA%98%D9%87-hvapzfwpuhcg در طول پروژه، همواره در چرخه برنامه‌ریزی کردن و سپس انجام کاری برای بهم زدن برنامه‌ریزی در حال حرکت هستیم. شاید متوسط عمر یک برنامه را بتوان ۴ ساعت دانست. پس از ۴ ساعت، معمولا به نحوی اتفاقی می‌افتد که این برنامه نیازمند تغییر خواهد شد. این اتفاقات انواع مختلفی دارند. گاهی از ابتدا اشتباه برنامه‌ریزی می‌کنیم، گاهی یک مشکل جدید را شناسایی می‌کنیم، گاهی مشکلی برای اعضای تیم بوجود می‌آید و خیلی اوقات نیازهای جدیدتری مطرح می‌شوند و یا اولویت کارها تغییر می‌کند. این‌ موارد تنها نمونه‌ای از اتفاقاتی هستند که با خط قرمز به سراغ برنامه تمیز ما می‌آیند. تغییر غیر قابل اجتناب است و بخش جدی از فعالیت روزانه بازی‌سازی است. شاید بتوان گفت که اگر اینچنین تغییرات روزانه وجود نداشته باشد باید کمی نگران شویم. به قول دوستان چابک: Embrace the Change.یک نکته ولی بسیار مهم است. برای انجام خود تغییرات نیز می‌توان برنامه‌ریزی کرد. در واقع برنامه‌ریزی برای تغییر برنامه‌ریزی فعلی. به عنوان مثال، با پیدا شدن یک نیاز جدید، چندین راه‌حل ممکن است وجود داشته باشد، یکی از این راه‌حل‌ها ممکن است از بقیه بهتر باشد. سوال اصلی این است که چطور می‌توان متوجه شد که کدام راه‌حل مناسب‌تر است؟برای باز کردن مساله از یک مثال استفاده می‌کنم. در وسط فاز تولید پروژه هستیم، متوجه می‌شویم که واسط کاربری بازی از نظر تجربه کاربری (UX) مناسب نیست (این اتفاق در واقعیت نیز چندین بار برای ما افتاده است). تغییرات جدی در آن لازم است، تغییراتی که نیازمند به تولید کار جدید برای برنامه‌نویس، آرتیست و طراح بازی است. سوال اینجاست: دقیقا چه زمانی و با چه ترتیبی باید روی این مساله کار کنیم؟ در اسرع وقت؟ فردا؟ هفته آینده؟ تبعات این مجموعه از کارها روی پروژه چیست؟ چه کارهای دیگری عقب می‌افتد و به چه اندازه؟ آیا فیچری از بازی که در زمانی مقرر باید آماده می‌شد ممکن است به دلیل این کارها به عقب بیفتد؟ با درگیر شدن آرتیست در این کارها، دقیقا چند نفر دیگر که کارشان وابسته به این آرتیست بود در دو هفته آینده ممکن است بدون کار بمانند؟ آیا طراح بازی درگیر مساله‌ای است که نیازمند به صرف زمان پیوسته‌ای است و درخواست اضافه شدن او به این مشکل تجربه کاربری، در کار او خللی جدی ایجاد خواهد کرد؟ با توجه به کارهای سه هفته آینده، برنامه نویس اول را روی این کار قرار دهیم یا برنامه نویس دوم را؟ کدام برنامه‌نویس بهتر است که در این زمینه نیز تجربه کسب کند؟ مقوله آموزش نیروی انسانی چقدر امروز مهم است؟ آیا اضافه کردن این کار در این هفته روحیه کسی را بالا یا پایین خواهد برد؟اگر بیش از یک راه‌حل برای برطرف کردن مشکل تجربه کاربری داریم، هر کدام از آن‌ها دقیقا روی وضعیت پروژه و موارد ذکر شده در بالا چه تاثیری می‌گذارد؟ با ارزش‌ دادن به اثر هر راه‌حل، می‌توان راه‌حل بهتر را انتخاب کرد. این فرآیند تفکر و شبیه سازی تاثیر راه‌حل‌های جدید روی آینده پروژه در واقع همان برنامه‌ریزی برای تغییر برنامه‌ریزی است. یک مکانیزم ارزش‌گذاری روی پارامترهای پروژه لازم داریم و هر راه‌حل را باید بررسی کنیم که چه تاثیری روی ارزش می‌گذارد. آن راه‌حلی انتخاب شود که با ارزش‌تر باشد. به عنوان مثال فرمول ارزش ممکن است اینگونه باشد:ارزش = کمترین درگیری Lead Programmer + عدم تغییر در زمان تکمیل کاراکتر Joey + بیشترین امکان تست سیستم جدید UXبر اساس فرمول ارزش بالا می‌توان راه‌حل‌های پیشنهادی را سنجید و بهترین راه‌حل را انتخاب کرد.با زیاد شدن اینگونه تغییرات در پروژه، آگاه بودن از تبعات هر تغییر روی کل پروژه و تیم بسیار مهم می‌شود و این نیز از مواردی بوده است که من به خوبی نتوانسته‌ام در پروژه اجرا کنم، موارد بالا به‌صورت ضمنی و ذهنی در نظر گرفته شده است ولی بهتر آن است که به‌صورت عینی در پروژه اجرا شوند. به نظر من ابزارهای جدیدی برای کمک به شبیه‌سازی تاثیرات تغییرات روی پروژه لازم است. ابزارهای فراتر از گانت‌چارت‌های استاندارد در نرم‌افزارهای کنترل پروژه و Kanban Board و یا Task Manager. امیرحسین فصیحی امیرحسین فصیحی Wed, 28 Aug 2019 02:29:34 +0430 https://virgool.io/@fassihi/%D8%AE%D8%B7%D8%A7%D9%86%D8%A7%D9%85%D9%87-%DB%B2-%D9%86%D8%B3%D8%A7%D8%AE%D8%AA%D9%86-%D8%AA%D8%B3%D8%AA-%D8%AE%D9%88%D8%AF%DA%A9%D8%A7%D8%B1-u648yjjsghli با بزرگ‌تر شدن پروژه‌های بازی، تست آن‌ها نیز دشوارتر و حساس‌تر می‌شود. هر چه به انتهای پروژه نزدیک‌تر می‌شویم نیز اهمیت این تست‌ها طبیعتا مهم‌تر می‌شود. بازی‌هایی که فضای حالت بزرگی دارند، همچنان کار تست را دشوارتر می‌کنند به این دلیل که زمان زیادی لازم است صرف شود تا قسمت‌های مختلف بازی دیده شود و مطمین شویم مشکلی وجود ندارد. احتمال زیادی هم وجود دارد که بعضی حالت‌ها هرگز در تست دیده نشود. چالش تست بازی فرزندان مورتا علاوه بر طولانی بودن مسیر اصلی بازی (حدود ۱۴ ساعت)، این است که محتوا به‌صورت procedural تولید می‌شود و ممکن است شما همه حالت‌های چیده شدن مرحله را در تست خود نبینید. بعضی از تست‌ها حتما باید توسط یک کاربر انجام شود ولی بعضی از آن‌ها را می‌توانیم به‌صورت خودکار انجام دهیم و نتایج را ببینیم. استفاده از Unit Testing در ساخت نرم افزار رایج است ولی تست‌های با ارزش‌تر بازی، نیازمند سیستمی است که کلیت بازی را بتواند تست کند و نه فقط یک ماژول را. به عنوان مثال کاراکتر شما را از ابتدای مرحله تا انتهای مرحله به‌صورت خودکار هدایت کند. اینگونه تست‌ها برای مطمین بودن از integrity بازی و عدم وجود حالت‌هایی که منجر به crash و یا hang در بازی بشه بسیار مفید است. طبیعتا جایگزین تست‌های دیگر نیست. یکی از حوزه‌های جدی دیگری که ساخت تست خودکار برای آن مفید است بحث بالانس بازی است.در اواسط پروژه ساخت بازی گرشاسپ، یک سیستم تست خودکار درست کردیم به نحوی که گرشاسپ را از ابتدای مرحله اول تا انتهای بازی حرکت می‌داد و به این شکل مطمین می‌شدیم که یکپارچگی بازی بهم نریخته است. معمولا صبح‌های زود و یا شب‌ها دیروقت، کامپیوترهای متعددی در حال اجرای خودکار بازی گرشاسپ بودند. همچنین این امکان وجود داشت که Debugger به بازی متصل شود و در صورت بروز مشکل، برنامه نویس بتواند دقیقا محل و دلیل روی دادن آن را بررسی کند. این سیستم تست به پروژه گرشاسپ کمک بسیار بزرگی کرد و امروز که به آن فکر می‌کنم تصوری ندارم که اگر نبود چه اتفاقی روی می‌داد. در پروژه Shadow Blade، به دلیل کوتاه بودن بازی و ساده بودن ساختار مراحل، نیازی به ساخت تست‌های اینگونه نبود. (البه تصور می‌کنم که با کمی فکر کردن همیشه می‌توان به نیازهایی رسید که با تست خودکار کیفیت را بتوانیم بالا ببریم) ولی در پروژه فرزندان مورتا جای اینگونه تست‌ها خالی است و همواره وجود انباشت کارهای لازم برای پروژه و درگیری اعضای تیم باعث شد که اولویت این کار پایین برود. به احتمال زیاد اگر یکی از نیازهای پروژه را قربانی ساخت این سیستم می‌کردیم، فرآیند تست راحت‌تری را تجربه می‌کردیم. پیشنهاد جدی این است که اگر پروژه شما می‌تواند از تست‌های خودکار بهره‌مند شود،‌ خیلی زود به سراغ ساخت آن بروید، حتما زمان خیلی زیادی را در آینده ذخیره خواهید کرد.اگر تمایل دارید در مورد استفاده از تست‌های خودکار در بازی League of Legends بدانید، این مقاله را مطالعه کنید:https://technology.riotgames.com/news/automated-testing-league-legends امیرحسین فصیحی امیرحسین فصیحی Mon, 26 Aug 2019 12:36:55 +0430