Здравствуйте всем.
Подскажите что необходимо для реализации задумки ОнЛайн Браузерки.

Задача такова:
1. Персонаж с набором характеристик, набором предметов.
2. Выбор-Перемещение на Локации кликом по мини карте (отображаются доступные из ближнего окружения).
3. Возможность менять статус Прохода на локацию "Проход возможен" "Проход НЕ возможен"(Завалить проход, закрыть дверь, заваРить проход...).
4. Комнаты за кодовыми замками...
5. возможность проникать в помещения при наличии определённых предметов (ключь, кувалда)...
6. Вес Предметов...
7. скорость передвижения перса меняется от веса инвентаря.
8. возможности понижаются при ранениях.
9. возможность после смерти одного перса иметь возможность другим пресом найти его тело и перенести в другое место, либо подобрать предметы...
10. Успешность поиска предметов на локации по вероятностям в зависимости от определённых характеристик перса - Зрение, слух, приборы, имплантанты и т.д., а так же от освещенности самого помещения и проч...
11. Разные виды защиты и оружия,  одно и тоже оружие по разной защите несёт разное повреждение... 
12. Бои проводятся (скорее всего) по вероятностям... т.е. при таком-то навыке - шанс удачной атаки 20% - при таком-то 50... Критическая атака и т.д. ...
13. Возможность маскировки на локации (Засады например, сна...) ухода в тень так же навык маскировки в баллах ит.д. ...
14. имитация звука перемещения и возможность по звуку определять присутствие другого на локации, ближайших локациях... например стоит - нет звука, идёт звук 20 клеток, бежит 80 и т.д. (клеток - условно)
15. определённое перемещение занимает определённое колл-во времени...
16. необходимость Питания перса... Отдыха... Заканчивающиеся батарейки...
17. возможность общения персонажей меж собой при нахождении на одной локации... (шепчет, говорит, кричит - разные люди могут могут слышать в зависимости от их собственных способностей и расстояния) при наличии рации общение на расстоянии - вид рации определяет дальность...
18. Постановка жучков прослушки на локациях (Жучок есть - пишем лог разговоров)...
19. 2-3 рассы...
20. Желательно что-бы если кто-то дверь замкнул, при приходе друго игрока она была бы закрыта... Т.е. единый Мир для всех...
21. Бестиарий. (бродячий и По локациям)

Игра не 2D, ни 3D.  Затрудняюсь точно определить...
Интерфейс таков: картинка локации - сугубо для атмосферы...
-- список выбора возможных действий на даной локации...
-- список статуса перса (сесть, встать, уйти в тень, одеть - то, снять - это, искать, открыть шкаф № такой-то и т.д.)

Если знаете игру "Ботва" - конечно к этому проекту она никакого отношения не имеет, но прнципы построения схожие - это единственное что я нашел, что бы обьяснить подход к построению интерфейса...

Так вот возможно ли что-то подобное реализовать "малой кровью"...
HTML, CSS, JAVA, PHP... Базы Данных.
С чего начать?
Мой Уровень - это пара сайтиков (localhost) на Html-Css, пара на Joomla и DLE (разковырял по ним Принципы работы PHP), Основы JAVA - но слабовато, пока...
Базы Данных - Пока вообще не сталкивался кроме как создать ее через Денвер и прикрутить к Сайту Джумлы...
Но Обучаем...
Photoshop - нормально.

В игре никаких Видео Наворотов - похоже сугубая работа с Базой Данных и Арреями Персонажей и Локаций... Суть в воображении Игроков и Максимального обьёма Реальстичности окружающей среды - разрушения - перемещение - взаимодействия игроков и т.д.

не знаю возможно ли весь мир в Базы Данных запихнуть со всеми дверями, их состояниями, предметами...

И мультиплеер - как это вообще..? Хотя если единые базы данных на сервере...

Искал по интерету про браузерки крайне мало... здесь на форуме как-то тоже... 2-3 поста и всё... Жаже не представляю с чего начать...
Денвер и Апачи стоят... А дальше... З-з-з-з-з-з -- Звенящая Тишина... 

Фу-ту..! вроде в общих чертах... Что посоветуете...

Это сообщение отредактировал(а) grimripper8698 - 5.12.2009, 01:38

Все с одной стороны легко, а с другой стороны плохо...

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

надо научиться ими манипулировать.

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

сначало потренеруйтесь писать системы управления на PHP и при этом как работать с файлами. вторая часть того что вам понадобиться это средние знания javascipt.

для начала хватит  

[email protected] спрашивайте

Благодарю.

"системы управления на PHP и при этом как работать с файлами"

Для начала уже что-то!
Посоветуй Какую Хорошую книгу. Или любую брать по PHP?


нашел что-то по он лайн играм: (не так много в интернете по этой теме)
Создание Игровых скриптов

Это сообщение отредактировал(а) grimripper8698 - 4.12.2009, 21:29

книги... если честно уже не помню с чего начинал... 

советую посмотреть книги типа: PHP5 для чайника и прочее.
делайте задания по книгам, пробуйте что-то придумать и т.д.
работайте пока не поймете саму суть работы.

на мой взгляд лучше учить сразу PHP5, он более удобный. 
Я своим студентам преподаю именно PHP5.

Ваша ссылка очень хороший пример.

Это Совет уже от меня - тем новичкам, кто, возможно, будет просматривать эту ветку форума...

ДЛЯ НАЧАЛА, Берите Американские учебники для изучения ЛЮБЫХ языков программирования и вообще всего что касается компьютеров!

Русские не могут псАть такие вещи - у них сразу математика и Сразу вся информация по Синтаксису в кучу и ДВОЙНОЕ ОТРИЦАНИЕ ОТРИЦАНИЯ! (не успел рассказать про "Операторы" уже говорит как оптимизировать код - мол это не изящно..!).

У Америкосов расчёт на полных "Dummies" и ПЛАВНАЯ ПОДВОДКА, так что еще что-то разобрать возможно...

-----------------------------
Как вам: "Сдвиг вправо битового представления значения левого целочисленного операнда на количество разрядов, равное значению правого целочисленного операнда"?

Это еще как-то можно было-бы понять, если-бы не последовавшее за этим "Пояснение":

"Двоичный код для 4 равен 100, при сдвиге влево на 2 разряда код 100 становится равным 10000, что соответствует десятичному значению 16."

Спасибо что объяснил... :)
-----------------------------

Образности не хватает... Может когда-нибудь компы заработают на Русском языке...

Это сообщение отредактировал(а) grimripper8698 - 5.12.2009, 01:02

Кошек нужно уметь готовить, а  базу данных нужно уметь проектировать.  В грамотных руках БД будет куда предпочтительней файлов.

Так же надо понимать что в тяжелом проекте главное не скорость а масштабируемость.

В "Грамотных" - наверняка...

Для меня сейчас главное понять принцип: ЧТО, КУДА и КАК подключается, как Описывается... Выяснить-Написать, так сказать, МИНИМАЛЬНЫЙ НАБОР ФАЙЛОВ для первых Реакций Странички на Пользователя и Первых Её самостоятельных Вычислений...

Понимаю так: Сейчас буду УЧИТЬСЯ создавать Систему (Взаимодействия и Вычисления на странице)
Например:
1. Создать Страничку с картинками ЧАРА и его характеристиками.
2. Создать Массив с переменными для ЧАРА.
3. Предмет в инвентаре и возможность Снять и Одеть его. с Изменением параметров ЧАРА.


Когда система заработает - подумаем где именно хранить данные.
в Файлах или БД... (к стати БД - это Бинарные файлы или тот же текст?)
Честно говоря не особо тянет учить еще и My SQL какой-нибудь...
Хоть бы с PHP разобраться на начальном этапе...
Так что пока, видно, Дата в Файлах будет...

Это сообщение отредактировал(а) grimripper8698 - 5.12.2009, 02:34

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

Работа с файлами при любом стичение обстоятельств происходит быстрей. 

Да возможно вынос БД на другой сервер (с заточкой его под нужды БД) в какой-то степени компенсирует показатели скорости.

Не стоит складывать все яйца в одну корзину. 
БД используется на маштабируемых проектах, и маштабируемость здесь не в количестве человек а в гибкости фильтрации данных и манипуляций над данными.
Как пример если MOSS2007 (Microsoft SharePoint 2007) работает на 3 серверах (БД, ВебСервер, основной сервер) и даже в этом случае мы отключим хранение прикрепленных файлов в БД, мы получим прирост производительности в 20-30%. Но в данном случае затрудняется разработка необходимых модулей для манипуляции с данными.

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

не использовать БД в играх тоже некая глупость, на БД пишется тажа авторизация, справочники (список кланов и прочая подобная весч).

Если использовать БД в бою то процессов чтения запись будет бешенное количество (использование маштабных битв при участие хотя бы 20 участников с разными примочками) более 100. При этом будет подвисать вся игра. 

Все это проверить можно простым методом загоните и считайте один и тот же объем (с учетом что размер приличный) из файла и БД.

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

Добавлено через 4 минуты и 30 секунд

есть специальный курс создания браузерных игр  стоит не дорого 2560 р. там все это дело разжевывается. 

Единсвенный минус его самопальность. Тоесть есть некоторые ошибки в написание кода, приходиться доделывать напильником. 
НО в целом закладываются идеи туда здравые. И прочитав его вы поймете этапы создания и что в каком порядке идет. По прохождению курса вы чуток и разберетесь в БД и научитесь читать код.
Здесь все написано на БД.

http://www.blitz-school.info/

Добавлено через 9 минут и 41 секунду

если хотите чтобы программировать на русском языке то попробуйте себя в 1с.

По поводу книг... А вы какие брали, я даже ради интереса нашел свои книги по программированию на C#,C++,ASP.NET,PHP и если их разложить по принципу 
Чайник, Проф, СПЕЦ, то в чайнике разжевывается все очень подробно. Перечисленные заморочки я даже е встретил в серии книг ПРОФ. 

При этом мне кажется, что вы пропустили первые главы где все эти вещи объясняются, там кратко но есть.

Да не в Русском языке дело (На английском я Гворю, Думаю и Иногда вижу сны. Java например вообще изучал только на Английском... напрягов не было. Мне вообще нет разницы что писать "Else" или "В Противном Случае" - Английский тут Объективно даже удобней) -  в логике того как Машине объясняется необходимое к выполнению...

Но тут мы уйдем в философию и филологию, Не хотелось бы... Больная тема для меня... Имею Обширный опыт общения с многими НЕ Русскоязычными Жителями Планеты... Уже сложилось устойчивое убеждение в ИСКУССТВЕННОСТИ СОЗДАНИЯ Германской и Романкой групп Языков... На этой же логике построено и программирование... Удаляем гланды через Жопу... Не чувствуете ГРАМОЗДКОСТИ Любого Кодинга..? И не спрашивайте чем заменить... Не про то... За неимением лучшего пользуемся тем что есть и не Жужжим... :) Однако я не показатель... Для меня вообще математика попахивает Шизофренией... Возьмите хотя-бы отрицательные Числа..!



Это уже видел. В интернете Принципиально Ни За Что не плачу...
Информация БеЗ-платна! Найду за "так" Гляну Обязательно...


Это так, Общее впечатление... Конечно я не думаю что Наши писАть не умеют... Наверно кто-то и для новичков что-то написал... И наверно - понятным языком. 

Дело в том, что в Массе своей при Первичной подаче Алгоритма, во-первых дается только Математическое обоснование его применения, чуждое за частую "Нормальному" человеку... А во-вторых сразу же переход на Альтернативный вид написания кода - который Проф. Программеры уже изобрели для себя - Шорт-кат скажем так... И весь дальнейший код уже с этими шорт-катами; от осмысления которых мозги закипают через пол часа работы... У амрикосов - хотя-бы даётся вариант Практического применения Описываемого Алгоритма...

А НЕ что-то вроде этого...
-----------------------------
Эта группа операторов работает с битовыми представлениями значений целочисленных операндов. В основном эти операторы применяются для создания набора булевых флагов.
Это Описание или Выебон?
-----------------------------
Я конечно Утрирую, но только для наглядности...

Проблема в том что я не математик... и математическая логика мне не приятна для мышления - Чужеродна...
Так же как и Английский  язык - Противен (хотя им Владею в совершенстве (и еще о паре языков имею представление))...
Никого не имел намерения "задеть" своими высказываниями - понимаю что среди программистов много людей "математического склада ума"...
Лишь пытаюсь объяснит своё понимание... Что б не подумали что плачусь на "Плохих Дядек", что не умеют писать понятные книжки... :)

Но это я опять раЗтекаюсь мыслями по дереву - моя Болезнь...
Больше Никакой Философии с моей стороны. Только Конкретные Вопросы по Предмету.


Это сообщение отредактировал(а) grimripper8698 - 5.12.2009, 14:16

Это вы ребятам из Oracle скажите   


Так уж и при любом   

Хотел бы у Вас спросить - как вы предлагаете реализовать на файлах базу данный всех зарегистрированных пользователей. И как вы собираетесь хранить информацию об их уровне, и локациях, где они находятся. И как вы сделали бы выборку всех пользователей находящихся в определенной локации при этом показав их уровень, да еще и отсортировав по уровню? 




Вы предлагаете это реализовывать на файлах? Т.е. постоянные обращения к дисковой системе? 

Я бы состояние боя хранил в памяти, раз в ход скидывая все данные в базу (только INSERT) для дальнейшей статистики. 




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

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

оракловые команды (которых на изучение можно потратить более 80 лет) предназначены для фильтрации данных, и половина команд необходимы для совместного чтения, записи в разных БД и таблицах и всякой такой мути, просто под разными углами. 

Если мне этого не надо, то зачем использовать? Забивать микроскопом гвозди? о нет...

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

А кто Вам сказал что обращение к большому количеству файлов при бое? когда создается бой, то все игроки с их массивами пишутся в один файл, один бой, один файл. И этот файл выгружается в MEMCASH. 
Выгрузка массива и выгрузка целой таблицы (вы же на бой отдельной таблицы создавать не будете или сколько будет тратиться времени на выборку из такой таблицы через год?) большая разница. Файл будет весить мегабайт 5 это при супер-пупер битве. 
И не забывайте, что дисковый массив это не объязательно харды  порой достаточно из оперативки сделать раздел харда, где и будут храниться данные. Зашел пользователь, загрузил его файл в нужных раздел (который работает на оперативе). 
Базу увы, вы всю не вставите в оперативку, места не хватит.
 

Archusha, 

То что Вы сейчас описываете - называется "порнография".  Вы пытаетесь обходить трудности, которые сами же себе создаете выбором неправильных технологий.



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

 

А я не говорил про топ игроков, а про сортировку игроков находящихся в локации.




memcash  для этого не предназначен - он не гарантирует сохранности данных.



  


А не проще ли использовать технологии предназначенные для создания высоконагруженных приложений, чем так извращаться? 

Информация то может и бесплатна, а труд тех кто ее готовил - вполне платен.


Чего вдруг? Вполне нормальным явлением считается сервер с оперативкой достаточной для помещения туда БД полностью.

Vasay - и снова о том же... 
мы говорим о разных вещах. Да если это удобно можно использовать БД для логирования (об этом я писал выше). 

про игроков в локаци, у вас есть файл локации в нем храните массив игроков данной локации, вышел затер себя, зашел вписал.

Не все файлы требуют сохранности - это раз. 
Не кто не мешает делать переодическую запись этих файлов на хард (сохранения их состояния) - это два.

а по поводу высоконагрузочных технологий, вы уверены что они не делают тоже самое? 

Simpliest - и согласен и не согласен. Есть потолки оперативки, с хардами попроще... да если база весит пару гигов, то можно ее в оперативку, а если 40-50?

Archusha, 



Почему вы так уверены, что все DB тормозные? Не потому ли, что стандартные средства php для общения с DB способны уложить на лопатки любой движок баз данных? (правда, я слышал, что вопрос решаемый)

Почему вам все время хочется куда-то сохранять оперативные данные? Не потому ли что php не позволяет держать их в памяти?  


п.с. При правильном проектировании DB реально быстры и созданная средствами php файловая база данных будет медленнее, ощутимо медленнее.