Loading...
nakov avatar nakov SoftUni Team Trainer 5295 Точки

ООП & Unity - препоръки

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

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

21
C# OOP Basics
kasskata avatar kasskata 492 Точки

Г-н Наков,  не се притеснявайте. В Unity има толкова ООП колкото и извън него. Единствената разлика е, че трябва да осъзнаем, че всеки обект в играта е обект(като малки Майн методи), който изпълнява КЛАСОВЕТЕ, които вече се правят като допълнителни файлове и се използват като класове както сме правили до сега. 

Съвет от мен: Направете си ПРИМЕРНА клас диаграма, за да можете да гледате голямата картинка, ще мoжете да допълвате нови класове и нови променливи, пропъртита, конструктори, методи. 

След като сте готови с голямата картинка МОЖЕТЕ спокойно да създавате 123541 оръжия , защото имате клас оръжие, 2137852148765 врагове защото имате клас враг. 

Проблемът идва от това, че Unity e направено прекалено интелегентно и не ти трябват много класове за да се справиш с проблемите на играта. 

Ние вече имаме готов човек, терен и particle systems за куршуми и съм в най-добрия отбор EVЕR така че ще се видим на защитите ;)

5
06/10/2014 20:46:27
RoYaL avatar RoYaL Trainer 6849 Точки

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, че ще направя нещата добре с Юнити и смятам да не го избирам като технология. :)

 

2
kasskata avatar kasskata 492 Точки

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

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

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

1
07/10/2014 00:29:44
RoYaL avatar RoYaL Trainer 6849 Точки

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

3
HPetrov avatar HPetrov 822 Точки

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

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

1
kasskata avatar kasskata 492 Точки

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

0
07/10/2014 01:38:52
RoYaL avatar RoYaL Trainer 6849 Точки

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

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

1
kasskata avatar kasskata 492 Точки

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

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

0
Можем ли да използваме бисквитки?
Ние използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Можете да се съгласите с всички или част от тях.
Назад
Функционални
Използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Използваме „сесийни“ бисквитки, за да Ви идентифицираме временно. Те се пазят само по време на активната употреба на услугите ни. След излизане от приложението, затваряне на браузъра или мобилното устройство, данните се трият. Използваме бисквитки, за да предоставим опцията „Запомни Ме“, която Ви позволява да използвате нашите услуги без да предоставяте потребителско име и парола. Допълнително е възможно да използваме бисквитки за да съхраняваме различни малки настройки, като избор на езика, позиции на менюта и персонализирано съдържание. Използваме бисквитки и за измерване на маркетинговите ни усилия.
Рекламни
Използваме бисквитки, за да измерваме маркетинг ефективността ни, броене на посещения, както и за проследяването дали дадено електронно писмо е било отворено.