В документации Вашего обезьянника - Blitz3D. Но можно проще - обрезать имена до пары-другой символов. Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Пятница, 13 Ноября 2015, 21:28
Сначала, пардон, посмотрел не туда... Проверьте-ка ограничения на длину имен переменных и меток. Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Пятница, 13 Ноября 2015, 13:34
Думаю, проще спросить: "Как научиться программировать в <конкретной системе>, ориентированной на спп?" Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Вопрос, на самом деле, интересен тем, что "карточный движок" (в своей материальной, а не виртуальной ипостаси), достаточно универсален. Я даже пару раз замечал, что в терминах "стол-колода-карта" формируются достаточно хорошие пользовательские интерфейсы для "обычных" программ, подчас симпатичнее тупо "оконных". Но, т.к. в моде "оконные", а реализация карточных начинается с "выкинем все Win-API вкусности", то придется мириться с реализациями через попу. Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Кстати, вопрос к читавшим. Авторы вводят понятие "геймплей", как наличие в игре более одной стратегии поведения игрока. Встречал ли кто-нибудь еще авторов, придерживающихся такого толкования?
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Ramilyanamana, ну, если Вы хотите стать крутым программистом, запомните: нет структур данных кроме массивов! Все эти STL-разносолы - для умственно недоразвитых пользователей. Какую бы фиговину вы не собрали из данных, на самом дне, все равно, будут массивы...
Далее Вы можете продолжать читать мой ответ или сразу перейти к 1-му тому "Искусства программирования" Кнута - там списки разжеваны подробно.
Что такое список? Это набор элементов, каждый из которых, кроме собственно данных содержит ссылку на следующий. "Мышка - за Кошку, Кошка - за Жучку, Жучка - за Внучку..."
Как это засунуть в массив? Если данные целочисленные (или массив состоит из структур), то поле "следующий" (со значением "номер следующего") вполне может быть приписан к данным.
Иначе, например, как у нас выше, где массив строковый - "Внучка", "Жучка".., нужен отдельный массив с номерами.
Далее должна следовать (у Кнута так и есть) лабуда про вставку и удаление элементов, циклические и двусвязные списки и т.п. и т.д.
Наконец, зачем в это влезать, если есть STL? Повторю, STL - для дебилов. Работа со сложными типами данных окупается только тогда, когда эти данные сложны и велики в объеме (поэтому ООП - тоже для дебилов), но когда это так, "стандартные" структуры нас не устроят и надо их писать под себя с нуля.
Просто об этом: Керниган Б., Пайк Р. Практика программирования. Сложно: Ахо А., Хопкрофт Дж., Ульман Дж. Построение и анализ вычислительных алгоритмов.
Добавлено (14 октября 2015, 15:42) --------------------------------------------- P.S. Вообще же, если есть проблема со структурами данных, то ее сначала надо локализовать. В чем проблема: 1. Как использовать списки в программе? 2. Как работают//устроены операции над списками? 3. Как работают/устроены те ("атомарные") операции над списками, которые зависят от представления списка? 4. Непонятно, как разделить на (1)-(3)? Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Среда, 14 Октября 2015, 15:44
martuk, извините. Просто, некоторых людей книги Амосова заинтересовали, и, чтобы не рассылать список по отдельности, дополнил пост.
Что касается ответа, то Вы правы
Цитатаmartuk ()
дендриты множатся не на весы нейрона а на весы самих дендритов
Проводимость связей моделирует долговременную память системы (кратковременная - возбуждение нейронов). Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Среда, 14 Октября 2015, 13:21
P.S. Если кто заинтересуется книгами Амосова, то главные кибернетические:
Искусственный разум, 1969 - общие идеи первого этапа работ; Автоматы и разумное поведение, 1973 - работы, проведенные на первом этапе; Алгоритмы разума, 1979 - общие идеи второго (неосуществленного) этапа работ.
Но есть еще много маленьких брошюрок и статей. Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
какой набор знаний требуется для практического приминения в реальных компаниях игровой разработки.
См. ниже "Команды" и "Вакансии".
Добавлено (13 октября 2015, 09:19) --------------------------------------------- Чем отличается местная "казацкая вольница" от "реальной компании игровой разработки"? В идеале должно было быть что-то вроде:
Предложение Харлана Миллза дает свежее и творческое решение [Mills H. Chief programmer team, principles, and procedures // IBM Federal Systems Division Report FSC 71-5108. Gaithersburg, Md., 1971.]. Миллз предложил, чтобы на каждом участке работы была команда разработчиков, организованная наподобие бригады хирургов, а не мясников. Имеется в виду, что не каждый участник группы будет врезаться в задачу, но резать будет один, а остальные оказывать ему всевозможную поддержку, повышая его производительность и плодотворность. При некотором размышлении ясно, что эта идея приведет к желаемому, если ее удастся осуществить. Лишь несколько голов занято проектированием и разработкой, и в то же время много работников находится на подхвате. Будет ли такая организация работать? Кто играет роль анестезиологов и операционных сестер в группе программистов, а как осуществляется разделение труда? Чтобы нарисовать картину работы такой команды с включением всех мыслимых видов поддержки, я позволю себе вольное обращение к метафорам.
ХИРУРГ. Миллз называет его ГЛАВНЫМ ПРОГРАММИСТОМ. Он лично определяет технические условия на функциональность и эксплуатационные характеристики программы, проектирует ее, пишет код, отлаживает его и составляет документацию. Он пишет на языке структурного программирования, таком как PL/I, и имеет прямой доступ к компьютерной системе, на которой не только производится отладка, но и сохраняются различные версии его программ с возможностью легкой модификации файлов, а также осуществляет редактирование документации. Он должен обладать большим талантом, стажем работы свыше десяти лет и существенными знаниями в системных и прикладных областях, будто прикладная математика, обработка деловых данных или что-либо иное.
ВТОРОЙ ПИЛОТ. Это второе "я" хирурга, может выполнять любую его работу, но менее опытен. Его главная задача - участвовать в проектировании, где он должен думать, обсуждать и оценивать. Хирург испытывает на нем свои идеи, но не связан его предложениями. Часто второй пилот представляет свою бригаду при обсуждении с другими группами функций и интерфейса. Он хорошо знает весь код программы. Он исследует возможности альтернативных стратегий программирования. Он, очевидно, подстраховывает на случай какой-либо беды с хирургом. Он может даже заниматься написанием кода, но не несет ответственности за какую-либо его часть.
АДМИНИСТРАТОР. Хирург - начальник, и ему принадлежит последнее слово в отношении персонала, прибавок к жалованью, помещений и т.п., но на эти дела он должен тратить как можно меньше времени. Поэтому ему необходим профессиональный администратор, заботой которого будут деньги, люди, помещения, машины, и который будет контактировать с административным механизмом организации в целом. Бейкер считает, что на полный рабочий день администратор должен привлекаться лишь в случае, когда отношения с заказчиком определяют существенные юридические, контрактные, отчетные или финансовые требования к проекту. В остальных случаях один администратор может обслуживать две команды.
РЕДАКТОР. Обязанность разработки документации лежит на хирурге. Чтобы она была максимально понятна, он должен писать ее сам. Это относится к описаниям, предназначенных как для внешнего, так и для внутреннего использования. Задача редактора - взять созданный хирургом черновик или запись под диктовку, критически переработать, снабдить ссылками и библиографией, проработать несколько версий и обеспечить публикацию.
ДВА СЕКРЕТАРЯ. Администратору и редактору нужны секретари. Секретарь администратора обрабатывает переписку, связанную с проектом, а также документы, не относящиеся к продукту.
ДЕЛОПРОИЗВОДИТЕЛЬ. Он отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта. Он имеет секретарскую подготовку и несет ответственность за все файлы, предназначенные как для машины, так и для чтения. Все данные для ввода в компьютер поступают делопроизводителю, который регистрирует их или вводит при необходимости с клавиатуры. Листинги вывода также поступают к нему для регистрации и хранения. Результаты самых свежих прогонов всех моделей заносятся в журнал результатов, а предыдущие хранятся в хронологическом порядке в архиве. Жизненно важным для концепции Миллза является превращение программирования "из личного искусства в общественную деятельность" путем предоставления результатов ВСЕХ прогонов всем членам команды и определения всех программ и данных, как общей собственности команды, а не чьей-то личной. Особые обязанности, возлагаемые на делопроизводителя, освобождают активных программистов от рутинных работ, систематизируют и обеспечивают надлежащее выполнение тех рутинных операций, которыми часто пренебрегают, и приближают главное, для чего работает команда - ее программный продукт. Ясно, что предложенная концепция предполагает прогон пакетных заданий. Если используются интерактивные терминалы, в особенности без возможности печати, функции делопроизводителя не сокращаются, но претерпевают изменения. В этом случае он ведет учет всех изменений, вносимых в общий экземпляр программы из личных копий, осуществляет прогон всех пакетных заданий и со своего терминала осуществляет контроль целостности и работоспособности увеличивающегося в размерах продукта.
ИНСТРУМЕНТАЛЬЩИК. Благодаря возможности в любое время редактировать файлы и тексты и пользоваться службой интерактивной отладки команде редко требуется своя вычислительная машина и группа обслуживающего персонала. Но доступ к этим службам должен осуществляться с безусловной быстротой и надежностью. Только хирург может решать, удовлетворяет ли его работа имеющихся служб. Ему необходим инструментальщик, ответственный за обеспечение доступа к основным службам, а также за создание, поддержку и обновление специальных инструментов - в основном, интерактивных служб, которые требуются его команде. У каждой команды должен быть свой инструментальщик, независимо от качества и надежности имеющихся централизованных служб, и его дело обеспечить всем необходимым или желательным инструментом СВОЕГО хирурга, а не другие команды. Инструментальщик обычно пишет специализированные утилиты, каталогизированные процедуры, макробиблиотеки.
ОТЛАДЧИК. Хирургу потребуется набор подходящих контрольных примеров для отладки написанных им фрагментов кода, а затем и всей программы. Отладчик является, таким образом, как противником, разрабатывающим контрольные примеры для системного тестирования, исходя из функциональных спецификаций, так и помощником, готовящим данные для ежедневной отладки. Он также обычно планирует последовательность тестирования и создание среды для тестирования компонентов.
ЯЗЫКОВЕД. Вскоре после появления Algol обнаружилось, что в большинстве вычислительных центров есть один-два человека, поражающих своим владением тонкостями языка программирования. Эти эксперты оказываются очень полезными, и с ними часто советуются. Здесь требуется иной талант, чем у хирурга, который является преимущественно системным проектировщиком и мыслит представлениями. Языковед может найти эффективные способы использования языка для решения сложных, неясных и хитроумных задач. Иногда ему требуется провести небольшое исследование (два-три дня) для нахождения удачной технологии. Один языковед может работать с двумя или тремя хирургами. Вот таким образом 10 человек могут выполнять хорошо дифференцированные и специализированные роли в команде программистов, организованной по образцу операционной бригады.
Но в реале, скорее, 1. в реальной фирме больше менеджеров кулеров и операторов кондиционеров 2. самое неприятное
Цитата
По мере того, как бизнес растет, он неизменно выходит за те рамки, в которых владелец может его контролировать - видеть и чувствовать работу, которую необходимо сделать, и лично следить за его развитием.
Поэтому в любой фирме есть "кулацкий подпевала" - человек, чье мнение (в данном случае, об играх и способах их изготовления) есть закон. Но, обычно, его кругозор и компетенция нисколько не выше, чем у местных "капитанов команд". Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Вторник, 13 Октября 2015, 09:41
как можно стать хорошим разработчиком компьютерных игр без понимая как работает компьютер
Если вы хотите писать для себя - никак (правда, информатика - это лишь "затычка" вместо настоящей науки о компьютерах - кибернетики). Если же вы считаете, что все игры, при всем их разнообразии, сводятся к тщательному соблюдению пары-другой правил с последующим тщательном наполнением, не за столом будет сказано, контентом (для товарного вида), то знание того, "как оно работает" будет даже вредно.
Доходит до смешного:
ЦитатаRaven84 ()
Я честно не фанат такого рода поделок и играть не смогу, но верю, что есть люди, кто в это играть будет. Потому что порой в Плэй Маркете попадаются такие вещи, что никогда бы не стал даже пробовать, но у которых уйма закачек.
ЦитатаIvanKorobko ()
Т.е. "современный программист" якобы должен представить все тупо в уме, написать код, рассчитав(допустим он кодит платформер) всю геометрию уровней, размеры/скорости, противников, и весь интерактив встречающийся по ходу, ну и так же мысленно представляя расположение интерфейсов, их удобство и юзабилити полагаясь лишь на свой третий глаз?) Конечно же разукрасив в коде все красивыми комментариями, чтоб представлять было удобней) А давайте в игры так же играть - поставим ведьмака на паузу, откинемся на кресле, закроем глаза и мысленно пройдем игру самым интересным для нас способом - а то современные игроки тоже обленились - все им во всех красках покажи да расскажи, за ручку проведи, вконце в попу поцелуй - совершенно не осталось места для фантазии и свободы действий)))
Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Понедельник, 12 Октября 2015, 22:08
Меня ведь интересует именно нейроны на их "скудном" уровне.
А "М-модели" Амосова отличаются от "нормальных нейронов" только тем, что он а) изначально не постулирует их "естественность", огульно расставляя формулы для весов и б) не напрягает читателя интегралами. А так, нейроны-нейронами. А уж нейронный ИИ там не только "предсказан", но и построен в железе. Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
martuk, "чистые нейроны" достаточно скучны. Лучше посмотрите развитие идеи в книге Амосова "Автоматы и разумное поведение". Там рассказано, как заставить "нейроны" работать. Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Ramilyanamana, основная ошибка - смешение в одну кучу математики, программирования и библиотечной эрудиции. Сначала надо решить задачу (а не как Вы - неаккуратно скопировали решение для сложения), затем запрограммировать (убрав ненужные операции копирования и приведения), и ни в коем случае не полагаться на то, что библиотека решит все Ваши проблемы (например, обнулит все выделяемые массивы). Вычтите пару чисел на бумажке в клеточку - и ошибка "лишних десяток" сама вылезет. Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Ну, раз пошла такая пьянка, дайте и мне потроллить. Мне кажется, проблема современного геймдева не в том, что всяк начинает с найма рабов под смутные идеи, а в самом непонимании идей. Нельзя смешивать... ... игру, как процесс (в которую можно играть еще в процессе написания и так и оставить недописанной, когда надоест, без какой-либо потребности ее общественном признании, разве что, в мемуарах под старость припомнить), ... игру, как нечто интересное и другим (например, сравните, "Космических палачей" с "Путешествием Пандоры" - с одной стороны супер-рогалик, с другой - настолько хорошо запрограммированная игра, что для нее даже не нужен компьютер; разве интерес сводится к возможности "разгроблять корованы"?), ... игру, как средство самореализации (как известно, первое, на что должен пойти начинающий бизнесмен, это перестать интересоваться процессом производства). Я не вижу никакой возможности примирить эти три желания. Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Могу сказать только за программистов (т.к. таковые на этот Форум не ходят, то это будет откровенным троллингом). Есть два способа решить подобную задачу (на самом деле есть еще пара, но это для крутых старых пердунов): 1. Начать раскладывать ее на более простые ("что надо начинать учить для графики... как лучше представлять карту... и через что организовывать мультиплеер..."), но вполне очевидно, что каждая из упомянутых Вами тем отражена в толстенных талмудах, и можно убить остаток жизни на любую из них. Причем совершенно выпадает промежуточное звено: ведь, Вы вполне понимаете, чем готовая "ртс" отличается от "плаформера", но насколько глубоко "вглубь" Вы можете проследить это "различие"? Ведь, очевидно, что книга "по мультиплееру" может вообще не затрагивать "ртс-проблематику"... Насколько быстро Вам надоест копаться в подзадачах, которые не будут иметь "игрового содержания". 2. Взять что-то похожее и переделать под себя. Но тут Вы сами загоняете себя в угол, напирая на "Дельфи". Ведь, немного понаблюдав за трепыханием начинающих игроделов умные люди и назафигачивали кучу "конструкторов", которые инкапсулирут в себе "наезженные общие места", позволяя только быстренько добавить что-то от себя. Найти исходники "ртс" на "Дельфи", наверное, можно, но кто будет разбирать все эти мегатонны кода?
Всяко рекомендую пару библиографий: "The current State of Human-Level Artificial Intelligence in Computer Simulations and Wargames" "A calculated Strategy: Readings directed towards the creation of a strategic artificial intelligence". Сможете ли Вы их сейчас нагуглить, не знаю (особенно первую). Если надо, вышлю.
Добавлено (30 сентября 2015, 10:50) --------------------------------------------- P.S. Совсем забыл. Основополагающая статья по сути "ртс": СССР, 1969. Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Сообщение отредактировал Gudleifr - Среда, 30 Сентября 2015, 18:40