Создание ролевой компьютерной игры

Мы приблизились к, пожалуй, самой ответственной части программы - программированию сражений с монстрами, ключевому элементу любой ролевой игры и игровой системы. Однако, несмотря на достаточную и объективную трудоемкость задачи, мы незамедлительно приступим к ее реализации, причем начнем с наиболее очевидных и простых элементов. Прежде всего, конечно, подготовим модуль Monster:

  unit Monster;

  interface

  implementation

  end.

Монстр будет характеризоваться, в первом приближении, своим названием, координатами на карте (x,y), а также, как планировалось ранее, здоровьем, количеством получаемого героем за победу над монстром опыта, уровнем монстра, атакой, обороной, дальностью зрения (расстояния, с которого монстр обнаруживает героя) и способом перемещения (точнее, вероятностью случайного шага в сторону в ходе преследования героя, когда тот обнаружен):

  type TMonster = record
     Name: String[20];
       ID,x,y: Integer;
       HP, MaxHP, XP, Level,
       Ad1, Ad2, Dd1, Dd2,
       ViewZone, RandomStep: Integer;
       end;

Что означают эти параметры? Поле ID - некий уникальный идентификатор, позволяющий отличить один тип монстров от другого. Значение полей Ad1, Ad2 задает величину поражения, которое наносится монстром герою. Поражение вычисляется по общепринятой в ролевых играх схеме - бросается N кубиков, каждый из которых описывается M гранями, и выброшенные результаты суммируются. Например, сочетание значений Ad1 = 2 и Ad2 = 6 означает, что бросаются два шестигранных кубика. Если выпадет, допустим, 1 и 4, то суммарное поражение составит 5 единиц.

Соответственно, поля Dd1 и Dd2, которые можно условно отнести к толщине шкуры, определяют величину, которую монстр отражает (вычитает) из поражения, которое ему нанесено. Так, если герой наносит монстру с характеристиками Dd1 = 3 и Dd2 = 2 удар, равный 11 единицам, а значения трех виртуальных двугранных кубиков (таких кубиков конечно не существует, но это неважно) составили значения 1, 2 и 2 (сумма равна 5), то реальный ущерб, нанесенный монстру, окажется равным 11-5 = 6 единицам.

Уровень монстра (Level) позволит корректно определять количество опыта, получаемое героем при победе. Если уровень героя выше, опыт будет меньше - и наоборот. Пока мы сделали самого сильного монстра седьмого уровня, для масштабной игры с множеством локаций потребуется гораздо большее число монстров.

Монстра с уровнем здоровья (HP), меньшим или равным нулю, будем считать мертвым и на карте не показывать.

Теперь подготовим массив типов монстров (именно типов, а не самих монстров - на карте может быть одновременно несколько монстров одного типа). Для начала сделаем семь типов монстров, в дальнейшем их можно будет произвольно увеличивать и изменять (в данном случае под типом имеется в виду не тип Паскаля, а тип монстра в игровом смысле - способ его реализации может отличаться от создания типа данных):

  const MaxMonsterTypes = 7;
         MonsterTypes: array[1..MaxMonsterTypes] of TMonster =
         (
         (Name: STR_MONSTER1;
          ID:1; x:0; y:0;
          HP:1; maxHP:1; XP:1; Level:1;
          ad1:1; ad2:3; dd1:1; dd2:2;
          ViewZone:4;
          RandomStep:3),
         (Name: STR_MONSTER2;
          ID:2; x:0; y:0;
          HP:2; maxHP:2; XP:2; Level:1;
          ad1:1; ad2:6; dd1:1; dd2:2;
          ViewZone:3;
          RandomStep:4),
         (Name: STR_MONSTER3;
          ID:3; x:0; y:0;
          HP:5; maxHP:5; XP:3; Level:1;
          ad1:1; ad2:2; dd1:2; dd2:2;
          ViewZone:4;
          RandomStep:5),
         (Name: STR_MONSTER4;
          ID:4; x:0; y:0;
          HP:9; maxHP:9; XP:7; Level:2;
          ad1:2; ad2:4; dd1:1; dd2:6;
          ViewZone:3;
          RandomStep:5),
         (Name: STR_MONSTER5;
          ID:5; x:0; y:0;
          HP:12; maxHP:12; XP:9; Level:2;
          ad1:3; ad2:3; dd1:3; dd2:2;
          ViewZone:3;
          RandomStep:4),
         (Name: STR_MONSTER6;
          ID:6; x:0; y:0;
          HP:20; maxHP:20; XP:15; Level:3;
          ad1:2; ad2:6; dd1:1; dd2:10;
          ViewZone:4;
          RandomStep:4),
         (Name: STR_MONSTER7;
          ID:7; x:0; y:0;
          HP:35; maxHP:35; XP:30; Level:4;
          ad1:4; ad2:10; dd1:2; dd2:6;
          ViewZone:5;
          RandomStep:3)
         );

Названия монстров разместим в модуле Texts (на него надо добавить ссылку в разделе Interface):

          STR_MONSTER1 = ' Крыса ' ;
          STR_MONSTER2 = ' Волк ' ;
          STR_MONSTER3 = ' Гигантский Паук ' ;
          STR_MONSTER4 = ' Скелет ' ;
          STR_MONSTER5 = ' Орк ' ;
          STR_MONSTER6 = ' Тролль ' ;
          STR_MONSTER7 = ' Гигантский Змей ' ;

Тут важно, что эти константы в DOS-версии должны быть записаны, конечно, в DOS-кодировке.

Массив действующих на карте монстров будем хранить в модуле Monster - в переменной под названием Monsters:

  const MaxMonsters = 50;
  var Monsters: array[1..MaxMonsters] of TMonster;

Константа MaxMonsters задает максимально допустимое число одновременно действующих монстров на карте.

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

Однако может вызвать определенные затруднения задача случайного выбора из массива MonsterTypes монстров одного уровня. Ведь исходно число типов монстров с одинаковым значением поля Level нам неизвестно, кроме того, в MonsterTypes они могут следовать в произвольном порядке. Если бы мы использовали Delphi, где имеется концепция динамических массивов, задачу удалось бы решить весьма легко. Однако TurboPascal по современным меркам весьма ограничен, поэтому воспользуемся более прямолинейным и нехитрым, хотя и не очень быстрым методом. Начнем перебирать все элементы массива MonsterTypes, и при нахождении типа монстра с нужным нам уровнем бросать виртуальный кубик. Таким образом мы выберем не первый попавшийся подходящий элемент MonsterTypes, а случайный, хотя равномерность этого случайного выбора в значительной степени будет зависеть от числа граней нашего условного кубика.

Следующая процедура заполняет монстрами текущую локацию, используя условный шестигранный кубик:

  procedure GenerateMonsters;
  var i,j,x,y: Integer;
  label Break2;
  begin
  for i := 1 to MaxMonsters do
    begin
    while true do
      for j := 1 to MaxMonsterTypes do
        if (MonsterTypes[j].Level = CurMap) and (random(6)=0) then
           begin
           Monsters[i] := MonsterTypes[j];
           FreeMapPoint(x,y);
           Monsters[i].x := x;
           Monsters[i].y := y;
           GoTo Break2
           end;
   Break2:
    end;
  end;

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

Генерацию монстров будем выполнять сразу после генерации карты в главной части программы, не забыв подключить в список модулей Monsters:

  program LearningRPG;

  uses Map, LowLevel, Hero, Game, CRT, Monsters;

  var k: Char;

  begin
  Randomize;

  VideoInitialize;
  MapGeneration(1);
  GenerateMonsters;
  InitHeroes;
  ...

А как показывать монстров? В соответствии с упомянутым подходом "послойной" отрисовки тайлы-предметы-монстры-герой. Укажем в процедуре ShowGame новый вызов ShowMonsters:

  procedure ShowGame;
  begin
  ShowMap;
  ShowMonsters;
  ShowHero(CurHero);
  ShowHeroInfo(CurHero);
  end;

Процедуру ShowMonsters реализуем в модуле Monsters. Она должна просканировать список монстров, определить, какие из живых созданий находятся в видимой части окна, и вывести их на экран. Функция проверки, лежит ли некая точка в видимой части, наверняка будет нам полезна в будущем, поэтому реализуем ее в модуле Map:

  function VisiblePoint(x,y: Integer): Boolean;
  begin
  VisiblePoint := GameMap[CurMap].Cells[x,y].IsVisible and
            (x >= GameMap[CurMap].LocalMapLeft) and
                  (x < GameMap[CurMap].LocalMapLeft+LOCAL_MAP_WIDTH)
  and
                  (y >= GameMap[CurMap].LocalMapTopLeft) and
                  (y < GameMap[CurMap].LocalMapTop+LOCAL_MAP_HEIGHT);
  end;

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

Процедура ShowMonsters может быть закодирована так:

  procedure ShowMonsters;
  var i: Integer;
  begin
  for i := 1 to MaxMonsters do
    if (Monsters[i].HP > 0) and
       VisiblePoint(Monsters[i].x,Monsters[i].y) then
       ShowMonster(Monsters[i]);
  end;

Отображение монстра на экране (процедура ShowMonster) связано с особенностями реализации этого процесса в конкретной операционной системе и поэтому должно быть расположено в модуле LowLevel. Сам "монстр" передается по ссылке - для экономии ресурсов, что важно для ДОС-реализации. Рисовать монстров будем таким же способом, как и тайлы - на основе уникального идентификатора станем обращаться к массиву, определяющему способ представления типа монстров на экране. Собственно, при подготовке такого массива нам пригодится уже задействованный в массиве TileRecords тип TTileRecord:

  const MonsterRecords: array[1..MaxMonsterTypes] of TTileRecord =
     (
     (C: ' p ' ; Clr:LightRed),
     (C: ' % ' ; Clr:Yellow),
     (C: ' @ ' ; Clr:LightGreen),
     (C: ' # ' ; Clr:LightMagenta),
     (C: ' & ' ; Clr:LightCyan),
     (C: ' j ' ; Clr:LightGray),
     (C: ' A ' ; Clr:LightBlue)
     );

Процедура отображения монстра будет не сложнее вывода тайла:

  procedure ShowMonster(var mns: TMonster);
  begin
  GoToXY( WINDOW_LEFT+mns.x-GameMap[CurMap].LocalMapLeft,
          WINDOW_TOP+mns.y-GameMap[CurMap].LocalMapTop );
  TextColor( MonsterRecords[mns.ID].Clr );
  Write( MonsterRecords[mns.ID].C )
  end;

Главное, чтобы вызывалась она после отрисовки карты.

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

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

Исходный код текущей версии:

http://russianenterprisesolutions.com/sbo/download/2995.zip 4836 байтов

Письма.

От Дмитрия.

Хочу пояснить, что Вашу рассылку я использую не столько как руководство к действию, сколько по принципу "внимательно прочитай и сделай по-своему". То есть воспринимаю скорее как руководство к размышлению и один из вариантов решения поставленной задачи.
Наверное, та задача, которую я поставил себе, нескольно отличается от Вашей. Моей целью является достаточно специфичный вид roguelike - а именно аналог UnReal World ( http://www.jmp.fi/~smaarane/urw.html). Соответственно, и задачи ставятся ннесколько другие.
Я делаю в игре упор на выживание, использование навыков и создание предметов, а не на dungeon exploration.

Отлично! Очень рад, - конечно, мои тексты - не более, чем руководство к действию! :) И чем оригинальнее будет ваша игра, тем лучше!

1) Уже давно хочу предложить такой вид процедуры для проверки, свободен или нет тайл карты:

  function IsFreeTile(Tile: Integer): Boolean;
  begin
    Result := Tile in WalkableTiles;
  end;

WalkableTiles описана следующим образом:

  const
    WalkableTiles: set of Byte = [tileGrass, tileGround, tileSwamp, tileHill];

Это множество содержит значения констант для различных типов местности. Аналогично можно описывать самые разные варианты для проверок принадлежности какого-либо объекта заданному множеству. В качестве примеров можно привести проверку кода нажатой клавиши - входит ли она в набор допустимых, проверку, является ли предмет режущим оружием и т.д.
Соответственно при изменении правил игры достаточно изменить значение константы, добавив или удалив какие-либо значения из множества. При этом текст соответствующих функций не затрагивается.

Единственная причина, по которой я так не сделал - опасался, что в крупной игре число проходимых тайлов может быть больше 255. Не знаю, как в последних версиях Дельфи, но в старых проверка на наличие в множестве была ограничена 255 элементами.

2) В одном из первых выпусков Вы упоминали (и продолжаете упоминать) модуль Defines.inc, однако так и не разъяснили его значение и содержание.

В 67 выпуске вроде я рассказывал о нем подробнее?

В этом файле хранятся константы для директив условной компиляции, набор для всего проекта. Если мы включаем этот файл в каждый pas-модуль проекта, то потом нам достаточно изменить только одну строчку в этом файле, чтобы весь наш проект полностью пересобрался с другими настройками. Хотим, с текстами на русском или английском, для Дос или Виндовс - меняем лишь настроечные константы в Defines.Inc.

Эта практика популярна в Си - там весь проект базируется на подобных заголовочных файлах, куда вынесены все описания, настройки и интерфейсы. Чуть-чуть подправили интерфейс- весь проект перестроился автоматически. Ну, если конечно исходный код написан правильно :)

3) От стринггрида я сам уже давно отказался, и сделал в графике. Добавлена опция для отображения темно-серым цветом тех тайлов, которые в данный момент не видны, но герой их уже видел. Для этого каждый тайл карты снабжен дополнительным полем IsExplored логического типа. При выводе тайла на экран сначала проверяется, что тайл был исследован. Если нет, ничего не выводится. Если исследован, проверяется его видимость, и соответственно выводится в цвете или темно-серым.

Про стринггрид - следующее письмо. От Boba.

У StringGridа есть событие "OnDrawCell". Оно происходит каждый раз, когда перерисовывается каждая ячейка таблицы. В процедуру передаются такие параметры, которые нам нужны:
Sender: TObject - наша таблица
ACol, ARow: Integer - текущая ячейка, которая перерисовывается
Rect: TRect - прямоугольник ячейки в пределах всего StringGridа
например, если высота строки = 16, а ее ширина - 20, то Rect ячейки [2,1] = (41,17,60,32), при условии если отсутствуют полосы прокрутки.

  procedure TForm1.StringGrid1DrawCell(Sender: TObject; ACol, ARow:
  Integer;
   Rect: TRect; State: TGridDrawState);
  begin
   if {какое-то условие} then with TStringGrid(Sender).Canvas do // наша
  табличка
   begin
   Font.Color:=clYellow; // задаем цвет символа в нашей ячейке
    Brush.Color:=clNavy; // задаем цвет фона ячейки
   FillRect(Rect); // закрашиваем ячейку полностью цветом фона
   TextOut(Rect.Left+2,Rect.Top+2,TStringGrid(Sender).Cells[ACol,ARow]);
  // *
   end;
  end;

  // *
  // выводим в текущую ячейку (которая перерисовывается) текст,
  который
  // содержится в ней же, так как перед этим мы ее закрасили
  полностью
  // и хотим напечатать текст другим цветом, а не тем, который в
  // параметре TStringGrid(Sender).Font.Color

  // к стати, в данном случае в таблице можно отображать ЛЮБОЙ
  текст в ячейке,
  // а не только тот, который в ней содержится. Например, в ячейку
  мы запишем
  // силу монстра "w", и тогда:

  MonsterPower:=IntToStr(TStringGrid(Sender).Cells[ACol,ARow]);
  if MonsterPower<100
   then TextOut(Rect.Left+2,Rect.Top+2, ' w ' )
   else TextOut(Rect.Left+2,Rect.Top+2, ' W ' );

  // таким образом содержимое ячейки = ' 100 ' , а отображаться будет
  ' w ' или ' W ' .
  // а если поиграться еще с Font.Style, Font.Size...

Далее, можно вставить в ячейку картинку.
Предлагают через ImageList, но мне этот компонент не сильно нравится (ну, не люблю я его!):

  procedure TForm1.StringGrid1DrawCell(Sender: ...
  var ImageIndex : Integer;
  begin
   if
   // рисуется колонка, в которую мы хотим поместить картинку
   // и выполняется условие для рисования картинки
   then
   begin
   ImageIndex:= ... { получим значение номера картинки в ImageList }
   // А теперь пусть ImageList нарисует ее на канве DBGrid ' а
   ImageList.Draw(TDBGrid(Sender).Canvas,Rect.Left,Rect.Top,
  ImageIndex);
   end;
  end;

Но я люблю через TBitmap или TImage.
Кладем на форму Имаги и грузим в них картинки, или объявляем TBitmapы, вот несколько примеров:

  public
   MyBm: TBitmap; // 1 битмап
   aBm: array [0..10] of TBitmap; // 11 битмапов
   aDynBm: array of TBitmap; // сколько хош битмапов :)

В событии создания формы:

  MyBm:=TBitmap.Create; // перед использованием BitMap ' а его нужно
  сначала создать
  MyBm.LoadFromFile( ' 1.bmp ' ); // загрузили картинку 1.bmp в MyBm

  for i:=0 to 10 do
  begin
   aBm[i]:=TBitmap.Create; // создаем текущий Битмап
   aBm[i].LoadFromFile(IntToStr(i)+ ' .bmp ' ); // загружаем в него картинку
  end;

  SetLength(aDynBm,FileCount( ' *.bmp ' )); // Задаем сколько хотим
  битмапов :) **
  for i:=0 to Length(aDynBm)-1 do
  begin
   aDynBm[i]:=TBitmap.Create;
   aDynBm[i].LoadFromFile( ' имя BMP-файла ' );
  end;

  // ** функции FileCount( ' *.bmp ' ) вроде нету в Дельфи, так что ее
  придется делать самому.

  // примечание: перед загрузкой партинки в Битмап желательно
  проверить - существует ли она:
  // if FileExists( ' имя картинки, которую мы хотим загрузить ' ) then
  MyBm.LoadFromFile(...)
  // ведь не исключено, что дурак-пользователь ПЕРЕНЕСЕТ
  "красивые картинки из игры"
  // в свою папку "Мои картинки"

А далее, в обработчике перерисовки ячейки OnCellDraw нашего Стринг-грида рисуем картинки:

  TStringGrid(Sender).Canvas.BrushCopy(Rect,MyBm,Rect(1,1,17,17),clFuch
  sia);
  TStringGrid(Sender).Canvas.CopyRect(Rect,aDynBm[0].Canvas,Rect(1,1,1
  7,17));

Синтаксис процедур BrushCopy и CopyRect изучайте в хелпе, скажу только, что у BrushCopy можно задать прозрачный цвет.

Также, ссылка от Боба на сайт с правилами ролевых игр: http://www.rpg-zone.net/portal/news.php

Кстати, насчет быстрой графики и работы с TImage - я давал чуть раньше ссылку на набор компонентов G32 (g32.org) - он работает в СОТНИ раз быстрее стандартных дельфийских компонентов имаге-имагелист и к тому же гораздо более удобен в работе. Сделал, кстати, российский пацан.

Важно! Первым заметил Артём:

В данной реалихации проверрки прокрутки есть ошибка

    if (abs(Heroes[CurHero].x - GameMap[CurMap].LocalMapLeft) <
    SCROLL_DELTA) or
       (abs(Heroes[CurHero].y - GameMap[CurMap].LocalMapTop) <
    SCROLL_DELTA) then
       ScrollMap;
    end;

при такой реализации поркрутка будет вестись только в случае движения героя влево или вверх( при движении же вниз или вправо перерисовка карты происходить не будет). В данных условиях проверяеться только на уменьшение границы пересечения а на увеличение проверки нет необходимо добавить ещё 2 усовия вот так будет это смотреться

    if (abs(Heroes[CurHero].x - GameMap[CurMap].LocalMapLeft) <
    SCROLL_DELTA) or
       (abs(Heroes[CurHero].y - GameMap[CurMap].LocalMapTop) <
    SCROLL_DELTA) or
       (abs(Heroes[CurHero].x - (GameMap[CurMap].LocalMapLeft +
  LOCAL_MAP_WIDTH)) <
    SCROLL_DELTA) or
       (abs(Heroes[CurHero].y - (GameMap[CurMap].LocalMapTop +
  LOCAL_MAP_HEIGHT)) <
    SCROLL_DELTA) then
       ScrollMap;
    end;

можно использовать другой вариант проверки, но тогда будет необходимо внести некоторые поправки в понимание некоторых констант в настоящий момент константа SCROLL_DELTA описывает границы в которые НЕ МОЖЕТ попадать наш Герой.

    0000000000 0 - область ограниченная константой SCROLL_DELTA
    0000000000 если герой стремиться попасть в неё то вызываеться прокрутка
    0000000000
    000....000 . - Свободная область где может перемещаться герой
    000....000 не вызывая прокрутки
    000....000
    000....000
    0000000000
    0000000000
    0000000000

если же принять что константа SCROLL_DELTA описывает границы в которых ДОЛЖЕН НАХОДИТСЯ Герой, то собственно вид границ будет таким

    .......... 0 - область ограниченная константой SCROLL_DELTA
    .......... в которой ДОЛЖЕН НАХОДИТЬСЯ герой
    ..........
    ...0000... . - Свободная область куда попадая Герой вызывает прокрутку
    ...0000...
    ...0000...
    ...0000...
    ..........
    ..........
    ..........

Тогда проверку можно записать так

    if (abs(Heroes[CurHero].x - (LOCAL_MAP_WIDTH div 2 +
  GameMap[CurMap].LocalMapLeft)) >
    SCROLL_DELTA) or
       (abs(Heroes[CurHero].y - (LOCAL_MAP_HEIGHT div 2 +
  GameMap[CurMap].LocalMapTop)) >
    SCROLL_DELTA) then
       ScrollMap;
    end;

Здесь константа SCROLL_DELTA описывает на сколько "шагов" можно двинуться от центра видимой карты в ту или иную сторону, при выходи из этой зоны вызваеться прокрутка.
Описание алгоритма прверки:
LOCAL_MAP_WIDTH div 2 + GameMap[CurMap].LocalMapLeft - находим центр по оси X
LOCAL_MAP_HEIGHT div 2 + GameMap[CurMap].LocalMapTop - находим центр по оси Y
имея данные вводные довольно легко найти область в которой должен находится герой
берем абсолютное значение разницы между координатами героя и центра локальной карты где он находится. Если данное число превосходить границу значит герой вышел из области в которой должен находиться.
поэтому мы вызываем прокрутку.

Поэтому константу я принимаю равным 2

const SCROLL_DELTA=2;

Во Вложении находиться вариант для Delphi, с собраным модулем CRT для консольного режима (модуль мне пришлось немного подправить, он не мой), пока только без ремарок. Надеюсь в скором будущем всё появиться

Артём, огромное спасибо за письмо и CRT !

Брать этот модуль с остальным кодом Артёма здесь:

http://russianenterprisesolutions.com/sbo/download/LearnRPG.zip 10444 байтов

А ошибку со скроллом кстати я заметил позже, и исправил ее где-то дальше по тексту, посмотрим в следующих выпусках, всплывет она или нет.

Полезные ссылки.

Сайт по технологиям гибкого моделирования софта - http://www.agilemodeling.com/

Гибкие - agile - методики были придуманы в противовес "тяжелым", которые подразумевают явно выделенные и продолжительные этапы формирования требований к проекту, проектирования, после чего техзадание замораживается. Однако в реальности требования заказчика постоянно меняются, а внедрение тяжелых методик типа CMM или RUP (RUP впрочем скорее полуэджил) сам по себе длительный процесс. Наиболее известна пожалуй методика экстремального программирования - http://www.xprogramming.ru/ , а по гибкому моделированию есть сайт на русском http://www.agilemodeling.org.ua/

Правда, в Core Practices на agilemodeling ничего серьезно не говорится о метамоделировании, построении онтологического словаря программной модели, некотором минимуме операционных определений, о стратегиях выявления паттернов, поэтому agile как бы "с другой стороны" пытаются решить проблему нехватки метаинформации за счет динамической адаптации к требованиям стэйкхолдера, однако корешки проблем все равно остаются и торчат из каждой практики.

Также, если вы плохо знаете английский, можно почитать о методологиях разработки здесь: http://www.maxkir.com/

Можно искать в яндексе, только не agile (это для гугля - agile ключевое слово), а гибкая разработка, гибкая технология.

Наверняка немало полезных ссылок с сайтов по экстремальному программированию.

Вот еще несколько англоязычных ресурсов:
www.agilealliance.org
www.agiledata.org

Полупопсовую презентацию на тему управления ИТ-проектами можно найти тут, в разделе Best Practices & Case Studies:

http://www.performanceweb.org/CENTERS/Project_Management/index.htm

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

Почему я заговорил на эту тему? Уверен, подписчикам понравятся современные зарплаты руководителей программных проектов :) Если разработчик - ну от 1000 до 2000 долл, то руководитель проекта уже побольше, вот недавно встретил - 100 тысяч рублей :)

При этом на самом деле программирование достаточно знать на уровне нашего базового курса, или даже немного меньше для такой деятельности.

Эта тема интересна - управление программными проектами? Если да, то будем и ей уделять внимание.

Школа программирования с нуля
Все предыдущие выпуски базового курса тут:
http://russianenterprisesolutions.com/sbo/

Дизайн рассылки: Алексей Голубев - Web-дизайн и web-программирование