Экспертная система Delphi.int.ru

Сообщество программистов
Общение, помощь, обмен опытом

Здравствуйте, уважаемые эксперты!


Не знаю точно в какой раздел задавать...

возникла такая проблема.
пишу приложене для игры... необходимо по навыкам персонажа (сила, интелект, ловксть...(храняться в Label1, Label2...)) выводить подходящие оружия...
думаю сделать БД, туда запихнуть картинки, и необходимые навыки, и в самом приложении делать запрос к БД, проверять навыки, и если прошло--вывести...
какую бд лучше взять(чтоб ее мона было скачать, тобиш мона былобы юзать без инета...) и как туда запихнуть картинку? или лучше просто в бд запихать ссылки на картинки( img1.bmp)...

а хотя может я вообще зря бд беру, может лучше както по другому?

подскажите плззз...

Вопрос задал: kashita (статус: Посетитель) Вопрос отправлен: 26 сентября 2007, 00:16 Состояние вопроса: решён, ответов: 5.

Ответ #1. Отвечает эксперт: PaVeL-Ekt

Здравствуйте, kashita!

Вы можете воспользоваться БД Paradox из стандартных делфовых толсов!
На форму вставляете Query со вкладки DBE в поле DataBaseName указываете папку с файлами парадокса, и делаете запрос типа:

Select * from название_файла_без_расширения

Ответ отправил: PaVeL-Ekt (статус: 2-ой класс) Время отправки: 26 сентября 2007, 08:02 Оценка за ответ: 5

Ответ #2. Отвечает эксперт: Косолапов Дмитрий Юрьевич

Здравствуйте, kashita!

Я думаю, БД для игры далеко не самый лучший вариант, а тем более BDE, без установки которого игра вообще не заработает. Я бы посоветовал все же воспользоваться типизированными файлами. Хотя кодировать работу с ними может оказаться сложнее, чем БД, но зато Ваша программа не "утяжелится" каким-либо движком БД. Что делать с картинками... Я бы их хранил отдельно, то есть либо файлами (в нужных местах указывая путь), а может быть их даже ресурсами в dll сделать.

Ответ отправил: Косолапов Дмитрий Юрьевич (статус: 8-ой класс) Время отправки: 26 сентября 2007, 10:04 Оценка за ответ: 5

Ответ #3. Отвечает эксперт: Вадим К

Здравствуйте, kashita!
Поддерживаю Косолапова Дмитрия Юрьевича. БД вам тут наверно только помешает. Paradox - это очень плохо. Мало того, что БДЕ прийдётся тянуть, так ещё и скорость упадёт.
Обычно делают так.
вначале ресурсы (картинки/музыка) раскладывают по папкам. Дальше пишем класс (набор функций) который по запросу выдаёт загруженную картинку. Зачем так сложно? а просто так вам будет легко подменить юнит с классом и ресурсы будут грузиться например с ресурсной длл.

Ответ отправил: Вадим К (статус: Академик) Время отправки: 26 сентября 2007, 11:18 Оценка за ответ: 5

Ответ #4. Отвечает эксперт: Feniks

Здравствуйте, kashita!
Я согласен с Вадим К и Косолапов Дмитрий Юрьевич. В довесок...
Может стоит подумать в сторону формата XML. Он хорошо рекламируется, имеет стандартизация и широко применяется, например в Офисе, особенно в 2007. Такие файлы структурированы, есть средства стандартные по работе с ними. А так же, в них можно и любые файлы запихивать. Один только минус - файл текстовый и сильно раздуется в размере, но приэтом, его можно зжать.

Ответ отправил: Feniks (статус: Бакалавр) Время отправки: 26 сентября 2007, 17:32 Оценка за ответ: 5

Ответ #5. Отвечает эксперт: Грег Леонов

Здравствуйте, kashita!
Я согласен с Вадим К и Косолапов Дмитрий Юрьевич.
Рекомендую не использовать БД для игр, кроме онлайн.

Есть вариант, использовать класс TList для хранения картинок.
И последующего сброса из на диск, с помощю файловой переменной типа TList. (var f: file of TList;)
Это альтернатива DLL и многочисленных папок с картинками, картинки определенных типов будет храниться в одном файле, другие в другом. По мере необходимости подгружать их в программу.

Никогда так не делал и необходимо проверить данную теорию).

Ответ отправил: Грег Леонов (статус: 1-ый класс) Время отправки: 26 сентября 2007, 22:47 Оценка за ответ: 5

Мини-форум вопроса

Грег Леонов (статус: 1-ый класс), 26 сентября 2007, 22:48 [#1]: Это мой первый ответ на вопрос)))

Вадим К (статус: Академик), 27 сентября 2007, 13:08 [#2]: to Грег Леонов вы чётко понимаете, что означает строка вида var f: file of TList;? (если конечно под TList нонимается стандартный класс) Галочка "подтверждения прочтения" - вселенское зло.

Грег Леонов (статус: 1-ый класс), 27 сентября 2007, 21:31 [#3]: возможно я неверно изложил свои мысли... суть в том чтоб картинки эти и т.п. сложить в TList, как в хранилище. и сохранить все это в файл. var f: file of TList; - файловая переменная типа TList. бывает же var ByteFile: file of byte; конечно могу ошибиться, я писал в ответе об этом.

Косолапов Дмитрий Юрьевич (статус: 8-ой класс), 27 сентября 2007, 22:19 [#4]: Как же можно объект, да еще и такой, как TList в файле сохранить непосредственно? Нет, так дело не пойдет, в лучшем случае в файлах можно записи (record) хранить, и то, без объектных полей. Однако возникла интересная мысль: TImageList можно попробовать применить, и как раз, насколько я помню, он из ресурсов достаточно удобно загружается. Соответственно при описании оружия можно сохранить просто номер картинки.

Грег Леонов (статус: 1-ый класс), 27 сентября 2007, 23:07 [#5]: TImageList пробовал, слишком мелкие там картинки. ан-нет! ща посмотрел внимательно, оказывается(!))) можно их увеличить, в свойствах..., только все будут одного размера.

Грег Леонов (статус: 1-ый класс), 27 сентября 2007, 23:08 [#6]: интересно, что по этому поводу думает магистр Вадим К?

Косолапов Дмитрий Юрьевич (статус: 8-ой класс), 27 сентября 2007, 23:34 [#7]: (Хоть я и не Вадим К, но все же..) Да, все будут одного размера, но для исходной задачи, видимо, это как раз то что нужно - наверняка есть какое-то стандартное окно для отображения параметров и картинки оружия. Так что стандартизация размера только на пользу пойдет, по-моему.

Вадим К (статус: Академик), 28 сентября 2007, 00:47 [#8]: var f: file of TList; - файловая переменная типа TList. За такой код нужно быть линейкой по пальцам. Ибо он сохранит не объекты типа TList, а указатели. Тоесть сохранивши 30 записей, будем иметь файл размера 120 байт (на 32 битных системах - делфи пока компилирует только под такие). К тому TList'у абсолютно вся равно, что там у него сохранено - он оперирует исключительно указателями. Это нужно запомнить. теперь дальше. Но использовать TList всё же можно. Надо только уметь. К нему нужно относиться как к навороченному массиву. Но не больше. По поводу TImageList. Для небольших проектов - самое оно. мало того, он имеет метод Draw. которому только нужно указать канву, координаты и номер изображения и он отрисует его там. Причём этот метод реализован достаточно хорошо. Тоесть отрисовывает быстро. Нельзя хранить картинки разных размеров? а разве это проблема? если у вас в игре есть юниты, то, хотя они и разные, но они имеют какие - то стандартные размеры. Поэтому можно обойтись 3-4 TImageList Стандартный TImageList имеет одну неприятность - он работает только с BMP и ICO. А так бы хотелось других форматов. Особенно привлекает png с его прозрачностью и альфаканалом. И есть решение - используем компонент с поддержкой всего этого плюс он совместим с стандартным. Учитывая, что найти картинки и особенно иконки в png проще, то получается чудно. Сам компонент (точнее пакет) смотреть здесь Галочка "подтверждения прочтения" - вселенское зло.

kashita (статус: Посетитель), 28 сентября 2007, 01:11 [#9]: Всем огромное спасибо!!! подали много идей) очень понравилось с компонентом TImageList, а точнее с его аналогом для png. скачал установил, но тут такая проблема появилась... размешаються на форму все элементы кроме PngImageList, пробую его перетащить на форму - вылетает дельфи.. подскажите я дурак, или как) а еще если с компонентом PngImageList делать, то как лучше осуществить проверки на "навыки"? просто для каждого предмета надо делать от 3 до 15 проверок... и как тогда хранить минимальные требования для каждого элемента..?)

Вадим К (статус: Академик), 28 сентября 2007, 11:23 [#10]: По первому вопросу. Указываем версию делфи, пробуем сделать пример "воспроизведимым". Сам лично не наблюдал с этим компонентом проблем. Второй вопрос. Хранить проверки на навыки. Телепатический модуль подсказывает, что храня там каких то юнитов, вы хотите иметь инфу, связанную с ними. тут наверно поможет следующее. заведите массив структур(а лучше коллекцию классов) с списком юнитов. одним полем структуры(класса) должен быть номерок картинки в ImageList. А в дальшнейшем, может быть и отказаться от сей идеи и хранить картинки прямо как поле класса. Галочка "подтверждения прочтения" - вселенское зло.

31 января 2011, 19:17: Статус вопроса изменён на решённый (изменил модератор Ерёмин А.А.): Автоматическая обработка (2 и более ответов с оценкой 5)

Чтобы оставлять сообщения в мини-форумах, Вы должны авторизироваться на сайте.