Công cụ cho một trò chơi dựa trên web cuối cùng có nên bắt đầu như một dịch vụ web không?

Gần đây tôi đã quyết định bắt đầu viết một công cụ cho một trò chơi bài. Tôi không phải là người chơi "thẻ" lớn, nhưng một người bạn đã giới thiệu cho tôi trò chơi (đó là trò chơi xoay quanh trò chơi tiếng Đan Mạch), và tôi đã yêu.

Tôi muốn phát triển trò chơi theo 3 phân đoạn:

1. Các công cụ cơ bản, xử lý thẻ / sàn / gamestate, vv
2. Giao diện người dùng (ở dạng ứng dụng web trên thiết bị di động / máy tính để bàn.)
3. Một trí tuệ nhân tạo với các chiến lược / khó khăn khác nhau, v.v.

Đây là những dự án rất khác biệt, trong suy nghĩ của tôi ... và tôi đang vật lộn để xem làm thế nào tất cả chúng sẽ phù hợp với nhau trong thời gian dài. Lúc đầu, tôi thậm chí không muốn "chơi" trò chơi bằng cách sử dụng công cụ này. Động cơ chủ yếu sẽ được kiểm tra bằng các bài kiểm tra đơn vị của nó. Chơi thử sẽ không bắt đầu cho đến khi khách hàng tồn tại. Vì vậy, có một cái gì đó của mối quan hệ máy khách-máy chủ ở đây.

Động cơ là một mảnh rất lớn của câu đố. Điều tôi muốn biết là: bạn sẽ phát triển "API công khai" cho công cụ này như thế nào?

Tôi đã nghĩ rằng công cụ này có thể là một dịch vụ web rất cơ bản, trả lại trạng thái của nó thông qua các truy vấn cho API RESTful, nhưng tôi lo lắng rằng việc phát triển công cụ này như một ứng dụng web có thể dẫn đến các quyết định lập trình kém. (Ví dụ: nếu tôi chọn khung vi mô MVC, thì API này sẽ không thực sự có lượt xem ... nó chỉ trả về các đối tượng được tuần tự hóa thông qua JSON hoặc một cái gì đó cho hiệu ứng đó. Thật tệ khi sử dụng MVC cho một dịch vụ như điều này? )

Ý tưởng khác của tôi là công cụ này sẽ chỉ là một ứng dụng giao diện điều khiển và sau đó tôi sẽ viết một cây cầu nào đó để nối dữ liệu giữa nó và ứng dụng web. (Cây cầu thực sự có thể là bất cứ thứ gì. Ý tôi là, máy chủ web và công cụ trò chơi có thể nhàn rỗi trong máy chủ IRC và chia sẻ trạng thái của chúng trong các kênh.)

Cách tiếp cận nào bạn sẽ thực hiện (phát triển như một dịch vụ web hoặc phát triển như một ứng dụng độc lập và kết nối nó sau này), và tại sao?

Cảm ơn, Robbie.

EDIT: Vì vậy, tôi đoán điều này thuộc về Phát triển trò chơi. Để làm rõ, tôi sẽ viết một công cụ trò chơi bài. Tôi đang cố gắng tìm ra cách tốt nhất để đưa ra API của công cụ để nó có thể được tích hợp trong tương lai với ứng dụng web và ứng dụng khách AI.

Tôi thậm chí còn không có tài khoản ở đây, vậy hả :)

Các tuyến dịch vụ web có lẽ là tốt nhất và có thể mở rộng nhất.

Tôi cũng thấy hoàn toàn KHÔNG có vấn đề gì khi sử dụng khung MVC để trả về JSON (asp.net mvc rất tuyệt ở đây). Nếu bộ điều khiển của bạn chỉ trả về JSON lúc đầu thì tốt, bạn có thể kiểm tra đơn vị mà không có bất kỳ chế độ xem nào. Khi bạn đã sẵn sàng để thêm giao diện trò chơi của mình, bạn có thể thêm lượt xem. Nếu html / css hoặc flash / silverlight đơn giản của họ, điều đó không thành vấn đề bởi vì, như bạn đã nêu, bạn đã xây dựng công cụ cơ bản.

Tôi không chắc môi trường phát triển hoặc lưu trữ của bạn trông như thế nào nhưng tôi sẽ không vượt qua nó. Một tập hợp các tệp php đơn giản trả về JSON có thể là tất cả những gì bạn cần. Tôi không quen thuộc với trò chơi mà bạn đang xây dựng, vì vậy tôi không chắc nó sẽ phức tạp đến mức nào.

Theo tôi, nếu bạn là người mới phát triển trò chơi và bạn sẽ tự mình làm điều đó, tôi khuyên bạn nên lấy thứ gì đó có thể chơi càng sớm càng tốt, bởi vì nó sẽ giúp bạn có động lực hoàn thành trò chơi và đánh bóng nó đến một mức độ tốt.

Một khung nhìn là một thực thể đăng ký một mô hình sẽ được thông báo khi thay đổi xảy ra.

Nếu mô hình của bạn nằm trong một máy chủ web, bạn gặp vấn đề vì HTTP không thực hiện một cách rõ ràng để cho phép máy chủ bắt đầu giao tiếp. Bạn có thể sử dụng websocket để xử lý việc này nhưng bạn sẽ hy sinh một số "RESTfulness" của mình ... Tôi nghĩ rằng một giải pháp tốt có thể là để URL web của bạn xác định mô hình và sử dụng đẩy máy chủ HTTP để cho phép quan điểm của bạn được thông báo Khi cần thiết.

Hãy nói rằng bạn có một trò chơi đang chạy

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/

bạn có thể sử dụng URL

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/playCard?id=3&place=stack 

để sửa đổi mô hình và

/games/cd073ac6-c37e-431f-9a5e-7b61bfacf9be/notify 

để chờ thông báo.

Thông báo sẽ chờ - trong một khoảng thời gian - để nhận được tin tức của người mẫu: nếu có thông báo nào đó sẽ gửi tin nhắn (dữ liệu nào được thay đổi hoặc loại sự kiện nào xảy ra hoặc bất cứ điều gì).

Khách hàng có thể thực hiện một yêu cầu ajax dài tới / games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / thông báo và đăng ký một cuộc gọi lại thông báo sẽ cập nhật chế độ xem và đăng lại yêu cầu thông báo tiếp theo.

Nếu games / cd073ac6-c37e-431f-9a5e-7b61bfacf9be / thông báo hết thời gian chờ trên máy khách, một yêu cầu mới được thực hiện, nếu hết thời gian trên máy chủ, tài nguyên được phân bổ sẽ được giải phóng.

Bạn có thể xây dựng một hệ thống thông báo khá chung trên máy chủ của mình và thư viện thông báo trên máy khách của bạn để bạn có thể xây dựng một MVC nhất quán trên một lớp thông báo trong suốt.

Nếu bạn đang tìm kiếm một công nghệ, bạn có thể xem xét để xây dựng công cụ trò chơi của mình trên máy chủ Couchdb. Couchdb là một DBMS REST không liên quan, sử dụng HTTP làm giao thức và JSON làm định dạng tài liệu. Nó cũng có thể PUT và GET các tệp nhị phân hoặc HTML dưới dạng tệp đính kèm để có thể viết một ứng dụng web đầy đủ chỉ bằng DBMS (couchApp).

Có tồn tại một thư viện javascript để có thể phản ứng với các cập nhật cơ sở dữ liệu trong số những thứ khác. Một couchdbApp đơn giản là một cơ sở dữ liệu để bạn có thể sao chép một ứng dụng sang một máy chủ khác bằng cách đồng bộ hóa: khách hàng của bạn có thể sao chép ứng dụng của bạn sang máy chủ cục bộ của họ và sau đó phát qua mạng LAN bị vi phạm.