Let me agree to disagree. Може Unity да ти позволява много неща, да е написан много качествено и зад имплементацията му да стоят едни от най-великите умове, в което не се съмнявам, но това не спомага за писането на този ООП код, който се шири по книгите за качествено обектно ориентирано програмиране.

Това е все едно да кажеш, че можеш да си направиш Web application-а с качествено ООП, като си го билднал през CMS. Еми, можеш, да, това което ще покажеш пред широката публика сигурно ще бъдат dummy класова, логически послеводателно свързани един с друг и със съответните dependency-та, но ще се опиташ да скриеш останалия boilerplate код, на който разчиташ.

Заигравал съм се съвсем леко с Unity, и съм ходил по някое-друго семинарче, така че нямам най-богатия опит от първо лице. Това, което видях, обаче беше, че можеш от UI-а да кажеш, че имаш Играч, и на Играча да му сложиш като депенденси - точки, примерно. И когато пиква обекти от картата - точките да му се увеличават.

Юнити ще създаде за теб цялата тази логика, ще инжектне депенденситата и ти ще имаш два обекта - Точка и Играч. И в момента, в който решиш, че Точките могат да са Златни и Сребърни ще започне да рейзва проблема ти.

Имаш вариант или през UI-а да създадеш още един вид точка, който да атачнеш към плейъра и после да извършиш сумиране или да се опиташ да направиш наследници на класа Точка.

Първото е по-безболезнения вариант и възможно най-неправилния от към ООП стандарти.

Вторият, обаче, ще те прати в едно друго измерение, в което ще отделиш дни четене на билд-ин методите в Unity за да видиш къде и в кой се случва интеракцията с точките, къде ти е event loop-а, къде минаваш точно през обекта Точка и къде минаваш през интерфейса за елементи на енджина, кога да провериш дали пикнатия обект от картата е такъв, че да ти увеличи златните точки, или такъв, че да ти увеличи - сребърните.

Първо, че това което ще се случи, няма да е най-правилния начин - подобни неща да се случват в методи с имена от сорта на Run() и второ, че няма да успееш да имплементираш достатъчно стабилен полиморфизъм, а по-скоро ще резултираш в if (something is Gold)

Сигурен съм, че има вариант всичко а е изпипано и да се пише близко до перфектното ООП, също така съм сигурен, че ще се наложат хиляди прокси класове и методи, за да се постигне това, с цел да се изолира логиката на Unity с тази на твоите обекти. Също така съм сигурен, че никой начинаещ в ООП-то не може да научи едновременно енджина и самата парадигма и да я приложи и то в отбор, за оставащото време до презентацията.

Аз не се чувствам толкова confident, че ще направя нещата добре с Юнити и смятам да не го избирам като технология. :)

Мда има доза истина в твоите думи , Ванка(особено в началото :D), но можеш да правиш OOP, въпросът е там, че не е толкова силно качеството, както би било в един банков проект. Това е чисто забавление и пари. Нека да не забравяме, че геймъра му се дава компилиран код в екзе и една папка трудно разбираема. а и през интерфейса няма да си смени удара на оръжието или да стане безсмъртен, ако не му дадеш копче. Демек капсулацията отпада. Не че не можеш да го правиш и би било по-добре да го правиш.

Но всичко е в сила от там нататък. Представи си че правиш World of Warcraft, колко пъти трябва да създадеш едно оръжие, ако няма IWeapon и абстракни методи: Staff,dagger, sword, gun etc. Сега след като се запознах с Unity по-надълбоко(макар и за 5 дена)вече си представям какво им е на големите фирми в такъв случай. Невъзожно е, ако не сe подготвиш за ООП.

Unity са ти дали мощен engine, но всичко останало си остава за теб. И от тук нататък се включваш и правиш един собствен engine за създаване на ... FPS например. А добра библиотека без ООП забрави, брат. Пускаш я за 200 долара (истински пример) и си продаваш готовата библиотека, ако имаш добра оценка на проекта, а както казах без лесен досег до класовете, няма слава... Така че можеш и е наложително да го правиш. особено ако искаш да си топ, а ние сме топ в това даскало. 

Нека не забравяме, че тук критериите са други, а не просто .ехе-то :) Аз съм голям фен на принципа - това което се продава - това правиш. Та, да, ако трябва да продавам на клиента си веднъж .ехе-то на играта, няма да му се старая много от към красота на кода, щом той търси бързодействието и качеството на продукта. Но тук ролите са обърнати, и СофтУни в ролята си на клиент, е поставил изисквания - не геймплей, не бързодействие, не качество на продукта - а качество на неговия код. Т.е. представи си все едно клиента ти, вместо много яка и шарена игра, иска да му продадеш неработещ, но красив и шарен код. Това се иска от теб - това правиш. Това се продава :) За това смятам, че не си заслужава ползването на юнити.

Не е работа на HeroKiborg да рисува :)

Аха, да правилно. Добре де ще го преотстипим на на някой друг клас. Идеята е дали можем да постъпим по някъв подобен начин?

Само да допълня: Ако обектите не се саморисуват, тогава вече навлизаме в дълбоки води, нужно ли е да е толкова висока летвата?

Това е проблема на използването на такава абстракция, че ще трябва да влезеш в дълбоки води, за да пишеш качествено ООП. Иначе е нужно да бъде правилно ООП, т.е. отговорността да се делегира на конкретно отговорните обекти.

Ако се абстрахирам от Unity си представям нещата, че трябва да имаш един обект ВЪРХУ който се рисува, съответно хващаш депендант обектите му, да речем обекта Map има обекта Player и рисуваш Player на определена позиция и запомняш къде си го нарисувал. Ако трябва да го преместиш, го рисуваш на нова позиция и запаметяваш това. Player обаче от своя страна не е наясно, че е нарисуван някъде. Той всъщност, не би трябвало, като цяло, да е наясно, че може да бъде рисуван. Той трябва да е просто API. И от където и да бъде достъпван - конзолата, графична среда, HTTP Request, да отреагира по един и същ начин. Уж, според книжките за правилно ООП, ако някой ден решиш да смениш средата и примерно от графична игра я направиш конзолна, трябва да може да ползваш абсолютно същите обекти и само глобалния гейм обект да е конзола (Strategy Pattern maybe?). Или ако решиш да смениш графичната библиотека/енджина, отново да може да ползваш обектите си без да променяш нищо по тях.