• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            不會飛的鳥

            2010年12月10日 ... 不鳥他們!!! 我要用自己開發(fā)的分布式文件系統(tǒng)、分布式調度系統(tǒng)、分布式檢索系統(tǒng), 做自己的搜索引擎!!!大魚有大志!!! ---楊書童

            #

            [linux]ld.so.conf 和 ldconfig

            今天重新編譯以前的一個程序,里面用到iconv庫:gcc test.cc -liconv
            運行時:a.out:error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory
            以前編譯運行是可以的,可能是不久前升級了iconv庫影響。在/usr/local/lib下可以找到libiconv.so.2,把/usr/local/lib加到路徑中也不行。
            google了一下,解決了:在/etc/ld.so.conf中加一行/usr/local/lib,運行l(wèi)dconfig。再運行a.out,行了。
            ld.so.conf和ldconfig是維護系統(tǒng)動態(tài)鏈接庫的。真不明白為什么iconv庫安裝時不把這一步也做了。



            //注意
            如果你不是root,ldconfig也運行不了的,解決的方法就是,設置環(huán)境變量 LDFLAGS=-L/usr/local/lib

            posted @ 2009-09-24 12:46 不會飛的鳥 閱讀(481) | 評論 (0)編輯 收藏

            例解 autoconf 和 automake 生成 Makefile 文件

            本文介紹了在 linux 系統(tǒng)中,通過 Gnu autoconf 和 automake 生成 Makefile 的方法。主要探討了生成 Makefile 的來龍去脈及其機理,接著詳細介紹了配置 Configure.in 的方法及其規(guī)則。

            引子

            無論是在Linux還是在Unix環(huán)境中,make都是一個非常重要的編譯命令。不管是自己進行項目開發(fā)還是安裝應用軟件,我們都經常要用到make或 make install。利用make工具,我們可以將大型的開發(fā)項目分解成為多個更易于管理的模塊,對于一個包括幾百個源文件的應用程序,使用make和 makefile工具就可以輕而易舉的理順各個源文件之間紛繁復雜的相互關系。

            但是如果通過查閱make的幫助文檔來手工編寫Makefile,對任何程序員都是一場挑戰(zhàn)。幸而有GNU 提供的Autoconf及Automake這兩套工具使得編寫makefile不再是一個難題。

            本文將介紹如何利用 GNU Autoconf 及 Automake 這兩套工具來協助我們自動產生 Makefile文件,并且讓開發(fā)出來的軟件可以像大多數源碼包那樣,只需"./configure", "make","make install" 就可以把程序安裝到系統(tǒng)中。





            回頁首


            模擬需求

            假設源文件按如下目錄存放,如圖1所示,運用autoconf和automake生成makefile文件。


            圖 1文件目錄結構
            圖 1文件目錄結構

            假設src是我們源文件目錄,include目錄存放其他庫的頭文件,lib目錄存放用到的庫文件,然后開始按模塊存放,每個模塊都有一個對應的目錄,模塊下再分子模塊,如apple、orange。每個子目錄下又分core,include,shell三個目錄,其中core和shell目錄存放.c文件,include的存放.h文件,其他類似。

            樣例程序功能:基于多線程的數據讀寫保護(聯系作者獲取整個autoconf和automake生成的Makefile工程和源碼,E-mail:normalnotebook@126.com)。





            回頁首


            工具簡介

            所必須的軟件:autoconf/automake/m4/perl/libtool(其中l(wèi)ibtool非必須)。

            autoconf是一個用于生成可以自動地配置軟件源碼包,用以適應多種UNIX類系統(tǒng)的shell腳本工具,其中autoconf需要用到 m4,便于生成腳本。automake是一個從Makefile.am文件自動生成Makefile.in的工具。為了生成Makefile.in,automake還需用到perl,由于automake創(chuàng)建的發(fā)布完全遵循GNU標準,所以在創(chuàng)建中不需要perl。libtool是一款方便生成各種程序庫的工具。

            目前automake支持三種目錄層次:flat、shallow和deep。

            1) flat指的是所有文件都位于同一個目錄中。

            就是所有源文件、頭文件以及其他庫文件都位于當前目錄中,且沒有子目錄。Termutils就是這一類。

            2) shallow指的是主要的源代碼都儲存在頂層目錄,其他各個部分則儲存在子目錄中。

            就是主要源文件在當前目錄中,而其它一些實現各部分功能的源文件位于各自不同的目錄。automake本身就是這一類。

            3) deep指的是所有源代碼都被儲存在子目錄中;頂層目錄主要包含配置信息。

            就是所有源文件及自己寫的頭文件位于當前目錄的一個子目錄中,而當前目錄里沒有任何源文件。 GNU cpio和GNU tar就是這一類。

            flat類型是最簡單的,deep類型是最復雜的。不難看出,我們的模擬需求正是基于第三類deep型,也就是說我們要做挑戰(zhàn)性的事情:)。注:我們的測試程序是基于多線程的簡單程序。





            回頁首


            生成 Makefile 的來龍去脈

            首先進入 project 目錄,在該目錄下運行一系列命令,創(chuàng)建和修改幾個文件,就可以生成符合該平臺的Makefile文件,操作過程如下:

            1) 運行autoscan命令

            2) 將configure.scan 文件重命名為configure.in,并修改configure.in文件

            3) 在project目錄下新建Makefile.am文件,并在core和shell目錄下也新建makefile.am文件

            4) 在project目錄下新建NEWS、 README、 ChangeLog 、AUTHORS文件

            5) 將/usr/share/automake-1.X/目錄下的depcomp和complie文件拷貝到本目錄下

            6) 運行aclocal命令

            7) 運行autoconf命令

            8) 運行automake -a命令

            9) 運行./confiugre腳本

            可以通過圖2看出產生Makefile的流程,如圖所示:


            圖 2生成Makefile流程圖
            圖 2生成Makefile流程圖




            回頁首


            Configure.in的八股文

            當我們利用autoscan工具生成confiugre.scan文件時,我們需要將confiugre.scan重命名為confiugre.in文件。confiugre.in調用一系列autoconf宏來測試程序需要的或用到的特性是否存在,以及這些特性的功能。

            下面我們就來目睹一下confiugre.scan的廬山真面目:


            # Process this file with autoconf to produce a configure script.
                        AC_PREREQ(2.59)
                        AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
                        AC_CONFIG_SRCDIR([config.h.in])
                        AC_CONFIG_HEADER([config.h])
                        # Checks for programs.
                        AC_PROG_CC
                        # Checks for libraries.
                        # FIXME: Replace `main' with a function in `-lpthread':
                        AC_CHECK_LIB([pthread], [main])
                        # Checks for header files.
                        # Checks for typedefs, structures, and compiler characteristics.
                        # Checks for library functions.
                        AC_OUTPUT
                        

            每個configure.scan文件都是以AC_INIT開頭,以AC_OUTPUT結束。我們不難從文件中看出confiugre.in文件的一般布局:


            AC_INIT
                        測試程序
                        測試函數庫
                        測試頭文件
                        測試類型定義
                        測試結構
                        測試編譯器特性
                        測試庫函數
                        測試系統(tǒng)調用
                        AC_OUTPUT
                        

            上面的調用次序只是建議性質的,但我們還是強烈建議不要隨意改變對宏調用的次序。

            現在就開始修改該文件:


            $mv configure.scan configure.in
                        $vim configure.in
                        

            修改后的結果如下:


                        #                                -*- Autoconf -*-
                        # Process this file with autoconf to produce a configure script.
                        AC_PREREQ(2.59)
                        AC_INIT(test, 1.0, normalnotebook@126.com)
                        AC_CONFIG_SRCDIR([src/ModuleA/apple/core/test.c])
                        AM_CONFIG_HEADER(config.h)
                        AM_INIT_AUTOMAKE(test,1.0)
                        # Checks for programs.
                        AC_PROG_CC
                        # Checks for libraries.
                        # FIXME: Replace `main' with a function in `-lpthread':
                        AC_CHECK_LIB([pthread], [pthread_rwlock_init])
                        AC_PROG_RANLIB
                        # Checks for header files.
                        # Checks for typedefs, structures, and compiler characteristics.
                        # Checks for library functions.
                        AC_OUTPUT([Makefile
                        src/lib/Makefile
                        src/ModuleA/apple/core/Makefile
                        src/ModuleA/apple/shell/Makefile
                        ])
                        

            其中要將AC_CONFIG_HEADER([config.h])修改為:AM_CONFIG_HEADER(config.h), 并加入AM_INIT_AUTOMAKE(test,1.0)。由于我們的測試程序是基于多線程的程序,所以要加入AC_PROG_RANLIB,不然運行automake命令時會出錯。在AC_OUTPUT輸入要創(chuàng)建的Makefile文件名。

            由于我們在程序中使用了讀寫鎖,所以需要對庫文件進行檢查,即AC_CHECK_LIB([pthread], [main]),該宏的含義如下:



            其中,LIBS是link的一個選項,詳細請參看后續(xù)的Makefile文件。由于我們在程序中使用了讀寫鎖,所以我們測試pthread庫中是否存在pthread_rwlock_init函數。

            由于我們是基于deep類型來創(chuàng)建makefile文件,所以我們需要在四處創(chuàng)建Makefile文件。即:project目錄下,lib目錄下,core和shell目錄下。

            Autoconf提供了很多內置宏來做相關的檢測,限于篇幅關系,我們在這里對其他宏不做詳細的解釋,具體請參看參考文獻1和參考文獻2,也可參看autoconf信息頁。





            回頁首


            實戰(zhàn)Makefile.am

            Makefile.am是一種比Makefile更高層次的規(guī)則。只需指定要生成什么目標,它由什么源文件生成,要安裝到什么目錄等構成。

            表一列出了可執(zhí)行文件、靜態(tài)庫、頭文件和數據文件,四種書寫Makefile.am文件個一般格式。


            表 1Makefile.am一般格式
            表 1Makefile.am一般格式

            對于可執(zhí)行文件和靜態(tài)庫類型,如果只想編譯,不想安裝到系統(tǒng)中,可以用noinst_PROGRAMS代替bin_PROGRAMS,noinst_LIBRARIES代替lib_LIBRARIES。

            Makefile.am還提供了一些全局變量供所有的目標體使用:


            表 2 Makefile.am中可用的全局變量
            表 2 Makefile.am中可用的全局變量

            在Makefile.am中盡量使用相對路徑,系統(tǒng)預定義了兩個基本路徑:


            表 3Makefile.am中可用的路徑變量
            表 3Makefile.am中可用的路徑變量

            在上文中我們提到過安裝路徑,automake設置了默認的安裝路徑:

            1) 標準安裝路徑

            默認安裝路徑為:$(prefix) = /usr/local,可以通過./configure --prefix=<new_path>的方法來覆蓋。

            其它的預定義目錄還包括:bindir = $(prefix)/bin, libdir = $(prefix)/lib, datadir = $(prefix)/share, sysconfdir = $(prefix)/etc等等。

            2) 定義一個新的安裝路徑

            比如test, 可定義testdir = $(prefix)/test, 然后test_DATA =test1 test2,則test1,test2會作為數據文件安裝到$(prefix)/ /test目錄下。

            我們首先需要在工程頂層目錄下(即project/)創(chuàng)建一個Makefile.am來指明包含的子目錄:


            SUBDIRS=src/lib src/ModuleA/apple/shell src/ModuleA/apple/core
                        CURRENTPATH=$(shell /bin/pwd)
                        INCLUDES=-I$(CURRENTPATH)/src/include -I$(CURRENTPATH)/src/ModuleA/apple/include
                        export INCLUDES
                        

            由于每個源文件都會用到相同的頭文件,所以我們在最頂層的Makefile.am中包含了編譯源文件時所用到的頭文件,并導出,見藍色部分代碼。

            我們將lib目錄下的swap.c文件編譯成libswap.a文件,被apple/shell/apple.c文件調用,那么lib目錄下的Makefile.am如下所示:


            noinst_LIBRARIES=libswap.a
                        libswap_a_SOURCES=swap.c
                        INCLUDES=-I$(top_srcdir)/src/includ
                        

            細心的讀者可能就會問:怎么表1中給出的是bin_LIBRARIES,而這里是noinst_LIBRARIES?這是因為如果只想編譯,而不想安裝到系統(tǒng)中,就用noinst_LIBRARIES代替bin_LIBRARIES,對于可執(zhí)行文件就用noinst_PROGRAMS代替bin_PROGRAMS。對于安裝的情況,庫將會安裝到$(prefix)/lib目錄下,可執(zhí)行文件將會安裝到${prefix}/bin。如果想安裝該庫,則Makefile.am示例如下:


            bin_LIBRARIES=libswap.a
                        libswap_a_SOURCES=swap.c
                        INCLUDES=-I$(top_srcdir)/src/include
                        swapincludedir=$(includedir)/swap
                        swapinclude_HEADERS=$(top_srcdir)/src/include/swap.h
                        

            最后兩行的意思是將swap.h安裝到${prefix}/include /swap目錄下。

            接下來,對于可執(zhí)行文件類型的情況,我們將討論如何寫Makefile.am?對于編譯apple/core目錄下的文件,我們寫成的Makefile.am如下所示:


            noinst_PROGRAMS=test
                        test_SOURCES=test.c
                        test_LDADD=$(top_srcdir)/src/ModuleA/apple/shell/apple.o $(top_srcdir)/src/lib/libswap.a
                        test_LDFLAGS=-D_GNU_SOURCE
                        DEFS+=-D_GNU_SOURCE
                        #LIBS=-lpthread
                        

            由于我們的test.c文件在鏈接時,需要apple.o和libswap.a文件,所以我們需要在test_LDADD中包含這兩個文件。對于Linux下的信號量/讀寫鎖文件進行編譯,需要在編譯選項中指明-D_GNU_SOURCE。所以在test_LDFLAGS中指明。而test_LDFLAGS只是鏈接時的選項,編譯時同樣需要指明該選項,所以需要DEFS來指明編譯選項,由于DEFS已經有初始值,所以這里用+=的形式指明。從這里可以看出,Makefile.am中的語法與Makefile的語法一致,也可以采用條件表達式。如果你的程序還包含其他的庫,除了用AC_CHECK_LIB宏來指明外,還可以用LIBS來指明。

            如果你只想編譯某一個文件,那么Makefile.am如何寫呢?這個文件也很簡單,寫法跟可執(zhí)行文件的差不多,如下例所示:


            noinst_PROGRAMS=apple
                        apple_SOURCES=apple.c
                        DEFS+=-D_GNU_SOURCE
                        

            我們這里只是欺騙automake,假裝要生成apple文件,讓它為我們生成依賴關系和執(zhí)行命令。所以當你運行完automake命令后,然后修改apple/shell/下的Makefile.in文件,直接將LINK語句刪除,即:


            …….
                        clean-noinstPROGRAMS:
                        -test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS)
                        apple$(EXEEXT): $(apple_OBJECTS) $(apple_DEPENDENCIES)
                        @rm -f apple$(EXEEXT)
                        #$(LINK) $(apple_LDFLAGS) $(apple_OBJECTS) $(apple_LDADD) $(LIBS)
                        …….
                        

            通過上述處理,就可以達到我們的目的。從圖1中不難看出為什么要修改Makefile.in的原因,而不是修改其他的文件。

            posted @ 2009-06-21 16:25 不會飛的鳥 閱讀(232) | 評論 (0)編輯 收藏

            實戰(zhàn)Makefile.am

            實戰(zhàn)Makefile.am

            Makefile.am是一種比Makefile更高層次的規(guī)則。只需指定要生成什么目標,它由什么源文件生成,要安裝到什么目錄等構成。

            表一列出了可執(zhí)行文件、靜態(tài)庫、頭文件和數據文件,四種書寫Makefile.am文件個一般格式。


            表 1Makefile.am一般格式


             

            對于可執(zhí)行文件和靜態(tài)庫類型,如果只想編譯,不想安裝到系統(tǒng)中,可以用noinst_PROGRAMS代替bin_PROGRAMS,noinst_LIBRARIES代替lib_LIBRARIES。

            Makefile.am還提供了一些全局變量供所有的目標體使用:

            表 2 Makefile.am中可用的全局變量

            在Makefile.am中盡量使用相對路徑,系統(tǒng)預定義了兩個基本路徑:

            表 3Makefile.am中可用的路徑變量

            在上文中我們提到過安裝路徑,automake設置了默認的安裝路徑:

            1)標準安裝路徑

            默認安裝路徑為:$(prefix) = /usr/local,可以通過./configure --prefix=<new_path>的方法來覆蓋。

            其它的預定義目錄還包括:bindir = $(prefix)/bin, libdir = $(prefix)/lib, datadir = $(prefix)/share, sysconfdir = $(prefix)/etc等等。

            2) 定義一個新的安裝路徑

            比如test, 可定義testdir = $(prefix)/test, 然后test_DATA =test1 test2,則test1,test2會作為數據文件安裝到$(prefix)/ /test目錄下。

            我們首先需要在工程頂層目錄下(即project/)創(chuàng)建一個Makefile.am來指明包含的子目錄:

            SUBDIRS=src/lib src/ModuleA/apple/shell src/ModuleA/apple/core

            CURRENTPATH=$(shell /bin/pwd)

            INCLUDES=-I$(CURRENTPATH)/src/include -I$(CURRENTPATH)/src/ModuleA/apple/include

            export INCLUDES

            由于每個源文件都會用到相同的頭文件,所以我們在最頂層的Makefile.am中包含了編譯源文件時所用到的頭文件,并導出,見藍色部分代碼。

            我們將lib目錄下的swap.c文件編譯成libswap.a文件,被apple/shell/apple.c文件調用,那么lib目錄下的Makefile.am如下所示:

            noinst_LIBRARIES=libswap.a

            libswap_a_SOURCES=swap.c

            INCLUDES=-I$(top_srcdir)/src/includ

            細心的讀者可能就會問:怎么表1中給出的是bin_LIBRARIES,而這里是noinst_LIBRARIES?這是因為如果只想編譯,而不想安裝到系統(tǒng)中,就用noinst_LIBRARIES代替bin_LIBRARIES,對于可執(zhí)行文件就用noinst_PROGRAMS代替bin_PROGRAMS。對于安裝的情況,庫將會安裝到$(prefix)/lib目錄下,可執(zhí)行文件將會安裝到${prefix}/bin。如果想安裝該庫,則Makefile.am示例如下:

            bin_LIBRARIES=libswap.a

            libswap_a_SOURCES=swap.c

            INCLUDES=-I$(top_srcdir)/src/include

            swapincludedir=$(includedir)/swap

            swapinclude_HEADERS=$(top_srcdir)/src/include/swap.h

            最后兩行的意思是將swap.h安裝到${prefix}/include /swap目錄下。

            接下來,對于可執(zhí)行文件類型的情況,我們將討論如何寫Makefile.am?對于編譯apple/core目錄下的文件,我們寫成的Makefile.am如下所示:

            noinst_PROGRAMS=test

            test_SOURCES=test.c

            test_LDADD=$(top_srcdir)/src/ModuleA/apple/shell/apple.o $(top_srcdir)/src/lib/libswap.a

            test_LDFLAGS=-D_GNU_SOURCE

            DEFS+=-D_GNU_SOURCE

            #LIBS=-lpthread

            由于我們的test.c文件在鏈接時,需要apple.o和libswap.a文件,所以我們需要在test_LDADD中包含這兩個文件。對于Linux下的信號量/讀寫鎖文件進行編譯,需要在編譯選項中指明-D_GNU_SOURCE。所以在test_LDFLAGS中指明。而test_LDFLAGS只是鏈接時的選項,編譯時同樣需要指明該選項,所以需要DEFS來指明編譯選項,由于DEFS已經有初始值,所以這里用+=的形式指明。從這里可以看出,Makefile.am中的語法與Makefile的語法一致,也可以采用條件表達式。如果你的程序還包含其他的庫,除了用AC_CHECK_LIB宏來指明外,還可以用LIBS來指明。

            如果你只想編譯某一個文件,那么Makefile.am如何寫呢?這個文件也很簡單,寫法跟可執(zhí)行文件的差不多,如下例所示:

            noinst_PROGRAMS=apple

            apple_SOURCES=apple.c

            DEFS+=-D_GNU_SOURCE

            我們這里只是欺騙automake,假裝要生成apple文件,讓它為我們生成依賴關系和執(zhí)行命令。所以當你運行完automake命令后,然后修改apple/shell/下的Makefile.in文件,直接將LINK語句刪除,即:

            …….

            clean-noinstPROGRAMS:

                -test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS)

            apple$(EXEEXT): $(apple_OBJECTS) $(apple_DEPENDENCIES)

                @rm -f apple$(EXEEXT)

            #$(LINK) $(apple_LDFLAGS) $(apple_OBJECTS) $(apple_LDADD) $(LIBS)

            …….

            posted @ 2009-06-21 16:19 不會飛的鳥 閱讀(880) | 評論 (0)編輯 收藏

            帶你輕松接觸PowerDesigner中的反向工程

            Power Designer是Sybase公司的CASE工具集,使用它可以方便地對管理信息系統(tǒng)進行分析設計,它幾乎包括了數據庫模型設計的全過程。利用Power Designer可以制作數據流程圖、概念數據模型、物理數據模型,可以生成多種客戶端開發(fā)工具的應用程序,還可為數據倉庫制作結構模型,也能對團隊設計模型進行控制。

            Power Designer的4種模型:概念數據模型 (CDM)物理數據模型 (PDM) 面向對象模型 (OOM) 業(yè)務程序模型 (BPM) 我主要介紹一下PDM。

            PDM 敘述數據庫的物理實現,幫助你考慮真實的物理實現的細節(jié)。你能通過修正PDM來適合你的表現或物理約束。主要目的是把CDM中建立的現實世界模型生成特定的DBMS腳本,產生數據庫中保存信息的儲存結構,保證數據在數據庫中的完整性和一致性。

            PDM是適合于系統(tǒng)設計階段的工具。簡單說:就是PDM可以自動生成諸如''create table''之類的sql腳本.在數據建模過程中,我們建立概念數據模型,通過正向工程生成物理數據模型,生成數據庫建庫腳本,最后將物理數據模型生成關系數據庫。

            系統(tǒng)數據庫設計人員希望能夠將數據庫設計和關系數據庫生成無縫地集成起來,如何保證物理數據模型與其對應數據庫之間的雙向同步成為數據建模非常關鍵的一點。

            Powerdesigner作為強大的Case工具,為我們提供了方便的逆向工程特性。可以將目前所有流行的后端數據庫(包括Sybase、DB2、Oracle等)的結構信息通過逆向工程加入到PowerDesigner的物理數據模型和概念數據模型中,包括表、索引、觸發(fā)器、視圖等。

            用PowerDesigner進行逆向工程

            ◆1.我用的數據庫是oracle9i,我為了訪問oracle數據庫,在我的機器上安裝了oracle客戶端(提供了oracle客戶端的驅動程序,而精簡客戶端則不可以),配置一個名稱為mylcl的服務:MYLCL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.3.106)(PORT = 1521)) ) (CONNECT_DATA = (SID = pwsc) ) )用戶名為:testuser,密碼為test。

            ◆2.在pd中,新建一個pdm,選擇數據庫為oracle9i。

            ◆3.選擇Database->configure connections,轉到system dsn標簽,點擊"添加",選擇驅動程序,由于我的數據庫是oracle,所以我選擇"oracle in oraclient10g_home1"(安裝了oracle客戶端才有這個驅動,而精簡客戶端沒有此驅動)。

            ◆4.在data source name 中,可以隨便命名一個"ora-test",在tns-server name中選擇第一步中的服務名稱:mylcl.點擊"test connection",輸入用戶名密碼,connection ok!

            ◆5.點擊database->reverse engineer database ,選擇odbc datasource:ora-test.然后點擊確定。(責任編輯:盧兆林)

            posted @ 2009-05-28 06:44 不會飛的鳥 閱讀(914) | 評論 (0)編輯 收藏

            linux c 一個autotools的最簡單例子

                 摘要:   1、準備:        需要工具autoscan aclocal autoheader automake autoconf make 等工具.  2、測試程序編寫:         &...  閱讀全文

            posted @ 2009-05-14 17:31 不會飛的鳥 閱讀(2030) | 評論 (1)編輯 收藏

            游戲引擎基礎(十一)(最后的章節(jié))

                 摘要: 第11部份: 最后的章節(jié)前端  你已經看到了菜單系統(tǒng),你可能理解游戲內的頭頂顯示(HUDs)時常是游戲經歷中被忽視和誹謗的部分。最近,這個領域開始被給人印象非常深刻的Black and White所關注,這款游戲實際上沒有HUD。在Peter Molyneux經歷了Dungeon Keeper以后,它在屏幕上大量的圖標,他決定游戲的大部分被這些圖標占用了,主要的屏幕沒有被足夠利用。因此他決定廢除所...  閱讀全文

            夢在天涯 2007-12-04 13:31 發(fā)表評論

            posted @ 2009-04-10 10:44 不會飛的鳥 閱讀(77) | 評論 (0)編輯 收藏

            游戲引擎基礎(十)(人工智能和導航)

            10部分: 人工智能和導航(路徑發(fā)現)


            人工智能(AI
              我們上面已經用了其他九個章節(jié)介紹了游戲引擎,現在讓我們深入到非常有趣和重要的人工智能主題。人工智能如今正在變成被談論得最多的僅次于游戲引擎渲染能力的游戲開發(fā)領域之一,確實如此。直到大約兩年半以前,游戲似乎主要是在考慮你能夠渲染多少個多邊形,眼睛是多么的漂亮,和勞拉的胸部是多么的有彈性...既然我們現在已經能夠渲染出非常真實的乳房,中心就開始轉移到我們實際上用那些多邊形做什么了(即玩游戲)。因為它給你提供實際玩游戲的刺激作用和參與游戲世界中正在進行的事情,所以人工智能在這個領域非常關鍵。

              人工智能包括了全部的東西,從在Tetris中決定哪一塊新磚頭掉落(這很大程度上知識一個隨即數產生器), 一直到創(chuàng)造基于小組的策略游戲,這些游戲和你交互,并且實際上在你玩的時候向你學習。人工智能包含了許多規(guī)則,如果你(作為一個游戲開發(fā)者)沒有花費足夠多的時間讓它正確地工作,它會反過來在你屁股上咬一口。所以讓我們談論一些哪些規(guī)則?這樣你能更好地理解人工智能系統(tǒng)會確實是多么的復雜。為了避免法律上的糾紛,我們將使用一個假設的游戲而不是一個真實的游戲作為例子。

              假設我們的游戲中有壞份子生活在3D世界中,干著他們的事情,而且如果你打攪了他們的正常次序他們就會反抗你(玩家)。你必須決定的第一件事情就是他們正在從事的到底是什么事情呢?他們正在守衛(wèi)什么東西嗎?在巡查?在計劃一個聚會?在購買食品雜貨?在整理床鋪?建立行為的基線是游戲開發(fā)者的工作之一。一旦有了這個,你就總有NPC(非玩家角色)或計算機控制的能夠恢復去做的事情,玩家與他們的交互就應當能被完成。

              一旦我們知道一個NPC角色需要做什么比如它在守衛(wèi)一扇門,并且在這個區(qū)域小巡邏,NPC也必須有世界意識。游戲設計者需要決定NPC的人工智能將如何看見世界,和它的知識范圍。你將會僅僅說計算機知道正在進行的每件事情嗎?這通常被認為是一件糟糕的事情,因為非常明顯計算機能夠看見和聽見你不能看見和聽見的事情,這被當成是在作弊。不是一種有趣的經歷。或者你將模擬他的視野,這樣他只能夠對他能看見的事物作出反應嗎?當有墻壁出現時這里就有問題了,因為你開始進入那些我在第九部分提到的追蹤例程,看看NPC是否試圖對被墻壁擋住的人作出反應。這是一個很明顯的人工智能問題,但是當涉及到門和窗戶時,這個甚至變得更加復雜了。

              當你開始為AI刺激例程增加聽覺意識時,這依然變得更加復雜了。但是,這個意識是那些關鍵的小事情之一,這些使得假想的游戲世界似乎更加真實,或者能夠去除懷疑的懸念。如果你碰到過這樣的事情,請舉手:你在槍戰(zhàn)中跟一個NPC交戰(zhàn),免除了一個NPC,你繞著角落行走并遇到了另外一個NPC依然保持他的缺省行為模式,沒有意識到剛剛發(fā)生的事情。現在,槍是嘈雜的事物,槍戰(zhàn)可能已經明顯地提醒了一個傾聽NPC有些事情正在進行。避免這種事情的技巧在于找到一個有效的方式來決定聲源(即你武器的發(fā)射)的距離是否足夠接近到NPC能夠聽見。

              接下來就是決策例程。當我們的巡邏NPC角色能夠聽到但不能看見某物時,你試圖實現什么樣的行為呢?他去尋找它嗎?不理睬它?你如何決定什么是重要的聲音他應該去或者不去調查?如同你看見的一樣,這會很快變得非常的復雜。有很多方法來建造處理這些事情的代碼,但通常這樣是一個好主意,建立一個不是對特定的NPC而是對所有的NPC都起作用的系統(tǒng),該系統(tǒng)基于你能夠在游戲引擎以外的文本文件中建立的屬性。這樣就不需要程序員為一個給定的角色而改變AI,并且如果你對游戲代碼做了改動,它將立即自動地應用到所有的角色,這在大多數情況下是一件好事情。

              其他的世界意識問題會冒出來,比如這樣的情形,兩個守衛(wèi)彼此緊挨著站立,你用狙擊武器干掉了一個,而另外一個站在哪兒完全不知已經發(fā)生的事情。再者,遵守真實世界行為的細節(jié)是一款好游戲和一款偉大游戲的之間的區(qū)別。

              讓我們說你已經把所有的刺激-響應部分準備好了你已經掃描了世界,決定NPC應當對正在進行的一些事情作出反應他聽到了玩家角色發(fā)出了聲響并且你(游戲開發(fā)者)決定了他應當對這個做些什么他將去調查。現在更加復雜的事情來了。他如何離開現在的位置,到達他認為發(fā)出聲音的地方,而不會想通常的數字傻瓜一樣跑到墻壁里面,碰到家具呢?繼續(xù)往下看


            有關正確的路徑 --- 世界導航
              快速,準確的世界導航( 也叫做路徑-發(fā)現) 近來已經成為游戲開發(fā)者的圣杯。 讓它看起來非常信服是一件非常困難的事情。你需要有局部世界的地理知識墻壁的位置,臺階,懸崖和建筑物等的邊緣。你也需要世界中的對象的知識比如家具,汽車,尤其是其他人的位置。真正最后的因素是問題所在,一會兒我們將回到這一點上。

              世界導航通常被分為兩個領域,世界導航和局部導航。二者實際上只是范圍上的區(qū)別,但大多數的程序員分別對待它們,因為這樣處理起來容易一些。世界導航例程處理理解房間,門和一般的地理學,并計算出讓玩家或者角色從世界中的A點到達B點的一條路徑。它將讓你從A點到達B,這是一句很容易說的話,不是嗎?說起來容易,但做起來很困難。理解世界是一個非常復雜問題,我已經看到過許多嘗試過的解決辦法。QuakeIII的機器人遵照建造的預先處理過的地圖,一般的說法,使用原來地圖的地面。預處理器檢測地面元素,由地圖建造者作上標記,并自己建造一個只使用地面的世界簡化地圖。機器人并不關心墻壁,因為他們從不接近它們,就像他們遵照地面的地圖一樣,設計上已經把避免墻壁構造在里面了。

              其他方法在地圖本身里面建造一些小的結點,AI可以追隨它們。這些結點通常被建造在彼此的視線里面,有從一個結點到其他所有結點的連接,角色AI能夠直接看見,所以你就確保了從一個結點移動到另外一個結點時AI不會試圖穿越墻壁。如果有門或者降落物,你能夠事先用這些結點對路徑的信息編碼,于是NPC能夠采用適當的行為等候電梯,打開一扇門,或者從一點跳到另外一點。這實際上是HereticII使用的系統(tǒng),也是Raven在他們其他的大多數游戲中使用的系統(tǒng)。

              關于這個主題,3D RealmsJess Crable,現在為Duke Nukem Forever工作,如是說:

              "導航在許多方面是個巨大的挑戰(zhàn),主要是當游戲中有大量正在發(fā)生的事情和一些非計劃性的東西,比如障礙。為了避免和(或)真實地對非計劃性的障礙物導航(例如像另外的AI),AI需要很好地知道正在它周圍發(fā)生的事情。比較而言另外一個巨大的挑戰(zhàn)就是真實感。如果AI正在表現玩家在實際生活中看到的一些東西,比如說一個人,或者一條狗, 那么讓它看上去真實可信就更加困難。"

              然后就是局部導航。我們可能有一條路徑讓我們的 NPC 從他在世界中的位置,移動到他認為聽到聲音的地方,但你不能盲目地按照這個執(zhí)行并期望得到看起來不錯的結果。這種性質的路徑傾向于非常特定于一個給定的目的。當你沿著走廊從一個房間跑到另外一個房間時,它很好,但如果你試圖指導他穿越一個巨大的房間時,路徑結點方法容易最終得到一些看起來很奇怪的發(fā)現路徑。這些路徑也不是動態(tài)的。因為他們被預先建造,他們不容易考慮到世界的任何動態(tài)變化。桌子可能有被移動過了,椅子被破壞了,墻壁被摧殘,當然,人們會移動。這就是局部導航不同于世界導航的地方。它必須考慮局部世界并導航NPC在里面穿越。它必須知道周圍的環(huán)境,存在哪些可以選擇的路徑,并決定選擇哪一條。

              在局部導航中最大的問題是其他的NPC。給定一個發(fā)現路徑的具體例程,如果你在相同的一般區(qū)域中有不止一個NPC,他們都試圖到達世界的同一地點,結果是他們都非常容易有相同的路徑。然后他們試圖沿著這個路徑行進,結果彼此遇到一起,然后花費他們所有的時間試圖將彼此分開,并且一旦成功地分開了,他們再次試圖到達目標,然后我們又再次看到同樣的事情發(fā)生。這一切看起來都是非常的愚蠢,這不是大多數人想要的效果。所以需要一些路徑發(fā)現中的變化來避免這種情形,需要一些妥善處理避免的代碼。有大量能夠幫助解決這種情形的算法。


            人工智能和角色動畫問題
              當然,當角色自己在世界中行走時你必須完全地決定你想要角色播放什么動畫。聽起來無足輕重?不是的。關于這個主題,Raven Chris Reed—Soldier of FortuneII使用名為LICHAI系統(tǒng)的現在的負責人如是說:

              "此刻我能告訴你,我們在平滑移動上正有著最大的困難。在一個多丘陵的長滿草的叢林中試圖讓五個角色在彼此附近行走是一個非常困難的問題。讓底層系統(tǒng)完美是重要的,因為除非角色在較低層次上(避免墻壁,適當的動畫)看起來真實,他們不能夠有效地表達任何較高層次決定的智能。由于這個單獨的原因,動畫和底層的移動是最重要的和最難實現的。它確實需要完美。"

              因此我們已經讓我們的角色從A點到達了B點,他自己穿越世界,在途中避免障礙物,正確播放動畫,現在到達了這里。他看見了你。接下來做什么呢?很明顯更多的是作出決策。他將向你射擊。太棒了。你回應射擊。現在干什么?當他試著逃走的時候,現在你再次經歷全部同樣的事情。

              為了讓這些情形看起來令人信服,你看見了這里必須要處理的大量問題。如果你建立你的AI使用沒有動畫的行為讓NPC執(zhí)行,這能被混合。一些Soldier of Fortune中的AI就是這樣的例子。他們受到了指責,因為壞家伙沒有以適當的方式對刺激作出反應。當他們明顯應該這樣做的時候,敵方NPC不掃射,或者不逃跑。部分問題是他們沒有掃射敵人NPC的動畫,或者讓他們往回跑,因為空間的問題。因此世界上所有最偉大的AI代碼都不能夠解決這個問題。這是所有要考慮的重要事情。

              想知道隱藏的難點嗎?看看我前面所有的描述,然后試著將它應用到一組NPC上,這些NPC彼此必須說話,設定目標,彼此溝通,但不妨礙彼此的方式。一旦你這么做了,試試那些代碼,作為玩家的隊友做上面所描述的這些,然而不要在槍戰(zhàn)中妨礙他。現在這是復雜的。然后這成為樂趣。這是最困難的部分。Raven Chris Reed關于AI‘感覺的一些評論:

              "我認為反饋是AI的一個極大的問題。如果角色對于他周圍環(huán)境的變化不產生反應,游戲的真實感就被完全打破了。這有許多明顯的例子(聽見槍炮聲,看見同伴被擊中...),以及一些更加微妙的事情(當兩個人通過門廳時看著彼此并點頭致意)。玩家是樂意接受一些生硬和可預測性的,但是這些事物容易把游戲帶到現實生活。"

              并且Jess Crable 贊同:

              "平衡是非常重要的對玩家將會有多大的樂趣至關重要,但還有其他的問題要平衡。游戲玩家時常說他們想在游戲中看見更加真實的人工智能。然而,太多的真實感開始把樂趣帶走。在這兩者之間必須要有一個好的平衡。變化和隨機同樣也很重要行為的變化,和保持在可信范圍內的一定程度的不可預測性。"


            游戲規(guī)則與自然發(fā)生的游戲
              在我們關于AI的所有描述中,我們采用的是FPS的方式。有不止一種的AI。我們已經描述的是處理3D世界一組規(guī)則。AI遠遠不止這些。時常最好的AI實際上非常的簡單。它就是一組規(guī)則,玩家必須響應和處理的響應(或開始)動作的規(guī)則。

              這里應當處理一個被稱為自然發(fā)生的游戲的專業(yè)術語。 自然發(fā)生的游戲本質上創(chuàng)造游戲將遵守的規(guī)則,那將會造成游戲程序員不能預見的情形。

              舉例來說,象棋能被認為是自然發(fā)生的游戲。有一組規(guī)則,但游戲能夠陷入各種程序員不能夠以個別方式處理的情形。你不能為每一種可能的棋局情形編碼規(guī)則。很清楚,游戲玩家每次不會總是面臨相同的游戲情景。一定程度上,進行中的游戲情形會根據他的行動而發(fā)生變化。Black and White是這種情形的一個完美的例子,和The Sims一樣游戲有它自己的規(guī)則,但你如何運用和調和他們是你自己的事情。實際上,你在玩游戲的過程中創(chuàng)造著游戲,而不是照著游戲設計者/程序員已經為你定義的路線進行。

              有可能把基于規(guī)則的,自然發(fā)生的游戲方式和FPS環(huán)境混合在一起。Half Life中的一些海軍陸戰(zhàn)隊士兵的行為就是這樣做的壓制火力和側翼攻擊從設定的規(guī)則中動態(tài)完成。它看起來是動態(tài)的,而且一定程度上它是這樣。然而,在FPS世界中僅僅有一組規(guī)則時常是不夠的。幾何和其他AI時常能夠打敗簡單的規(guī)則,這讓保持正確并依然有趣變得更加困難。所以對那些可憐的AI程序員有一些同情心吧。他們的工作不容易。


              好吧,下面還有一個章節(jié),僅僅還剩下一個章節(jié)了。在最后的章節(jié)里,我們將討論頭頂顯示,菜單系統(tǒng),游戲定制和配置,游戲引擎版權與建造,最后是游戲“mods”



            夢在天涯 2007-12-04 13:29 發(fā)表評論

            posted @ 2009-04-10 10:44 不會飛的鳥 閱讀(198) | 評論 (0)編輯 收藏

            游戲引擎基礎(九)(現成產品與定做的游戲引擎設計工具,游戲特定主題)

                 摘要: 第9部分: 現成產品與定做的游戲引擎設計工具,游戲特定主題現成產品與定做的設計工具  我們從第8部份的腳本引擎來到這一章節(jié)中的許多主題,我們認為那些鐵桿游戲玩家和有志成為游戲開發(fā)者的那些人將會發(fā)現它們相當有趣。我們將開始討論現成產品與定制的設計工具。   你的工具的選擇是你引擎設計的一個非常重要的部份,因為這是你將用來給你的游戲產生內容的東西,是最耗時的部份。在這個過程中有助于節(jié)省時間和資源的任何...  閱讀全文

            夢在天涯 2007-12-04 13:28 發(fā)表評論

            posted @ 2009-04-10 10:44 不會飛的鳥 閱讀(97) | 評論 (0)編輯 收藏

            游戲引擎基礎(八)(腳本系統(tǒng))

                 摘要: 第8部份: 腳本系統(tǒng)腳本系統(tǒng)  我們從第七部分的游戲網絡問題來到了腳本系統(tǒng),因為其呈現的故事敘述機會,最近已經形成一種很大的游戲元素。在一個需要以受控制的方式解釋的情景,預先編制的電影腳本是解決問題的方法。在電影中,這通常用來處理或者由主角向一個伙伴解釋情形,或者敵人對英雄解釋。當然,有其它的方法來做這件事情 -- 敘事者,倒敘,等等 – 但通常是使用實時情景的人們和事件來完成。當然,...  閱讀全文

            夢在天涯 2007-12-04 13:27 發(fā)表評論

            posted @ 2009-04-10 10:44 不會飛的鳥 閱讀(146) | 評論 (0)編輯 收藏

            游戲引擎基礎(七)(網絡和連線游戲環(huán)境)

            7部份: 網絡和連線游戲環(huán)境


            網絡游戲
              我記得一些年前坐在GDC(游戲開發(fā)者大會)聽負責開發(fā)X-Wing Vs TIE Fighter的家伙們題為淹沒在Internet” 的演講,全是關于讓網絡游戲實時地在Internet上工作的東西。他們選擇那個題目是多么的正確啊。當它開始處理數據包的丟失,亂序,潛伏(一個數據包發(fā)送到它的目的地所花的時間)等等時,它確實淹沒了。然而它是可能的。對于Internet需要一些聰明和經驗,但它是肯定可能的。看看今天大量的連線游戲,從Quake IIIUnreal TournamentCounter Strike一直到EverQuestUltima Online

              如今大多數真正有長久生命力的游戲都至少有一些連線成分。最純粹的單人游戲容易玩一次,也許兩次,或者甚至三次如果它是非常好的游戲,但一旦游戲結束,就被束之高閣了。如果你想要有任何長久生命力,那么多人連線游戲就是形勢的核心所在,并且那意味著和Internet打交道,為編碼者打開了那個潘多拉的盒子。

              那么跟Internet打交道包括些什么呢?首先是要理解Internet是怎么工作的,和點對點與客戶機/服務器體系結構的快速討論。點對點就是你在兩臺機器上運行游戲,并簡單地在它們之間共享輸入。每個單獨的游戲假定它是正確的,并僅僅在它一幀接一幀的刷新中合并來自另外一臺機器的輸入。客戶機/服務器是一臺機器有效地運行游戲,別的機器僅僅是一個終端,接受來自玩家的輸入,并渲染服務器讓它渲染的任何東西。

              客戶機/服務器的優(yōu)點是每臺機器都將會展現相同的游戲,因為所有的處理都在一個地方完成,沒有跨越多臺機器,你可以不用考慮每臺機器相互之間的同步問題。不足之處是,服務器本身需要有一些重要的CPU可用時間來處理每一個連接的客戶機,和一個合適的網絡連接來確保每一個客戶機及時地接收到它的更新。


            了解IP
              我們都已經聽說過TCP/IP(傳輸控制協議/網間協議)和UDP(用戶數據包協議), Web網絡上有大量關于這些協議的深奧的技術資訊。實際上,在Cisco網站上有一些極好的TCP/IP指導。我們將在較高層面上介紹一些TCP/IP的基本知識,目的是讓你更好地了解使用這些標準協議的網絡游戲設計者面臨的挑戰(zhàn)。

              TCP/IPUDP/IP是兩層的通信協議系統(tǒng)。IP層負責網際數據包的傳輸。UDP或者TCP層將大的數據包傳給IPIP將數據包分割為小的子數據包,為每個數據包加上一個信封,計算出目的地的IP地址,應該如何到達那里,然后將數據包發(fā)送到你的ISP,或者不管怎樣你連接到網絡。 這實在象是在一張明信片上寫下你要發(fā)送的,貼上郵票,寫上地址,塞進一個郵箱,它就送走了。

              UDPTCP是從你編碼者或者游戲接收數據包的高層協議,并決定該如何處理這些數據包。UDPTCP的區(qū)別在于TCP保證數據包的傳送和有序,而UDP不保證。UDP是一條直接和IP對話的小路,而TCP是在你和IP之間的一個接口。它像是在你和你的郵件之間有一個管理員助手。使用UDP你會自己為你的信打字,把它們放進一個信封等等。使用TCP你會僅僅向你的管理員口授信稿,管理員會做全部的工作并追蹤確認信件送到了。

              然而,所有這些令人驚奇的為你完成的工作伴隨著代價。為了確定數據包通過Internet完好無損地送到了目的方,TCP期待從目的方為它發(fā)送的每個數據包發(fā)回一個應答包(網絡用語是ACK)。如果它在一定時間內沒有收到ACK,它就停止發(fā)送任何新的數據包,重新發(fā)送丟失的數據包,并且將繼續(xù)這樣做直到收到目的方的回應。當你訪問一個網頁時,我們都已經看到了這種情形,在半途中下載停止了一會然后又重新開始了。可能是一個數據包在什么地方丟失了(假定不時ISP的問題),在任何更多的數據包被發(fā)送以前TCP要求重新發(fā)送它。

              這一切的問題是,在認識到出了差錯的發(fā)送者和實際上正在送達的數據包之間出現了延遲。有時這能花上數秒鐘,如果你僅僅只是下載一個文件或一個網頁,這不是什么大礙,但如果這是一個游戲數據包而且每秒至少有十次,那么你真的是遇到麻煩了,尤其是因為它停止了其他一切事情。實際上就是這個問題所以幾乎沒有游戲選擇使用TCP作為它們主要的Internet協議,除非它不是一個實時動作游戲。大多數游戲使用 UDP--他們不能保證有序或可靠送達,但它確實很快或者結果是至少通常比TCP/IP更快。現在我們了解這些了,接下來呢?


            客戶端預測
              因為 UDP 明顯的是快速響應游戲的方式,我們將必須自己處理數據包的丟失和亂序。邊而且這是技巧所在。不用說出太多的代碼秘密,我就能說有方法。作為開始,有客戶端預言,一個被談論得相當多的詞語。當你作為一個客戶端連接到一個大的服務器,但是不能連貫地看見來自服務器的更新,客戶端預言開始起作用了。正在你的電腦上運行的游戲部分看著你正給它的輸入,并在缺乏來自服務器的任何棄絕信息的情況下,對它認為將繼續(xù)進行的事情作出最好的猜測。它將會顯示被猜測的數據,然后當它得到來自服務器的世界的最新狀態(tài)時,改正它自己,如果需要。你可能會對這個方法的效力感到驚訝。大體而言,大部分時間數據包不容易丟失大多數時候是一秒的幾十分之一,這種情況下游戲沒有太多的時間偏離服務器實際上認為正在發(fā)生的事情。偏離確實會隨著時間變的比較大,大多數游戲里面有一個超時功能,當出現很長時間沒有來自服務器的聯絡時就停止游戲。

              你正在創(chuàng)造的游戲類型在這里有關系 -- 第一人稱射擊游戲不需要這樣有效的客戶端預言,因為它多數情況下僅僅處理我在哪兒,我是否要射擊?。在第三人稱游戲中,你必須更加精確,因此你能夠正確地預測你的角色正在播放的動畫,并且動作流暢。在這種情形中流暢的動畫是完全必要的。Heretic II在這方面有很大的問題,并且是當它開始網絡編碼時Raven一直不得不處理的最困難的事情之一。

              當然如果你有一個很不錯的網絡連接,比如寬帶連接,那么這個問題就遠沒有那么重要。對比較大的數據包有一個更寬的管道,對你的網絡連通時間更快速。事實上,寬帶對于游戲的主要優(yōu)點不比較胖的管道多,但大大減少了延遲,特別是你到ISP的第一跳上。對于56K 調制解調器,第一跳典型的延遲是100ms,這已經嚴重地增加了你到網絡上任意一臺游戲服務器的潛在連通時間。對于寬帶連接比如像DSL,第一跳的延遲時間多半是20ms。使用Windows中一個叫做TraceRouteTRACERT.EXE)的命令行程序并指定一個目標IP地址或者域名,你能夠找出你的第一跳的連通時間。仔細觀察第一跳,因為這幾乎總是你到你的ISP的網絡連通時間。并且觀察你在你的ISP的網絡內部用了多少跳直到你看見在一個給定跳上列出的一個不同的域名。

              請注意,寬帶并不總是能解決延遲問題。你仍然受最慢的路由器/服務器和數據包從服務器穿越網絡到達你的跳數(反之亦然)的支配。有一個寬帶連接確實容易緩和這些,但不可能它們最后就消失了。當然,如果你打算要運行某種服務器,你將會需要一個具有足夠快速的向上游的數據速率的帶寬,因為僅僅一個調制解調器不能夠處理一個服務器產生的負荷。

              值得一提的是,如果你想要在PS2或者Xbox上面玩網絡游戲,你將需要一個寬帶連接,因為它們兩者都不支持調制解調器。


            包大小,智能數據傳輸,和反作弊
              別的必須被處理的事情是數據包的大小。如果你在一個游戲里面64個人都在跑來跑去相互攻擊,從一臺機器發(fā)送到另外一臺機器的數據包能變得相當大,達到了一些調制解調器沒有帶寬處理這些數據的程度。這正在變得特別和那些有著很大的地表系統(tǒng)的游戲有關。這里增加的問題是,因為你有這個很好的地表系統(tǒng),你能夠看得很遠,因此能夠看見許多其他游戲玩家,使得你為了精確渲染所需要的來自服務器的數據數量以很快的速率增長。我們能做什么呢?

              好吧,首先必要的是只發(fā)送絕對必須的東西給任何給定的客戶端,因此他僅僅得到從他的角度觀察游戲所需要的東西。發(fā)送在他視野以外的人們的數據沒有一點意義他將看不見這些。同時,你最好確保只發(fā)送那些每幀之間實際上發(fā)生改變的數據。如果一個家伙仍然在播放相同的動畫,重新發(fā)送數據沒有意義。當然,如果數據包丟失時這確實帶來一些問題,但這就是為什么好的網絡程序員被支付很多金錢,來處理類似這樣的東西。

              還有一些其他的事情也要處理。最近已經有大量的令人苦惱的連線作弊正在發(fā)生。這是某些人修改游戲以給他們不正當利益的地方。盡管嚴格意義上這不是網絡的一部分,但它確實發(fā)生了。有時人們會創(chuàng)作一些模塊,允許他們立即瞄準進入視野的任何人,或者簡單地允許他們看穿墻壁,或者讓其他游戲玩家看不見他們自己。大部份時間這些事情可以在網絡層內部或者在服務器上被處理。任何有100%命中率的人被簡單地踢出游戲,因為在人力所及的范圍內那是不可能的。

              游戲開發(fā)者必須盡一切可能制止作弊行為,但很不幸,人做的東西可以被人突破。所有你能做的就是讓作弊變得困難,當確實發(fā)生時去嘗試發(fā)現它。

              好吧,現在就到這里了。在第8部分中,我們將會看看游戲腳本系統(tǒng)的趣味世界,根據游戲過程中出現的事件來渲染或使能預先定義的場景和行為,協助故事敘述。



            夢在天涯 2007-12-04 13:24 發(fā)表評論

            posted @ 2009-04-10 10:44 不會飛的鳥 閱讀(130) | 評論 (0)編輯 收藏

            僅列出標題
            共9頁: 1 2 3 4 5 6 7 8 9 
            思思久久99热只有频精品66| 久久天天婷婷五月俺也去| 久久久久久综合一区中文字幕| 久久亚洲高清综合| 久久亚洲视频| 久久久久久国产a免费观看不卡| 色综合合久久天天综合绕视看 | 丰满少妇人妻久久久久久4| 久久99国产乱子伦精品免费| 久久青青草原精品国产| 亚洲人成精品久久久久| 精品少妇人妻av无码久久| 国内精品久久久久久99| 99久久亚洲综合精品成人| 品成人欧美大片久久国产欧美| 精品无码人妻久久久久久| 亚洲国产成人久久综合一区77| 一本色道久久综合| 久久久久亚洲AV无码麻豆| 91久久福利国产成人精品| 久久久久婷婷| 伊人久久综合成人网| 久久亚洲精品成人AV| 91久久精品国产91性色也| 欧美精品福利视频一区二区三区久久久精品 | 无码久久精品国产亚洲Av影片 | 精品久久久久久国产免费了| 久久这里有精品视频| 亚洲精品乱码久久久久久自慰| 久久av无码专区亚洲av桃花岛| 91精品免费久久久久久久久| 久久免费视频一区| 久久久噜噜噜www成人网| 精品久久久久中文字| 午夜精品久久久久久久久| 欧美久久精品一级c片片| 久久无码高潮喷水| 99久久99久久精品国产| 亚洲AV无码久久| 亚洲国产一成久久精品国产成人综合 | 狠狠久久亚洲欧美专区|