(3)Если имеется в виду HMM - то нет, не в моих это возможностях. А если героями считать тех, кто сможет с первого раза выиграть во все планируемые игры, то может быть и будут.
(4) HMM были реализованы ещё на 1С 7.7. У меня где-то лежал архив с играми на семёрке. Там, наверное десятка два игр было.... Причем в HMM была анимация, что меня несколько поразило.))))
(11) Пользователь может играть лесными эльфами, охраной дворца и злодеем. И если пользователь играет эльфами то эльфы в лесу, домики деревяные набигают солдаты дворца и злодеи. Можно грабить корованы... И эльфу раз лесные то сделать так что там густой лес... А движок можно поставить так что вдали деревья картинкой, когда подходиш они преобразовываются в 3-хмерные деревья. Можно покупать и т.п. возможности как в Daggerfall. И враги 3-хмерные тоже, и труп тоже 3д. Можно прыгать и т.п. Если играть за охрану дворца то надо слушаться командира, и защищать дворец от злого (имя я не придумал) и шпионов, партизанов эльфов, и ходит на набеги на когото из этих (эльфов, злого…). Ну а если за злого… то значит шпионы или партизаны эльфов иногда нападают, пользователь сам себе командир может делать что сам захочет прикажет своим войскам с ним самим напасть на дворец и пойдет в атаку. Всего в игре 4 зоны. Т.е. карта и на ней есть 4 зоны, 1 - зона людей (нейтрал), 2- зона императора (где дворец), 3-зона эльфов, 4 - зона злого… (в горах, там есть старый форт…)
(15)...Так же чтобы в игре могли не только убить но и отрубить руку и если пользователя не вылечат то он умрет, так же выколоть глаз но пользователь может не умереть а просто пол экрана не видеть, или достать или купить протез, если ногу тоже либо умреш либо будеш ползать либо на коляске котаться, или самое хорошее... поставить протез. Сохранятся можно...
Согласен, что игры интереснее писать нежели какие-то стандартные "программистские дела". Когда-то решил написать 2048 на 7.7 (https://infostart.ru/public/401256/), пришлось поломать голову над алгоритмом немного.
(14) Про алгоритм "схлопывания" чисел. После написания в лоб, выяснилась ошибка при которой не все "схлопывалось", что должно. На просторах инфостарта находил игру, где это выдавалось за "фичу" игры.
(14)
(18)Именно затруднить или облегчить, нет. Я игрался с вероятность появления 2 и 4, чтобы органично игралось. В первых вариантах она была одинаковая и сильно заметно было, что что-то не так с игрой.
(20)У меня изначально идея была понять на сколько реально дойти до конца игры. Потому я и сделал сохранения, чтобы в случае ошибки можно было откатиться и переиграть.
Процедура НачалоНаКлиенте()
...
Генератор = Новый ГенераторСлучайныхЧисел(ТекущаяУниверсальнаяДатаВМиллисекундах());
Для с = 1 По 3 * НастройкиИгры.ШиринаПоля Цикл
Данные.Добавить(Цифры[Генератор.СлучайноеЧисло(0, ?(НастройкиИгры.Сложность = 0, 3, ?(НастройкиИгры.Сложность = 1, 5, 8)))]);
КонецЦикла;
....
КонецПроцедуры
Показать
Я завис на такой конструкции, разбирая код. Воспринимается очень сложно часть внутри цикла.
Такой код можно заменить на следующий:
Процедура НачалоНаКлиенте()
...
Генератор = Новый ГенераторСлучайныхЧисел(ТекущаяУниверсальнаяДатаВМиллисекундах());
Сложность = СоответствиеУровняСложности.Получить(НастройкиИгры.Сложность);
Для с = 1 По 3 * НастройкиИгры.ШиринаПоля Цикл
Данные.Добавить(Цифры[Генератор.СлучайноеЧисло(0, Сложность)]);
КонецЦикла;
...
КонецПроцедуры
//Раздел инициализации переменных
СоответствиеУровняСложности = Новый Соответствие;
СоответствиеУровняСложности.Вставить(0, 3);
СоответствиеУровняСложности.Вставить(1, 5);
СоответствиеУровняСложности.Вставить(2, 8);
Показать
В моем виде код легче читаем, быстрее адаптируем, и переменную Сложность рассчитываем один раз, а не внутри цикла.
О подобном способе программирования я написал в своей публикации https://infostart.ru/1c/articles/1768304/
(24)Согласен, только вместо соответствия лучше использовать массив. А еще лучше - просто вынести тернарный оператор за цикл и заменить его на Если, и не связываться с дополнительными коллекциями. Это не тот случай, когда требуется оставлять возможность кастомизации))).
Это не тот случай, когда требуется оставлять возможность кастомизации))).
Я не понял, почему не нужно кастомизировать алгоритм и одновременно использовать нечто для хранения данных?
Я рассуждаю так: если игра на одного человека, то массив для хранения данных не нужен - табличный документ выполняет одновременно роль хранителя данных и представления данных.
Если игра локальная на двоих или троих людей, тогда массив для хранения данных будет обязательным для перерисовки/новой отрисовки табличного поля у каждого игрока после очередного хода другого игрока - то есть массив это буфер данных. А в этом случае интересно будет усложнить настройки игры - расширить поле, расширить уровень сложности (сделать вариантов 10 и больше). Для 10 вариантов уровней сложности писать Если/Тогда будет не комильфо.
Использовать массив вместо соответствия можно лишь для числовых уровней: 0,1,2 и т.д. А если рассмотреть уровни "слабый", "новичок", "профи", "средний" - то подойдет коллекция Соответствие. Универсально для всех случаев.
(31)И снова Вы правы, но... Все-таки это не та игра, где гибкие настройки значительно повысят качество/интерес/реиграбельность. А для казуальных игр (как эта) обилие настроек, вообще говоря, - зло. Игроку достаточно 2-3 варианта, а не 10-20, он не должен думать над настройками, а должен поскорее начать играть. Отдельный массив для данных нужен, вспомним про MVC. Здесь массив данных - M, а табличный документ - V. Вдобавок я уверен, что доступ для чтения к элементу массива многократно быстрее, чем к ячейке документа, плюс - защита от "повреждения" текста в ячейках документа, плюс - возможность переделки ТабДок на другой вид отображения. Использовать Соответствие для уровней сложности, заданных в текстовом виде - самый правильный вариант, но зачем их создавать в текстовом виде? Преимущества минимальны, но зато мы лишимся упорядочивания (чем больше номер, тем сложнее). И опять же - не та игра, чтобы так усложнять. Если же говорить о качественной архитектуре программного модуля, то самым правильным способом будет вынести в отдельную функцию получение нужного значения в зависимости от настроек сложности. И назвать переменную не "Сложность", а "ИндексКоличестваВариантовДоступныхЦифр" - это более правильно описывает смысл этого значения. Что будет внутри такой функции - каскад "Если" (аналог switch...case), чтение из Соответствия, или что-то другое - уже не так важно. Кстати, именно каскад "Если" - наиболее универсальный вариант.
Все-таки это не та игра, где гибкие настройки значительно повысят качество/интерес/реиграбельность.
Да-да, все верно. Буду ждать следующих ваших игр, чтобы развивать мысль.
Я на основе вашей игры стал учить программированию своего сына. Он загорелся, видя что может управлять параметрами игры. Складывать два числа, чтобы в сумме было 10 - это легко. Посложнее это когда надо получить 23 - при этом у игроков игра будет развивать внимательность, счет в уме и т.д. Играть в паре интереснее - из-за соревновательности и непредсказуемости - "твое" число вдруг "съедает" другой игрок - приходится начинать поиск подходящей пары чисел снова.
Полагаю, что на табДоке можно реализовать игру Мемо для всей семьи.
(0) Значение в ячейке можно получить через конструкцию Число(Таб.ТекущаяОбласть.Текст).
Не понятно, зачем использовать массив для хранения значений ячеек?
Если не использовать массив, то можно игровое поле делать квадратным или вообще любой длины и высоты.
(25)Методически не очень хорошо использовать табличный документ (т.е. средство представления результата) в качестве хранилища данных. И, да, массив может содержать данные для поля любого размера и соотношения сторон.
(36) у меня и анпак нет. Представляете весь этот процесс погружения в неизвестность - найти и изучить анпак, затем залезть в исходники 7.7 - чтобы среди многого что-то интересное и полезное вытащить - сложный алгоритм чего-либо....этот процесс - для меня болото, для другого человека возможно нет. Экономика быстрее развивается, когда каждый вносит свой небольшой вклад. Не обращайте внимание на лирику, тут смысл сказанного важен.
(33)
(38)
Неее. Исходники - это уже сами доставайте. У меня та же проблема. Найти где-то в архивах платформу 7.7, поставить, И повытаскивать исходники. А мне оно надо? У меня на работе сейчас веселье, перетащить данные из УТ 10.3 в УТ 11.4. Если уж по правильному, допустим вы хотите портировать какую-нибудь игру из 7.7 в 8.3 - нужно её запустить в оригинале, посмотреть, как оно работает, и уже потом кодить на 8.3. Например, HMM (Герои Меча и Магии) на 7.7 реализованы интерактивно. Там также движется герой, такие-же подобия лесов, такие-же подобия врагов, встречаясь с которыми ты сражаешься. (Вот только, собственно, сами сражения не реализованы, но это уже мелочи). Вообще, она меня весьма приколола. Может, конечно, убого по сравнению с оригинальными Героями, но всё же...
Так что, всё сами....
Тем более, изначально, вы просили ссылку на игры. Ссылку я дал. )
Я добавил в игру поле для задания параметра - у вас по умолчанию сумма чисел должна быть равной 10 - я же задаю параметр. Плюс научился подсвечивать ячейки - выделять цветом и толстой рамкой, какие ячейки дают в сумме 10 - как раз для этих целей удобен массив для хранения данных...
...Плюс думаю в сторону представления двумерных массивов через табличный документ: хранение в массивах, представление в табличном поле, как у вас в игре...
(32)Мне, с одной стороны, приятно, что моя игра дала толчок для таких модификаций, но, право же, есть гораздо более интересные игры для этого, в том числе и на этой площадке. А подсвечивание ячеек слишком облегчает игру, делая ее менее интересной))))
Мне, с одной стороны, приятно, что моя игра дала толчок для таких модификаций, но, право же, есть гораздо более интересные игры для этого, в том числе и на этой площадке. А подсвечивание ячеек слишком облегчает игру, делая ее менее интересной))))
да-да , все понимаю. вы хотите понять мой интерес? - у меня их несколько - и они сошлись в одном месте - один из интересов научить ребенка программированию. Я вижу как "подсвечивание" ячеек помогает в этом процессе.