KRIEGSSPIELE!

GUDLEIFR СОЛДАТИКИ FORTH gudleifr.h1.ru
 
ФорумФорум  КалендарьКалендарь  ЧаВоЧаВо  ПоискПоиск  ПользователиПользователи  ГруппыГруппы  РегистрацияРегистрация  ВходВход  

Поделиться | 
 

 Главное - не быть "программистом"

Перейти вниз 
АвторСообщение
Gudleifr
Admin
avatar

Сообщения : 707
Дата регистрации : 2017-03-29

СообщениеТема: Главное - не быть "программистом"   Вс Май 07, 2017 11:13 am

Как пишутся компьютерные игры? Нет, когда-то, игру сначала придумывали, а потом программировали, но те времена счастливо канули в лету. Вот пара перлов с Форума "современных игроделов":
Цитата :
* Т.е. "современный программист" якобы должен представить все тупо в уме, написать код, рассчитав (допустим он кодит платформер) всю геометрию уровней, размеры/скорости, противников, и весь интерактив встречающийся по ходу, ну и так же мысленно представляя расположение интерфейсов, их удобство и юзабилити полагаясь лишь на свой третий глаз? Конечно же разукрасив в коде все красивыми комментариями, чтоб представлять было удобней.
* А давайте (сарказм.- G.) в игры так же играть - поставим ведьмака на паузу, откинемся на кресле, закроем глаза и мысленно пройдем игру самым интересным для нас способом - а то современные игроки тоже обленились - все им во всех красках покажи да расскажи, за ручку проведи, в конце в попу поцелуй - совершенно не осталось места для фантазии и свободы действий.
* Большая часть проблем решается визуальными компонентами. Мне обычно хватает пару часов на создание всего этого. (Если без доп функций, типо выводов графиков, рассчетов, обработки данных и тп).

Как же происходит "программирование" сейчас?

Сначала выбирают два опорных "столпа": существующую компьютерную игру, которая "почти годится", и некоторый ее идеальный вариант ("такой же, но с перламутровыми пуговицами"). Затем начинается процесс "совместной разборки" обоих программ - углубления в их внутреннее устройство. Разборка длится до тех пор, пока не становится возможным, на основе понятых частей старой игры, с добавлением осмысленных модулей новых, собрать нечто работающее.
Иногда это просто, например, выясняется, что старая игра имеет встроенный редактор, возможности которого вполне обеспечат внедрение "инноваций". Или файлы ресурсов (контента) вполне могут быть быть хакнуты без правки программного кода. Но, иногда, при разборке от старой игры остается только "пшик". Или идея новой игры признается несостоятельной.

Метод "поиска наибольшего общего делителя" двух игр сам по себе ни хорош и не плох. Но есть подводные камни.

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

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


Последний раз редактировалось: Gudleifr (Ср Июл 12, 2017 10:25 am), всего редактировалось 1 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

Сообщения : 707
Дата регистрации : 2017-03-29

СообщениеТема: Re: Главное - не быть "программистом"   Пн Май 08, 2017 11:35 am

Замкнутый круг геймдева.
1. Конечно, если есть идея собственно компьютерной игры, то ее можно быстренько реализовать на каком-нибудь BASIC, строк этак в двадцать. Подобавлять туда фич, пока размер не вырастет до нескольких сотен строк - и забыть/выкинуть. Но такие игры уже никого не интересуют, нужен гигабайтный контент.
2. Управление гигабайтным контентом само по себе целая наука, и процесс коллективного творчества.
3. Это коллективное творчество быстро становится работой, не оставляющей возможности поиграть. Требуются конструкторы, позволяющие написать что-то веселое строк в двадцать... Далее см. 1.
***

Более того, с каждым витком этого круга мы все дальше уходим от реальной жизни:

Вот, например, на КВН в 2007 году радостно ржут над тем, как был бы поражен Билл Гейтс, увидев убогую советскую игру "Ну, погоди!" 1984 года.



А, вот герой фильма "К-9" 1989 года играет в подобную игру (Manhole) и почему-то не кажется ни убогим, ни отсталым:



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

1. Допустим, есть работяга, целый день проводящий "в поле", который вечером хочет расслабиться.
2. Есть программист, умеющий заставить компьютер играть и расслаблять, который хочет помочь работяге.
3. Есть игрок, которому эти расслабление за компьютером интереснее работы.
4. Есть бизнесмен, который видит потенциальные возможности рынка игроков.
5. Есть игродел, который хочет втюхать бизнесмену свой продукт.

И кто-то хочет воспринимать копошение #5 всерьез? А кушать что будем?


Последний раз редактировалось: Gudleifr (Вс Сен 03, 2017 11:45 am), всего редактировалось 2 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

Сообщения : 707
Дата регистрации : 2017-03-29

СообщениеТема: Re: Главное - не быть "программистом"   Чт Июн 08, 2017 11:19 am

К чему это приводит?

Для чего игра пишется (на собственном опыте; как пример того, что нельзя гнаться за всем сразу и перескакивать с одного на другое)?

1. Мне плевать, кто и что написал до меня. Я пишу потому, что не могу не писать.
2. Я свободно ориентируюсь в том, что написали другие. И заведомо смогу не хуже. Почему бы не урвать свой кусочек славы, денег...
3. Я перерыл многое из написанного другими, но так и нашел того, что заставило "душу развернуться, а потом опять свернуться". И мне не важно, я напишу подобное или кто другой, главное, я хочу в это играть.
4. Другими написано много дельного и много ерунды. Я даже не хочу в это вникать. Но обсуждение этой вот конкретной темы (или рождение нового проекта) слишком похоже на игру само по себе и я хочу в нее поиграть.

И остался только п.2b - "Только бабки! Утром деньги - вечером стулья!"?
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

Сообщения : 707
Дата регистрации : 2017-03-29

СообщениеТема: Re: Главное - не быть "программистом"   Чт Июл 13, 2017 9:00 pm

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

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

С переносом внимания бизнеса с запросов нормальных людей на рынок задротов-ботанов стало важнее не наличие в игре, собственно, игровых идей, но копипастинг обязательных элементов из других игр. Что в конце концов свелось к AAA хреновым симуляторам жизни с элементами а ля Марвел. Соответственно, игры для креативного класса (быдла).
***

Быдло - массовый потребитель. Креатитвный класс.
Форумный планктон - посетители, считающие, что с Форумом они "весят" больше, чем без Форума.
Мультимедиа продукт - то, что называет игрой быдло. Спам-атака на примитивные чувства игрока. Настоящая игра - там "на донышке".
Компьютерная игра - обычная игра, к которой прицепили компьютер.
Хорошая КИ - КИ, в которой компьютер делает то, чего нельзя достичь без него.
Плохая КИ - КИ, в которой компьютер делает то, что возможно и без него (картинки, музыка, виртуальная реальность, симулятор жизни...).
Старая игра, настоящая игра - игра, написанная для себя.
Составные части игры - идея, реализация и общественное мнение.
Быдлоигра - игра, в которой главное - общественное мнение. Создавались путем компиляции "опробованных" методов: WS3D, DuneII, PG, SP, H M&M, X-Com...
Геймплей - бессмысленная характеристика мультимедийного продукта.
Свобода - то, от чего отказывается игрок, садясь за КИ.
Реализм КИ - адекватность игровых переживаний реальным.
Искусство КИ - профанация.
Полное 3D - замена красивых картинок безвкусными моделями.
Смайлик - признак неуверенности в своей позиции.


Последний раз редактировалось: Gudleifr (Вс Сен 03, 2017 11:46 am), всего редактировалось 1 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

Сообщения : 707
Дата регистрации : 2017-03-29

СообщениеТема: Re: Главное - не быть "программистом"   Чт Июл 13, 2017 9:02 pm

Я знаю два способа играть интересно и бесплатно:

1. По-минимуму
Играете в своем дворе, классе, студ.группе, лаборатории, офисе. Сами придумываете, сами изготовляете необходимые настольные, спортивные, компьютерные принадлежности. Развиваете игру в игре. Надоедает - выбрасываете и придумываете новую игру. Со двора не выносите. По старости - описываете в мемуарах. См. "Кондуит и Швамбрания".

2. По максимуму.
Устраиваетесь на хорошую работу. Любите ее. Находите в ней игровые моменты и развиваете. Дорастаете до должности, когда вам платят за вашу игру, точнее за ее полезный побочный эффект. Ср. "Наука - есть удовлетворение своего любопытства за государственный счет".
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

Сообщения : 707
Дата регистрации : 2017-03-29

СообщениеТема: Re: Главное - не быть "программистом"   Вс Сен 03, 2017 11:08 am

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

Итак, суперхардкор. Нужно осилить, писаясь и плача, всего две книжки:

1. В.М.Брябрин, Программное обеспечение персональных ЭВМ, 1988 - DJVU, 2.75Мб.
Конечно, в те годы книжка писалась, как введение для пользователей (и даже тогда проигрывала в этом качестве печально известной книге Фигурнова), но где те пользователи? Где те компьютеры? За исключением некоторых вещей, которые можно кое-как сэмулировать на современном компьютере, все придется принимать на веру и практически абстрактно. Однако... Со смысловой точки зрения все осталось по-прежнему. Если тогда операционная система кое-как была способна на какую-то фичу, то, в большинстве случаев, "дальнейшее развитие" свелось к тому, чтобы доказать "сообществу", что красивое графическое оформление этой фичи целиком компенсирует неспособность сделать ее более удобной/разумной.
Так что, просто просмотреть эту книжку: мол, это так устарело, что и читать не буду, а то - очевидно тоже самое, что я уже понял,- ни в коем случае нельзя. Нужно тщательно пересчитывать функции и представлять насколько они покрывают область запросов пользователя. Что пользователь должен был делать сам, а что тогда мог компьютер.
Чтобы было легче, попробуйте посмотреть какие либо фильмы тех времен, те же "Военные игры" по Бишофу или технотриллеры по книгам Крайтона. Сойдут даже "Коломбо" и "Она написала убийство".

2. Л.Бек, Введение в системное программирование, 1988 - PDF, 27.6Мб.
Тут будет полегче. Хотя, описываемые тут компьютеры тоже вымерли, но, по крайней мере, многие термины употребляются до сих пор.

Итак, осилили. Теперь Вы знаете то, что все уже забыли. Сначала, для психологической разгрузки надо хорошенько поржать (конечно, Вас уже немножко посмешило описание Windows 1.0 у Брябрина). Берем любую книгу/журнал тех времен с красочным описанием возможностей компьютеров будущего (например, "Техника-молодежи" номер 5 за 1988 год или "В мире науки" - 12 1987). Приложите это к тому, что прочли в книгах - не правда ли, современная реализация этих чудес выглядит сделанной через задницу?

Что дальше? По уму, получив какую-то задачу, Вы, имя в голове примерную схему "что из чего следует" можете найти "что-то из современного", что бы заткнуть эту дыру. Например, написать и запустить что-то из книги Ч.Уэзерелл, Этюды для программистов, 1982 - DJVU, 9.74... Но тут современные производители подложили свинью: мол, хочешь программировать - купи обезьянник, без него ты даже не найдешь в какое место свои программы запихивать... Тут проще кому-нибудь на хвост сесть... и убедиться, что ваши тайные знания основ программирования никому не нужны... Или..?

P.S. Но, зато, в хорошей компании - DJVU, 9.41Мб (Лекции лауреатов премии Тьюрига).


Последний раз редактировалось: Gudleifr (Ср Дек 06, 2017 3:01 pm), всего редактировалось 3 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

Сообщения : 707
Дата регистрации : 2017-03-29

СообщениеТема: Re: Главное - не быть "программистом"   Вс Сен 03, 2017 11:41 am

А ЧТО, ВООБЩЕ, ДОЛЖЕН ЗНАТЬ ПРОГРАММИСТ?

ГЛАВА ПЕРВАЯ. ОСНОВНЫЕ ПОНЯТИЯ
Аксиома 1: Программистов не бывает. Есть только системщики и пользователи. Системщики бывают математикам или электронщиками, а пользователи - физиками или лириками.
Следствие 11: Программирование - есть создание кибернетических машин, максимум энтропии которых соответствует останову при получении правильного результата.
Следствие 12: Машина понимает только действия и значения. Любые абстракции - функции, объекты, компоненты, системы, языки - это лишь многоуровневые системы имен, (обозначающих некоторые наборы действий, значений и других имен), удобных для решения некоторых конкретных задач.
Следствие 13: Если запись решения на языке программирования оказывается более путаной и длинной, чем на человеческом языке, значит, программист не владеет нужным языком программирования.
Следствие 14: Тестирование программы не может доказать отсутствия в ней ошибок.
Следствие 15: Сложность программы определяется только ее размером.

ГЛАВА ВТОРАЯ. КУРСЫ
Аксиома 2: Нельзя научить решать задачи, но можно научиться решать задачи.
Следствие 21: В обучении программированию наглядность курсов обратно пропорциональна полезности. Ибо программирование - умение абстрагироваться от наглядности.
Следствие 22: Знания/умения программиста никак не могут иметь ценности за пределами конкретной задачи.
Следствие 23: Сначала научись что-то делать и только потом учись это программировать.

ГЛАВА ТРЕТЬЯ. ЗАДАЧИ
Аксиома 3: Человек решает задачу. Человек программирует решение для машины. Человек знает необходимые детали устройства машины. Эти три умения программиста между собой никак не связаны
Следствие 31: Любое решение программистской задачи можно записать языком математики. Т.к. машина является материальным представлением языка математики, то существует способ перевода решения задачи на язык машины. Этот способ называется языком программирования.
Следствие 32: Языки программирования в равной степени могут созданы теоретиками, практикам или самим программистом.
Следствие 33: Если результат можно рассчитать, это хорошо, если нет - нужно использовать таблицы. Только, если и это невозможно, можно применять сложные структуры управления языка программирования.
Следствие 34: Язык программирования выбирается/изобретается таким, чтобы как можно больше результатов рассчитать.

ГЛАВА ЧЕТВЕРТАЯ. САМОДЕЛКИ
Аксиома 4: Мы живем в Матрице, которую называем культурой.
Следствие 41: Машина должна исполнять не ту работу, которую легко запрограммировать, но ту, которую человеку исполнять сложно или неинтересно.
Следствие 42: Легкость программирования определяется не интеллектуальностью машины, но ее простотой.
Следствие 43: Машины/языки развиваются в двух направлениях: "понимают, что вам надо" - интерпретаторы, и "знают лучше вас, что вам надо" - компиляторы. И это развитие далеко опережает реальные потребности программиста.
Следствие 44: Простейший способ написать что-то сложное - переложить работу на пользователя.
Следствие 45: Объединять простые модули в сложную программу удобнее всего средствами операционной системы. Не стоит это делать вручную (изобретать для этого сложные языки).

ГЛАВА ПЯТАЯ. ПРОЕКТЫ
Аксиома 5: Очень небольшой процент рабочего времени программист тратит на написание программ. Гораздо больше уходит на то, чтобы заставить их работать. Первое приятно и престижно, второе - нет.
Следствие 51: Ни один программист не любит сложных программ. Пропадает даже та маленькая толика удовольствия, которая ему положена.
Следствие 52: Еще эфемернее предстает возможность научиться программировать на большом проекте. Неразрешимые проблемы встретятся раньше, чем появятся первые результаты.
Следствие 53: Единственный способ написания хорошей программы - полное выбрасывание исходников, как только они перестают нравиться.


Последний раз редактировалось: Gudleifr (Чт Фев 08, 2018 7:39 pm), всего редактировалось 2 раз(а)
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Gudleifr
Admin
avatar

Сообщения : 707
Дата регистрации : 2017-03-29

СообщениеТема: Re: Главное - не быть "программистом"   Вс Сен 03, 2017 11:49 am

БЫДЛОКОДЕРСТВО КАК НЕПОНИМАНИЕ ДУАЛИЗМА

Цитата :
Есть, например, юниты, у каждого - набор свойств и навыков (а-ля Герои - Минотавр имеет "Храбрость", лазутчик - "Отравленный выстрел")
Возникает, скажем, такая ситуация: лучник стреляет в пехотинца, применяя скилл "Стрельба". Пехотинец имеет навык "Щит", поэтому урон снижен. Однако лучник не простой, он имеет также способность "огненная стрела", поэтому пехотинец загорается. Но будь у пехотинца свойство "Несгораемость", не подгорел бы.
Все юниты, эффекты, навыки - отдельные объекты, с набором методов и, тем более, их реализацией, я не могу определиться.
Как бы вы стали организовывать подобное взаимодействие? Т.е. срабатывание (применение) одного скилла может активировать другой и так далее. Где какой код писать (идейно)?
Интересно, много ли осталось людей, понимающих, что если бы на этот вопрос существовал ответ в форме, ожидаемой спрашивающим, т.е. "тупо создайте темплейт объекта типа <дурацкий факт> и тупо используйте его метод <логическое осмысление>", то программирование не было бы искусством?

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

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

Это знают все. Особенно изобретатели всяких там языков "логического", "автоматного" и прочего "хитрого программирования". Но подавляющее большинство почему-то забыло, что ВСЕ языки программирования, даже какой-нибудь ALGOL-60, УЖЕ являются машинами для подобных рассуждений. Наличествующие в той или иной мере в каждом языке механизм данных и процедур уже готовы к решению "рассуждательной проблемы". Механизм данных обеспечивает накопление фактов (прямая цепочка), механизм процедур - их запрашивает и использует (обратная цепочка). Все остальное, что есть в языке - способ как-то ограничить "область перебора", т.е. разбить и факты, и действия на изолированные группы, в которых и осуществлять логические вычисления. Т.е. не проверять все условия боя на мечах при расчете космических перелетов, и не проверять, как влияет бузина в огороде на поведение дядьки в Киеве.

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

Существуют ли системы, при изобретении которых программист вынужден все-таки, однозначно определить, каким способом он будет рассуждать? Этот вопрос целиком относится к вопросу ограничений машины, для которой пишется программа. Противопоставление машины с хранимой программой (изменяющей свой код при получении новых фактов) машине с произвольным доступом к памяти (способной гибко запрашивать данные). Или, даже, противопоставление ОС, основанных на процессах (ожидающих готовности данных), ОС, основанным на сообщениях (где данные вызывают действия). Применение одного из методов в этих случаях диктуется железом. Но! Для программиста отличие одной машины/ОС от другой совершенно ничего не определяют! Эквивалентность этих машин/ОС многократно проверена и местами строго доказана! Так, что привязывая свою логику к WIN-объектам и/или пытаясь описать в XML-файлах все сущее, быдлокодер, по сути, отказывается от решения программистской задачи, пытаясь тупо приспособить вчерашнее решение к сегодняшней задачи.
Вернуться к началу Перейти вниз
Посмотреть профиль Online
Спонсируемый контент




СообщениеТема: Re: Главное - не быть "программистом"   

Вернуться к началу Перейти вниз
 
Главное - не быть "программистом"
Вернуться к началу 
Страница 1 из 1

Права доступа к этому форуму:Вы не можете отвечать на сообщения
KRIEGSSPIELE! :: Заметки о простых играх-
Перейти: