БелАмор, ох, БИГ-БИГ, СЕНКС. Ну я могу в принципе исходники сюда поставить. Если вам не жалко будет посмотреть на это жалкое зрелище. 




Присоединённый файл ( Кол-во скачиваний: 4 )
 ________.rar 600,66 Kb

БелАмор, В Close формы тоже стоит MainForm.Show. Если нетрудно просмотрите, пожалуйста, исходники. Буду очень благодарен. Кода там совсем немного, так как я только начал. Как по мне так все работает нормально. Но если у тебя все работает, это еще не значит, что ты святее Папы Римского.   



Присоединённый файл ( Кол-во скачиваний: 6 )
 ________.rar 600,66 Kb

Проект посмотрел, "рецензию" напишу позже.

БелАмор, 

спс, буду ждать.

Там правда почти не реализовано ничего. Разве что выбор пола  и динамическое создание форм. 

Планов громадье. ) Работаю над созданием математической модели боя. Первичная, использованная мной в игрушке на VB была слишком примитивна. Впору писать диздок.

Это сообщение отредактировал(а) PsiMagistr - 11.6.2010, 17:35

На самом деле всё не так уж плохо... Вы избежали очень многих характерных ошибок. В частности, вы очень правильно делаете, формируя в рантайме полный путь к картинкам.



"Спокойствие, только спокойствие!" Я найду, до чего докопаться...

По поводу стиля оформления кода

Настоятельно рекомендую поработать над стилем оформления кода.
В качестве основы я бы рекомендовал статью Стандарт стилевого оформления исходного кода DELPHI
Посмотрите также её обсуждение
Рекомендую, в частности, обратить внимание на сообщение в обсуждении от 15-02-2007 00:37

По поводу пользовательского интерфейса

1. На мой взгляд, достаточно неудачной идеей является использование радиогруппы в форме запуска игры, поскольку любое действие становится двухэтапным, даже просто закрытие формы. Я бы в данном случае использовал обычные кнопки для всех пунктов. Кроме того, надписи на пунктах вводят в заблуждение, поскольку в них речь идёт только о персонаже. На самом деле, речь должна идти о персонаже и запуске игры с ним (поскольку именно так у вас сейчас реализовано). Так что, если что-то менять в рамках заданной вами модели, то в этой форме я бы сделал кнопки (названия условны):

Запуск игры с новым персонажем
Запуск игры с существующим персонажем
Выход

2. Окно с персонажами должно иметь кнопку "Отмена".

3. Запрос на подтверждение выхода в ситуции, когда выход не приводит к потере чего-либо (настроек, игры и т.д.), не имеет смысла и только раздражает.

4. Ситауция, когда после нажатия на что-то, появляется череда окон, каждое из которых является единственным отображаемым, лично мной воспринимается как некомфортная. На мой взгляд, гораздо лучше, когда есть некая "опорная" (она-же главная) форма, которая маячит на заднем плане, а всё, что происходит на переднем плане, относится именно к ней, например, выбор персонажа для игры где? Првильно, на главной форме... Поэтому на мой взгляд, логичнее было бы главной сделать именно форму с игровым полем, а уже там - меню или кнопки "Выбрать персонаж", "Начать новую игру" и т.д. В принципе, вы писали, что у вас есть мысль сделать главной формой именно игровую форму. Мысль вполне здравая. Причём я бы не стал предлагать выбор персонажа при открытии игровой формы. Пусть человек спокойно зайдёт, посмотрит на пустую игровую форму, осмотрится, и уже когда сам захочет, нажмёт кнопку "Начать новую игру" или "Выход".

По поводу алгоритмов и реализации

1. Сейчас у вас реализовано так: из главного меню открывается форма создания/выбора персонажа, а в обработчике закрытия этой формы открывается игровая форма. Это крайне неудачное решение, поскольку при просмотре обработчика главного меню эта логика полностью скрыта. Гораздо логичнее было бы в обработчике главного меню сначала показать форму выбора персонажа, после её закрытия проанализировать код возврата, и если было подтверждение, а не отмена, открыть игровую форму. Но для этого форма выбора персонажа должна отображаться в модальном режиме. Немодальные формы должны применяться только в случаях, когда небходим параллельный доступ к нескольким окнам. В случае окна выбора персонажа такой необходимости нет. Недостатком модального режима является нестандартное поведение при сворачивании, поэтому желательно, чтобы основная рабочая форма не была модальной. Большинство же вспомогательных форм логично делать модальными. Не забудьте у ваших форм в дизайнере вернуть Visible в False.

2. Рекомендации по коду на примере TFrmCreate.RGenderClick
  а) Если имеется несколько блоков кода, различающихся только небольшой частью, логично оставить только один блок, а разичающуюся часть обработать отдельно, возможно, заранее (но не обязательно), а в основном блоке использовать уже вычисленный результат.
  б) Если в коде много раз встречается одинаковая длинная конструкция (GBX.Controls[i] as TPanel), то логично завести отдельную переменную нужного типа, поместить в неё результат и далее использовать только её.
  в) Если один раз проверили тип объекта через оператор is (if GBX.Controls[i] is TPanel), то в дальнейшем нет необходимости использовать приведение типа с проверкой (GBX.Controls[i] as TPanel). Вместо этого логичнее применять приведение типа без проверки (TPanel(GBX.Controls[i])).
  г) При формировании сложных строк удобно использовать функцию Format. Это значительно облегчает воприятие кода.
  д) При формировании длинных строк, различающихся только в одном месте, бывает очень удобна функция IfThen из модуля StrUtil (есть варианты для числовых типов, см. справку). Поскольку при этом вычисляются оба значения, следует использовать эту функцию только для случаев, когда имеются оба готовых значения, в данном случае - литералы.




Это сообщение отредактировал(а) БелАмор - 13.6.2010, 16:21

БелАмор, к сожалению пока не имею возможности повысить Вам репутацию, но сердечно благодарю. Вникаю в Ваш код.

(Плюсик за мной)

Это сообщение отредактировал(а) PsiMagistr - 13.6.2010, 17:00

PsiMagistr, не вопрос

Ребят, немного позорного оффтопа, но не открывать же новую тему из за него.

Скачал Дельфи 2009. (чтоб утечек не было, хочу поставить), но... Можно свою 6-ку не трогать, не удалять с компа? Ибо привык уже. Или конфликты будут?

Поставил на 6ку кучу всевозможных патчей. Думал мож поправит чего. Увы, как текло так и течет. Похоже еще хуже стало. (Проверял Fast MM44 на девственных проектах).

2010 чего то не охота.  Обалденные сис. требования. Я ахнул. Слона они запихнули, что ли?)



Это сообщение отредактировал(а) PsiMagistr - 14.6.2010, 13:42

Конфликтов быть не должно.
В 2010 исправлены многие баги 2009