Sprites là diễn viên

12

Tôi không có kinh nghiệm trong các câu hỏi Phát triển Trò chơi, nhưng là một lập trình viên. Trong ngôn ngữ Scala, bạn có thể có khả năng đa tác vụ mở rộng với Diễn viên, rất ổn định, như tôi nghe thấy. Bạn thậm chí có thể có hàng trăm ngàn trong số họ chạy cùng một lúc mà không gặp vấn đề gì.

Vì vậy, tôi nghĩ rằng, có lẽ bạn có thể sử dụng chúng như một lớp cơ sở cho 2D-Sprites, để thoát ra khỏi vòng lặp trò chơi đòi hỏi phải đi qua tất cả các họa tiết và di chuyển chúng. Về cơ bản, họ sẽ tự di chuyển, theo sự kiện.

Điều đó có ý nghĩa cho một trò chơi? Có nó đa nhiệm như thế? Rốt cuộc, nó sẽ chạy trên JVM, mặc dù điều đó không phải là vấn đề ngày nay.

BIÊN TẬP:

Sau khi suy nghĩ một lúc, tôi nhận thấy chỉ có một lợi thế thực sự cho ý tưởng này: Hỗ trợ đa điểm. Một vòng lặp trò chơi đơn giản sẽ chỉ chạy trên một lõi và sẽ hoạt động xuyên suốt mọi thứ.

Vì các máy tính hiện đại, ngay cả ở nhà, ngày nay đã tích hợp sẵn hai lõi trở lên, tôi nghĩ rằng nên cho phép các lập trình viên trò chơi sử dụng hiệu quả các lõi khác. Rốt cuộc, tôi nghĩ thông thường người chơi sẽ chỉ có trò chơi chạy trên cỗ máy tám lõi của mình, vậy tại sao không.

Ưu điểm khác tôi thấy là trong Scala, bạn có thể có RemoteActors, có thể được đối xử theo cùng một cách nhưng chạy trên máy tính khác. Vì vậy, có lẽ điều này có thể đơn giản hóa chơi game mạng là tốt.

Tôi dự định xây dựng nó vào công cụ Scala 2D của mình ngay khi có thể.

java sprites multithreading

— Lanbo
nguồn

Tôi rất muốn biết làm thế nào điều này bật ra. Tôi đã nhìn Scala một vài lần nhưng chưa bao giờ tham gia vào nó trước đây.

— Davy8

Nhiều người sẽ lập luận rằng để hỗ trợ đa lõi rõ ràng, bạn tốt hơn với các luồng hơn là các quy trình (và các quy trình mô hình diễn viên Scala). Điều này là do bạn có thể tận dụng bộ nhớ chia sẻ trên các luồng. Tất nhiên, đó là lỗi dễ xảy ra theo cách mà mô hình Diễn viên không có.

— Kylotan

Các tác nhân Scala được ghép trên đỉnh của một nhóm luồng, do đó chúng có thể nhẹ hơn các luồng. Điều này có nghĩa là họ có thể điều khiển bộ nhớ dùng chung để liên lạc, miễn là nó được đồng bộ hóa đúng cách. Nếu bạn sử dụng các tác nhân từ xa, thì chúng có thể nằm trên các quy trình khác nhau và cách duy nhất để liên lạc là gửi tin nhắn.

— axel22

7

Tôi đã không thử, nhưng tôi là một lập trình viên Scala và tôi sẽ nói rằng đây không phải là cách tiếp cận tốt nhất. Sprites cần phải được hoạt hình đồng bộ. Các diễn viên không có gì đảm bảo rằng họ sẽ được thực hiện một cách công bằng - một số họa tiết có thể nhanh hơn những người khác, đó không phải là điều bạn muốn. Bạn có thể muốn sử dụng một rào cản để đồng bộ hóa chúng, nhưng sau đó - tại sao lại sử dụng các tác nhân. Nếu bạn chỉ dựa vào việc truyền tin nhắn, thì việc thực hiện loại đồng bộ hóa này (thực hiện một rào cản đối với hơn 1000 diễn viên) là một việc quá mức cần thiết.

Một vấn đề khác là - bạn sẽ sử dụng chuyển tin nhắn để làm gì? Bạn có cần các sprite của bạn để giao tiếp? Bạn có thể gửi tin nhắn của diễn viên chính, yêu cầu mỗi sprite chuyển sang khung hình tiếp theo, nhưng về mặt hiệu suất, đó là cường độ và cường độ nhiều hơn so với việc gọi trực tiếp các phương thức và lặp qua một nhóm các họa tiết.

Dường như với tôi rằng những gì bạn cần ở đây là một loại đa nhiệm rất nhẹ và không có thông điệp nào được chuyển đi cả. Tham gia vào việc thực hiện giống như diễn viên của bạn để đảm bảo sự công bằng có lẽ là cách tốt nhất nếu bạn muốn đảm bảo điều này, nhưng đó là quá nhiều công việc cho quá ít lợi ích. Một điều khác để xem xét là lập trình phản ứng chức năng và scala.react, tôi tin rằng đó là một kết hợp tốt hơn cho trường hợp sử dụng này.

Tôi đã triển khai một công cụ trò chơi isometric 2d trong Scala. Tôi chỉ sử dụng 1 diễn viên toàn cầu để cập nhật các họa tiết có thể nhìn thấy được.

Bạn có thể muốn triển khai logic trò chơi của mình bằng cách sử dụng các diễn viên - ví dụ: để phân phối các tính toán trên các phần khác nhau trên bản đồ trò chơi của bạn cho các diễn viên khác nhau để họ cập nhật trạng thái trò chơi song song - và đạt được hiệu suất. Tôi sẽ không sử dụng một diễn viên duy nhất cho mỗi đối tượng trò chơi, thay vào đó, một diễn viên cho mỗi khu vực. Nếu bạn đi quá tốt hạt, hiệu suất bị ảnh hưởng.

Tuy nhiên, nếu tôi là bạn, tôi sẽ thử nó, chỉ để xem điều gì xảy ra.

— sợi trục22
nguồn

1

Vì vậy, tôi nghĩ rằng, có lẽ bạn có thể sử dụng chúng như một lớp cơ sở cho 2D-Sprites, để thoát ra khỏi vòng lặp trò chơi đòi hỏi phải đi qua tất cả các họa tiết và di chuyển chúng. Về cơ bản, họ sẽ tự di chuyển, theo sự kiện.

Điều gì sẽ là sự kiện di chuyển chúng?

Nó sẽ là một sự kiện bạn phát ra một lần trên mỗi khung hình?

Và nếu vậy, điều này đã thay đổi hệ thống theo cách thực tế nào?

Khi ban đầu nghiên cứu hướng đối tượng trong ngữ cảnh của C ++, tôi đã học được rằng một số người thích nghĩ về một tuyên bố xyz.doThis(x)như ý nghĩa 'gửi tin nhắn do This đến xyz (với tải trọng của x) và chờ phản hồi ngay lập tức'. Khi được xem ở cấp độ này, không có sự khác biệt nội tại giữa một hệ thống dựa trên sự kiện hoặc thông báo và hệ thống thủ tục thông thường.

— Kylotan
nguồn

Diễn viên là một giải pháp đa luồng. Các thông tin liên lạc không đồng bộ. Các tác nhân Scala (khái niệm từ Erlang) cho phép lập trình đa lõi dễ dàng.

— Ellis

Bạn có một điểm ở đó, nhưng điểm khác biệt ở đây là sprite dựa trên Actor không chặn vòng lặp trò chơi trong khi thực hiện hành động, trong khi phương pháp tiếp cận chờ đợi cho đến khi xyz.doThis(x)hoàn thành. Tôi nghĩ rằng điều này thậm chí có thể giúp làm cho logic trò chơi nhanh hơn, đặc biệt là trên các hệ thống đa lõi.

— Lanbo

Nó làm cho nó dễ dàng hơn để phân phối xử lý thực thể trên nhiều lõi, đúng. Nhưng cái giá phải trả là bạn không thể dễ dàng giới thiệu từ diễn viên này sang diễn viên khác mà không cần thêm tin nhắn hoặc dữ liệu bổ sung được gửi trong tin nhắn. Vì vậy, bạn nhanh chóng nhận ra rằng cách tiếp cận ngây thơ ở đây không giúp ích gì cho bạn - bạn có thể hình thành cách thức thực hiện các cập nhật dựa trên diễn viên không?

— Kylotan

Hiện tại, tôi đang thử nghiệm một số loại cập nhật phân tán: Các tác nhân của tôi giống như các nút trong cấu trúc cây và cập nhật gốc cập nhật cho trẻ em, bằng cách phân phối tin nhắn. Ngoài ra, lợi thế thực sự sẽ là kết nối mạng: Trong Scala, Actor và RemoteActor (Actor trên hệ thống khác) có thể được xử lý theo cùng một cách, bằng cùng một thông điệp.

— Lanbo

Vâng, nhưng vấn đề không phải là kích hoạt bản cập nhật như vậy, nó đảm bảo người nhận tin nhắn có tất cả thông tin cần thiết để hành động.

— Kylotan

0

Đó là một cách tiếp cận tuyệt vời để suy nghĩ về việc cập nhật các đối tượng trò chơi của bạn. Tôi không biết Scala, nhưng tôi nói hãy thử và xem nó như thế nào, và thậm chí tốt hơn là đăng kết quả của bạn!

Các câu hỏi chính nảy ra trong đầu tôi là: Làm thế nào để bạn quản lý tần suất một số đối tượng trò chơi cập nhật so với những người khác? Bạn có cần phải lo lắng về việc các diễn viên sprite chiếm quá nhiều chu kỳ sao cho hệ thống kết xuất không có thời gian để vẽ khung hình cứ sau 1/60 | 30 | 24 giây không?

Một điều khác cần xem xét là làm thế nào điều này sẽ ảnh hưởng đến độ phân giải của người chơi và các tương tác AI dựa trên thứ tự của một chuỗi các sự kiện rất nhanh. Tùy thuộc vào loại trò chơi, điều này có thể không quan trọng lắm.

— michael.bartnett
nguồn

Điều tuyệt vời về Scala Actors là họ điều khiển thông điệp. Mỗi người trong số họ có một tin nhắn / hàng đợi sự kiện riêng. Tôi không chắc chắn 'Vẽ' nên là một tin nhắn hay một phương thức cho cuộc gọi. Tôi nghĩ nó sẽ là cái thứ hai, để Sprite có thể được rút ra bất cứ lúc nào, bất kể trạng thái của hàng đợi sự kiện của họ. Và họ có thể gửi tin nhắn cho nhau để đảm bảo mọi việc được thực hiện theo một thứ tự nhất định.

— Lanbo

Hãy cẩn thận ở đó, tôi không nghĩ rằng mỗi sprite có phương thức Draw hoặc sự kiện sẽ hữu ích, ngoại trừ có thể là một lá cờ để chuyển đổi khả năng hiển thị. Trong giai đoạn kết xuất của một vòng lặp trò chơi, thứ tự các họa tiết được hiển thị trên màn hình có ảnh hưởng lớn đến kết quả. Nếu bạn có một sprite nằm ở phía trước cái kia (chiều hướng về phía màn hình), bạn muốn cái đó được vẽ thứ hai. Tôi thấy các diễn viên của Scala rất hữu ích cho phần cập nhật / logic của vòng lặp trò chơi.

— michael.bartnett

Thông thường, bạn chỉ có một phương thức vẽ ở đó, vì vậy bằng cách thực hiện theo cách đó, sẽ không có nhiều sự khác biệt so với cách xử lý thông thường với các họa tiết.

— Lanbo

À không sao, tôi đã hiểu nhầm những gì bạn đang mô tả. Tôi bằng cách nào đó tưởng tượng các họa tiết tự thể hiện bất cứ khi nào và tuy nhiên họ vui lòng. Hãy cho chúng tôi biết làm thế nào điều này bật ra!

— michael.bartnett

0

Chà, tôi cũng không phải là một lập trình viên, nhưng tôi không thấy có vấn đề gì trong đề xuất của bạn. Tôi thậm chí không nghĩ ra cách phát triển diễn viên như vậy.

Nó có thể là một thách thức khá lớn, vì IA phải rất chính xác, để tránh hành vi không bị ảnh hưởng, nhưng bên cạnh đó, tôi thấy đó là một đề xuất khá tốt

— Carlos Valenzuela
nguồn

0

Nếu bằng sprite, bạn có nghĩa là thực thể trò chơi thì chắc chắn.

Thực thể trò chơi không bao giờ nên tự vẽ. Họ nên cập nhật một tay cầm đồ họa mô tả vị trí và cách họ cần được vẽ. Hệ thống kết xuất hoặc biểu đồ cảnh hoặc bất cứ điều gì làm bản vẽ thực tế. Có một card đồ họa, hơn nữa card đồ họa phải được đồng bộ hóa sau mỗi 16ms. Một thiết lập như thế chỉ không hoạt động tốt để xử lý không đồng bộ phân tán.

Hệ thống kết xuất phải là một diễn viên (hoặc có thể là một cặp nếu bạn khéo léo). Khi các thực thể trò chơi cập nhật xử lý đồ họa, nó sẽ gửi tin nhắn đến hệ thống kết xuất. Hệ thống kết xuất, họ có thể đưa ra tất cả các loại quyết định và / hoặc tối ưu hóa, ví dụ như kết xuất hàng loạt, tắc, làm mịn jitter vật lý, v.v.

Tôi không phải là nhà phát triển Scala, nhưng tôi đã làm khá nhiều với Erlang. Vì vậy, nếu một số thuật ngữ Scala của tôi không chính xác, xin vui lòng tha thứ cho tôi.

— deft_code
nguồn