Dev G

Just 4 fun!

Of course I can change the world, If you give me a source code

Post Ads (Documentation)

Author Info (Documentation)

style="display:block"
data-ad-client="ca-pub-2623284640924516"
data-ad-slot="8347113188"
data-ad-format="auto">

Friday, July 5, 2019

Cô đơn chưởng pháp từ cơ bản đến nâng cao


Để mở đầu thì đây không phải là bài viết về cách (thoát) độc thân :)) Đây là về Singleton trong Unity, mình giật tít tí thôi :P

I. Singleton để làm gì?
    Mình sẽ giả vờ rằng bạn chưa hề biết tí gì về singleton trong bất cứ ngôn ngữ nào. CÒn nếu bạn đã biết rồi thì có thể bỏ qua phần này và kéo xuống những phần sau đọc giải trí :3.
Ở trong bài viết "Mấy ông game dev ơi, đừng dùng GameObject.Find nữa đi!" mình có đề cập đến việc truy cập đến component của gameobject khác thông qua biến public hoặc SerializeField. Nhưng giả sử bạn đảm bảo rằng một đối tượng A trong scene chỉ có nó là duy nhất, không tồn tại một thằng gameobject thứ 2 cũng có component A, và rất nhiều đối tượng khác cần truy cập đến thằng A, bao gồm cả những đối tượng mới sinh ra trong quá trình game chạy. Vậy thì việc dùng public hoặc SerializeField rồi kéo thả A vào từng thằng là ko thể. Đó là lúc mình cần dùng đến Singleton.

II. Cô đơn chưởng pháp chiêu thứ nhất:
    Vậy cách triển khai singleton cơ bản nhất là gì? Nó như sau:

    public class A{
        private static A instan = null;
        public static A _Instan{
            get{
                return instan;
            }
        }

        void Awake(){
            instan = this; //Gán đối tượng vào biến instan khi scene chạy
        }
    }

Đầu tiên, mình cần khai báo một biến static là instan để chứ chính đối tượng cần singleton. Vậy tại sao phải để là private? Để đảm bảo chỉ có chính nó mới đc phép gán hoặc bỏ những class khác chỉ đc phép lấy nó ra và dùng, và lấy ra bằng cách gọi A._Instan như mình đã khai báo biến static _Instan public và chỉ được phép get. Hiểu được đến đây là xong chiêu thứ nhất.

III. Cô đơn chưởng pháp chiêu thứ hai:
    Chiêu thứ nhất căn bản vkl, nên nó sẽ tồn tại nhiều sơ hở cho đối phương khai thác. Ví dụ nhỡ tay thả 2 thằng gameobject cùng gắn component A vào scene, vậy khi scene start sẽ có ngay 2 thằng instance của A đc tạo ra, còn gì là singleton nữa T_T. VÍ dụ khác, có một class B cũng là singleton, cơ mà chưa có đối tượng nào cần truy cập, nhưng mặc định lúc Awake vẫn tạo ra một instance của B, lãng phí vl lãng phí. Nên ta phải sửa lại như sau:

    public class A{
        private static A instan = null;
        public static A _Instan{
            get{
                if (instan == null) {
                    instan = FindObjectOfType ();
                }

                if (instan == null) {
                    GameObject obj = new GameObject ();
                    instan = obj.AddComponent (A);
                }
                return instan;
            }
        }

    }

Đấy, chiêu thức biến ảo vl rồi, chuyển thành tâm pháp cho dễ học thuộc nè. Đầu tiên để tránh instance 2 object cùng lúc thì ta sẽ kiểm tra xem no đã tồn tại chưa bằng FindObjectOfType(). Ok, nếu chứ tồn tại thì tạo một thằng gameobject mới rồi add nó vào và trả về cho người cần thôi, EZ vkl. Đến đây là đủ để hạ khối đứa rồi đếi, nhưng mình là một thằng lười vkl, cho nên, phải sáng tạo ra đường tắt.

IV. Cô đơn chưởng pháp chiêu thứ ba:
    Bây giờ một game mình có ít thì vài cái nhiều thì vài chục cái cần dùng singleton. Chả nhẽ cứ phải code đi code lại cái đoạn như kia à. Đéo, lười vl, dỗi vl :((
Nên, mình mới tạo một class như sau:

    public class SingletonClass<T>: MonoBehaviour where T: MonoBehaviour
    {
        private static T instan;

        public static T _Instan
        {
            get
            {
                if (instan == null) {
                    instan = (T)FindObjectOfType(typeof(T));
                }

                if (instan == null) {
                    GameObject obj = new GameObject ();
                    instan = obj.AddComponent<T>();
                }
                return instan;
            }
        }
    }

Xong, giờ mỗi class muốn singleton mình chỉ việc kế thừa từ thằng SingletonClass mình vừa tạo thôi:

    A:SingletonClass<A>

ngon lành chưa. Chém ko trượt phát nào nhé :)))

Nói chung đến đây là hết rồi, để mình nghĩ xem còn lười thêm đc phần nào nữa ko bổ sung tiếp trong các bài viết sau nhé :3 Chúc các bạn độc thân vui vẻ :P

Wednesday, May 29, 2019

Ánh sáng trong unity2D


Ai cũng biết, Light native trong unity2D là vô dụng vkl T_T. Well, ài viết này sẽ giúp các bạn làm nó trở nên hữu dụng đấy :))) Bắt tay vào làm việc thôi nào :D


Tất nhiên, chúng ta sẽ ko cần code :3 nhưng các bạn nên biết một chút về Photoshop nhé :P Đầu tiên, mình sẽ có hình ảnh cần chịu tác động của ánh sáng, ví dụ ở đây là con sói ngu. Nhớ tạo ra thêm một layer phía trên nó nhé, layer này để empty, nhất thiết phải có :)
Chọn layer trên cùng, sau đó chuột phải, chọn create clipping mask, sau đó dùng brush tool chọn màu gì cũng đc (trắng chẳng hạn) và bôi hết cái mask đó. Ta sẽ thu được cái ảnh như sau:
Xuất nó ra một file ảnh png khác thôi! Rồi import cả 2 cái, ảnh gốc và ảnh trắng vừa tạo vào Unity nhé, chuẩn bị đến bước quan trọng rồi này :v
Chuyển Texture Type của cái ảnh trắng thành Normal map, tích chọn ở ô Create from GrayscaleBumpiness để là 0 và Apply thôi.
Giờ ta phải tạo một Material mới, phần Shader chọn Legacy->Bumped Diffuse

Tiếp theo chỉ việc kéo cái Map vừa tạo vào ô Normalmap và cái ảnh gốc vào Base (RGB) thôi nhé
Phần này là dễ quên lắm nè :3 Sau khi kéo thả các thứ ok ngon lành thì chúng ta phải tiếp tục chọn lại Shader và chuyển về Sprites->Diffuse
Đến đây là ta đã xong rồi :D Kéo thả ảnh gốc vào scene, và kéo cái Material vừa tạo vào phần material. Tạo một cái light bất kì và căn chỉnh trục Z cho xuất hiện trước object là ok rồi nha :))

Chúc các bạn sớm áp dụng được light native vào các dự án game 2D của mình, chứ lạm dụng ảnh và effect để tạo giả light vừa xấu vừa nặng đó nhé :D


Thursday, February 2, 2017

Return first???


Return first là 1 kỹ thuật rất đơn giản
Tuy đơn giản nhưng nhiều người lại không biết đến nó, tôi đã từng gặp nhiều anh/chị có đến mấy năm kinh nguyệt trong người mà vẫn không biết viết return first như thế nào.
Return first chia làm 2 tư thế, oánh theo trình tự:
  1. Khi gặp vấn đề phải luôn bi quan ! Nghĩ đến trường hợp tồi tệ nhất.
  2. Chia tay sớm, bớt đau khổ.
Chắc không ai hiểu nên thôi lấy cái ví dụ:
Nhiều bạn khi boss giao cho mần 1 cái form login, thì hay viết như thế này:
public function doLogin() {
    if (isset($_POST['username']) && $_POST['username'] !== "") {
        if (isset($_POST['password']) && $_POST['password'] !== "") {
            if (Auth::validate($_POST['username'], $_POST['password'])) {
                // login success
                return true;
            } else {
                $this->error = 'username or password incorect';
                return false;
            }
        } else {
            $this->error = 'password should not be blank';
            return false;
        }
    } else {
        $this->error = 'password should not be blank';
        return false;
    }    
}
Có rất nhiều điểm chưa tốt trong đoạn code trên, if lồng nhau là thấy sợ rồi, phức con mẹ nó tạp, chúng ta có thể viết lại như sau đây để code được khô thoáng hơn

public function doLogin() {

    if (empty($_POST['username'])) {
        $this->error = 'username should not be blank';
        return false;
    }

    if (empty($_POST['password'])) {
        $this->error = 'password should not be blank';
        return false;
    }

    if ( ! Auth::validate($_POST['username'], $_POST['password'])) {
        $this->error = 'username or password incorect';
        return false;
    }

    // chay toi day la ngon roi =))
    return true;
}
Như các bạn thấy, tôi luôn bi quan, nghĩ là username có thể empty, sau đó tôi luôn làm biếng, nếu empty thì return luôn, khỏi chạy chi nữa cho mệt.
Áp dụng return first sẽ giúp code các bạn mỏng hơn, vì không cần dùng if lồng nhau.
Nó cũng có tác dụng làm cho code các bạn dễ đọc hơn.
Tóm lại không cần nhiều lớp mà vẫn thấm hút phi thường. Đạt được hiệu quả y chang sản phẩm cùng loại.
Hi vọng qua bài này, các bạn có thể bỏ return first vào hộp đồ nghề của mình.

Wednesday, December 28, 2016

Khi to và lâu không phải là lợi thế!

Code game là phải nhỏ và nhanh

       Mỗi nền tảng phát triển game đều có những hạn chế về năng lực xử lý của CPU(bộ xử lý trung tâm) và GPU (bộ xử lý đồ hoạ) .Đặc biệt trong các cảnh game 3D với độ chi tiết cao thì nhu cầu xử lý sẽ càng cao . Khi nhu cầu xử lý này trở nên quá tải thì hiệu năng game sẽ giảm và gây cảm giác khó chịu cho người dùng như là load game lâu, game chạy chậm và bị giật hoặc nghiêm trọng hơn thì có thể bị treo hệ thống .Quy trình tối ưu hoá là chuỗi các quyết định hay thoả hiệp giữa việc duy trì hiệu năng game và chất lượng đồ hoạ. Vậy chúng ta cần phải tối ưu những gì và cụ thể như thế nào? Well, hãy đọc hết bài này đi nhé! J

1. Hạn chế dùng Update
Hàm update được gọi mỗi lần cho 1 frame(khung hình). Và trong toàn bộ các object có hàm update thì nó gọi khá là nhiều, ngoài ra còn có FixUpdate và LateUpdate cũng được gọi thường xuyên. Chức năng này được gọi đến để cập nhật các hành vi và sự kiện theo thời gian, nên dùng trong trường hợp cần thiết, nếu lạm dụng update thì sẽ rất ảnh hưởng đến performance. Khi bạn gọi một hàm khác từ trong hàm Update() hay FixedUpdate() thì hàm bạn gọi được chạy từ lúc bắt đầu cho tới lúc kết thúc một frame, ở tốc độ 60fps thì điều này có nghĩa là hàm đó sẽ được gọi 60 lần trên giây, thấy sự lãng phí ở đây chưa? Vậy điều đầu tiên cần nhớ đó là hạn chế sử dụng tính toán và gọi hàm từ Update nếu bạn không muốn game của mình chạy ỳ ạch và ngốn hết tài nguyên hệ thống. Để thay thế thì có nhiều cách, như ta có thể dùng Coroutine hoặc InvokeRepeat
-      Corooutine có thể tạm ngừng việc thực thi của nó trong một frame rồi lấy lại và tiếp tục thực thi trong frame tiếp theo qua bất kỳ độ dài frame nào . Thử so sánh một hàm chạy 60 lần trên giây và 10 lần trên giây mà hiệu năng game vẫn vậy thì bạn chọn cách nào , rõ ràng trong trường hợp này dùng Coroutine sẽ tăng hiệu năng lên 6 lần.

-      InvokeRepeat dùng để gọi hàm sau một số giây nhất định, gần giống với Corooutine, cụ thể khác nhau ở những điểm nào mình sẽ có một bài viết phân tích sau J

2. Object pooling
          Object pooling lấy việc tối ưu hoá mô hình làm sẵn . Việc tạo thể hiện và huỷ đối tượng cũng chiếm một chi phí tính toán đáng kể . Thay vì tạo thể hiện và huỷ hết đối tượng này đến đối tượng khác thì một mảng các mô hình đối tượng game làm sẵn sẽ được tạo ra dưới dạng "pool" (bể chứa) để có thẻ lấy ra đối tượng khi cần rồi trả lại đối tượng khi không sử dụng nữa. Nhân nói về tạo và hủy, theo mình thì nên hạn chế sử dụng hàm Destroy() theo giây. Mặc dù đây là sự cải tiến để tránh việc có quá nhiều đối tượng trong chương trình , nhưng Unity vẫn phải theo dõi mỗi đối tượng và kiểm tra vòng đời của chúng cho tới khi nào hết thời gian . Một giải pháp khác là hàm Destroy() sẽ sử dụng khi đối tượng chạm vào một vùng trigger nào đó mà ta chỉ định thay vì việc phải kiểm tra liên tục.

5.Sử dụng Static Batching
        Đối với các object tĩnh, ví dụ như bàn, background tĩnh,… không di chuyển trong suốt quá trình chơi game, thì ta có thể chọn vào Static:






Unity sẽ tối ưu hóa, giảm số draw calls và tăng hiệu suất làm việc hơn.
6. Tối ưu hoá với Mecanim
Dưới đây là một số lưu ý để dùng Mecanim hiệu quả hơn .
  • Triển khai AI Layer để điều khiển Animator . Bạn có thể dùng AI Layer để cung cấp các lời gọi callback đơn giản cho hàm OnStateChange(), OnTransitionBegin , ...
  • Sử dụng tag state để dễ dàng ánh xạ máy trạng thái AI với máy trạng thái Mecanim.
  • Sử dụng đường cong phụ trợ để mô phỏng Events .
  • Sử dụng đường cong phụ trợ để đánh dấu animation(ví dụ như kết hợp với việc ánh xạ mục tiêu)
  • Tối ưu hoá thời gian chạy :
    • Luôn tối ưu hoá animation bằng cách thiết lập mục Culling Mode của animator về thành Based on Renderers , và vô hiệu hoá thuộc tính Update when offscreen của trình render lưới da (skinned mesh renderer) . . Theo đó thì cách animation sẽ không phải cập nhật khi nhân vật chưa hiện ra .

7. Lưu đệm các tìm kiếm component
            Kỹ thuật viết script này thường hiệu quả với các script được dùng thường xuyên ,nhưng đổi lại đòi hỏi viết nhiều mã hơn một chút . Hàm GetComponent() là một ví dụ về tìm kiếm (lookup) . Việc tìm component trong đối tượng game sẽ tiêu tốn thời gian và ảnh hưởng tới hiệu năng . Ý tưởng ở đây là tìm tham chiếu một lần duy nhất rồi lưu đệm hoặc lưu tham chiếu trong một biến private để sẵn sàng sử dụng trong các script về sau . Nói cách khác hãy tránh dùng hàm GetComponent() trong hàm Update() hoặc hàm FixedUpdate() bất cứ nơi nào có thể. Ví dụ:
Thay vì gọi trực tiếp : gameObject.getComponent<Rigidbody2D>() liên tục mỗi khi cần dùng đến, ta dùng:

Rigidbody2D mRigidbody2D;
Void Start() {
      mRigidbody2D = gameObject.getComponent<Rigidbody2D>();
}

Bây giờ, nếu muốn sử dụng thì chỉ cần dùng mRigidbody2D.
Đặc biệt đối với transform ( và một số thuộc tính tương tự, như audio…) cũng nên dùng cách này để tránh tham chiếu trực tiếp component của objects.

Void Start(){
     mTransform = transform;
}
Void Update(){
     mTransform.localPosition = mPosition;
}

    Điều này cũng đúng khi dùng Hash ID khi làm việc với animator, thông thường bạn sẽ code theo kiểu như thế này:




Animator anim;
//...
anim.SetBool("isRun",true);
anim.SetFloat("speed",5f);
...

Hãy thử tưởng tượng khi làm một game lớn với số lượng animation cực khủng, thì việc truy cập thông qua các chuỗi string như thế này sẽ ảnh hưởng tới performance. Hoặc là khi muốn đổi tên 1 chuỗi string, bạn phải tìm và đổi rất nhiều nơi, và thường gặp lỗi chính tả khi viết các chuỗi string. Unity cung cấp cho chúng ta Hash id, chuyển các chuỗi string về kiểu int trong Animator.

public int isRun;
void Awake(){
   isRun = Animator.StringtoHash("isRun");
}
//.......
anim.SetBool(Hash.isRun,true);

Bạn nên để tất cả các hash id này vào 1 class để dễ dàng quản lý.
P/s: Đối với tag và layer cũng là các chuỗi string, trong quá trình code, bạn nên tập trung vào 1 class khai báo quản lý. Và cũng nên khai báo 1 class để chứa và quản lý các hằng số trong game, dễ quản lý và bảo trì.





Monday, December 12, 2016

LẬP TRÌNH GAME - HÀNH TRÌNH KHÔNG CHỈ CÓ MÁU VÀ NƯỚC MẮT


LẬP TRÌNH GAME - HÀNH TRÌNH KHÔNG CHỈ CÓ MÁU VÀ NƯỚC MẮT

Vậy là bạn đang có ý định tạo một trò chơi, huh? Hãy chuẩn bị đi, đó là một hành trình dài và gian khổ.
Cuộc phiêu lưu của một lập trình game bắt đầu với một ý tưởng về một trò chơi mà họ muốn làm. “Một trò chơi với một số quái vật bên trong của một ngôi nhà tối tâm, đáng sợ và người chơi chỉ có thể tránh né chúng và tìm lối ra” – Nó chỉ đơn giản như thế. Với những người mới bắt đầu họ nghĩ nó rất đơn giản. Nhưng đó là một sai lầm, bởi trong game bạn còn phải tạo ra thêm vô số thứ khác như tạo và xắp đặt bàn, ghế, cánh cửa, tủ quần áo, tivi…cùng một số âm thanh cho mỗi con quái vật…rồi làm thế nào để cho chúng di chuyển, làm thế nào để đốt một ngọn đuốc…
Bạn có thể nói, “Vâng, nhưng tôi chỉ muốn làm cho một trò chơi như Mario. Nó cũng đâu quá khó”. Mặc dù được tạo ra hơn 25 năm trước đây, trò chơi platformer 2D này cũng khá khó khăn để thực hiện. Nếu bạn hỏi bất kỳ lập trình game nào đã thực hiện hoặc đang cố gắng để làm một game như thế, và bạn sẽ nghe một “câu chuyện” dài đến nửa đêm khi họ coding để cố gắng làm cho các đối tượng di chuyển và thực hiện va chạm một cách chính xác…. Mặc dù nó có vẻ đơn giản từ góc nhìn của một game thủ, nhưng từ quan điểm của một lập trình game, có vô số các quy trình cần phải được tính toán cẩn thận và thực hiện rất công phu khi làm cho một trò chơi.
Nếu chỉ có một điều bạn cần biết trước khi bắt đầu học cách để làm cho trò chơi, nó này: Tạo trò chơi phải mất rất nhiều thời gian và nỗ lực!
1. Có một ý tưởng hay.

Khi bạn nghĩ rằng bạn hoàn toàn sẵn sàng để tạo ra một trò chơi, hoặc để bắt đầu cuộc hành trình của bạn trong việc phát triển trò chơi, vấn đề đầu tiên bạn sẽ gặp phải được tìm ra một ý tưởng hay. Tất cả những “trạng thái” trong trò chơi của bạn đều phụ thuộc vào ý tưởng ban đầu này.
Bạn có thể rơi vào 2 loại:
a) Bạn là một người mới bắt đầu với rất ít hoặc không có kinh nghiệm lập trình
Trong trường hợp này, bắt đầu rất đơn giản. Nếu bạn duyệt qua các diễn đàn, các bạn sẽ thường thấy các nhà phát triển trò chơi kỳ cựu nói với những người mới bắt đầu là hãy làm một game Pong, thay vì thực hiện những ý tưởng mà bạn đang theo đuổi. Đề nghị này không phải là một sự xúc phạm, đó là một chiến lược đã được chứng minh. Khi bạn bắt đầu, hãy cố gắng học cách “sao chép” một trò chơi cũ như Pac Man, Missile Command, hoặc có lẽ là một trò chơi đơn giản như đánh cờ. Bạn cũng sẽ ngạc nhiên khi có rất nhiều thứ bạn sẽ được học từ những game như thế, và những gì bạn học sẽ được sẽ áp dụng cho các trò chơi chất phức tạp hơn sau này của bạn.
b) Bạn là một lập trình viên có kinh nghiệm hoặc đã ít nhất là đã từng đọc một cuốn sách viết về C
Khi bạn đã biết chương trình là gì thì sẽ có một chút dễ dàng hơn cho bạn để bắt đầu các trò chơi cao cấp hơn. Ngay cả khi bạn là một lập trình viên giàu kinh nghiệm, bạn sẽ không “bị đau” nếu bắt đầu từ những thứ đơn giản để biết được lập trình trò chơi khác với lập trình ứng dụng hoặc phát triển web như thế nào. Ngoài ra bạn có thể sẽ học thêm một ngôn ngữ mới hay biết được một số điều mới mẽ.
Bắt đầu từ đâu?
Sau khi bạn có một ý tưởng cho trò chơi của bạn, bước tiếp theo là quyết định cách bạn sẽ tạo ra trò chơi của bạn. Có hai phương án sau:
–  Tự mình lập trình tất cả mọi thứ
–  Tận dụng game engine hay một game buider
Game engine
Một sai lầm phổ biến với các lập trình game mới là họ thực sự nghĩ rằng “game engine” cơ bản là một phần mềm kỳ diệu mà bạn chỉ cần đưa vào chúng những graphics của bạn, thay đổi một vài dòng code giống như skining một trang web forum, thì… tôi đã có một trò chơi cho mình! Điều này hoàn toàn không đúng. Thuật ngữ “game engine” được sử dụng rất rộng rãi và bị hiểu sai, nó thực sự không có ý nghĩa cụ thể. Một lập trình game có thể đưa ra một “game engine” chỉ trong một vài tuần, trong khi một đội lập trình game chuyên nghiệp lại phải mất một năm để tạo ra nó.
Tuy nhiên, về cốt lõi chúng đều thực hiện những nhiệm vụ tương tự nhau. Một game engine là một tập hợp các code làm việc chặc chẽ với nhau để xử lý các yếu tố cơ bản mà hầu như tất cả các trò chơi đều cần đến. Những yếu tố đó có thể là: graphics rendering (2d hay 3d), Physics (phát hiện và đáp ứng va chạm), player input  (xử lý bàn phím và các sự kiện cảm ứng), và những thứ có khả năng khác như kết nối mạng, animation, các menu, high scores…. Game engine sẽ giúp cho bạn xử lý khá nhiều công việc, chắc chắn chúng có thể giúp bạn tiết kiệm rất nhiều thời gian và công sức khi tạo ra trò chơi của bạn, nhưng đừng suy nghĩ rằng bạn sẽ không mất nhiều thời gian và công sức khi sử dụng các game engine.
Game Builders
Game Builders là một dạng khác của game engine. Nói cách khác, thông thường với game builder bạn chỉ cần đưa vào một số graphics viết một vài dòng lệnh đơn giản, bấm vào một số checkboxes và thay đổi một số cài đặt để add thêm một số hành vi, sau đó chỉ cần nhấn vào nút “Build” thì trò chơi của bạn được thực hiện . Game Builders có thể là một cách tốt cho những đứa trẻ làm một trò chơi và thúc đẩy sự sáng tạo của chúng, nhưng quá trình tạo ra rất nhanh chóng và dễ dàng, làm cho chúng không linh hoạt và có nhiều hạn chế.
Lập trình từ đầu đến cuối
Nhiều nhà phát triển trò chơi muốn “bắt đầu từ đầu” và xây dựng một trò chơi từ mặt đất lên, tự mình làm (hầu như) mọi thứ. Đây là một cách tuyệt vời để tìm hiểu về phát triển game và lập trình nói chung. Để đi từ hướng này, điều đầu tiên bạn cần làm là chọn cho mình một ngôn ngữ lập trình.
2. Ngôn ngữ lập trình
Có rất nhiều ngôn ngữ mà nhiều người mới bắt đầu sẽ “bị lạc”trong đó và không bao giờ học được điều gì. Dưới đây là những ngôn ngữ thích hợp nhất bạn nên học khi phát triển cho Mac-iOS.
C
Đây là một trong những ngôn ngữ được ưa thích nhất bởi các lập trình viên. Trong nó có vẽ rất phức tạp, nhưng nó thực sự rất logic. Trong những năm 1990 và đầu những năm 2000, hầu hết các trò chơi được viết bằng C. Marathon, Duke Nukem 3D, Quake 3, và hàng tá những game khác. Mặc dù ngày này C ít được quan tâm nhưng vẫn là một lựa chọn hoàn toàn tốt.
Một trong những phần khó khăn nhất để hiểu về các ngôn ngữ lập trình C là quản lý bộ nhớ và con trỏ. Đối với người mới bắt đầu, điều này có thể rất khó hiểu nên khi nhảy thẳng vào C cho trò chơi đầu tiên của bạn, sẽ rất lâu để bạn tạo ra trò chơi của mình. Mặc dù vậy cũng có những điều tuyệt vời khi học nó, là một khi bạn biết nó, bạn có thể tìm hiểu hầu như bất kỳ ngôn ngữ mới nào một cách nhanh chóng.
C++
Ngày nay, thay vì viết các trò chơi trong C hầu hết các game “chuyên nghiệp” được viết trên nền tảng C++ (game engine). Sự khác biệt cơ bản giữa C và C++ là C++ là một ngôn ngữ “hướng đối tượng”. Lập trình hướng đối tượng (OOP) là một chủ đề rất rộng vượt ra ngoài phạm vi của bài viết này, nhưng đơn giản là không giống một ngôn ngữ thủ tục như C, C++ là nơi tất cả các hành động có thể thực hiện và xử lý được tổ chức thành một danh sách lớn gọi là các “hàm”, lập trình hướng đối tượng cung cấp một cách để cấu trúc tất cả những hành động và quá trình thành một hệ thống các”classes” với các dữ liệu và các hàm liên quan chặt chẽ với nhau.
Trong khi OOP là thứ tốt nhất để các lập trình viên tiếp cận, nhưng có một điều bạn phải cẩn thận với C++. Có rất nhiều thứ đang xảy ra ở đằng sau scene và đôi khi ứng dụng của bạn có thể hành xử khác nhau, và việc gỡ lỗi làm cho bạn như đang sống trong địa ngục. C++ cũng là một ngôn ngữ rất phức tạp. Một khi bạn biết được multiple inheritance, templates, operator overloading… bạn sẽ nhanh chóng hiểu ra lý do tại sao một số người không thích C++ và muốn sử dụng C. Nhưng nếu bạn không cần phải sử dụng tất cả các tính năng này thì bạn có thể chìm trong sự “ngọt ngào” của C ++.
Objective-C / Objective-C ++
Objective-C là những gì được sử dụng khi bạn phát triển ứng dụng Cocoa cho Mac OS X và iOS. Objective-C cũng có khả năng hướng đối tượng. Nó là một ngôn ngữ rất “sạch sẽ” và thường được sử dụng bởi người mới bắt đầu kể từ khi Cocoa và Objective-C cung cấp những cách đơn giản để làm những điều phức tạp, hoặc những thứ đó sẽ là phức tạp nếu làm bằng ngôn ngữ khác. Bạn có thể nói rằng ngôn ngữ này cũng giống như một phiên bản của OOP C, mà không có sự nguy hiểm của C++.
Objective-C++ là một superset của Objective-C có thể tương tác hoàn hảo với C++ code. Điều này có nghĩa là khi bạn sử dụng Objective-C++, bạn có thể sử dụng C, C++, và cú pháp Objective-C trong cùng một chương trình. Điều này có lợi thế rất lớn, cho phép bạn kết hợp một cross-platform C++ hiện có với một Objective-C để tương tác với Cocoa trong Mac OS X hay iOS. Đó là một tính năng rất mạnh mẽ.
Java
Java một ngôn ngữ phổ biến vì cho phép các nhà phát triển viết một chương trình dựa trên Java (gọi là applet) và nhúng nó vào một trang web. Kể từ đó Java đã trưởng thành và lan rộng để trở thành một ngôn ngữ phổ biến để viết các ứng dụng trên cở sở sever, đối với các trò chơi hiện nay, có cũng không phổ biến lắm. Đặc điểm lớn nhất của Java là khả năng nền tảng chéo, để bạn có thể viết một chương trình một lần, và nó sẽ làm việc trên nhiều nền tảng. Đây là một ngôn ngữ thú vị để tạo ra những trò chơi đa nền tảng mà không cần phải đối phó với porting. Nhưng nếu bạn muốn tạo ra một trò chơi 3D phức tạp, thì đừng sử dụng Java. Một lý do đơn giản là vì không có nhiều người thực hiện, có nghĩa là bạn sẽ có ít sự trợ giúp cũng như những code cho bạn tham khảo. (Java có thể được sử dụng cho các trò chơi 3D đơn giản. Runescape là một ví dụ về điều này.)
Python với pygame hoặc Pyglet
Một ngôn ngữ cũng khá tốt đối với newbie hiện nay là Python và các thư viện trò chơi Pygame và Pyglet. Python là một ngôn ngữ khá đơn giản và nó đủ mạnh mẽ để viết các trò chơi thực có chất lượng. Khi bạn bắt đầu với một ngôn ngữ như Python, nó sẽ là một bước đệm tốt cho bạn khi chuyển sang C / C ++ / v.v.. sau này. Hãy tìm kiếm trên Google về Python và Pygame hoặc hướng dẫn Pyglet, nó sẽ khá hữu ích trên con đường phát triển của bạn.
3. Engines Game / Frameworks / Creators
Đối với các thông tin mới nhất về những công cụ này, bạn có thể xem thêm tại đây.
Các công cụ
Để xây dựng và test trò chơi của bạn, bạn sẽ cần một số loại công cụ. Nếu bạn đang sử dụng một ngôn ngữ biên dịch như C, C++, C#, Java, vv.., bạn sẽ cần một trình biên dịch để biên dịch code của bạn và tạo ra các ứng dụng. Bạn cũng sẽ cần một phần mêm soạn thảo văn bản “của lập trình viên” với “màu cú pháp” và các tính năng khác khi viết code của bạn. Có hàng tá các trình biên dịch và soạn thảo văn bản, nhưng thường chỉ có hai loại được sử dụng để phát triển trên nền tảng của Apple.
Xcode
Được tạo bởi Apple, Xcode là IDE (Integrated Development Environment) để phát triển các ứng dụng cho Mac OS X và iOS. Xcode biên dịch nhiều ngôn ngữ, bao gồm cả các đại gia lớn như C, C ++, Objective-C, và Objective-C ++, và thậm chí là các ngôn ngữ khác như AppleScript và Ruby. Nếu bạn đang dự định viết game trên một máy Mac, bạn sẽ cần phải làm quen với Xcode.
Make
Make là một lệnh UNIX sử dụng để biên dịch các ứng dụng trên command line. Xcode là về cơ bản chỉ là một phiên bản đồ họa của Mark và một trình soạn thảo văn bản đơn giản. Một số nhà phát triển thích Xcode IDE, trong khi những người khác lại thích Mark. Nếu bạn là một người mới, tôi nghĩ bạn nên chọn Xcode.
Libraries
Với ý tưởng, ngôn ngữ, và các công cụ, bước cuối cùng là chọn một số thư viện thích hợp để giúp bạn tạo ra trò chơi của mình. Một trong những lĩnh vực mà các thư viện có thể giúp bạn là sound, graphics, và physics. Nhu cầu phải bổ sung thêm các yếu tố khác cho trò chơi rất cao và nếu bạn không có thời gian cũng như khả năng để tạo ra chúng, bạn có thể “tận dụng” các công việc của những người khác.
4. Bạn sẽ đi đến đâu?
Một khi bạn đã chọn và học một ngôn ngữ lập trình để sử dụng trong các công cụ mà bạn lựa chọn, bạn có thể bắt đầu xây dựng trò chơi của bạn. Tôi cung cấp khá nhiều thông tin ở đây, nhưng có rất nhiều thứ khác mà tôi đã không nói đến. Lập trình game là một chủ đề lớn, chứng minh là có đến hàng trăm đầu sách viết về chủ đề này!
Để tìm hiểu thêm về làm thế nào để bạn có thể tự viết một trò chơi cho mình, có bốn con đường bạn có thể theo. Đó là:
– Tự thực nghiệm
– Nhìn vào những trò chơi mã nguồn mở như một ví dụ
– Đọc hướng dẫn trên web và các diễn đàn
– Đọc các cuốn sách lập trình game
Đó là những con đường tốt nhất. Bạn cũng có thể kết hợp tất cả chúng. Sách là một cách tuyệt vời để bạn có những bước đi chắc chắn trong lập trình một trò chơi. Hãy đến những hiệu sách gần nhất và chọn cho mình những quyển mà bạn thích nhất. Một cách tuyệt khác là nhìn vào code của trò chơi hiện có. Khi bạn lần đầu tiên mở ra, bạn sẽ bị choáng. Nhưng trong vòng một giờ bạn sẽ có thễ hiểu được chúng.
Và một điều hiển nhiên, đó chính là khi bạn bị “mắc kẹt” trong một vấn đề nào đó, lúc này, tìm kiếm các hướng dẫn trên internet, các bài trên diễn đàn, và các ví dụ về chủ đề này sẽ là một nguồn lực lớn giúp bạn giải quyết vấn đề. Các diễn đàn đều rất năng động và thân thiện, vì vậy đừng ngại đặt câu hỏi khi bạn đang đứng trước một bức tường.
Sau khi có được trò chơi của mình, hãy thử làm một cái gì đó mới hơn, cao cấp hơn. Một khi bạn đã vượt qua những trở ngại trong trò chơi đầu tiên của mình, bạn đã có thể học nhanh hơn và nhanh hơn nữa. Chẳng bao lâu bạn sẽ chỉ bị giới hạn bởi chính trí tưởng tượng của bạn mà thôi.