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 долара (истински пример) и си продаваш готовата библиотека, ако имаш добра оценка на проекта, а както казах без лесен досег до класовете, няма слава... Така че можеш и е наложително да го правиш. особено ако искаш да си топ, а ние сме топ в това даскало. 

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

Единствено по въпроса мога да добавя следното:
"Има ли желание, има и начин."

Ако искаш да пишеш чисто ООП в Unity - никакъв проблем. Ако не ти се занимава да разучаваш нова технология заедно с ООП-то -> търсиш си алтернативи, които те устройват. Всеки сам си избира хорото, на което да се хване. От тук нататък спора е просто излишен.

Обади се най-накрая човека, който работи с Unity :) Благодаря ти.

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

Прочетете статията на Джоел Сполски "the law of leaky abstractions". През телефона съм и нямам как да я линкна сега.

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

Не знам как ще научи някой OOP с триъгълници и лихви да смяташ за пореден път. По-добре ООП игра. Идва ти отвътре.