jarg

Форум для проектов, находящихся на стадии Альфа и Бета. В них ещё не реализована вся задуманная автором функциональность, а значит идёт активная разработка.

Модераторы: Sanja, Максим Кич

Аватара пользователя
ishellstrike
Сообщения: 37
Зарегистрирован: 21 авг 2013, 21:50
Откуда: Москва

jarg

Сообщение ishellstrike » 21 авг 2013, 21:55

just another roguelike game
Дата начала работы: апрель 24, 2013
Дата релиза: не известна
Способ распространения: Free software
Открытый репозиторий: https://github.com/ishellstrike/sge
Язык разработки C++, squirrel

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


Проект - выживач с зомби и прочей нечистью c развитой системой крафта и прокачки персонажа.

Проект постигло уже как минимум 2 полных переписывания (изначально был на C#, затем на Qt) что связано с изменением моих личных предпочтений за 3 года вялой разработки.

Возможно тут скоро будут скриншоты.

Идейным вдохновителем послужил Cataclysm, на него, вероятно, игра и будет похожа
Всем постапокалипсис.
Последний раз редактировалось ishellstrike 01 фев 2016, 13:29, всего редактировалось 28 раз.

Siri0n
Сообщения: 31
Зарегистрирован: 19 авг 2013, 10:31

Re: jarg

Сообщение Siri0n » 22 авг 2013, 10:15

Здорово. А потыкать можно?

Аватара пользователя
ishellstrike
Сообщения: 37
Зарегистрирован: 21 авг 2013, 21:50
Откуда: Москва

Re: jarg

Сообщение ishellstrike » 23 авг 2013, 10:00

Siri0n писал(а):Здорово. А потыкать можно?
Конечно, на гитхабе периодически буду выкладывать скомпилированную версию (там вкладка releases)

Аватара пользователя
Foxman
Сообщения: 243
Зарегистрирован: 19 янв 2012, 20:30

Re: jarg

Сообщение Foxman » 24 авг 2013, 06:44

Если интересно, можешь посмотреть исходники Бусикатора, тоже но OpenTK, исходники открыты. Все что касается OpenTK вынесенно в отдельную сборку
http://rlgclub.ru/forum/viewtopic.php?f=25&t=734

Аватара пользователя
ishellstrike
Сообщения: 37
Зарегистрирован: 21 авг 2013, 21:50
Откуда: Москва

Re: jarg

Сообщение ishellstrike » 25 авг 2013, 20:50

Foxman писал(а):Если интересно, можешь посмотреть исходники Бусикатора, тоже но OpenTK, исходники открыты. Все что касается OpenTK вынесенно в отдельную сборку
http://rlgclub.ru/forum/viewtopic.php?f=25&t=734
У меня в общем пока не возникает проблем по технической части, если у тебя в проекте что-то в этом плане есть необычное, назови, буду благодарен, погляжу

Аватара пользователя
ishellstrike
Сообщения: 37
Зарегистрирован: 21 авг 2013, 21:50
Откуда: Москва

Re: jarg

Сообщение ishellstrike » 06 сен 2013, 09:49

Товарищи, я в раздумьях. Не могу определиться между 2мя подходами с хранении данные о разных блоках\существах\предметах.
Сейчас у меня есть одна база, которая хранит все поля, которые могут понадобится блоку\предмету\... т.е. в ней есть и питательность для пищи и боезапас для оружия. А сам массив блоков, например, хранит только id блока и его освещенность. Блок не может сам себя нарисовать и обновить свою логику, т.к. он не знает своих координат и вообще ничего не знает, отрисовка происходит в цикле всем сектором сразу, чем нарушается ооп. Чтобы узнать какие-то данные о блоке есть структура базы, к которой, если обратится по id, можно их все получить -- т.е. имя, описание, непрозрачность и т.д.
Есть вариант сделать 1 класс на 1 тип блоков\существ\предметов. ЧТобы они сами себя рисовали и обновляли. Добавиться гибкости, но пропадет добавление контента без перекомпиляции (сейчас все базы по блокам и т.д. грузятся из текстового файла формата

Код: Выделить всё

~Subclass,id
name=%имя% 
description=%описание% 
и так любые поля в любом порядке)
Что скажете, какой подход оправданнее?

Еще разок:
  • База данных со всеми параметрами, безликие блоки хранят только id
    Класс на каждый тип блока, параметры блока через свойства класса, тип определяется через класс

Аватара пользователя
Jesus05
Сообщения: 1792
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: jarg

Сообщение Jesus05 » 06 сен 2013, 09:53

ishellstrike писал(а):Товарищи, я в раздумьях....
Если твоя задача именно сохранить ООП. то сделай блокам "интерфейс" в котором будут методы только для получения данных отрисовки. и пусть рисовальщик берет блоки только через этот интерфейс.

Аватара пользователя
ishellstrike
Сообщения: 37
Зарегистрирован: 21 авг 2013, 21:50
Откуда: Москва

Re: jarg

Сообщение ishellstrike » 06 сен 2013, 09:56

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

Аватара пользователя
Jesus05
Сообщения: 1792
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: jarg

Сообщение Jesus05 » 06 сен 2013, 10:04

ishellstrike писал(а):Jesus05, практически так и есть, вопрос скорее в том, как хранить данные, в свойствах класса, производного, от класса блок, т.е. класс стол, класс стул. Или дальше хранить в одной большой базе, а блоки оставить одинаковыми.
Я думаю, что можно хранить и в одной большой базе.
Думаю что усложнение и разнос на классы "стол" и "стул" не нужно и оно противоречит борьбе со сложностью.

Аватара пользователя
ishellstrike
Сообщения: 37
Зарегистрирован: 21 авг 2013, 21:50
Откуда: Москва

Re: jarg

Сообщение ishellstrike » 06 сен 2013, 10:24

Jesus05, просто меня печалят конструкции вида

Код: Выделить всё

IBlock a = GetBlock(x,y);
...=BlockDataBase.Data[a.Id].Description
if(BlockDataBase.Data[a.Id].Prototype == typeof(BlockTable)) {
...=BlockDataBase.Data[a.Id].%поле, характерное для стола%
}
где Description и т.д. -- открытые поля в статическом классе BlockDataBase, от статичности можно конечно избавиться

в ооп подходе было бы

Код: Выделить всё

IBlock a = GetBlock(x,y);
...=(a as Block).Description
if(a is BlockTable) {
...=(a as BlockTable).%поле, характерное для стола%
}
где Description и т.д. -- открытые только для чтения свойства, экземпляра нашего блока. Соответственно у винтовки нет свойств стола.

Аватара пользователя
Jesus05
Сообщения: 1792
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: jarg

Сообщение Jesus05 » 06 сен 2013, 10:35

ishellstrike писал(а):Jesus05, просто меня печалят конструкции вида

Код: Выделить всё

IBlock a = GetBlock(x,y);
...=BlockDataBase.Data[a.Id].Description
if(BlockDataBase.Data[a.Id].Prototype == typeof(BlockTable)) {
...=BlockDataBase.Data[a.Id].%поле, характерное для стола%
}
где Description и т.д. -- открытые поля в статическом классе BlockDataBase, от статичности можно конечно избавиться

в ооп подходе было бы

Код: Выделить всё

IBlock a = GetBlock(x,y);
...=(a as Block).Description
if(a is BlockTable) {
...=(a as BlockTable).%поле, характерное для стола%
}
где Description и т.д. -- открытые только для чтения свойства, экземпляра нашего блока. Соответственно у винтовки нет свойств стола.
А не замучаешься все типы объектов приписывать в коде, и на каждый делать класс... а чем отличаться будут эти классы?

Аватара пользователя
ishellstrike
Сообщения: 37
Зарегистрирован: 21 авг 2013, 21:50
Откуда: Москва

Re: jarg

Сообщение ishellstrike » 06 сен 2013, 10:40

Jesus05 писал(а):А не замучаешься все типы объектов приписывать в коде, и на каждый делать класс... а чем отличаться будут эти классы?
Да, в этом то и вся проблема, отличаться стол от стола, по сути, будут, только свойством, возвращающим их спрайт, ну и свойством-именем. Такой подход используется в minecraft и я бы не сказал, что он чемпион по производительности )

Аватара пользователя
Jesus05
Сообщения: 1792
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: jarg

Сообщение Jesus05 » 06 сен 2013, 10:44

мои прошлые размышления на эту тему там -> http://rlgclub.ru/forum/viewtopic.php?p=8114#p8114 начиная с этого сообщения и ниже.

Аватара пользователя
Cfyz
Сообщения: 761
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: jarg

Сообщение Cfyz » 06 сен 2013, 11:39

(то, что я скажу, может быть и мимо, ведь я так и не понял что именно ты подразумеваешь под "безликим блоком": объект на карте, ячейка карты, описательный блок в базе, etc.)

tl;dr Объекты в классы 1:1 нельзя, надо делать небольшое количество фундаментально различных классов-сущностей.
ishellstrike писал(а):Да, в этом то и вся проблема, отличаться стол от стола, по сути, будут, только свойством, возвращающим их спрайт, ну и свойством-именем
Если стол и стул отличаются только спрайтом и именем, то это одна сущность ("фурнитура", скажем) и нет смысла разделять ее. Если два объекта отличаются только содержимым полей, но не их количественным или качественным составом, то это один класс объектов.
ishellstrike писал(а):Добавиться гибкости, но пропадет добавление контента без перекомпиляции
Такие аргументы меня всегда смущали. ООП это же не классы по поводу и без, это в первую очередь логическое разделение. Разные классы объектов, т. е. разные сущности, они должны вести себя по-разному. Если выходит, что они не ведут себя по-разному, не требуют фундаментально разных алгоритмов для обработки (и не требуют перекомпиляции), то это означает лишь ошибку в проектировании, и это на самом деле один класс, объекты которого отличаются только содержимым, которое обрабатывается одинаково для всех объектов этого класса. И это нормально, что программу приходится перекомпилировать из-за добавления или модификации алгоритма =).
ishellstrike писал(а):ЧТобы они сами себя рисовали и обновляли.
По-моему, тут распространненный случай over-engineering. Вот например с отрисовкой, чаще всего нет никакого смысла выносить ее в "классы", как правило отрисовка отдельных объектов алгоритмически ничем не отличается, будь это буквы ASCII, тайлы или даже 3D-модели. Внешнее оформление -- это лишь свойство объекта, но не его уникальная характеристика.

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

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

Аватара пользователя
Oreyn
Сообщения: 297
Зарегистрирован: 07 авг 2013, 14:59

Re: jarg

Сообщение Oreyn » 06 сен 2013, 12:51

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

Точно так ядовитый паук и скелет тоже экземпляры одного класса. Но у паука есть тег "ядовитый", который дает шанс отравления при атаке, а у скелета "нежить" и "костяной", который отменяют лечение и урон от дистанционных атак.
Плюс такого подхода, что изменять свойства объектов можно прямо на ходу. Некромант оживляет трупы? Бах, оживляем существо и добавляем тег "нежить" и вот уже ядовитый мертвый паук, с шансом отравить при атаке и не котого не действует лечение, марширует по полю.
Редкая магическая наковальня, положили любой предмет - бах! добавился тег "слотабл" и в предмет можно вставить драг камень, что повышает характеристики.

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 6 гостей