[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Архитектура браузерной игры
Страницы: 1, 2, 3
n1ko
Добрый вечер, коллеги и товарищи. Написал полный дизайн документ игрушки, команда художников уже прорисовали море графики, а я ломаю голову над архитектурой приложения... Есть много всяких скриптов, алгоритмов, но а вот "движка" нет, который объединит разрозненную логику в один организм.

Кто имел опыт создания крупных игрушек? Перекопал десятка два игр, исходников из сети, и всё мимо, тихий ужас нулевых.

Буду благодарен за любую полезную информацию, статьи, личный опыт, советы. Игра объёмная, рпг. Будут и привычная лавка, пиналка, чат и море других локаций, и персональные для каждой фракции. Хотелось бы изначально продумать и прописать всё максимально грамотно, чтобы при расширении последующем оно не вздулось и не лопнуло :-)
n1ko
Цитата
symfony возьми

Благодарю, рассмотрю обязательно Ваше предложение :-)

А у вас нет ссылок на рабочие проекты на симфони?
Invis1ble
лично у меня ссылок нет, да и зачем они? что ты там надеешься увидеть? php-код и архитектуру по внешнему виду? smile.gif

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

n1ko
Нет конечно, мне не 14 лет, не настолько наивен :-D

Просто посмотреть масштабы проекта. Л - Любопытство.
n1ko
Цитата (Wind @ 24.10.2015 - 19:22)
Разрабатывали на Codeignater

Тоже были мысли такие... Да вот я попытки предпринимал изначально на немного модифицированной архитектуре CI. В итоге я плюнул на это, ибо на первых этапах приложение превратилось в Ж. Но надо подумать и попробовать ещё раз :-)
Invis1ble
ну дык на офсайте есть примеры http://symfony.com/showcase/
или на главной Projects using Symfony

_____________

Профессиональная разработка на заказ

Я на GitHub | второй профиль

Valick
ну кагбе фреймворк и игровой движок это далеко не одно и то же
сразу вам скажу, не надо ориентироваться на то что это браузерная игра, браузерности у неё только клиент, серверу вообще должно быть по барабану с чего к нему подключаются, игровому движку до фени это.
опять же большая часть игры будет написана на SQL, так что фреймворк это дело десятое.

_____________
Стимулятор ~yoomoney - 41001303250491
inpost
n1ko
Фреймворк - то такое. Может сыграть как в плюс, так и в минус. А какой выбрать? Хочешь начать холивар кто круче, Симфони, Зенд, Yii или Ларавел? wink.gif А может вообще самописку ставить? wink.gif

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
n1ko
Цитата (inpost @ 24.10.2015 - 20:54)
Хочешь начать холивар кто круче


О нет, таким я не занимаюсь) Каждый хорош, если к месту и в умелых руках.
Сейчас копаю микрофреймворк Slim. Пока мыслей по поводу оного нет.

Я не выступаю с вопросом, какой ФВ юзать, а интересуюсь именно архитектурой) К примеру изначально я задумал несколько точек входа (для главной, для авторизации, для лавки, арены, и т.д.), сейчас думаю, может быть уместно сделать одну через index и настроить роутинг красивый.

К примеру работа с БД у меня в классе одном статическом, удобно делать запросы одной строкой DB::object('SQL для выборки одной записи в объект') или DB::objectList('SQL для выборки списка объектов'). Это так я и оставил бы, просто и понятно. А вот другие вещи, более глобальные, я не могу утвердить. Располагать ли всё в контроллерах, или прям в файле, дедовским способом?) Вопросов море, потому я и ищу знатоков, кто с геймдевом знаком, а не выпендривается сидит, как часто это бывает на форумах :-)
n1ko
Короче я всегда рад развиваться и исправлять свои ошибки, вот и интересуюсь. Уместна ли MVC в таких вещах, или и с процедуркой можно сжиться?
inpost
n1ko
Одной точки хватит с головой. Ну ты пишешь, что есть готовый код , то и пользуйся им.
Контроллер и есть "файл", на самом деле.

Ты конкретные вопросы задавай, на них и сможем ответить.

Знаешь в чём разница между геймдев и обычным интернет-магазином?! НИКАКОЙ РАЗНИЦЫ, абсолютно никакой в коде.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
inpost
Ты про MVC спросил - никто не мешает разделять на MVC в процедурном стиле. Появляется небольшой перевес в сторону жирных контроллеров, или худых контроллеров, но всё же, MVC остаётся. wink.gif

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
n1ko
Цитата (inpost @ 24.10.2015 - 21:03)
Знаешь в чём разница между геймдев и обычным интернет-магазином?! НИКАКОЙ РАЗНИЦЫ, абсолютно никакой в коде.


Вы правы, да. Думаю стоит меньше заморачиваться и просто начать писать :-)

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

Изначальное видение:

(к примеру) 3 точки входа
- index.php
- player.php
- shop.php

В каждой я подключаю некий init файл, который содержит автолоадер, конфиг подрубает, пути устанавливает различные, подключает файл с классом БД и файл с разными функциями.

Дальше в точке входа я обращаюсь к классу Auth и проверяю, авторизован ли юзверь (чекается сессия, не умерла ли она, не забанен ли уже юзверь и т.п. условия). Если точка входа требует авторизацию, а её нет, то редиректим куда нужно.

Всё, дальше идёт html, инклюдим шапку, боковую панель, а так же отображаем интерфейс этой точки входа. Это простое, ничего не забивает голову. НО! К примеру это shop.php, т.е. мы можем покупать тут что-то. Я думал создать класс определённый с методами, которые будут покупать или продавать шмотку со всей нужной логикой, а так же класс с объектами самих шмоток, ибо не хочу их заносить в БД (экономим лишний раз запросы).

И это лишь первые мысли организации. Есть ли советы какие на этот счёт? Или не нужно никакие классы писать для магазина и писать в этом же файле всё? (при условии, если точки останутся разные)
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.