Вообще, нужно взять бумажку и задать на высшем уровне абстракции все возможные в текущем представлении сущности. Если разговор о "змейке" - задаете вопрос, что у вас в игре есть как сущности. Скажем, есть змея, есть стены, есть жрачка, их пишете как сущности. Затеяли добавить "муху" - пишете тоже. Затем пишете, кто что умеет делать: змея умеет ползать, стукаться в стены или жрачку, расти и возможно что-нибудь ещё, стены просто стоят, жрачка умеет появляться, съедаться. И так далее, пока всю игру в примитивах не опишете. Дальше - каждая сущность это класс, каждое отношение это метод, каждый параметр, выясненный в процессе, это свойство класса. Но чем дальше в лес, тем больше грабли. На уровнях выше начинаются модули со своей инкапсуляцией, события, гонки всякие, а-ля "кто съел яблоко, вы или противник", асинхронное взаимодействие, подписки на что-либо, и так далее, интерфейсы становятся сложнее, какие-то объекты передаются как параметры и всё такое, но общий принцип остается - сначала большими кусками всё делится на куски поменьше, определяются интерфейсы (кто что может спросить или повлиять на кого), пытается реализовываться, потом, вполне возможно, находятся противоречия, которые приходится устранять рефакторингом, и по спирали.
Что поизучать - сначала просто базовое ООП, чтобы понять, из чего вообще строить программу, что такое объект, класс, интерфейс, наследование, полиморфизм (та же жрачка может быть нескольких видов, например, но "съедается" она одинаковым образом), инкапсуляция (а-ля "не лезь в мои свойства своими лапами"). Все эти SOLID и прочие аббревиатуры, а также паттерны и антипаттерны, появятся в процессе, когда от архитектуры перейдете к дизайну самих сущностей и написанию кода методов. По-моему так.
Сложный
