Знатоки теперь на Кью! Присоединяйтесь к новому сервису ЯндексаПерейти

Программирование

Не могу освоить верстку — 21 ответ

Здравствуйте. Очень давно пытаюсь освоить верстку, но никак не выходит. Много пересмотрел видео на ютубе, перечитал книг(понимаю, что впитывал воду). Не могу, не выходит ничего, аж руки опускаются. Курсы от htmlacademy купить не могу, средства не позволяют(школьник, не имею такую сумму, к сожалению). Уже нервы не к черту, на стены готов лезть. Что в таком случае делать? Не нужно советов типа "на ютубе очень много видео, учись!"(Просто не нужно таких советов, сам про него знаю). Что в таком случае делать?
21 человек оценил этот вопрос
Интересный вопрос
Дизайнер интерфейсов из Ozon отвечает на вопросы об интерактивном дизайне, UX, анимации и проектировании сложных систем.

То, что вы готовы лезть на стены ради освоения вёрстки, вызывает моё восхищение. Это говорит о высокой мотивации и любви к предмету. Чтобы освоить HTML и CSS, нужен такой план:

  1. Не изучать устаревшие материалы, забыть о существовании xHTML и ориентироваться только на современные стандарты HTML5 и CSS3. Понять, что в HTML5 теги бывают двух типов: парные и одиночные. Вёрстка состоит в основном из парных тегов и каждый тег имеет определённые доступные параметры и CSS-свойства по умолчанию. Бывают теги, которые отличаются только семантически: div очень похож на h1, у них просто разный набор свойств и нужно использовать их в разных ситуациях. Семантика — умение применять теги уместно.

Хорошая очень компактная книжка, которую я когда-то читал — Джереми Кит - HTML5 для веб-дизайнеров.

  1. Важных тегов, которыми надо уметь пользоваться, не так много: script, link, section+header+footer, div, span, h1+h2+h3, ul+li, a, form, input, table+tr+td. Все остальные можно подсмотреть на htmlbook.ru/html когда будет время и желание.

  2. Понять, что CSS не надо писать руками. Научиться работать с CSS-препроцессорами. Это сэкономит тонну времени. Мне нравится LESS, в моде сейчас SASS.

  3. Узнать наиболее употребимые CSS-свойства: float, display, opacity, width+height, position, background, border, border-radius. Заодно узнать, как использовать псевдоклассы: :hover, :focus.

  4. Разобраться в теме Flexbox-вёрстки. Полезно и развязывает руки.

  5. Поставить нормальную среду разработки, например Visual Studio Code (прекрасен+бесплатный) или WebStorm (любят знакомые), настроить в нём красивую цветовую схему и моноширинный шрифт Menlo покрупнее. Поставить на него плагин Emmet, который позволит меньше печатать HTML-кода. Такой мощный тулбокс будет мотивировать больше практиковаться.

  6. Понять, как реализовать адаптивность: узнать, как работают медиа-запросы. Научиться пользоваться сеткой Бутстрапа или другого фреймворка по душе. Понять, как верстать адаптивный 12-колонник. Сэкономить на этом вторую тонну времени, потому что на одних только медиа-запросах адаптивность реализовать очень больно.

  7. Познать контроль версий: завести Гитхаб, научиться выполнять простые операции: git init, status, log, add, commit, remote, push, diff. Все они есть в курсе по гиту на Хекслете. Степик тоже заслуживает внимания.

  8. Сразу пытаться применять изученное и ставить себе задачи, которые заставят задавать новые вопросы. Не терять наработки и вести конспекты в Notion. Так вы никогда не растеряете то, чему научитесь.

На этом уровне уже можно найти работу тысяч на 40. Идти сразу работать, а не тратить 5 лет на идиотский российский институт, как ваши одноклассники.

  1. Понять, что вёрстка — низшее звено веб-разработки и ваш путь только начался. Понять, что без знания JavaScript на вёрстке не заработать и пора учить его. Идти на сайт JavaScript.ru и становиться фронтенд-разработчиком.
Интересный вопрос
Кандидат физ.-мат. наук, делаю Яндекс, увлекаюсь всем на свете

Я пишу код уже больше 20 лет и, хотя в последнее время больше занимаюсь руководством, на пике формы был способен писать по 500+ строк хорошо работающего кода в день. Вот принципы, которые мне в этом помогали:

  1. Не переобобщайте. Если не получается малой кровью создать универсальное решение, то и неважно, решите конкретную текущую задачу и двигайтесь дальше. Обобщение, даже хорошее, в 70% случаев так и остается нигде больше не использованным.

  2. Не оптимизируйте код заранее. Идея усложнить код ради его ускорения почти всегда ошибочна. Исключение возможно только в том случае, когда именно этот участок код "тормозит" так, что это уже заметно на уровне продукта или бизнеса. "Пессимизировать" код тоже, конечно, не нужно, из двух версий, одинаковых по сложности и по объему кода, выбирайте более быструю. Из этого есть важное следствие: нельзя дублировать данные и нельзя кешировать результаты вычислений там, где этого не требует во весь голос производительность. Больше половины структурных багов возникает из-за того, что "разъехались" кэш и реальные данные, причем еще и отлаживать такое обычно адски сложно, потому что в момент собственно "разъезжания" никакого бага еще не видно, он проявится потом, когда ставить breakpoint-ы и проходить исполнение по шагам уже поздно.

  3. Называйте и группируйте всё происходящее правильно. Код, в котором нет алгоритмических или технологических сложностей, должен читаться как текст, написанный по-английски. Хорошо, когда код, в котором ниндзя куда-то крадётся, выглядит как-то вроде ninja.sneak(...), а не pDst2.trySetCoord(...) и ещё десять строчек после этой, ни одну из которых нельзя забыть. Если функция что-то меняет в состоянии объекта, она не может называться isSomething -- если так сделать, следующий же код с её участием обречён на интересный дебаг. Если функция что-то трудно вычисляет, она не может называться getSomething -- кто-нибудь наверняка начнёт вызывать её в цикле и удивляться, почему всё тормозит. Класс, который хранит состояние документа, может называться DocumentState или Document, но никак не SDManager. Кстати, про Manager-ов. Если единственное название, которое вы можете выбрать для класса или метода, получается очень расплывчатым, это верный признак того, что вы делаете что-то неправильно. Классы BaseObject и World или функции databaseOps и initService быстро приведут к самым разным проблемам и багам, связанным с нарушениями этого и предыдущего пунктов.

  4. Не смешивайте алгоритмы и другие технологически сложные участки кода с бизнес-логикой. Выразительности современных языков программирования вполне достаточно для того, чтобы, скажем, графический движок компьютерной игры ничего не знал о ниндзя и вертолётах, функции работы с БД в CRM-системе не знали слов "счёт" и "клиент", и т.д. и т.п. Для бизнес-логики типичны постоянные изменения, нечеткость и путаница. Как только сущности с разных уровней абстракции начинают упоминаться в соседних строчках кода, , всё это тут же начинает проникать и в технологически сложный код, и всё взрывается.

  5. Не используйте никакие advanced фичи никакого языка. В С++, например, не стоит пользоваться темплейтной магией, переопределением операторов, множественным наследованием и т.д. и т.п. Экзотические языки программирования (Haskell, диалекты Лиспа, хитрые декларативные язычки, работающие поверх JVM) вообще стоит использовать только как хобби, источник вдохновения. Не напрямую в той работе, за которую вам деньги платят. Эта точка зрения часто вызывает споры. К сожалению, обстоятельно аргументировать её в формате ответа на Знатоках не получится. Поэтому просто сошлюсь на свой почти 20-летний опыт индустриального программирования. Во всех областях и организациях, в которых я успел поработать, что в Яндексе, что в разработке игр, что в науке идея использовать в качестве рабочего инструмента "красивый полёт свободной мысли, недоступный простым умам" оказывалась разрушительной. Часто и для всего проекта, но всегда, без исключений, для автора идеи.

  6. Стоит выкинуть из головы все ООП. Единственное полезное, что в императивные языки пришло из этой идеологии - модификаторы private. Иерархии классов это зло, наследовать реализации нужно себе запретить. Наследовать можно интерфейсы, и то не слишком много уровней. Агрегация почти всегда лучше наследования. Большая часть классических "шаблонов проектирования" уже либо устарела, либо нашла поддержку на уровне языка.

  7. Используйте как можно больше assert'ов, логов и прочих способов поймать незапланированное состояние системы как можно раньше. Очень часто в момент, когда неверное поведение системы становится заметно пользователю, дебажить её уже сложно. Если же вы смогли поймать систему именно в тот момент, когда её внутреннее состояние впервые становится неконсистентным или она начинает вести себя не так, как вы задумывали, чаще всего разобраться в том, почему, становится тривиально.

  8. Каждая лишняя строчка кода это зло. Там, где это вообще возможно, не стоит пользоваться чужим кодом, который вы не прочитали и не поняли от и до. Это касается в том числе и широко известных библиотек и фреймворков общего назначения. Чем меньше кода (включая и тот, который пишешь сам, и тот, от которого зависишь) - тем лучше.

  9. Граничные случаи стоит проверять "в голове" прямо по ходу написания кода. Например: я пишу list.back(), а почему этот список не пуст? Как я "доказал" к этому моменту, что этого не может произойти? Что сделает эта функция, работающая со строчкой, если она пуста?

  10. Любой баг, если он все-таки вам встретился, старайтесь возводить до первопричины и до общего правила. Что я написал в коде такого, что этот баг вообще оказался возможен? Как я могу поменять свои практики так, чтобы больше никогда не допускать таких же? Например, баг состоял в том, что я написал такую-то строчку в функции save и забыл добавить симметричную в функции load. Может быть, пора, наконец, заменить эту пару на одну функцию serialize? Обложить их тестами? Или хотя бы поклясться вслух самому себе, что никогда не будете трогать их по одиночке? Или, например, причина бага была в том, что в указателе pNeighbor содержится null, а программа этого не ожидает и падает. Можно просто воткнуть if (pNeighbor != null) и закрыть баг как исправленный. А где ещё в коде разыменовывается pNeighbor? Везде ли есть такая же проверка? Насколько вообще эта ситуация легальна, может быть, настоящая ошибка там, где pNeighbor впервые оказался нулевым? Если значение pNeighbor это результат отображения NULL из БД на объектную модель, то как этот NULL попал в БД, кто его туда положил и не стоит ли воткнуть там constraint? И т.д и т.п. Никогда не считайте, что ваш код уже идеален! Наблюдайте за собой, совершенствуйтесь, старайтесь работать вместе с людьми, у которых есть, чему поучиться.

Тема эта неисчерпаема, приёмов и приёмчиков можно вспомнить ещё много, но я, пожалуй, остановлюсь на этой десятке. Всем хорошего кода!

Интересный вопрос

Формально он, конечно, программирования, но не всё так просто :)

Аббревиатура расшифровывается как structured query language (структурированный язык запросов). Если быть точным, SQL - это декларативный язык запросов к данным в определённом типе баз данных (реляционном).

Что такое язык запросов?

Это язык, допускающий команды по выборке и модификации данных. Добавление строчек в таблицу, выборка определённых значений и их агрегатов (сумм, количества и т.п.). Среди наиболее используемых можно назвать команды выборки SELECT, вставки INSERT, удаления DELETE, обновления UPDATE.

Что такое декларативный?

В отличие от императивных C, Java и т.п., декларативные языки не позволяют напрямую описать алгоритм. При написании декларативного кода вы не пишете КАК вы хотите получить результат, но пишете КАКОЙ РЕЗУЛЬТАТ вы хотите получить (накладываете набор ограничений). Например, существует несколько способов запрограммировать выборку из таблицы всех мужчин старше 65 лет на Java, но на SQL вы просто напишете, например:

SELECT name, surname FROM people WHERE age > 65 AND gender = 'male'

Что такое реляционные базы данных?

Этот термин пришёл из дискретной математики, где слово RELATION (отношение) описывает некоторое подмножество декартова произведения. В терминах таблиц с фиксированными столбцами, можно считать, что любая конкретная таблица - это отношение (подмножество) на множестве всех возможных строк. Для таких объектов придуман специальный раздел математики - реляционная алгебра, который описывает допустимые операции над отношениями, а также выводит способы оптимизации запросов (вы можете написать очень неудачный запрос, но с помощью аксиом и теорем реляционной алгебры, он автоматически будет преобразован к более компактному и/или быстрому).

Интересный вопрос
Привет. У нас большая экспертиза в области вёрстки и тестирования веб-страниц. Работаем над повышением уровня качества вёрстки на рынке

Однако, далеко не все программисты могут стать менеджерами проектов. Многие программисты хорошо умеют делать свою работу и писать код. Менеджерство же подразумевает больше именно организационную работу, постановку и контроль задач.

Программисты чаще всего становятся тимлидами, то есть старшими разработчиками, которые отвечают за весь код конкретного продукта или нескольких продуктов, проводят его ревью и следят за общим качеством. При этом на таких проектах всё равно есть менеджер, которые ставит задачи и следит за их выполнением.

Путь когда менеджером становится тестировщик, намного экологичнее. По роду своей деятельность менеджеру приходится тестировать продукт на соответствие, а поэтому такой навык менеджеру необходим. При этом вырастить хорошего менеджера из тестировщика гораздо проще чем из хорошего разработчика.

Это не означает, что менеджерами не становятся хорошие разработчики, а только плохие. Просто даже хорошие разработчики когда-то перестают писать код и начинают заниматься чем-то другим и менеджерство отличный вариант.

Интересный вопрос
Мультидисциплинарный дизайнер — UX/UI, веб и диджитал

JS — своеобразный язык, в нём есть одна общеизвестная логическая ошибка (если будете изучать — узнаете), которую специально не исправляют для совместимости с предыдущими разработками на js. Сам js — создан для фронтенда и его код обрабатывается непосредственно браузером, но из-за повсеместной популярности, из него сделали и бекенд—версию. Плюс, для js создано большое количество всевозможных фреймворков, заточенных под разные задачи и облегчающие процесс кодинга

Интересный вопрос

Очень субъективное мнение: хороший программист умеет решать задачи "от и до", учитывать все возможные ограничения своего решения, последствия для разрабатываемой системы. О точно знает, что и почему он сделал. В первую очередь это зависит от широты специальных знаний.

Как максимально корректно выстроить взаимосвязь между объектами по имеющимся у них признакам, при этом расчеты не должны быть чрезмерными? — 1 ответ

Имеем некоторое N условных абстрактных объектов. N - конечное значение и не чрезмерно большое. Объекты появляются в поле нашего зрения в произвольные моменты времени и имеют один дополнительный признак в каждый момент появления. Признаки могут повторяться, могут все время быть одинаковыми для какого-то объекта, но могут и не быть таковыми. Количество признаков - конечное значение, но, теоретически, большее чем количество объектов. Условно можно составить такую таблицу: Объект_1 | дата\время появления_1 | Признак_1 Объект_1 | дата\время появления_2 | Признак_3 Объект_2 | дата\время появления_2 | Признак_4 Объект_3 | дата\время появления_2 | Признак_3 Объект_N | дата\время появления_Z | Признак_X (Объект_1 и Объект_3 в этом примере можно считать связанными с большой долей вероятности) Требуется установить наиболее устойчивые взаимосвязи между ОБЪЕКТАМИ, на основании ПРИЗНАКОВ. При этом нужно учитывать тот факт, что чем больше временное окно между появлениями двух объектов с одинаковыми признаками, тем менее вероятна связь между ними. Так же нужно учитывать тот факт, что один из объектов может в один и тот же временной интервал, условно, допустим, месяц, может появиться 300 раз, а другой объект - всего 1 раз. Естественно, связь между такими объектами весьма сомнительна, и может быть случайностью. Приветствуются любые идеи, но чем менее они ресурсоемки в плане нагрузки на вычислительную систему, тем лучше.
5 человек оценили этот вопрос
Интересный вопрос

Идея 1.

Дискретные признаки все вывести в one-hot encoding, числовые отнормировать, время тоже. Получим сколько-то мерный вектор для каждого объекта, при этом каждому признаку прикручено время. И дальше можно считать попарные разности векторов (евклидово расстояние, L1-норма), но с поправкой на временное расстояние. Условно (v1[i] - v2[i])^2 * (1 - (t1[i] - t2[i]))^2. Можно также натравить на эти векторы кластеризацию, например DBSCAN.

Идея 2.

Итерационные процесс - собрать объекты в мешки по признакам, а затем прореживать "мешки" в соответствии с эвристическим правилами (если вы имеете какое-то понимание о том, что значат те или иные признаки).

Интересный вопрос
8 лет помогаю ребятам начать карьеру в диджитал или получить новые навыки для ее развития, люблю шутить :)

Привет, стоит отметить, что в последнее время всё большую популярность для создания игр набирает среда Unity, которая лучше всего взаимодействует с C#.

Python в геймдеве он тоже пригодится. 2D и 3D-игры, простые квесты и RPG — это далеко не все, что можно написать на «змеином языке». Скрипты Python хорошо взаимодействуют со многими движками, что позволяет использовать их для более эффективного и простого кода, даже если игра написана на другом языке.

Не теряет популярности Java, и достижения технического прогресса играют ему на руку. Кроссплатформенность этого языка позволяет легко адаптировать игры под любую операционную систему. Java пригодится не только в игрострое. С его помощью создают Android и веб-приложения, серверные проекты в сфере финансовых услуг, встраиваемые системы и инструменты для обработки Big Data.

Классика для создания игр — C++. При всей сложности в изучении этот язык крайне востребован. Он гибкий и компилируемый.

Интересный вопрос
Геймдизайнер , в индустрии более 7 лет. Веду свой блог "Геймдизайн для сочувствующих" в ВК, где пишу статьи для начинающих специалистов.

Процесс создания игры - это сложный, многостадийный и многосоставной процесс, поэтому ответить на ваш вопрос не так уж и просто, но я попробую.

Давайте предположим, что вы спрашиваете с позиции геймдизайна. Тогда я бы посоветовала вам начать с проработки идеи.

ШАГ НОМЕР 1: РАБОТА С ИДЕЯМИ

У всех у нас есть игры, которые нас вдохновляют, которые мы любим. Мы знаем, как сделать их еще лучше, или хотим сделать похожее, но свое. Многие геймдизайнеры-теоретики мечтают выпустить свою ММОРПГ с открытым миром, или стратегию уровня Civilization, или мощный шутер от первого лица с нелинейным сюжетом.

Такие амбиции заслуживают уважения, но они, к сожалению, никогда не будут удовлетворены. Задумайтесь, почему ни одна российская игровая компания с многомиллионным капиталом не выпускает блокбастеры ААА класса? Потому что работа эта сопряжена с огромными денежными затратами и огромными рисками, потому что если проект после разработки “не выстрелит”, то гигантские средства, потраченные на разработку, не вернутся. Все деньги игровой индустрии сосредоточены на западе, и конкурировать с выпускаемыми там проектами очень сложно. Поэтому, если вы замахиваетесь на масштабный проект, то он должен по уровню графики, эффектов, наворочанности игровых механик быть конкурентоспособным хотя бы в среде бета-самцов жанра, что совершенно невозможно, если у вас нет опыта, средств и огромной команды. Как правило, начиная разработку такого проекта, геймдизайнер ненамеренно устраивает сам себе ад на земле. Команда вся идет вразнобой, разработка проекта затягивается, постоянно возникают какие-то проблемы, для решения которых геймдизайнеру необходимо иметь 34 часа в сутках и как минимум шесть рук. Особые наркоманы начинают вливать такие мертворожденные проекты свои собственные деньги. В итоге вся эта канитель продолжается год или два, и геймдизайнер, измученный и истощенный с криком “это надо только мне одному, а больше никто работать не хочет”, бросает проект, испытывая отвращение к геймдизайну, к людям в целом и к себе в частности. Такой ошеломляющий провал как правило убивает в человеке желание попытаться снова чуть более чем полностью.

Вам нужно выбрать такой проект, который вы сможете реализовать небольшим коллективом и при этом впоследствии опубликовать его в сторах. В этой статье я не буду рассматривать площадки и способы продвижения проекта на них, скажу только, что самым простым вариантом для вашей первой игры является мобильный проект с последующей публикацией в первую очередь на Google Play, а затем в AppStore.

Что сказать о самой игре? Поверьте мне, даже если вы соберетесь создать примитивный тетрис, то вы столкнетесь с таким количеством сложностей и проблем, что вы удивитесь, как вообще кто-то умудряется выпускать в этом мире игры. Возьмите на вооружение концепт с небольшим количеством графики и простыми игровыми механиками.

ШАГ НОМЕР 2: ПЕРВИЧНАЯ ДОКУМЕНТАЦИЯ

Когда вы определились со своей идеей, первое что нужно сделать - попытаться сформулировать ее и дополнить деталями. Идея - это набор разрозненных мыслей. Хорошая идея - это продуманный и структурированный набор тезисов.

Концепт-документ - это короткий документ (10-15 страниц), который относительно детально описывает вашу игру. Цели этого документа следующие:

  • содержать понятное описание концепции игры;

  • знакомить потенциальных членов вашей будущей команды с идеей игры;

  • являться отправной точкой для будущей детализации и документации.

Содержание концепт-документа должно быть следующим:

1. Среда разработки

Мобильная платформа, или ПК, а может быть консоль или соцсети. Это, собственно, определит очень многое. Некоторые компании или издатели работают только с конкретными платформами. Выбор платформы также поможет определить среду разработки и выбрать игровой движок, что в свою очередь создаст определенные требования к программистам на проекте. Выбор платформы также определяет рекламную кампанию, и направление для маркетинговых работ.

2. Жанр, целевая аудитория

Выбор целевой аудитории также даст представление о том, как в дальнейшем продвигать проект, о том, какую нишу он займет на рынке игр, и даже о некоторых игровых механиках вашей игры.

3. Описание геймплея, список фич.
Фича - feature - это игровая механика, особенность игры. Это очень важный момент. Фактически, это первая серьезная информация, с которой столкнется человек, читающий ваш документ (первые два пункта представляют собой один абзац). Здесь вы должны максимально понятно описать, в чем, собственно, и состоит сам процесс игры.

1) Начать стоит с описания game loop - игрового цикла - последовательности действий, которые совершает игрок постоянно. Чтобы было понятно, о чем речь, приведу game loop известного мобильного проекта Clash of Clans:

image.png

На самом деле, игровых механик в игре Clash of Clans, конечно же, намного больше, но ключевой геймплей, который повторяется каждую гровую сессию - именно такой.

2) Далее перечислить более подробно основные игровые механики: что еще интересного и веселого игрок сможет делать в игре. Например: прокачка персонажа, или лечение раненых войск, или крафт уникальных предметов. Насколько полным будет это описание - зависит от типа документа.

4. USP - Unique Selling Points - уникальные особенности игры.
USP - это уникальные фичи, которые делают вашу игру особенной и которые должны привлечь игрока, заставить его выделить ваш продукт среди конкурентов в том же жанре. То, что другие люди выделяют в первую очередь, когда вы рассказываете им о своей идее, и будет являться вашими USP. Также в этот пункт попадают какие-то инновационные идеи, или необычное сочетание уже известных игровых механик.

Если вы не знаете, что написать в этот пункт, значит вы недостаточно хорошо продумали свою концепцию и открыв вашу игру, игроки не найдут в ней ничего нового и интересного и просто закроют ее.

5. Сюжет, история мира.
Здесь нужно дать общее представление о сюжете и о том как механики, описанные выше обоснованы сюжетно. Можно также указать ключевых персонажей вашей истории с кратким описанием их характеров. Можно упомянуть основные конфликты, интересные сюжетных ходы, чтобы дать наиболее полное представление об игровом мире.

6. Контент

Это ваш примерный фронт работ. Конечно, на стадии идеи вам будет трудно продумать все детали, но это и не нужно, достаточно просто примерно посчитать то, что вам нужно будет сделать. Это поможет вам понять, какого размера команда вам потребуется для разработки, и возможно протрезветь на тему того, потянете ли вы вообще масштаб, который задумали. Посчитать количество персонажей, квестов, диалогов, бэкграудов, объектов и прочего и записать списком в документ.

7. Стиль графики с референсами.

Если вы сами не рисуете, найдите в сети референсы на то, как вы хотите, чтобы выглядела ваша игра, скриншоты их других игр, работы художников, палитры цветов. Добавьте эти картинки с небольшим текстовым описанием: что самое важное на той, или иной картинке.

ШАГ НОМЕР 3: ПОИСК КОМАНДЫ

Если вам удалось сформулировать ценную и интересную идею, то теперь ее необходимо разделить с другими людьми. Попробуйте поискать разработчкиков в инди-пространствах, на форумах, или в тематических группах. Это не очень простой шаг.

Постарайтесь остановить свой выбор на таком концепте, для разработки которого потребуется не более 4 человек. При более многочисленной команде начнется искажение и искривление планов и вы не сможете ее контролировать, потому что работать вы все будете, скорее всего, удаленно. Заранее составьте план разработки и четкую презентационную документацию по проекту, чтобы доказать свою компетентность и серьезность своих намерений. Не принимайте людей в команду "за ради Христа", выставляйте четкие требования к возможным кандидатам, чтобы сразу дать им понять всю меру ответственности, которую вы от них ждете. Ищите команду в группах по геймдизайну, программированию и концепт-арту, на форумах типа gamedev.ru. Не переживайте, если поиск займет много времени. В данном случае важнее всего качество, а не количество.

Когда сложный процесс поиска команды закончен, вам остается самое сложное - руководить ею так, чтобы она не разбежалась и не рассыпалась, а проект был выполнен в намеченный срок.

Подробнее о руководстве командой читайте здесь:
https://vk.com/@mistle_gamer-kak-ladit-so-svoei-komandoi

Отдельно о работе с художниками можно почитать тут:
https://vk.com/@mistle_gamer-kak-rabotat-s-hudozhnikami

Как работать с программистами можно почитать тут:

https://vk.com/@mistle_gamer-kak-rabotat-s-programmistami

ШАГ 4: РАЗРАБОТКА

Когда вы беретесь за самостоятельный проект, который вы будете, вероятнее всего, делать в свободное от работы и учебы время - главное сохранять системность. До того, как позвать остальных членов команды в свой проект, попробуйте самостоятельно составить себе расписание, по которому вы будете работать (подготавливая документацию, например) несмотря ни на какие другие дела. Ведь работа над игрой - это как вторая работа. Ни прогуливать, ни пропускать нельзя, потому что если вы, самый замотивированный в мире человек, будете это делать, то что же тогда будет с остальной командой?

Для того, чтобы суметь построить свой рабочий процесс над проектом, нужно ознакомиться с уже существующими методологиями работы. Существуют целые системы циклов производств, которые помогут вам системно подойти к разработке.

О методологиях работы над проектом можно почитать вот тут:

https://vk.com/@mistle_gamer-metodologii-upravleniya-proektom

Если к вам подключится еще человек, или два, можно обсуждать нюансы вашей идеи и детализировать документацию по проекту. То есть, брать каждый отдельный пункт написанного ранее концепт-документа и превращать его в отдельный набор документации. Не бывает так, что вы напишете огромный дизайн-документ, отдадите его команде и - вуаля - игра готова. Написание дизайн-документации по проекту - это кропотливый и долгий процесс, который заключается в логическом разделении элементов проекта на группы механик и методичном описывании принципов их работы вплоть до закорючки.

О системе дизайн-документации и принципах ее написания можно почитать вот тут:

https://vk.com/@mistle_gamer-rabochii-dizain-dokument-kotoryi-budut-chitat

Разработка собственного проекта это, как правило, адский труд, требующий огромной мотивации, целеустремленности, умения структурировать и систематизировать работу на насколько месяцев вперед, уверенности в своей идее и хорошего ее понимания. Правильно оцените свои силы и будьте уверены в себе, и тогда все ваши старания непременно окупятся.

Как создать переменную со случайным значением в диапазоне от 1 до 10 включительно?  — 4 ответа

Я порылся на просторах интернета и получил вот это: var ran1 = GetRandomIntRage(1, 10); Но оно не пашет. Может нужно ещё чего-нибудь добавить?
1 человек оценил этот вопрос
Интересный вопрос
Аналитик, учусь на магистра фин.менеджмента, люблю Италию, папа - шеф-повар

Для создания переменной со случайным значением в диапозоне от 1 до 10 включительно, необходимо использовать таку функцию:

0 <= RandomNum < X

Получится такая функция

От 1 до 10 – Random(10)+1

Популярные темы