Xây dựng cộng đồng chơi game caro trên thiết bị di động

Hiện tại có một số framework cho phép lập trình viên có thể xây dựng các thể loại game online này như LibGdx, AndEngine… Nội dung bài cáo của em thực hiện bao gồm việc tìm hiểu về quy t

ỜI MỞ Ầ

Hiện nay trên thế giới có hàng trăm game online khác nhau với sự tham gia của hàng trăm triệu thành viên trên khắp thế giới, chúng ta có thể điểm qua những trang nổi tiếng và thành công nhất như: Facebook, Zingme…Bằng những tính năng vượt trội của mình, các cộng đồng này đã thu hút đông đảo người đăng kí và sử dụng Trong đó, Zingme là cộng đồng thành công nhất tại Việt Nam hiện nay với con số thành viên được thống kê lên tới hàng trăm triệu lượt truy cập

Trong xu thế phát triển của công nghệ hiện nay, và cùng theo đó là sự phát triển,

ra đời của các thiết bị smartphone tân tiến Việc tốc độ xử lý nhanh, bộ nhớ SDCard lớn trên các máy điện thoai smartphone cho phép thực hiện các nhiệm vụ trong công việc hay giải trí dần dần thay thế cho máy tính Các ứng dụng trên môi trường mạng dần thay thế các ứng dụng chạy trên máy đơn, cục bộ Với sự lớn mạnh và phát triển vượt bậc trong những năm gần đây, hệ điều hành Android đã cho thấy được thế mạnh của mình trong các thiết bị smartphone Các ứng dụng, phần mềm phát triển trên Android OS ngày càng nhiều, và mục đích của các ứng dụng ngày càng đáp ứng được yêu cầu của người dùng

Đề tài xây dựng ứng dụng cộng đồng chơi cờ caro trên thiết bị di động thông qua WebServices Đề tài nhằm tạo ra một môi trường giải trí lành mạnh cho mọi người Thông qua môi trường mạng, sử dụng Web Service giúp cho ứng dụng kết nối đến

cơ sỡ dữ liệu của mọi người chơi và cơ sở dữ liệu của server

Cách hoạt động của phần mềm bao gồm: Khi đăng ký tài khoản, bạn cài đặt ứng dụng lên smartphone của mình Sau đó, bạn có thể vào chơi hoặc xem mọi người chơi Phần mềm này được dùng trên các dòng điện thoại và máy tính bảng chạy hệ điều hành Android từ 2.3 trở lên, PC hoặc dòng điện thoại chạy hệ điều hành IOS Về sau phần mềm sẽ mở rộng lên trên website

Vì khả năng và thời gian còn hạn chế, phần mềm không tránh khỏi những thiếu sót nhất định, rất mong sự góp ý của quý thầy cô và các bạn để phần mềm được hoàn thiện hơn Xin chân thành cảm ơn

LỜI CẢM Ơ

Xin cảm ơn thầy Trần Minh Văn, người đã tận tình hướng dẫn, chỉ bảo tôi trong suốt thời gian thực hiện đề tài Trong thời gian làm việc với thầy, tôi không những học hỏi được nhiều kiến thức bổ ích mà còn học được tinh thần làm việc, thái độ nghiên cứu nghiêm túc của thầy Thầy đã dạy cho tôi tất cả kiến thức cần thiết cho bài thực tập

Tôi xin chân thành cảm ơn quý Thầy cô trong Khoa Công Nghệ Thông Tin, đã tận tình giảng dạy giúp chúng tôi có những kiến thức làm tiền đề cho việc thực hiện đề tài

Xin gửi lời cảm ơn chân thành đến gia đình, ba mẹ và bè bạn vì đã luôn là nguồn động viên to lớn, giúp đỡ tôi vượt qua những khó khăn trong suốt quá trình làm việc Mặc dù đã cố gắng hoàn thiện bài thực tập với tất cả sự nỗ lực của bản thân, nhưng chắc chắn không thể tránh khỏi những thiếu sót Kính mong quý Thầy Cô tận tình chỉ bảo

Một lần nữa, tôi xin chân thành cảm ơn và luôn mong nhận được sự đóng góp quý báu của tất cả mọi người

NHẬN XÉT

(của giản v n ƣớng d n)

………

………

………

………

………

………

………

………

………

………

………

………

………

……… ……….………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

Nha Trang, ngày tháng năm 2013

Giáo viên hướng dẫn

H GI

(của giảng viên phản bi n)

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

Nha Trang, ngày tháng năm 2013

Giáo viên phản biện

M C L C

HƯƠ G GIỚI THI U TỔNG QUAN 2

1.1 Giới thiệu đề tài 2

1.2 Mục tiêu đề tài 2

1.3 Nội dung báo cáo 2

HƯƠ G E F WE E I E 4

2.1 Tổng quan về RESTful Web services 4

2.2 JSON 13

HƯƠ G 3 GIỚI THI U CHUNG VỀ GAME VÀ GAME TRÊN THIẾT BỊ I NG 16

3.1 Khái quát về game 16

3.2 Game trên thiết bị di động 18

3.3 Sơ lược quy trình phát triển game trên di động 19

3.4 Một số framework hỗ trợ việc phát triển game trên di động 20

HƯƠ G 4 GIỚI THI U VỀ LIGDX VERSION 1.5.3 23

4.1 Các khái niệm chính trong lập trình LiGdx 23

4.1.1 Camera 23

4.1.2 Scene 23

4.1.3 Layer 23

4.1.4 Sprite 23

4.1.5 Texture 23

4.1.6 Texture Region 23

4.1.7 ApplicationListener 24

4.1.8 NetWorking 24

4.2 Vòng đời của một game sử dụng LibGdx 24

4.3 Một số hàm và đối tượng thường dùng trong LibGdx 25

HƯƠ G 5 XÂY Ự G Ò HƠI 26

5.1 Đặc tả hệ thống 26

5.2 Phân tích thiết kế cơ sỡ dữ liệu: 27

5.2.2 Mô hình quan niệm dữ liệu 27

5.2.3 Mô hình vật lí dữ liệu 28

5.3 Mô hình quá trình chơi 33

5.4 Kết quả ứng dụng 34

HƯƠ G 6 ỔNG KẾT 49

6.1 Ưu khuyết điểm của chương trình đã xây dựng 49

6.1.1 Ưu điểm 49

6.1.2 Khuyết điểm 49

6.2 Hướng đi trong tương lai 49

6.3 Kết quả đạt được 49

Tài li u tham khảo 50

HƯƠ G GIỚI THI U TỔNG QUAN 1.1 Giới thi u đề tài

Ngày nay, điện thoại di động đã trở thành phương tiện không thể thiếu trong cuộc sống hằng ngày của chúng ta Điện thoại không còn đơn thuần là dành cho những cuộc gọi hay nhắn tin nữa, nhu cầu sử dụng điện thoại bây giờ rất đa dạng và phong phú, trong đó không thể bỏ qua nhu cầu giải trí Game trên trên điện thoại di động đã trở thành thú vui số 1 của giới trẻ

Tuy game trên điện thoại di động chơi không sướng như trên máy tính nhưng tính tiện lợi thì rất rõ, có thể chơi mọi lúc mọi nơi Trước kia các ứng dụng game trên

di động hầu hết đều là chơi offline, nhưng với sự bùng nổ công nghệ hiện nay dẫn đến con người có ý muốn được tương tác, chia sẻ với nhau nhiều hơn, nên các dòng game offline dần được thay thế bới có game online để có thể nói chuyện, giao lưu giữa những người chơi với nhau

Cộng đồng chơi caro là một game online cho phép hai người chơi qua mạng, có thể xem người khác chơi, có thể trò chuyện, trao đổi với nhau, và có tính điểm và xếp hạng cấp độ của người chơi Hiện tại có một số framework cho phép lập trình viên có thể xây dựng các thể loại game online này như LibGdx, AndEngine…

Nội dung bài cáo của em thực hiện bao gồm việc tìm hiểu về quy trình làm game online sử dụng framework LibGdx thông qua web service để xây dựng game caro online có thể chạy trên các thiết bị di động hiện nay

1.2 Mụ t u đề tài

Đề tài này thuộc hướng tìm hiểu công nghệ từ đó xây dựng ứng dụng Mục tiêu của đề tài là tìm hiểu framework LibGdx rồi từ đó xây dựng thử nghiệm game caro online chạy trên các thiết bị di động

Để thực hiện được điều này nội dung của báo cáo bao gồm:

 Tìm hiểu về RESTful Web services và Json

 Tìm hiểu về framework LibGdx

 Tìm hiểu sơ lượt về quy trình làm game và các khái niệm trong game

 Phân tích thiết kế cơ sỡ dữ liệu cho game từ đó xây dựng và phát triển ứng dụng game

1.3 Nội dung báo cáo

Báo cáo bao gồm 6 chương:

 Chương 1: Giới thiệu tổng quan

 Chương 2: Trình bày về RESTful web service, Json và cách thực thi

 Chương 3: Giới thiệu về game, game di động và quy trình làm game

 Chương 4: Giới thiệu về framework LibGdx và các khái niệm cơ bản trong thư viện để làm game

 Chương 5: Trình bày quá trình xây dựng ứng dụng

 Chương 6: Kết luận và hướng phát triển

HƯƠ G : RESTFUL WEB SERVICES 2.1 Tổng quan về RESTful Web services

REST định nghĩa các quy tắc kiến trúc để bạn thiết kế Web services chú trọng vào tài nguyên hệ thống, bao gồm các trạng thái tài nguyên được định dạng như thế nào và được chuyển tải qua HTTP thông qua số lượng lớn người dùng và được viết bởi những ngôn ngữ khác nhau Nếu tính theo số dịch vụ mạng sử dụng, REST đã nổi lên trong vài năm qua như là một mô hình thiết kế dịch vụ chiếm ưu thế Trong thực

tế, REST đã có những ảnh hưởng lớn và gần như thay thế SOAP và WSDL vì nó đơn giản và dễ sử dụng hơn rất nhiều

REST không thu hút được nhiều sự chú ý khi lần đầu tiên giới thiệu vào năm 2000 bởi Roy Fielding trong luận án của ông "Architectural Styles and the Design of Network-based Software Architectures" (Phong cách kiến trúc và thiết kế kiến trúc phần mềm dựa trên mạng) tại Đại học California Luận án đã phân tích một loạt các nguyên tắc kiến trúc phần mềm sử dụng Web như là một nền tảng tính toán phân tán Đến nay, vài năm sau đó, đã xuất hiện các framework chủ đạo cho REST và chúng vẫn đang được tiếp tục phát triển, nó đang được xem xét để đưa vào trong bộ Java™ 6 thông qua tiêu chuẩn JSR-311

REST được biết đến nhiều hơn thì việc cụ thể hóa một Web service REST sẽ tuân thủ theo bốn nguyên tắc thiết kế cơ bản sau:

 Sử dụng các phương thức HTTP một cách rõ ràng

 Phi trạng thái

 Hiển thị cấu trúc thư mục như URls

 Chuyển đổi JavaScript Object Notation (JSON) và XML hoặc cả hai

Các phần sau đây sẽ mở rộng dựa trên bốn nguyên lý này và đề xuất một nhân tố kỹ thuật cơ bản giải thích vì sao chúng quan trọng đối với các nhà thiết kế dịch vụ mạng REST

Sử dụn p ươn t ức HTTP một cách rõ ràng

Một đặc tính quan trọng của dịch Web service RESTful là sử dụng một cách rõ ràng các phương thức HTTP theo cách một giao thức được xác định bởi RFC 2616 Ví dụ HTTP GET được xác định như là một phương thức sinh ra số liệu được sử dụng có chủ đích bởi các ứng dụng người dùng để thu thập tài nguyên, dữ liệu từ một máy chủ,

hoặc thực thi một truy vấn mà máy chủ sẽ tìm kiếm và phản hồi cùng với một gói thông tin tương thích

REST yêu cầu các nhà phát triển sử dụng phương thức HTTP một cách rõ ràng theo cách tương thích với giao thức chuẩn Nguyên lý thiết kế REST cơ bản này thiết lập một ánh xạ 1-1 giữa các hành động tạo, đọc, cập nhật và xoá (CRUD) các quá trình vận hành và các phương thức HTTP Theo cách ánh xạ này thì:

 Để tạo một tài nguyên trên máy chủ, bạn cần sử dụng phương thức POST

 Để truy xuất một tài nguyên, sử dụng GET

 Để thay đổi trạng thái một tài nguyên hoặc để cập nhật nó, sử dụng PUT

 Để huỷ bỏ hoặc xoá một tài nguyên, sử dụng DELETE

Một lỗ hổng trong thiết kế vốn có trong các Web API là việc sử dụng các phương thức HTTP mà không có mục đích trước Ví dụ lệnh URI trong một lệnh HTTP GET thường xác định một tài nguyên cụ thể Hoặc một chuỗi truy vấn trong một lệnh URI bao gồm một nhóm các tham số xác định tiêu chí tìm kiếm được máy chủ sử dụng để tìm các tài nguyên phù hợp Ít nhất điều này cho thấy HTTP/1.1 miêu tả GET như thế nào Nhưng có nhiều trường hợp Web APIs không được tốt lắm, do sử dụng HTTP GET để khởi động một vài tác vụ trên máy chủ — ví dụ, thêm các bản ghi vào một cơ

sở dữ liệu Trong các trường hợp này, phương thức GET-yêu-cầu-URI đã không được

sử dụng đúng đắn hoặc chưa sử dụng đầy đủ Nếu Web API sử dụng GET để tiến hành các thủ tục ra lệnh từ xa thì nó sẽ có dạng như sau :

GET n/adduser?name=Robert HTTP/1.1

Đây không phải là mẫu thiết kế hấp dẫn vì phương pháp nói trên hỗ trợ phương thức thay đổi trạng thái trên HTTP GET Nói cách khác, phương thức yêu cầu HTTP GET nói trên có những tác động phụ Nếu được xử lý thành công, kết quả của yêu cầu (trong ví dụ này) là để tạo thêm một người dùng mới vào kho dữ liệu Vấn đề ở đây chỉ về mặt ngữ nghĩa Các Web server được thiết kế để phản hồi lại các yêu cầu HTTP GET bằng cách truy vấn dữ liệu phù hợp với đường dẫn (hoặc câu truy vấn) theo URI

và phản hồi những dữ liệu này hoặc những thông tin đại diện, chứ không phải để thêm một dữ liệu vào database Từ góc độ mục đích sử dụng giao thức đó và theo tiêu chuẩn Web server HTTP/1.1 thì việc sử dụng GET theo cách này tồn tại mâu thuẫn

Về mặt ngữ nghĩa, có nhiều vấn đề khi sử dụng GET là để khởi động một sự xoá bỏ, sửa đổi, hoặc ghi thêm vào cơ sở dữ liệu, hoặc để thay đổi trạng thái máy chủ theo

một cách nào đó Nó dùng các công cụ Web cache (các đường dẫn) và các công cụ tìm kiếm để làm thay đổi máy chủ một cách không chủ định thông qua đường dẫn Một cách đơn giản để vượt qua vấn đề hay xảy ra này là di chuyển tên và giá trị các tham

số yêu cầu trên URI vào các thẻ XML Các thẻ kết quả, một đại diện XML của một chủ thể được tạo ra, có thể được gửi vào một nhóm HTTP POST, những nơi mà yêu cầu URI là chủ thể sinh ra có chủ đích (xem ví dụ 1 và 2)

Ứng dụng máy khách sau đó có thể nhận kết nối của nguồn sử dụng URI mới, lưu ý rằng ít nhất về mặt logic, nguồn được đặt dưới /users, như trong ví dụ 3

Ví dụ 3 Lệnh HTTP GET

GET /users/Robert HTTP/1.1

Host: myserver

Accept: application/xml

Sử dụng GET theo cách này rất rõ ràng vì GET chỉ dành cho truy cập dữ liệu GET là

một phương thức mà không có hiệu ứng phụ, như là một đặc tính riêng không thay đổi

dụ 5 rõ ràng ở chỗ nó chỉ ra dữ liệu được cập nhật bằng cách xác định nó trong câu lệnh URI, và nó chuyển một đại diện mới của các thuộc tính dữ liệu cần chuyển đổi như là nhóm không chặt chẽ các tên tham số và giá trị trên lệnh URI Ví dụ 5 cũng có hiệu ứng từ việc đổi tên tài nguyên từ Robert sang Bob, và trong việc các thay đổi của URI sang /users/Bob Trong một dịch vụ mạng REST, lệnh tiếp theo của tài nguyên sử dụng URI cũ sẽ sinh ra lỗi căn bản 404 Not Found

Như là một nguyên tắc thiết kế chung, nó giúp theo sát các hướng dẫn sử dụng REST

để sử dụng các phương pháp HTTP một cách rõ ràng bằng cách sử dụng các danh từ trong URIs thay vì động từ Trong một Web service RESTful, các động từ — POST, GET, PUT, và DELETE — đã được định nghĩa bởi giao thức Và tốt nhất, để giữ giao diện được khái quát hoá và cho phép người dùng hiểu rõ các thao tác mà họ gọi thì Web service không nên đưa ra nhiều động từ hoặc các thủ tục remote từ xa, như adduser hoặc updateuser Nguyên tắc thiết kế chung này cũng áp dụng đối với phần thân câu lệnh HTTP, được sử dụng có chủ ý để chuyển trạng thái tài nguyên, không mang tên của một phương thức hay thủ tục remote từ xa

Phi trạng thái

Các Web Service REST cần được điều chỉnh về quy mô để đáp ứng được các yêu cầu ngày càng cao về chất lượng thực hiện Các khu vực lưu trữ của máy chủ với khả năng cân bằng tải và vượt qua sự mất mát, các bức ngăn (tường lửa) và các cổng được sắp xếp theo một phương thức đặc thù nhằm tạo ra một cấu trúc dịch vụ bền vững cho phép chuyển tiếp yêu cầu từ một máy chủ tới máy chủ khác khi cần để giảm tổng thời gian phản hồi của một yêu cầu Web service Sử dụng máy chủ trung gian nhằm nâng cao mức yêu cầu dịch vụ mạng REST của khách hàng để gửi các yêu cầu hoàn chỉnh

và độc lập, có nghĩa là gửi các yêu cầu bao gồm tất cả dữ liệu cần thiết để đáp ứng sao cho các thành phần trong các máy chủ trung gian có thể gửi tiếp đi, gửi theo tuyến và cân bằng tải mà không cần các trạng thái được kiểm soát bên trong giữa các yêu cầu Một yêu cầu hoàn chỉnh, độc lập không đòi hỏi máy chủ để thu thập được bất kỳ ngữ cảnh hoặc trạng thái của ứng dụng nào trong lúc xử lý yêu cầu Một ứng dụng (hoặc máy khách) Web service RESTchứa ở phần đầu và phần thân trang HTTP của một yêu cầu tất cả các tham số, ngữ cảnh và dữ liệu cần thiết bởi thành phần bên ngoài máy chủ để đưa ra một phản hồi Phi trạng thái theo nghĩa này nâng cao tính hiệu quả của dịch vụ Web, đơn giản hoá thiết kế và sự thi hành của các thành phần của máy chủ vì khi máy chủ không có trạng thái sẽ huỷ bỏ nhu cầu để đồng bộ hoá các mảng

dữ liệu với một ứng dụng bên ngoài

Hình 2.1 minh hoạ một dịch vụ trạng thái, từ đó một ứng dụng có thể yêu cầu trang sau trong một tập hợp các trang kết quả, giả sử rằng dịch vụ theo sát ứng dụng dừng lại ở nơi trong khi điều chỉnh tập hợp đó Đối với thiết kế trạng thái, dịch vụ gia tăng

và lưu giữ một previousPage (trang trước) thay đổi ở nơi để có thể phản hồi các lệnh tiếp theo

Hình 2.0.1 Mô hình thiết kế trạng thái

Dịch vụ trạng thái như thế này trở nên phức tạp Trong môi trường Nền tảng Java, Phiên bản Doanh nghiệp (EE), dịch vụ trạng thái yêu cầu rất cẩn thận lúc ban đầu để lưu trữ hiệu quả và cho phép đồng bộ hoá dữ liệu session (phiên làm việc) qua một hệ thống container Java EE Trong môi trường này, có một vấn đề quen thuộc đối với các chuyên viên phát triển servlet/JavaServer Pages (JSP) và Enterprise JavaBeans (EJB), những người này thường gặp khó khăn khi tìm gốc rễ nguyên nhân của java.io.NotSerializableException trong khi tái tạo session Liệu nó được chuyển bởi thành phần chứa Servlet trong khi HttpSession được tái tạo hoặc chuyển đi bởi thành phần chứa EJB trong khi sao bản EJB trạng thái, đó là vấn đề mà có thể làm các chuyên viên phát triển mất nhiều ngày để xác định mấu chốt một đối tượng mà không thực thi Serializable, đôi khi trong một đồ thị phức tạp của các đối tượng mà đóng góp nên trạng thái của máy chủ Ngoài ra, phần tối ưu hoá làm đội thêm chi phí ảnh hưởng đến hiệu quả của máy chủ

Mặt khác, các thành phần máy chủ phi trạng thái ít phức tạp hơn để thiết kế, viết và phân bổ thông qua máy chủ được cân bằng tải Dịch vụ phi trạng thái không chỉ hoạt động tốt hơn, nó còn chuyển hầu hết vai trò duy trì trạng thái sang ứng dụng ở máy khách Trong một dịch vụ mạng RESTful, máy chủ chịu trách nhiệm đưa ra các phản hồi và cung cấp một giao diện cho phép máy khách duy trì trạng thái ứng dụng của

chính nó Ví dụ, trong yêu cầu tập hợp trang kết quả, máy khách sẽ gồm số trang thực

tế khi truy xuất thay vì đơn giản chỉ là yêu cầu tiếp theo (xem hình 2.2)

Hình 2.0.2 Mô hình thiết kế phi trạng thái

Một dịch Web phi trạng thái sinh ra một phản hồi liên kết với số trang tiếp theo trong một tổng thể và để máy khách làm những gì mà nó cần để giữ giá trị này ở mức nhất định Khía cạnh này của thiết kế dịch vụ Web RESTful có thể được tách thành hai phần trách nhiệm như là mức phân chia cao nhất mà chỉ rõ một dịch vụ phi trạng thái

có thể được duy trì như thế nào

Máy chủ

 Tạo ra các phản hồi bao gồm các đường dẫn tới nguồn tài nguyên cho phép các ứng dụng điều hướng giữa các tài nguyên liên quan Loại phản hồi này nhúng các liên kết Tương tự, nếu các yêu cầu đối với máy chủ hoặc các kho tài nguyên, thì các phản hồi RESTful Web service điển hình có thể bao gồm các đường dẫn đến các máy con hoặc các tài nguyên phụ sao cho những phản hồi này được duy trì kết nối

 Tạo ra các phản hồi mà xác định chúng có thể lưu trữ hoặc không phải để nâng cao được hiệu quả bằng cách giảm số lượng yêu cầu đối với các tài nguyên trùng nhau và bằng cách loại trừ một vài yêu cầu toàn bộ Máy chủ làm được như vậy bằng cách gộp một phản hồi phần đầu HTTP Last - Modified (lần sửa gần nhất) (giá trị ngày) và Cache-Control (bộ điều khiển lưu trữ)

Ứng dụng máy khách

 Sử dụng phần đầu phản hồi Cache-Control (bộ điều khiển lưu trữ tạm) để xác định lưu trữ tài nguyên (lập một vùng sao chép nội bộ) hay không Máy khách

cũng đọc phần đầu phản hồi Last-Modified (lần sửa gần nhất) và gửi lại giá trị ngày vào phần đầu If-Modified-Since (nếu-sửa) để truy vấn máy chủ xem tài nguyên có thay đổi không Việc này được gọi là truy vấn có điều kiện, và hai phần đầu đi với nhau trong phản hồi của máy chủ là mã 304 chuẩn (không sửa đổi) và bỏ qua tài nguyên thực được yêu cầu nếu nó không thay đổi Mã phản hồi HTTP 304 có nghĩa rằng máy khách có thể sử dụng an toàn một vùng sao lưu nội bộ, lưu giữ một bản sao mới nhất của tài nguyên đại diện, hiệu quả bằng cách vượt qua yêu cầu GET tiếp theo cho đến khi tài nguyên thay đổi

 Gửi các yêu cầu hoàn chỉnh có thể được đáp ứng độc lập bởi các yêu cầu khác Điều này đòi hỏi máy khách sử dụng toàn bộ các phần đầu HTTP như chỉ định bởi giao diện dịch vụ mạng và để gửi các đại diện tài nguyên hoàn chỉnh trong phần giữa của yêu cầu Máy khách gửi yêu cầu lập một vài giả thuyết về các yêu cầu trước đó, sự tồn tại của một vùng của máy chủ, khả năng của máy chủ

để thêm các ngữ cảnh vào yêu cầu, hoặc về các trạng thái ứng dụng mà được giữ giữa các yêu cầu

Sự hợp tác này giữa ứng dụng máy khách và máy chủ là cần thiết để có một phi trạng thái trong một Web service RESful Nó nâng cao hiệu quả bằng cách tiết kiệm băng thông và tối thiểu hoá trạng thái ứng dụng về phía máy chủ

ƣa ra ấu trú t ƣ mục giống URIs

Từ điểm hiện có của tài nguyên địa chỉ ứng dụng máy khách, các đường dẫn xác định tính hiện thực của Web service REST như thế nào, và được sử dụng theo cách các chuyên viên thiết kế có thể tham gia Tính năng thứ ba của Web service RESful về tất

cả đường dẫn

Các địa chỉ Web service REST nên có tính hiện thực theo nghĩa rằng chúng dễ dàng đối với người dùng Có thể nghĩ rằng một địa chỉ đường dẫn như là giao diện tự đóng gói mà đòi hỏi ít lý giải hoặc tham chiếu, nếu có, đối với một nhà phát triển để hiểu nó nhắm đến điểm gì và phân phát tài nguyên liên quan Cuối cùng, cấu trúc của một địa chỉ nên rõ ràng, có thể đoán được và dễ hiểu

Một cách để đạt được mức độ sử dụng này là xác định cấu trúc thư mục giống URIs Loại URI này có thứ bậc, có điểm khởi nguồn tại một đường dẫn đơn giản, và có nhánh đi ra là các nhánh phụ thể hiện các vùng chính của dịch vụ Theo định nghĩa này, một URI không chỉ là một chuỗi bị cắt không giới hạn, mà còn là một cây với các nhánh chính và nhánh dọc nối với nhau tại các nút Ví dụ, trong một thảo luận dịch vụ

nhỏ thu thập các chủ đề từ Java tới bài viết, bạn có thể định nghĩa một tập hợp được cấu trúc bởi URIs giống như sau:

http://www.myservice.org/discussion/topics/{topic}

Phần gốc, /discussion, có một nút /topics bên dưới nó Phía dưới là một chuỗi tên các chủ đề, như chuyện xã hội, kỹ thuật, v.v , mỗi chủ đề chỉ ra một mạch thảo luận Trong cấu trúc này, dễ dàng kéo các mạch thảo luận bằng cách gõ một vài thứ sau /topics/

Trong một vài trường hợp, đường dẫn tới một tài nguyên cho mượn chính nó đặc biệt tốt với cấu trúc giống cây thư mục Ví dụ, tài nguyên được cấu trúc bởi ngày, điều mà phối hợp rất tốt để sử dụng một cú pháp phân cấp

Ví dụ này trực quan vì nó dựa trên các nguyên tắc:

http://www.myservice.org/discussion/2008/12/10/{topic}

Phần đầu tiên trong đường dẫn là năm có bốn chữ số, phần thứ hai là ngày có hai chữ

số, và phần thứ ba là tháng có hai chữ số Có vẻ hơi ngu ngốc khi giải thích theo cách này, nhưng đây là mức độ đơn giản Con người và máy móc có thể dễ dàng sinh ra các cấu trúc URIs giống như vậy vì chúng dựa trên các nguyên tắc Bổ sung vào các phần đường dẫn trong các khe của một cú pháp làm cho chúng tốt hơn vì có một mẫu xác định từ đó để soạn chúng

http://www.myservice.org/discussion/{year}/{day}/{month}/{topic}

Một vài hướng dẫn bổ sung để lưu ý trong khi nói về cấu trúc địa chỉ của Web service RESTful là:

 Giấu các đuôi tài liệu mở rộng của bản gốc trong máy chủ (.jsp, php, asp), nếu

có, vì vậy bạn có thể giấu một số thứ mà không cần thay đổi địa chỉ Urls

 Để mọi thứ là chữ thường

 Thay thế các khoảng trống bằng gạch chân hoặc hoặc gạch nối (một trong hai loại)

 Tránh các chuỗi yêu cầu càng nhiều càng tốt

 Thay vì sử dụng mã (404 Not Found) khi yêu cầu địa chỉ cho một phần đường dẫn, luôn luôn cung cấp một trang mặc định hoặc tài nguyên như một phản hồi Các địa chỉ URIs nên giữ nguyên để khi tài nguyên thay đổi hoặc khi tiến hành thay đổi dịch vụ, đường liên kết cũng sẽ giữ nguyên Việc này cho phép đánh dấu lại vị trí

đang đọc Nó cũng rất quan trọng vì mối liên quan giữa các tài nguyên mà được mã hoá trong các địa chỉ được giữ nguyên độc lập với các mối liên quan đại diện khi chúng được lưu trữ

2.2 JSON

JSON (JavaScript Object Noattion) là 1 định dạng hoán vị dữ liệu nhanh Chúng dễ dàng cho chúng ta đọc và viết Dễ dàng cho thiết bị phân tích và phát sinh Chúng là cơ sở dựa trên tập hợp của Ngôn Ngữ Lập Trình JavaScript, tiêu chuẩn ECMA-262 phiên bản 3 - tháng 12 năm 1999 JSON là 1 định dạng kiểu text

mà hoàn toàn độc lập với các ngôn ngữ hoàn chỉnh, thuộc họ hàng với các ngôn ngữ

họ hàng C, gồm có C, C++, C#, Java, JavaScript, Perl, Python, và nhiều ngôn ngữ khác Những đặc tính đó đã tạo nên JSON 1 ngôn ngữ hoán vị dữ liệu lý tưởng

JSON được xây dựng trên 2 cấu trúc:

 Là tập hợp của các cặp tên và giá trị name-value Trong những ngôn ngữ

khác nhau, đây được nhận thấy như là 1 đối tượng (object), sự ghi (record),

cấu trúc (struct), từ điển (dictionary), bảng băm (hash table), danh sách khoá (keyed list), hay mảng liên hợp

 Là 1 tập hợp các giá trị đã được sắp xếp Trong hầu hết các ngôn ngữ, this được nhận thấy như là 1 mảng, véc tơ, tập hợp hay là 1 dãy sequence

Đây là 1 cấu trúc dữ liệu phổ dụng Hầu như tất cả các ngôn ngữ lập trình hiện đại đều hổ trợ chúng trong 1 hình thức nào đó Chúng tạo nên ý nghĩa của 1 định dạng hoán vị dữ liệu với các ngôn ngữ lập trình cũng đã được cơ sở hoá trên cấu trúc này

Trong JSON, chúng có những thứ trên các định dạng:

1 đối tượng là 1 hổn độn của các cặp tên và giá trị 1 đối tượng bắt đầu bởi dấu ngoặc đơn trái { và kết thúc với dấu ngoặc đơn phải } Từng tên được theo sao bởi dấu

2 chấm : và các cặp tên/giá trị được tách ra bởi dấu phẩy ,

1 mảng là 1 tập hợp các giá trị đã được sắp xếp 1 mảng bắt đầu bởi dấu mở ngoặc vuông [ và kết thúc với dấu ngoặc vuông phải ] Các giá trị được cách nhau bởi dấu phẩy ,

1 giá trị có thể là 1 chuỗi string trong những trích dẫn kép hay là 1 số, hay true hay false hay null, hay là 1 đối tượng hoặc 1 mảng Những cấu trúc này có thể lồng vào nhau

1 chuỗi string là 1 tập hợp của zero hay ngay cả mẫu tự Unicode, được bao bọc trong các dấu trích dẫn kép ("), dùng để thoát ra dấu chéo ngược 1 ký tự đã được hiển thị như là 1 chuỗi ký tự đơn độc 1 chuỗi string rất giống như là chuỗi string C hay là Java

1 số rất giống 1 số C và Java, trừ định dạng bát phân và hex là không thể dùng

Trích xuất thông tin từ JSON : Trong Android hỗ trợ 2 kỹ thuật trích xuất thông tin và thấy thông tin về từ webservice lưu theo kiểu JSON

 Cách 1 : Sử dụng đối tượng JSONObject: Thiết lập 1 kiểu key/value Key phải là duy nhất và không được null Value của JSONObject, JSONArray phải là 1 trong các kiểu cơ bản sau : String, Booleans, Integers, Longs, Doubles, NULL

 Cách 2 : Sử dụng đối tượng GSON Được cung cấp và sử dụng khi Android Application làm việc với file JSON

HƯƠ G 3 GIỚI THI U CHUNG VỀ GAME VÀ GAME TRÊN

THIẾT BỊ I NG 3.1 Khái quát về game

Kể từ khi máy tính xuất hiện, game đã trở thành một trong những ứng dụng phổ biến nhất trên thị trường Trong cuốn sách Reality Is Broken, tác giả Jane

McGonigal đã nêu ra 4 thuộc tính của phần lớn game trên thị trường:

 Mục tiêu: Game chỉ ra một mục tiêu rõ ràng cho người chơi để họ đạt được Mục tiêu là những thử thách đối với người chơi, nhưng họ có thể vượt qua Người chơi sẽ cảm thấy hứng thú nhất nếu mục tiêu đó phù hợp với khả năng của mình, không quá khó, không quá dễ Mục tiêu rõ ràng, thú vị cũng

là yếu tố quan trọng thu hút người chơi đến với game

 Quy tắc: Game cũng có những quy tắc bắt buộc mà tất cả người chơi phải tuân theo Các quy tắc này thường làm cho việc đạt được mục tiêu nêu trên khó khăn hơn Điều đó cũng khuyến khích sự sáng tạo của mỗi người

 Phản hồi: Game cần phản hồi cho người chơi biết rằng họ đang làm công việc của mình tốt hay không Một điều đáng lưu ý rằng, hệ thống phản hồi chính là chìa khóa để làm trò chơi thú vị

 Tham gia một cách tự nguyện: một trò chơi sẽ không còn là một trò chơi đúng nghĩa nếu bạn không thực sự thích chơi nó Điều này ngụ ý rằng người chơi phải chấp nhận được mục tiêu, các quy tắc, và hệ thống phản hồi của trò chơi Các thể loại game cơ bảnNhững người phát triển game không chủ động phân loại các trò chơi của họ Và tất nhiên, không có danh sách chuẩn nào về việc phân loại game Mặc dù vậy, theo thời gian, các trò chơi cũng dần được phân loại vào các lớp khác nhau theo những cách khác nhau Việc phân loại chính xác rất khó khăn Tuy vậy, chúng ta có thể kể đến một

số loại game điển hình như sau:

o Game hành động hay kỹ năng: Người chơi phải sử dụng một số kỹ năng trong thời gian thực (VD: bắn vào một vật đang di chuyển ) để đạt được mục tiêu

o Game về chiến lược: Người chơi ít phải sử dụng kỹ năng hơn, và chủ yếu tập trung đưa ra những quyết định lựa chọn chiến lược hợp lý để vượt qua màn chơi

o Game về chiến lược: Người chơi ít phải sử dụng kỹ năng hơn, và chủ yếu tập trung đưa ra những quyết định lựa chọn chiến lược hợp lý để vượt qua màn chơi

o Game phiêu lưu hay có cốt truyện: Những game này được xây dựng dựa trên một cốt truyện hấp dẫn, với các nhân vật được chau chuốt cùng với một cốt truyện cụ thể Cốt truyện đó cũng định nghĩa ra mục tiêu cho người chơi trong thể loại game này

o Game mô phỏng: Thông thường, game thuộc thể loại này mô tả lại một yếu tố có trong thực tế (VD như lái một chiếc xe, chơi tennis )

o Game câu đố: Một số trò chơi truyền tải trực tiếp câu đố đến với người chơi Tuy nhiên, trong một số game phức tạp, những câu đố này có thể ẩn dưới nhiều hình thức khác nhau Có thể hiểu như một game nhỏ, trong một game lớn hơn

 Các thành phần cơ bản của một game:

o Opening (Splash) Screen: Để tối ưu hóa hiệu năng hoạt động, trước khi game sẵn sàng, đồ họa của level thường được nạp vào trước khi level đó bắt đầu Quá trình nạp dữ liệu có thể kéo dài đến vài giây Trong thời gian đó, bạn không muốn để người dùng phải nhìn vào một màn hình trống Vậy nên, hãy hiển thị một màn hình chờ (splash screen) Nó cho người dùng biết game vẫn đang hoạt động bình thường

o Menu Screen:Khi game đã sẵn sàng, chúng ta cần cung cấp cho người dùng nơi để họ có thể đưa ra những lựa chọn (Ví dụ như bật/tắt âm thanh, xem hướng dẫn chơi ) Điều này được thực hiện ở Menu Screen

o Âm nhạc (Music): Đối với bất kì ai, âm nhạc có ảnh hưởng mạnh đến cảm xúc Bởi vậy, nhạc nền đóng vai trò quan trọng trong việc giữ nhịp cho game, và cũng giúp cho việc chuyển đổi giữa các phần khác nhau trong game được liên tục, không bị ngắt quãng

o Hiệu ứng âm thanh (Sound Effects): Những hiệu ứng âm thanh sẽ làm cho game trở nên thú vị hơn nhiều Ví dụ như khi hai vật thể va chạm, người chơi muốn được nghe một tiếng động nào đó thể hiện

sự va chạm này Âm thanh sẽ làm cho game thân thiện hơn với người chơi

o Thời gian: Hầu hết các trò chơi đều kết hợp thời gian Yếu tố thời gian thôi thúc người chơi hoàn thiện mình qua từng màn chơi để có thể đáp ứng được mục tiêu của màn chơi

o Mạng (Lives): Game sẽ trở nên hấp dẫn hơn nếu có thêm những thử

Như vậy, người chơi sẽ cảm thấy được thách thức, game sẽ vui hơn nhiều

o Chướng ngại vật (Obstacles): Mỗi thể loại game khác nhau sẽ sử dụng những chướng ngại vật khác nhau Hãy lựa chọn chướng ngại vật phù hợp để tăng độ khó cũng như thử thách người chơi

o Cấp độ (Levels): Thử thách trong game là một phần thúc đẩy người chơi Nhưng hãy biết cách giới hạn nó! Hãy chia những thử thách thành nhiều cấp độ Người chơi bắt đầu với những màn chơi dễ dàng, rồi dần dần làm quen, nâng cao kỹ năng, để chiến thắng được những cấp độ khó hơn

o Người chơi (Player): Người chơi luôn là phần quan trọng nhất của bất kỳ game nào Game sẽ chỉ thành công khi luôn giữ được sự thú

vị, lôi cuốn đối với người chơi Người chơi cần được thử thách bởi các thành phần trong game, nhưng không được quá thách thức khiến họ từ bỏ game trong thất vọng Game cần bao gồm đủ nhiều yếu tố để duy trì sự quan tâm từ phía người chơi!

o Màn chơi (Scenes): Nếu coi trò chơi như một bộ phim, thì mỗi màn hình hiển thị cho người chơi cũng giống như một cảnh trong phim Ở

đó có sự thay đổi về nền đồ họa trong mỗi cảnh, nhưng không quá nhiều dù điểm nhìn của người chơi thay đổi Sau đó, ta thêm vào những thứ chuyển động, cùng với những chướng ngại vật để tạo ra một màn hình game hoàn chỉnh

3.2 Game trên thiết bị động

Cùng với sự đa dạng và phong phú về thể loại game có thể lựa chọn, chúng ta cần tập trung vào những yếu tố phù hợp nhất với nền tảng di động (điện thoại di động, máy tính bảng ), đặc biệt quan tâm đến những game có thể phát triển bằng một nhóm

ít người Với tiềm năng to lớn của thị trường di động, không ngạc nhiên khi có rất nhiều nghiên cứu và tư tưởng được đưa ra nhằm mục đích tạo nên một game di động tốt Cùng với việc tiếp tục áp dụng những nguyên tắc thông thường khi thiết kế game trên máy tính, ta cần quan tâm đến một số đặc điểm của game được thiết kế trên các thiết bị di động:

 Không lãng phí thời gian của người chơi

 Cung cấp sự trợ giúp cần thiết cho người chơi

 Làm cho mục tiêu của trò chơi dễ hiểu

 Hiển thị các trạng thái trong game một cách rõ ràng

 Người dùng di động thường chỉ chơi game trong một thời gian ngắn

 Người chơi có thể dễ dàng tạm dừng hay tiếp tục game khi cần thiết

 Người chơi có thể đạt được tiến bộ trong một thời gian ngắn

 Những hạn chế của thiết bị di động ảnh hưởng đến việc xây dựng game:

 Kích thước màn hình nhỏ, và đa dạng về kích thước màn hình, độ phân giải

 Có rất nhiều cách thức nhập dữ liệu từ người dùng (bàn phím, cảm ứng, cảm ứng đa điểm)

 Hạn chế về khả năng tính toán

 Hạn chế về pin

3.3 ơ lƣợc quy trình phát triển ame tr n động

Một đội phát triển game trên thiết bị di động thường có những vị trí sau:

 Người viết kịch bản

 Lập trình viên

 Người thiết kế đồ họa

 Người soạn nhạc và hiệu ứng âm thanh

 Người kiểm tra và đóng gói sản phẩm

Cần có một tài liệu thật tốt để mọi người trong nhóm có chung tiếng nói, hiểu được mục tiêu chung và cùng nhau phát triển tốt sản phẩm game

Xét về mặt tổng quát, có thể chia phát triển game thành 4 giai đoạn:

Giai đoạn 1: Giai đoạn tiền sản phẩm/ý tưởng

Ở giai đoạn này, từng thành viên phát triển ý tưởng, sau đó thống nhất với cả đội để xác định ý tưởng chủ đạo của sản phẩm Qua giai đoạn này, các ý tưởng cho lập trình, nội dung, thể loại game (action, puzzle, adventure, platform, sport, RPG ), phong cách đồ họa và âm nhạc dần được hình thành thể hiện qua biểu đồ, đặc tả, các thông số thử nghiệm, hình vẽ tay về nhân vật (sketch), giai điệu nhạc được lựa chọn và thống nhất xuyên suốt các giai đoạn phát triển

Giai đoạn 2: Đặc tả cho lập trình

Đây là một giai đoạn rất quan trọng trong quá trình thiết kế game Bạn càng bỏ nhiều thời gian cho giai đoạn này thì khi lập trình, gỡ lỗi càng tiết kiệm thời gian Lập trình viên chuyên nghiệp hiểu rằng lỗi xuất hiện trong quá trình thiết kế sẽ thiệt hại hơn nhiều so với lỗi được phát hiện trong giai đoạn này.Bạn

cần giấy, bút hay chương trình văn bản và cùng với một vài người khác chơi

thử game Khi ―chơi thử‖ bằng cách ghi ra giấy, các ưu/khuyết của thiết kế sẽ

lộ rõ và bạn có thể chỉnh sửa cho đến khi cảm thấy vừa ý

Giai đoạn 3: Thực hiện viết code, thiết kế đồ họa và chọn nhạc, hiệu ứng âm thanh

Với đặc tả đã có, hãy dự tính thời lượng cho việc lập trình, tính toán

ngày công kỹ càng để có thể ước tính khối lượng công việc và dễ theo dõi tiến

độ Và phải đảm bảo việc code đúng với những gì đã đặc tả trong game.Bên

cạnh việc viết code, thiết kế đồ họa trong game cũng cần đặc biệt lưu tâm Do

độ phân giải của màn hình điện thoại di động khá nhỏ nên mọi vật thể đồ họa

trong game đều được thực hiện bằng đồ họa điểm ảnh (pixel art), vì vậy người

thiết kế đồ họa ngoài kiến thức về vẽ tay, đổ bóng còn phải có kỹ năng thao tác

tỉ mỉ Âm thanh trong game là một phần rất quan trọng tạo nên cái hồn của

game Việc lựa chọn hay mix nhạc phù hợp sẽ tạo sự hào hứng với người chơi,

tăng độ hấp dẫn cho game của bạn Hiện tại cũng có nhiều chương trình giúp

cho việc soạn nhạc dễ dàng mà không cần biết nhiều về nhạc lý, bạn chỉ cần

lựa vài hợp âm, nhạc cụ, tempo, điệu nhạc , và chương trình sẽ tạo bản nhạc

cho bạn

Giai đoạn 4: Kiểm tra và đóng gói sản phẩm

Kiểm tra: Nhóm lập trình sẽ cùng chơi thử, cảm nhận và ghi lại tất cả các ưu và khuyết Sửa các lỗi nếu có Phát hành bản beta cho game thủ chơi thử

và lấy ý kiến của họ

Đóng gói: game cho di động phải được ―xuất‖ hay đóng gói cho các dòng máy khác nhau (do các dòng máy này khác nhau về phím nhấn, bộ nhớ và

thư viện hỗ trợ)

3.4 Một số framework hỗ trợ vi c phát triển ame tr n động

Do nhu cầu không ngừng của người chơi game cũng như của những nhà phát

triển, ngày nay trên thị trường có rất nhiều framework hỗ trợ việc xây dựng và phát

triển game trên các thiết bị di động, đặc biệt là trên hệ điều hành Android.Tùy theo

yêu cầu và đặc điểm của từng game, mà lập trình viên lựa chọn cho mình framework

thích hợp để lập trình Một số framework cơ bản có thể kể đến như:

 Libgdx: Libgdx framework được phát triển dựa trên nghiên cứu về game

development cross-platform Nghĩa là game của bạn khi viết ra bằng Libgdx

framework, nó sẽ chơi được trên Desktop, Web, Android, iOS và trong tương lai có thể thêm những platform khác nữa! Khi bạn code game sử dụng Libgdx framework, bạn có thể code trên desktop và debug ở đó, sau khi game hoàn thiện, bạn hoàn toàn có thể mang game đó chạy trên các platform khác

mà không cần sửa chữa mã nguồn nhiều Libgdx framework tối ưu hóa game của bạn bởi các thành phần thiết kế như quản lý tài nguyên được viết bằng Native code Libgdx framework có phần tài liệu hướng dẫn rất tuyệt vời và được hỗ trợ qua forum một cách nhanh chóng và nhiệt tình Libgdx framework

có nhiều game example, nhiều source code, và có rất nhiều game thương mại

và phi thương mại đã và đang sử dụng Libgdx framework.Ligdx framework thích hợp để xây dựng những game chơi được trên nhiều platform, và những game hành động đòi hỏi di chuyển mượt mà

 AndEngine: AndEngine là một bộ các công cụ để phát triển video game, được phát triển bởi Nicolas Gramlich Nó bao gồm đầy đủ các thuộc tính quan trọng nhất của OpenGL, ngay cả khi bạn không có kinh nghiệm với OpenGL - bạn vẫn có thể tạo ra 1 game có đồ họa đẹp và đầy đủ tính năng hoặc 1 ứng dụng đẹp mắt sử dụng công cụ này Tất cả các phương diện quan trọng của một game đều được định nghĩa sẵn trong AndEngine, và rất dễ dàng để sử dụng AndEngine có thể làm việc trên nhiều thiết bị khác nhau, với độ phân giải khác nhau Hỗ trợ cảm ứng đa điểm, và hình nền động Bằng những lợi thế đó, AndEngine rất thích hợp để xây dựng những game yêu cầu đồ họa cùng những hiệu ứng đẹp mắt

 Unity: Unity là một commercial game engine, được xây dựng bởi đội ngũ Unity Technologies Hiện tại đã release đến version 3.5 và đang chuẩn bị cho những bước tiến mới bằng version 4.0 sắp được phát hành.Với các phiên bản đầu tiên như 1.x - 2.x, Unity còn rất đơn giản và gần như chỉ hướng đến các nhà làm game không chuyên với những khả năng đơn giản Các phiên bản về sau, Unity được cải tiến, nâng cấp và tích hợp nhiều thành phần, công nghệ mạnh mẽ khác để đủ sức phát triển một serious game Hiện nay, mặc dù cộng đồng sử dụng Unity đa số vẫn là các cá nhân hay các indie team, nhưng Unity vẫn phát triển mạnh với tốc độ rất nhanh, bằng chứng là càng có nhiều cá nhân, công ty sử dụng Unity, đồng thời đã có nhiều tựa game được phát triển bởi Unity được tung ra thị trường (đặc biệt là thị trường game mobile)

 Cocos2d-x: Cocos2d-x là một framework làm game port từ framework nổi tiếng Cocos2d iPhone, điểm khác biệt là nó sử dụng C++ để hiện thực, thay vì

Win32, Mac, Linux, iOS, android, Blackberry, Marmalade, Tizen, WinRT

(metro app), Wp8 Cocos2d-x hoàn toàn là open source, bạn có thể làm bất kỳ

điều gì với code của nó, bạn cũng có thể đóng góp vào framework nữa để giúp

nó phát triển hơn Do sử dụng C++ để code nên Cocos2d-x có hiệu xuất cao,

chạy được trên cả những thiết bị cấu hình rất thấp của Android Đặc biệt

Cocos2d-x cho phép sử dụng Lua, hay Javascript để lập trình chứ không nhất

thiết phải là C++

Trong khuôn khổ đồ án này, chúng ta sẽ tập trung tìm hiểu về LiGdx version 1.5.3