tag:blogger.com,1999:blog-4024831422917131975.post3315153522027408898..comments2023-06-19T07:10:57.540-07:00Comments on Игры старого охотника: Вброс для программистовOld Huntsmanhttp://www.blogger.com/profile/11429266296439086619noreply@blogger.comBlogger36125tag:blogger.com,1999:blog-4024831422917131975.post-79522623600659610852014-03-29T16:06:57.093-07:002014-03-29T16:06:57.093-07:00Ну кстати приближенность к естественному языку я у...Ну кстати приближенность к естественному языку я уже оценил за время что пробую классы. Действительно читается проще.Old Huntsmanhttps://www.blogger.com/profile/11429266296439086619noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-31614192904730671382014-03-29T12:03:00.586-07:002014-03-29T12:03:00.586-07:00>>"И такой подход работает вполне непло...>>"И такой подход работает вполне неплохо, даже экономит объём кода."<br /><br />Это ситуация из разряда "пот экономит кровь". Лишний абзац на инициализацию класса там-сям даёт возможность впоследствии писать очень приближённо к естественному языку, а не продираться сквозь конструкции из скобочек. Говорю как перешедший однажды в своих поделках с самопальных конструкций на ООП))<br />Ну и кроме того ООП как-то... упорядоченней. Взять те же методы - молоток как-то логичнее смотрится неподалёку от коробки с гвоздями, чем в одном ящике с расчёской и столовой посудой)whttps://www.blogger.com/profile/06601328939305169241noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-46616429039320116932014-03-27T11:32:06.087-07:002014-03-27T11:32:06.087-07:00Этот комментарий был удален автором.Anonymoushttps://www.blogger.com/profile/13921786337029190294noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-85901566176023837042014-03-27T10:09:09.188-07:002014-03-27T10:09:09.188-07:00Некоторое время назад я читал хорошую книжку по пр...Некоторое время назад я читал хорошую книжку по прграммированию. Там была такая фраза . Do not program in the language.Program into it. Перевод на русский несколько затруднителен,однако обшая идея такова : не меняй свои требования изза возможностей языка. Ищи новые возможности для реализации своих требований. <br />... Надо будет разработать единую конвенцию для подопытных чтобы потом мозги себе не ломали...Anonymoushttps://www.blogger.com/profile/05836691398954210092noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-13563645713182749692014-03-27T09:52:35.310-07:002014-03-27T09:52:35.310-07:00Ну я естественно изначально пишу некоторую механик...Ну я естественно изначально пишу некоторую механику словами. Просто практика показывает что когда берешься за код всё сильно меняется + возникает много такого о чем заранее и не думал.<br /><br />В общем вероятно я через некоторое время создам проект на GitHub и постараюсь организовать совместную с энтузиастами работу над кодом. Но это когда настанет время реализации.Old Huntsmanhttps://www.blogger.com/profile/11429266296439086619noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-81178729374018549712014-03-27T09:45:00.960-07:002014-03-27T09:45:00.960-07:00Не такая уж и большая. Это для того и делается что...Не такая уж и большая. Это для того и делается чтобы привести язык хотелок к требованиям к приложению. Если "рабыня должна плакать когда ее бьют", то по крайней мере мы знаем что нам нужен как минимум класс рабыня , в нем метод плакать, который будет зависеть от того бьют ее или нет. ООП позволяет более менее говорить с приложением на человеческом языке.<br />Поэтому если у тебя еще нет всего плана в мельчайших подробностях то опиши хотя бы на том уровне детализированности какой есть. Поикрайней мере ты получишь две выгоды. <br />Вопервых ты сможешь собрать все свои идеи в кучку и разложить по полочкам. Сможешь увидеть "общий план" и понять чего не хватает.<br />Во вторых ты сможешь увидеть примерную структуру приложения. Ну если с этим будет трудно, то мы всегда поможем :D<br />А насчет того, что еще не все детали есть,не беспокойся. С ООП очень легко расширять и править функционал.<br />В общем, мы плохого не посоветуем :-)Anonymoushttps://www.blogger.com/profile/05836691398954210092noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-91604776293072471852014-03-27T08:39:34.709-07:002014-03-27T08:39:34.709-07:00У меня никогда не получалось заранее написать техз...У меня никогда не получалось заранее написать техзадание целиком. Очень много конкретики становится понятно только тогда когда начинаешь пытаться реализовать более общие вещи в коде.<br />Всё-таки пропасть между хотелкой описаной человеческим языком и работающей программой слишком велика.Old Huntsmanhttps://www.blogger.com/profile/11429266296439086619noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-20485736117683660872014-03-27T06:09:59.575-07:002014-03-27T06:09:59.575-07:00Знаешь,ты задал довольно интересный вопрос. Я неск...Знаешь,ты задал довольно интересный вопрос. Я несколько дней размышлял почему именно я пишу соблюдая ООП . Ответ получился одновременно простым и сложным. Если в двух словах : так проще.<br />Сама парадигма ООП не появилась на пустом месте. Она не противостоит процедурному а расширяет его. С помощью классов, можно составлять сложные отношения между обьеектами и при этом соблюдать четкую структуру кода. Модификаторы доступа , overwriting и overloding методов позволят тебе быть уверенным что твои обекты будут вести себя так как ты этого хочешь.<br />Это как сравнивать телегу с лошадью и автомобиль. Оба могут тебя доставить из пункта А в пункт Б. Но на авто это получится быстрее,комфортнее, никто тебе не будет ветрв под нос пускать и еще и песенку спеть может.<br />В заключение скажу что мне очень знакомо жто чувство,когда надо переходить от чего то старого и знакомого на что то новое и не совсем понятное. Первое время будет некомфортно, зато потом ты сможешь роектировать целые куски приложения в голове.<br />Кстати, я бы тебе сейчас посоветовал отложить реализацию в сторону, взять листок бумаги и ручку и написать все все идеи насчет твоего проекта. Тогда тебе яснее будет представляться функционал приложения, требуемые сущности и отношения между ними. Потом и релизация буддет проще. Плюс ты можешь поделиться планами с нами и получить тоннну советов.:)<br /><br />В любом случае,успехов!!<br />ЗЫ: Пишу с телефона поэтому сорри за опечатки если что.Anonymoushttps://www.blogger.com/profile/05836691398954210092noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-11144098757309770772014-03-26T20:18:19.939-07:002014-03-26T20:18:19.939-07:00Этот комментарий был удален автором.Anonymoushttps://www.blogger.com/profile/04627162587661048478noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-4612587288002973152014-03-26T15:21:41.064-07:002014-03-26T15:21:41.064-07:00Я пробовал RPGmaker. Он для моих задач избыточен, ...Я пробовал RPGmaker. Он для моих задач избыточен, там всё крутится вокруг модели с бродящим по карте спрайтом. Делать спрайты и карты это отдельный геморой, а вот польза для игрового процесса сомнительна. На мой взгляд один вред. Имхо именно реализация на RPGmaker-е запорола SimBrothel 2. Хотя первая часть была годная.Old Huntsmanhttps://www.blogger.com/profile/11429266296439086619noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-76202737735058543892014-03-26T10:29:07.217-07:002014-03-26T10:29:07.217-07:00Ну и вообще про программирование с помощью ООП ест...Ну и вообще про программирование с помощью ООП есть шикарнейшкая книга: "Совершенный код" Стива Макконелла. Там не столько про само программирование, сколько про подход.Hikke Kunhttps://www.blogger.com/profile/04630751343454168641noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-30195352981391608802014-03-26T07:09:27.021-07:002014-03-26T07:09:27.021-07:00Как резюме. ООП как правило(зависит от реализации)...Как резюме. ООП как правило(зависит от реализации) ведет к инкапсуляции(изоляции) части кода и данных. Собственно дальше все сводится к правильному конструированию классов и правильность имеется в виду концептуальная а не синтаксическая. Конечно все что можно описать классами, можно описать и без них.Можно писать вообще на ассемблере. Как было сказано в "Ученые шутят" Если бы строители строили так же, как программисты пишут, то первый же залетевший дятел разрушил бы мир. ООП снижает остроту этой проблемы. А вообще то я бы на вашем месте присмотрелся к RPG maker ace там в основе ruby. Но большую часть можно вообще не писать, там интерфейс WYSIWYG позволяющий решить большинство задач. И при этом можно переопределить или расширить почти все именно потому, что все написано в рамках ООП и все коды доступны. Есть русификатор и русифицированный код. Сейчас фирма делает возможность порта игр на андройд. В случае вопроса легальности она стоит в районе 20 баксов. К нему есть куча расшареного кода реализующего все виды боевок(от пошаговых, до 3D). Квестовых систем и т.д. тут ссылок не привожу но достать на трекерах 5 минут. А вообще хотел выразить свой респект) Вы умница. Очень интересная модель поведения. http://informaticslib.ru/books/item/f00/s00/z0000024/st007.shtmlAnonymoushttps://www.blogger.com/profile/04627162587661048478noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-71840036105376790302014-03-26T07:07:28.964-07:002014-03-26T07:07:28.964-07:00Я играл в школе в книги игры да. Но сейчас играть ...Я играл в школе в книги игры да. Но сейчас играть это в pdf-е я пожалуй не выдержу ))<br />Проблема не в том что у меня нет идей что напихать в игру. Проблема как суметь реализовать всё что я придумал.<br />Old Huntsmanhttps://www.blogger.com/profile/11429266296439086619noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-19963726381819088602014-03-26T05:02:12.447-07:002014-03-26T05:02:12.447-07:00Охотник сори не знаю как твоё имя.у меня не вопрос...Охотник сори не знаю как твоё имя.у меня не вопрос а совет(посмотри если будет время)самая популярная книга игра конца 1990 или начало 2000 не столь важно называется Гохан или странник изгоняющий мрак игра шикарная там нет 18+но может чтото возьмёшь для себя игра эта рельно кульная <br />http://quest-book.ru/forum/viewtopic.php?t=1617<br />там и текст и персонажи и по мне можно чтото взять <br />Костя.пс мне 24 года Anonymoushttps://www.blogger.com/profile/09693838597036375562noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-18287669268503747892014-03-26T04:38:18.972-07:002014-03-26T04:38:18.972-07:00А вообще не парьтесь :) Пишите в своё удовольствие...А вообще не парьтесь :) Пишите в своё удовольствие и не нам вас учитьAnonymoushttps://www.blogger.com/profile/04297250308791211427noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-22795243209064023322014-03-26T04:36:05.809-07:002014-03-26T04:36:05.809-07:00Возьмем, например, 00pythonearly.rpy. Те переменны...Возьмем, например, 00pythonearly.rpy. Те переменные, что там объявлены вначале доступны из ЛЮБОГО места в коде. Например функция<br />def interactionSucess(pattern) выглядит так, как будто она принимает на вход pattern и возвращает что-то. Но на самом деле она меняет все состояние программы. В точке вызова этого не видно. Если передать все необходимые параметры, то в точке вызова это будет выглядеть так<br /><br />action_sucess = interactionSucess(interaction_pattern, my_girl, public, shame, disgust, fear, anger, guilt, suffer, insult, pleasure, tender, attraction, gratitude, confidence ...и еще много )<br /><br />Это конечно "доставляет", но зато в точке вызова примерно видно что функция делает и что её для этого нужно. И если вся программа написана таким образом, то это делает код немного понятнее. НО глобольные переменные все портят. Они могут быть изменены из любого места в коде. Обычно это происходит внезапно (особенно если в проекте задействовано много людей).<br /> Anonymoushttps://www.blogger.com/profile/04297250308791211427noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-27922581174357193622014-03-26T02:04:15.210-07:002014-03-26T02:04:15.210-07:00>> Почему?
Грубо говоря, классы - это как т...>> Почему?<br /><br />Грубо говоря, классы - это как торговый автомат: нажали на одну кнопку - выпала шоколадка; на другую - сухарики. И вам не нужно знать, конструкцию аппарата, чтобы им пользоваться. Только уметь дать входящие данные (кнопки нажать) и забрать итоговый результат (получить хавчик). <br /><br />Если вы уже один раз сконструировали такую машину - пользоваться ею сможет кто угодно. И ни вы, ни кто-то еще, уже не сломают ее, потому что вам просто не потребуется лезть во внутрь работающей системы. <br /><br />Программирование становится строительством из готовых, отлаженных и рабочих блоков и даже целых комплексов, а не из отдельных кирпичиков, из которых кто угодно может собрать что угодно, включая полный авангард. John Doehttps://www.blogger.com/profile/16418443155626105871noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-21148133210918640222014-03-26T01:22:47.843-07:002014-03-26T01:22:47.843-07:00А что за глобальные объекты?А что за глобальные объекты?Old Huntsmanhttps://www.blogger.com/profile/11429266296439086619noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-14492074907664555052014-03-26T01:22:23.833-07:002014-03-26T01:22:23.833-07:00А что плохого в джампах? Для питоновских кусков он...А что плохого в джампах? Для питоновских кусков они в целом мне пока и не были ни разу нужны, а вот RenPy на них полагается изрядно так как построен из локаций как и QSP.<br /><br />За три года можно просто привыкнуть к чему угодно. Но иногда мы склонны путать то что привычно с тем что действительно удобно, правильно или хорошо.<br />Впрочем я верю что работа в строгих рамках будет способствовать качеству кода. И я хотел бы конечно писать код лучше. Но для меня это всё же вторично. Я хочу лучше писать код ради игр, а не делаю игры для того чтобы научиться лучше писать код. Если что-то мешает мне в этом процессе, я сразу теряю настроение (Old Huntsmanhttps://www.blogger.com/profile/11429266296439086619noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-44930673026826539182014-03-25T13:36:00.568-07:002014-03-25T13:36:00.568-07:00Отвечая на вопрос "Нужно ли мне заморачиватьс...Отвечая на вопрос "Нужно ли мне заморачиваться с ООП подходом и что это даст?", то ответ "ДА". Но лучше сначала заморочиться с процедурным подходом. Для начала откажитесь от глобальных переменных и "goto" / "jump".<br /><br />Когда я начинал меня поставили в жесткие рамки стандартом кодирования ( https://www.dropbox.com/s/vhrh6d2j57ul80j/GooglePythonStyleGuide%28RUS%29.zip ). Примерно через 3 года пришло понимание почему так нужно было делать. В нашем стандарте (для C++) было 2 решающих правила: 1. НИКАКИХ глобальных объектов 2. Процедура должена помещаться на экран. Это сразу приводит к тому, что все входные и выходные параметры нужно передовать, плюс количество процедур растет быстро. Дальше чувство прекрасного (common sence) решает и ООП органично встраивается в ваш мозг.Anonymoushttps://www.blogger.com/profile/04297250308791211427noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-43574160970900635512014-03-25T13:11:36.296-07:002014-03-25T13:11:36.296-07:00>микрокласс
Я уже писал, что доводить до абсурд...>микрокласс<br />Я уже писал, что доводить до абсурда не надо. Класс на 1 функцию это уж слишком<br />>надо заранее представлять<br />Попробуй начать с ТЗ. Заранее определи что ты хочешь получить в итоге, при этом сразу же в ТЗ оговори что возможно (но не факт) может измениться. А уже по этому делай архитектуру приложения/модуля.<br />Понятно, что за раз все не получится, еще придется вернуться к ТЗ и переписать интерфейсы.<br />Часть смысла ООП в модульности. Есть некий модуль (класс/набор классов), который предоставляет некий API/функционал, который скрыт от пользователя этого API/функционала. При этом внутренняя реализация этого функционала может меняться, не затрагивая другие модули. Таким образом достигается взаимодействие разработчиков - они работают над разными модулями согласовав взаимодействие между ними, например. Таким образом достигается удобство траблшутинга ошибка будет всегда внутри модуля. Так достигается раширямость - при изменении/добавлении модулей другие модули не меняются или меняются незначительно.<br /><br />Отдельно стоит отметить питон. Как писалось тут в конечном счете все классы транслируются в словари, поэтому разделение на классы/словари не шибко критично в данном контексте. В этой свзязи я особой разницы не вижу, в том плане, что неправильно спланированные классы так же будут мешаться как неправильно спланированные словари. Ну и ООП это не обязательно классы, ООП - это подход к решению.Hikke Kunhttps://www.blogger.com/profile/04630751343454168641noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-70993171123960826092014-03-25T12:40:52.787-07:002014-03-25T12:40:52.787-07:00Могу дать общий совет не ударяться в крайности.
Н...Могу дать общий совет не ударяться в крайности. <br />Не обязательно делать выбор между полным отсутвием ООП и классами для каждой мелочи объединенными в жуткую иерархию которая все равно 10 раз изменится до релиза. Баланс и золотая середина наше всё.<br /><br />С иерархией действительно будут проблемы, если не знаешь точно что пишешь. В твоём случае не стоит особенно с ней маньячиться, достаточно делать наследование только там, где оно очевидно и само проситься.<br /><br />А в чем проблема с инициализацией, я не очень понимаю если честно. Можно ведь просто не инициализировать, если так уж не хочется)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-20535645835262761262014-03-25T11:46:39.852-07:002014-03-25T11:46:39.852-07:00Не стоит доводить до абсурда и создавать класс на ...Не стоит доводить до абсурда и создавать класс на каждый чих.<br />И я не вижу никакой проблемы в инициализации. У нормального класса есть конструктор по умолчанию, лишних строк по сравнению с процедурным вариантом будет одна-двеAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-74367136715178699212014-03-25T11:26:50.367-07:002014-03-25T11:26:50.367-07:001) Ну есть же словарь собаки. В нём и хранятся все...1) Ну есть же словарь собаки. В нём и хранятся все её переменные касающиеся её.<br />2) Других объектов вообще нет, если не ООП )<br />3) Вот это интересный момент. Да тут уже писали про структурирование, наверное это действительно плюс.<br />4) модификация единой функции имеет свои преимущества, особенно в объёме кода<br /><br />Собственно что меня напрягает это появление микроклассов которые имеют один метод и полторы переменных, но при этом отдельно инициализируются и захламляют всё. Плюс проблемы с наследованием, особенно множественным и т.п. Чтобы писать объектами, особенно с иерархией наследования, надо заранее представлять себе какие они будут нужны в конце, а у меня такого понимания нет,я пишу программу на ощупь. Учусь прямо в процессе написания.<br /><br />Но так или иначе я попробую сделать боёвку в рамках ООП и посмотрю как оно пойдёт на практике.<br />Old Huntsmanhttps://www.blogger.com/profile/11429266296439086619noreply@blogger.comtag:blogger.com,1999:blog-4024831422917131975.post-47520949119170356762014-03-25T11:01:19.898-07:002014-03-25T11:01:19.898-07:00Тем, что допустим, собаки умеют лаять. Если эта фу...Тем, что допустим, собаки умеют лаять. Если эта функция просто выводит в чатик лай, то никаких проблем. А если эта же функция должна еще отнимать у той собаки, которая лает, стамину? Ей нужно будет передавать параметр, где хранится значение стамины. А если она еще, допустим увеличивает голод? Ей нужно будет передать параметр где хранится голод для этой собаки.<br />При работе с классом, после создания объекта класс может хранить переменные для значений стамины и голода для данной собаки.<br />Т.е. мы получаем следущие плюсы.<br />1) Все данные про собаку храняться в одном месте.<br />2) Другие объекты ничего не знают про состояние этой собаки, что ведет к уменьшению вероятности ошибки..<br />3) Значительно проще искать ошибки и сопровождать такой код. Засчет того, что вместо хранения разных переменных в разных местах (про которые нужно помнить в один и тот же момент времени) мы получаем аккуратный объект.<br />4) В случае необходимости мы можем переопределить функцию лая в потомках класса. Т.е. все собаки лаят "гав", а Доге лает "вов". При этом у нас останется единый интерфейс для лая: bark(), вместо двух функций. Можно использовать и одну функцию, но это приведет к переусложнению кода.Hikke Kunhttps://www.blogger.com/profile/04630751343454168641noreply@blogger.com