زندگی، فلسفه، تکنولوژی صنعت <- اندیشه ها، احساسات

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

یک روز خسته از بازی و حرف و درس و ... از مدرسه به خانه آمده بودم که یادم نیست برای نصب چه برنامه ای از همسایه مان یک CD گرفتم که در آن مجموعه ای از برنامه ها نصب بود. CD متعلق بود به یک خدمات کامپیوتری به نام شمیم و درونش برنامه ها با یک فایل readme انگلیسی قرار داشتند. درونش یک برنامه بود به اسم Game Maker 6 که در readmeش نوشته بود، می توانید با این برنامه بازی بسازید. من هنوز خیلی برنامه نویسی بلد نبودم و هنوز انگلیسیم هم چندان تعریفی نداشت اما کنجکاو شدم. من از کودکی همیشه بازی کرده بودم و به بازی خیلی علاقه داشتم. تا آن روز انتخاب هایم از روی نخواستن بود و کمی از روی علاقه. نخواستن، یعنی انسانی نمی خواستم و به ریاضی علاقه داشتم پس به آن رشته فکر کردم. حدود سال سوم راهنایی در شبکه آموزش دیدم فردی پاسکال درس می دهد (حلقه repeat until) و برنامه factorial می نویسد. تا قبل از آن فقط می دانستم برنامه نویسی هست و برایم هیجان انگیز بود ولی آن روز آن درس را یاد گرفتم. من هنوز کد پاسکال و حتی دلفی ننوشته ام و الآن هم چیزی از پاسکال نمی دانم. بعد ها متوجه شدم همسر پسر عمه ام که به تازگی ازدواج کرده بود برنامه نویس است، در سفری یکی دو روزی با او صحبت کردم و به کامپیوتر علاقه پیدا کردم. به هنرزستان رفتم و تا روز یافتن آن CD فقط می دانستم به برنامه های اداری علاقه ندارم و باید برنامه دیگری بنویسم. مثلا نرم افزار مهندسی و یا IDE/compiler ... وقتی کمی با آن برنامه کار کردم فهمیدم به آن علاقه دارم.

چند ماه بعد که بیشتر کلاس زبان رفته بودم، یکی از معلم هایمان به من گفت که اگر آزمایش های درس فیزیک سال های دبیرستان را به شکل interactive پیاده کنم، آن ها را از من خواهد خرید (هر کدام 50000 تومان :) ) با سینا دوستم صحبت کردیم و دوباره به سراغ Game Maker رفتم و این بار با انگلیسی بسیار بهتر سریع خیلی چیزها را یاد گرفتم. آن پروژه سریع کنسل شد اما دیگر دیر بود و ما آلوده شده بودیم. بعد ها با چیز های مختلفی مثل FPS Creator, Dark Basic, 3d game studio و ... آشنا شدیم. با 3d game studio مقادری کار هم در سال اول دانشگاه کردیم و بعد از آن با یونیتی آشنا شدیم و همچنین با فردی که از یک کشور خارجی به ایران آمده بود و می خواست برای ساخت یک بازی یا سایت یا برنامه یا ... روی ما سرمایه گذاری کند. پول زیادی نبود و همه اش خرج خرید لایسنس یونیتی و ساخت مدل شد و ما بدون گرفتن پول سعی کردیم یک MMO کشاورزی برای Facebook بسازیم. چیزی شبیه Harvest Moon ولی به شکل MMO که شکست خوردیم.

این ها اصل مطلب نیست، پس از آن هم کار ما ادامه پیدا کرد و هر یک در جایی به کار های مختلف پرداختیم ولی چرا من بازی ساز شدم؟ چرا به سراغ کارهایی که احتمال پول در آوردنش بیشتر بود نرفتم؟ چرا کاری که همه می کردند را نکردم؟ دلیلش این بود که اولا می خواستم خودم چیزی بسازم و خلق کنم، می خواستم هیجان در کارم باشد و چیزی که می سازم ، اثری باشد که بتوانم به آن عشق بورزم و با جان و دل دوستش داشته باشم. می خواستم خودم بتوانم بفروشمش. این کار قبلا خیلی سختتر بود. وقتی app store رسمی Apple برای iPhone تولید شد، حدودا 20-21 سالم بود. هنگام تولید کافه بازار هم سن پدر بزرگ انوشیروان دادگر بودم. وقتی ما شروع به کار کردیم بازار های ممکن، فروش بازی در ایران بود (که به خاطر وجود بازی گرشاسپ خیلی غیر ممکن به نظر نمی رسید، الآن انتشار بازی فیزیکی در ایران طقریبا غیر ممکن است). فروش در Facebook بود که آن موقع ها سر و صدای زیادی به پا کرده بود. فروش در فروشگاه های خارجی و یافتن پابلیشر و همچنین فروش بازی تبلیغاتی به شرکت ها که ما سعیی هم برای آن کردیم. من اولین بازیم را به شرکت گلرنگ و برای وب سایت آن ها فروختم. بازی برای ایران و با حجم زیر 300 کیلو بایت تولید شده بود و روی web player یونیتی اجرا می شد.

چرا در این شرایط ما به این رویا دل بسته بودیم؟ ما در ابتدا حتی از وجود بازی سازان دیگر خبر نداشتیم. بازی های آقای پویا دادگر را دیدیم ولی ایشان را نمی شناختیم و چیزی که در دبیرستان دیدیم بازی اولشان بود که کیفیتش چیزی بود که ما در نادانی کودکیمان به نظرمان خیلی خوب نیامد و به شدت هیجان زده نشدیم. الآن درک می کنم که چه شجاعت شگفت انگیزی داشته اند و چه مردی بوده اند. در دوره دانشگاه توسط یک هم دانشگاهی با پروژه گرشاسپ آشنا شدیم و با سازندگان بازی که بلاگ هایشان را خواندیم و با ایمیل با آقای فصیحی در ارتباط بودیم (ولی تا 2-3 سال بعد ایشان را ندیدیم). در ذهنمان اصلا چیزی جز بازی سازی نبود. ساخت برنامه اداری و کار برای شرکت های بزرگ برایمان (با ذهنیت ما)اشتباه به نظر می رسید. به میزان سختی کار فکر نمی کردیم. به این فکر می کردیم که چه کاری از بازی سازی می تواند جالبتر باشد. بازی سازی کاری است پر از خلاقیت، دنیایی می سازی که قبل از تو نبوده است و روحت را در آن می ریزی و به گونه ای اثر تو با خودت یکی است. کاری است با مسایل فنی بسیار عمیق و سخت و جذاب و مسایل هنری و حسی فوق العاده. اکنون فقط در باره طراحی بازی (game design) و نوشتن برنامه های لازم صحبت می کنم زیرا هرگز کارهای هنری بازی را به شکل حرفه ای انجام نداده ام. بازی ساختن به شگفتی ساخت نرم افزار خلق دنیایی مجازی را نیز اضافه می کند. نرم افزار ساختن به خودی خود خیلی شگفت انگیز است. ما مثل مهندسین دیگر محدود به قوانین مربوط به فیزیک موادی که با آن ها کار می کنیم نیستیم و فقط محدود به زمان و پیچیدگی برنامه مان هستیم. نرم افزار چیزهای غیر ممکن را ممکن کرده است و اگر به آن خلق دنیا های جدید را بیفزاییم. این حقیقت دارد که با ساخت یک بازی هم می توان نظرات و اندیشه هایمان را در قالبی هنری به دیگران نشان دهیم، هم کسب درآمد کنیم و هم از انجام کاری عمیق و چالش برانگیز لذت ببریم.

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

۱۵ شهریور ۹۶ ، ۱۲:۰۲ ۰ نظر موافقین ۰ مخالفین ۰
اشکان سعیدی مزده

اهمیت شگفت انگیز فلسفه در تکنولوژی

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

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

اگر خوب نگاه کنید، در  C++, Erlang  و ... ویژگی های خاصی را می یابید. سازندگان Erlang به تحمل خطا و Fault Tolerance می اندیشیدند و در نتیجه تمرکز زبان بر روی این موضوع است. CPU از Process ها به شکل خودکار گرفته می شود. سعی بالایی برای کم کردن احتمال Crash در VM شده است و همه کتابخانه های متعلق به Erlang بر روی Scalability و Fault Tolerance متمرکز هستند. در مقابل در سی پلاس پلاس تمرکز بر روی نزدیکی به سخت افزار، وجود کنترل کاملبر روی همه چیز و پرداخت هزینه فقط برای چیزهایی است که استفاده می کنید. همچنین تمرکز بالایی روی کارایی و performance وجود دارد و در نتیجه کتابخانه های بدون allocation و بسیار پیچیده و با کارایی بالا در اطراف آن زیاد یافت می شود.

این موضوع در مورد Unity, Unreal Engine, Nodejs, Orleans, F#, Linux و ... نیز صدق می کند. فقط کافی است سعی کنید از این زاویه به این تکنولوژی ها نگاه کنید تا فلسفه پشت آن ها را در یابید. گاهی هم باید کمی علوم کامپیوتر و تاریخ آن را بشناسید. به این دلیل من فکر می کنم بسیار مهم است فلسفه چیزی که شما می سازید به تکنولوژی مورد استفاده شما نزدیک باشد. این موضوع باعث می شود که چیزی که شما می سازید هم شکل درستی داشته باشد. در IBM و Google تحقیقاتی در رابطه با میزان productivity افراد هنگام کد زدن با زبان های مختلف انجام دادند که نشان داد نوشتن کد در C می تواند به اندازه نوشتن کد در Python سریع باشد.  این موضوع مطلبی جدا از این است که آیا با Python هم شما می توانید برنامه ای به کارایی برنامه C بنویسید و اگر پاسخ مثبت است ، این کار چه قدر زحمت دارد. من فکر می کنم هنگام نوشتن سرور یک بازی RealTime که قرار است بسیار سریع باشد، اگر از تکنولوژی هایی استفاده کنید که با تمرکز بر روی این موضوع ساخته نشده اند و قابلیت های پایه آن ها بر این موضوع متمرکز نیست یا شما فلسفه اشتباهی را دنبال می کنید و متوجه موضوع اصلی مورد تمرکز نیستید و به تحقیق بیشتر نیاز دارید و یا کارتان با تکنولوژی مورد نظر به مشکل خواهد خورد.

مثلا شما می توانید با C کد gameplay بنویسید ، البته برای سادگی بهتر است کامپایلر یک نسخه ساده از C را طراحی کنید. می توانید با NodeJs یک برنامه بسیاری سریع scalable و distributed بنویسید در صورتی که ساختار ها و abstraction های لازم را در یک پلاگین با سی پلاس پلاس پیاده کنید. اما در این صورت شما با C و NodeJs کار نمی کنید. از خیلی از ابزار ها و دانش موجود در جامعه کاربران زبان نمی توانید استفاده کنید و باید برای خود یک سری استاندارد و ساختار و framework مخصوص داشته باشید. فیسبوک کد PHP محدود خود را که به سی پلاس پسال کامپایل می کند به این شکل تولید می کند. نوشتن این کد PHP شبیه همه کد های PHP بیرون فیسبوک نیست. چون فیسبوک شرکتی بسیار بزرگ با برنامه نویس های بسیار خوب است می تواند این کار را راحتتر از بقیه انجام دهد و عملا هم بیشتر کد خود را دیگر با PHP نمی نویسد. در مقابل وقیت شما با Erlang نرم افزار سرور و با سی پلاس پلاس Game Engine می نویسید، احساس می کنید در خانه خود هستید و همه تکنولوژی به سمت درستی جلو می رود و همه به زبان شما صحبت می کنند و همه ابزار ها قابل استفاده هستند و کار شما بسیار با کیفیتتر و بهتر و سریعتر جلو می رود. علاقه مندم نظرات شما را در این باره بدانم.

حتی در نرم افزار هایی مثل سیستم های عامل و رویکرد شرکت ها هم می توانید این موضوع را ببینید. معمولا دید و فلسفه افراد سازنده کاملا شکل دهنده اکوسیستم یک نرم افزار خواهد بود. دلیل توجه فراوان به رابط کاربری و طبیعی بودن همه چیز در OSX و سیستم عامل های قدیمی Apple دید خود استیو جابز و افراد اصلی دیگر در Apple بودند. من شک دارم استیو جابز هرگز می توانست یک برنامه خشک مهندسی با تمرکز روی performance را که قرار است کار خاص خطرناکی را انجام دهد رهبری کند و در مقابل شک ندارم او در توانایی نسل بعد نرم افزار های ارایه محتوی در دوران social network ها و یا شاید سخت افزاری خاص برای کار با آن ها و زندگی در این دوره یکی از بهترین گزینه ها بود. این موضوع در باره افراد دیگر و فلسفه هایشان هم از نظرم صادق است. فکر می کنم ما باید هنگام انتخاب تکنولوژی فلسفه و قابلیت های اصلی تکنولوژی را با چیزی که می خواهیم بسازیم مطابقت دهیم و هرگز از تکنولوژی هایی که برای کارهای متفاوت از نظر ویژگی های اصلی هستند برای کار های نا مربوط استفاده کنیم. وقتی می گویم هرگز، بدین دلیل است که همواره با سیستمی sub-optimal رو به رو خواهیم بود که دلیل ساخته شدنش به روشی خاص آشنایی ما با یک تکنولوژی یا علاقه کورکورانه بوده است.

یک بار ما در MuchDifferent به علت آشنایی اعضای شروع کننده یک پروژه سرور licensing برای تمام محصولاتمان، با PHP و Python ، این سرور را با PHP و یک بار با Python نوشتیم و برای سریع کردن آن به حد نیاز باید کارهای خاصی می کردیم و از کش استفاده می کردیم و ... اما همین سرویس با ASP.NET بر روی Owin توسط افرادی دیگر به سرعت نوشته شد و کاملا جواب گوی تعداد درخواست ها بود و لازم نبود ما برای سریع شدنش کار خاصی نیز انجام دهیم. بسیاری افراد با Django سایت های بسیار بزرگ می نویسند و حتی API می نویسند ولی به طور کلی DJango برای ساخت سایت های forms over data و line of business و ... مناسب است و برای بالا رفتن سرعت باید از cache و تکنولوژی های دیگر استفاده کرد. در مقابل کد دات نت بسیار سریعتر بوده و شما به شکل پیش فرض از یک ORM نه چندان سریع استفاده نمی کنید و راه های زیادی برای سرعت بخشیدن به پاسخ گویی سرور وجود دارد که ساخت یک web service بسیار high performance را خیلی ساده تر می کند. شاید کسی در Python با زحمت فراوان و بدون استفاده از Django بتواند همین کار را بکند، اما آن وقت دیگر از سادگی های Django استفاده نکرده است و لزوما از سادگی های Python برای پروژه های کوچک هم بهره نبرده است. این فلسفه من است و تا به حال از آن سود فراوانی برده ام و دوست دارم نظرات دیگران را نیز در کامنت ها بدانم.

۱۴ شهریور ۹۶ ، ۱۶:۴۶ ۰ نظر موافقین ۰ مخالفین ۰
اشکان سعیدی مزده

Abstraction چیست و کجا از آن استفاده کنیم؟

برای بررسی مفهوم abstraction و information hiding که به پنهان کردن پیچیدگی های بخشی از یک سیستم از بخش های دیگر گفته می شود، و اعتبار آن باید ابتدا نوع نرم افزاری که می نویسیم را مد نظر داشته باشیم. یک مقاله خوب در باره کاربرد مناسب information hiding در بخش خوبی از نرم افزار ها http://www.stevemcconnell.com/ieeesoftware/bp02.htm می باشد. نویسنده مقاله ، همچنین نویسنده کتاب بسیار عالی Code Complete می باشد که دید شخص بنده را به برنماه نویسی تغییر داد و آن را به همه پیشنهاد می کنم.
انواع مختلف نرم افزار عمر های متفاوتی دارند و از ویژگی های متفاوتی نیز برخوردار هستند. برای مثال نرم افزار های شاتل های فضایی عموما بدون هیچ تابعی نوشته می شوند و چند هزار خط کد پشت سر هم هستند (زیر 5 هزار خط). دلیل این کار نیاز به مشخص بودن دقیق تمام کارهایی است که اتفاق می افتد. در این گونه نرم افزار ها این است که هر خواننده ای بتواند بدون رفتن به تابع دیگری یا ... بداند کد دارد دقیقا چه کاری انجام می دهد. بازی ها نوع دیگری از نرم افزار هستند که معمولا عمر نسبتا کوتاه چند ساله دارند و کد آن ها در آینده خیلی مورد استفاده قرار نمی گیرد. به این دلیل خیلی از مسایل مربوط به آماده سازی کد برای تغییرات شدید در آینده در آن ها صورت نمی گیرد. همچنین چون بازی ها در لایه نزدیکتری نسبت به سخت افزار سیستم نوشته می شوند تا performance بهتری داشته باشند، خیلی از کارهایی که در نوشتن نرم افزار های اداری مناسب هستند در آن ها قابل پیاده سازی نیستند. در مقابل برخی نرم افزار های اداری بیش از 50 سال سن دارند و در طول زمان تغییرات فراوانی می کنند.

از نظر من، پنهان کردن پیچیدگی ها پشت توابع جذابترین نوع information hiding می باشد زیرا شما بدون پرداخت هزینه زیادی کد را بسیار خواناتر و بسیار قابل تغییرتر می کنید. در مقابل قرار دادن برخی بخش های برنامه پشت abstraction های مختلف مثل interface ها هیچ سود خاصی ندارد زیرا در صورت تغییر آن بخش نوع رویکرد شما با آن نیز تغییر می کند. تکنولوژی WCF به شدت از این مشکل رنج می برد و برنامه نویس هایی که در تمام توابع به جای برگرداندن یک نوع collection خاص (مثل آرایه یا لیست) یک نوع عمومی (مثل IEnumerable در .NET) را برمی گردانند نیز با این مشکل روبه رو هستند. واقعیت این است که اگر لیست شما به صف یا پشته تبدیل شود ، نوع کارکرد شما و دید شما به آن تفاوت شدیدی خواهد کرد، شما می توانید با یک لیست کتاب در فروشگاه به عنوان یک abstraction برخورد کنید ولی درون این ماژول یا کلاس یا ... باید دقیقا مساله لیست کتاب ها را با توجه به ساختمان های داده مورد استفاده حل کنید. هر برنامه در نهایت یک سری ورودی و یک سری تابع برای تغییر داده ها و ارسال داده ها به خروجی است و به جز این تغییرات هیچ ارزش دیگری ندارد. ما در دنیای واقعی زندگی می کنیم و در حال تلاش برای حل مسایل واقعی روی سخت افزار های واقعی هستیم و همیشه نمی توانیم این مسایل را به مسایلی abstract تبدیل کنیم و خیلی اوقات خیلی از ما این حقیقت را فراموش می کنیم. هنگامی که شما از IEnumerable استفاده می کنید، هنگامی که از Linq استفته می کنید ، تعداد زیادی memory allocation و virtual method call اضافه دارید که می توانستید نداشته باشید. اگر یک وب سایت ساده می نویسید که روزی 300 نفر از آن بازدید می کنند، این مساله اهمیتی ندارد اما اگر در حال ساخت کتابخانه ای برای دیگران هستید، اگر یک نرم افزار high performance یا نرم افزاری برای سرور و یا سخت افزار های کوچک و ضعیف می نویسید باید به این مسایل دقت کنید. من ترجیح می دهم هنگام نوشتن ساده ترین نرم افزار ها هم کار خود را به بهینه ترین شکل ممکن برای حل مساله واقعی پیش رویم انجام دهم تا با مصرف کمتری از منابع ، کار خود را به شکل بهتری انجام داده باشم. اصلا پیشنهاد نمی کنم که برای بهینه کردن برنامه هایی که نیاز ندارند دنبال optimize کردن تمام خطوط باشید بلکه پیشنهاد می کنم به جای نوشتن ابزار و به نوعی compiler و general problem solver سعی کنید مساله پیش روی خود را حل کنید مگر این که دلیلی برای حل مساله ای کلیتر وجود داشته باشد. خیلی وقت ها واقعا شما در حال مساله ای کلی هستید اما خیلی وقت ها این طور نیست. فراموش نکنید خیلی وقت ها تغییرات مورد نظر شما با تغییر یک interface و پیاده سازیش امکان پذیر نیستند، مثلا اگر شما به جای TCP از UDP استفاده کنید و یا به جای SQL Server از Riak به عنوان پایگاه داده استفاده کنید، نمی توانید تمام مسایل مربوط به این تغییرات را پشت یک interface پنهان کنید و خیلی وقت ها رویکرد شما در بخش های مختلف برنامه با این تغییرات نیاز به تغییر خواهد داشت. به این دلیل خوب است اول فکر کنیم که آیا باید برای انجام کاری از abstraction ها استفاده کنیم یا خیر.

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

۱۴ شهریور ۹۶ ، ۱۱:۴۶ ۰ نظر موافقین ۰ مخالفین ۰
اشکان سعیدی مزده

پست اول و دلیل ساخت بلاگ

11 سال من در دوره دبیرستان پس از آشنایی با نرم افزار Game Maker 6 با بازی سازی آشنا شدم و از آن روز به بعد تمام زندگی حرفه ای و بخش خوبی از زندگی غیر حرفه ایم را در ارتباط با ساخت بازی سپری کرده ام. برای شرکت های مختلف تولید بازی و ابزار های ساخت بازی (میان افزار یا همان Middleware) و ... کار کرده ام و چند بار سعی کرده ام با افراد مختلف و یا به تنهایی شرکتی تاسیس کنم و یا پروژه ای را بسازم. این بلاگ را برای به اشتراک گذاشتن اندیشه هایم و اندک تجربه ام و چیز های جالبی که با آنها آشنا می شوم، ساختم.
به طور مفصلتر ، امروز تو دفتر یکی از دوستان و همکاران در حال صحبت بودیم که به من پیشنهاد ساخت یک بلاگ شخصی فارسی رو داد. من در گذشته پست در gamasutra و بلاگ شخصی خودم ashkasm.blogspot.com و بلاگ های شرکت هایی که در اون ها مشغول بودم زیاد نوشتم (این بلاگ شخصی انگلیسی زیاد پست ندارد اما تعداد زیادی پست در بلاگ های دیگر نوشته ام) اما به علت وجود نداشتن جامعه بزرگ بازی سازی در کشور و مشغولیت های مختلف پز از پایان سال های اول دانشگاه و پاک کردن اول بلاگ خودم در blogfa دیگر بلاگ فارسی ننوشتم.

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

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

۱۳ شهریور ۹۶ ، ۲۱:۰۴ ۳ نظر موافقین ۰ مخالفین ۰
اشکان سعیدی مزده