Архитектура игры под Android

@VV_RIP · Регистрация: 05.02.2012

Студворк — интернет-сервис помощи студентам

Здравствуйте! Я новичок в создании игр, но хотелось бы сделать что-то приличное, с возможностью повторного использования кода и т.д. Игра будет с использованием графического движка AndEngine. Погуглив, я нашел несколько вариантов, но хочу пока предложить один пример (картинка во вложении). Игра будет не сетевая, поэтому с виду все подходит. Как вы думаете, стоит ли её использовать? или у этого примера есть какие-то явные проблемы, которые я пока не вижу?

@XAHOK · 05.08.2013, 15:46

Классическая архитектура на MVC с менеджером ресурсов. Проблемы могут быть только от ее реализации Вами (особенно внимательно нужно подойти к реализации AI части). Если жесткие связи между типами закладывать не будете, то большинства проблем избежите. При желании такая архитектура легко расширяется и для сетевой игры.

@VV_RIP · 11.08.2013, 14:11 **[ТС]**

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

@XAHOK · 11.08.2013, 23:46

Если вы с асинхронным программированием раньше не сталкивались, то лучше и не заморачивайтесь с многопоточностью. А вообще оцените сначала целевую аудиторию и используемую ими аппаратуру. И затачивайте игру под самый слабый аппарат. Если все таки хотите многопоточный вариант, то посмотрите в сторону синхронизации потоков, а так же на хранение зависимостей между подпрограммами, на основе которых определяется порядок выполнения.

@Nomadd · 13.08.2013, 16:50

А зачем разделять PlayerView и PlayerModel, CreatureView и CreatureModel и т.д.?
Ведь проще создать такой класс, который будет обрабатывать и рендер,и игра.

@XAHOK · 13.08.2013, 18:16

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

Так же такую разделенную систему намного легче покрыть автоматическими тестами.

@Nomadd · 13.08.2013, 21:08

Про паттерн MVC я читал, и даже реализовывал. Но я не делал по 2 класса на один объект.
Т.е. я делал базовые классы контроллер, модель и представление.
Контроллер вызывал из модели функцию Draw, и в качестве аргумента передавал представление.
В функции Draw модель в цикле отрисовывала кубики с текстурами функциями, вызванными из представление.
А для создания нового типа объекта(к примеру дерево) нужно было создать один класс. Потом я ещё хотел сделать для каждого типа объекта свою функцию отрисовки, принимающую представлениев качестве аргумента.

@XAHOK · 14.08.2013, 06:31

Сообщение от Nomadd

Про паттерн MVC я читал, и даже реализовывал. Но я не делал по 2 класса на один объект.
Т.е. я делал базовые классы контроллер, модель и представление.
Контроллер вызывал из модели функцию Draw, и в качестве аргумента передавал представление.
В функции Draw модель в цикле отрисовывала кубики с текстурами функциями, вызванными из представление.
А для создания нового типа объекта(к примеру дерево) нужно было создать один класс. Потом я ещё хотел сделать для каждого типа объекта свою функцию отрисовки, принимающую представлениев качестве аргумента.

У вас ошибочное понятие представления. Представление - это ваш реализованный вами метод Draw. Если говорить простым языком, то представление отвечает на вопрос - как отображать. В целом у вас должно получаться не 2 класса на объект, а 3 класса. Один класс отвечает за рендер объекта, второй за внутреннюю логику и взаимодействие объекта со сценой, и третий - модель данных объекта (причем этот класс будет корневой). Рендер и логика (представление и контроллер) являются независимыми и любой из них можно независимо заменять и/или изменять. Да и найти нужное место в узко-специализированном классе намного проще, чем в одной портянке, в которой и рендер, и логика и модель данных.

Новые блоги и статьи Все статьи Все блоги /
Первый деплой lagorue 16.01.2026 Не спеша развернул своё 1ое приложение в kubernetes. А дальше мне интересно создать 1фронтэнд приложения и 2 бэкэнд приложения развернуть 2 деплоя в кубере получится 2 сервиса и что-бы они. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь постоянного тока с R, L, C, k(ключ), U, E, J. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа, решает её и находит токи на L и напряжения на C в установ. режимах до и. . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?
Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .

@VV_RIP 11 / 10 / 1 Регистрация: 05.02.2012 Сообщений: 106

	Архитектура игры под Android 03.08.2013, 12:42. Показов 3045. Ответов 7 Метки нет (Все метки) Здравствуйте! Я новичок в создании игр, но хотелось бы сделать что-то приличное, с возможностью повторного использования кода и т.д. Игра будет с использованием графического движка AndEngine. Погуглив, я нашел несколько вариантов, но хочу пока предложить один пример (картинка во вложении). Игра будет не сетевая, поэтому с виду все подходит. Как вы думаете, стоит ли её использовать? или у этого примера есть какие-то явные проблемы, которые я пока не вижу? Миниатюры 0

@XAHOK 273 / 266 / 20 Регистрация: 27.02.2009 Сообщений: 694 Записей в блоге: 7
	05.08.2013, 15:46
	Классическая архитектура на MVC с менеджером ресурсов. Проблемы могут быть только от ее реализации Вами (особенно внимательно нужно подойти к реализации AI части). Если жесткие связи между типами закладывать не будете, то большинства проблем избежите. При желании такая архитектура легко расширяется и для сетевой игры. 1

@VV_RIP 11 / 10 / 1 Регистрация: 05.02.2012 Сообщений: 106
	11.08.2013, 14:11 [ТС]
	Меня смущает только очередь сообщений, не совсем понятно, как в одной очереди могут уживаться сообщения для различных частей программы, ведь выполнение каких-то действий может занять больше времени, если со всем будет возиться один поток(так уже есть и двух и четырех ядерные коммуникаторы). Или лучше несколько очередей? но если их будет обрабатывать несколько потоков, то может получиться так, что один из них выполнит задачу быстрее, и другой поток может уже столкнуться с проблемами ... Как лучше? 0

@XAHOK 273 / 266 / 20 Регистрация: 27.02.2009 Сообщений: 694 Записей в блоге: 7
	11.08.2013, 23:46
	Если вы с асинхронным программированием раньше не сталкивались, то лучше и не заморачивайтесь с многопоточностью. А вообще оцените сначала целевую аудиторию и используемую ими аппаратуру. И затачивайте игру под самый слабый аппарат. Если все таки хотите многопоточный вариант, то посмотрите в сторону синхронизации потоков, а так же на хранение зависимостей между подпрограммами, на основе которых определяется порядок выполнения. 0

@Nomadd 14 / 9 / 0 Регистрация: 12.07.2012 Сообщений: 82
	13.08.2013, 16:50
	А зачем разделять PlayerView и PlayerModel, CreatureView и CreatureModel и т.д.? Ведь проще создать такой класс, который будет обрабатывать и рендер,и игра. 0

@XAHOK 273 / 266 / 20 Регистрация: 27.02.2009 Сообщений: 694 Записей в блоге: 7
	13.08.2013, 18:16
	Почитайте про паттерн MVC. Фактически вы получите три условно независимых подсистемы: модель, представление и контроллер. Особенно это актуально для мультиплатформенных приложений. Если у вас каждый клас будет отвечать за все, то для портирования игры с ведроида на яблоид потребует изменения этих классов и в результате у вас будет два проекта. Поддерживать их актуальность будет весьма геморойно, т.к. любое изменение нужно будет вносить под каждую платформу (например исправления ошибок логики AI и т.п.). Но если вы вынесите рендер в отдельную подсистему (представление) с доступом через интерфейс, то заменить один рендер на другой будет намного легче, а внутренняя логика приложения будет полностью изолирована. Так же такую разделенную систему намного легче покрыть автоматическими тестами. 0

@Nomadd 14 / 9 / 0 Регистрация: 12.07.2012 Сообщений: 82
	13.08.2013, 21:08
	Про паттерн MVC я читал, и даже реализовывал. Но я не делал по 2 класса на один объект. Т.е. я делал базовые классы контроллер, модель и представление. Контроллер вызывал из модели функцию Draw, и в качестве аргумента передавал представление. В функции Draw модель в цикле отрисовывала кубики с текстурами функциями, вызванными из представление. А для создания нового типа объекта(к примеру дерево) нужно было создать один класс. Потом я ещё хотел сделать для каждого типа объекта свою функцию отрисовки, принимающую представлениев качестве аргумента. 0