Софтуерно Инженерство
Loading...
+ Нов въпрос
nakov avatar nakov SoftUni Team Trainer 5456 Точки

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

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

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

21
C# OOP Basics
RoYaL avatar RoYaL SoftUni Team Trainer 6883 Точки

Ей, същото казах още 1вата вечер като се събрахме с отбора :) Радвам се, че и от другата страна на барикадата мислят така :)

5
HPetrov avatar HPetrov 822 Точки

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

В крайна сметка много зависи от това, какво иска отбора да сътвори и от това, колко се разучава какво можеш и какво не можеш да избегнеш от нова технология.

5
D_N_D avatar D_N_D 18 Точки

В условието пише:

" The game can be console-based or written using some kind of a Graphical User Interface (e.g. Unity, WPF, Windows Forms, Swing, AWT, Java FX, etc.)"

Ако не ползваме Unity или конзола (понеже на конзолата ще е бая грозно и съм 100% сигурен, че комисията ще реже точки за това, ...), какви опции ни остават? И за 2 седмици изобщо какво може да се направи from scratch? 

 

Който иска да ми отговаря, аз така си питам риторично ...

8
kasskata avatar kasskata 492 Точки

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

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

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

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

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

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

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 SoftUni Team Trainer 6883 Точки

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

3
oconne avatar oconne 113 Точки

За пръв път се докосвам до Юнити, но горе долу добих няква представа. 

Пързалката за която предопреждава Наков е напълно реална. Увличането по готовите сценарий състоящи се от примерно от двайсетина скрипта публикувани в нета (и ние като допишем още 20) няма да доведе до добър резултат (да не говорим за научаване на ООП), даже на места да можем да направим и демонстрираме йерархични модели. Проектът трябва да е консистентен (да има общ автономен Модел) и да следва логиката на задачта в заданието.

 Възможно ли е все пак да се стартира от нулата, отговора на моят рисърч е да статия. Юнити съдържа в себе си цялата програмна логика за рисуване, дизайн, и моделиране, но това е съизмеримо с кошмар, ако трябва да спазиш 20 дневн срок и да постигнеш ефектно представяне. Ако искаме да създадем цялостен автономен  Модел, трябва да почнем от EmptyObject който да наследява и някъв деифиниран от нас абстрактен клас или интерфейс съдържащ методa за рисуване (който най вероятно ще делигира права на Унити машината да рисува в някои от следващите нива на абстракция в зависимост какво сме измислили ). Например тук в тази статия е показано рисуване-процедура:статия. Да не говорим че Юнити подържа GL. Въобще въпроса за ООП не е ясно дефиниран в Юнити и подлежи на много уговорки и компромиси.

В този смисъл искам да попитам, може ли да използваме ASSETS, като допълнителен ресурс, върху който да изградим нашият "UML" Model. Ще направим  например класически за това интерфейс IDrow с метод Drow(), който да се наследи от абстрактен клас DrowGameObject iи допълнителна имплемантация там ако се нуждаем, после в класа HeroKiborg ще имаме метод Drow(){return new prefabObject()} Същото за осталите роли на героя и въобще другите геймобжектс . Може ли да се направи този компромис? Или изискването е чист код без никакви ресурси като assets. Или въобще да бъде зададена някаква ясна рамка?

0
07/10/2014 11:21:28
RoYaL avatar RoYaL SoftUni Team Trainer 6883 Точки

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

2
oconne avatar oconne 113 Точки

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

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

 

0
07/10/2014 12:22:24
RoYaL avatar RoYaL SoftUni Team Trainer 6883 Точки

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

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

2
07/10/2014 12:58:45