А по теме, смысл набирать большую команду для сайдскроллера? Имхо, но достаточно 1 кодера и 1 норм моделлера или 2х новичков или тупо ассетстора и 1 директора)
Цитатаv_popik ()
Команду стараемся сделать побольше, чтобы рабочий процесс шел активнее.
Возможно, v_popik работал кочегаром, и знает точно — больше угля накидаешь, шибче паровоз поедет.
Брать тупо из ассетстора они ещё год назад собирались (с форума unity3d):
Цитатаv_popik ()
В основе будут лежать бесплатные модели, анимации, звуки. высококачественные текстуры нам тоже не нужны. все будет монотонное. Нужные анимации будут записаны через киннект. Игра будет на 40 минут, по объемам все реально
Цитатаv_popik ()
Модели не содержат костей. ты слышал что-то про айписофт и про библиотеку бесплатных готовых анимаций? Стилистически не подходят - по этому текстуры будут монотонные и стиль будет выбран соответствующий. Много полигонов. здравствуйте. существует множество бесплатный лоупольных моделей дли игр, даже в ассет сторе их навалом. И великая проблема замоделить лестницу или мусорный бачек самому за 10 минут.
И про сайдскроллер:
Цитатаv_popik ()
Ну вижу никаких особых амбиций у данного проекта. его цель - завершиться хотябы в 50% виде, от изначальной задумки. А амбиции будут возложены на следующий проект, т.к к делу будем подходить уже с опытом. смысл проекта - понять как создаются игры подобного типа. А 2д спрайтовый платформер можно создать за 2 месяца и никакого особого опыта этот процесс не принесет, если мы изначально нацеливались на 3д
(ему там говорили, что-де нада 5-10 моделлеров на сайдскроллер в 3D, не потянете, идите пилить 2D, и т.д.)
Думаю, если б у них были "норм моделлер и кодер", давно бы прогресс был... То ли планы слишком круты, то ли плана вообще нет)
А так тут где-то была команда из человек 15-ти (и продолжала рост), и ничего... решили с 2D перескочить на 3D, ибо в 2D им оказалось слишком сложна... Главное, главное — чтоб людям было весело проводить время вместе, а уж игра там как-нибудь сама доделается, да и нужна ли она вообще?))
Для этого есть корпоративная вики, где описаны правила и приложены ссылки на официальные доки. Если не соблюдать тот или иной стиль кода, то его просто не пропустит git с правильно настроенным валидатором (CI / CD). Каждый грамотный проект, даже если он опен-сорсный и его разработкой занимаются много людей с разных уголков света, должен иметь CI и группу людей, которые модерируют любой ваш коммит.
С этим согласен... Похоже, я пока просто не встречал грамотных проектов) ...ну, или я просто на самом деле немогутор в серьёзное программирование(
Цитатаmartuk ()
Может быть и заблуждаешься, но я вижу огонь в твоих глазах - и это хорошо!)
Хорошо, если это тот огонь, о котором ты думаешь, а не пожар моей депрессии)))) *ещё много якобы весёлых скобочек*
Цитатаpixeye ()
Тем кто работает над конкретным кодом он должен быть "понятен" и не более
Эм, где-то вычитал, что по отношению к коду "красиво" = "понятно".
Думаю, это как-то связано с психологией, ведь нет никаких биологически обусловленных признаков "красивого кода". Вот если ты легко понимаешь конкретный код, то его чтение доставляет тебе удовольствие (в противовес страданию от состояния ЯНИЧЕГОНЕПОНЯЛ при чтении непонятного кода), а то, что доставляет тебе удовольствие — очевидно, должно быть чем-то "красивым", ибо нечто "уродливое" удовольствия как правило не доставляет.
Кстати, если проводить параллель с текстами на естественных языках — всегда приятнее тот текст, что легче читать. Об этом не говорят как о какой-то "красоте", но ведь именно из-за этого в Интернете не принято писать зАбОрЧиКоМ, писать всё сообщение капсом и т.д., потому что читать становится сложнее и неприятнее. В общем, думаю, "красота" и "понятность" тут связаны.
Совсем другое дело, что понятность субъективна, это да)
Цитатаpixeye ()
Тому кто тебе платит глубоко ***** красивый код или нет
Им потом этот код в будущем поддерживать придётся (не лично, а организации, если речь об этом). Что, совсем плевать, какой код поддерживать?
Цитатаpixeye ()
ЦитатаTimKruz ()
И не надо про оптимизации, что лишний вызов подпрограммы замедляет программу, что длинные имена занимают больше места на диске и т.д. Мы не в 90-х,
Ты очень, очень сильно сейчас заблуждаешься : )
Цитатаk0fe ()
Вот поэтому в Стиме так много лоуполи игр и прочие kinda meh graphics, которые грузят мой средний пк (1050, i5-7th) на 90% "Мы ж не в прошлом" не совсем правильный подход.
pixeye, k0fe, я тут опять простыню накатал, но потом одумался. Если кратко: оптимизации кода не должны быть во вред читаемости кода. Какой толк от того, что ты выигрываешь 5 микросекунд на исполнении кода, который не можешь расширить, дополнить, и т.д.? Давайте все просто машинные коды набирать, нам же не нужно потом в этих кодах разбираться... Есть масса способов писать и понятно, и оптимально. Но почему-то люди предпочитают оправдывать свой грязный код мистическими "оптимизациями", в которых они потом сами разобраться не могут...
А игры в стиме такие тормозные, потому что простые движки/конструкторы доступны всем, а технический склад ума и необходимые знания доступны не всем. Сегодня у людей понимание того, чем они занимаются, возникает позже, чем они получают возможность создать новый игровой суперхит и срубить кучу бабла. Потом они понимают, что было бы неплохо улучшить своё творение, но, оглядываясь по сторонам, видят сотни таких же глючных и тормозных проектов, и справедливо решают "ну, раз тут так принято, то зачем мне напрягаться?"... Так что, возможно, во всём этом бардаке виноваты как раз те люди,
Цитатаpixeye ()
которые делая низкоуровневые вещи позволяют тебе писать так высокоуровнево как ты хочешь
Цитатаafq ()
С чего ты взял, что сможешь разобраться в сложном проекте, если даже в моём не можешь?
В твоём я даже суть не понимаю. Ты создаёшь как бы эмулятор ПК, но при этом у тебя в основном работа с файлами выдуманной файловой системы... Ты же на C++ пишешь? Где ООП? Где Computer.Create("zex")?
Цитатаafq ()
Зайди в main.cpp и посмотри что получилось в итоге, как создаётся всё. И пофиг что не по 18 строк кода функция. Она требует больше строк кода. Лишние вызовы других функций ни к чему.
Ты прав. Лишние вызовы ни к чему. Поэтому мой игровой движок максимально прост:
Код
begin GameEngine := TGenGECore.Create(Configuration); GameEngine.Run; end.
Дальше он делает всё сам. Магия? Не думаю)
...сначала транслируется код генерирующего скрипта, затем скрипт генерирует исполнимый код игры, и код передаётся виртуальной машине, которая максимально тупа, но очень послушна. В теории это позволило бы очень легко и быстро моделировать поведение игры и её ресурсы, в то время как компилируемая часть движка оставалась бы без изменений, маленькой и простой. Как-то так работают Форт-машины, но здесь хотелось большей приближенности к играм...
Правда, я это дело забросил на начальной стадии. Транслятор-то у меня есть, и простую машину написать я могу, но у меня не клеится общая концепция движка. Не получается придумать набор инструкций и связи между отдельными машинами (их, по идее, должно быть несколько), а без этого всё становится бессмысленным. К тому же язык генератора, который я придумал, оказался не таким уж универсальным, и без его расширения особо интересного не нагенерируешь (хотя позабавился знатно)... Так что дальше генерации забавных картинок дело с движком не ушло, а тексты генерировать как-то совсем грустно((
Нет, я понимаю, что всё это можно придумать по ходу дела, это ведь не ИИ какой-то, чтобы заранее придумывать от А до Я. Но мотивация никакая. Да и нужен ли мне собственный игровой движок, если я не стремлюсь делать игры?..
afq, а что должно симулироваться на этих твоих виртуальных ПК, у тебя ведь там не настоящие операционки и программы... Неужели целиком весь терминал эмулируешь, со всеми этими dd, man, sudo?.. Мне просто интересно, насколько быстро я мог бы сделать сравнимый аналог на Pascal (со стороны игрока), но разбираться в чужом коде ради этого совсем не хочется)
Обычно после просмотра своего же видео спустя недельку желание сразу пропадает. Ну а если нет, значит может и впрямь скрытый талант пропадает.
Ага. После взгляда на свой же первый рисунок спустя недельку желание рисовать сразу пропадает. После чтения своего же первого рассказа спустя недельку желание писать сразу пропадает. После прослушивания своей же первой мелодии спустя недельку желание музицировать сразу пропадает. После запуска своей же первой игры спустя недельку желание делать игры сразу пропадает. Так можно даже сесть на свою же табуретку спустя недельку и сразу пропадёт желание делать табуретки.
Интересно, как вообще появляются люди, которые чего-то добились? Рождаются с видеокамерой в зубах, кисточками в руках, клавиатурой на животе, флейтой в заднице... типа, талантливые дофига?
Но согласен, если критически оценивать своё творчество, то можно отбить любое желание к творчеству вообще. Навсегда.
Вообще я не имел ввиду, что надо судить себя по первым результатам, а всего лишь про тот случай, когда на ютуб идут чисто по тренду моды, быть как все. При этом ни особо творческих замыслов, ни их долговечности нет.
Многие хорошие идеи рождаются спонтанно, но далеко не с первой попытки) Можно пойти куда-то на волне моды, а остаться, потому что оказалось круто... Но разочарование от первых попыток будет в любом случае)
Просто нужно настраивать себя не на "снять видео и через недельку посмотреть", а на то, что придётся долго и упорно развивать свою речь, составлять сценарии, учиться разному ПО, искать контент/материалы, придумывать оригинальные идеи и способ их подачи, и всё это необходимо испытывать боем, иначе никогда не поймёшь, где ошибаешься... А испытывать боем — это ловить кучу негатива и издевательств не то, что за ошибки, а даже за само начинание... Хочешь через всё это пройти? Вперёд и с песней. Возникают вопросы "зачем мне это"? Ну, значит, это не твоё. И не придётся снимать первое видео)
Цитатаtduk ()
При этом у него около 50к подписоты всего лишь. А у челов с "что будет если разрезать ножем овер9999 градусов землю/шар/масло" миллионы
Ну это как сравнить анекдоты, художественную литературу разного уровня и научную литературу. Анекдоты не виноваты, что их рассказывают даже неграмотные люди (уметь читать для этого не надо), а бульварные романы не виноваты, что они популярнее, чем научные журналы. Просто разным потребителям — разный контент, и было бы несправедливо лишать доступных развлечений 95% населения этой планеты)
Ну а то, что производители ширпотреба получают в разы больше профита, чем производители годноты — так это просто награда за находчивость, ведь не каждый способен обратить уязвимости ширнармасс в свою пользу)
Понятно - растяжимо. Тебе может быть непонятно в силу того что твои знания недостаточны и ты просто не в состоянии адекватно оценить этот кусок кода.
ЦитатаTimKruz ()
Совсем другое дело, что понятность субъективна, это да)
Я не спорю, просто бывает менее понятно и более понятно (в самом общем смысле).
Цитатаpixeye ()
Сокрытие работы не имеет ничего общего с понятностью.
Сокрытие сокрытию рознь: — то, что больше никогда не придётся редактировать, и имеет понятный внешний интерфейс; — то, что постоянно падает и ломается, и при том трудно понять, как этим управлять извне.
И код свой я привёл скорее в шутку, а не как пример чего-то правильного) У меня вообще код редко бывает правильным (в первую очередь потому, что я ничего до конца не довожу)...
Цитатаpixeye ()
Те кто будут именно поддерживать твой код будут работать не с обертками а с тем что ты скрываешь за своим Create.
Ну смотри: — смотрим снаружи: просто, понятно (в отрыве от реализации); — вскрываем первый уровень абстракции: по-прежнему просто, понятно (в отрыве от второго уровня); — вскрываем следующий уровень абстракции: всё ещё просто и понятно (в отрыве от третьего уровня); — ... — углубляемся в самый низ: элементарные операции, понятные даже школьнику. В чём проблема?
Проблема тут только в том, что не все могут правильно разделить проект на самостоятельные и независимые уровни. Например, я уже писал тут, что код должен работать даже отдельно от остального кода — это означает не только то, что любая из подсистем игрового движка должна запускаться отдельно от остального кода движка, но и любой существенный фрагмент кода не должен зависеть от всего остального кода (т.е. если воткнуть в другую программу, его поведение не изменится).
Как я понимаю, в этом и должно заключаться ООП. Мы создаём "объекты" как нечто, что существует само по себе, и нас не должно волновать, какие внутренности в них спрятаны (пока эти внутренности оправдывают наши ожидания). Но это возможно, только пока объекты остаются маленькими и понятными (подразумевается собственный код объекта, а не суммарно с вложенными объектами).
Ой, и вообще, разве разработка снизу вверх не решает эти проблемы? Сделали модуль, протестировали, и больше никогда к нему не притрагиваемся, только если не забудем, чем он должен был заниматься (но эту проблему устраняет понятность интерфейса и, при необходимости, документация). Вообще не понимаю, зачем копаться в кишках какого-то компонента, если проще и быстрее собрать новый из тех же фрагментов, из которых собран старый (если стараться делать проще).
Ммм... Ну вот, скажем, тот транслятор, о котором я говорил, используется всего в три шага: Create, LoadFromFile, Generate. Последняя функция принимает требуемую точку входа в скрипт, и возвращает результат трансляции/выполнения (на самом деле это скорее метаязык, он описывает только порядок слияния чего-либо с чем-нибудь, так что я не знаю, какие определения тут уместны) в виде строки. Зачем нам ковыряться во внутренностях? Только если расширять синтаксис языка, но тогда это будет уже совсем другой транслятор другого языка. Поэтому я могу использовать этот транслятор и отдельно, и в составе игрового движка, и ещё в чём-либо, где требуется нагенерировать каких-то данных из скрипта — и мне даже не нужно думать каждый раз о том, как устроен транслятор изнутри, потому что его работа абсолютно одинакова.
А вот обратная ситуация, когда у какого-то пепелаца стопицот рычагов управления (кажется, это называется "суперобъект"?), и приходится рыться в его реализации, чтобы понять, почему при дёргании за рычаг №120 отваливаются рычаги со 150 до 230, а рычаг 90 ещё издевательски посвистывает при этом (или бросает безымянный exception без внятного объяснения). Разобраться в этом всём можно, разумеется, но — зачем? Какая-то особая форма мазохизма, рыться в этом всём...
(Это основная причина, почему я пилю велосипеды и ненавижу обмазываться готовыми библиотеками. Моя мечта (одна из) — сделать свой ЯП, на котором никогда не будет чужих библиотек, и писать на нём лично. В гордом одиночестве. Что мне будет угодно.)
Хороший вопрос Ну тип... Просто нравится делать что-то, что работает. Но когда юзаешь готовые инструменты, сначала тратишь уйму времени на изучение этих инструментов, а потом уйму времени на борьбу с ошибками этих инструментов, которые не можешь исправить из-за монструозности этих инструментов (при том что 90% от их функционала тебе не нужно!). В итоге ничего нормально не работает, а ты завален мануалами и не понимаешь, зачем тебе это всё нужно изучать, ломать и чинить...
Я вот, например, никак не пойму, зачем в C++ и подобные ЯПы продолжают добавлять новый функционал даже не на уровне библиотек, а на уровне синтаксиса. Зачем? Это ведь изучать нужно, а потом возиться в каше из кучи сущностей, использования многих из которых можно было бы избежать (если бы в языке их не было, либо программисты их не использовали)... Типа сначала все ополчились против "goto", мол он усложняет восприятие, но потом сделали 100500 новых фиговин, которые ничуть не лучше goto, особенно в таком количестве.
Честно говоря не понимаю людей, которые хвастаются, что такой-то ЯП умеет делать и так, и эдак, и ещё десятком инструментов. Оно, может, и удобно в ряде случаев, но потом приходится удерживать в голове кучу информации, чтобы разобрать очередной фрагмент кода. Типа: "так, а почему здесь это? а, новая функция, недавно в стандарт добавили... а это что? а, здесь использование бага десятилетней давности, понятно... а вот это, кажется, должно приводить к ошибке, ну-ка глянем в мануал... не, это только выглядит как ошибка, но формально допустимо... а это что за бред? нет, и так тоже можно..."
Вот и хочется иметь инструмент, который не имел бы в себе всего этого мусора. И заодно — чтобы не было соблазна набрать use MagicLibrary, которая делает хорошо, но непонятно как.
А ещё меня бесят лицензии. Надеюсь, если из чужого у меня будет только "железо" (инструкции ЦП, команды BIOS, и т.д.), я не должен буду прикладывать специальный файл, в котором тщательно подлизываюсь к каждому, кто хоть как-то посмотрел на мой код? А то так ведь придётся создавать свой компуктер, только потом окажется, что транзисторы запатентованы и нужно кому-то дань нести, чтобы из них что-то паять... Остановите планету, не хочу нарушать чьи-то авторские права на Землю((
Счастье детей и домохозяек — нажимать "я принимаю лицензионное соглашение" ещё до того, как это самое соглашение успеет появиться на экране. Остальные вынуждены страдать (ну, кроме юристов, наверное).
Цитатаpixeye ()
Решается через ecs.
Entity component system? Можно было б хотя бы ссылку на Вики дать.
Код не совсем понял, но глянув статью на Википедии, вспомнил, что что-то такое и пытался сделать. Ну, разумеется, после того, как несколько месяцев назад прочитал статью про подход через компоненты. Но, опять же, какие компоненты мне нужны? Пытался построить схему движка, но так и не приблизился к пониманию, как всё связать (например, как и когда физический движок передаёт графическому координаты, если графический не знает о существовании физического, и наоборот?).
Цитатаpixeye ()
Непонятно о чем именно идет речь.
Не важно, просто я со своими попытками сделать всё универсальным зашёл слишком далеко, и окончательно запутался))
Да, знаю, если б я реально работал программистом, а не страдал в попытках на коленке сделать то, что не удаётся огромным корпорациям (ибо всё меньшее уже сделали до тебя), то у меня не было бы таких проблем, просто следовал бы общепринятым методам работы над проектами. Зарабатывал бы кучу денег и так далее)
Но я уже смирился, что мой путь — это к тем поехавшим одиночкам, которые мнят себя великими изобретателями, а на деле несут какой-то бред, в огромных масштабах (для примера, есть один форум по ИИ, так там как в дурдоме — все такие сурьйозные, а говорят в основном о совершенно бредовых вещах, далёких от практической разработки). Так-то нет особой разницы, пытается человек изобрести вечный двигатель, найти философский камень, сформулировать общую концепцию всего или запрограммировать компьютер на человекоподобное поведение... Короче, всё очень плохо у меня.
const MSG_EMPLOYEE_INFO = 'Employee #%d: %s %s (%d y.o.)'; type TEmployee = record ID: Integer; Name, Surname: String; Age: Byte; end; var EmployeesRoom: array of TEmployee; Employee: TEmployee; begin for Employee in EmployeesRoom do with Employee do WriteLn(Format(MSG_EMPLOYEE_INFO, [ID, Name, Surname, Age])); end;
Ваще не понимаю, зачем нужны все эти ::, auto const &[]:, <type>, <<, >> и прочая бесовщина. То есть разобрать и понять значение я могу, но принимать это не хочу. Больше слов — меньше неясных спецсимволов!
ИМХО, есть два вида ЯП: 1. Spider; 2. ,//\\(::,,::)//\\, Первые можно читать и понимать как текст, а вторые нужно разглядывать, как ASCII-картинку. Вот только если в языках первого типа на опечатку в слове укажет компилятор, то в языках второго типа мало того, что можно глазами не заметить лишний/недостающий символ, так ещё и компилятор может принять опечатку за корректный код, который приведёт к неизвестным заранее последствиям... Поэтому мне больше нравятся языки, подобные языку Ada (паскаль на максималках, еее). И читать приятнее, и пишется проще (дольше — не сложнее; проще — не короче).
Цитатаafq ()
TimKruz, ну как ты пробывал сделать хакерскую игру?
Ну я набросал такую вот фигню около 4 часов ночи:
А потом мне это надоело и я уснул под утро)
Цитатаpixeye ()
Ты просто честно-честно ответь себе чего ты действительно хочешь. И все встанет на свои места : ) Не прячься и не играй в игры разума. Все на поверхности.
Если отбросить инфантильные мечты — ничего по-настоящему не хочется, и это вгоняет в депрессию. Если фокусироваться на тех мечтах — реализовать их не выходит, и это вгоняет в депрессию.
Скажем так, всю мою сознательную жизнь пронизывают идеи, связанные с разумными существами, не являющимися людьми в биологическом смысле слова; в особенности, идеи, связанные с робототехникой, искусственным интеллектом и т.д. Последнее преобладает за счёт того, что надежды на каких-то инопланетных/биоинженерных/потусторонних/каких угодно ещё существ нет, а вот робототехника развивается семимильными шагами вот прям щас. Это я понял ещё в детстве, наверное.
Вот только реальность оказалась в разы жёстче, чем в самых пессимистичных моих прогнозах. То, что называется сейчас ИИ, и близко не стоит с тем, о чём мечтается, при этом развитие ИИ направлено на бизнес, а это вообще противоположно моим желаниям, соответственно помощи ждать не от кого. В книгах на тему ИИ либо сплошная математика, либо философия. Собственные мои размышления упираются в концепции, которые не ведут ни к чему хорошему (ибо зачастую получается "сделаем вот так, а потом оно авось само как-нибудь"), если вообще к чему-то ведут (иногда тупо зарываюсь в философию или математику). Делать роботов же вообще не вижу смысла до тех пор, пока у меня не будет способной к самообучению программы, но и тут уже вижу, что слишком радужно воспринимаю идею "запилить роботессу" (в детстве вообще фантазировал на тему "собрать из выкинутых на свалку электронных плат", хотя когда-нибудь и такое станет возможным). В сумме вся эта безысходность загоняет меня ещё глубже в ту депрессию, в которую я вошёл давным-давно благодаря усиливающейся социальной дезадаптации и ряду других причин...
Я бы мог заняться чем-то другим (ну, не знаю, научиться рисовать кавайных аниме-тян давно хотелось), если бы увидел в этом значимость выше своей идеи-фикс (ммм, живая роботян лучше нарисованной, не так ли?). Но пока я не вижу особой значимости во всём, чем пытаюсь заниматься, малейшие неудачи заставляют меня всё бросить и углубиться в страдания ("аааа! опять как-то не так рисуется! какое же я ничтожество, даже такую бесполезную фигню сделать не могу!")...
Секс с роботами — это интересно, но роботов хочется больше и чаще, чем секса)
Цитатаpixeye ()
Нормальное такое желание. Роботяны и прочая хренота просто отмазы
Нормальное для этого организма, потому что в него это заложено генетически. Те, кто не имел "нормальных желаний", не оставили потомства. Но это было актуально в древности, когда не было технологий и перенаселённости.
Я должен быть выше этого, иначе как я вообще могу считать себя разумным? Просто голая обезьяна, управляемая инстинктами и совсем немножко оптимизируемая знаниями... Хочется принимать взвешенные и обоснованные решения, а не следовать своим эмоциям и инстинктам. Иначе какой смысл в разумности?..
(Хм, может ИИ до сих пор нет, т.к. мы пытаемся создать чистый разум, а не тонкую надстройку над тупым животным?.. Всё больше склоняюсь к этой идее, но боюсь, как бы не оказаться в ловушке "животное есть, а разума так и нет".)
Цитатаpixeye ()
Почему ты позволяешь себе неуважать чужое ремесло
Ты не понял, я очень даже уважаю художников, которые мне нравятся. Вот в этой фразе:
ЦитатаTimKruz ()
какое же я ничтожество, даже такую бесполезную фигню сделать не могу
Речь шла про то, что я не могу лично для себя поставить рисование превыше всего, дабы заниматься им постоянно.
Если бы я мечтал именно стать художником, я бы им и стал. Но рисование для меня лишь инструмент "добычи приятных картинок", очень неудобный и неэффективный — я не хочу тратить на него время, силы и нервы, когда поисковые машины с той же задачей справляются в разы лучше, чем мои руки.
Нет, разумеется, рисовать самостоятельно — круто, но требуемые затраты на получение необходимого уровня навыка слишком высоки относительно преимуществ владения этим навыком (субъективно). Что могут художники, кроме как рисовать?..
С тем же успехом я "не уважаю" писателей, хотя сам иногда пишу и, кажется, пишу неплохо. Просто я не вижу пользы от художественной литературы, особенно с учётом переполненности современного рынка.
Цитатаpixeye ()
Нормальная реакция для человека обесценивать то, что ему нравится, но получить не может. Мозгу так проще.
Эт да, но почему-то некоторые вещи я не могу обесценить. Хотел бы, да не могу. В одних случаях думаю "ну и ладно, не больно-то и нужно", а в других — "если отступлюсь, то предам самого себя"...
Цитатаpixeye ()
Искренне желаю тебе найти сил разобраться во всём этом.
Спасибо, хотя мне б найти сил на конструктивную деятельность, от самокопания я уже устал) Все эти мои мечты про ИИ вполне достижимы (если не уходить в философию), но нужно делать конкретные шаги, а не валяться в направлении цели и мечтать о её достижении... Впрочем, знать бы ещё, куда эти шаги делать.
Цитатаafq ()
ты же вроде писал что сделать файлы и каталоги легко. Я думал что ты это в первую очередь сделаешь. А ты за четыре часа сделал echo и exit.
Ух... Если тебя это так волнует, я потратил 2 часа 16 минут (параллельно играя в игру), и сделал не "echo и exit", а синглтон "TGameConsole", который принимает пользовательский ввод, разбирает и анализирует команды, список которых легко пополнить. Без этого обработчика смысла в дальнейшей работе не было бы, ибо даже если написать класс, работающий с файловой системой, испробовать на практике его не получится (без временного кода).
По мере создания класса, работающего с "файловой системой", я бы мог испытывать его в роли игрока, а не тестовыми вызовами. Я не говорю, что это удобнее или проще, но это нагляднее и мне так нравится больше — код начинает выполнять свою задачу задолго до того, как будет дописан до конца. Получается "игра с кодом", а это приятнее, чем делать всё в уме.
Цитатаafq ()
Тебе же советую учить какой нибудь язык раз в год. Ну или не раз в год, а хотя бы ещё один язык, чтобы мышление менялось.
Я перепробовал множество ЯПов (как минимум писал программки для усвоения), но в конечном итоге понял, что нет особого смысла знать много языков. Они, по большей части, отличаются только синтаксисом, набором библиотек, фичами и багами компиляторов, да основной платформой. Но когда твоя платформа — винда, фичи и баги компиляторов тебя не волнуют, библиотеки тебе зачастую не нужны, а синтаксис нравится какого-то конкретного вида, не вижу никакого смысла во владении десятком ЯПов одновременно.
И потом, ЯП — это инструмент решения задач, а задач у меня тупо нет.
Всегда, пытаясь освоить новый ЯП, думал в стиле "щас чёт крутое запилю!" Время шло, а крутых идей, которые я мог бы реализовывать, на ум не приходило. В итоге бросал и возвращался к своему обычному режиму "покодить что-нибудь на паскале раз в полгода от скуки".
Скажем, изучал Java, чтобы освоить разработку под Android. Но осознал, что мне нечего делать именно на смартфоны. Для рынка? Он переполнен. Бросил Java.
Хотя чаще я всё-таки сталкиваюсь с тем, что не только я не знаю, чё делать, но и гугление не даёт ничего про реализацию моих идей. По крайней мере, простым и понятным языком, а не абстрактными формулами.
Цитатаafq ()
для терминала выбирать лучше команды линукса, потому что врядли хакер будет пользоваться терминалом ms-dos.
Меня заинтересовала идея игровой симуляции работы с ПК, а не симулятор хакера)
Я вообще хотел бы создать свой набор команд, чтобы игроку было интересно изучать что-то новое, а не тупо содрать всё с реальной консоли. Зачем играть в игру про терминал, если я могу открыть настоящий терминал?
Цитатаafq ()
вот смотри что у меня реализовано
Эм... А где хлебные крошки? В линуксе же есть: user@comp:~/user/documents/books$ Или как там, не суть. Мне кажется, это очень важная фича.
Цитатаafq ()
Всегда сложно понять что автор имел ввиду написав несколько строк кода.
Плохой автор, значит)
ЦитатаXakep ()
Ну фиг знает на счет ассемблера, это дикий лоу левел и 10 строк уже могут быть абсолютно не понятными, если писал его не ты, плюс условные и безусловные переходы вместо ветвлений и циклов очень сильно усложняют навигацию по коду (хотя может это и решается с помощью макрасов?).
Глянь fasm, там тема с макросами дошла до того, что можно программы писать только из макросов, без инструкций ЦП.
И если кодить на ассемблере под Windows, то там в основном куча вызовов библиотечных процедур (invoke имяпроц парам1, парам2, парам3), хоть это и не избавляет от необходимости понимания работы процессора и ассемблера.
ЦитатаXakep ()
естественно, если ты не знаком с функциональной парадигмой, все что будет написано будет не понятно, хоть как ты обзови переменные
Если не ошибаюсь, функциональная парадигма отличается отсутствием классических переменных — т.е. все результаты куда-то передаются, а если и хранятся, то без изменений. Из-за этого код выглядит так: v = Func1(Func2(Func3(Func4(1, 2, 3)))); Т.е. "Func4 сделала что-то с 1, 2 и 3, передала ответ в Func3, которая ... в Func1, которая сохранила результат работы в v". По-моему всё просто.
Так что проблема опять же сводится к названиям) Вот что это за Func4 и почему она получает 1, 2 и 3? Кто знает...
Или языки типа Forth. На них можно писать как угодно, но обычно пишут кучей сокращений из двух-трёх букв, и это нереально усложняет понимание кода. Читал что-то типа "программист разговаривает с Фортом на собственном языке", и в примерах там были читабельные имена, а реальный код... Далёк от этого.
ЦитатаXakep ()
все раздроблена настолько мелко и не пойми как взаимодействует друг с другом.
Оглавление, оглавление надо делать) И по папкам раскладывать по смыслу.
ЦитатаXakep ()
можешь не понимать, но тебе это решение по умолчанию может показаться красивым
Ну не знаю, я не могу посчитать "красивым" то, что не могу понять... Возможно, я вижу красоту в работе каких-то систем, а внешняя сторона (синтаксис, именование, дробление) только обёртка; однако в плохой обёртке работу этих систем становится трудно разглядеть.
На счёт возможности писать понятно, но некрасиво — не спорю, но обычно так получается с маленькими участками кода, в которых грязь не мешает восприятию)
ЦитатаXakep ()
Просто не пользуйся не нужным мусором и пиши в своем стиле
Легко сказать. Трудно пересилить нежелание делать что-то вручную)
ЦитатаOrdan ()
И вот, я часто слышу от плюсовиков о проблемах с памятью и никогда не понимал, что за ужасы там творятся то)
Там вроде любая более-менее сложная задача решается через динамические структуры данных, т.е. через указатели. Когда в других ЯПах есть особые структуры или классы для работы с такими данными, сишникам приходится писать всё вручную.
Раньше я тоже пробовал пилить свои структуры данных на указателях, получалось нормально (список, стек, даже дерево вроде), но потом надоело каждый раз с нуля это делать и теперь пользуюсь TList или просто массивами записей. Нет у меня таких задач, которые нужно было бы оптимизировать указателями.
ЦитатаOrdan ()
Когда ты будешь делать другие проекты твой навык кодинга, всяко выше чем когда делал предыдущий проект и старый код будет для тебя просто мусором.
Про навык согласен, но если уж приходится часто переписывать, лучше один раз написать и использовать. Когда навык поднимется значительно — вернуться и переписать лучше.
Но, окей, это всё абстрактные размышления, так можно вечно обсуждать)
Мне кажется, что незаслуженно обойдена/проигнорирована очень важная тема (и для Unity, и для C# вцелом). Речь идет о реализации Text-To-Speech подсистемы. Тем более что реализация модулей TTS уже предполагает различные решения для "сетевых" и локальных синтезаторов.
А в чём вопрос-то? Как подключить TTS к Unity или использовать на C#? Или какие варианты TTS существуют?
Цитатаsandy ()
(Для новичков краткое пояснение: TTS, это когда вместо мегабайт предзагруженных аудио-диалогов, вы сможете использовать килобайты требуемого текста)
Мне кажется, технологии TTS пока недостаточно развиты для того, чтобы использовать их в творческих проектах. Это как если бы все персонажи в ААА-игре говорили голосом "гугл-робота" (см. на ютубе серию роликов).
Да и в чём плюсы от TTS? Однозначно не в экономии дискового пространства (сейчас его принято не экономить). 1. Можно на клиенте озвучить любой текст, даже такой, который изначально не был задуман. Нужно ли это играм? Пока нет полноценного ИИ, который не выглядел бы как тупой чат-бот или не менее тупой игровой болванчик, подобная возможность играм не требуется (все тексты заготовлены заранее). 2. Можно серьёзно сэкономить на найме актёров озвучки. Но большим проектам это вообще не нужно (мочить репутацию?), а инди-разработчики предпочитают обходиться текстом. В конце концов все давно привыкли к тому, что большинство игр либо не имеют озвучку совсем, либо озвучены лишь основные/начальные квесты. 3. Экономия пространства диска - сомнительно, т.к. звук требует меньше места, чем качественная графика, а качественный TTS движок сам по себе весит не мало. Ещё нужно будет посчитать, будет ли выгода - у Вокалоидов, к примеру, банк данных одного персонажа весит сотни мегабайт, если я ничего не путаю. Если использовать облачную технологию - возникает необходимость в интернет-подключении, плюс всё сломается, когда кончится лицензия/аренда или облако закроется.
Тут ещё затрагивали тему по обучению языку - так вот в обучении языкам от TTS вообще мало пользы, и, насколько я знаю, все адекватные сервисы обучения используют записи живых актёров. Просто от примитивного TTS трудно добиться правильного звучания, особенно для новичков в языке, а продвинутый TTS может оказаться невыгодным.
Теоретически, нейронные сети вроде как достигли больших успехов в области TTS - пару лет назад были примеры "неотличимого от человеческого" синтеза голоса, но там другая проблема - на пользовательском ПК такой синтез займёт слишком много времени, и уж тем более для игр не подходит, поскольку игра и без синтезатора сильно нагружает любой ПК.
Вообще, TTS хорошо подошёл бы к какой-нибудь игре на тему роботов и всего такого, но, опять же, выгоднее было бы заранее записать фразы и не париться с подключением TTS-движка, если в игру не встроен чат-бот, самостоятельно синтезирующий текст. Короче, нет источника оригинальных текстов - нет необходимости в TTS, особенно если TTS звучит фигово.
Кстати, если подгонять TTS под серьёзную игру, придётся записывать голосовой банк практически под каждого персонажа - и здесь уже неизвестно, что будет дешевле, записать несколько фраз или целый банк (не знаю, насколько трудно создать голосовой банк с нуля, и что может дополнительно потребоваться от актёра). Плюсом - лишний вес игры от каждого дополнительного банка...
Lich420king1337, sandy, пожалуйста, юморите в разделе флейма, зачем здесь это?
готов работать для начала за идею на чистом энтузиазме. Готов возглавить проект
Ну так работай над каким-нибудь своим проектом, потом художников найдёшь. Кто в здравом уме будет искать "лидера на чистом энтузиазме", если тут каждый первый сам себе лидер?)
ЦитатаIcticStep ()
-знаю С, С++ -умею верстать на html/css/js -очень хорошо знаю движки Construct 2, Construct 3 -умею писать хороший сюжет и диалоги
Продемонстрируй примеры своих работ по всем заявленным пунктам, иначе так любой может сказать "я очень хорошо умею...", а потом выяснится, что "очень хорошо" не так уж и хорошо...
Да и "знаю C/C++" - это как "знаю английский язык", на деле ни о чём не говорит. Знать можно по-разному - в разных сферах применения и с разным багажом знаний/опыта... Уточнять надо, раз уж примеров нет (на гитхабе, скажем).
Нет, я не говорю, что тебе обязательно нужно всё это демонстрировать, но с несерьёзным подходом можно получить предложения только от несерьёзных людей, с которыми далеко не уедешь, даже если сам будешь делать всё возможное)
но никак не пойму, это игры-песочницы или полноценные конструкторы с возможностью скомпилировать проект
В Steam игры размещаются в категории Games, а софт для разработки игр - в Software. Возможность создавать свои уровни и распространять их через встроенный функционал не делает игру конструктором.
Так что на первый взгляд (лень вчитываться), все три проекта - это именно "игры-песочницы с продвинутым редактором".
ЦитатаGameDev2 ()
очень много всякого рода конструкторов игр, глаза разбегаются
Есть спрос - рождается и предложение, но спрос этот у тех, кто ниасилил старые средства разработки. Имеет ли смысл пробовать все эти конструкторы, тем более в Early Access (т.е. "куча багов, минимум пользователей, возможно разрабы бросят"), если умеешь пользоваться более полноценными, а, главное, надёжными инструментами?..
...Да и вообще, все три проекта - бесплатные, поставь себе и поюзай, если надо. Или полистай форумы Steam, там наверняка задавались такие вопросы. Нам за тебя что ли это делать?)
Сообщение отредактировал TimKruz - Пятница, 16 Августа 2019, 16:28
Хотелось влететь в тему с криком "ребята, я в этом шарю!", но кого я обманываю...
ЦитатаNikitaKobich ()
Сколько находил только 3-4 урока/примера и все
Плохо искал. Под старый OpenGL (1.x) уроков масса, есть даже книги (я с одной такой начинал в своё время). Под новый OpenGL (2/3+) уроки тоже есть, но в основном на английском и не для Pascal, однако разницы между разными ЯП в плане управления OpenGL - никакой абсолютно.
Самое главное, что важно знать, когда хочешь программировать с OpenGL на Pascal-подобных ЯПах: весь OpenGL-код состоит из обращений к OpenGL-библиотеке, а такие обращения во всех современных ЯП выглядят плюс-минус одинаково. Т.е. вам нужно знать названия функций OpenGL и что они принимают на вход, а на каком ЯП эти функции вызывать - не имеет значения.
Так что, чтобы программировать OpenGL на Pascal, достаточно уверенно владеть каким-либо диалектом Pascal, английским языком и навыком поиска по интернету. Всё. Разумеется, полный новичок в программировании такое не потянет (ну, OpenGL вообще не для новичков)...
ЦитатаOrdan ()
Однако всё равно тема паскаля(ныне дельфи)
Ээээм? С каким пор Паскаль - ныне Дельфи? Delphi - это RAD IDE; ещё так иногда называют диалект Object Pascal, который этой средой используется со времён Borland, но Паскаль остаётся Паскалем. С сайта Embarcadero:
Цитата
Trusted for over 24 years, our modern Delphi is the preferred choice of Object Pascal developers worldwide for creating cool apps across devices.
Кстати, недавно решил полностью пересесть на FreePascal/Lazarus - оказалось очень удобно, ничем не хуже Delphi, в чём-то даже лучше (кроссплатформенность, бесплатность, некоторые дополнительные фичи диалекта). Ну, для меня-то вообще почти никакой разницы, т.к. уже года два почти всё программирую в PSPad, вызывая компилятор Delphi/FPC через командную строку. Т.е. принципиальная разница только в некоторых особенностях диалекта и директивах компилятора, если не нужна VCL/LCL.
Да и вышеупомянутый PascalABC.NET - отдельный диалект Pascal, только не знаю, кто им пользуется по-настоящему, кроме разве что некоторых школ...
ЦитатаOrdan ()
про грамотный рендер спрайтов я вообще чудом узнал
Ммм, а есть что-то более грамотное, чем натягивание текстуры на quad? Хотя quad'ы вроде считаются устаревшими...
P.S. Очень печально, что раздел Pascal на GCUP немножко умер.
P.P.S. Я тут в начале августа решился начать пилить свою игорь, да, на FPC+SDL2+OpenGL... Небывалый случай - работаю над одним проектом 10 дней подряд, раньше рекордом было 2-3 дня... Хочется создать тему игры, но какой смысл, если показать пока нечего (нужно хотя бы полноценную 3D-сцену отрендерить и управление "персонажем", а так это всё не далеко от моих предыдущих опытов ушло, коих было с десяток и все брошены). Хотя ладно, не важно, всё равно чисто для себя пилить собирался...
---- Я случайно сломал сообщение, пришлось фиксить
Сообщение отредактировал TimKruz - Пятница, 16 Августа 2019, 18:01
TimKruz, Спасибо, хоть один нашелся ЧЕЛОВЕЧИЩЕ, кто помог, кинул полезной инфы.
Просто удачно зашёл и заметил тему)
ЦитатаNikitaKobich ()
А то что мы с Максом решили немного рассказать о уроках чувака которого смотрим, но хочется альтернативы, а тут сразу налетели и ...
Эм, я не знаю, правду ты говоришь или как, и мне это не важно, но... Зачем было именно так? На спектакль похоже, а такое обычно только спамеры делают. Хочется рассказать про ютуб-канал? Есть раздел "Кино и видео", там таких тем полно и никто вроде как не жалуется...
Или, если канал чужой, можно же было написать так:
Цитата
Ищу уроки по OpenGL на Pascal, нашёл этот ютуб-канал, но хочется попробовать что-то другое, покидайте ссылок...
И тогда никаких проблем бы не было, потому что ссылка по теме и вопрос адекватный.
Ну и я не знаю, помогут ли вам мои ссылки, т.к. я-то с Паскалем уже лет десять, а щупать OpenGL начинал лет восемь назад... Трудно объективно оценить уровень вхождения в тему, в которую уже давным-давно вошёл. Да и видеоуроки меня никогда не интересовали - мне проще пролистать текст, глянуть иллюстрации, а потом перепечатывать код, попутно читая объяснения... Все эти видеоуроки выглядят скорее как развлечение, чем реально полезные материалы.
Хотя "Modern OpenGL" я сам только планирую изучать (правда, "крутой графоний" мне вообще не хочется, мне бы геймплейно игру выстроить, ботам ИИ нормальный смастерить, генераторы контента конструировать, а графон сойдёт и как в 90-х), а то глупо как-то в 2019 пилить новый движок/игру на основе того, что существует с 90-х...
Суть в том, что я не художник. Немного рисую в Illustrator, но это не люди, а предметы, а чаще абстракции. Умею кодить. Вопрос: стоит ли пытаться стать инди-разработчиком, или сначала лучше научиться рисовать?
Аналогичная ситуация. Рисовать пытался годами, но это было мучительно больно; теперь мне больно от одного желания "снова порисовать". И в 3D тоже пытался, тоже через боль и т.п. А вот программирование как-то легко всегда давалось, но что толку без контента?..
Так что могу сказать, что как минимум для людей типа меня "сначала научиться рисовать" = "потратить N лет на освоение навыка", и в итоге не получить ни удовольствия, ни желаемого результата (ради чего всё начиналось). Вообще, настоящий художник отличается тем, что не может назвать себя хорошим художником - и потому непрерывно развивается. Как понять, что ты уже достаточно хорошо развил нужные навыки, чтобы применить их для создания игрового контента?..
Однако инди - это не только "мастер на все руки", это в принципе любой "независимый разработчик". Независимый от издателя, а не от любых других людей. Если раньше игры делались строго по контракту с издателем (и на деньги издателя, если я правильно понимаю), то с приходом новых технологий стало возможно делать игры дёшево и распространять без помощи издательств. Так что можно быть программистом в инди-компании (пусть из 2-3 человек) и только программировать, и при этом быть "инди".
С другой стороны, если нет возможности или желания искать напарников, а программировать уже умеешь неплохо - можно просто начать делать игру без контента, или с т.н. "программерским артом". Т.е. пусть у тебя будут некрасивые картинки и кривые модельки, но они будут крутиться на рабочем движке и в это уже можно будет поиграть. А там уж можно будет попытаться найти артистов, подходящих по качеству/стоимости. Ну или постепенно наращивать свои художественные навыки, ведь даже игра без качественного контента делается не за два дня.
Так что полностью согласен с:
Цитатаb_ear ()
кто-то осудит, но времени в нашей жизни мало, поэтому моя рекомендация - учиться на реальном живом проекте гораздо лучше чем просто так. Мне казалось вы уже вступили на этот путь), ваш проект "[3d]Легенды Эйнарии[rpg]", разве нет? Не стесняйтесь, делайте свой проект, повышайте навыки. Главное - не останавливаться! Если самому нарисовать или сделать 3Д-модели совсем не получается, ищите помощников готовых сделать это для вас на энтузиазме/для получения опыта или за небольшую оплату. Можно комбинировать свои работы и других художников, если вы сами тоже развиваетесь в этом направлении.
Главное, чтобы проект не надоел и не оказался заброшен)
Цитатаavkvl ()
самый оптимальный путь - это когда берешь на себя предпринимательский риск и платишь другим людям за их работу
Тогда можно свести всё это "инди" к банальному "я заказчик, ты - исполнитель, теперь сделай мне игру".
Всё-таки одно дело, когда у тебя много денег и предпринимательского опыта, и тебе хочется поиграть в специфическую игру (о которой ты давно мечтаешь, но занят своим бизнесом), и совсем другое дело - это когда ты мечтаешь не об игре, а о романтике разработки игр, или о том, чтобы "сделать игру своими руками". Ведь наняв команду рабочих, ты можешь получить результат, но не можешь получить удовольствие от процесса разработки (который пройдёт мимо тебя).
Так что, ИМХО, тут ещё всё зависит от целей.
Цитатаavkvl ()
Если я сяду рисовать персонажа, я потрачу может быть 10-20 часов и результат все равно будет далек от профессионала. Профессионала я могу привлечь за 2-3 тысячи рублей. Я эти 10-20 часов своего времени продам сильно дороже.
С рациональной точки зрения ты прав; но если сравнить полученную за N килорублей модельку от фрилансера со своими руками сделанной моделькой, которая на порядки хуже модельки от фрилансера, то к своей испытываешь как-то больше чувств и всего такого, что составляет основную часть романтики игростроя... Если тебе нужно как можно быстрее создать игру и получить от неё много денег - то тут не до романтики, конечно, но стоит ли смотреть на игры исключительно как на средство заработка?..
Кроме того, вон Minecraft не очень графикой может похвастаться, ну что там 8x8 цветных пикселей стоит нарисовать? А ведь это тоже 3D. Никто не ждёт от независимого яжпрограммиста ААА-проект, убийцу всех остальных ААА-проектов. Игры делаются не только благодаря отточенным навыкам в какой-либо сфере...
И да, я лично всегда мечтал "делать одну игру десятилетиями", и испытываю уважение к тем, кто не бросает разработку своей игры спустя 10/15/20 лет. По-моему, это круто. Круче, чем все эти вылизанные до блеска "профессиональные" проекты, приносящие кучу денег своим создателям, но совершенно бездушные изнутри...
1. Знаний программирования нет. 2. Логическая игра на вычисление нужного по исходным данным. Типо логической задачи. Данные меняются в зависимости от действий игроков. Количество игроков до 100 одновременно (multiplayer).
Не совсем понял, что за задачи предполагается разрешать, тем более на 100 игроков, но без знаний программирования тут никак не выкрутиться, даже с помощью "конструкторов". Конструкторы обычно упрощают процесс добавления в игру контента - графики, музыки, текста - и управления им как игровыми сущностями (типа перемещения картинок по экрану по заданным правилам, с автоматическим обсчётом физической модели и т.д.). Игровая же логика в любом случае кодится, и чем больше перевес в сторону логики, тем меньше преимуществ от конструктора.
Ну и лично я что-то не помню ни одного конструктора, в котором было бы легко и просто сделать мультиплеер хотя бы на 4 игрока по сети, что уж говорить про 100... Сотня игроков в одной сессии - это уже по сути ММО, потребуется отдельный сервер, который конструкторы чаще всего обеспечить никак не могут (кроме специализированных под ММОРПГ) - придётся кодить самому.
Ну и наконец, если под Android и игра фокусируется на "логических задачах" (подозреваю, что-то текстовое?), то лучше будет либо писать с нуля на Java, либо использовать какой-то легкий игровой фреймворк. Потому что любой конструктор игр тащит во все свои игры своё программное ядро, в котором много функций, бесполезных для конкретной игры и нагружающих зазря и так не очень мощное мобильное железо (ниже требования к железу = шире охват пользователей).
Так что конкретизируй свою задачу, а то так можно любой универсальный конструктор предложить... Но сразу предупреждаю, что если идея какая-то очень необычная (не попадает ни в одну популярную категорию игр), то никакого специализированного конструктора найти не удастся, и тут действительно либо с нуля писать, либо универсальный брать.
Нет никакого желания вчитываться в этот код, но замечания возникают даже от просмотра по диагонали:
1. Паскаль - в первую очередь структурный ЯП. Под структурами подразумеваются вот эти все if, for, begin-end и всё остальное, что позволяет организовать код удобными блоками. Но главное в них то, что их должно быть удобно читать - а этого можно добиться только правильным оформлением.
То есть вместо такого безобразия:
Код
begin for x:=1 to 12 do for y:=1 to 22 do begin ss:=st[x,y]; k(x,y); end; end;
Должно быть хотя бы так (но это всё равно плохой код, см. ниже):
Код
begin for x := 1 to 12 do for y := 1 to 22 do begin ss := st[x, y]; k(x, y); end; end;
В противном случае становится труднее читать код.
2. Паскаль - замечательный язык, именно язык, а не набор спецсимволов. На нём нужно говорить, а не выстреливать порции случайно нажатых символов. Код должен быть читаем - в нём должны быть слова.
То есть вместо множества всяких pus, ss, st, n, k, c, b... и прочей чепухи должны быть СЛОВА. Лучше - слова английского языка. В идеале чтобы получались связные предложения, по которым можно понять, что происходит в конкретном участке кода.
В частности, переменные должны называться существительными и отвечать на вопрос "что здесь хранится?", названия процедур и функций должны состоять из глаголов и отвечать на вопрос "что будет сделано?", и т.д. Без этого код становится очень трудно читать, понимать, изменять и искать в нём ошибки.
3. Комментарии в коде - это хорошо. Но только тогда, когда они действительно нужны. Не нужно комментировать то, что понятно и без комментария. Если что-то без комментария понять невозможно - значит, это что-то нужно переименовать или переписать другими словами, так, чтобы стало понятно без комментариев.
Чаще всего комментарии должны покрывать трудные места, в которых используются какие-то хитрые трюки, или в которых встречается трудноуловимая ошибка, избежать которой невозможно, и т.п. В идеале, код должен сам про себя говорить всё, что о нём можно сказать - без каких-либо дополнительных комментариев.
Нет, конечно, для учебного кода имеет смысл написать дополнительные комментарии, но конкретно этот код нельзя использовать как учебный. Он ничему хорошему не научит.
4. Чем больше кода между begin и end подпрограммы - тем труднее её воспринимать. Даже если какой-то блок кода не планируется использовать повторно, его следует выделить в отдельную подпрограмму, если он вырос слишком большим. Главное преимущество подпрограммы - уникальное имя, по которому к ней обращаются. Это имя позволяет лучше понимать те процессы, которые происходят в коде программы - разумеется, если выполняются описанные выше правила.
Помни, что любой крупный безымянный блок кода - лишние минуты на его чтение с целью понять, что в нём происходит. Код, разумно разделённый на именованные блоки, значительно проще для восприятия и редактирования, и потому более ценен.
Дальше разбирать неохота, без описанных основ смысла в коде никакого. Написал всё это в защиту Паскаля, а то некоторые после встречи с подобными "тетрисами" потом ругаются в сторону языка программирования, не понимая, что язык к такому коду вообще никакого отношения не имеет...
Вообще, программирование - это искусство, а не "тяп-ляп и вроде работает". Может, позже когда-нибудь поймёшь...
ЦитатаDimaLink ()
А такой паскаль EXE файл дает создать?
PascalABC.NET - компилятор, а не интерпретатор, так что - да, это его предназначение. Но если хочешь серьёзный Паскаль, лучше пробуй Free Pascal (и Lazarus) или бесплатную версию Delphi CE - у них богаче история, шире сообщество, много библиотек, стабильность, кроссплатформенность и т.д. А то у PascalABC.NET сайт лёг (как сейчас) - и всё, где информацию достать?..
ЦитатаTLT ()
В движке, как вижу, не предусмотрены фигуры из больше четырёх квадратов? А зря - разновидности Тетриса были и с более разнообразными фигурами, нежели стандартный набор.
С таким-то кодом он вполне благоразумно не стал усложнять дизайн игры. Тут каждая новая фича будет даваться кровью и потом, если вообще будет даваться... Зато потом придёт осознание причин таких проблем и с нуля напишется много лучше.
Сообщение отредактировал TimKruz - Воскресенье, 01 Сентября 2019, 03:09
проще говоря, язык остановился в развитии 15 лет назад
Я таки не понимаю, какое развитие может быть у языка программирования? Кроме исправления багов в компиляторах... Нет, ObjectPascal/Delphi и FreePascal/Lazarus развиваются. Конечно, не так быстро, как всякие си, но есть ли смысл добавлять кучу лишнего мусора в язык, в котором и так есть всё необходимое для хорошей жизни?
ЦитатаShortKedr ()
Ну и Pascal по синтаксису кода менее удобный и более времязатратный
Если тебе Pascal кажется неудобным и времязатратным по синтаксису, то ты просто не знаком с языком Ada. Вот у Ada синтаксис, ИМХО, самый лучший, лучше Pascal. Да и в целом она строже, как Pascal на максималках... Только по производительности не очень и изучать трудно, трудно найти нужную информацию...
Цитатаnikolas-z ()
Судя по всему, сэр, вы и по русски с трудом глаголете. Студенты? У вас? Нда...
Судя по всему он белорус, и если его родной язык белорусский, то вполне очевидно, почему ему трудно даются некоторые элементы русского языка.
ЦитатаShortKedr ()
FreePascal всё таки компилятор, сам язык называется ObjectPascal.
Free Pascal - современный диалект Object Pascal, т.е. отдельный ЯП. Компилятор Free Pascal называется FPC (Free Pascal Compiler), и он умеет в разные диалекты в режиме совместимости.
ЦитатаOrdan ()
у дельфи помимо классов есть такая штука как "Record", у него функционал как у класса, однако его не нужно ни создавать, ни удалять
Record не является аналогом класса. Record - сложный тип данных, как string или array. Только настраиваешь самостоятельно. Class - эволюция object из старого Object Pascal (да, раньше была другая реализация ООП), позволяет объединять процедуры-функции вместе с данными, определяется как ссылка. Кстати, старые object создавать тоже не нужно было, но точно не помню, это устаревший функционал.
Т.е. record - сложная переменная для данных, а class - пачка методов, которые могут владеть данными. Хотя в принципе процедуры могут быть представлены как данные (ссылки), но это всё-таки совсем разные вещи.
ЦитатаOrdan ()
К примеру если я создам массив из миллиона Record, а потом изменю размер массива до 10, то вся память сама освободится и никакого гемороя
На заметку: при изменении размеров динамических массивов (это те, что array of без указания границ) происходит полное копирование всего содержимого массива из одной области памяти в другую, если в памяти есть свободный блок достаточного размера. Так что лучше быть аккуратнее с частым изменением границ огромных массивов...
И таки нельзя забывать, что переменные типа record можно создавать динамически, т.е. через New(), удаляя через Dispose(). Вот тут-то можно получить утечку, если забыть Dispose() и потерять ссылку...
Кстати, с помощью динамически создаваемых record можно делать какие угодно динамические структуры данных - стеки, очереди, деревья и т.д. Т.е. тип record может содержать в себе ссылку на тот же тип record, очень удобно.
И для сравнения: массив из миллиона class будет изначально содержать указатели на nil (аналог null). Ты в этих указателях можешь хранить ссылки на экземпляры классов, которые совсем не обязательно освобождать при уменьшении массива - ведь они могут использоваться где-то ещё. По сути, ты должен воспринимать массив как набор ссылок на объекты, а не как набор объектов - удаление массива ведёт к потере ссылок и ничего не говорит о состоянии объектов (которые, вообще-то, могут быть освобождены сборщиком мусора, если на них больше нет активных ссылок, но это не точно).
Цитатаdrcrack ()
просветите, какие у него вообще есть преимущества перед актуальными языками типо Java/C#/C++?
Ну если ты сомневаешься, то для тебя - никаких. Меня больше интересует, какие преимущества есть у Java/C#/C++, если их синтаксис отвратителен, стиль кода ужасен, первые два сидят на медленных виртуальных машинах (совсем не Forth), и они не предоставляют ничего уникально нового по сравнению с любым другим языком. Единственный сомнительный плюс - производительность C++, но кому нужна производительность кода, который невозможно безболезненно прочитать человеческими глазами? Эдак лучше на Ассемблере писать, ещё быстрее получится, и никаких лишних синтаксических гадостей не будет.
Цитатаdrcrack ()
ну так и в Java/C# тоже нет проблем с памятью
Нет контроля над памятью - нет проблем с памятью, так что ли?) Можно ли в Java/C# вручную адресовать какой-то блок памяти? Вряд ли, они же на виртуальных машинах, абстрагируются от доступа к реальному железу... Можно сказать, что памяти у Java/C# вообще нет))
Сообщение отредактировал TimKruz - Воскресенье, 01 Сентября 2019, 04:49
