Игра "ЛОГИКА" (в Delphi)

[KingArthur]

Появилась идея.

Допустим хочу я соеденить А3, В1, В2

Делаю это таким образом:




Нажимаю на кнопку >>> <Создать контакт между элементами>

(потом появляються кнопки: <Создать дорожку>, <Создать контакты>, <Сохранить контакт>, <Стереть контакт>)


Нажимаю кнопку <Создать дорожку> и соеденяю А3,В1 и В2 линиями

После этого нажимаю кнопку <Создать контакты> рисую одним кликом контакт К1

После этого нажимаю кнопку <Сохранить контакт> и дорожка готова и записана структура в один

RECORD (из динамической цепи которая состоит из указателей(pointers))

при этом логика сохраняетса отдельно

короче примерно так

все ЛЕВЕЛС буду хранить в типизированном файле

[mutabor]

Можно и так, хотя если честно принцип не совсем ясен, но то что одним кликом - это хорошо, кнопок желательно делать поменьше а автоматизации побольше.

Несколько советов:
Дорожку можно хранить как набор ключевых точек (конечные, повороты). Таким образом на хранение выше нарисованной дорожки понадобится шесть элементов типа TPoint, три конца, два поворота, одно разветвление , а программа уже по ним будет линии рисовать.

Насчет игрового поля (логика):
Вне зависимости от кол-ва элементов, и размеров матрицы 3х3, 5х5, или 10Х10, все на поле должно быть в фиксированных местах. Колобок может останавливаться в определенных точках, элементы находиться в опр. ячейках, основания рук также. Все поле представляет из себя как-бы разлинеенную поверхность, своего рода матрицу, где для каждого есть свое место, и в другое его не впихнешь, для счета и кол-ва жизней тоже.
Если понять этот принцип, сделать игру будет намного легче.

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

[KingArthur]

спасибо за советы я примерно так и собираюсь сделать

Сообщение от mutabor

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

Ты имеешь в виду что мне нужно использовать принцип модуляризации. Так и сделаю. А если так не сделаю и все в один UNIT смешаю, то этот проэкт доценты даже смотреть не будут.

Кстати как бы ты сделал локический формат уровня?

Ведь нужна еще определенная последовательность переменных величин (VAR)

Kontakt.jpg

для самой логики я написал бы так:

A3:=A1 AND A2;
B1:=A3;
B2:=A3;
B3:=B1 AND B2;

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

для [A3:=A1 AND A2] и [B3:=B1 AND B2] я могу уже за ранее написать функции но остальное тяжелее. здесь я думаю нужно связывать переменные величины в зависимости их состояния. допустим в RECORDE величины B1 стоит IN а в A3 стоит что это OUT. После того как я соеденю мышкой B1 c A3 или A3 c B1 то прога сама поймет что B1:=A3 (благодаря IN и OUT знакам). Но если схема большая и все соеденено запутаннее, то это реализовать тяжелее.

Может я думаю слишком сложно и эту проблему можно легко решить?


sorry если мой русский не понятен. я програморование итд изучал в германие. поэтому незнаю некоторых слов. да и на русской клаве только недавно начал писать. вес этот техт я написал за 35минут.

спасибо за внимание и советы

[alexBlack]

На случай, если не заметили похожая тема

http://www.programmersforum.ru/showthread.php?t=16704

По вопросу. Изменение состояния должно повлечь рекурсивный обход всех связанных узлов. Нужно только следить чтобы не было зацикливания.

Еще одна проблема. Элементы И-НЕ можно соединить так, что получится генератор. Здесь нужно будет решить - будет ли программа работать с такими схемами или их просто можно игнорировать.

[KingArthur]

Сообщение от alexBlack

На случай, если не заметили похожая тема
http://www.programmersforum.ru/showthread.php?t=16704

ага заметил. только если я не ошибаюсь там обьекториентированный подход. обьекториентированние мне в моем проэкте использовать запрещенно

Сообщение от alexBlack

По вопросу. Изменение состояния должно повлечь рекурсивный обход всех связанных узлов. Нужно только следить чтобы не было зацикливания.

Мне кажеться ты меня не правильно понял. Основная проблема заключаеться в порядке действий. допустим прога должна знать откуда именно начинать зачислять переменные величины.
например именно в этом порядке:

A3:=A1 AND A2;
B1:=A3;
B2:=A3;
B3:=B1 AND B2;

[alexBlack]

Сообщение от KingArthur

Мне кажеться ты меня не правильно понял. Основная проблема заключаеться в порядке действий. допустим прога должна знать откуда именно начинать зачислять переменные величины.
например именно в этом порядке:

A3:=A1 AND A2;
B1:=A3;
B2:=A3;
B3:=B1 AND B2;

Да нет, по-моему, и я о том же. Отбросим ООП. В record храним еще и вычисленные ранее значения 0/1 для всех контактов. Они уже установлены при загрузке очередного уровня или вычисляются при загрузке по известным входам (признак IN для несоединенных контактов). Допустим, как в примере, мы соединяем A3 с B1 и B2. Значение в A1 уже известно. Изменяется B1 - пересчитывается B3, и так далее - для всех связанных узлов. Т.е. расчет начинается с узла, в котором произошло изменение уровня при очередном действии игрока.