Дневник создания рокалика.
Модератор: Jolly Roger
Дневник создания рокалика.
Решил создать свою игрушку.
Поскольку времени свободного не ахти, буду просто писать сюда мысли.
А потом реализовывать.
Поскольку времени свободного не ахти, буду просто писать сюда мысли.
А потом реализовывать.
пятница 10.10.2008.
1) Язык на котором буду писать вероятнее всего C#.
Причины просты. 5 лет писания на дельфях и 1,5 года на си.
В си шарпе как рыба в воде, чувствую себя комфортно.
2) Пока первая задача сформулировать принципиальную схему движка. По возможности сделать это как можно более общо, дабы потом было можно сдлеать очень многое.
1) Язык на котором буду писать вероятнее всего C#.
Причины просты. 5 лет писания на дельфях и 1,5 года на си.
В си шарпе как рыба в воде, чувствую себя комфортно.
2) Пока первая задача сформулировать принципиальную схему движка. По возможности сделать это как можно более общо, дабы потом было можно сдлеать очень многое.
Итак наверное я изобретаю велосипед, но чутье подсказывает мне что я это делаю правильно.
1-е. Схема движка проста как три копейки.
получаем то что хочет сделать пользователь (под словом сделать я понимаю действия которые изменят игровой мир, сделать шаг, порыться в инвентаре, кастануть заклинание, и т.п.) формируем так называемый вектор изменения мира.)
Далее получаем действия которые хочет сделать ИИ. (под ИИ понимаются не только монстры но и различные летящие предметы, горящие факелы, текущая вода.) Формируем опять таки вектор.
Далее загоняем матрицу векторов изменения мира, вместе с матрицей текущего состояния в обработчик(я его называю процессор, так както солиднее звучит), там естессно с учетом приоритетов вычисляются и обрабатываются события, на выходе из "процессора" мы получаем новуюматрицу состояния мира.
Далее вся эта красота копируется в блок фильтра (игрок далеко не все о мире должен знать) на выходе мы получаем исключительно ту информацию которую можно и нужно предоставить игроку, а уже эту инфу скидываем в блок визуализации.
В идеальном случае "процессор" должен разрешить деллемы кто что успел сделать, и соответственно определить кто прав.
Рассмотрим случай когда в одну клетку шагнули игрок и монстр. Но у игрока скорость допустим больше чем у монстра.Тут следует маленькое упрощение. Действие считается завершенным если время на него отведенное кончилось. Если время которое нужно игроку для перехода в эту клетку истекло раньше чем у монстра, то игрок попадает в эту клетку, в то время как монстру приходит сообщение о провале действия.
При подсчете в "процессоре" эталонным временем считается время затрачиваемое игроком на действие.
Когда какой либо объект начинает действовать к нему привязывается счетчик с обратным отсчетом, когда счетчик истекает то действие считается совершенным.
1-е. Схема движка проста как три копейки.
получаем то что хочет сделать пользователь (под словом сделать я понимаю действия которые изменят игровой мир, сделать шаг, порыться в инвентаре, кастануть заклинание, и т.п.) формируем так называемый вектор изменения мира.)
Далее получаем действия которые хочет сделать ИИ. (под ИИ понимаются не только монстры но и различные летящие предметы, горящие факелы, текущая вода.) Формируем опять таки вектор.
Далее загоняем матрицу векторов изменения мира, вместе с матрицей текущего состояния в обработчик(я его называю процессор, так както солиднее звучит), там естессно с учетом приоритетов вычисляются и обрабатываются события, на выходе из "процессора" мы получаем новуюматрицу состояния мира.
Далее вся эта красота копируется в блок фильтра (игрок далеко не все о мире должен знать) на выходе мы получаем исключительно ту информацию которую можно и нужно предоставить игроку, а уже эту инфу скидываем в блок визуализации.
В идеальном случае "процессор" должен разрешить деллемы кто что успел сделать, и соответственно определить кто прав.
Рассмотрим случай когда в одну клетку шагнули игрок и монстр. Но у игрока скорость допустим больше чем у монстра.Тут следует маленькое упрощение. Действие считается завершенным если время на него отведенное кончилось. Если время которое нужно игроку для перехода в эту клетку истекло раньше чем у монстра, то игрок попадает в эту клетку, в то время как монстру приходит сообщение о провале действия.
При подсчете в "процессоре" эталонным временем считается время затрачиваемое игроком на действие.
Когда какой либо объект начинает действовать к нему привязывается счетчик с обратным отсчетом, когда счетчик истекает то действие считается совершенным.
чтобы писать нужно время.
А чтобы это время сэкономить нужно заранее спланировать все алгоритмы, все продумать и привести все в то состояние когда нужно всеголишь набить парочку функций.
Покарйней мере в нашей компании проектирование и исполнение делается примерно по такой схеме.
Проектирование самая важная часть написания любого софта и она отнимает наибольшее количество времени.
-------------------------------
по делу.
действие кастуемое на клетку действует на все чот на ней находится.
соответственно заклинание кастуемое на монстра кастуется на все что на нем находится и т.п.
При скастовывании фаерболов, стрелянии стрел, и т.п. создается объект снаряд, с повторяющимся действием движение в указанном направлении, со своей собственной указанной скоростью. тогда снаряды тоже впишутся в объектную модель мира.
магический огонь, льющаяся вода, ветер тоже объекты.
для все объектов предусмотренна реакция с другими объектами (это будет двумерная таблица). Некоторые никак не буду реагировать друг с другом. некоторые будут нейтрализовывать друг друга, или даже будут действовать однонаправленно (если водой полить огонь он потухнет, а если огнем поджигать воду то она скорее всего никак на это не отреагирует).
Сочетание двух объектов может порождать третий. (вода плюс соль = соленная вода)
при складывании объектов важним методом является оператор сложения, им является действие которым собираются соединять два объекта. При выборе оператора (действия) которое тоже есть объект, происходит преобразование операнда (вода плюс полить = полить водой) далее суммирует этот объект со вторым операндом (полить водой + шапка=мокрая шапка)
А чтобы это время сэкономить нужно заранее спланировать все алгоритмы, все продумать и привести все в то состояние когда нужно всеголишь набить парочку функций.
Покарйней мере в нашей компании проектирование и исполнение делается примерно по такой схеме.
Проектирование самая важная часть написания любого софта и она отнимает наибольшее количество времени.
-------------------------------
по делу.
действие кастуемое на клетку действует на все чот на ней находится.
соответственно заклинание кастуемое на монстра кастуется на все что на нем находится и т.п.
При скастовывании фаерболов, стрелянии стрел, и т.п. создается объект снаряд, с повторяющимся действием движение в указанном направлении, со своей собственной указанной скоростью. тогда снаряды тоже впишутся в объектную модель мира.
магический огонь, льющаяся вода, ветер тоже объекты.
для все объектов предусмотренна реакция с другими объектами (это будет двумерная таблица). Некоторые никак не буду реагировать друг с другом. некоторые будут нейтрализовывать друг друга, или даже будут действовать однонаправленно (если водой полить огонь он потухнет, а если огнем поджигать воду то она скорее всего никак на это не отреагирует).
Сочетание двух объектов может порождать третий. (вода плюс соль = соленная вода)
при складывании объектов важним методом является оператор сложения, им является действие которым собираются соединять два объекта. При выборе оператора (действия) которое тоже есть объект, происходит преобразование операнда (вода плюс полить = полить водой) далее суммирует этот объект со вторым операндом (полить водой + шапка=мокрая шапка)
- reincarnation
- Сообщения: 33
- Зарегистрирован: 25 ноя 2006, 22:24
- Откуда: Москва
Во-во, проектирование это хорошо но на нем не нужно зацикливаться.Ага, у нас уже штук 20 описаний артефактов есть, набросок сюжета...2 года периодически пытаемся что-то сделать.
Я бы начал проектирование с определения игровых объектов (да и вообще с терминологии и это не шутка, у вас сложно понять что значит например вектор развития мира), примерно так:
объект - это сущность описанная какими-либо свойствами и обладающая рядом действий которые может совершить или которые могут быть совершены на ней.
В игре есть следующие объекты: одна клетка, существо, декорация и т.д. Затем описываются их свойства, затем их возможные действия, затем действия над ними и т.д.
А уж только потом действия игрока и реакцию на эти действия движка. Хотя советовать ничего не буду может вам так легче и проще.
И удачи вам.
Мудрая мысль.
Даем описания.
объект - некоторая сущность имеющая свой собственный уникальный идентификатор. Больше никакой информации объекту нет смысла хранить.
Имеется так называемая модель. Модель указывает на объект, плюс хранит в себе всю необходимую информацию. (цвет, размер толщину и т.п.) Каждая модель представляет собой односвязанный список.
причина по которой я разделил модель и объект проста. Может быть 300 стрел, объект в принципе один а вот их содержимое разное, одна летящая другая лежащая и т.п. (хотя тут стоит подумать по крепче).
Под вектором я понимаю: "заявка на действие"
Поскольку любое действие изменяет состояние объектов(а) которые(й) является неотъемлемой частью мира, то называется этот вектор вектором изменения мира.
Вектор:
1) хранит указатель на объект инициализировавший его,
2) на объект к которому он применяется,
3) идентификатор оператора,
4) указатель на данные которые будут участвовать в реакции.
5) счетчик обратного отсчета.
Чтобы не было никаких глюков, используется не указатель на модель объекта, но делается копия только существенных для этого действия данных.
(пока все)
Даем описания.
объект - некоторая сущность имеющая свой собственный уникальный идентификатор. Больше никакой информации объекту нет смысла хранить.
Имеется так называемая модель. Модель указывает на объект, плюс хранит в себе всю необходимую информацию. (цвет, размер толщину и т.п.) Каждая модель представляет собой односвязанный список.
причина по которой я разделил модель и объект проста. Может быть 300 стрел, объект в принципе один а вот их содержимое разное, одна летящая другая лежащая и т.п. (хотя тут стоит подумать по крепче).
Под вектором я понимаю: "заявка на действие"
Поскольку любое действие изменяет состояние объектов(а) которые(й) является неотъемлемой частью мира, то называется этот вектор вектором изменения мира.
Вектор:
1) хранит указатель на объект инициализировавший его,
2) на объект к которому он применяется,
3) идентификатор оператора,
4) указатель на данные которые будут участвовать в реакции.
5) счетчик обратного отсчета.
Чтобы не было никаких глюков, используется не указатель на модель объекта, но делается копия только существенных для этого действия данных.
(пока все)
Re: Дневник создания рокалика.
Как продвигается?
- Максим Кич
- Администратор
- Сообщения: 1642
- Зарегистрирован: 03 дек 2006, 20:17
- Откуда: Витебск, Беларусь
- Контактная информация:
Re: Дневник создания рокалика.
Ты всех вкругорядь обходишь? Я тебе и так могу ответить по каждому случаю: неважно продвигается.Anfeir писал(а):Как продвигается?
Dump the screen? [y/n]
- Maelstrom
- Мастер
- Сообщения: 2062
- Зарегистрирован: 26 ноя 2006, 14:19
- Откуда: г. Усть-Кирдык
- Контактная информация:
Re: Дневник создания рокалика.
Дайте Анфейру уже право выкидывать темы в компост, чтобы он успокоился
Айв кнгенгах Йог-Сотот
Re: Дневник создания рокалика.
Нене, вдруг кто очнется и вспомнит, что у него рогалик есть в планах.
- Харука-тян
- Мастер
- Сообщения: 544
- Зарегистрирован: 29 ноя 2006, 00:23
- Контактная информация:
Re: Дневник создания рокалика.
А меня растолкать?.. Вдруг я тоже "забыла" про свою выпечку?Anfeir писал(а):Нене, вдруг кто очнется и вспомнит, что у него рогалик есть в планах.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 48 гостей