FruitCraft Shop

چطور پول سخت ( Hard Currency ) بازیمون رو بفروشیم!

توسط | مقالات فنی

توی سبک بازی های رایگانی که پرداخت درون برنامه ای دارن ( Free to Play )، از مدلی استفاده میشه به اسم “پول نرم و پول سخت” (  Soft Currency/Hard Currency Model) .در این مدل، پول نرم همون پول متداول داخل بازیه که با حجم زیاد به دست میاد و خرج میشه! اما کنار این پول رایج، واحد پولی دومی وجود داره که به پول سخت معروفه و توی بازی راحت به دست نمیاد. با اینکه بدون خرج کردنش هم بازی بازیکن ها جلو میره، ولی معمولا کارهایی رو برای بازیکن انجام میده که بازیشو جلو میندازه ( Boost) ، شرایط بازی رو براش راحت تر میکنه، و اختلافشو با بازیکن های دیگه ای که از این پول استفاده نمیکنن زیاد میکنه. بازیکن برای به دست آوردن این پول ارزشمند میتونه با پول واقعی توی جیبش اون رو خریداری کنه ( In Game Purchase ).

برای مثال توی بازی Clash Royale، پول نرم بازی سکه، و پول سخت الماس هست. شما می تونید هر دو واحد پولی رو داخل بازی به دست بیارید، ولی حجم به دست آوردن این دو و حجم مورد نیاز برای خرج کردنشون یکسان نیست. درسته که هر چقدر بیشتر بازی کنید از هر دو بیشتر به دست میارید، ولی با اینکه سکه هایی که به دست میارید برای ارتقا دادن ( Upgrade ) کارت هاتون کافیه، الماس هایی که با بازی کردن به دست میارید برای رد کردن زمان انتظار باز شدن صندوقچه ( Chest ) های بازی اصلا کافی نیست. پس تنها راهی که میمونه اینه که وارد فروشگاه بشید، و الماس بیشتری خریداری کنید. این در حالیه که با نخریدن این الماس ها هم چیزی توی بازی از دست نمی دید، فقط باید بیشتر منتظر بمونید. در حالی که با خریدن این پول سخت می تونید سرعت و در نتیجه قدرت بازیتون رو افزایش بدید.

Clash Royale GemClash Royale MoneyClash Royale Currencies

از اونجایی که این واحد پولی منبع اصلی درآمد این نوع بازی هاست، میشه نتیجه گرفت که  چقدر میتونه در درآمدزایی موثر باشه.  و من میخوام در این مقاله راجع به اصول فروختن این پول سخت توی فروشگاه ( Shop ) بازی بنویسم.

نکاتی که اینجا گفته میشه در ژانر بازی هایی بررسی شده که ارز مجازی دارن، اما در واقع برای اکثر بازی های با پرداخت درون برنامه ای که دارای فروشگاه هستن، قابل تعمیم هست.

آیتم های فروشی

اولین نکته ای که باید توی فروشگاه بازی بهش توجه داشت اینه که چه آیتم هایی باید برای فروش گذاشته بشن؟Clash Royal Shop

تنها آیتمی که بازیکن میتونه براش پول واقعی پرداخت کنه و بخره، پول سخت بازیه. همون طور که گفته شد بازیکن توی جریان بازی مقدار قابل قبولی پول نرم به دست میاره، ولی اگر حتی پول نرم بیشتری هم نیاز داشت میتونه بیشتر بازی کنه و مقدار قابل توجهی از این واحد پولی به دست بیاره. از اون جایی که ما همیشه میخواهیم بازیکن وقت بیشتری رو توی بازیمون بگذرونه، این واحد پولی رو مستقیما به بازیکن نمی فروشیم.

اما نمیشه به طور قاطع این قابلیت رو از بازیکن ها گرفت، چون برای بعضی هاشون نارضایتی ایجاد میکنه. پس پول نرم بازی تون ( یا آیتم های دیگه ای که توی روند بازی تاثیر دارن ) رو میتونین با تبدیل پول سخت بازی برای فروش بگذارید. در واقع به پلیر میگید پول سخت بازی رو بخر، و باهاش هر چیزی که دوست داری به دست بیار!

نقاط قیمت گذاری

یه بازیکن نمیتونه توی هر خریدش از فروشگاه بازی هر مقداری که دلش میخواد پول سخت خریداری کنه، ولی میتونه بین مقادیر از پیش تعیین شده ای که به صورت بسته ای به فروش میرسن حق انتخاب داشته باشه. تعیین مقدار واحد پول در این بسته ها و قیمت هر کدوم از بسته ها موضوع مهمیه چون تاثیر مستقیمی روی روش و تعداد خرید بازیکن ها میگذاره.

برای قیمت گذاری این بسته ها از روش ثابتی استفاده میشه. توی این روش باید ارزون ترین و گرون ترین بسته ای که مایل به فروشش هستین رو با توجه به پتانسیل بازی و نیاز بازیکن انتخاب کنین.

نکته ای که راجع به نقطه ی آغاز این بازه مهمه اینه که هیچ وقت اولین بسته ی پیشنهادیتون رو خیلی ارزون انتخاب نکنید، چون اولا باید کمترین حجم بسته به اندازه ای باشه که بعد از خرید و استفاده کردنش تاثیرش توی بازی بازیکن به چشم بیاد و ناچیز شمرده نشه تا برای خرید های بعدی بازیکن رو مایوس نکنه، و دوما بهتره که یه جایی هم برای کم کردن قیمت بسته ها توی تخفیف های آینده بگذارید.  نگران نباشید، یه جمله ی معروف هست که میگه: “خریداری که حاضره واسه ی خرید محصول شما به قیمت خیلی کم دست توی جیبش بکنه، واسه ی یه کم بیشترش هم این کارو میکنه! “ پس باید دنبال عدد درستی بگردید که بالاترین فروش رو در نتیجه ی حاصلضرب تعداد خرید ها و قیمت شون بهتون بده.

آخرین بسته ی پیشنهادیتون رو هم جوری انتخاب کنید که  بیش از حد بزرگ نباشه و بازیتون پتانسیل خرج کردن این مقدار پول سخت رو داشته باشه.  البته بلندپروازی تون رو هم حفظ کنید، چون بازیکن ها با دیدن این ارقام بزرگ توی فروشگاهتون به ارزش خرج کردن توی بازیتون پی میبرن.

حالا باید داخل این دو نقطه ی ابتدا و انتهای بازه، ۵ یا ۶ نقطه برای بسته های دیگه ی فروشگاه مشخص بشه که  قیمت هر کدوم تقریبا دو برابر قیمت نقطه ی قبلیه.

این اعداد تقریبا در تمام بازی های مطرح دنیا به دو شکل دیده میشن:

۱۰۰ ۵۰ ۲۰ ۱۰ ۵
۷۰ ۳۵ ۱۴ ۷ ۳

و در آخر میشه تعداد پول موجود در این بسته ها رو با تقسیم این اعداد به قیمت واحد پولتون، و اعمال تخفیف خرید عمده ( که در ادامه بهش میپردازیم ) تعیین کرد.

روش ارایه ی قیمت

خریدارها همیشه تخفیف گرفتن رو دوست دارن! اما توی خرید درون برنامه ای خبری از چونه زدن نیست! هیچ بازیکنی نمیتونه یه بسته ی ۵ هزار تومنی رو ۴ هزار و ۵۰۰ تومن بخره!!! پس باید یه جوری حس شیرین خرید خوب و به صرفه رو براشون ایجاد کرد.

این روزها خیلی جاها قیمت ها رو به شکل ۹دهم  واحد می بینیم ( مثل ۴.۹ هزار تومن )، و از همه بیشتر توی خریدهای اینترنتی. این اعداد با اینکه فرق قابل توجهی با عدد صحیح بالایی شون ندارن، ولی از لحاظ روانی بار عدد صحیح  پایینی شون رو منتقل میکنن!

در واقع، با فروختن یه بسته ی ۵ هزار تومنی به قیمت ۴.۹ هزار تومن، به مخاطب القا میشه که این مقدار پول مجازی به قدری خوش قیمته که حتی از ۵ هزار تومن پول واقعی هم کمتره .

تخفیف خرید عمده

همیشه باید به بازیکن گفته بشه که هرچی بیشتر بخره، ارزون تر میخره! در واقع هر چقدر بسته ی خریداری شده بزرگتر باشه، سود طرفین هم بیشتر میشه.

اگه شما یه بسته ی ۲۰۰ تایی پول سخت تون رو دقیقا ۲ برابر قیمت بسته ی ۱۰۰ تایی بفروشید، چرا باید بازیکن بسته ی ۲۰۰ تایی رو بخره؟ فقط یک دلیل وجود داره که بازیکن رو ترغیب کنه  بیشتر هزینه کنه و بسته ی بزرگ تر رو بخره، و اونم اینه که با خرید بسته ی بزرگتر قیمت هر واحد پول مجازی براش ارزون تر تموم شه. شاید همه خریدارها نه، ولی درصد بالایی ازشون قبل از انتخاب بسته ی مورد نظر حساب و کتاب میکنن، و به صرفه تر بودن قیمت بسته های بزرگ تر همیشه این دسته از آدم ها رو وسوسه میکنه!

پس میتونید روی بسته های بزرگ ترتون تخفیف های جزیی ولی متقاعد کننده اعمال کنید، و با هرچه بزرگ تر شدن بسته ها این درصد تخفیف رو هم افزایش بدید.

percity shop

برای مثال توی فروشگاه بازی پرسیتی ( PerCity ) مشاهده می کنید که در بسته ی اول هر عدد الماس به قیمت ۳۹ تومن به فروش میرسه. قیمت بسته ی دوم، اگر قیمت واحد بسته ی اول رو داشت، باید ۱۰۱۴۰ تومن می بود. اما در بسته ی دوم قیمت هر واحد الماس ۳۸ تومن محاسبه شده. یعنی با اعمال ۵ ٪ تخفیف.

همین طور با جلو رفتن توی بسته ها و بزرگتر شدن حجم فروش، درصد تخفیف هم افزایش پیدا میکنه. به طوری که در بسته ی آخر، قیمت هر واحد الماس به ۲۲ تومان میرسه، یعنی ۴۵ ٪ تخفیف نسبت به بسته ی اول.

کدومشو بخرم؟

سوالی که اغلب موقع خرید تو ذهن بازیکن میگرده (خصوصا توی خرید های دفعات اول)، اینه که حالا کدوم بسته رو بخرم؟؟؟

بررسی روانشناس ها در مورد رفتار خریدارها نشون میده که آدم ها اگه گزینه های زیادی داشته باشن و حین خرید تصمیم گیری براشون سخت بشه، اغلب ترجیح میدن تصمیمی نگیرن و کلا از خرید منصرف میشن. بنابراین وظیفه ی هر فروشنده ی خوبیه که خریدار رو توی خرید محصولاتش راهنمایی کنه.

اطلاعات مفیدی که در  فروشگاه بازی میشه به خریدار داد میتونه شامل مناسب ترین قیمت، و پرطرفدار ترین بسته باشه. این اطلاعات رو میشه به صورت یه نشون ( Badge ) روی محصول ارایه داد که توجه بازیکن ها رو به خودش جلب کنه.

Angry Birds Go Shop

لقب مناسب ترین قیمت:

این لقب به بسته ای تعلق میگیره که به ازای هر واحد پول سخت ارزون تر تموم شده باشه. طبیعتا آخرین و بزرگ ترین بسته تون این ویژگی رو داره، که با حجم بالایی که داره خریدارهای زیادی رو به سرعت فراری میده! بنابراین نسبت تعداد بازیکن هایی که بزرگترین بسته ی یه فروشگاه رو میخرن به کل خریدار ها خیلی کمه. ولی با اختصاص دادن این عنوان به این بسته ی کم مشتری، نگاه ها رو به سمتش جلب میکنین و شانس خرید این بسته رو افزایش می‌دید. با این روش دسته ی بازیکن های معدودی رو که میان بزرگترین بسته رو بخرن و برن جمع می کنید با دسته ی جدیدی از بازیکن ها که میان به صرفه ترین بسته رو بخرن!

میتونید کنار نشون مناسب ترین قیمت، درصد تخفیفی که روی این بسته ها اعمال میشه رو هم به بازیکن نشون بدین، یا مقدار واحد پول اضافی ای که با خریدن این بسته گیرشون میاد. ولی به دلیل وجود راه های مختلف واسه ی به دست آوردن درصد تخفیف یا مقدار اضافی بسته ها، اکثر بازی های مطرح این کار رو به عهده ی خود خریدار میگذارن!

لقب پرطرفدارترین بسته:

تجربه ی بازی ساز ها ثابت کرده که لقب پرطرفدارترین عموما به ارزون ترین بسته ی فروشگاه تعلق میگیره، چرا که اکثر خرید های اول بازیکن ها با کوچکترین بسته شروع میشه. اما هیچ بازی سازی دوست نداره همین منوال ادامه پیدا کنه! پس کاری که میشه کرد ( و اکثر گیم های مطرح دارن پیاده ش میکنن ) اینه که بازیکن ها رو سوق بدین به سمت پله ی بعدی خرید! نگذارید خریدهاتون گیر کنه روی بسته ی اول، نشون پرطرفدارترین رو به بسته ی بزرگتر بعدی منتقل کنید و در واقع پرطرفدارترین بسته ی آینده رو بهشون معرفی کنید!

حرف آخر:

نکاتی که توی این مقاله گفته شد میتونن به بیشتر شدن درآمدزایی یه بازی کمک کنن، اما قطعا هیچ کدوم به تنهایی کافی نیستن. نکته ی مهمی که باید قبل از ترغیب بازیکن به خرید کردن داخل فروشگاه بهش توجه داشت، هدایت کردن اون به سمت فروشگاه هست. در این مسیر خیلی چیزها میتونه تاثیرگذار باشه، مثل بالا بردن پتانسیل بازی برای خرج کردن پول سخت، و یا عادت دادن بازیکن به استفاده از این واحد پول.

با مقالات بعدی ما در این مسیر همراه باشید.

 

Wanderer Game Jam Team

تجربه ساخت سه بازی در گیم جم – بخش سوم – بازی Wanderer

توسط | مقالات فنی

 

تیم گیم جم ما از چهار نفر تشکیل شد که با وجود موانع سر راهشون تونستن پروژه ی Wanderer رو که فرسنگ ها با ایده ی اولیه شون فاصله داشت ببندن!
این چهار نفر عبارت بودن از: من ( مونا ) ، سارا ، مهراد و امین.
اولین چیزی که همه ی بچه ها کارشون رو باهاش شروع کردن طوفان فکری (brain storm) با توجه به موضوع (theme) اعلام شده ی موج بود. ما تصمیم گرفته بودیم توی این رویداد با یه ابزار جدید کار کنیم، ولی به قدری در حال طوفان راه انداختن با افکار و ایده هامون بودیم که این موضوع رو کلا یادمون رفت…
در انتهای این جلسه، بچه ها ( بدون اطلاع از قابلیت ها و محدودیت های ابزارشون ) ایده شون رو روی تلفیقی از بازی با موج دریا و موج موسیقی بستن.

ایده ی اولیه ی بازیمون چی بود؟Wanderer

ایده ی بازی ما یک پازل صدا و فیزیک موج بود.
قرار بود یک سری قایقران داشته باشیم که روی دریا آواز می خونند. هر کدوم از این قایقران ها به تنهایی نت خودشون رو میخونن و در صورتی که بتونیم به کمک امواج دریا اونها رو از موانع رد کنیم و با ترتیب درست نت هاشون به هم برسونیم، میتونیم به ملودی کاملشون برسیم و پازل حل میشه!

از چه ابزاری استفاده کردیم؟

ما تصمیم گرفتیم توی این رویداد از Corona SDK استفاه کنیم که برامون تازگی داشت و فرصت خیلی خیلی خوبی بود تا باهاش آشنا بشیم! البته نه تنها هیچ کدوم تا حالا با فیزیک کرونا کار نکرده بودیم (که توی پیاده سازی ایده مون خیلی بهش نیاز داشتیم!)، بلکه سه تامون حتی تا حالا کرونا رو از نزدیک هم ندیده بودیم!!! اگرچه همه به این نتیجه رسیدیم که با Unity میتونستیم خیلی بیشتر پیش بریم، ولی از آشنایی با Corona هم به شدت خوش وقت شدیم!

چه چیزایی خوب پیش رفت؟

همکاری توی طراحی Design بازی خیلی خوب پیش رفت، و حیف شد که شرایط بهمون اجازه نداد عملیش کنیم.
گرافیک Graphic بازیمون هم داشت به سمت چیزی که میخواستیم میرفت و به نظرمون راضی کننده میومد.
در هر صورت میشه گفت که تمام المان های یه رویداد پر تکاپو و جالب خیلی خوب پیش رفت. بحث های خوب، ایده های قشنگ، همفکری ها، و …

چی خوب پیش نرفت؟

• پیش بینی حجم کار:
ما یه ایده داشتیم که با توجه به تجربیات خودمون فکر می کردیم می تونیم راحت عملیش کنیم ولی اواسط کار متوجه شدیم که اشتباه می کردیم!
میشد تو مستندات کرونا بیشتر تحقیق کرد و راجع به توانایی ها و ناتوانایی هاش اطلاعات به دست آورد.
به عنوان مثال، توی برخورد موج ها که قرار بود به صورت پویا بزرگتر بشن, سیستم کرونا این scale شدن رو در نظر نمی گرفت و نمیتونست باهاش برخوردی ایجاد کنه. ما زمان زیادی رو صرف برطرف کردن این مشکل کردیم، که اگه اطلاعات کافی داشتیم می تونستیم از قابلیت های دیگه ی کرونا بیشتر استفاده کنیم.

• زمان بندی و تقسیم کار:
چون از ابتدای کار اطلاعاتمون درست و کامل نبود طبیعتا زمان بندی مون هم درست نبود!
غیر از زمان بندی، تقسیم وظایفمون هم میتونست بهتر پیش بره و در نتیجه کمتر به بچه ها فشار بیاد.

• از دست دادن نیرو:
با تمام این اوصاف غول مرحله ی آخرمون هم کم شدن نیرو بود! رایج ترین اتفاقی که تو ماراتون های این چنینی پیش میاد و باعث شکست خوردن پروژه میشه…
به دلیل مشکلاتی که روز آخر واسه ی ۲ تا از بچه ها پیش اومد، تیم ما تبدیل به یه تیم ۲ نفره شد… در حالی که مجبور بودیم با محدودیت های پیش اومده، کل پروژه رو از اول تعریف کنیم و تو ۸ ساعت باقی مونده از این ماراتون ۴۸ ساعته ببندیمش!

گیم جم تادگیم جم تادگیم جم تادگیم جم تاد

و در آخر، تو گیم جم Game Jam چی تجربه کردیم؟

ما توی این اتفاق گروهی جذاب و پرتکاپو لحظات بالا و پایین زیادی رو تجربه کردیم، لحظه های عبوسی که اعصابمون بهمون حتی اجازه ی حرف زدن نمیداد، یا لحظه های شادی که از هیجان جیغ می کشیدیم!

چیزخیلی خوبی که تو ساعت های پایانی رویداد با پوست و استخونمون احساسش کردیم، گرفتن تصمیم های سریع و سازنده، و مدیریت بحران بود. تصمیم های سریع ولی قاطع که تو ساعات های پایانی، design بازیمون، هدف بازیمون، و همه چی رو عوض کرد، ولی نذاشت دست خالی و شکست خورده برگردیم خونه!
اگرچه چیزی که تولید شد هیچ ربطی به ایده ی اولیه مون نداره، ولی ما بهش افتخار می کنیم! 🙂 🙂 🙂 🙂

Game Jam 2017 Wanderer

پیوندهای مرتبط

تجربه‌ی ساخت سه بازی در گیم‌جم – بخش دوم – بازی پلاسکو

توسط | مقالات فنی

نزدیک به ۴۸ ساعت تجربه کار گروهی فشرده در یک فضای پویا، پرانرژی و چالشی برای من به عنوان اولین حضور در Global Game Jam، تجربه جالبی بود. علاوه بر من،  هادی و نیلوفر نیز در تیم حضور داشتند و در روز دوم رویداد، امیرحسین نیز به ما پیوست. خروجی نهایی تیم ما، بازی Selfish (که به فارسی «پلاسکو» نام گذاری شد) بود. محصول ما، یک بازی موبایل بود که شاید بتوان آن را در دسته Art Game گنجاند.

در گیم جم ۲۰۱۷، تصمیم گرفته شد تا تمام تیم‌ها از لحاظ برنامه‌نویسی از موتور بازی‌سازی کورونا استفاده کنند. از این رو من به دلیل داشتن تجربه بیشتر در کار با کورونا علاوه بر تیم خودمان، به نحوی عضو نیمه‌مشترک بقیه تیم‌ها نیز بودم و فضای کاری دو تیم دیگر را کم و بیش لمس کردم. برای همین دوست دارم علاوه بر تجربه تیم خود، به برخی نکات و اتفاقات در فضای کلی شرکت در حین رویداد نیز اشاره کنم.

آماده سازی

شروع فرآیند گیم‌جم ۲۰۱۷ برای ما در واقع از دو روز قبل‌تر از آغاز رسمی آن، با انتخاب تیم‌ها کلید خورد. در ابتدا سعی شد تا بر اساس مهارت بچه‌ها با اولویت توانمندی گرافیکی سه تیم تشکیل شود ولی به هنگام شروع رویداد ترکیب تیم‌ها به دلایل مختلف عوض شد و این ناخودآگاه در نتیجه این رویداد اثر گذاشت. برای مثال چهار عضو تیم ما تبدیل به ترکیب آشنایی از تیم فروت‌کرفت که دو سال است با هم کار می کنند تبدیل شد ولی از طرف دیگر یک تیم هیچ عضوی در  بخش گرافیک نداشت و دو عضو دیگر آن نیز به طور ثابت در کنار تیم حضور نداشتند. این تغییرات در نتیجه و تجربه افراد هر تیم در طول رویداد، هم مثبت و هم منفی، تاثیر خود را گذاشت.

ایده‌پردازی و انتخاب موضوع

اولین گام در جریان کاری گیم‌جم، ایده‌پردازی و انتخاب موضوع بازی بود. در تیم ما هر نفر ۴۵ دقیقه تا ۱ ساعت فرصت داشت تا ایده‌های خود را روی کاغذ جمع آوری کند. بعد از پایان این زمان، هر کسی ایده‌های خود را به صورت کلی ارائه می‌داد و در یک لیست بلند‌تری اضافه می‌کرد. بعد از این ارائه‌ها، ایده‌هایی که احتمال انتخاب شدن را داشتند به صورت جزیی‌تر از لحاظ نحوه‌ی بازی، گرافیک و … بیشتر بررسی شدند.
در نهایت با توجه به محدودیت زمانی، پیاده‌سازی فنی و هنری، ۳ ایده انتخاب شد. از آنجایی که از لحاظ پیاده‌سازی فنی، هر سه ایده تقریبا در یک سطح بودند، انتخاب ایده نهایی بر اساس علاقه جمعی صورت گرفت و حادثه دردناک پلاسکو به عنوان موضوع انتخاب شد.

طراحی و مکانیک بازی

هدف اصلی ما این بود که بتوانیم در پایان رویداد، یک بازی کامل و قابل بازی ارائه بدیم. برای اینکه به این هدف برسیم در طول طراحی بازی و حتی انتخاب ایده تا جایی که امکان داشت سعی کردیم پیچیدگی‌های غیر ضروری را از بازی حذف کنیم و بازی را در سبک‌ترین و ساده‌ترین حالت نگه داریم. بازی ما شامل سه صحنه اصلی بود. در صفحه اصلی بازی، بازیکن می‌بایست مردمی که در حال سلفی گرفتن در کنار ساختمان در حال سوختن پلاسکو بودند را از این ساختمان دور می کرد. آتشنشان‌ها به صورت خودکار در حال خاموش کردن آتش بودند ولی با افزایش موج افراد «سلفی بگیر»، از توانایی آتشنشان‌ها برای مهار آتش کاسته می شد و در نهایت ساختمان فرو می‌ریخت.
از آنجایی که داستان اصلی بازی بر اساس واقعیت بود، تصمیم گرفتیم که پایان بازی نیز بر اساس واقعیت باشد یعنی بازیکن در هر صورت با سخت‌تر شدن بازی محکوم به شکست باشد.

گرافیک – صدا

یکی از ویژگی‌های اصلی بازی ما استفاده از سبک Pixel Art برای طرح‌های گرافیکی بود که آن را با بقیه بازی‌ها کمی متفاوت می‌کرد. در راستای گرافیک بازی، طبق بررسی که با نیلوفر انجام دادیم به این نتیجه رسیدیم که زاویه دید ایزومتریک بهترین گزینه برای ماست. این زاویه هم فضای بهتری را در بازی پوشش می‌داد و هم به عنوان اولین تجربه نیلوفر در ترکیب زاویه ایزومتریک و پیکسل آرت یک چالش محسوب می‌شد.
اکثر صداهای بازی، در روز آخر رویداد توسط من در کنار بچه‌ها تولید شد که تجربه خیلی جالب و خوبی برای من بود. با توجه به بازخوردها، بقیه اعضای تیم هم از صدا‌ها و موسیقی‌های ساخته شده راضی بودند.

تجربه نو

یکی از بهترین اتفاق‌ها و تجربیاتی که در رویداد گیم جم رخ داد به نظر من و بقیه اعضای تیم، برنامه‌نویسی هادی بود. هادی برای اولین بار داشت بدون هیچ دانش اولیه‌ای برنامه‌نویسی می‌کرد. در دو روز اول رویداد، هادی یک پروژه تمرینی با کورونا ساخت و در روز آخر دو صحنه از سه صحنه اصلی بازی توسط هادی تولید شد. در کنار این اتفاق، من هم توانستم بعد از دو سال، توانایی خودم در انتقال تجربیاتم در کورونا را بسنجم.

روحیه تیمی

ما توانستیم یک ساعت قبل از پایان یافتن رویداد، یک بازی نسبتا کامل و قابل استفاده تولید کنیم. مهمترین عامل در این اتفاق از نظر من، روحیه تیمی بالا و حس مسوولیت پذیری بود که تک‌تک اعضا نسبت به تیم و پروژه تعریف شده داشتند. با وجود اختلاف نظر‌‌هایی که در فاز‌های مختلف کار پیش می‌آمد، تمام افراد فضای حاکم را درک می‌کردند و هر کس با توجه به توانایی‌های خودش سعی در یکسو‌سازی و هم‌گرایی نظرات بود.

همیشه همه چیز خوب نیست!

اکثر اتفاقاتی که در این رویداد برای ما افتاد اتفاقات مثبتی بود و در روند کار به مشکلات زیادی نخوردیم ولی شاید بد نباشد که به چند مشکلی که با‌ آن مواجه شدیم، اشاره کنم:

  • نیلوفر قصد داشت تا طرح‌های گرافیکی را با استفاده از تبلت وکام (Wacom) شخصی خود اجرا کند ولی متاسفانه درایور مناسب آن برای ویندوز ۱۰ را پیدا نکردیم. از این رو تقریبا یک روز از رویداد از روی ناچاری طرح‌ها با موشواره زده شد. این اتفاق هم سرعت تولید المان‌های گرافیکی را پایین آورد و هم باعث شد از بعضی از ایده‌ها و طرح‌ها صرف نظر کنیم. محدود بودن زمان هم کمی به استرس این ماجرا افزود.
  • زمان ایده‌پردازی ما خیلی بیشتر از بقیه تیم‌ها طول کشید(تقریبا روز اول رویداد به ایده پردازی و انتخاب موضوع گذشت) و اگر در آخرین لحظات نمی‌توانستیم کنترلش کنیم شاید نتایج بدی را برامون به ارمغان می‌آورد.

کلام آخر

از آنجایی که توانستیم در زمان محدود و با فشار کاری بالا، هدفمان را محقق کنیم به نظرم به موفقیت نسبی در این رویداد رسیدیم. بازی پلاسکو برای دستگاه‌های اندرویدی از طریق کافه بازار در دسترس است. در آخر می‌خواهم از اعضای تیم تشکر کنم و چند خطی راجع به نقش‌شان در این پروژه بنویسم:

  • نیلوفر نوایی:
    بدون حضور نیلوفر پروژه ما به سختی جلو می‌رفت. از آنجایی که از لحاظ پیاده‌سازی خیلی پروژه پیچیده‌ای نداشتیم، بخش بزرگی از بار کاری روی دوش نیلوفر بود که از نظر من خیلی خوب از پس این کار برآمد. همچنین به‌دلیل تجربه و اطلاعات خوبی که نسبت به بازی‌ها و رویداد‌های مرتبط به آن داشت در خیلی از مقاطع نکات مهم و کار راه‌اندازی را به ما گوش‌زد می کرد.
  • هادی دعایی:
    هادی خیلی با استعداد عمل کرد و در روز آخر دو تا از بخش‌های بازی را هادی پیاده‌سازی کرد. همچنین در بخش ایده‌پردازی بخش زیادی از ایده‌ها رو هادی ارائه کرده بود.
  • امیرحسین حسنینی:
    تمام جذابیت‌های بازی مثل رفتار تصادفی آدم‌ها، آتشنشان‌ها و افکت‌های تصویری مثل آب و انفجار همه کار امیرحسین بود. طبق تجربه‌ای که این مدت با امیر‌حسین داشتم، کافیست امیر‌حسین را کنارت داشته باشی تا از هیچ نظر هیچ غمی نداشته باشی! در مدیریت تیم در این رویداد دو روزه مواردی که در مدت همکاری دو سال و نیم از امیر‌حسین یاد گرفتم خیلی به من کمک کرد. یک لیدر می‌تواند در عین جدیت و قاطع‌بودن، مهربان،حمایت‌گر و باعث دلگرمی اعضای تیم نیز باشد.

تیم توسعه پلاسکو

 


پیوندهای مرتبط

 

تیم بازی Stock Stalker در گیم جم

تجربه ساخت سه بازی در گیم جم – بخش اول – بازی Stock Stalker

توسط | مقالات فنی

گیم جم یک رویداد ۴۸ ساعته‌ست که کسانی که به ساخت بازی علاقه دارند در اون شرکت میکنند و در این مدت کوتاه به صورت پیوسته روی ایده، طراحی و ساخت یک بازی کار میکنند تا به یک محصول برسه! ما در رویداد Global Gamejam 2017 شرکت کردیم و روی یک بازی به اسم Stock Stalker کار میکردیم که تیممون از سه نفر، من (علی)، رامین و فهیمه تشکیل میشد. تصمیم گرفتیم که تجربه و حس‌مون از شرکت در این رویداد رو با این نوشته به اشتراک بگذاریم.

۴۸ ساعت فرصت داشتیم، پس روندی که ما طی کردیم به این شکل بود که مطابق توصیهی این رویداد حدود یک ساعت و نیم رو صرف طوفان فکری، انتخاب ایده و پختن ایده کردیم. تقریبا در همین زمان هم (سه نفر از چهار نفر) به توافق رسیدیم که روی یکیش کار کنیم به غیر از یکی از بچه ها که به پیشنهاد ما و خودش جابجا شد. البته این مورد طبیعی هست، چون باید انگیزه کافی از طرف همهی افراد وجود داشته باشه که روی اون ایده کار کنن. توی استارت آپ ویکند ها معمولا ایده ها توسط افراد (نه گروه) تعریف میشه و اون افراد در همون روز اول برای ایده شون تیم جمع میکنند، به همین جهت چنین مشکلی وجود نداره و افراد به اختیار حول اون ایده جمع شدهان. ولی در فرآیند گیم جم ما، تیم ها قبل از اعلام موضوع رویداد تشکیل شده بود.

چه طور ایده رو انتخاب کردین؟

موضوع رویداد «موج» (Waves) بود. ایدههایی اولیه ای که این موضوع توش باشه رو هر کسی روی کاغذ میکشید و به بقیه نشون میداد. حدود هشت تا ایده داشتیم. ویدیوی معرفی موضوع که از طرف تیم گیم جم ارسال شده بود، تصویرهایی از موجهای سینوسی و نمودارهاش نشون میداد. از طرفی بالا و پایین شدن قیمت سهام هم چنین نمودارهایی رو توی ذهن ما تداعی کرد. این شد که تصمیم گرفتیم یک بازی شبیه سازی بازار سهام بنویسیم که توش قیمت محصولات به صورت متناوب بالا و پایین بشه. بازیکن قرار بود توی این بازی با کلیک بتونه جنسش رو به قیمت اون لحظه بخره و بفروشه و با این کار پول در بیاره.

تصویر بازی Stock Stalker در گیم جم ۲۰۱۷

از چه ابزاری استفاده کردین؟

تصمیم گرفتیم که از تکنولوژی کرونا استفاده کنیم، که یه آشنایی اولیه داشتیم، رشد یادگیریش سریع بود و به نظر ابزار مناسبی برای پروتوتایپ سریع (Fast Prototyping) بود و علاوه بر اینها یه نفر (علیرضا) توی مجموعه بود که سوال هامون رو ازش بپرسیم. من که اولین تجربه کار جدیم با یک موتور بازی بود، فهیمه (و البته من) خیلی ازش راضی بودیم. رامین ولی معتقد بود که یونیتی که خودش باهاش اشنا بود کار رو میتونست سریع تر از این هم بکنه.

چه کاری خیلی خوب پیش رفت؟

یکی از بهترین کارهایی که کردیم (در واقع رامین به صورت داوطلبانه انجام داد) این بود که از نقاشیهای اولیهی فضای بازی که روی تخته کشیده بودیم، یک نمونهی گرافیکی اولیه طراحی کرد که هم المانهای بازی رو نشون میداد، هم چینش (layout) بخش های مختلف رو و دو نفر دیگه که بیشتر کارهای کدنویسی رو انجام میدادیم، تونستیم با داشتن طرح اولیه خیلی سریع به نسخهی اولیهی بازی با همون گرافیک ها برسیم.

چه کاری خوب پیش نرفت؟

میتونم بگم بزرگترین اشتباهی که انجام دادیم این بود که در آخرین ساعتها، یک امکان جدید برای بازی در نظر گرفتیم که درآمد بازیکن رو در یک بازهی زمانی محدود کنیم. این ایده ویژگی های مثبتی رو به بازی اضافه میکرد اما تقریبا همهی بخش های دیگر بازی که تابحال نوشته شده بودند و کار میکردند رو تحت تاثیر قرار میداد و متاسفانه در آخرهای کار فهمیدیم که پیچیدگیش بیش از اندازه هست. تقریبا تا یک ربع قبل از اتمام زمان ارسال، فهیمه با استرس زیاد داشت روی رفع اشکالات این بخش کار میکرد و در نهایت هم اشکالات به طور کامل در نسخه نهایی حل نشده بود. اگه برای بستن کار و تست اون و اضافه نکردن امکانات جدید سخت گیری بیشتری روی خودمون داشتیم، قطعا نتیجه بهتر بود و استرسی به این شکل برای بستن کار به تیم وارد نمیشد.

حلقه‌ی بازیکنان گیم جم بازی Stock Stalker

تجربه و حستون از گیم جم چی بود؟

گیم جم تجربهی دلپذیری برای هر سهی ما بود. رامین اشاره میکنه که حضور توی همچین رویدادی، ذهن رو حتی توی رخت خواب درگیر خودش میکنه (که چطور میشه این بازی رو بهتر کرد) و اتفاقا داستان بازی ما در یه همچین نصفه شبی نوشته شده! فهیمه میگه که حتی توی خواب هم داشته برای بازی کد مینوشته. اینکه محدودیت زمانی توی همچین رویدادی وجود داره، باعث میشه سرعت یادگیری، و توان جسمی و ذهنی به شدت بالا بره، مثل شبهای امتحان!

تیم بازی Stock Stalker گیم جم - شرکت تاد تیم بازی Stock Stalker گیم جم تیم بازی Stock Stalker گیم جم

از طرفی حس کار گروهی توش بسیار پر رنگه. ما از سیستم Git برای اشتراک منابع و کد استفاده میکردیم. تقریبا هر ساعت که نتیجه کار بچه ها رو روی سیستم خودم میگرفتم، حس رضایتی بهم دست میداد. حس اینکه من دارم برای یکی از دیوارها آجر میچینم و الان میبینم که دیوار کناریش رو هم تیمیم ساخته و من دارم استفاده میکنم. این باعث میشه که آدم ها به هم نزدیک تر بشن و حس یه کار گروهی مثبت رو تجربه کنن. فهیمه اضافه میکنه که ساخت یه بازی توی این مدت، حس رضایت و قدرتمندی بهمون اضافه کرده و قطعا تلاش خواهد کرد چنین تجربهای رو تکرار کنه.

دو تیم دیگه هم به زودی تجربیاتشون رو از همین طریق به اشتراک خواهند گذاشت و میتونید دنبال کنید. اطلاعات این پروژه در سایت رسمی گیم جم ۲۰۱۷ در این لینک قابل دسترسی و دانلود هست.

پیوندهای مرتبط

Adche group vision

شش درس در کالبد شکافی شکست یک پروژه

توسط | مقالات فنی

مشغول دویدن معمول روی تردمیل بودم که به فکر فرو رفتم. خاطرات پروژه‌ی «ادچه» در خاطرم زنده شد که این روزها اثری از آن باقی نمانده است. دیدم که این روزها بسیاری از آنچه در رویدادها میشنویم، داستان های موفقیت است و داستان‌های شکست کمتر گفته و شنیده میشود. در داستان‌های گذشته، اهمیت نوشتن این مقاله و چگونگی آن غرق شدم به طوری که رکورد دویدنم را زدم و وقتی به خودم آمدم ۲۰ دقیقه دویده بودم.

سابقه

ما یعنی تاد یک استودیوی تولید اپلیکیشن موبایل بودیم، که بعد از چندین سال تجربه و تلاش‌های مختلف، موفق شده بودیم یک بازارچه‌ی اپلیکیشن‌های موبایل با اسم سیبچه و یک کارت بازی اجتماعی آنلاین ، به نام فروت کرفت را توسعه داده، منتشر کرده و به موفقیت برسانیم. بعد از دو تجربه‌ی موفق، تصمیم گرفته بودیم که با دو پروژه‌ی دیگر، نشان دهیم که موفقیت‌های پیشین تصادفی نبوده است. اول پروژه‌ی ادچه و در کنار آن یک بازی اجتماعی آنلاین دیگر در سبکی متفاوت که از اولی تقریبا هیچ چیز نمیدانستیم اما خوشبختانه تجربه‌ی دومی را داشتیم.

Adche postmortem ادچه

ماجرای ادچه چه بود؟

داستان از یک میهمانی دورهمی شروع شد که دو نفر از اعضای شرکت با فرد جدیدی آشنا شدند که در صنعت تبلیغات روزنامه بسیار فعال بود و با توجه به تخصص و ارتباطاتی که داشت امکان چاپ آگهی ارزان قیمت در روزنامه ها و نیازمندی های شهری برایش فراهم بود. این آشنایی حدود یک هفته بعد به جلسه‌ای در دفتر سیبچه تبدیل شد که قرار بود در آن پیشنهاد شگفت انگیزی به ما ارایه شود که خبر نداشتیم این پیشنهاد چیست.

در این جلسه، آمار گردش مالی بازار تبلیغات روزنامه های کشور را به صورت روزانه بررسی کردیم و به تخمین چند میلیارد تومانی در روز رسیده بودیم که حجم قابل توجهی (حدود نصف) از این عدد به نیازمندی‌های همشهری اختصاص داشت. تیم ما توان و تخصص توسعه یک تجارت موبایلی / اینترنتی را داشت و در مقابل «شریک» جدیدمان توان و تخصص ارایه‌ی هر گونه تبلیغات چاپی و غیر چاپی با قیمت مقرون به صرفه. بنابراین به این نتیجه رسیدیم که با شروع یک همکاری میتوانیم نیازهای تبلیغاتی مردم را از طریق وب و موبایل برآورده کنیم و بخشی از این بازار چند میلیاردی، هر چند که کوچک باشد، را تصاحب کنیم.

ایده اولیه‌ی شریک این بود که تمامی نیازهای تبلیغاتی در قالب یک اپلیکیشن موبایل برآورده شود. او حتی با استخدام یک برنامه نویس به یک نمونه اولیه برای این برنامه رسیده بود که میتوانستید حتی بیمه ماشین تان را هم در این برنامه تمدید کنید. در اولین تلاش‌ها برای تمرکز و کوچک کردن محدوده‌ی کار، موفق شدیم بحث‌های متفرقه مثل اقلام تبلیغاتی و تمدید بیمه و … را از محدوده‌ی کاری فعلی خارج کنیم (البته با دادن این امید به شریک که اگر کار فعلی گرفت انشالله برخواهیم گشت و این موارد را هم انجام خواهیم داد).

درس ۱- درس های قبلیتان را دوره کنید!

در طی سالهایی که گروه تشکیل شده بود و پروژه‌های موبایلی مختلف را انجام داده بودیم، چندین بار پروژه هایی را به اتمام رساندیم که در مرحله‌ی توزیع و انتشار با مشکل مواجه شد. این مشکلات شامل عدم اقبال کاربران، عدم انجام وظایف تعهد شده‌ی ناشر و یا ریسک‌های فنی بود (مانند آنچه در Situationist تجربه کرده بودیم که تمام تلاشمان با حذف برنامه توسط شرکت اپل به باد رفت). به همین جهت، در توسعه‌ی بازی فروت کرفت، تصمیم گرفتیم که یک نمونه‌ی اولیه در کمترین زمان توسعه بدهیم و اقبال مردم و موفقیت پروژه را، پیش از اینکه زمان توسعه‌ی طولانی برای آن صرف کنیم، امتحان کنیم. این تجربه بسیار موفقیت آمیز بود. با یک کمپ دو هفته‌ای و تولید یک نمونه‌ی اولیه از بازی، با استقبال کاربران مواجه شدیم. این نمونه تنها از چند صفحه‌ی وب که کارت‌های بازی را نمایش میداد تشکیل شده بود. پس از آن با اطمینان خاطر فرآیند توسعه‌ی ده ماهه‌ی این بازی را شروع کردیم و به سرانجام رساندیم.

هنگامی که به عنوان تیم فنی، سراغ ادچه رفتیم، با همین ذهنیت یک سایت اولیه به کمک ابزارهای آماده در طی سه روز ایجاد کردیم که کاربران میتوانستند روزنامه و آگهی خود را در یک فرم ساده ثبت کنند و ما سفارشات را در ایمیل خود دریافت کنیم. تا اینجای کار، با ساخت یک نمونه اولیه درس خود را فراموش نکرده بودیم، اما اینکه هیچ کس در این سایت سفارشی ثبت نمیکرد و شریک هم حاضر به گسترش و تبلیغات این سایت نبود، را بدین معنی دانستیم که قطعا تجربه‌ی کاربری نقش اساسی در این تجارت دارد و ما به اندازه کافی کار را برای مردم آسان نکرده ایم که درخواست تبلیغاتشان را به ما بدهند. در حالی که فرض دیگری که قوت بیشتری داشت این بود که به هر دلیلی، مشتریان ارزش ارایه شده‌ای در محصول نمی‌بینند و از سفارش آنلاین آگهی چاپی امتناع دارند و میتوانستیم با تحقیقات بیشتر از طراحی و توسعه‌ی یک سیستم کامل سفارش گیری جلوگیری کنیم. بنابراین بهتر است به جای اینکه تمرکز را بر روی روند‌های پیچیده‌ی بگذاریم، بهتر بود انرژیمان را بر روی جایی متمرکز کنیم که مشتریان در آن ارزشی می‌بینند.

درس ۲ – اعتماد به نفس یک موفقیت، به جای خوش‌بینی باید دقت به ارمغان بیاورد.

در طراحی ادچه با توجه به شناختی که از فرآیند سفارش یک آگهی در نیازمندی های همشهری پیدا کرده بودیم، تقریبا مطمئن بودیم که موفق می‌شویم، از آنجا که یک فرآیند طاقت فرسا برای کاربران را تبدیل به چند کلیک در اینترنت کرده ایم و چه کسی ترجیح میدهد تلفنی نزدیک ترین نمایندگی همشهری را پیدا کند، بعد منتظر پیک باشد که احراز هویت را انجام دهد و فرم کاغذی آگهی را پر کند و در نهایت مبلغ آگهی را به صورت نقدی بپردازد یا کارت به کارت کند. ما تمام این فرآیندها را به یک سایت ساده تبدیل کرده بودیم که کاربر میتوانست آگهی خود را در آن تایپ کند، پیش نمایش نزدیک به چاپ آگهی خود را مشاهده کند و با پرداخت آنلاین وجه نگرانی دیگری نداشته باشد. حتی قیمت‌های ارایه شده و تمام شده برای مشتری در این سایت کمتر از حالت فیزیکی بود.

حدود یک ماه بود که نسخه‌ی اولیه از سایتی که توان پذیرش آگهی را داشت منتشر کرده بودیم و در یکی از سایت‌های خبری، مطلبی مربوط به انتشار این سرویس منتشر کرده بودیم. اما استقبال بسیاری اندک کاربران باعث شد که دنبال دلیل این موضوع بگردیم و آن را در دسته بندی و الگوی رفتاری مشتریان خود پیدا کردیم.

مشتریان ادچه دو گروه بودند، آنها که مستقل بودند و برای رفع نیاز شخصی (مثلا فروختن ماشین یا استخدام) در برهه هایی از سال نیازی برایشان ایجاد می‌شد و اقدام به سفارش آگهی میکردند (که این گروه حدود ۶۰ درصد سفارش‌ها را تشکیل میدادند) و گروه دوم (۴۰ درصد باقی‌مانده) مشتریان ثابت بودند که صنف هایی مانند بنگاه های املاک، و نمایشگاه های ماشین عمده‌ی آنها را تشکیل میدادند. این گروه تقریبا به صورت روزانه نیازمند چاپ آگهی بودند.

هدف ابتدایی ادچه یک تجارت B2C بود که به مشتریان نهایی، یعنی گروه اول خدمات بدهد. مسیر عمومی این گروه از مشتریان برای سفارش دادن این بود که یک نیازمندی همشهری چاپ شده پیدا کنند و سپس با تلفن دفاتر که در صفحه اول چاپ شده بود، تماس بگیرند. با اینکه شریک موفق شده بود یک نمایندگی مجازی از همشهری اخذ کند، اما همشهری اجازه نداد که ما خدمات خود را در صفحه اول این روزنامه به نمایش دربیاوریم به جهت اینکه ممکن بود دفاتر سنتی فعلی همشهری در خطر از دست دادن مشتری قرار بگیرند.

از طرفی موضوع آگهی دادن برای یک نفر از این گروه کاربری، موضوعی گاه گاهی بود و به همین جهت گرفتن تبلیغات برای جذب مشتری، تا حدودی غیر ممکن بود زیرا هنگامی که یک نفر با معرفی خدمات ما مواجه میشد، احتمال اینکه در آن زمان نیاز به دادن آگهی داشته باشد، بسیار اندک بود. این دو نکته، مواردی بودند که شاید با تفکر و تحقیقات پیش از شروع کار میتوانستیم به آنها دست پیدا کنیم و چندین قدم جلوتر باشیم.

به همین جهت در تصمیمی مشترک، بر روی گروه دوم مشتریان تمرکز کردیم و گروه بازاریابی شروع به سر زدن به بنگاه های املاک و نمایشگاه های ماشین کردند اما در کمال ناباوری در یک ماه تنها حدود ۳ الی ۴ مشتری ثابت را توانستند با تلاش های مضاعف جذب کنند. در این حوزه نیز مشکل اجرایی وجود داشت که ما اهمیت آن را بسیار کم میدانستیم. نمایندگی های همشهری، مشتریان مداوم و ثابت خود را (که بیشتر صنوف را شامل میشود) بر روی کد شعبه نمایندگی خود قفل میکنند و هیچ نمایندگی دیگری اجازه‌ی سرویس دهی به این مشتریان را ندارد. همین موضوع باعث میشد که مشتریانی که ما به آنها مراجعه میکردیم، امکان جابجایی و استفاده از خدمات ما را نداشته باشند.

شاید حدود نه ماه از شروع پروژه گذشته بود که با یکی از همکاران فنی، از شرکت بیرون زدیم و به بنگاه های املاک اطراف شرکت رفتیم و پروژه را ارایه کردیم. عموم آنها با مهاجرت به یک سیستم جدید مشکل داشتند و ترجیح میدادند که با دفاتر همشهری که سالها بود با آنها در ارتباط بودند، فعالیت کنند. انحصار مشتریان گروه دوم و عدم علاقه آنها به مهاجرت نیز مسائلی بود که میتوانست پیش از اینکه یک محصول ساخته شود، مورد بررسی قرار بگیرد و یکی از درس هایی بود که آموخته بودیم اما به کار نبستیم.

درس ۳ – یک هدف و آینده‌ی مشترک و کوچک، بهتر از صدها هدف بزرگ غیر مشترک در ذهن افراد است.

adche_groupهنگام شروع فرآیند طراحی محصول، طبق انگیزه‌ای که داشتیم و چراغ سبزی که شریک برای هر نوع رسانه‌ی تبلیغاتی به ما داده بود، تصمیم بر آن داشتیم که هر نوع رسانه‌ای در سیستم ما قابل سفارش باشد. حتی در این فکر بودیم که مشتری بتواند بیلبورد کنار اتوبان همت را انتخاب کند و سفارش بدهد. در اولین جلسه‌ای که برای طراحی جدید سیستم گذاشتیم به این نتیجه رسیدیم که سیستمی که از آن صحبت میکنیم حداقل نیاز به یک سال توسعه‌ی مداوم خواهد داشت تا به نقطه‌ی صفر برسد. به همین جهت یک تصمیم مناسب برای کوچک تر کردن محدوده‌ی پروژه گرفتیم و نقطه‌ی شروع خود را رسانه‌های چاپی گذاشتیم. اما دو اشتباه کردیم:

اول اینکه در طراحی های خود آینده‌ی فکر بزرگمان را دخیل میکردیم و سیستم را طوری طراحی میکردیم که به آسانی برای آن آینده قابل گسترش باشد و دیگری اینکه شاخ و برگی که از محدوده‌ی پروژه زدیم باز هم کم بود و همچنان رسانه‌های چاپی هم نقطه‌ی شروع بزرگتری بود. اگر به آن نقطه بازگردیم احتمالا فقط و فقط از نیازمندی های همشهری شروع میکنیم. یک رسانه چاپی خاص که سهم بزرگی از بازار دارد.

کوچک تر کردن محدوده‌ی پروژه یکی از کارهای خوبی بود که در فرآیند طراحی انجام داده بودیم. برای اینکه شریک را در جهت انجام این کار متقاعد کنیم تلاش بسیاری انجام دادیم. اما بعد از جلسه‌ی توجیحی برای اینکه کار کوچک‌تر و متمرکزتر باشد، کارهایی توسط تیم بازاریابی انجام می‌شد که نشان از این داشت که شریک هنوز برای متمرکز کردن پروژه متقاعد نشده است و ما نتوانسته بودیم پیام و تجربه‌ای که داشتیم را درست منتقل کنیم. به همین جهت تا مدتی آنچه در ذهن هر یک از پدید آورندگان بود، متفاوت بود. یکی از ما میخواست دوچرخه ای بسازد و دیگری قطار مغناطیسی سریع السیر…

این یکی از آفت های کارهای مشترک است که آینده و هدف (Vision) در ذهن افراد متفاوت باشد و نیازمند این است که پدیدآورندگان قبل از شروع به کار، ذهنیت خود را از کار یکسان کنند. حتی در مواقعی شاید حذف کامل یک آینده‌ی بزرگ تر مفید باشد، چون ممکن است همانطور که بالاتر ذکر شد، یک برنامه نویس در طراحی خود و یک بازاریاب در ارتباط جدیدی که تشکیل میدهد، آینده‌ی بزرگی را در نظر بگیرد که به این زودی ها وجود نخواهد داشت، حال آنکه این تلاش میتوانست بر روی هدف کوچکتری که در کوتاه مدت نتیجه بخش باشد متمرکز و هزینه شود.

درس ۴ – انتخاب شریک، اگر سخت تر از انتخاب همسر نباشد، آسان تر نیست

انتخاب شریک سخت است. ما انسان ها اساس روابطمان بر پایه‌ی احساس، دوستی و اعتماد است. اما انتخاب افراد بر اساس این پارامترها کاستی‌هایی به همراه دارد که می‌بایست به کمک بررسی های عقلانی و تحقیق آن را جبران نمود. به عنوان مثال ممکن است یک فرد به خودی خود، فهرستی از موفقیت های مختلف را در شرح حال کاری خود داشته باشد اما هیچ کدام از انها شامل همکاری و یا یک کار گروهی نباشد. تجربه‌ی شراکت موفق (به صورت منظم نه به صورت سنتی یا بازاری)، نحوه‌ی ارتباط، کار تیمی، راضی کردن و راضی شدن در مواقعی که اختلافی پیش می‌آید، و شفاف بودن مواردی هستند که بررسی آنها برای انتخاب شریک در شروع هر کاری مهم است. یکی از موارد دیگر یکپارچکی و مبنای اخلاقی برای تصمیم‌هاست که می‌بایست در فرد مورد نظر به دنبال آن گشت و در صورتی که تصمیمات فرد بر اساس اصول اخلاقی و مستحکمی نباشد، ممکن است در طی زمان رفتارهای متناقضی مشاهده کنید که باعث تعجب شما گردد.

درس ۵ – تصمیمات جدی و قراردادهای کاری‌تان را مستند کنید.

Adche Cofounder ادچه

یکی از مواردی که به تجربه بارها از نبودش ضربه خورده ایم و در این پروژه هم تکرار شد، نوشته نشدن شرایط همکاری و بررسی شرایط موفقیت و شکست است. اینکه وقتی کاری را شروع میکنید، درصد های شراکتی را به صورت رسمی مشخص کنید و بسم الله بگویید کار درستی نیست. بهتر است همه‌ی شرایط ممکن بررسی شده و نوشته شود. اگر مجموعه به موفقیت رسید، اگر رشد مجموعه ثابت ماند، اگر ورشکست شد و هزینه‌هایی روی دست شریکان گذاشته شد، در همه‌ی این شرایط چه اتفاقی می‌افتد. چگونه هزینه های جاری تامین می‌شود، چگونه شکست جبران می‌شود، وقتی کار بزرگتر شد، تصمیم های اساسی چگونه گرفته می‌شود. اینها موارد مشترک و ساده ایست احتمالا اصول مشترکی در ذهن کسانی که تجربه‌ی شراکت جدی داشته‌اند، در موردشان وجود دارد. اما اگر با کسی شراکت را آغاز می‌کنید که اینگونه تجربه‌ای نداشته است، حتما آگاهش کنید و حتی المقدور بررسی شرایط و وضعیت های مختلف را مکتوب کنید.

ما انسانیم و هر چقدر هم که باهوش و ذکاوت باشیم، فراموش میکنیم و این در طبیعت ماست. بنابراین جدای از تصمیمات اساسی در ابتدای کار،‌ بهتر است نتایج عموم جلسات و تصمیم‌ها توسط یک نفر مکتوب شود و به بقیه ارسال گردد. این مکتوبات هم در آینده نزدیک برای شروع عملیات (اکشن)‌های مربوط به جلسه مفید است و هم در آینده دور به افراد آنچه گذشته است را یادآوری می‌کند.

درس ۶ – نشانه‌های مشکل ارتباطی در تیم را خوش بینانه تفسیر نکنید.

شاید یکی دوماه از اولین آشنایی ما با شریک میگذشت که در جلسات برگزار شده، تفاهم به سختی به دست می‌آمد. نشانه‌های ارتباط غیر صمیمانه و دور از تفاهم بین بعضی اعضای شرکت و شریک باعث شده بود که یک جدایی ارتباطی بین بنیانگذاران ایجاد شود. البته با تفسیر خوش بینانه‌ی این موضوع، یک نفر همواره تلاش داشت که با صحبت جداگانه با افراد، موضوعات را به طور خاص حل و فصل نماید که کم کم دچار شرایط دیگری تحت عنوان میانجیگری شدیم که در مواقعی که تفاهم به دست نمی‌آمد، یک فرد دیگر (میانجی) ارتباط را برقرار کرده و مساله را به نتیجه می‌رساند.

وقتی هم افزایی (synergy) در یک تیم وجود داشته باشد، نتیجه‌ی به دست آمده بیش از جمع کار تک تک افراد تیم خواهد بود. عدم ارتباط سالم در یک تیم، به جای آنکه تلاش تک تک اعضای تیم را با هم جمع کند و بیشتر از آن نتیجه تولید کند، باعث اصطکاک شده و نتیجه‌ی به دست آمده حتی کمتر از کار فردی اعضا خواهد بود. پس از شش ماه از شروع پروژه جلساتی برگزار میشد که در آنها نتیجه‌ای به دست نمی‌آمد که همه‌ی افراد آن را قبول داشته باشند و آن را عملی کنند و این موضوع ریشه در مشکلات ارتباطی تیم پدید آورندگان داشت. البته هر عضو این تیم مرکزی، یک تیم زیرمجموعه برای خودش داشت که در آنها مشکلات ارتباطی چندانی وجود نداشت، اما به هر حال مشکلات ارتباطی یک تیم مرکزی، باعث به نتیجه نرسیدن تلاش تیم های کوچک تر میشود.

فصل

پایه‌ی اصلی تجارت‌ها تکنولوژی یا ایده و … نیست، بلکه ما انسان‌ها هستیم و شناخت، روابط انسانی، و ارتباط موثر بر موارد دیگر مقدم هستند و می‌توانند آنها را بسازند یا خراب کنند. اتفاقات زیادی در مدت زمان این پروژه افتاده است که در این مقاله جای ذکرشان نبوده باشد و تلاش بر این بوده که تجربیاتی که ما با شکست و هزینه به دست آورده ایم، به خواننده منتقل شود که امیدوارم این نوشته به این هدف دست پیدا کرده باشد.

نکاتی برای بهینه‌سازی عملکرد کد در لوآ

توسط | مقالات فنی

لوآ۱ بخش زیادی از محبوبیت و شهرت خود را مدیون عملکرد و کارایی خود است تا جایی که خیلی از زبان‌های اسکریپت‌نویسی دیگر برای معرفی خود از عبارت “سریع و کارا مانند لوآ” استفاده می‌کنند. با این حال، کارایی یکی از المان‌های مهم برنامه‌نویسی است که هنگام کار با زبان لوآ هم باید به آن توجه کرد. « آیا عملکرد برنامه‌ی من نیاز به بهینه‌سازی دارد؟ » اولین سوالی است که ذهن برنامه‌نویس را در خصوص بهینه‌سازی عملکرد به خود مشغول می‌کند. اگر جواب این سوال مثبت باشد سوال بعدی و کلیدی که مطرح می‌شود این است : « کجای برنامه‌ی من نیاز به بهینه‌سازی عملکرد دارد؟ ». برای زبان لوآ، افراد متعددی روی بهبود عملکرد برنامه‌ها و ابزار‌های اندازه‌گیری آن تمرکز داشته‌اند و با توجه به نتایج بدست‌ آمده، نکاتی را برای بهبود عملکرد برنامه‌های نوشته شده با لوآ پیشنهاد می کنند. در این نوشته سعی دارم بخشی از این نکات را با شما به اشتراک بگذارم.

استفاده از متغیر‌های محلی

پیش‌کامپایلر۲ لوآ با توجه به داشتن ثبات‌۳های زیاد می‌تواند تمام متغیر‌های محلی۴ را در ثبات‌های خود نگه دارد. به همین دلیل، دسترسی به متغیر‌های محلی در لوآ بسیار سریع است. برای نمونه فرض کنید متغیر‌های a و b محلی هستند. یک گزاره مانند a = a + b ، دستورالعمل زیر را تولید می‌کند:

حال اگر دو متغیر سراسری۵ باشند، کد برای یک عمل جمع ساده به صورت زیر خواهد بود:

 

این مثال ساده نشان می‌دهد که چرا استفاده از متغیر‌های محلی یکی از پرطرافدارترین پیشنهادات برای بهبود عملکرد برنامه است. با توجه به ساختار‌ها و قابلیت‌های زبان لوآ می توان توابع را نیز در متغیر‌های محلی ذخیره نمود. این‌کار نیز تاثیر خوبی در عملکرد برنامه دارد. به تکه کد زیر توجه کنید:

در کد بالا ،با یک تغییر ساده و استفاده از متغیر محلی برای تابع محاسبه سینوس می توان تا ۳۰ درصد سرعت اجرا را افزایش داد:
 

در هر حال ممکن است شما در کد خود به متغیر‌های سراسری نیاز داشته باشید. در این‌صورت حتماً هر جا که دیگر نیازی به آن‌ها نداشتید آن‌ها را با nil مقدار‌دهی کنید تا به زباله۶ تبدیل شوند زیرا زباله جمع‌کن۷ در زبان لوآ، متغیر‌های سراسری را به عنوان زباله نمی‌شناسد.

استفاده از دستورات کوتاه درون خطی به جای توابع هنگام کار کردن با جداول

زبان لوآ برای کار با جداول۸، توابعی را پیش بینی کرده است. یکی از این توابع، تابع insert است که برای اضافه کردن المان جدید به جدول استفاده می‌شود. ابزار‌های اندازه‌گیری مختلف نشان داده‌اند که استفاده دستورات کوتاه درون خطی در تعداد بالا معمولا عملکرد بهتری نسبت به تابع از پیش تعیین شده برای اضافه کردن عضو به جدول دارند زیرا دستورات درون خطی معمولاً عملگرهای زبان لوآ هستند و بار زیادی را ایجاد نمی کنند. در حالی که استفاده از تابع insert در ساده ترین حالت، نیاز به دسترسی به ماژول table و سپس فراخوانی تابع insert از این ماژول و محیط آن دارد. به دو نمونه کد زیر توجه کنید:

 
 

کد دوم، عملکرد بهتر و سریعتری نسبت به کد اول دارد. لازم به ذکر است که کد بالا را می توان با استفاده از یک عملگر ساده‌تر نسبت به #، به حالت بهینه‌تری بازنویسی کرد:

 

ملاحظات در عملگر ها و توابع ریاضی

در لوآ مانند خیلی از زبان‌های دیگر، برخی عملگر‌های ریاضی سریع‌تر از عملگر‌های دیگر رفتار می‌کنند. به عنوان مثال بهتر است که از عملگر ضرب به جای تقسیم استفاده کنیم:

 

عملگر ضرب از عمگر توان هم کارا‌تر است. در توان‌های پایین می توان از ضرب استفاده کرد:

 

سخن آخر

تمامی پیشنهادات بالا وقتی کاربردی خواهند شد که برنامه‌نویس ابتدا به دو سوال اول این نوشته پیرامون بهینه‌سازی کد پاسخ داده باشد. قطعاْ هر برنامه‌ای با توجه به ساختار‌ها و شرایط ویژه خود نیازمند بهینه‌سازی‌های خاص خود است ولی در نهایت نکات بالا به طور عمومی می‌تواند برنامه‌نویس را به سمت برنامه‌نویسی بهینه‌تر با زبان لوآ هدایت کند. نکات بالا برگرفته از کتاب الماس‌های برنامه‌نویسی با لوآ۹  و همچنین برخی تجربیات شخصی من بوده است. شما هم اگر تجربه متفاوت یا نکات مفید دیگری در این راستا دارید، حتماً با من به اشتراک بگذارید.


۱ – Lua
۲ – Pre-Compiler
۳ – Register
۴ – Local Variables
۵ – Global Variables
۶ – Garbage
۷ – Garbage Collector
۸ – Tables
۹ – Lua Programming Gems, edited by L. H. de Figueiredo, W. Celes, R. Ierusalimschy

 

 

لوگوی مور - سامانه رتبه‌بندی لینکدین

معرفی سامانه‌ی مور – رتبه‌بندی متخصصان ایرانی در لینکدین

توسط | خبرها

هیچ وقت کنجکاو شده اید که چه کسانی دیگری در ایران، در حوزه‌ی کاری شما و یا بخشی که به آن علاقه دارید متخصص هستند؟ قطعا زمانی که به صورت موردی با افرادی در این زمینه‌ها آشنا شده‌اید، از طریق شبکه اجتماعی/تخصصی لینکدین، ارتباط خود را با آنها قوی تر کرده‌اید و چه بسا این آشنایی به یک همکاری بلند مدت منتهی شده باشد.

سینا بهارلویی، یکی از اعضای چابک تاد اقدام به راه اندازی سیستمی نموده است که اطلاعات حساب‌های لیندکین را در یک مکان جمع آوری می‌کند و میتوانید متخصصان یک حوزه را بر اساس میزان تخصصشان، بیابید. با استفاده از «مور» متخصصان میتوانند با همکاران جدید و کارفرمایان میتوانند با افراد جدیدی که با مجموعه شان همخوانی دارند آشنا شده و تماس بگیرند. مور اطلاعات خود را از صفحه‌ی عمومی پروفایل کاربران در لینکدین جمع آوری می‌کند و بر روی تخصص‌های Endorse شده تمرکز می‌کند. این سامانه در حال حاضر به صورت آزمایشی راه اندازی شده است و نیازمند نظرات شما برای ارتقا می‌باشد. در صورت نیاز با ایمیل moor@todco.ir در ارتباط باشید.

http://moor.todco.ir

نسخه ی آزمایشی «پرسیتی» منتشر شد!

توسط | خبرها

بازی زیبای پرسیتی (شکوه شهر پارسی)

تهران، ۱۵ اسفند ۱۳۹۴ – پرسیتی (Per.City)، دومین محصول استودیوی بازی‌سازی تاد (تولید کننده‌ی بازی فروت کرفت)، در کافه بازار برای دستگاه‌های اندرویدی منتشر شد.
پرسیتی یک بازی تفننی در سبک شهرسازی است که شما را به دوران هخامنشی برای زنده کردن پادشاهی پدریتان میبرد. عمق زیاد در محتوا و جریان بازی از طرفی و کیفیت طراحی المان‌های گرافیکی از سوی دیگر پرسیتی را نسبت به دیگر بازی های ایرانی متمایز میکند. از برداشت گندم، تولید آرد و پخت نان تا ساخت یک عمارت بزرگ همه و همه به دست بازیکنان سپرده شده است تا تجربه‌ی اداره و مدیریت دهکده فعلی و شهر آینده خود را داشته باشند و توسعه‌ی اقتصادی و تجارت را تجربه کنند.

منصور جوادی مدیر تولید این بازی میگوید: «در قالب یک تیم پنج نفره بیش از یکسال و نیم بر روی این بازی کار کرده ایم. برای طراحی نقشه‌ی بازی و المان‌های گرافیکی بارها خودمان را ملزم کرده‌ایم که کارهای انجام شده را کنار گذاشته و از نو شروع کنیم تا به کیفیت مطلوب و شایسته‌ی کاربران ایرانی برسیم»
پرسیتی رایگان است و برای برخی از بخش‌های بازی، قابلیت خریداری الماس جهت سرعت بخشیدن به عملیات ساخت و ساز را فراهم کرده است. این بازی به دو زبان انگلیسی و فارسی طراحی شده است و به زودی نسخه‌ی ۱ (نسخه‌ی پایدار) خود را برای علاقه مندان منتشر خواهد کرد.

پرسیتی را از کافه بازار دریافت کنید.
سایت بازی: http://per.city
کانال تلگرام: https://telegram.me/percity
ایمیل: hello [at] per [dot] city

از چه ابزاری برای تولید برنامه موبایل استفاده کنیم؟

توسط | مقالات فنی

این روزها که بحث نوشتن برنامه های موبایل داغ است، بسیاری به فکر تولید اپ و ایده هایی هستند که به صورت بازی یا برنامه‌ی موبایل به دیگران عرضه کنند. این سوال عموما مطرح می‌شود که برنامه‌ی مورد نظر را با استفاده کدام تکنولوژی یا کدام ابزار باید تولید کرد؟ آیا بهتر نیست از ابزارهایی که به صورت همزمان برای آندروید و iOS خروجی می‌دهند استفاده کرد؟ آیا استفاده از این ابزارها هزینه تولید را کاهش میدهد یا چالش‌های دیگری نیز به همراه دارد؟ هدف این نوشتار، آشنایی شما با اکوسیستم موبایل و انتقال تجربه‌ی توسعه با ابزارهای مختلف و مقایسه‌ی خوبی‌ها و بدی‌های آنهاست تا به برخی از سوالات فوق جواب داده شود.

سهم هر یک از پلت فرم‌های موبایل در حال حاضر مطابق نمودار زیر در جهان است:

سهم آندروید و آی-او-اس و ویندوزفون در بازار

مطابق این نمودار نمیتوان به یکی از این پلت‌فرم ها بسنده کرد و در صورتی که مشتریان زیادی از برنامک/اپ ما در یک پلت فرم استقبال کنند، بهتر است با تولید اپی با همان کارایی در پلت فرم های دیگران، از دیگر جوامع کاربری موبایل هم استفاده کرد.

چه ابزارهای استانداردی عرضه شده است؟

برای نوشتن برنامه های هر سیستم عامل موبایل، ابزارهای استانداردی از سوی شرکت های مادر معرفی شده است. اگر پلت فرم‌های اصلی را آندروید شرکت گوگل، iOS شرکت اپل و ویندوزفون شرکت مایکروسافت بدانیم، به ترتیب ابزارها و زبان‌های برنامه نویسی زیر جهت تولید برنامه از سوی این شرکت ها معرفی شده است:

سیستم عامل محیط توسعه زبان برنامه نویسی سایت رسمی توسعه دهندگان
آندروید Android Studio یا Eclipse Java developer.android.com
iOS Xcode Objective-C یا Swift developer.apple.com
ویندوزفون Visual Studio  عموما #C dev.windows.com 

هنگامی که از تکنولوژی های اصلی هر سیستم عامل برای تولید برنامه استفاده میکنیم، اصطلاحا از ابزارهای بومی (یا Native) بهره برده‌ایم که در واقع سیستم‌عامل مورد نظر با بهترین سرعت ممکن و بیشترین میزان هماهنگی از نظر امکانات و ظاهر برنامه را اجرا خواهد کرد. راه حل‌های جایگزین دیگری نیز برای تولید برنامه موبایل وجود دارد که برخی از ویژگی های ذکر شده‌ی اپ های بومی (Native) را ندارند.

چه ابزارهایی برای خروجی همزمان روی چند پلت‌فرم وجود دارد؟

ابزارهای تولید نرم افزار موبایل برای چند پلت فرم Xamarin Appcelerator

این دسته از ابزارها هر یک با نگاه خاصی به حل این مساله پرداخته اند که با نوشتن یک برنامه‌ی مشترک، خروجی همزمان برای دو یا چند سیستم عامل ایجاد شود. با توجه به میزان استفاده از کد بومی و روشی که پیش گرفته‌اند می‌توان آنها را به دو دسته تقسیم کرد:

۱- ابزارهای ترکیبی (Hybrid) با استفاده از HTML5 و Adobe Air

با ورود HTML5 و پشتیبانی مرورگرهای موبایل از این استاندارد، و از طرفی معرفی Adobe Air برای موبایل، این ابزارها تلاش نموده اند تا با استفاده از همان تکنولوژی هایی که بر روی مرورگرها وجود دارد یعنی HTML, Flash, CSS و JavaScript برنامه هایی طراحی کنند که به دلیل استاندارد بودن نحوه نمایش صفحات طراحی شده با HTML5، این صفحات بر روی دستگاه های مختلف به یک شکل و به صورت همزمان قابل مشاهده خواهند بود. این ابزارها حتی با پیوند زدن Javascript با امکانات بومی دستگاه، امکان استفاده از امکانات دستگاه مانند دوربین، موقعیت مکانی GPS و امکانات ارتباطی ایمیل و پیامک را به برنامه‌های نوشته شده می‌دهند. نمونه‌های موجود عبارتند از:

ردیف نام لینک
۱ Sencha Touch https://www.sencha.com/products/touch
۲ PhoneGap http://phonegap.com
۳ SAP http://go.sap.com/developer.html
۴ Kony http://www.kony.com/products/mobilefabric
۵ Adobe Air  http://www.adobe.com/devnet/devices.html

استفاده از این ابزارها به کسانی که با ابزارهای توسعه‌ی وب سایت ها آشنا هستند، این امکان را میدهد که با استفاده از همان دانش بتوانند ساخت برنامه موبایل نیز را انجام بدهند. از طرفی به دلیل استاندارد نسبی بین موتورهای نمایش صفحات HTML ظاهر نسبتا ثابتی بین پلت فرم های مختلف نمایش داده می‌شود.

از آنجایی که اکثر پلت فرمهای موجود بر پایه HTML5 یا Flash (به استثنای Starling) از امکانات افزایش سرعت سخت‌افزاری استفاده نمیکنند، معمولا عملکرد کند تری نسبت به برنامه های معمول دارند و برای برنامه هایی که نیاز به Performance بالا دارند مناسب نیستند. به همین جهت در حال حاضر اکثر برنامه های تولید شده توسط این ابزارها، شامل نمایش محتوا و یا پر کردن فرم های درخواست می‌شود.

۲- ابزارهایی که خروجی بومی می‌دهند

ابزارهای این دسته راه حل های بسیار پیچیده تری را در پیش گرفته اند تا بتوانند برنامه هایی با ظاهر بومی هر سیستم عامل تولید نمایند و از سرعت و هماهنگی ظاهر که برای برخی از پروژه‌های موبایل الزامی هستند بهره ببرند.

Xamarin تلاش می‌کند تا از چارچوب .NET استفاده کرده و زبان برنامه نویسی مشترکی بین دو پلت فرم آندروید و آی-او-اس ایجاد نماید تا توسعه دهندگان به جای یادگیری دو زبان برنامه نویسی Java و Objective-C به صورت مشترک با زبان #C اقدام به نوشتن برنامه‌های خود کنند. بنابراین به صورت عمده بهره‌ای که در استفاده از این ابزار گرفته می‌شود، این است که هنگام ساخت نرم افزارهای آی-او-اس، توابع و کتابخانه‌های ارایه شده توسط شرکت اپل در زبان #C قابل دسترسی و اجرا می‌شوند. به عنوان مثال برای نمایش یک پیام به کاربر (Alert View) قطعه کدهای زیر را مشاهده کنید:

Objective-C (iOS)
 Xamarin C# (iOS)
Java (Android)
Xamarin C# (Android)

در تجربه‌ای که با ابزار Titanium یا Appcelerator داشتیم، به این نتیجه رسیدیم که برای برنامه‌ای مانند یک سیستم پخش موسیقی که نیاز به شخصی سازی (Customization) زیادی دارد، استفاده از این پلت فرم دست توسعه دهنده را می‌بندد و به حالتی منجر می‌شود که می‌بایست تعداد زیادی افزونه (Plugin) به زبان بومی iOS و آندروید نوشته شود که کارایی های دلخواه و شخصی شده را ارایه بدهد. بنابراین نه تنها توسعه دهندگان تیم شما می‌بایست به محیط Titanium مسلط باشند، بلکه بابت نیازهای خاص ایجاد شده می‌بایست بر محیط توسعه بومی iOS و آندروید نیز تسلط به دست بیاورند.

۳- چارچوب‌های ساخت بازی

بازی ها به دلیل ماهیت شان و اینکه به المان های سیستم عامل وابستگی چندانی ندارند، بهترین گزینه برای خروجی گرفتن همزمان بر روی چند پلت فرم هستند. تکنولوژی های مورد نیاز برای بازی های دو بعدی و سه بعدی در موبایل اکثرا در انتها به استفاده از OpenGL باز میگردد که API های مشابه و مستقل از سخت افزار اکثر آن را تشکیل می‌دهد. به همین دلیل ابزارهای خروجی همزمان بسیار در این زمینه موفق عمل کرده اند و موتورهایی نظیر Unity و UDK در سال های اخیر توسط بسیاری از توسعه دهندگان بازی های مستقل (Indie) مورد استفاده قرار گرفته است. تعدادی از موتورهای بازی سازی با امکان خروجی همزمان در فهرست زیر معرفی شده اند:

نام زبان برنامه نویسی توضیحات
۱ Unity #C مناسب برای بازی‌های دوبعدی و سه بعدی
http://www.unity3d.com
۲ UDK UnrealScript مناسب برای بازی‌های سه بعدی

http://www.unrealengine.com

۳ CryEngine  Lua مناسب برای بازی های سه بعدی با امکان خروجی برای کنسولها و PC

http://www.crytek.com/cryengine

۴ GameMaker  GML http://www.yoyogames.com
۵ Cocos2d-X  Lua, C++, JS مناسب برای بازی های دوبعدی و موبایل

http://www.cocos2d-x.org

۶ Corona SDK  Lua

مناسب برای بازی های دوبعدی و موبایل

رایگان، نسخه فروشی در صورت نیاز به افزودن کتابخانه‌های بومی

https://coronalabs.com/products/corona-sdk

چه زمانی از ابزارهای خروجی همزمان استفاده کنم؟

جواب به این سوال، به نیاز شما و نوع برنامه‌ای که تولید می‌کنید بستگی دارد!

اگر بازی تولید میکنید: قطعا استفاده کنید! چارچوب های تولید برنامه برای چند پلت فرم در تمام آنها عملکرد بسیار مشابه دارند و با تغییرات اندکی می‌توانید برای هر پلت فرم خروجی مورد نظر خود را بگیرید. اگر بازی خود را با Android-SDK شرکت گوگل تولید کنید، برای iOS مجبور خواهید بود بسیاری از ساختارها رابازنویسی کنید اما استفاده از چارچوب های خروجی همزمان و موتورهای بازی مانند Unity به شما کمک میکند با کمترین تغییرات بازی خود را برای پلت دوم و سومی خروجی بگیرید.

اگر یک اپ ساده برای ارایه محتوا تولید می‌کنید: از چارچوب‌های خروجی همزمان با HTML5 استفاده کنید. این چارچوب‌ها ارایه‌ی محتوا را بسیار ساده کرده‌اند و محتوای شما به یک شکل در پلت فرم‌های مختلف دیده می‌شود. اگر با ActionScript یا فلش از قبل آشنا هستید، Adobe Air گزینه خوبی برای شماست.

اگر یک اپ با UI زیاد تولید می‌کنید و می‌خواهید آن را تا حد زیادی شخصی‌سازی (Customize) کنید: در استفاده از چارچوب‌های Native شک نکنید، استفاده از چارچوب‌های خروجی همزمان در بسیاری موارد مانعی بر سر راه شما برای شخصی سازی المان‌های نمایشی و UI هستند.

اگر یک اپ با UI عادی اما حجم کد منطق و پردازشی زیاد تولید می‌کنید: استفاده از ابزارهای خروجی همزمان مانند Xamarin به شما کمک می‌کند که بخش هایی از نرم افزار که به دریافت، پردازش و نگهداری اطلاعات می‌پردازد را یک بار توسعه بدهید.

بخش پنهان و خاموش برنامه های موبایل را فراموش نکنیم!

بسیاری از بازی ها وبرنامه هایی که امروزه استفاده میکنیم، اطلاعات را در خود دستگاه ذخیره نمیکنند بلکه با یک ارتباط اینترنتی خدمات را ارایه میدهند و پشت صحنه‌ی آنها، یک سرور مرکزی برای جمع آوری، نگهداری و تحویل اطلاعات وجود دارد. این مقاله به تکنولوژی های مربوط به نوشتن برنامه‌ی موبایل یا Client پرداخته است، اما اگر سیستمی که به دنبال پیاده سازی آن هستید نیاز به بخش Server دارد، می‌بایست تکنولوژی های سمت وب از جمله PHP، ASP.NET و Ruby و یا Python را هم بررسی کنید که عموما برای تولید سرویس دهنده ها مورد استفاده قرار میگیرند.

Gauge yourself as a leader

توسط | مقالات فنی

An effective leader is someone who empowers followers to make visions into reality.

Leading is a responsibility, and the effectiveness of this responsibility is reflected in the attitude of those being led. These attitudes consist of four dimensions which make up empowerment.

I’ve extracted a few key points from one of my favourite books ‘Leaders – by Warren G Bennis & Burt Nanus’, that clarifies this subject whigh can provide you with the key points that you need to pay attention to when evaluating your effectiveness as a leader.

۱- Significance:
When people feel that they are making a difference in the organisation or the outside world (in most cases customers). Effective leaders are able to create a vision that gives followers the feeling of being at the heart of things and that what they do has effect on somebody or something. In short, that they are in some way significant. Being able to create a compelling vision and communicating it along with communicating each person’s role in making that vision into reality are key here.

۲- Competence:
Meaning development and learning on the job. The feeling that you are learning something, gaining mastery over your job and improving your performance. Employee growth/training programs, regular feedback are key here.

۳- Community:
A feeling of family, joined in some common purpose. This doesn’t necessarily mean liking one another, but rather a sense of reliance on one another toward a common cause.

۴- Enjoyment or fun:
Through empowerment workers seem to get so immersed in their game of work that they forget basic needs for long periods of time. This fun doesn’t mean playing foosball in the office, but rather from enjoyment of doing the work itself. See here for more on this.

For the third and fourth one its easy to identify an environment with these qualities, but a bit harder to consciously create. In my experience this can be done through providing a desirable vision, focusing on performance goals and creating a collegial environment of trust and cooperation.

I would love to hear your opinions on these subjects and your ideas on how we can improve ourselves as leaders.