Question Game Architecture is troubling me.

Hello everyone,

right now I am dabbling a bit at creating a game, but I always run into issues regarding on how to structure my agame and how to connect all the little pieces.

The game I'm working (very early) on basically combines a (Hexagon) Grid and Roguelike Deckbuilding. A bit similar to Alina of the Arena or Fights in Tight spaces, it however will have a specific twist regarding how turns and card costs work.

But basically I feel quite ocnfident in my basic coding, but always run into trouble when I have to connect two things that don't have a "natural" feeling connection.

An example of a natural connection would be:

• Player (MonoBehaviour) contains a Deck (Plain C#)
• Deck contains Cards (Plain C#)
• Cards are a Wrapper Class for a CardObject (Scriptable Object)
• CardGroupObejct contain a list of CardObjects, and serve as a deck constructor for example. (or later on make up the draft-pool)
• CardView (MonoBehaviour) contains a Card and basically does the visuals and serves as an input-point.

A lot of things in this structure use the ObserverPattern which worked quite well for this.

But these cards need to effect the grid and get information from the grid. And this is were I always question myself if there is a better way to to stuff.

Right now I abuse the in-scene monobehaviours to make the connections. A PlayerController (which executes the CardViews among other things) basically just has a reference to a HexMapView Monobehaviour and the Player Monobehaviour and passes everything needed down the methods.

And my feeling tells me there probably is a better way to do this. Btw I would also share the small amount of work I have done so far on the project if someone would be interested in giving me feedback.

Good Day everybody.

 

If you're talking about observers and views, you're trying to solve this through inheritance.

I recommend to look at component-based design unity employs by default. That means using very shallow hierarchies.

For example, you only need VIEW classes when ther's more than one way to represent the MODEL. If there's only one view, you don't need a view class.

For example, in your case, you could go with following scheme:
There's a battlefield that has combatants in it, and there's a card area where cards are placed. And when a card is placed, some specific effect happens.

So. Instead of abstract idea of "views" you'd have very concrete things. Battlefield, combatant, card, effect. Try thinking about that.

 

So you mean I should scrap that kind of layering whenever possible?

For cards I went with Card and Cardview so I could have cards exist in a deck without having an actual GameObject when not currently having it in hand. Is that a sensible thing to do?

 

Game Programming Patterns

this has helped me a lot^

 

//opinion
I follow principles of KISS and YAGNI. Meaning solution should be simple, and things you you won't need must be scrapped.

In your case a good idea would be to first make a solution that WORKS, and then you can think how to make it pretty. If you start by making it pretty, but it doesn't work, then what's the point in making it pretty.

 

Are you an experienced programmer or not? If not, try breaking your game into chunks: imagine that coding does not exist and that the only things that you can do is by using magical blocks that do stuff, take input in and so on. Do you need to use multiple blocks, each with their own specific function? Perhaps you don't need all the blocks and some things can be joined together, into one single block. This approach is often used when teaching people that are not that tech-savvy anything related to programming and frankly, it's quite useful (on par with the famous rubber duck debugging).

 

Avoiding preliminary optimizations should be placed much higher in the invisible hierarchy of "things-each-and-every-dev-should do" (imo) and sometimes, it should be placed even higher than KISS (at least for Unity/C# devs)(also imo).