Aquaria уже Open Source!

Имхо твой вариант читается сложнее. В первом сразу видно что нужно, чтобы произошло событие (lamp = red), а во втором надо вчитываться. А если таких конструкций в коде много - это уже мозг разрушает:)

Я ещё раз повторюсь, проблема не в том, как это реализовать, плагины можно и на сях писать. Проблемы тут 1) понять, что так писать - в перспективе ведёт к предельной неразберихе, и 2) (основное) придумать, как разбить сложные взаимосвязи на более простые блоки (либо крупные логические единицы типа электродвигателей/блоков управления, либо более мелкие типа цепей и токов).

>2) (основное) придумать, как разбить сложные взаимосвязи на более простые блоки (либо крупные логические единицы типа электродвигателей/блоков управления, либо более мелкие типа цепей и токов).

Да-да-да, ты приближаешься к пониманию ООП. С наследованием и инкапсуляцией.

Одобряю!

>Да-да-да, ты приближаешься к пониманию ООП. С наследованием и инкапсуляцией.

Вот только магические слова «ООП, наследовние, инкапсуляция, абстракция итд» не являются залогом правильного проектирования. Наоборот, можно начитаться паттернов, налепить их везде, а в результате получить не менее кривую программу, которая работает на честном слове.

Кстати, кто посоветует хорошую книжку по проектированию, чтобы не делать глупостей (хотя бы частично) при написании программ. ООП приветствуется, знание программирования есть, опыт тоже (часто печальный)?

Да, сложнее, я ж говорю, не факт - наколенный вариант. Я просто попытался показать, что программа должна быть больше завязана на реальную спецификацию, чтобы её легко можно было менять. Есть электрическая схема - эмулируем элементы (как какой-нибудь electronic workbench) и реагируем на изменения.

Я скорее должнен был бы показать другую проблему, когда switch1 и switch2 в разных блоках. Скажем, в «speed_control» и «engine_control». Тогда напрямую к switch из check_lamp2() обращаться - очень-очень плохо. Надо обрабатывать сигналы блоков «movement_denied» и «engine_on», а уж от каких switch оно там зависит - дело конкретного типа engine.

P.S. И кстати, все «cascade» тут - лишние сущности, они должны автоматически рассчитываться исходя из зависимостей.

Хочешь сказать, в вышеуказанных исходниках нет наследования и инкапсуляции?

Я не про наследование и инкапсуляцию. Я про то, что дизайн программы должен быть понятен и читаем. Должен отражать предметную область (см. DDD) - по программе/данным должно быть понятно, где это в спецификации, и наоборот. Что изменения в предметной области, новые условия должны логично и просто вписываться в исходный код, а не требовать 20 измений в разных местах, и ещё не факт, что заработает. Что if (), завязанный на 5 переменных, перед этим изменённых в той же самой функции 5 раз (хорошо ещё если не глобальных) - не лучший вариант.

А ООП - это всего лишь очень низкоуровневый инструмент.

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

Вещь сложная, несомненно. Скажем, написать Electronics Workbench непросто, а подключить к эмулированной схеме электромобиля 3D графику движения - ещё сложнее. Но если проект серьёзный, оно окупится: когда в схему начнут активно вносить изменения, цена этих изменений будет практически 0 - поменял пару элементов в схеме и всё заработало, т.к. за связи между элементами отвечает движок, а не ручные тонны сишных if-ов. Когда таких элементов - сотни и тысячи, оно стоит того.

>Наоборот, можно начитаться паттернов, налепить их везде, а в результате получить не менее кривую программу, которая работает на честном слове.

Не надо лепить паттерны. Надо просто смотреть, какие множества есть в программе, и писать для них классы.

Но вообще, да, даже простое следование ООП избавило бы этот код от кучи if-ов и взаимосвязей, ибо не было бы прямого доступа к множеству переменных.

Меня же просто интересовало, реально ли так все игры пишут - с места в карьер, в стиле начала 90-х, или же всё-таки это исключение.

/me обречённо пошёл в сотый проходить DeusEx 1 - единственную известную мне достойную игрушку, под Linux идущую явно лучше, чем под виндой. Да, DooM 3 тоже лучше, чем под виндой, но если это достойная игрушка...

>Меня же просто интересовало, реально ли так все игры пишут - с места в карьер, в стиле начала 90-х, или же всё-таки это исключение.

Все пишут как могут. Тут ещё код приличный, ты не видел код для некоторых сайтов на пхп на ынтерпрайз CMS, очень популярной в РФ. От программиста зависит всё.

Да не, уж ынтырпрайзных поделок от индусов я насмотрелся. Что индусы в одной функции на 10 экранов могут заюзать одновременно db/SQL/pop3/файлы/парсинг/goto/10 уровней for/if - этого добра хватает.

Я с играми никогда не сталкивался, разве что лет 10 назад читал книгу по программированию Дум-подобных игр, и там применялись похожие циклы на 10 разворотов. Поэтому меня ситуация конкретно в играх интересовала - может, там есть какие-то ограничения (скорость, время разработки), которые прямо-таки требуют писать подобный код.

Мне непонятно зачем функцию на 10 страниц делать? Ведь разбиение на функции как раз и были придуманы, чтобы упростить понимание кода и уменьшить сложность программы. Или смысл 10 страниц кода легко и быстро осилить для индусов?

Интересно, если бы Вы тогда про VHDL знали, использовали бы эти знания...

Я и сейчас VHDL не знаю ;-) Мне кажется, тут больше какой-нибудь Пролог подошёл бы.

В идеале там вообще данные по работе железа должны бы были вводить пользователи.

Кто все эти игры?

>Я с играми никогда не сталкивался, разве что лет 10 назад читал книгу по программированию Дум-подобных игр, и там применялись похожие циклы на 10 разворотов. Поэтому меня ситуация конкретно в играх интересовала - может, там есть какие-то ограничения (скорость, время разработки), которые прямо-таки требуют писать подобный код.

Скорость и время разработки всегда ограничивают, в любых сферах.

А насчёт циклов - в играх кроме всяких прочих расчётов нужно обновлять состояние объекта при следующем «шаге», учитывая все возможные состояния. Отсюда и большое количество if-ов, а уж как их устроить в коде - вопрос проектирования. В любом случае надо будет проверять все условия.

Для хранение состояния придумали переменные - члены классов. Хранить 10 разных состояний внутри одной громадной функции - это кошмар. Впрочем, хранить «большое количество» разных состояний внутри одного громадного класса не сильно лучше. Поэтому выделяются связанные состояние, пишутся классы, ими управляющие, и уже эти классы общаются друг с другом внутри функции, которая уже не такая громадная.

ждём дебов. купленный диск с вендовыми ресурсами в наличии

Где скриншоты?

Захотелось тупого, детского и 2д без 3Дмоделей, может как раз оно?

Надеюсь кто-нибудь сделает порт

Порт куда?

> может, там есть какие-то ограничения (скорость, время разработки)

Кстати игры - одно из редких направлений в программировании, где можно чуть меньше задумываться о поддержке кода в ближайшие 20 лет.

Не куда, а какой. Морской порт, например. Игра всё-таки про море.

Тут. Очень даже может быть, что подойдёт. Хотя оно не совсем чтобы детское. Более, так сказать, игрушечное — это World of Goo.

Хм, кстати да. В отличие от всякого ынтерпрайза, который хоть и точно так же срочно нужно написать «вчера», ынтерпрайз когда-нибудь придётся-таки поднять и заюзать/переделать/понять. С играми, полагаю, таких проблем нет, хоть на костылях, абы работало к сдаче. Так что, может, и оправдано.

ты не понял. в смысле, что купить бинарный пакет у них с сайта нельзя.

на линукс конечно же

ты не поверишь...

> посоветует хорошую книжку по проектированию

учебники по UML вполне годятся для обучения проектированию (читал александра леоненко).

тыкни ссылкой что я совсем офигел :)

поржал: весь мусор - в опен сорс!

Эх, вы не видели код который в IBM пишут... Это просто писец какой то. Говорю, к сожалению, не по наслышке. Там исходники > 100000 строк самое милое дело а едиснтвеная парадигма проэктирования это copy paste.

Eric Evans: Domain-driven design, но я не осилил за раз, тем более я предпочитаю более конкретный / рабочий стиль, не такой теоретический (мне интереснее почитать живые обсуждения, скажем, на http://c2.com/cgi/wiki). Но само направление мысли, хоть и не подходит ко всем проектам, собирает в себя множество других техник.

Design Patterns хорошо (хотя кто его не читал), но не как набор шаблонов, а как пример подхода к задачам - так сказать design over implementation.

Классная игра, отличная новость! Как только сессия закончится, порублюсь во все их выпущенные под гпл игры.

Ну что, новые звезды геймдева показали что, в отличие от гнилых старперов типа valve и blizzard, способны делать качественные игры, и более того, относятся к ним не как к корму для хомячков, а как к творческим произведениям, и чтобы их
- можно было использовать сейчас
- можно было использовать всегда
открывают исходники. Это начало новой эры в геймдеве, господа. А вот 2D Boy выродки и жиды, ибо, что показательно, единственные, кто ни черта не открыл. Гореть им и их семьям в аду.

Ути-пути, какой толстенький.

оооо!! зашибись! давно лорчую! ждём ебилдов)

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

Должно. В исходниках проверки и так не должно быть уже, вроде.