Если не делать его многоклеточнымJustHarry писал(а):Да я бы не сказал, что игра в стиле "подходи по одному". Зомби то будут респаунится в разных точках карты и будут окружать игрока. Так что единственный способ заставить их подходить по одному это забуриться в какую нибудь комнату, и сидеть там, вот только за патронами придется бегать. К тому же босса придется водить за собой долго, если валить его не очень убойным оружием.
AfterlifeRL
Модератор: Jolly Roger
- Максим Кич
- Администратор
- Сообщения: 1642
- Зарегистрирован: 03 дек 2006, 20:17
- Откуда: Витебск, Беларусь
- Контактная информация:
Re: AfterlifeRL
Dump the screen? [y/n]
Re: AfterlifeRL
Согласен насчёт слишком больших домов и комнат. Вообще, карту следует уменьшить, площади и улицы тоже слишком огромные, даже учитывая специфику игры(орды зомби).
Re: AfterlifeRL
Поживем - увидим.Согласен насчёт слишком больших домов и комнат.
Итак, что насчет монстров.
Структуру их я написал, теперь думаю насчет их респа.
В принципе, здоровье и урон монстров будут расти линейно, но возможно с небольшими рандомными отклонениями. Боссы будут уникальными со своими собственными способностями. Я придумал следующую схему:
Волна N.
Фаза 1.
Среднее число зомби.
Малое число собак и птиц.
Фаза 2.
Среднее число зомби.
Среднее число собак и птиц.
Несколько стреляющих монстров.
Фаза 3.
Большое число зомби.
Среднее число собак и птиц.
Малое число порождений хаоса.
Финальная фаза.
Огромное число зомби.
Большое число собак и птиц.
Среднее число порождений хаоса.
Босс.
Коэффициент "множественности" будет расти в зависимости от волны. В начале на вас будут нападать небольшие группы врагов, в конце вам придется только успевать менять обоймы и смотреть в оба.
Сегодня подумаю над формулой.
Re: AfterlifeRL
Сделай в зависимости от уровня прокачки персонажа (если он есть). А потом сбалансируй. Спортивно! И добавь конечно ачивки-медальки (оригинальные). Получится эдакий кримсонленд. А если уж зомби-тема (сам фанат Z-всего), добавь такую фичу: "после крита зомби - игроку дается время до превращения (допустим 2 минуты). За это время нужно максимально реализовать весь свой комбат скилл + rage mode". И чтобы можно было играть за женщину-негритянку. Топ-100 (кто умер на какой волне, сколько продержался после заражения, сколько спас живых(теоретически)). Я буду играть в такую игру и советовать ее знакомым.Коэффициент "множественности" будет расти в зависимости от волны
Re: AfterlifeRL
Да, персонаж будет качаться также. Постараюсь увязать все в одну кучу.Сделай в зависимости от уровня прокачки персонажа(если он есть)
Позже будутдобавь конечно ачивки-медальки (оригинальные)
Да, тоже хорошая идея. Можно успеть лекарство найти.после крита зомби - игроку дается время до превращения (допустим 2 минуты). За это время нужно максимально реализовать весь свой комбат скилл + rage mode
Это типа вот такой: ☻ ?И чтобы можно было играть за женщину-негритянку.
Живых теоретически добавлю.Топ-100 (кто умер на какой волне, сколько продержался после заражения, сколько спас живых(теоретически))
"Рикомендую такую игру"Я буду играть в такую игру и советовать ее знакомым.
Re: AfterlifeRL
Ну да же, на все. Смертность должна составлять 98%.
Re: AfterlifeRL
Вопрос по ООП:
Вот я написал следующее:
type Item=Object
x,y:byte;{координаты на карте}
InBag:boolean;{у игрока или нет}
procedure Drop;
procedure Get;
procedure Use; virtual;
end;
потом хочу создать к примеру класс оружия(потомок)
пишем
type Weapon=object(Item)
name:string[20];
ammotype:byte;
procedure Fire;
procedure Use; Virtual;
end;
1) Когда пытаюсь вызвать процедуру Item.Use или Weapon.Use, вылетает с ошибкой 210, хотя эти процедуры я объявил.
АПДЕЙТ: вроде разобрался. У родителя метод Use сделал виртуальным, а у потомка сделал статичным.
2) Непонятно, как хранить к примеру массив вещей, если скажем, несколько предметов типа Weapon, а несколько предметов типа Ammo, если например напишем
var Inventory:array[1..MaxItems] of Item;
можно ли присваивать родительскому типу тип потомка?
типа
Inventory[k]:=w, если w - weapon.
Я в размышлениях.
Вот я написал следующее:
type Item=Object
x,y:byte;{координаты на карте}
InBag:boolean;{у игрока или нет}
procedure Drop;
procedure Get;
procedure Use; virtual;
end;
потом хочу создать к примеру класс оружия(потомок)
пишем
type Weapon=object(Item)
name:string[20];
ammotype:byte;
procedure Fire;
procedure Use; Virtual;
end;
1) Когда пытаюсь вызвать процедуру Item.Use или Weapon.Use, вылетает с ошибкой 210, хотя эти процедуры я объявил.
АПДЕЙТ: вроде разобрался. У родителя метод Use сделал виртуальным, а у потомка сделал статичным.
2) Непонятно, как хранить к примеру массив вещей, если скажем, несколько предметов типа Weapon, а несколько предметов типа Ammo, если например напишем
var Inventory:array[1..MaxItems] of Item;
можно ли присваивать родительскому типу тип потомка?
типа
Inventory[k]:=w, если w - weapon.
Я в размышлениях.
- Jolly Roger
- Сообщения: 2973
- Зарегистрирован: 27 ноя 2009, 09:10
- Откуда: Minsk, Belarus
Re: AfterlifeRL
Помню, что похожий вопрос уже разбирался на форуме пару раз.
По поводу ошибки 210 помочь не могу, что касается массива вещей, то, Массива вещей нет, просто у каждого предмета есть указатель на следующий (по желанию предыдущий), а у персонажа просто один указатель на первый предмет в общем массиве вещей.
Таким образом, сразу снимается необходимость скрещивать ужа с ежом.
Что касается непосредственно вещейкак мне помнится, было два варианта: они либо имеют общего предка типа ITEM, либо, не мудрствуя лукаво, любой предмет обладает всеми характеристиками доступными Всем предметам.
Имхо, второй вариант лучше, так как много места не сьест, а позволит обойти кучу острых углов и повысит гибкость и устойчивость приложения, что, имхо, для рогалика важнее экономичности и точности.
По поводу ошибки 210 помочь не могу, что касается массива вещей, то, Массива вещей нет, просто у каждого предмета есть указатель на следующий (по желанию предыдущий), а у персонажа просто один указатель на первый предмет в общем массиве вещей.
Таким образом, сразу снимается необходимость скрещивать ужа с ежом.
Что касается непосредственно вещейкак мне помнится, было два варианта: они либо имеют общего предка типа ITEM, либо, не мудрствуя лукаво, любой предмет обладает всеми характеристиками доступными Всем предметам.
Имхо, второй вариант лучше, так как много места не сьест, а позволит обойти кучу острых углов и повысит гибкость и устойчивость приложения, что, имхо, для рогалика важнее экономичности и точности.
Писать диздок спустя несколько лет разработки и множества изменений концепции - исконная русская девелоперская традиция.
Re: AfterlifeRL
Спасибо!
ERROR 210: Call to abstract method (Вызов абстрактного правила)
Имхо, во втором случае все равно массив объектов можно использовать, если они все однотипные.
ЗЫ: что касается самой игры:
вытянул список оружия и патронов, теперь буду размещать их в игре.
Вот он.
Weapons
Ammo
Свобода выбора налицо=)
ERROR 210: Call to abstract method (Вызов абстрактного правила)
Имхо, во втором случае все равно массив объектов можно использовать, если они все однотипные.
ЗЫ: что касается самой игры:
вытянул список оружия и патронов, теперь буду размещать их в игре.
Вот он.
Weapons
Скрытый текст: ПОКАЗАТЬ
Скрытый текст: ПОКАЗАТЬ
Re: AfterlifeRL
Можно, а вот чтоб потом сделать наоборот, т.е. w := Inventory[k] придется делать приведение типов:JustHarry писал(а):можно ли присваивать родительскому типу тип потомка? типаInventory[k]:=w, если w - weapon.
w := Weapon(Inventory[k]);
Я вместо массивов\двухсвязного списка использую TList, тоже свои плюсы и минусы есть. Еще можно динамические массивы юзать (A: array of Item; SetLength(A, 100))
Не хочу разводить флемваров, но имхо первый вариант проще и изящнее. Макконнелл рекомендует.Jolly Roger писал(а):Что касается непосредственно вещейкак мне помнится, было два варианта: они либо имеют общего предка типа ITEM, либо, не мудрствуя лукаво, любой предмет обладает всеми характеристиками доступными Всем предметам.
Да, и кстати конструкция
вообще-то deprecated. Лучше использовать динамически создаваемыеtype Item=Object
type Item=class
Но если в конструкторах\деструкторах не разбираешься, то и object сойдет.
Re: AfterlifeRL
А если захочу например метод Weapona использовать?Можно, а вот чтоб потом сделать наоборот, т.е. w := Inventory[k] придется делать приведение типов:
Это как писать
Weapon(a[k]).Use
?
Просто если просто пишу a[k].use он вызывает Item.Use а не Weapon.Use. Бида.
Re: AfterlifeRL
Если метод виртуальный, то должен вызываться Weapon.Use
Если вызывается Item.use - значит метод статический.
У тебя Weapon.Use объявлен с директивой override? Компилятор какие-нибудь варнинги выдает? И что за компилятор кстати?
Если вызывается Item.use - значит метод статический.
У тебя Weapon.Use объявлен с директивой override? Компилятор какие-нибудь варнинги выдает? И что за компилятор кстати?
Re: AfterlifeRL
Короче у итема метод Use виртуальный, а у Weapona нет. Когда вызываю Weapon.Use работает а когда a[k].Use вылетает. Компилятор Free Pascal 2.4.0.У тебя Weapon.Use объявлен с директивой override? Компилятор какие-нибудь варнинги выдает? И что за компилятор кстати?
А что такое override?
Re: AfterlifeRL
Если мы в родителе объявляем метод virtual, то во всех потомках надо объявлять его override; И наверняка компилятор тебе на это указывает (при компиляции сообщение что-то типа method Weapon.Use hides virtual inherited method).
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 58 гостей