Раз пошла такая пьянка, то:
1. Общее.
1а глобалки
1б уже упомянутый код рендера в логике
1в немало литералов - в данные или хотя бы в константы
1г довольно немало магии всякой, работы с указателями, записями, массивами, в итоге всякие циклы, хитрая индексация и т.п. при том что списки тоже в ходу.. лучше бы всё на списках и классах с уже упомянутой необходимостью контроля времени жизни
1д упомянутая инкапсуляция - введение её поможет сделать удобнее то, что в предыдущем пункте
1е использование объектов и поинтеров и последующие касты (тоже можно к магии отнести, но выделяю особняком)
1ё именование несколько напряжное
2 Субъективное
2а коробят конечно подчёрки, но видимо автору нормально и привычно..
2б меня напрягает неслежение за регистром идентификаторов, а также за пробелами между идентификаторами и прочим синтаксом, скачет отступ возле : и параметрами/переменными, скачет идентация у блоков
2в размеры методов - сложно конечно судить насколько возможно что-то с ними сделать, но тем не менее, великоваты
По архитектуре надо сперва покопать, а для этого надо бы инструкцию как собрать чтобы бегало как на видео.
P.S. дико повеселил Cooldawn (идентифаер в сцен_арена_шутер), может ещё какую перловочку найду ))
Код всяких _scene_ arena_shooter\cosmo\rpg\space_stealth и прочее можно не смотреть) Это код на прошлые конкурсы, писался иногда в условиях нехватки времени, так что всяких косяков и несуразностей там может быть много. В данном контексте стоит смотреть остальные модули(сам движок) + модули из _apoc_*(код текущего шутера).
"1а глобалки"
В движке из глобалок юзается Window, TextureManager, вроде бы все. Ну а в коде шутера вообще нет никаких глобалок, окромя служебных BaseClassesIndexes в одном месте и все. Специально во все классы где надо пробрасывал ссылки на Scene, Map, и прочее.
"1б уже упомянутый код рендера в логике"
Вот поподробнеее разъясните, что там не так? Рендер у меня в Graph-классах да в DrawScene. Куда его вынести?
"1в немало литералов - в данные или хотя бы в константы"
Спорить не буду, есть такое, на этапе рефакторинга уберется.
"2б меня напрягает неслежение за регистром идентификаторов, а также за пробелами между идентификаторами и прочим синтаксом, скачет отступ возле : и параметрами/переменными, скачет идентация у блоков"
Вот насчет этого не очень понял. Идентификаторы я набираю везде через контрол-пробел, так что регистр везде должен сохраняться. Про пробелы и отступы тоже не понятно, бегло пробежался по коду, ничего такого не нашел. Везде где логически начинается вложенный блок например после if then - 2 отступа. В параметрах идентификаторы через пробел. В секциях var по 2 отступа.
"По архитектуре надо сперва покопать, а для этого надо бы инструкцию как собрать чтобы бегало как на видео."
Инструкцию вроде бы дал. Запустить "Eve -s", подождать немного, запустить "Eve 127.0.0.1" несколько раз. Получилось?
Daemon написал:
Это сарказм? Если нет, то завтра отпишу, что бы и как я поменял.
А нафига подчеркиваний столько? В делфи так не принято писать. Где F у филдов? У тебя что филды, что методы, всё наружу, все выглядит одинаково снаружи, не понять. Инкапсуляции побольше бы. Проперти где?
Darthman написал:
А нафига подчеркиваний столько? В делфи так не принято писать. Где F у филдов? У тебя что филды, что методы, всё наружу, все выглядит одинаково снаружи, не понять. Инкапсуляции побольше бы. Проперти где?
На все эти вопросы я ответил ранее. Подчеркивания - для того, чтобы быстро найти свой класс. Когда ищешь по контрол-пробелу свой класс не приходится выискивать его среди кучи прочих системных, которые начинаются с тех же букв. Про проперти и F специально тебе же ответил ранее. Инкапсуляция - после рефакторинга. В делфи так не принято писать - в делфи принято мышкой по форме возюкать, да приложения для баз данных писать, а не игры, а я в делфи и не пишу, в лазаре.
Вообще изначально вопрос был такой "Ну, тем интереснее будет мне узнать насколько мой код прозрачен и читабелен :)", вот никакого ответа на этот вопрос ваши придирки к качеству кода не дают.
Если ты их не видишь, это не значит что они не дают. Я вот тебе четко сказал - нету F у филдов. Следовательно у тебя хер поймешь метод это, пропертя, или поле у класса. Так понятнее?
Приведи мне хоть одну ситуацию где можно спутать метод и поле?
На ум приходит только функции без параметров. Даже не процедуры. Типа A := SomeFunc; Её вот можно спутать с полем. Так же как и её можно спутать и с проперти, у которых вроде как не принято ставить никаких особых меток типа F вначале. По моему это просто придирки на пустом месте, вследствие какой то одержимости следования путем Делфи, в которой приняты эти проперти. А проперти я не использую. Поэтому и F нигде там не нужно. Вообще, непонятно, почему отсутствие метки F там где она не нужна вызывает такое неприятие, так же как и присутствие метки "_" там где она нужна?
Я могу сказать одно, что если человек упирается и рьяно защищает так свой подход, то он не рвется получить комментарии чтобы их воспринять. Я тебе объяснил свою позицию, а дальше думай как хочешь. Если ты хочешь получить критику своего кода ради того чтобы её "разгромить" и остаться довольным собой - твоё право.
Если тебе критика нужна для улучшения - то наматывай на ус то, что говорят другие.
Значится, по инструкции запустил и побегал - очень даже ничего !
По коду:
Код всяких _scene_ arena_shooter\cosmo\rpg\space_stealth и прочее можно не смотреть) Это код на прошлые конкурсы, писался иногда в условиях нехватки времени, так что всяких косяков и несуразностей там может быть много. В данном контексте стоит смотреть остальные модули(сам движок) + модули из _apoc_*(код текущего шутера).
Вон оно что, Петрович !
Тогда собственно добрая половина претензий отпадает, и глобалки, и рендер получается не размазанный (а просто попал из других проектов), и иденты я видел именно в разных модулях разные (точно видел что после ифа у бегина был отступ, и в другом модуле не было) а вот пробелы точно (в одном месте а : б в другом а: б, сравнивать T_Socket.Write и RunSock или AddUnit и GetUnitsOnRadius - пробелы гуляют), насчёт регистра идентификаторов - возможно, тоже малоактуально, но помню что видел writeln и inc и имена типов (бул инт поинтер и прочее не капитализированы) и прочее из системного, а вот собственные идентифаеры с гуляющим регистром наверное из старых модулей и в малом числе.
Про рендер, кстати, больше вопрос не почему он в коде многих юнитов, а то, что он прямыми вызовами опенгла, без каких-либо абстрагирующих от опенгла слоёв, т.е. используются включения именно гл модулей, и при надобности как-либо вынести всё это, разделить, будет сложной задачей.
А вот с инкапсуляцией и магией, конечно, остаются ещё неясности, которые довольно _осложняют понимание и прозрачность кода_ . В моём розовом мире код читается хорошо, когда в дебри сложной логики погружаешься при надобности, придя туда из хорошо названного публичного метода, коих у класса немного и все на виду в виде отдельной паблик секции, так легко понять что весь класс делает, и по одному встреченному использованию такого класса сразу уяснить его цель и возможности. Ну и лично моё мнение, что код хороший, когда в нём хорошо прослеживается, что внутрянка отдельно (и лазить в неё редко) а "клиентская" часть - отдельно, и с ней работаешь часто, дёргая только публичные интерфейсы внутрянки. А когда каждый контактирует с каждым, да ещё и с кишками - код приходиться понимать целиком, просматривая много-много модулей и зависимостей.
Надо будет мне сообразить чего показать, что я считаю красивым и реально использую, только основной мой проект в привате.. постараюсь с одного прежнего проекта скинуть чего.
Darthman написал:
Я могу сказать одно, что если человек упирается и рьяно защищает так свой подход, то он не рвется получить комментарии чтобы их воспринять. Я тебе объяснил свою позицию, а дальше думай как хочешь. Если ты хочешь получить критику своего кода ради того чтобы её "разгромить" и остаться довольным собой - твоё право.
Если тебе критика нужна для улучшения - то наматывай на ус то, что говорят другие.
У тебя просто критика неконструктивная. Выглядит это все примерно так:
- зацени, как на вкус?
- Пиво у тебя неправильное, алкоголя совсем не чувствуется.
- Это не пиво, это квас, и алкоголя там не должно быть в принципе.
- А я еще раз повторяю, неправильное у тебя пиво! Все люди делают пиво с алкоголем!
- А я еще раз повторяю, это не пиво, это квас, и алкоголя там не должно быть в принципе!
Я вот хотел узнать, насколько легко и приятно будет пить мой персональный квас. А ты видишь в нем пиво. А раз я не соглашаюсь, с тем, что пиво неправильное, потому что это вовсе не пиво, то я на самом деле не хочу улучшить это пиво, а хочу просто самоутвердиться. А ты мог бы просто сказать, что пиво невкусное и уж точно его пить не будешь.
MysticCoder написал:
Я вот хотел узнать, насколько легко и приятно будет пить мой персональный квас. А ты видишь в нем пиво. А раз я не соглашаюсь, с тем, что пиво неправильное, потому что это вовсе не пиво, то я на самом деле не хочу улучшить это пиво, а хочу просто самоутвердиться. А ты мог бы просто сказать, что пиво невкусное и уж точно его пить не будешь.
2phomm,
Посмотрел твой проект. Понравилась твоя идея с умениями для ходьбы. Напомнило Age of Wonders. Там у каждого юнита помимо боевых характеристик типа атаки, защиты и количества жизней есть набор свойств, как пассивных, так и активных. Типа "Дракон", "Стрельба", "Полет", "Иммунитет к Магии". А еще вспомнилась далекая юность и попытки делать стратегию на стринггриде:D. Насколько я понял по коду, эти MovingActions и есть своего рода компоненты, которых игрок делает разные комбинации? В таком случае мне кажется стоило делать их более универсальными, типа они могли бы относиться не только к движению, а еще давать возможность атаки, стрельбы, других каких то действий. Потому что заводить кучу разных классов в которых только одна строчка немного различающаяся от класса к классу как то странно. Возможно, у тебя конечно были другие планы, сделать какие то фундаментальные различия в будущем. Думаю тебе понравится древняя статья про лептонный стиль программирования, она к компонентному подходу мало относиться, но что то где то рядом) http://www.wasm.ru/wault/article/show/1005016
Такие демки как раз пилятся после фейла сделать стратегию (стратегию, не тактику :) ) на стринггриде, когда приходит понимание, что надо планировать и проектировать и следить за очень многим, о чём не задумывался, в том числе и проверять идеи и их реализации в искусственной среде демок.
Там в коде есть помимо мувингэкшенов (точнее, мувингов, наследников Тмувинга) ещё и другие атомарные сущности (их тоже можно обозвать компонентами), но доступны к модифицированию игроком именно мувинги. Насчёт универсальности - тут другая концепция, поэтому отвечать за какие-то там ещё игровые правила - неверно по концепции. На абстрактном уровне у существа есть набор атомов, а именно позиция и мувинг (в данной демке изначально планировалось реализовать принцип движения по карте на основе гибкой системы, которая была бы расширяема без боли - та самая концепция), если захотеть, можно будет продумать и другие атомы типа действий и прочего. А главная фича этого подхода, что атомы лишь абстрактно примитивны, чёрные ящики, кажущиеся полнотелыми стеклянными шариками. По замыслу же, за атомами скрывается не просто ссылка на потомка, а целый контейнер, извне ведущий себя просто. Поэтому потребитель (общающийся с классом мувмента существа) видит очень простую картину - может модифицировать атом мувабилити (кидая енумы абилок) а там уже выстраивается всё взаимодействие между разными имплементациями атома мувинга и атомом позиции, пользователь только кликает по желаемой клетке.
Тут как раз полиморфизм хорошо играет роль, делая разную работу для каждой имплементации. И ничего страшного что класс содержит 1 перекрытую функцию, зато добавить новый мувинг стоит простейших усилий - написать сам класс из 1 функции, длиной 1-2 строки, и зарегить его в менеджере (не сделана автоматика просто, можно заморочиться с ртти) - и всё заработает само, как родное. Например, джамп был добавлен как раз после завершения разработки, за 5 минут собственно, я был доволен.
Но вот у системы пока не решён вопрос взаимодействия между атомами - неизвестно как сделать нежёсткую привязку, возможно, какие-то сообщения и подписку на них, а пока что просто идёт обращение к носителю атомов (классу мувмента существа) и там запрашивается конкретный атом (в моём случае позиция).
Также не решён вопрос параметризации работы атомов (атомы существуют в единственном экземпляре в менеджере, а везде просто по ссылке выдаются), и если будет несколько разных существ, применяющих одни и те же абилки движения, но с разными коэффициентами расчётов, то как правильно хранить эти коэффициенты и как их давать атомам в обсчёт - надо думать.
Но, как я уже говорил, на протяжении нескольких лет изучаю всякие модели для подобной системы, пока ещё не нашёл и не придумал такую, чтобы устраивала, а когда будет - уже будет от чего отталкиваться в создании крутой игрули :)
Статью, к сожалению, не очень понял, сложно у меня с асмом, часть прочитал только , но сути не взял.
MysticCoder написал:
После прохода по каждому классу с кучей NetStream.Write(Field1, SizeOf(Field1)), а также зеркально Read, энтузиазма как то поубавилось. На каждое поле приходилось 2 длинных строки. А уж при мысли о том, что надо будет поддерживать весь этот зоопарк при расширении полей и всяких компонент хотелось забиться в угол и тихо плакать.
Есть уже готовые велосипеды. Можно взять какой-нибудь протобуф и радоваться.
MysticCoder написал:
После некоторых тестов на VPS, я пришел к удручающему выводу, что пять локальных клиентов(+10 левых юнитов, в итоге 15 юнитов на карте), уже жрут всю мою хилую пропускную способность инета в 250КБ/с. Была вспомнена мудрая мысль о том, что можно слать только те данные которые реально изменились.
Возможно ещё где-то вас ждет пушистый зверек под маской дисконнектов..
Есть ещё одна мудрая мысль - использовать архивацию потоков данных. Если взять какой-нибудь простейший zip-поток, то с минимальным использованием CPU пропускная способность возрастает на порядок.
ZblCoder написал:
Да, код немного странный. Любовь к символу "_" заметна сразу.
phomm написал:
коробят конечно подчёрки, но видимо автору нормально и привычно
А я обожаю нотацию в стиле Lower Case. Она с _, но правда, чаще совсем другая. И жаль, что в мире больше распространены венгерские верблюды.