CODEWITHSUNDEEP
c#.netwinformsdesign-patternsgame-engine
user2757243
user2757243

Reputation: 81

What is the best aproach to design this kind of c# game?

I am developing a single form c# game that is composed o many user controls , credits panel , history panel of game actions and so on. I have developed a Manager class to separate Interface from "game engine" , this Manager class is responsible for all game logic. But i am not satisfied with my solution.

So here is the question what would be the best aproach for this kind of situation ?

A form full of user controls exposing its objects through public properties and a Manager class to deal with "the engine" ? What kind of design pattern could be used ?The game is a c# version of SicBo.

Many thanks in advance

Upvotes: 1

Views: 440

Answers (3)

Weyland Yutani
Weyland Yutani

Reputation: 4960

You've already made the first key step of separating the interface from the engine. Further gains can be made by splitting apart the engine and interface into lesser components. Eg into input controller, renderer, animation manager, turn system, units/cards/pieces or whatever.

People can tell you stuff, but my advice is not to dive in on the first game expecting to get the design right. Plan to improve design with each game you write and learn from personal experience. Accepting that your early games will have bad design will free you to be more productive. It's more important to maintain a tempo and not get bogged down in design decisions and thinking about patterns. A finished game with messy code is a game. A well designed game that is never completed is not. Some of the most productive (amateur) game developers I know of have written horrendous code in their initial games. They just plowed through it and got it done.

Upvotes: 2

Adam Kewley
Adam Kewley

Reputation: 1234

You'll want to separate concerns if your game is going to be more complicated than a simple maze or something. Another commenter has mentioned MVC. I'd reccomend that advice also (although experienced game developers will certainly have a more suitable approach).

I'd approach it in a few steps: Model, Manipulation, and Interaction

Model

First, think about what state you will allow your game to be in. For example, In chess, there's a board containing 8x8 square of locations, two players, and pieces that belong to either player that must occupy an unoccupied square. So your first step would be to think about how you'd model the allowed states the game may be in:

interface IChessGame
{
    IPlayer PlayerA { get; }
    IPlayer PlayerB { get; }
    IChessBoard ChessBoard { get; }
}
// Etc etc.

That part is quite fundamental. The robustness of your model will have a large effect on how easy it is to implement the next steps.

Manipulate

Next, think about how that state may be manipulated by your game, application, etc. These will eventually be components of your commands. Taking a static example:

static IChessGame MovePiece(IChessGame oldState, IChessPiece chessPiece, int[,] newLocation)
{
    // Check the chess piece.
    // See if the new coordinates are allowed for that piece.
    // Deal with any collisions (e.g. if an opponents piece is in the square then kill it, if it's your piece then block the move, etc.)
    // Generate a new, allowed, state
}

Now you have commands that may manipulate the state of your game. How you design these will depend heavily on your model approach (mutable, immutable, contains contentChanged events, etc.)

Interaction

Now you have a model that represents the state of your game and tools to manipulate that state. The final stage is to design a method by which your user can start to work with that, that's the UI/console.

This will change alot depending on how exactly you've done the other two steps but I'd highly recommend doing the previous steps without worrying about your interaction.

Upvotes: 1

Sherlock
Sherlock

Reputation: 5627

Maybe you are looking for the MVC pattern. I'm no game developer but this is a standard for apps and I use it for most projects.

There are a lot of resources on how to use this pattern. This link will show an example of how to use it in game design specifically.

The MVC pattern will help you separate your 'engine' from your 'user controls' using your 'manager'.

Based on your question it sounds like you're doing it like this already ... ? Why are you unhappy with your current solution ?

Upvotes: 0

Related Questions