Переход от ООП к ECS при разработке игр⁠⁠

Ты бы еще PHP взял, а потом жаловался, что оно кривое.

Кхм, ну начинать тогда можно и с турбопаскаля=)))

Начинать можно с чего угодно что сердцу милее, но все же стоит учитывать два момента -- новички часто вообще не понимают куда им податься (не просто так всякие древа знаний клепают типа "путь в профессию" и прочее), а что еще нужно учитывать и что крайне важно -- это психологический момент -- ну начинаем мы тот же с++ давать новичку, так вот он охует уже с первых строк своего кода (ну помимо привет мир), потому что сразу столкнется с тем что ему нужно начать свою соображалку включать еще до того как он что-то там написал (а если новичок и вовсе без какой-то базы?) -- что вызвать, что объявить и потом еще куда-то это деть и все блятские точки с запятыми расставить -- не полет творчества, а облом сплошной. И с самого начала одна теория, теория, пока злосчастный калькулятор (что угодно подставить из того что там новички пишут) начнешь писать, охренеешь настолько, что возможно до калькулятора дело не дойдет вовсе.

Именно поэтому пайтон и считается хорошим выбором для новичка, он на первых порах не заставляет забивать голову всем подряд в том числе и выбором направления куда потом бечь, он дает возможность войти в программирование плавно и очень ласково (на сравнении), то что в этих спокойных водах куча подводных камней, узнается потом, а до того момента как это "потом" наступит, человек уже нахватается какого никакого опыта и знаний, что позволит нырять в другие темные омуты с шансом не утонуть сразу, а еще потрепыхаться немного. Оставаться на пайтоне выше начального уровня и общего понимания -- нужно лишь тем кому нужен именно пайтон (но еще, конечно, стоит раз 10 подумать, нет ли иных вариантов).

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

хрен поспоришь :D
Но развите таки претендует на оригинальность.

Классическое ООП не подходит для разработки игр.

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

Я придумал достаточно оригинальную идею игры

Спойлер: оригинальная идея - это тетрис

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

ошибка tkinter'а

Пайтон очень многое позволяет, например писать не чистым ООП, вообщем новичку наломать дров и запутаться очень легко. Можно конечно такое и в шарп попытаться сделать, только чтобы такое устроить в шарп надо еще голову поломать как=)) Поэтому с шарп сидишь и изначально все продумываешь, приходиться больше разбираться с классами, доступами, инкапсуляцией, переменные разбирать, структуру продумывать, проверкам время уделить и т.д То что в пайтоне на начальных этапах редко кто голову забивает ( и оно конечно же потом все вылезает боком). Вообщем из-за особенностей самого языка есть шансы избежать самых очевидных граблей, он просто заставляет сесть и немного больше подумать над тем что за хрень ты пишешь что и куда у тебя пойдет, где и как будет использовано, конечно же от всех ошибок и проблем это не убережет, но все же приучает чуть к другому подходу, чуть к другому программированию изначально. Именно поэтому советуют начать с пайтона как базового (чтобы интерес не отбить), но потом, как в основы вникаешь перейти на что-то более "строгое" на практике, с# для этого хорошо подходит, потому что все же попроще для понимания и поинтереснее на началах чем java или c++.

Серьезное, не серьезное, на пайтон можно и "серьезное" писать, смотря что подразумевать под "серьезным", если имеется в виду нагрузка, типа что-то объемное и должно быстро фурычить, то конечно пайтон проиграет c# (вот насчет проиграет ли c# с++ -- тут от прямоты рук зависит и от того что конкретно пишется). У с# есть свои преимущества, а есть и свои недостатки, но именно для игр он хорошо подходит.

Что бы делать успешные игры можно вообще ничего не учить (имеется в виду глубоко не нырять), сейчас многое можно собирать практически из готового, главное идея самой игры, есть куча игр (механик), которые не требуют семи пядей во лбу чтобы их написать -- т.е важнее всего именно сама игра, насколько она получится реиграбельной и сколько времени будут игроки в ней проводить, а не сложность и красота кода и на чем она там написана=)

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

Писали бы, например, на С# и никаких бед бы не знали=))) Потому что вам сам язык ограничил бы и требовал бы прописывать и разрабатывать структуру от и до понимая как оно будет развиваться и расти, а не как попало =))))

А если серьезно, ну не пишите вы на пайтоне игры, так себе затея, зачем так все усложнять для себя, получится рано или поздно, но будете все методом набивания шишек добирать. С# -- и вперед (тот же юнити). С++ не предлагаю, хотя может он вам понравится больше, просто он сложнее..

Путал , ecs это уже движок в любой реализации , а не просто принцип

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

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

Особенно учитывая что ты подход с движком путаешь