Ну, тут уже вопрос проекта и даже я б сказал, маркетинговый :). на что "ставить", чем привлекать. И все таки самое главное. Еще пару месяцев назад я вообще ничего не знал о пхп и MySQL :). А задачка чата, ИМХО, как  раз хороша для обучения :) себя

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

чат уже фактически сделан, только без привата. и даже работает. на аяксовой бибилиотеке с  dklab (надеюсь это не реклама? а ссылка на хороший сайт? ). я считаю, что в любом онлайн проекте чат самый первичный :). ибо туда заходят общаться

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

Конструктивный вопрос. новый, но связанный :).Есть таблица сообщений чата. Кто, когда и что отпарвил.Как оптимально организовать приват? С учетом того, что приват будет возможен сразу нескольким игрокам? Группе игроков... 1)Делать отдельное поле "текст", куда запихивать через разделитель логины игроков?2)делать отдельнуь таблицу... хм, тут опять же варианты вроед есть...3)делать в том же поле, где сам текст, со спецразделителями, но тогда проблемочка с редактированием этих полей...Доступных примеров нормальных чатов нету :(

Цитата: "md5" от 30 Август, 2007, 06:07:56 делай временную таблицукоторую потом просто чистьГыыы... в этом и вопрос... была б одна таблица... а тут под каждый бой свою выходит... 100 "табличек " одновременно... а выше меня в хвост и в гриву "отругали" за множество мелких таблиц... хотя некоторые "учебники" рекомендуют все таки большео количество таблиц вместо одной глобальной... буду читать...спасибо всем за идеи/мысли/возражения... а кто нибудь приличный чат на аяксе делал? если не секрет то хотелось бы тоже по поводу структуры таблиц поспрашать... некоторые вопросики... а то переделывать в будущем не хочется... велосипед изобретать нет желания, только я так понял - это "секретная" информация... :)

Цитата: "vasa_c" от 30 Август, 2007, 06:08:35 ЦитироватьУ игроков 2, 3, 4, 5,6 происходит периодический запрос, который разворачивает массив, смотрит, нет ли изменений, отсылает новое положение для отображения...Да, именно так и делается. И какие проблемы?по времени проигрыш...  ведь сериализация и ансериализация будет производится после каждого хода и не одна... а всем игрокам... оченн не удобно ИМХО... причем в "клеточке" хранится не просто число или строка, а... объект практически... здоровье типа, наложенное заклинание и иные модификаторы юнита... помимо его айди...

Сериализация не катит... думал уже... массив же динамический... существует только в данный момент.. он мне через час не нужен :) да и через минуту после окончания боя...Выходит а то, что получен ход игрока1. разворачиваем массив, изменяем, сворачиваем, запоминаем.У игроков 2, 3, 4, 5,6 происходит периодический запрос, который разворачивает массив, смотрит, нет ли изменений, отсылает новое положение для отображения... как то кривовато... по идее, для нормальных, а не онлайн игрушек такой массив хранится в памяти, а потом просто зануляется и все :)...

1)Бой происходит в виде передвижения юнитов по клеточкам. типа шахмат.2)Т.е. когда два игрока "входят" в бой формируется массив клеточек, в каждой из которых может находится юнит или пусто.3)массив этот динамический - изменяется после каждого "хода".4)доступ к этому массиву должен быть у нескольких игроков, чтобы отображать им текущую ситуацию5)как хранить это массив?

Ну тут согласен. Логи все таки сразу в файлы... тут уж точно каждый бой в один файл. А начальное расположение и текущее состояние массива юнитов, точнее массив территории, где ходят юниты. Т.е. в клетке 11 стоит юнит такой-то, в клетке 12 никого нету... Т.е. тот массив, который отображается у игроков и соответственно меняется при команде одного из игроков типа сходить таким-то юнитом туда-то...

Не, я не считаю, что для каждого элемента должна быть своя табличкая. именно в данном случае казалось что так оптимальнее... но вроде как отговорили :) в принципе... табличка не будет сильно динамичная, меняется редко, так что... согласен, что с одной гораздо удобнее...Но тогда в продолжение темы... вопрос про бой... что посоветуете? В момент начала боя формируется массив предположим 10на10 клеток, для простоты они либо пустые, либо ссылка (хм, тогда точно нужна одна большая табличка с индивидуальными айди) на юниты игроков, которые в процессе боя перемещаются, погибают... т.е. нужно хранить этот массив объектов. После окончания боя массив в принципе не нужен, удаляется. разве только ходы запсиатьв отдельны файл. но это уже из другой оперы... (из другого эксплорера=))как построить таблицы в этмо случае? предположим одновременно может происходить до 100 боев... опять же (пусть я новичок) логично напрашивается структура вида:таблица1айди_боя, оппонент1, оппонент2, оппонет3 (т.е. кто в этом бою)таблица boj+айди_бояклетка11 айди_юнита, здоровье в текущем бою, модификаторы в текущем бою...клетка12клетка13но опять же получаются динамически генерящиеся таблицы, которые меня смущают... а еще ведь ходы надо запоминать, чтоб была возможность потом запомнить в файл...делать опять же через одну табличку дял всех боев?айди_боя, клетка11....айди_боя, клетка12...и т.д.ага, вспомнил, чем мне не нравится одна таблица... блокировками... в случае множества мелких, каждый "боец" работает со своей, а тут сотня (хм, а ведь не много)....

Цитата: "cage" от 30 Август, 2007, 03:41:28 сделай таблицу состояний,первая колонка айди юзера,вторая айди вещи,3я износ,четвертая цена по которой ее приобрел юзер и т.д. и т.п.Вот вопрос про это изначально и идет... ведь в этом случае: занимается "лишнее" место на повторение айди юзера, хранятся вещи по одному юзеру не подряд(хотя... это проблемой быть не должно выборке пофигу :) )но возникла идея сэкономить место на индексы и на саму табличку... сделать несколько маленьких, но что-то смущает в этом...

1)Сорри за невольную рекламу. Хотел взять название в кавычки, как имя нарицательное... ну а так даже лучше :). (А ничего, что я как бы свой проект "рекламирую", хотя он еще и не сделан...)ничего=)2)Для тех, кто в танке (без обид). Я не собираюсь хранить ВСЕ в одной табличке. Есстественно одна таблица для пользователей. ЕЩЕ одна для базовых свойств вещи. Вопрос конкретный, как удобнее (оптимальнее) хранить наборы вещей конкретного пользователя, с учетом того, что эти вещи будут уметь индивидуальные характеристики, которые определяются по ДВУМ ключам: по ид игрока и по ид вещи. Т.е. броня у игрока1 может иметь износ 20, а у игрока 2 такая же броня, но уже износилась на 30 пунктов. Более конкретный вопрос, чем чревато на практике хранить данные в большой куче (10000) маленьких табличек.ПС Как раз сейчас и занимаюсь тем, что пытаюсь сначала на листочке смоделировать структуру.ПСС Нуп я... пхп изучаю меньше месяца... чат для проекта сделал, а вот дальше уперся в правильную структуру таблиц, чтоб потом не переделывать...ПССС На самом деле проект задумывается для... думающих игроков, т.е. "бой" будет не тупым расставлением точек, но это уже могут и правда рекламой определить... просто маячит еще один "философский" вопрос: как оптимально хранить таблицу боя и ходов? Массив клеток, с юнитами и что они делали.. опять же... или под каждый бой делать отдельную табличку, а потом ее уничтожать (сохранив к прмиеру) или одну большую и чистить периодически...Так все таки ОДНА таблицка (ну или две, три) большая или много-много маленьких...

Типичный, ну к примеру рассмотрим ХХ, проект. Т.е. вещи конечно же делятся по "виду", но могут иметь отличия, в частности, износ ЭТОЙ конкретной вещи.Т.е. Игрок1, у него есть Броня Шикарная (есстественно тут имеется табличка с базовыми свойствами данной брони, вещей). Про параметры пользователя речь НЕ ИДЕТ!!!! просьба не "захламлять" вопрос подвопросами :).Есть таблица пользователей вида: ид_игрока, логин, пассворд.Есть таблица вещей вида: ид_вещи, параметр1, параметр2...Вопрос создать третью ОДНУ таблицу, где будут пересекаться ид_игрока, ид_вещи и индивидуальные параметры ВЕЩИ типа износа (т.е. износилась данная броня на 20 пунктов).Решение 1:ид_игрока, ид_вещи, износ, уведичение параметра1... и т.п. (возможно ид_вещи конкретной, этой)Решение 2:таблица с именем vesh+ид_игрокаид_вещи, износ, увеличение параметра1  и тп Давайте не будем рекламировать проекты,не будем упоминать названия,здесь не рекламное агентство

Ну, предположим, игровой проект. Есть пользователь игрок, со своими параметрами типа ловкостей и удачи всяких. И у него есть... вещи, которые имеют свой износ к примеру и иные \"модификаторы\". И вещей будет от 30 до 100 ориентировочно. Так вот и думаю, как же оптимальнее... либо каждому пользователю свою табличку, но тогда будет 10К табличек по 100 строк каждая или одну с 1000К строк, в каждой из которых \"лишнее\" поле ид_игрока. Вроде бы оптимальнее много табличек, но я на практике с таким не сталкивался, вот и озадачился заранее :) не будет ли с этим проблем. Опять же... вещи эти могут переходить от одного игрока к другому и вроде бы нужен уникальный ид_вещи... или необязателен...