ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!
|
| » Два пути - количество или качество игр | страница 1 |
|
|
|
|
Канал Игры Мечты: «Два пути - количество или качество игр» |
|
|
|
Minx
 978 EGP
       
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
  |
|
Это правда, что в геймдеве есть два разных пути:
| Цитата: |
| Цитата: |
|
{I путь} специфика: довольно низкая степень переиспользования старого кода. Т.е. сделали продукт, выпустили на рынок. А для нового продукта затем чуть ли не все заново сделали. По крайней мере из того, что у конечного пользователя на компьютере крутится.
|
Не, так только у тех, кто мелкие поделки делает в разных жанрах.
{II путь} Кошерный путь — это разработка линейки игр, с постепенным развитием кода и повышением качества, поскольку с налёта и без наработок ААА игру всё равно сделать не получится. Плюс, инфраструктурные части (графический/физический движки, например) вполне переносимы, вот с логикой на порядок сложнее, в новых играх её действительно часто с нуля надо делать.
|
?
Соответственно, для каждого из них применяются разные технологии и по-разному организуется процесс разработки?
Например, первый путь может использоваться для быстрой сборки множества прототипов/игр, из которых можно потом выбрать что-то выстрелевшее и пойти по второму пути. (?)
Соответственно, первый путь - меньший порог вхождения, меньшее качество кода, меньшие затраты на выпуск, быстрые итерации. Второй путь - более мощные и точные инструменты, больший профессионализм. (?)
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
DIMOSUS.X
 995 EGP
   
Рейтинг канала: 4(67)
Репутация: 188
Сообщения: 3252
Откуда: Vilnius/Minsk
Зарегистрирован: 06.08.2008
 |
|
Я бы сказал, что первый путь это путь начинающих. Второй — уже для состоявшейся в геймдеве компании.
_________________
Даже ежики ежиков могут с трудом,
Иначе бы ежики были кругом. |
|
|
|
Sh.Tac.
 151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
это один путь 
делают продукт, потом когда делают второй (а этого может и не случиться ведь), думают что бы такого выдрать из первого
так появляется инструментальная библиотека перерастающая в движок
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| DIMOSUS.X : |
|
Я бы сказал, что первый путь это путь начинающих. Второй — уже для состоявшейся в геймдеве компании.
|
Понятно, что AAA игру сходу вряд ли получится выпустить, и несколько лет пилить первую игру, близкую к идеальной (как было например с FEZ или Braid, это были первые игры 'начинающих', без какой-либо состоявщейся компании) маловероятно (но возможно). И опять же, вопрос тут в подходе и инструментах.
Т.е. твой ответ на первый вопрос - неправда?
| Sh.Tac. : |
|
делают продукт, потом когда делают второй (а этого может и не случиться ведь), думают что бы такого выдрать из первого
|
Или загибаются под эффектом второй системы по Бруксу.
| Sh.Tac. : |
|
так появляется инструментальная библиотека перерастающая в движок
|
Только на полке сейчас уже есть куча готовых движков и библиотек. Поэтому можно пилить свое (профессионально, но долго, 2-й путь), или брать готовое (1-й путь). Нет?
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
парадокс если и есть, то проистекающий из следующего наблюдения, ты не знаешь что тебе нужно, пока не сделаешь что-либо
можно и нужно брать готовый движок, но там та же история, со временем образуется всё утолщающаяся прослойка кода между чистым движком и игрой
потом готовый движок может быть серьёзно модифицирован с учётом наработанного опыта
кста недавно увидел в действии подход о котором только слышал, если что-то нужно, люди просто берут и пишут это, я офигел, но это работает
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Sh.Tac. : |
можно и нужно брать готовый движок, но там та же история, со временем образуется всё утолщающаяся прослойка кода между чистым движком и игрой
потом готовый движок может быть серьёзно модифицирован с учётом наработанного опыта
|
При чем тут все это..
Выше два варианта описано. Первый - нагавнокодил за неделю-месяц игру и [в среднем из большого числа] продал каждую за среднюю зп по отрасли. Второй - продвижение линейки игр или долгое пиление одной игры.
И то и то делается с движками и библиотеками. Или без них. И там и там прослойки кода (разной толщины). Но в первом случае код постоянно переписывается, а во втором постоянно сопровождается.
| Sh.Tac. : |
|
кста недавно увидел в действии подход о котором только слышал, если что-то нужно, люди просто берут и пишут это, я офигел, но это работает
|
Э.. альтернативный подход это какой? Это если что-то нужно, люди не берут и не пишут? Или, люди берут и пишут когда что-то не нужно?
_________________
μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (23:38 08-09-2015), всего редактировалось 1 раз |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Minx : |
|
Выше два варианта описано. Первый - нагавнокодил за неделю-месяц игру и [в среднем из большого числа] продал каждую за среднюю зп по отрасли. Второй - продвижение линейки игр или долгое пиление одной игры.
|
пытаюсь рассказать про обобщённый случай, когда "нагавнакодил" по-быстрому, а потом приходится поддерживать годами, потому что проект состоялся
| Цитата: |
|
Э.. альтернативный подход это какой?
|
самый разумный отказаться от фичи, второй, поискать готовое решение, а вот чтобы просто сесть, прикинуть, накалякать и отладить, такое редко где уже
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Sh.Tac. : |
|
пытаюсь рассказать про обобщённый случай, когда "нагавнакодил" по-быстрому, а потом приходится поддерживать годами, потому что проект состоялся
|
Это понятно. Но у меня вопрос-то про другое..
| Sh.Tac. : |
|
самый разумный отказаться от фичи, второй, поискать готовое решение, а вот чтобы просто сесть, прикинуть, накалякать и отладить, такое редко где уже
|
А как можно найти готовое решение для игровой логики? Она же везде разная.
Если есть альтернативы, то естественно как всегда компромисс между тем что уже есть и тем, что можно сделать самому. И далее инженерная практичность затрат в единицу времени.
_________________
μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (23:56 08-09-2015), всего редактировалось 1 раз |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Minx : |
|
А как можно найти готовое решение для игровой логики? Она же везде разная.
|
есть базовые кубики, например модификаторы параметров, которые могут быть с таймером и тогда бафы/дебафы, кубики можно складывать по-разному, складывать буквально, множить, выбирать максимальное и т.п.
конкретное знание о том, что это за параметр или характеристика не требуется
но вообще да, игромех это собсно и есть игра, формализовать его тяжело и иногда вряд ли нужно
| Цитата: |
|
И далее инженерная практичность затрат в единицу времени.
|
часто это субъективно, вот недавний пример, мне надо было проэкстраполировать вращение, взял кватернионы, написал тест, что-то не сошлось, в течении часа не разобрался, написал на углах эйлера, там собсно одно граничное условие, фазы сдвигаются на pi когда pitch переходит через полюс, подобрал с помощью sin/cos, вышло не быстрее, но как бы неважно
в продакшн коде такое может не проканать, тебе популярно объяснят где ты неправ
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Sh.Tac. : |
|
есть базовые кубики, например модификаторы параметров, которые могут быть с таймером и тогда бафы/дебафы, кубики можно складывать по-разному, складывать буквально, множить, выбирать максимальное и т.п.
|
Да практически везде есть базовые кубики. Те же списки-векторы, регулярные выражения, диспетчеры, мьютексы, фабрики и прочая. Только начинаются проблемы, когда это все нужно связать и потом со всем этим взлететь (;
| Sh.Tac. : |
|
там собсно одно граничное условие, фазы сдвигаются на pi когда pitch переходит через полюс, подобрал с помощью sin/cos, вышло не быстрее, но как бы неважно
|
С недавнего времени меня как-то заинтересовало - граничное условие это следствие двумерного/трехмерного
ежа?
| Sh.Tac. : |
|
в продакшн коде такое может не проканать, тебе популярно объяснят где ты неправ
|
Это чесальщики ЧСВ будут объяснять. А кто пороху нюхал вполне понимает, что такое сжатые сроки и необходимость выкатить релиз. Такое не прокатывает в долгосрочной перспективе, или когда постоянно отмазываются костылями из-за лени.
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
Guest
2075 EGP
        
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
TL;DR: я бы не стал делить пути на два, всегда будет промежуточный вариант.
| Minx : |
|
Это правда, что в геймдеве есть два разных пути:
|
Да, но не в геймдеве, а в программинге вообще.
Можно использовать старый код, а можно его выкинуть.
Если старых наработок нет и/или они не подходят к новому проекту - то пишут заново, тут просто без вариантов - взять неоткуда.
Если старые наработки подходят - пишут с использованием старого.
Второй подход не "кошерен" а как бы является нормальной практикой, но при этом имеет стоимость поддержки старого кода.
Вот в качестве контрпримера второго пути хорошо привести Эгософт с его Иксами. Наработок куча, они последовательно тягаются в следующий проект, от чего проекту с каждой итерацией всё хуже и хуже.
Так что смотря чего тягать. Инфраструктуру - да, если цель позволяет (не у всех есть мегауниверсальные решения типа Анрила, Края или Юнити). А вот контент, скажем, тянуть смысла нет... Логику тянуть можно, если она подходит, но высока вероятность лютого закостыливания. А вот архитектуру - можно и даже нужно, чтобы шлифовать.
З.Ы.: для прототипов лучше всего, когда есть инфраструктурная основа готовая, т.к. там главное - быстро набросать логику. Логика с нуля, а на всё остальное лучше время не тратить.
З.З.Ы.: ну и просто по логике: одно дело делать скажем Call of Duty 2022, имеющего хвосты ещё от Call of Duty Pre-Alpha, а другое дело - перейти от Civilization к C&C. Обе - стратегии, но тащить не получится вообще ничего, даже движок.
| Minx : |
|
Соответственно, первый путь - меньший порог вхождения, меньшее качество кода, меньшие затраты на выпуск, быстрые итерации. Второй путь - более мощные и точные инструменты, больший профессионализм. (?)
|
Первый путь - значительно большие временные затраты, значительно большие затраты на выпуск, большее количество итераций.
Качество кода - зависит только от программистов и архитекторов, не от пути.
Порог вхождения на первом пути - необходимость писать всю архитектуру целиком с пустого места, что только кажется простым. На втором пути - необходимость разобраться или обучить использованию уже написанного, что по большей части зависит только от качества документации. Хорошая документация - низкий порог...
Частота итераций при разработке вообще только от методологии разработки зависит, как хочешь - так и циклись.
Профессионализм - это да. Сделать что-то, что можно потом применить куда-то ещё - это круче, чем сделать то, что потом можно только выкинуть. Уметь использовать готовые решения вместо велосипедов, а заодно примерно знать, как они внутри работают и каковы их ограничения. В общем, разница между мидлом и сеньором. 
Повторное использование ресурсов позволяет сэкономить на втором и следующих циклах производства, ценой задержки первого цикла (гибкость решения, подробное документирование). Экономия может быть существенной, но дороже всего в производстве - контент (сегодня только говорил по этому поводу), а контент на вторичное использование почти не идёт.
По поводу прототипов ещё одно - нет ничего более постоянного, чем временное. Из прототипа, как правило, большая часть так и перетекает в релиз без изменений и обрастая слоем костылей. Так что делать прототип в конечном итоге дешевле выйдет именно на готовой основе, а не с нуля.
_________________
Трещит земля как пустой орех
Как щепка трещит броня
Последний раз редактировалось: Guest (02:52 09-09-2015), всего редактировалось 1 раз |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Guest : |
|
я бы не стал делить пути на два, всегда будет промежуточный вариант.
|
Тут же рассматривается в вакууме. На одном конце спектра конструкторы, а на другом например профессиональные движки, с помощью которых могут получить намного больше, чем например юнити.
И тут отдельный вопрос по поводу инструментария. Например, на плюсах новичок себе чего-нибудь сломает, и порог вхождения ему будет слишком большой, какой бы хорошая документация на плюсам не была.
В этом вопросе инструменты разного уровня раскидываются по спектру. Например, в жаве порог вхождения значительно меньше плюсов, и потому она существенно ближе в этом отношении к быстронаписанным играм.
Откуда может вытекать следующее. Если хочется быстро что-то сделать (не важно, прототип или нет), то проще будут конструкторы, языки с динамической типизацией, .. Но если хочется линейку или качественный долгострой, то придется расчахлить что-нибудь помощнее.
И с профессиональной точки зрения (относительно затрат) - может эффективнее набросать прототипы в чем-то простом, а боевое применение начать собирать уже в более мощном.
Потому что например в программировании вообще, если нужно решать какие-нибудь штучные задачи (хитро отпарсить логи, поднять хттп-сервер с простой логикой, запускать скрипт раз в час, ..) то это решается эффективно скриптовыми языками (руби, питон, ..). А вот когда нужен мощный продакшен, или реал-тайм, то тут уже дорога в статику (C/C++). Или нужно решение для большого проекта на большое время и большое число людей (тут уже Java/C#/C++/..), потому как скриптовыми языками сложнее работать долго или в команде.
| Guest : |
|
Первый путь - значительно большие временные затраты, значительно большие затраты на выпуск, большее количество итераций.
|
Как мне видиться, первый путь меньше по временным затратам если проект быстрый. Если же проект жить собрался долго, то тогда уже будут большие временные затраты.
| Guest : |
|
Качество кода - зависит только от программистов и архитекторов, не от пути.
|
Тут такая логика: если нет перспективы развития, то зачем держать марку качества?
| Guest : |
|
Порог вхождения на первом пути - необходимость писать всю архитектуру целиком с пустого места, что только кажется простым.
|
У меня есть впечатление, что для ряда проектов народ вообще не задумыается об архитектуре. Для появления здравых архитектурных мыслей нужно несколько лет опыта [в абсолютном большинстве случаев].
_________________
μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (16:46 09-09-2015), всего редактировалось 3 раз(а) |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| Minx : |
|
Как мне видиться, первый путь меньше по временным затратам если проект быстрый. Если же проект жить собрался долго, то тогда уже будут большие временные затраты.
|
Если пишешь с "пустого листа" - это всё равно дольше, чем если уже есть талмуд и надо поюзать отдельные главы из него, дописав совсем немного. Конечно, придётся поломать голову над тем, какие главы взять и как их адаптировать.
Тут граничный случай - если одних совсем базовых средств среды хватает, чтобы собрать что-то рабочее, скажем текстовый квест. В этом случае "основой" выступает чуть ли не язык программирования (ну не с драйверов же писать начинать). Тут да, на фиг не нужны никакие наработки, кроме опыта. Да и то, имея хороший движок квеста из предыдущих итераций - можно просто сходу гнать тексты, уже не думая про загрузку ресурсов, менюшки, триггеры и т.д.
| Minx : |
|
Тут такая логика: если нет перспективы развития, то зачем держать марку качества?
|
Ты так пишешь, как будто "марка качества" - это что-то типа рекордного веса штанги...
Ни одна разработка не обходится без ошибок, а чем хуже пишешь - тем сложнее потом фиксить, так что это только увеличивает временные затраты.
| Minx : |
|
У меня есть впечатление, что для ряда проектов народ вообще не задумыается об архитектуре. Для появления здравых архитектурных мыслей нужно несколько лет опыта [в абсолютном большинстве случаев].
|
Есть ИМХО два пути:
I) прикидывается общая архитектура типа "тут мы храним это, тут это, сюда рыбу заворачиваем, а вон ту хрень хз куда, давай пока отдельно положим, а потом растащим в подходящие места", расписывается на листочке и потом по возможности используется, чтобы не путаться и копии кода не плодить. А по невозможности - забивается и кодится полный трешак с пометкой //TODO: после ближайшего кранча переделать на фиг!
II) приходит АРХИТЕКТОР ПРОЕКТА, полгода пыжится и рожает документ на 720 страниц, начинающийся с раздела "общие положения мироустройства локального микрокосма Вселенной" а заканчивающийся описанием порядка размещения переменных в каждой из функций. В результате выполнения требований этого документа получается абсолютно гибкая система, с равной степенью пригодная для стратегий, шутеров, квестов, управления БАКом и автопилотирования Шаттлом.
Совсем без архитектуры не получится, даже если она сильно морфирует в процессе кодинга. Иначе придётся очень много копи-пастить и потом ещё больше ползать с поиском.
И вообще - готовые инструменты позволяют сэкономить на подготовке инструментов! 
добавлено спустя 6 минут:
| Minx : |
|
Тут же рассматривается в вакууме. На одном конце спектра конструкторы, а на другом например профессиональные движки, с помощью которых могут получить намного больше, чем например юнити.
|
А "профессиональный движок" - это что такое и чем он хуже конструктора?
Если это узкоспециализированная система - она экономит время на разработке специализированного софта, но очевидно немедленно сливает при попытке разработки чего-то за своими рамками.
Широкоспе...циализированная система экономит время на разработку всяких базовых блоков. Скажем, не надо писать контроллер обращения к драйверу видяхи, контроллер камеры, менеджер шейдеров, менеджер текстур, менеджер памяти. Эти штуки нужны абсолютно любой игре, и могут с минимальными адаптациями применяться к любому проекту, так зачем их с нуля писать каждый раз? С другой стороны, менеджер сцены из игры в игру особо не потаскаешь, его писать в каком-нибудь виде (даже если это скрипты вида "если игрок рядом и нажал ЛКМ - ПЫЩ-ПЫЩ ПОПЯЧСА ОЛОЛО!") придётся всё равно.
_________________
Трещит земля как пустой орех
Как щепка трещит броня
Последний раз редактировалось: Guest (17:11 09-09-2015), всего редактировалось 1 раз |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Guest : |
|
Если пишешь с "пустого листа" - это всё равно дольше, чем если уже есть талмуд и надо поюзать отдельные главы из него, дописав совсем немного. Конечно, придётся поломать голову над тем, какие главы взять и как их адаптировать.
|
Это работает хорошо тогда (не не только тогда), если уже есть опыт работы с этим талмудом. Т.е. важно не только иметь талмуд, но и понимать что он умеет и иметь представление о карте разбросанных граблей.
Поэтому когда народ пишет движок сам, он начинает понимать, как движок может быть устроен под капотом. И соответственно возможности и узкие места других движков становятся более понятными.
| Guest : |
Ты так пишешь, как будто "марка качества" - это что-то типа рекордного веса штанги...
Ни одна разработка не обходится без ошибок, а чем хуже пишешь - тем сложнее потом фиксить, так что это только увеличивает временные затраты.
|
Если например есть дедлайн, и он через неделю, то стиль доработки может поменяться координально от дедлайна в месяц-год. Соответственно, меняется и качество. Поэтому если готовится проект за неделю, то смысла готовить проект к долгой жизни просто нет.
| Guest : |
|
Совсем без архитектуры не получится
|
По моему мнению, это не архитектура. Скорее, организация и дисциплина разработки.
| Guest : |
|
А "профессиональный движок" - это что такое и чем он хуже конструктора?
|
Если сам писал движок, и знаешь, как работают все его шестеренки и даже глубже, то вполне можешь чудить очумелые (для взгляда со стороны и по факту) вещи. Если же смотреть на конструкторы, то для большинства новчиков уровень их абстракции непроницаем, а старичкам работать с такими уже не хочется.
---
Все таки, суть моего вопроса видимо в этом:
| Minx : |
И с профессиональной точки зрения (относительно затрат) - может эффективнее набросать прототипы в чем-то простом, а боевое применение начать собирать уже в более мощном?
Потому что например в программировании вообще, если нужно решать какие-нибудь штучные задачи (хитро отпарсить логи, поднять хттп-сервер с простой логикой, запускать скрипт раз в час, ..) то это решается эффективно скриптовыми языками (руби, питон, ..). А вот когда нужен мощный продакшен, или реал-тайм, то тут уже дорога в статику (C/C++). Или нужно решение для большого проекта на большое время и большое число людей (тут уже Java/C#/C++/..), потому как скриптовыми языками сложнее работать долго или в команде.
|
И обратная логика - те, кто пишут на легкоусваиваемом, то потом тяжелее все сопровождается. (?)
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
Ты противопоставляешь "простой" и "мощный", а это не антонимы.
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
ага, та же уешька, прототип накидывается схематично брашами и блюпринтами, уже можно бегать и что-то делать, в т.ч. например по сети
дальше всё это выкидывается и пишется уже в коде
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Guest : |
|
Ты противопоставляешь "простой" и "мощный", а это не антонимы.
|
Простой - малое число отверток.
Мощный - большое число отверток.
Простой - просто усвоить, сложно потом из малого числа кубиков собрать что нужно.
Мощный - сложно усвоить, но кол-во предоставляемых абстракций намного больше, и из их комбинаций проще получить более точный и нужный результат. Т.е. более гибкий, более быстрый, более удобный.
Есть и другие факторы, но это самое существенное.
добавлено спустя 4 минуты:
| Sh.Tac. : |
|
дальше всё это выкидывается и пишется уже в коде
|
Вот где-то про это имею ввиду..
А есть варианты когда это продается за [смешные] деньги и так делается много раз?
---
Например, Minecraft первый собрали на жаве на какой-то там конкурс (т.е. судя по всему быстро).
Space Station 13 - это жестокий пример, но пример.
Как-то народ все таки иногда взлетает со всем этим или на всем этом..
_________________
μηδείς αγεωμέτρητος εισίτω
Последний раз редактировалось: Minx (20:46 09-09-2015), всего редактировалось 2 раз(а) |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| Minx : |
|
А есть варианты когда это продается за [смешные] деньги и так делается много раз?
|
мне кажется на колбасные обрезки нет покупателей
игры на конструкторах не стоит недооценивать, собрать что-нить такое на Scirra Construct2 и залить на kongregate, это много корячиться надо, особенно учитывая невозможность нормально прогать
_________________
This is what you get ...
(c) Radiohead |
|
|
|
Guest
2075 EGP
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| Sh.Tac. : |
ага, та же уешька, прототип накидывается схематично брашами и блюпринтами, уже можно бегать и что-то делать, в т.ч. например по сети
дальше всё это выкидывается и пишется уже в коде
|
Да, но при этом в той же уешке
| Minx : |
Простой - малое число отверток.
Мощный - большое число отверток.
Простой - просто усвоить, сложно потом из малого числа кубиков собрать что нужно.
Мощный - сложно усвоить, но кол-во предоставляемых абстракций намного больше, и из их комбинаций проще получить более точный и нужный результат. Т.е. более гибкий, более быстрый, более удобный.
|
Ну так сложность освоения не от количества предоставленных абстракций зависит.
Может быть много неудобных отвёрток, а может быть много удобных. Возможности одинаковы, в трудозатраты в первом случае выше.
добавлено спустя 1 минуту:
| Minx : |
Space Station 13 - это жестокий пример, но пример.
|
SS13 лежит на BYOND, довольно сложном и универсальном движке.
_________________
Трещит земля как пустой орех
Как щепка трещит броня
Последний раз редактировалось: Guest (03:47 10-09-2015), всего редактировалось 1 раз |
|
|
|
Minx
978 EGP
Рейтинг канала: 6(328)
Репутация: 135
Сообщения: 10521
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
|
|
| Guest : |
Ну так сложность освоения не от количества предоставленных абстракций зависит.
Может быть много неудобных отвёрток, а может быть много удобных. Возможности одинаковы, в трудозатраты в первом случае выше.
|
Поэтому и написал:
| Minx : |
|
Есть и другие факторы, но это самое существенное.
|
Оченьвидно, что абстракции криптографической библиотеки вряд ли помогут в написании парсера XML. Но если сравнить TinyXML с libxml, то это две большие разницы.
| Guest : |
|
SS13 лежит на BYOND, довольно сложном и универсальном движке.
|
Видимо меня дизинформировали по поводу BYOND..
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
|
|
|
|
|
Канал Игры Мечты: «Два пути - количество или качество игр» |
|
|
| К списку каналов | Наверх страницы |
Цитата не в тему: И еще - у меня на конец-то встал на Х2, так что я вскоре переезжаю. (Fry в КСО)
|
| » Два пути - количество или качество игр | страница 1 |
|
