2010-07-21 29 views
5

Là dự án WPF đầu tiên của tôi, tôi đang cố gắng xây dựng một ứng dụng để chơi trò chơi bài tương tự như Magic the Gathering. Nó không phải là rõ ràng với tôi làm thế nào để lay ra khu vực chơi chính. Bạn có thể xem một số ví dụ tương tự với những gì tôi đang cố gắng bằng cách xem example 1 hoặc example 2. Các khu vực trò chuyện/thông tin ở bên phải sẽ là các điều khiển người dùng riêng biệt.Bố trí WPF cho trò chơi bài phức tạp

Thẻ phải duy trì tỷ lệ khung hình của chúng và mỗi khu vực phát sẽ bắt đầu bằng 10 cột và hai hàng thẻ. Khi có nhiều thẻ hơn, số cột và/hoặc hàng có thể thay đổi. Mỗi khu vực người chơi có thể có một số cột và/hoặc hàng khác nhau. Thẻ có thể chồng lên nhau và có thể được đặt ngang (khai thác). Thẻ ở tất cả các khu vực phải có cùng kích thước (mặc dù chúng có thể bị cắt ở một số khu vực). Thẻ không cần phải nằm chính xác trên lưới (chúng không nhất thiết phải chụp vào lưới).

Khi người dùng di chuột qua thẻ, thẻ sẽ mở rộng thành kích thước lớn hơn đáng kể bằng cách sử dụng hoạt ảnh. Một thẻ trong một khu vực người chơi có thể tràn vào khu vực của người chơi khác khi được mở rộng (nhưng chỉ miễn là con chuột di chuyển).

Với những yêu cầu này, tôi bị cám dỗ sử dụng một điều khiển người dùng lớn có nguồn gốc từ Canvas với các đối tượng hình ảnh cho mỗi thẻ (cùng với các hình khác để phân định các khu vực). Điều này ngụ ý rằng tôi sẽ làm rất nhiều công việc trong sự kiện OnRenderSizeChanged để định vị các mục con trong canvas (bố cục thủ công).

Việc sử dụng lưới điện dường như không khả thi đối với tôi, do vị trí dạng tự do và trùng lặp.

Phân chia khu vực phát thành điều khiển người dùng nhỏ hơn sẽ tận dụng khả năng bố trí WPF, nhưng có vẻ như quá trình phân tách sẽ ngăn các thẻ mở rộng vào các điều khiển người dùng liền kề trong khi di chuột qua, điều đó dường như không khả thi.

Có cách nào thay thế tốt hơn cho một kiểm soát dựa trên canvas lớn không? Có vẻ như sai khi thực hiện bố cục thủ công trong WPF, nhưng tôi không thể thấy một giải pháp thay thế.

Trả lời

0

Tôi khuyên bạn nên xem this guys project. Trong java tôi biết nhưng nếu tôi đã đi con đường xây dựng một trò chơi thẻ. Đó sẽ là những gì tôi sẽ đi.

+0

Cảm ơn bạn đã liên kết, nhưng giả mạo được viết bằng java và tập trung hơn vào việc có AI để chơi trò chơi (một vấn đề khó khăn hơn nhiều). Mục tiêu của tôi là cho phép hai người chơi qua kết nối internet. Có một dự án dựa trên WPF tương tự (http://moxdev.wordpress.com/) là nơi mà ý tưởng mở rộng thẻ xuất phát từ đó. Anh ấy cũng đang sử dụng một bức tranh (tôi tin), nhưng nó vẫn có vẻ hơi sai khi lạm dụng một bức tranh theo cách đó. – Doug

0

Rất nhiều canvas bên trong lưới có thể giúp bạn ở đây, canvas sẽ cho phép nội dung hiển thị bên ngoài giới hạn của nó, miễn là bạn chuyển ClipToBounds thành sai và bạn sẽ được kiểm soát nhiều hơn vị trí chính xác của các thẻ hơn với các lược đồ khác. Bạn cũng sẽ nhận được chức năng mạnh mẽ của điều khiển lưới, cho phép bạn thêm và xóa các cột và hàng khi cần thiết (mặc dù bạn cũng sẽ phải thêm và xóa tự động các đối tượng, mặc dù điều này không quá khó.

Nếu bạn lo lắng về nội dung của "Thẻ" của bạn di chuyển xung quanh khi hộp được rescaled, bao quanh nó trong một viewbox.Nó sẽ quản lý tất cả các quy mô của bạn cho bạn, và đảm bảo thẻ của bạn sử dụng càng nhiều bất động sản như nó có thể nhận được. có thể sử dụng một RenderTransform, nhưng rất nhiều trong số này có thể làm chậm chương trình của bạn xuống (Các chuyên gia: không hoạt động bằng cách sử dụng RenderTransforms? Nếu vậy điểm này là moot)

Để đảm bảo thẻ duy trì tỷ lệ khung hình của chúng được đặt thành "Đồng bộ", khiến tất cả đều được giữ kích thước tương tự có thể được thực hiện bằng cách chỉ định thẻ chính và chiều cao và chiều rộng của tất cả các thẻ tiếp theo cho thẻ gốc này, mặc dù đó là một chút lộn xộn và không cho phép thẻ mở rộng. Một giải pháp khác là đặt một kích thước cho mỗi thẻ theo cách thủ công, làm động tác này khi bạn muốn mở rộng hoặc thu nhỏ.

+0

Nếu ông sử dụng một RenderTransform nội dung có thể được trả lại bên ngoài giới hạn của nó, dù sao, không cần phải thiết lập các thuộc tính khác. Ngoài ra, ông có lẽ nên sử dụng ItemsControls chứ không phải là canvas động, vì sau đó ông có thể sử dụng công cụ liên kết và liên kết với các bộ sưu tập thay vì liên tục cập nhật và tạo canvas mới trong mã. – Charlie

+0

Ý tưởng hay, nhưng anh ấy vẫn cần sử dụng canvas để đặt mục chính xác, dịch chúng từ điểm cố định có thể quá phức tạp. Mặc dù canvases có thể được tạo ra như một phần của ItemsTemplate cho một điều khiển cha. –

2

Điều này nghe giống như một kịch bản tuyệt vời cho Ứng dụng tổng hợp ala Prism.Nó cung cấp khung vững chắc cho việc thực hiện các vùng, mô-đun, gửi thông điệp giữa các mô-đun vv ... Từ việc nhìn vào màn hình của bạn, việc phát triển một trình bao với các vùng khác nhau và thả mô-đun vào chúng sẽ rất có lợi cho bố trí của bạn. Đối với bản thân các thẻ, có lẽ chúng cũng có thể là các mô-đun?

Check out: http://msdn.microsoft.com/en-us/library/ff649780.aspx

Particualy ví dụ tốt đi kèm với các gói tải về bao gồm thị trường chứng khoán và sự kiện như ứng aggregator ví dụ.

+0

Tôi không chắc chắn có thẻ như mô-đun sẽ rất hiệu quả, nhưng khác hơn thế, Prism sẽ giúp đỡ rất nhiều. –

+0

Tôi đã nhìn một chút lăng kính, và thú nhận tôi đã bị mất một chút. Nó không phải là rõ ràng với tôi như thế nào nó sẽ giúp, như phối hợp các kích thước thẻ giữa các khu vực có vẻ khó khăn khi cửa sổ được thay đổi kích cỡ. Có một thẻ tràn khu vực của nó và phủ một khu vực khác trong quá trình mở rộng chuột cũng có vẻ phức tạp. – Doug

+0

Điều này có thể hữu ích, nhưng có lẽ sẽ chỉ thêm sự phức tạp không cần thiết cho một vấn đề WPF có khả năng tự xử lý tất cả. – Charlie

2

Bạn nói:

Phân rã các khu vui chơi vào điều khiển người dùng nhỏ hơn sẽ thúc đẩy khả năng bố trí WPF, nhưng nó có vẻ như phân hủy sẽ ngăn chặn các thẻ từ mở rộng sang điều khiển người dùng liền kề trong mouse-over, vì vậy điều đó dường như không khả thi.

Nhưng điều này không chính xác. Phân hủy là cách tiếp cận hoàn toàn phù hợp, và điều này sẽ không ngăn các thẻ mở rộng sang các điều khiển người dùng lân cận. Lý do là bạn có thể sử dụng RenderTransform thay vì LayoutTransform. Xem this example, của Charles Petzold hoặc this article để hình dung sự khác biệt. Bởi vì RenderTransform được áp dụng sau khi bố cục đã xảy ra, thẻ của bạn sẽ có thể mở rộng ra ngoài giới hạn của chúng.

Do phân tách đó là cách tiếp cận đúng, tôi sẽ sắp xếp các bộ sưu tập thẻ khác nhau của bạn thành Grid, với mỗi bộ sưu tập là ItemsControl. Các ItemsControl nên ràng buộc tài sản ItemsSource của nó để một số bộ sưu tập, và sau đó bạn có thể cung cấp một tùy chỉnh ItemTemplate mà sẽ hiển thị hình ảnh và bất kỳ thông tin khác. Tôi sẽ do dự khi sử dụng một Canvas, vì điều này sẽ hạn chế bạn mã hóa cứng các vị trí cho các thẻ (đó là một giải pháp rất giống WinForms cho một vấn đề có thể được giải quyết một cách thanh lịch hơn nhiều). Tận dụng lợi thế của công cụ bố trí tuyệt vời của WPF và sử dụng lưới lồng nhau và các mục điều khiển để tạo bố cục động. Điều này sẽ đảm bảo rằng bảng trò chơi của bạn có vẻ tốt ở mọi độ phân giải và khi được kéo dài đến các kích thước khác nhau.

+0

Cảm ơn bạn đã cung cấp thông tin hữu ích. RenderTransform sẽ giải quyết vấn đề tràn thẻ. Tuy nhiên, một vấn đề khác với sự phân hủy là giữ các thẻ có cùng kích thước trên tất cả các trẻ em. Ví dụ, hãy xem xét điều khiển vùng chứa mẹ và hai điều khiển con (một cho thẻ của mỗi người chơi). Khi cửa sổ bên ngoài được thay đổi kích cỡ, tôi cần tính toán kích thước thẻ mới dựa trên khu vực trẻ em nào có nhiều thẻ nhất. Có một sự kiện tôi có thể móc trong thùng chứa sau khi trẻ em đã được định vị (và kích cỡ) để tôi có thể tính toán kích thước thẻ và gửi cho trẻ em không? – Doug

+4

Thay vì dính vào một sự kiện, bạn nên liên kết kích thước thẻ (đối với tất cả các thẻ) với một thuộc tính nhất quán duy nhất trên kiểu xem của bạn. Sau đó, khi một khu vực con tăng hoặc mất một thẻ, bạn tính lại kích thước tài sản này, và tất cả các ràng buộc được cập nhật tự động. – Charlie

Các vấn đề liên quan