Strange Wood

[Dmiry]

18.07.07
При запуске приложения выдает ошибку в SDL. ОШибка в SDL.dll по адресу 10019B02. Не понимаю, из-за чего. Надо попробовать сделать тестовый проект просто для обработки клавиатуры.

22.07.07
Не работает обработка событий клавиатуры в SDL. Не понимаю, почему. Вроде код правильный. Впечатление, что окно игры просто не получает событий от клавиатуры. Попробовать включить в проект флаг CONSOLE? Добавил. Теперь создается текстовое окно, в дополнение к окну SDL. Но клавиатура все равно не обрабатывается.

Начал писать редактор для предметов. Чтобы не лазить каждый раз в файл описания предметов. Попробовал включить существующие модули от игры в редактор. Не получилось. Модуль UItems довольно плотно завязан с остальными модулями. Это плохо. Получается, что между модулями довольно высокая связность.

Вопрос к сообществу: кто может поделиться работающим примером обработки клавиатуры средствами SDL (на Delphi)?

[Alchemist]

Вопрос к сообществу: кто может поделиться работающим примером обработки клавиатуры средствами SDL (на Delphi)?

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

procedure TMainWindowSDL.WndCreate(aWidth, aHeight: Integer);
begin
  inherited WndCreate(aWidth, aHeight);
  SDL_Init(SDL_INIT_VIDEO);
end;

procedure TMainWindowSDL.WndDestroy;
begin
  SDL_QUIT;
  inherited WndDestroy;
end;

procedure TMainWindowSDL.Run();
var
  event: TSDL_Event;

  function KeyboardStateToShiftState: TShiftState;
  var
    modifier: LongWord;
  begin
    Result := [];

    modifier := event.key.keysym.modifier;

    if (modifier and KMOD_LCTRL <> 0) or (modifier and KMOD_RCTRL <> 0)
    then Include(Result, ssCtrl);

    if (modifier and KMOD_LSHIFT <> 0) or (modifier and KMOD_RSHIFT <> 0)
    then Include(Result, ssShift);

    if (modifier and KMOD_LALT <> 0) or (modifier and KMOD_RALT <> 0)
    then Include(Result, ssAlt);
  end;

var
  x, y: Integer;
  key: Word;
  Shift: TShiftState;
  button: TMouseButton;
begin
  try
    AppCreate();

    try
      if (Cursor <> nil)
      then SDL_ShowCursor(0);

      while not(Terminate) do begin
        while (SDL_PollEvent(@event) = 1) do begin
          case event.type_ of
            SDL_KEYDOWN: begin
              key := event.key.keysym.sym;
              Shift := KeyboardStateToShiftState();
              KeyDown(key, Shift);
            end;

            SDL_KEYUP: begin
              key := event.key.keysym.sym;
              Shift := KeyboardStateToShiftState();
              KeyUp(key, Shift);
            end;

            SDL_MOUSEMOTION: begin
              x := event.motion.x;
              y := event.motion.y;

              Shift := [];
              if (event.motion.state = SDL_BUTTON_LEFT) then Include(Shift, ssLeft);
              if (event.motion.state = SDL_BUTTON_MIDDLE) then Include(Shift, ssMiddle);
              if (event.motion.state = SDL_BUTTON_RIGHT) then Include(Shift, ssRight);

              MouseMove(Shift, x, y);
            end;

            SDL_MOUSEBUTTONDOWN: begin
              x := event.button.x;
              y := event.button.y;

              Shift := [];
              if (event.button.button = SDL_BUTTON_LEFT) then button := mbLeft;
              if (event.button.button = SDL_BUTTON_MIDDLE) then button := mbMiddle;
              if (event.button.button = SDL_BUTTON_RIGHT) then button := mbRight;

              MouseDown(button, Shift, x, y);
            end;

            SDL_MOUSEBUTTONUP: begin
              x := event.button.x;
              y := event.button.y;

              Shift := [];
              if (event.button.button = SDL_BUTTON_LEFT) then button := mbLeft;
              if (event.button.button = SDL_BUTTON_MIDDLE) then button := mbMiddle;
              if (event.button.button = SDL_BUTTON_RIGHT) then button := mbRight;

              MouseUp(button, Shift, x, y);
            end;

            SDL_QUITEV: Terminate := True;

            SDL_VIDEOEXPOSE: Paint();
          end;
        end;
      end;
    finally
      AppDestroy();
    end;
  except
    on E: Exception do LogWrite('MainWindow.Run(): ' + E.Message);
  end;
end;

procedure TMainWindowSDL.SetCaption(const Value: string);
begin
  inherited SetCaption(Value);

  SDL_WM_SetCaption(PChar(Value), nil);
end;

Надеюсь, поможет. У меня все работает

[Dmiry]

Спасибо!

После изучения твоего кода поправил свой, и все заработало!

[Dmiry]

28.07.07
Обработка клавиатуры работает. Дополнительно слегка изменил вывод на экран, вынеся Flip в отдельный метод. Заметно ускорился вывод на экран.

Поскольку с текстами пока затык, решил начать делать монстров и НПС. Насчет вывода текста на экран - надо разобраться с модулем SDL_sfont. Вроде он делает все, что мне надо.

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

[Dmiry]

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

31.07.07
Вместо монстров начну делать LOS. Сначала - отрисовка карты с видимыми и невидимыми тайлами, затем - пометка виденных тайлов и их отрисовка.

Пока отказался от рисования посещенных тайлов. Сначала разобраться с рисованием видимых тайлов. Для простоты возьмем квадрат 7х7 клеток, герой в центре. Требуется отрисовать все тайлы карты в этом квадрате. А также все предметы, если они там есть.

Сделал такое рисование. Но пока почему-то не работает корректно вывод. Неправильность в следующем: запаздывает рисование вновь видимых тайлов, и не стираются те, которые уже невидимы. Попробую сделать сейчас следующее: при вызове Hero.SetPosition все ранее видимые тайлы становятся невидимыми. Плюс перенести DoFOV после установки новой позиции.

Перенес. Теперь работает правильно. Отрисовка ранее посещенных тайлов осталась. При прокрутке рисует не вполне правильно. Вообще, получилось зрелище не для слабонервных. Еще и с учетом неправильно рисуемых предметов.

[Максим Кич]

28.07.07
Есть еще одна идея для игры, но надо подумать. Заменить просто голод и жажду более широкими потребностями. Точнее, голод по разным продуктам. То есть например, на хлебе и воде долго не протянешь. Смысл - чтобы на зиму заготавливать не только копченое мясо или гречку. Через полгода питания одной гречкой человека станет тошнить только от ее вида. Тут надо подумать, как лучше это реализовать? Включить в описание каждого продукта перечень составных элементов? Или заменить состав продукта перечнем вкусов? В общих чертах - заменяем для каждого продукта один параметр (питательность) несколькими (для простоты - питательность А, Б, В и т.д.). И отдельно просчитывать голод по каждому параметру. Если например не хватает элемента А, и его больше всего в огурцах - выводить сообщение "Персонаж хочет огурцов". Если поесть других продуктов, в которых этого элемента тоже много - можно голод по этому параметру удовлетворить. Но зато можно получить пресыщение по другому элементу Б, что тоже нехорошо - теперь персонажа какое-то время будет тошнить от продуктов, содержащих этот элемент в некотором кол-ве, превышающем определенный уровень. В общем, это надо попробовать реализовать и посмотреть, что будет.

Эх, ты меня опередил. Но у меня эта фишка возникла из общей концепции отказа от хитпойнтов: там ещё для того, чтобы нормально шла прокачка, нужно правильно питаться. Но пока колеблюсь — боюсь прибить геймплей.

[Maelstrom]

Но пока колеблюсь — боюсь прибить геймплей.

Если делаешь канонический рогалик, то геймплей вполне может поколечится. А если аналог unreal world - т.е. симулятор чукчи-оленепаса , то такое вполне разнообразит игру

[Sanja]

Максим Кич

боюсь прибить геймплей.

И прибьёшь. Симс это ужасно.

Dmiry

В общем, это надо попробовать реализовать и посмотреть, что будет.

Да можно и не пробовать. И так ясно. С Maelstrom-ом согласен.

Твоя фишка с едой смещает акцент с боя и тактики (что есть рогалик) на какой-то симулятор робинзона крузо. Короче и посоветовать нечего, т.к. не понятно что за рогалик ты делаешь.

[darhark]

Да... не стоит... Точнее - геймплей не прибьешь, просто странно это. В рогалике герой - Герой! Настоящий мужик. Сражается с ордами гоблинов. Переносит голод, холод и непогоду. Он должен уметь питаться тухлыми крысами. А не воротить нос от батона только потому, что на него не положили кусок колбасы с сыром. Лучше пига добавь. Вот без пига никакой герой точно долго не протянет.

[Dmiry]

Короче и посоветовать нечего, т.к. не понятно что за рогалик ты делаешь.

Вот ответ:

аналог unreal world - т.е. симулятор чукчи-оленепаса

Лучше пига добавь. Вот без пига никакой герой точно долго не протянет.

Если имеется в виду пиво, то со временем появится медовуха со всеми вытекающими последствиями.

Собственно, регулярно прокручиваю в голове те фишки, которые были в UrW, и пытаюсь представить, что можно сделать иначе. Например, ххочется иметь свободное строительство, не ограниченное тремя предопределенными постройками. Мясо или рыбу не только жарить, солить или сушить, а еще в леднике хранить. Зерно в амбаре (от мышей защищать), мед в ульях (от медведей), пиво в бочках (от проходимцев-приключенцев).
Для воды колодец выкопать (а не только снегом питаться).
Потерял серп - пошел в кузницу и новый выковал (насколько умения хватит).
Зимой ноги мерзнут - летом овцу постриг и носки связал (а их моль сожрала).

[Dmiry]

После перерыва продолжаю.

21.08.07
Начал делать систему тайм-менеджмента. За основу взял статью с Roguebasin, но переделываю на классы вместо использования процедурных типов.

Поменял картинки тайлов, взял готовые, перевел на размер 32х32. Выглядит симпатичнее. Глюк с неправильной отрисовкой при скролле карты остался. Пока нет идей, откуда это может возникать. Предположение - сначала надо очистить старое изображение.

Сегодня размышлял, как лучше сделать систему производства. Два варианта: либо выбирать использование скилла, либо использование станка. И в том, и в другом случае выбором будет определяться перечень возможных действий. Стоит ли включать использование схем/чертежей? Например, при старте персонаж умеет делать только несколько базовых вещей, которые он изучил во время детства/взросления, а остальное - надо узнавать у соответствующих мастеров. Например, сделать шалаш может любой, а вот построить дом или баню - только тот, кто учился у плотника. Можно включить возможность самостоятельного изучения - например, имея топор, любой сможет вытесать гладкое бревно после сотни запорченных деревьев. Другое дело, что при обучении у плотника число запорченных деревьев будет исчисляться в худшем случае одним-двумя десятками.

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

Сейчас задумался - как реализовать прерывание действия при наступлении какого-то события. Например, в UrW персонаж мог бросить свое занятие, если получал рану, обморожение, или по команде с клавиатуры. Как вариант: выделить отдельное событие - действие персонажа. Если идет команда с клавиатуры - это действие прекращается и удаляется из очереди (после подтверждения). Надо подумать - прерванные действия как потом предолжить? Ведь если прерваться на середине тесания бревна - потом надо будет не тесать заново, а начать уже с середины. С другой стороны, некоторые действия нельзя прерывать. Точнее, можно прервать безболезненно (рыбалка), или при прерывании действия результат будет утрачен. Тогда удастся избежать ситуации "наполовину натянутый арбалет".

[Dmiry]

25.08.07
Сейчас задумался - надо почти полностью переделывать систему обработки событий в игре. При новой системе исчезает процедура NextTurn. Остается система учета времени (и времен года). Какие могут возникнуть ситуации: регулярное уменьшение значения сытости, при нахождении на холоде наступает обморожение. Календарь в любом случае остается постоянно. Это понадобится для учета времени суток и времен года. Надо ли делать изменение длины дня в зависимости от времени года? В UrW это вроде бы есть.

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

Примеры получились следующие:
1) кратковременное, не прерываемое: шаг, удар оружием
2) длительное, не прерываемое игроком, с продолжением: сон
3) длительное, прерываемое, без продолжения, с полной потерей ресурсов: приготовление мяса или рыбы
4) длительное, прерываемое, без продолжения, без потери ресурсов: рыбалка, рубка леса(?)
5) длительное, прерываемое, с продолжением, без потери ресурсов: постройка дома
6) длительное, прерываемое, с продолжением, с частичной потерей ресурсов: ???
7) длительное, прерываемое, с продолжением, с полной потерей ресурсов: ?не бывает?

Задумался над необходимостью введения разделения на длительные и прерываемые действия. Получается, что если действие короткое, то оно не прерываемое, если длинное - прерываемое. Надо над этим еще подумать. Пока надо продумать механизм прерывания действия. Это может происходить как по команде с клавиатуры, так и по наступлению некоторых других событий. Например, при обморожении надо выдать запрос - остановить зимнюю рыбалку или продолжить. Или во время сна услышать шорох и проснуться.

[Dmiry]

12.09.07
Все еще затыкаюсь с отрисовкой карты на экране. Попробовал вывести в дамп содержимое клеток карты (видимость и известность). В памяти все правильно, а вот отрисовка происходит неправильно. Надо разбираться с SDL. Кажется, проблема именно в этом.
Переделываю систему тайм-менеджмента. Для отладки и разборки завел отдельный проект. Частично перевел на классы. Осталось оформить само событие в виде отдельного класса, плюс разобраться как эти события будут работать параллельно. Сейчас фактически работает только одно событие - обновление календаря. Надо бы добавить еще парочку событий работающих параллельно, и проверить их работу.
Решил разделить событие на две части: первая - это то, что хранится в списке событий, второе - какие действия выполняются при наступлении события. То есть вместо одного класса TimeEntity появляются два: TimeEntity и TimeAction.

[Asesino]

Dmiry
Альф-бет пока никаких, как я понимаю, нет? Проект очень интересный, желаю успехов!

[darhark]

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