Bài viết này là review ngắn gọn về cuốn sách Thiết kế giao diện game của tác giả Brent Fox. Đối với tôi, cuốn sách này rất thú vị từ quan điểm của một lập trình viên phát triển trò chơi chỉ như một sở thích. Ở đây tôi sẽ mô tả nó hữu ích như thế nào đối với tôi và sở thích của tôi.
Đánh giá này sẽ giúp bạn quyết định xem liệu có đáng để bạn đầu tư nguồn lực vào nó hay không. Trong phần bình luận, bạn có thể tìm thấy tài liệu tham khảo về những cuốn sách hữu ích khác về chủ đề giao diện trò chơi từ những đồng nghiệp hiểu biết và tốt bụng hơn.
Mức độ liên quan
Cuốn sách được xuất bản vào năm 2004. Do đó, rõ ràng có những mô tả và khuyến nghị đã lỗi thời. Ví dụ: độ phân giải của PC là 1024x768 được gọi là "độ phân giải rất cao". Tác giả cũng gợi ý sử dụng Flash để tạo bố cục giao diện tương tác. Mặc dù Flash không còn là công nghệ phổ biến nhưng nó vẫn có thể là giải pháp tốt để tạo bố cục nhanh chóng.
Sơ lược về lịch sử của Adobe Flash []
Những ý tưởng và lời khuyên chính trong cuốn sách dường như vẫn phù hợp và tài liệu có thể được coi là hữu ích. Thật tuyệt khi bắt gặp cách tiếp cận tỉ mỉ hiện không được ưa chuộng nhằm giảm thiểu dữ liệu đồ họa để trò chơi có thể chứa trên một đĩa DVD (hoặc thậm chí là CD) thay vì nặng dưới 60 GB.
Do khoảng cách giữa các năm nên cuốn sách không thể gọi là Must Have. Tuy nhiên, nó có thể hữu ích, đối với tôi nó là như vậy.
Целевая аудитория
Cuốn sách chủ yếu hướng đến những người mới bắt đầu thiết kế trò chơi - nhà phát triển giao diện làm việc theo nhóm với các lập trình viên, nghệ sĩ, ban quản lý và khách hàng/nhà xuất bản. Đối với các nhà thiết kế có kinh nghiệm, nó có thể sẽ ít được sử dụng (kể cả việc đánh giá qua các đánh giá trên các cửa hàng trực tuyến). Console được coi là nền tảng phát triển chính, tiếp theo là PC. Điện thoại thông minh (và đặc biệt là VR) không được xem xét, bởi vì... Vẫn còn 3 năm nữa trước khi sự nổi tiếng bùng nổ của họ bắt đầu với việc phát hành iPhone.
Đối với các đội indie tối thiểu, lời khuyên cũng sẽ rất thú vị. Cuốn sách được viết một cách dễ dàng và hấp dẫn. Tôi đã đọc nó bằng tiếng Anh và không tìm thấy bất kỳ cụm từ phức tạp, không phù hợp nào - mọi thứ đều đơn giản và chính xác. Phải mất 16 giờ để đọc và ghi chép. Hai chương cuối đề cập đến những điều cơ bản khi làm việc với Photoshop và Macromedia Flash, nhưng bạn có thể bỏ qua chúng.
Những ý tưởng đáng chú ý từ cuốn sách
Bây giờ, trong khi đọc sách, tôi viết riêng những đoạn trích ngắn gọn từ những hướng dẫn và lời khuyên được đề xuất. Tổng cộng, tôi đã xác định được 63 trích đoạn cho riêng mình ở đây. Dưới đây tôi sẽ đưa ra một số trích đoạn như vậy.
14. Nếu bạn có một ý tưởng cực hay và sáng tạo cho giao diện trò chơi thì bạn nên cân nhắc kỹ lưỡng (điều này cũng bao gồm cả các phương pháp điều khiển trong trò chơi). Có lẽ họ đã cố gắng thực hiện nó nhưng có những lý do rất chính đáng để từ bỏ nó. Và thực tế không phải là bây giờ chúng ta có thể giải quyết được chúng (và nói chung, nó có đáng không?). Giao diện và cách điều khiển mới có thể trở thành một tính năng của trò chơi, nhưng nó cũng có thể khiến trò chơi trở nên bất tiện và khó hiểu.
18. Nhìn không có mây. Để có cái nhìn mới mẻ về công việc của mình, bạn cần thay đổi cách bạn “hiểu” nó. Ví dụ: trên thiết bị khác; thay thế văn bản bằng hình chữ nhật; thay đổi quy mô; doanh số; di chuyển ra khỏi bàn hoặc sang một bên.
21. Khoảng cách giữa các hình khác nhau về mặt thị giác so với khoảng cách thực tế. Hình chữ nhật yêu cầu nhiều khoảng cách hơn hình tròn để làm cho chúng có vẻ cách đều nhau.
Những thành kiến nhận thức trong giao diện người dùng. [] Bài viết này trình bày chủ đề chi tiết hơn, mặc dù nó nhắm đến các nhà thiết kế web nhiều hơn.
Ý tưởng là khoảng cách thực tế giữa các ký hiệu/hình ảnh có thể giống nhau, nhưng khoảng cách cảm nhận được có thể bị biến dạng đáng kể.
24. Hiệu ứng chuyển động. Ngay cả các yếu tố tĩnh cũng có thể truyền tải cảm giác chuyển động. Ví dụ: các đường chéo kéo dài ra xa bằng phối cảnh.
Ngược lại, các đường dọc và ngang mang lại sự ổn định, ổn định cho bức ảnh.
32. Giao điểm của các vật thể. Các đối tượng phải liền kề hoặc giao nhau một cách đáng chú ý.
Với một chút chồng chéo, có vẻ như nhà thiết kế đã cố gắng căn chỉnh chúng từ đầu đến cuối, nhưng anh ta đã không thành công và kết quả là một sự chồng chéo quanh co.
46. Hoạt ảnh trong giao diện phải nhanh, thường không quá một giây. Hơn nữa, có thể bỏ qua hoàn toàn để chuyển ngay sang màn hình hoặc điều khiển tiếp theo. Hoạt hình thú vị chỉ thú vị trong vài lần đầu tiên, sau đó nó trở nên nhàm chán. Nếu để quá lâu sẽ chỉ gây khó chịu. Nếu nó ngắn, thì nó sẽ trở nên vô hình, đối với giao diện, điều này có lợi hơn là bất lợi.
49-51. Về biểu tượng. Các nút và chỉ báo ở dạng biểu tượng được người chơi cảm nhận nhanh hơn nhiều so với văn bản và số. Vì vậy, nên chọn các biểu tượng rõ ràng thường xuyên nhất có thể.
Các biểu tượng có thể được nhóm lại theo mục đích của chúng. Ví dụ: làm cho các nút tấn công màu đỏ, các nút cài đặt (âm thanh, độ phân giải) màu xanh lam, các nút xây dựng màu bạc... Điều này sẽ cho phép người chơi nhanh chóng tìm thấy nút mong muốn, cắt ngay lập tức các nhóm không cần thiết khỏi khu vực tìm kiếm.
Các biểu tượng nên duy trì nguyên tắc đồng nhất. Ví dụ: nếu hình ngũ giác hoặc hình tròn màu đỏ được sử dụng làm biển báo dừng ở một nơi thì bạn không nên sử dụng hình vuông màu đen từ máy phát âm thanh ở một nơi khác. Khi phân nhóm màu sắc, bạn cũng nên áp dụng nguyên tắc này. Bạn không nên thay đổi màu sắc của các biểu tượng giống nhau ở các cửa sổ menu khác nhau.
Như với bất kỳ đồ họa nào, bạn cần cảnh giác với vấn đề bản quyền với các biểu tượng. Vì vậy, sẽ an toàn hơn nếu bạn tự tạo phiên bản biểu tượng “theo gương” của trò chơi khác. Nhưng cũng có thể có vấn đề với điều này.
Ví dụ: việc sử dụng chữ thập đỏ trên nền trắng trong hộp sơ cứu (và các vật dụng khác) bị cấm và bạn có thể bị “kiện một cách lịch sự”. Việc này được tổ chức Chữ thập đỏ thực hiện định kỳ; để biết thêm chi tiết, xem bài viết “Phản ứng bất ngờ: Hội chữ thập đỏ yêu cầu loại bỏ các biểu tượng của nó khỏi trò chơi Kiến trúc sư nhà tù” []
55. Các yếu tố động trong HUD (giao diện hoạt động “luôn luôn” trong trò chơi). Cần phải phân tích nhu cầu hiển thị tất cả thông tin trong HUD - liệu nó có thực sự luôn phải hiển thị và có thể truy cập được, có thể chỉ ở một trạng thái nhất định? Ví dụ, trong chiến lược, họ thường ẩn thanh sức khỏe của những nhân vật hoàn toàn khỏe mạnh và chỉ hiển thị chúng nếu họ bị thương.
Trong một số trường hợp, thanh sức khỏe một phần có thể bị ẩn và chỉ hiển thị trong vài giây ngay sau khi nó thay đổi (hồi phục hoặc bị thương). Hoặc chỉ hiển thị thanh sinh mệnh trong chế độ chiến đấu, ẩn chúng trong chế độ lang thang và tìm kiếm yếu tố kích hoạt trận chiến.
Thông tin về các Tác giả
Cáo Brent. Vào thời điểm viết bài, anh ấy đã làm việc trong ngành game được 7 năm với tư cách là giám đốc dự án và giám đốc nghệ thuật (lúc đó anh ấy 34 tuổi). Làm việc/quản lý các nhóm lên tới 27 người và cũng làm việc trên các trò chơi có kinh phí rất thấp. Phát triển trò chơi trên nhiều loại máy chơi game. Đã làm việc tại các studio: Bla-Dam Studios, Furious Games. []
Tác giả cuốn sách hiện đang làm giám đốc nghệ thuật tại Wahoo Studios []. Họ chủ yếu phát triển trò chơi trên hệ máy console theo hợp đồng với Microsoft và Electronic Arts.
Kết luận
Ý kiến của tôi là cuốn sách có thể khá hữu ích. Tuy nhiên, chúng ta không được quên một số lượng đáng kể các đánh giá tiêu cực - cuốn sách bị chỉ trích là quá cơ bản/đơn giản trong cách tiếp cận mà không có sự tinh tế mang tính chuyên nghiệp cao. Vâng, nó đã trở nên lỗi thời đáng chú ý. Sẽ thật tuyệt nếu trong phần nhận xét, những độc giả có kinh nghiệm hơn sẽ giới thiệu những cuốn sách khác về chủ đề này: hay hơn và/hoặc phù hợp hơn.
Liên kết đến các nguồn và đọc thêm
1.
2.
3.
4.
5.
Nguồn: www.habr.com