За год чтения этого форума сложилось устойчивое ощущение, что именно проблема с написанием движка тормозит все начинания и движения молодых адвентписателей в сторону своей первой игры.
На мой взгляд неверна изначальная установка о необходимости движка, которую вбивают в голову начинающим. Отсюда новичок уже твердо знает, что просто так игру не пишут - нужен движок, существующие он отвергает, а вот оставшийся единственный вариант написания собственного практически всегда увязает в истощившемся желании, недостатке чисто технических знаний и др. На мой взгляд, это очень опасный прецендент, образующий целую группу отрицательных моментов :
1) Любой новичок как пробовавший, так и не пробовавший начинать писать игру, прочно ассоциируют создание IF с первоначальным написанием движка, причем у пробовавшего - эта ассоциация уже носит отрицательный характер.
2) Любой энтузиаст, севший за написание движка, расходует весь свой энтузиазм (носящий, как правило чисто IF-шный характер) на решение унылых технических проблем движка, чаще всего на этом все и заканчивается.
3) Любому начинающему жизненно необходимо сразу же поселить протагониста хоть в какое-то пространство и отработать основные приемы взаимодействия с окр.ср., почувствовать какие новые взаимосвязи образуются только лишь после добавления одного предмета в локацию, то есть окунуться в чистую метафизику IF, вместо этого он ломает голову над тем, как его движок будет различать одинаковые внешне, но по-разному наполненные плазмой энергетические ловушки, хотя на самом деле герою его игры еще не пришлось просто попробовать прочитать надпись или поднять камень.
То есть, люди, пришедшие в IF, постепенно, сами того не осознавая, перенаправляют свою энергию в другое русло.
Три момента еще более усугубляют эту ситуацию :
а) Новички хотят создать СУПЕР-ПАРСЕР, на котором бы их игры писали все остальные и тем покрыть себя славой (как правило желание самому написать игру тут уже пропадает)
б) Ветераны IF продолжают вбивать в голову новичкам мысль о первейшей необходимости движка и бомбят немногих, написавших хоть что-то похожее на движок, своими "тестами на крутость". Это они бросают фразы типа "твоя игра отвечает на все непонятные глаголы одинаково" или "твой герой даже не может подпрыгнуть на месте". Они формируют аксиому "слабый движок = ОЧЕНЬ слабая игра".
в) Этот момент я называю "IF-аномалией автора-новичка". Абсолютно ВСЕ существующие движки отвергаются в конечном счете. Причины называются разные - итог один.
Я ни в коей мере не отрицаю важность и даже первостепенность значения движка, но это все справедливо только для высшей лиги IF, а ведь дорога к ней трудна и длинна и вымощена ей-богу булыжниками (читай камнями подводными) и шаткими-валкими мостиками (читай костылями и подпорками в коде).
И так, представляю вашему вниванию концепцию "solid code", которая проста и всем знакома. Если вы хотите попробовать написать IF-игру и более-менее умеете программировать (а именно такие люди начинают писать движок), забудьте о движке и СРАЗУ НАЧИНАЙТЕ ПИСАТЬ ИГРУ самым простым способом - IF-ELSE-ELSEIF. Множьте свои IF-ы (в смысле условия внутри программы) и не обращайте внимания на то, что это самый "чайниковый" способ - в скомпилированной игре мы ваших навыков кодописания не увидим, а вот механику можно будет оценить уже сразу. К слову сказать, этим способом гипотетически можно реализовать самую сложную функциональность в небольшой по размеру игре. Вы меня спросите "а в большой", а большие игры даже на хороших движках получется писать только ветеранам, у которых не один десяток любительских "заготовок" за плечами. Нужно отметить тот факт, что больших и сложных игр в русском IF очень мало, несмотря ни на наличие можных движков, ни на программистские способности человека. Большая и хорошая игра - это вопрос не к движку, а к автору в первую очередь.
По мере того, как вы начнете спотыкаться о "спагети-код" своей игры (а это хороший признак, это значит, что в вашей игре уже можно где-то прогуляться, что-то взять и чем-то на что-то подействовать), вы начнете работу по упорядочиванию кода - NPC и предметы инкапсулируются у вас из набора переменных в структуры (struct, record, object), появятся обособленные процедуры для наиболее частых действий, но выполняя все эти правки, вы уже будете держать в голове вашу игру, состоящую из "если X, то Y" и вы будете точно понимать для чего вы сейчас пишете тот или иной кусок кода. Хоть такой подход и не даст создать под готовой игрой универсального и мощного движка, как нельзя пропихнуть под лежащим слоном подстилку, но это даст несколько просто замечательных моментов :
1) Вашу игру, в которую уже можно будет поиграть
2) Вы набъете руку (приступая к другой новой игре, вы уже автоматически организуете элементы кода под нужды вашей игры, с каждой новой игрой эта организация будет становиться все совершеннее).
3) На определеном этапе вашего творчества в стиле "solid code" и имея несколько solid code-игр за плечами, вы уже сможете подготовить для себя некую программную базу своих игр, которую уже можно будет назвать "движком". Самое главное - игры должны опережать движок, а не наоборот.
Нас не интересуют ваши движки, нас интересуют игры.
Удачи в начинаниях!
Отредактировано Owl Wilson (15.02.2008 13:09)
Неактивен
2 OwlWilson
ППКС
Твои слова - подтверждение происходящего со мной. Именно, solid code была моей мечтой о программировании: "Блин, а нельзя разве, чтобы это как-нибудь вместе лежало?" - вопрос, которым закончились мои попытки осилить ТАДС.
Именно возможность начать с "чайниковского" программирования, постепенно (на ходу!) изучая более ёмкие и изящные способы организации методов и процедур, помогла (и помогает постоянно) побороть свою лень и продолжать проект.
(еще раз отмечу печальный факт, что С++ для подобного "восхождения" никак не годится, ибо чайниковское программирование там попросту невозможно). Так что IF..THEN..ELSE - действительно гораздо быстрее даст чайнику понять, чего на самом деле он хочет от своей игры (и быстрее получить первые результаты), чем сразу "мокать с головой" в ООП, рискуя не выплыть и бросить эту затею.
Благо, языки, позволяющие плавно переходить от процедурного к объектному и обратно, есть.
(Однако, справедливым остаётся тезис, который высказал где-то тут zerr, о том, что написание первых 80% кода занимает 20% времени, и оставшиеся 80% уйдут на написание оставшихся 20% кода. У меня такая же история вышла с "Шорохами", но, к счастью, уже работа подходит к завершению.)
Owl Wilson написал:
fireton написал:
Зачем?! Есть RTADS, RInform, URQ, QSP - чего там не хватает? Пять минут изучения и уже можно написать простейшую локацию. Программеру и того быстрее.
...
в) Этот момент я называю "IF-аномалией автора-новичка". Абсолютно ВСЕ существующие движки отвергаются в конечном счете. Причины называются разные - итог один.
...
Во-первых, давайте отделим пареное от жареного: менюшные игры можно делать в чём угодно, хоть на PowerPoint, и поэтому поиски новых движков там действительно выглядят странно.
Что же до парсерных... Никакой аномалии здесь нет. Про "пять минут изучения" РТАДС - это красивая сказочка про пушистых белочек, сочинённая программерами якобы для чайников, но на деле итог тоже один: дальше "простейших локаций" дело обычно не заходит. В англоязычном ИФ-мире поэтому новичка сразу честно предупреждают: ТАДС - это очень сложная и громоздкая система, для новичков не рекомендуется.
А без новичков никакого движняка и "притока новых игр" не будет. Вот и получается коровья запятая.
Желание писать текстовую игру у начинающего программиста возникает совместсно со своим (пусть туманным и ошибочным) видением того, как там всё должно работать. Но если не набить свои шишки на простом программировании, то до сложного дойти шансов почти нет, ибо не будет понятно ЗАЧЕМ нужно оптимизировать\увеличивать те или иные куски кода (и потом уже КАК это сделать). В ТАДСЕ всё сложное вроде бы уже сделали добрые дядьки, и остаётся просто вписывать в нужные места нужные слова. Но это лишь кажущееся упрощение. На деле это медвежья услуга.
Такое обучение - это всё равно, что учить ребенка ходить показывая ему чертежи ходящего робота. И как ни крути, изобретать велосипед приходится всем, даже знающим ТАДС. Но тут уже для кого что лучше: изобрести свой велосипед, или разобрать (и потом долго собирать) чужой.
И наконец, ещё один важный нюанс. Все упомянутые платформы созданы с ориентацией на английский язык. И поэтому для русскоязычного автора это в любом случае ходули, ибо в английском есть вещи, которые проще реализовать на русском (и наоборот). Так что все порывы написать свой движок - вполне закономерное стремление не ковылять на ходулях, а сконструировать нормальные ноги.
Отредактировано oleksus (16.02.2008 01:38)
Неактивен
fireton написал:
Ты меня просвети, пожалуйста, но что мешает это делать в RTADS? Пишешь русским языком, игра отвечает тоже вполне по-русски...
Речь о программировании. Ну вот взять хотя бы этот нюанс с оформлением частей объектов ("ручка чашки", "ствол ружья"), обсуждаемое сейчас в ветке ТАДСа. Приходится авторам вставать на ходули, чтобы реализовать такую простую вещь. Взгляните на билдер 6 дней и увидите, как русская падежность реализуется быстро и изящно. Есть там и "зеленая ручка чайника" и "ножка красного стола", причем проще зевка. А всё потому, что автор движка изначально исходил из русской парадигмы, а не натягивал русскую на готовую английскую. Вот вам и велосипед.
Неактивен
goraph написал:
я сделал вывод, что никто из читающих этот форум, не считает себя человеком обладающим литературным талантом
Как же так?! А ПЕТРОВ?! ![]()
Неактивен