Lập kế hoạch trò chơi và thiết kế phần mềm? Tôi cảm thấy UML không thuận tiện

Trong trường đại học của tôi, họ luôn nhấn mạnh và cường điệu về thiết kế và công cụ UML, trong đó tôi cảm thấy nó sẽ không hoạt động tốt với thiết kế cấu trúc trò chơi. Bây giờ, tôi chỉ muốn một lời khuyên chuyên nghiệp về cách tôi nên bắt đầu thiết kế trò chơi của mình? Câu chuyện là tôi có một số kỹ năng lập trình và đã thực hiện nhiều trò chơi nhỏ như làm cho một số nền tảng 2D hoạt động đến một số mở rộng. Các vấn đề mà tôi tìm thấy về chương trình của tôi là thiết kế kém chất lượng. Sau khi mã hóa được một lúc, mọi thứ bắt đầu bị hỏng do kế hoạch kém (Khi tôi thêm tính năng mới, nó có xu hướng khiến tôi phải mã hóa lại toàn bộ chương trình). Tuy nhiên, để lên kế hoạch cho mọi thứ mà không có một lỗi thiết kế nào là quá lý tưởng. Vì vậy, lời khuyên nào cho tôi nên lập kế hoạch cho trò chơi của mình? Làm thế nào tôi nên đặt nó vào hình ảnh có thể nhìn thấy, để tôi và bạn bè của tôi có thể tổng quan về các thiết kế?

Tôi dự định bắt đầu viết mã một trò chơi với bạn tôi. Đây sẽ là tinh thần đồng đội đầu tiên của tôi, vì vậy bất kỳ lời khuyên chuyên môn nào cũng sẽ là một niềm vui. Có sự thay thế nào khác ngoài UML không?

Một câu hỏi khác là "tạo mẫu" thường trông như thế nào?

Tôi chỉ muốn một lời khuyên chuyên nghiệp về cách tôi nên bắt đầu thiết kế trò chơi của mình?

Thiết kế trò chơi là đặc điểm kỹ thuật của trò chơi, tài sản, hệ thống tính điểm, v.v. - những thứ này không dành riêng cho phần mềm. Như vậy, UML là công cụ sai cho nhiệm vụ đó.

Khi nói đến việc thiết kế mã để thực hiện các hệ thống này, UML là một công cụ tốt cho nhiệm vụ, cung cấp cho nhóm của bạn biết nó và tuân theo các loại sơ đồ phổ biến hơn. Thông thường, khi cố gắng thiết kế một tính năng, bạn sẽ biết liệu bạn cần sử dụng mô tả hay sơ đồ. Nếu bạn cần sử dụng một sơ đồ, UML cung cấp cho bạn một cách vẽ tiêu chuẩn, đó là một điều tốt.

Sau khi mã hóa được một lúc, mọi thứ bắt đầu bị hỏng do kế hoạch kém (Khi tôi thêm tính năng mới, nó có xu hướng khiến tôi phải mã hóa lại toàn bộ chương trình).

Đó thường là một vấn đề với cách bạn lập trình, hơn là cách bạn lập kế hoạch. Phần mềm tốt thường dễ dàng mở rộng và tái sử dụng. Nếu bạn tuân thủ các thực hành lập trình tốt, vấn đề này sẽ giảm. Nhưng lập kế hoạch tốt hơn cũng sẽ giúp ích và bạn không cần các sơ đồ phức tạp cho việc này. Chỉ cần có một danh sách các tính năng sẽ có nghĩa là khi bạn mã hóa một thứ, bạn có các tính năng khác trong tâm trí và có thể coi chúng là mã.

Vì vậy, lời khuyên nào cho tôi nên lập kế hoạch cho trò chơi của mình? Làm thế nào tôi nên đặt nó vào hình ảnh có thể nhìn thấy, để tôi và bạn bè của tôi có thể tổng quan về các thiết kế?

Có vẻ như bạn đang trộn lẫn 2 vấn đề ở đây, thiết kế trò chơi và thiết kế mã.

Tôi đề nghị trước tiên hãy viết ra một thiết kế trò chơi cơ bản, chỉ định các tính năng bạn cần, đồ họa và âm thanh bạn cần, cách trò chơi thắng và thua, v.v. Tra cứu 'tài liệu thiết kế' nếu bạn cần giúp đỡ ở đó.

Từ đó, bạn sẽ có một ý tưởng về các tính năng mà bạn cần mã hóa. Bạn có thể lần lượt xem xét từng tính năng và cố gắng suy nghĩ về cách triển khai chúng. Sơ đồ có thể giúp hiển thị các mối quan hệ giữa các lớp và đối tượng khác nhau trong trò chơi của bạn, nhưng kỹ năng biết những đối tượng nào cần tồn tại là điều mà bạn phải học thông qua thực hành và / hoặc đọc thêm.

Ngoài ra, hãy thử làm việc trên các dự án nhỏ hơn, ít tham vọng hơn. Điều đó sẽ giúp bạn quen với việc viết mã tốt, làm việc mà không cần lập kế hoạch mở rộng hoặc viết lại.

Không hiểu một cái gì đó làm cho nó dễ dàng để loại bỏ. UML là một công cụ kỹ thuật được sử dụng để truyền đạt các ý tưởng bạn có theo cách có cấu trúc. Trò chơi là một hệ thống có thể được thiết kế giống như bất kỳ trò chơi nào khác. Nếu bất cứ điều gì, sự phức tạp và năng động của một trò chơi làm cho một đại diện trực quan của các bộ phận và tương tác của chúng là vô giá.

Các sơ đồ UML là các khung nhìn khác nhau về một mô hình của hệ thống đang được thảo luận. Tôi bắt đầu với các trường hợp sử dụng cho một người ngồi trước chương trình của tôi và bắt đầu nó. Trong trường hợp của một trò chơi, có hai loại người dùng: nhà thiết kế và người chơi. Tôi viết một ca sử dụng cho từng điều tôi có thể thấy họ đang làm. Sau đó, tôi làm một số thẻ CRC để tìm ra những dịch vụ tôi cần cung cấp. Sau đó, tôi tạo một sơ đồ lớp cho các giao diện sẽ cung cấp các dịch vụ này và các mối quan hệ của chúng. Điều này dựa trên các thẻ CRC. Tiếp đến là sơ đồ động cho các sự kiện như khởi tạo cần lập kế hoạch và điều phối. Sau đó, sơ đồ tĩnh chi tiết hơn cho thấy các lớp thực hiện các giao diện.

Trong khi tôi đang viết mã và tạo mẫu và phát triển nó theo hướng cung cấp các dịch vụ để hỗ trợ đáp ứng các yêu cầu của trò chơi của tôi. Không có gì được xây dựng mà không hỗ trợ người dùng thông qua các trường hợp sử dụng. Tôi viết một số phần tử sơ đồ vô dụng, nhưng giữa mã hóa giao diện và sơ đồ hóa tôi viết rất ít mã vô dụng. Vẽ sơ đồ giúp tôi tự tin rằng tôi hiểu cách lớp tôi đang viết phù hợp với toàn bộ hệ thống.

Điểm tôi đang cố gắng thực hiện là một chương trình tầm thường có thể được viết mà không có kế hoạch, nhưng một trò chơi là bất cứ điều gì ngoài tầm thường. Cách đây một thời gian, khi OOP còn mới, đã có rất nhiều thử nghiệm và một số thực tiễn tốt nhất đã xuất hiện. Cộng đồng phát triển phần mềm đồng ý rằng chúng tôi cần một ngôn ngữ để viết và phân tích các thiết kế phần mềm. UML là ngôn ngữ chúng tôi đã phát triển. Tất cả chúng ta đều biết và hiểu nó, vì vậy nếu bạn muốn sử dụng giải pháp của người khác cho các vấn đề của mình (sách, thảo luận trực tuyến, bài viết, danh mục mẫu, v.v.) và không phát minh lại bánh xe, bạn phải học cách đọc ký hiệu chuẩn. Như một phần thưởng, khi bạn buộc bản thân phải suy nghĩ về hệ thống của mình bằng ngôn ngữ khác, bạn sẽ học được những điều bất ngờ.

Nhiều phương pháp khác nhau tồn tại, nhưng tất cả đều xác định vấn đề và mô tả một giải pháp một cách có hệ thống. Đây là kỹ thuật. UML rất lớn và phức tạp, nhưng không một mô hình nào sử dụng mọi cấu trúc. Nó giống như một con dao quân đội Thụy Sĩ. Bạn phải làm quen với nó và tìm ra cách sử dụng nó để hỗ trợ quá trình kỹ thuật của bạn. Điều quan trọng không phải là quá trình hay phương pháp nào mà là bạn có một quy trình. Nếu không bạn sẽ chìm đắm trong sự phức tạp.

Tôi cũng đang làm việc trên một số dự án trò chơi độc lập với một người bạn (nhóm 2 người). Là một người có hoàn cảnh tương tự như bạn, tôi có thể đưa ra một vài mẩu tin mà tôi thấy hữu ích.

1. Nếu ý tưởng của bạn còn sơ sài, hãy thử thực hiện từng ý tưởng trong các dự án tạo mẫu siêu nhỏ. Ví dụ, bây giờ tôi đang tạo một trò chơi nền tảng 2D và việc nhảy đúng người chơi là vô cùng quan trọng đối với tôi. Vì vậy, tôi đã thực hiện một dự án mới trong đó chỉ có 2 điều xảy ra là a) Vẽ trình phát trên màn hình và b) Phát hiện đầu vào và vẽ lại bước nhảy [nhân vật thậm chí không thể di chuyển sang trái hoặc phải]
2. Một số người có thể nhăn mặt với lời khuyên này, nhưng trước tiên hãy nghĩ đến việc viết hướng dẫn trò chơi (để giải thích các khái niệm, điều khiển, mục tiêu). Điều này có thể làm 2 việc cho bạn - tạo ra một tài liệu rất cần thiết, nhưng cũng phác thảo các hệ thống con của trò chơi của bạn và bất kỳ chi tiết cần thiết nào cho người chơi. Nếu bạn biết trước những gì người chơi cần biết, thì bạn sẽ biết trước những gì bạn cần làm.
3. Viết mã thành các đoạn nhỏ đủ (còn gọi là mô đun hóa ) để các phần được bao bọc có thể được di chuyển xung quanh hoặc được tổ chức tốt hơn mà không cảm thấy như bạn đang cố gắng loại bỏ tất cả các miếng mì spaghetti cỡ vừa ra khỏi một đĩa mì ống.

Hy vọng rằng bạn đã tìm thấy ít nhất một thông tin hữu ích trong đó, và chúc may mắn!

Tôi nghĩ rằng có một số điểm đáng giá từ UML mà bạn không thể phủ nhận. mặt khác, hãy nhớ rằng UML được xây dựng cho các quy trình kinh doanh , bạn biết đấy, các hệ thống mô hình hóa có rất nhiều người tương tác với nó, tất cả đều có những mong muốn và nhu cầu và mong muốn khác nhau. UML cố gắng đảm bảo bạn không bỏ sót điều gì hoặc bị choáng ngợp bởi chi tiết.

UML là "một cách tiêu chuẩn để trực quan hóa kiến ​​trúc của hệ thống"

UML mô tả

• hoạt động
• diễn viên
• quy trình kinh doanh
• lược đồ cơ sở dữ liệu
• thành phần (logic)
• báo cáo ngôn ngữ lập trình
• linh kiện phần mềm tái sử dụng

Nhưng nếu bạn đang làm một trò chơi đơn giản, bạn có thực sự cần phải mô hình hóa tất cả điều này không?

• Diễn viên: Người chơi.

Điều đó giúp được bao nhiêu?

Mô hình hóa một số điều khác mặc dù, rất hữu ích. Ví dụ: nếu bạn đang tạo một MMO nhỏ, bạn chắc chắn muốn các lược đồ cơ sở dữ liệu được thiết kế tốt.

Vì vậy, trong khi các bước đi từ UML là tuyệt vời (biết bạn đang làm gì, hãy viết ra các yêu cầu và phác thảo sơ đồ của sơ đồ bất cứ nơi nào cần thiết) và các yếu tố của nó rất hữu ích, tôi có xu hướng cảm thấy quy trình UML đầy đủ là một chút của một lỗ tròn tròn vuông cho các trò chơi.

UML không phải là một thứ mà nó là một tập hợp những thứ mà một số trong số chúng có giá trị khác không nhiều. kiểu sử dụng cũ hơn (ít nhất là cái mà chúng ta gọi là ca sử dụng) nói rằng

• Tên
• yêu cầu
• điều kiện tiên quyết
• gây nên
• hành động
• hành động thay thế
• ngoại lệ

có thể khá hữu ích. mặc dù những gì bạn tìm thấy cho "Các trường hợp sử dụng" nếu bạn thực hiện tìm kiếm trên web (hình ảnh) là nhiều hơn cho phần mềm chung.

Tôi cũng sẽ đặt một số tín dụng cho sơ đồ Lớp. điều này cho thấy rằng bạn có thể hiển thị mối quan hệ giữa tất cả các đối tượng của bạn và bạn biết cách bố trí kiến ​​trúc của mình.

Vấn đề là bộ tính năng của bạn nên được lên kế hoạch và khóa int (được cho thuê trong thiết lập nhu cầu / muốn) trước khi lập mô hình, và việc lập sơ đồ thậm chí được bắt đầu. những điều này nên có trong Bản tóm tắt / Điều trị / Kịch bản của bạn (đôi khi được gọi là cao độ, tài liệu đặc trưng và câu chuyện). sau đó từ đó bạn sẽ thực hiện công cụ tài liệu công nghệ có mô hình và sơ đồ của bạn.

có những công ty sử dụng UML, nhưng đây thường là những công ty có các nhóm thiết kế và triển khai riêng biệt. các công ty sẽ tạo ra tất cả các tài liệu của họ, và sau đó đưa nó cho một nhóm các con khỉ mã để tạo ra một nguyên mẫu / alpha. Nó nói rằng nếu bạn có thể mô hình hóa trò chơi của mình một cách chính xác, bạn sẽ có thể đưa nó cho một đội hoàn toàn khác và để họ lập trình nó mặc dù đây là một giấc mơ xa vời hơn là một sự chính xác.

Họ sẽ dạy bạn về UML tại trường đại học của bạn để giúp bạn truyền đạt ý tưởng của mình cho các thành viên khác trong nhóm và cho các giảng viên biết bạn có kiến ​​thức tốt về các nguyên tắc kỹ thuật phần mềm cơ bản.

Giống như bất kỳ cuộc thảo luận nào về ngôn ngữ, công cụ hoặc thiết kế - nó thường liên quan đến cách BẠN sử dụng nó. Chọn công cụ / ngôn ngữ / thiết kế tốt nhất cho công việc và sao lưu sự lựa chọn của bạn với một lý do mạnh mẽ. Tôi sẽ thừa nhận UML không linh hoạt cho sản xuất trò chơi, mặc dù tôi có thể nói rằng chúng tôi đã sử dụng nó một cách hiệu quả để mô hình hóa các tính năng của động cơ như giao tiếp và thời gian mạng, quản lý tác vụ song song và các trường hợp sử dụng. Không có gì tệ hơn là giải thích điều tương tự với 5 thành viên khác nhau trong 10 lần khác nhau vì họ không hiểu lắm. Đây là tài liệu, đọc nó.

Tùy thuộc vào mức độ thiết kế vững chắc của bạn và nhóm của bạn có kỷ luật như thế nào, có thể khá hiệu quả để có thể mô hình hóa các công trình của riêng bạn xung quanh những công trình chưa được bắt đầu và chưa biết chính xác chúng sẽ hoạt động như thế nào do tài liệu.

Mặc dù vậy, có lẽ bạn sẽ nghe (và nhận ra một cách gay gắt) rằng đây là những TÀI LIỆU SỐNG, và trừ khi chúng được xem xét và cập nhật thường xuyên, chúng sẽ trở nên lỗi thời nhanh chóng và vô dụng.