Дата | Видеоурок | Результат | |
---|---|---|---|
Теория ООП Интерфейс. VIP. Тяжёлая дружба кругов и квадратов. | + 20 | ||
Реализовал игру "квадратики играют с кружочками" по своему Разобраться с типами и придумать концепцию реализации У меня квадратики играют с кружочками в virusGame. Единственное что не доделал - квадратики не отталкиваются от кружочков и зона действия функции касания для квадрата определена поперечными размерами квадрата ( касание не засчитано если задет только угол и вскользь) . А так работает)) |
|||
Теория ООП Интерфейс. VIP. Пересечение прямоугольников. | + 20 | ||
Реализовал игру "квадратики играют с кружочками" по своему Разобраться с типами и придумать концепцию реализации У меня квадратики играют с кружочками в virusGame. Единственное что не доделал - квадратики не отталкиваются от кружочков и зона действия функции касания для квадрата определена поперечными размерами квадрата ( касание не засчитано если задет только угол и вскользь) . А так работает)) Этот отчёт будет идентичен следующему так как задание выполнено досрочно. |
|||
Теория ООП Интерфейс. VIP. Квадратики тоже хотят играть. | + 20 | ||
не знаю ничего Игра virusGame для квадратиков |
|||
Теория ООП Интерфейс. ФИНАЛЬНЫЙ УРОК. | + 20 | ||
Не знаю, тут суть уже не в изучении чего-то нового, а в придумывании алгоритма. Заставить всё работать как надо. Классная серия !) Для себя ООП я скорее не изучил, а закрепил (Раньше долго и нужно изучал на c++) . Но были и новые нюансы , которых я не знал. Что такое интерфейс я не знал. Сейчас имею хотя бы общее представление. Думаю нужно написать ещё много проектов с их использованием, чтобы вникнуть полноценно. Так с любой темой. Следующий курс для себя я пока не определил. Планирую восстановить изучение в направлении web-разработки. Восстановить ранее полученные знания и учиться, учиться, учиться... Есть много чего интересного и кажется уже не угонишься за прогрессом. Разве что если выбрать одно направление в программировании и чисто над ним сидеть... В любом случае спасибо Евгению Витольдовичу за этот курс!) Было занятно) |
|||
Теория ООП Интерфейс. Создаём новую игру. | + 20 | ||
Созданию своей игры метод findNewLeader ениеКак и было предложено реализована игра, в которой лидерство меняется от красных к чёрным шарикам и наоборот по факту наличия оставшегося одного не заражённого шарика - он и становится новым шариком вирусом "вымирающего цвета". setLeader у меня нет , я всё делаю через сравнение цветов коснувшихся шариков в findLeader. Там идут двойной проход по списку игроков (чтобы взять каждого игрока и проверить не коснулся ли он другого) и потом сверяются их цвета. Если цвета разные - проверяется какая команда сейчас лидирует. Для этого в классе имеются две переменные типа bool rLead и bLead, имеющие всегда различные друг от друга значения. Можно было бы обойтись и одной, но так нагляднее и проще в написании кода. Собственно суть я вроде описал... |
|||
Теория ООП Интерфейс. Изменяем правила игры. | + 20 | ||
не знаю ничего Теоретически, это интерфейс , если сильно доработать, можно использовать в 3D версии настольного тенниса например.... Это как ответ на вопрос... |
|||
Теория ООП Интерфейс. Кружочки гоняются друг за другом. | + 21 | ||
решению поставленной задачи везде сложностей было по немногу . Выделить самое сложное не могу Я немного улучшил программу заставив шарики не иметь возможности появляться там, где уже стоит другой шарик - в следствии они не пересекаются при появлении. Ну а раз на то пошло я заставил их ещё и отскакивать друг от друга. Что же касается лимитации кол-ва кружков - просто при добавлении кружков я написал условие, чтобы список не содержал больше 20 элементов. |
|||
Теория ООП Интерфейс. Кружок готов к игре! | + 20 | ||
не знаю ничего нужна реализация алгоритма движения кружков |
|||
Теория ООП Интерфейс. Кружок хочет играть. | + 20 | ||
Пока ничего нового не было ничего Метод Run() для начала должен бы определять, является ли данный кружок лидером . Если да, то бежать за ближайшим кружком. Если же нет - бежать от лидера в направлении , в котором наибольшее расстояние до стены. Метод же Catched() должен сверять цвет ( если данный кружок синего цвета или красного цвета - он уже был пойман , если же чёрного - пойман не был ) |
|||
Теория ООП Интерфейс. Запускаем кружки на площадку! | + 20 | ||
Не уверен что могу ответить на этот вопрос ничего Засунул кружки в список для возможности дальнейшей работы с пересечением кружков (при добавлении будут проверятся все имеющиеся кружки по координатам) , может это и лишнее, увижу потом |
|||
Теория ООП Интерфейс. Кружок на площадке. | + 20 | ||
не знаю ничего всё пока понятно |
|||
Теория ООП Интерфейс. Площадка для игры. | + 20 | ||
ничему ничего Класс арена нужен для размещения кружков и контроля над ними |
|||
Теория ООП Интерфейс. Создаём кружок. | + 20 | ||
ничему ничего для создания игры осталось нарисовать N кружков, написать алгоритм их передвижения |
|||
Теория ООП Интерфейс. Алгоритм игры. | + 20 | ||
ничему ничего Чтобы получилась игра , нужно добавить визуализацию , например движущимися объектами сделать рисунки со спрайтов предыдущих уроков. Также добавить алгоритм для перемещения "игроков" и связать всё это добро вместе. |
|||
Теория ООП Интерфейс. Правила игры. | + 20 | ||
Пока ничему ничего setNewLeader должен быть вызван как только предыдущий лидер коснулся другого (координаты совпали, если рассматривать как точку. setNewLeader лишь присваевает leader = player , и заставляет всех снова бежать. findNewLeader должен бы, по хорошему , вызываться в начале игры, когда лидер не определён. Выбирается рандомное число от 0 до кол-ва игроков, и потом вызывается setNewLeader(player [ сгенерированное число]); |
|||
Теория ООП Интерфейс. Зачем он нужен. | + 20 | ||
Созданию интерфейса ничего На сколько я понял, интерфейс - это сет public методов, свойств и событий , как бы инструкций и составных частей, которые испульзуются классами и реализуются непосредственно для каждого класса использующего его. |
|||
Теория ООП ПОЛУФИНАЛЬНЫЙ УРОК. | + 20 | ||
На этих ведеоуроках я закрепил полученные ранее знания по ООП , а также изучил несколько тонкостей С#. Спасибо за этот замечательный курс, он мне помогает более досконально внедряться во всю так-сказать пучину ООП))) Составление отчёта Александр Новицкий |
|||
Теория ООП Перемещение Снеговиков | + 20 | ||
Установке таймера подбор интервалов вы хотели усы в движении )) |
|||
Теория ООП Перемещение других фигур | + 20 | ||
Изменению методов draw наверное ) ничего КАк-то так) |
|||
Теория ООП Перемещение круга | + 21 | ||
Добавлять событие ничего я немного добавил кнопок)) |
|||
Теория ООП Спрайт для Снеговика | + 20 | ||
Использованию списка (List) в C# Ничего особо сложного, но и не всегда всё очевидно, нужно было подумать над переделыванием инициалиации graphics мыши желают вам добра |
|||
Теория ООП Мощь полиморфизма | + 20 | ||
имплементации концепта полиморфизма на вышеуказанных методах всё сделать правильно )) спасибо за классный урок |
|||
Теория ООП Переезд graph в базовый класс | + 20 | ||
реализации вышеуказзанных методов ничего всем добра |
|||
Теория ООП Переезд метода Draw | + 20 | ||
не знаю ничего всем добра |
|||
Теория ООП Приведение с мотором | + 20 | ||
Использованию typeof и getType ничего При реализации Draw через полиморфизм переменную shape.position можно будет добавить в override-ные Draw в качестве слагаемого к координатам при вызове graphics.DrawLine/Circle и т.д. |
|||
Теория ООП Фигуральный базовый класс | + 20 | ||
Пока ничему ничего сложного, просто перемезаем и всё Draw реализовать можно через полиморфизм, добавив виртуальный метод базовому классу , а затем использовать override Ещё , чисто гипотетически , можно попробовать помучать typeof с if , пересматривая тип, и для каждого типа написать свою строку по рисованию, но это как-то неэстетично |
|||
Теория ООП Богатое наследство | + 20 | ||
Я использовал наследование ещё раньше, так как было лень писать повторяющийся код ничего Моё мини определение наследования : наследование - это один из трёх основных компонентов ООП , позволяющий передовать свайства/параметры родительских классов классам наследникам что влечёт за собой сокращение кол-во кода, используется для создания скажем подвидов (например класс мышь мог бы быть наследником класса животное) , позволяет не переопределять медоды класса наследника, а лишь дополнять их при необходимости (классу мышь можно добавить в методе еды, что она может есть ещё и зёрнышки). |
|||
Теория ООП Второй Снеговик | + 20 | ||
Использовать наследование Ничего сложным не было Предполагаю, что чтобы перемещать, поворачивать или изменять размер наших изображений, их нужно поместить в некоторые прозрачные контейнеры, а потом добавить eventListener-ы и присобачить их к работе со свойствами контейнеров. |
|||
Теория ООП Рисуем Снеговика | + 20 | ||
Тут мы просто закрепляли полученные ранее знания )) Ничего особо сложного. Главное координаты подобрать Всем добра |
|||
Теория ООП Цветные карандаши | + 20 | ||
Ничему Ничего Я создал доп классы и не стал заморачиваться на рисунке. Нарисовал будку справа от домика. |
|||
Теория ООП Расстояние между пикселями | + 20 | ||
Ничему. Просто создал доп перегрузку методов как и раньше Ничего На снимке выделен перегруженный метод, использующий метод distance. Новую окружность создавать не стал, а просто нарисовал старую при помощи новоиспечённого метода ) |
|||
Теория ООП Пиксели для классов | + 1 | ||
Мспользованию :this( ) для того, чтобы не переписывать один и тот же код. Ничего. Как называется эта операция(или как это назвать) с использованием :this() ? |
|||
Теория ООП Структура vs Класс | + 20 | ||
Узнал что такое out, его различие с ref. Узнал о синтаксисе передачи ссылок в C#, а также о нюансах их использования с классами и структурами. Ничего. Вместо режима отладки показал пример различий в консоли. Таким образом показав несколько основных примеров в одном месте. Также благодаря использованию консоли всё удалось поместить на одном screenshot-е ) Не судите строго. Если использование режима отладки принципиально - могу сделать неск. screenshot-ов в режиме отладки. |
|||
Теория ООП Структура пикселя | + 20 | ||
Созданию структуры под названием "Pixel" Ничего Был удивлён, что тут в структуре нужно обязательно указывать модификаторы доступа (В c++ можно не указывать , по умолчанию в struct стоит public. |
|||
Теория ООП Круглый класс | + 20 | ||
Рисовать окружность Рисование параллелограмма ))) Всё хорошо) |
|||
Теория ООП Второй класс | + 20 | ||
Ничему Ничего Всем добра) |
|||
Теория ООП Первый класс | + 20 | ||
По сути ничему... Всё это было известно из курса ООП по c++ Оказывается , в c# нельзя передавать константные ссылки на объекты как в c++ и ещё там было много мелких неувязок основанных моей самодеятельности... Всё норм) |
|||
Теория ООП Урок рисования | + 1 | ||
Рисовать домик) Ничего Прикольно) Осталось оттточить навык) |
|||
Теория ООП Инкапсуляция мечты | |||
Пока ничему Ничего Инкапсуляция - это возможность проектирования объектов таким образом, чтобы конечному пользователю были доступны лишь действия, связанные с public методами данных объектов, в то время как внутри класса недоступные пользовател. методы и переменные скрыты под идентификатором private. |
|||
Демо софт Вступительное слово | + 21 | ||
Созданию отчёта Ничего Первый урок уже понравился) Давно искал что-нибудь похожее на этот сайт |
|||
Нано-игры Арканоид - Уровень и ракетка | |||
|