Конечно, мы не можем рассмотреть каждую неприятность, которая может произойти, но я выделю некоторые общие моменты. Есть два типа Плохих Вещей: случайные и повторяющиеся. Крайне сложно выявить или исправить случайные проблемы, над которыми вы не имеете никакого контроля, и не знаете когда они происходят, а когда нет. Однако, когда проблема повторяется "когда я на третьем уровне и нажимаю два раза стрелку влево", то можно что-нибудь сделать.
Читайте гр*баную инструкцию. Инструкция может принимать одну из нескольких форм. С open source играми поставляются файлы readme. К коммерческим играм прилагается книжка с инструкцией и, может быть, какие-нибудь файлы readme на CD. Не забудьте о вэб-сайте игры. Возможно, автор много раз сталкивался с людьми, у которых возникла такая же проблема, и выложил на сайте соответствующую информацию. Хорошим примером может служить Loki Software с их online FAQs.
Если вы ненавидите ЧГИ, по крайней мере заимейте привычку пользоваться grep, вместо того, чтобы не заниматься ЧГИ вообще. Так, если ваша игра некорректно работает с сетью, вы всегда можете сделать "grep network *". Это лучше, чем вообще не смотреть на ГИ. Но все же надо попытаться прочитать инструкцию; люди, которые хотят все получать на блюдечке с голубой каемочкой, должны использовать продукты Microsoft, а не Linux.
Если это open source игра, которую вы сами откомпилировали, сходите на сайт игры и убедитесь, что у вас самая свежая версия. Если игра входит в дистрибутив, проверьте, не выпустил-ли его разработчик обновленный пакет rpm или deb для этой игры.
Разработчики коммерческих игр, такие как Loki, выпускают для своих игр патчи. Зачастую, игра имеет МНОГО патчей (Myth2), а некоторые без патчей доставляют определенные проблемы (Heretic2). Вы должны проверять сайт на наличие патчей вне зависимости от того, имеются у вас сейчас проблемы с игрой, или нет!
Кстати, у Loki теперь есть специальная утилита, которая ищет на вашем винчестере игры их производства и автоматически их обновляет. Спасибо им большое, это была отличная идея! Посмотрите на http://updates.lokigames.com.
Если вы не знаете что такое netnews/newsgroups/nntp/usenet, то вам определенно стоит потратить 30 минут времени, чтобы узнать об этом. Установите программу для чтения новостей. Я предпочитаю консольные инструменты, поэтому использую tin, однако slrn тоже популярен. В Netscape также есть отличная графическая программа для этого.
К примеру, так можно подключиться к серверу новостей Loki:
* tin -g news.lokigames.com
* Большинство программ для чтения новостей будут соединяться с сервером, адрес которого содержится в переменной окружения NNTPSERVER. Вы можете установить ее командой:
NNTPSERVER=news.lokigames.com tin -r
* Большинство программ также заглядывает в файл /etc/nntpserver в поисках адреса сервера новостей.
Все, что отправляется в usenet, архивируется на этом сайте. Раньше архив назывался deja (www.deja.com), но потом он был куплен google. Большинство людей все еще знают его как deja, поэтому я буду использовать это название.
Вы не являетесь настоящим пользователем Linux, пока вы не используете deja для решения своих проблем. В подавляющем большинстве случаев, вопрос о вашей проблеме (относящейся к играм или нет) уже появлялся на deja. Более того, наверняка уже был дан ответ на него. И не однажды, не дважды, а много раз. Если вам не понятен первый из ответов на ваш ворос (или он не помог), скорее всего вы получите и другие. Deja должен стать одним из ваших рефлексов на любую проблему.
Отправляйтесь на
<url url="http://groups.google.com/advanced_group_search" name="">
Все очень просто. К примеру, если моя проблема в том, что Quake III падает всякий раз когда Lucy прыгает, я бы ввел в строке "Find messages with all of the words" следующее:
linux quake3 crash lucy jumps
или если вы не можете заставить работать звук в Unreal Tournament:
linux UT sound problem
Вы можете включить в поиск название своей звуковой карты. Есть поля, позволяющие ограничить поиск определенными группами новостей. Выделите время, прочитайте и разберитесь, что обозначает каждое из них. Обещаю, этот сервис вас не разочарует. Используйте его и вы станете гораздо счастливее.
Это отличается от того, что вы делали бы с коммерческой игрой. В случае игр с открытыми исходниками вы можете помочь автору, предоставив ему файл core или stack trace. В двух словах, core (он же core dump) -- это файл, содержащий "состояние" программы на момент сбоя. Он содержит полезную для программиста информацию о природе сбоя -- что стало причиной и что делала программа, когда это произошло. Если вы хотите побольше узнать о файлах core, у меня есть отличный gdb tutorial по адресу .
В *крайнем* случае автор заинтересуется содержимым стека на момент крушения.
Вот как вы можете получить его.Иногда дистрибутивы настроены так, чтобы файлы core (которые предназначены только для программистов) не создавались. Либо создавались, но только определенной длины. Первый шаг -- сделать так, чтобы система разрешила создание
файлов core любой длины.
ulimit -c unlimited
Теперь вы должны перекомпилировать программу и передать gcc опцию -g (объяснение этого лежит за рамками данного документа). Теперь запустите игру и сделайте то, что приводит программу к сбою и очередной генерации core.
Запуститие отладчик с файлом core в качестве второго аргумента:
gdb CoolGameExecutable core
А после приглашения (gdb) введите "backtrace". Вы увидите что-то типа:
#0 printf (format=0x80484a4 "z is %d.
<equation>
<alt>$\backslash $
<math>
<mtable>
<mtr><mi> backslash
n") at printf.c:30
#1 0x8048431 in display (z=5) at try1.c:11
#2 0x8048406 in main () at try1.c:6
Это может быть долго, но все же, при помощи мыши скопируйте эту информацию в файл. Напишите автору письмо, в котором сообщите:
Если у вас широкий канал в Интернет, спросите автора не хочет-ли он получить файл core, созданный программой. Если он захочет, отправьте. Не забудьте сначала спросить, так как файлы core могут быть очень, очень большими.
Если в игре есть сохранение текущего состояния, то отправка автору отложенной игры очень важна, так как это позволит ему воспроизвести у себя проблему. Для коммерческих игр это более полезно, чем отправка файла core или стека, потому что они не могут быть перекомпилированы для включения отладочной информации.
Опять же, стоит сначала спросить нужно-ли это, а уже потом отправлять, так как эти файлы обычно велики; но такая компания как Loki имеет достаточно широкий канал. Mike Phillips из Loki Software напоминает, что отправка отложенных игр -- это хорошая идея.
Стоит-ли добавлять, что все это имеет смысл проделывать лишь в том случае, если игра постоянно падает в определенной месте. Если же игра сбоит каждый раз, когда вы ее запускаете, или работает крайне медленно, файл с отложенной игрой ничем особенно помочь не поможет.
Иногда вы можете видеть сообщение об ошибке, указывающее на то, что не был найден файл. Файл может быть библиотекой:
% ./exult ./exult: error while loading shared libraries: libSDL-1.2.so.0: cannot load shared object file: No such file or directory или разновидностью файла с данными, таким как wad или map: % qf-client-sdl IP address 192.168.0.2:27001 UDP Initialized Error: W_LoadWadFile: couldn't load gfx.wad
Предположим, что gfx.wad уже есть в системе, но не может быть найден, потому что находится не в том каталоге, в котором должен находиться. Тогда ГДЕ же он должен лежать? Не будет-ли полезно узнать где именно программа его ищет? Это то, в чем блистает strace. strace говорит вам какие системные вызовы были сделаны, с какими аргументами и каковы были возвращенные значения. В моей книге
`Kernel Module Programming Guide' (скоро выйдет в рамках LDP) я выделил все,
что вы хотели бы знать о starce. Но вот краткая выдержка с использованием
канонического примера того, что же из себя представляет strace.
Введите команду:
strace -o ./LS_LOG /bin/ls
Опция -o направляет вывод strace в файл; здесь -- в LS_LOG. Последний аргумент
-- проверяемая программа, здесь -- "ls". Посмотрите на содержимое LS_LOG
Весьма впечатляет, да? Вот типичная строка:
open(".", O_RDONLY|O_NONBLOCK|0x18000) = 4
Мы использовали системный вызов open(), чтобы открыть "." с различными
аргументами и было возвращено значение "4". Что он будет делать с файлами,
которые не может найти?
Предположим, я хочу посмотреть демо StateOfMind, потому что оно мне никогда не
надоедает. Я пытаюсь его запустить и происходит что-то нехорошее:
% ./mind.i86_linux.glibc2.1
Loading & massaging...
Error:Can't open data file 'mind.dat'.
Давайте используем strace, чтобы выяснить где именно программа искала этот
файл.
strace ./mind.i86_linux.glibc2.1 2> ./StateOfMind_LOG
Запустив vim (потому что он крут) и включив поиск всех вхождений "mind.dat", я
обнаружил следующие строки:
open("/usr/share/mind.dat",O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "Error:", 6Error:) = 6
write(2, "Can $\backslash $ backslash 't open data file $\backslash $ backslash 'mind.dat $\backslash $ backslash '."..., ) = 33
Мы видим, что он искал mind.dat только в одном каталоге. Ясно, что mind.dat не
в /usr/share. Теперь мы можем найти mind.dat (locate maind.dat) и переместить
его в /usr/share.
Этот метод работает также и для библиотек. Предположим, библиотека libmp3.so.2
находится в /usr/local/include, но ваша новая игра "Kill-Metallica" не может ее
найти. Вы можете использовать strace, чтобы определить где же Kill-Metallica
искала библиотеку и создать в этом каталоге символическую ссылку на
/usr/local/include/libmp3.so.2.
strace -- очень мощная утилита. Когда разбираешься почему что-то не было
найдено, это ваш лучший союзник, это даже быстрее, чем поиск в исходниках.
Последнее замечание: вы не можете искать информацию в исходниках коммерческих
игр от Lokisoft или Tribsoft. Однако, вы все же можете использовать с ними strace!