Sign in to follow this  
Followers 0
ChrisAMazur(ing)

Card Games, Hex Battlefields

6 posts in this topic

Hello Gamedev! I'm here because my google-fu has been exhausted; any help is appreciated.

 

tl;dr - How should I go about representing a 2 Dimensional grid-based battlefield, given that it has to hold a number of card objects and also its be able to represent its own state? What is the best way to implement a deck of card objects?

 

--

I'm currently working on a Card/Battlefield game, where you summon creatures, items, and spells using cards from a deck you build.

 

I'm having a bit of trouble, conceptually, on how best to represent the various states and positions of each card object in the deck and on the field.

 

Currently, I'm using a linkedlist of cards for the deck and hand, and a 2-D array of cards for the battlefield grid. It's pretty simple, and lets me do what I want with moving cards around and restricting their placements, but it feels clumsy and basic.

It also makes it difficult to implement things like Fog of War; I'd have to make a battlefield tile object and populate the array with them instead of cards, and there's a lot of space for things to go wrong for someone of my skill in that sort of case - though of course, it does work, and it does what I want - I'm just not confident I understand the languages I use well enough to catch all the issues with it, and there aren't many non-web places I can ask for help.

 

Thanks you for reading, and thanks for your time.

 

 

0

Share this post


Link to post
Share on other sites

Thanks for the help; what I've got right now is something like

Card{
Card info
}

Deck {
linked list of cards
Functions for the list
}

Battlefield Hex{
hex position
hex visibility
card info
}

Battlefield {
array of hexes
operations for the battlefield
}

My problem now is allowing battlefield hexes to have more than one card affecting them - like when two units fight, or when multiple spells are flung at a spot.

My initial response is a prioritized queue of cards that allows faster units to attack first, or faster spells to resolve first. Should this be part of the Hex, the Battlefield, or a completely separate manager (such as an overlay that has hexes corresponding to the battlefield, but only contains resolving effects, and applies the final resolved / combined effect to the battlefield) altogether?

0

Share this post


Link to post
Share on other sites


My problem now is allowing battlefield hexes to have more than one card affecting them - like when two units fight, or when multiple spells are flung at a spot.

My initial response is a prioritized queue of cards that allows faster units to attack first, or faster spells to resolve first. Should this be part of the Hex, the Battlefield, or a completely separate manager (such as an overlay that has hexes corresponding to the battlefield, but only contains resolving effects, and applies the final resolved / combined effect to the battlefield) altogether?

 

This largely depends on the nature of your spells. Are they targeted at specific cards, or just specific Hexes, or a combination of both?  If they're only targeted at other cards, it may not make sense to contain them within the Battlefield/Hexes.  If it's either of the other two, it probably does make sense to contain them within the Battefield. Regardless of where they are contained, any resolution of those effects and spells should be a separate class.  Build your gameplay on top of the Battlefield, not in it, but use the Battlefield as the container for your gameplay components where it makes sense (basically anything that applies to some area of the Battlefield).

 

If, however, the Battlefield and/or Hex classes are becoming bloated with lots of conditional code based on the type of item they contain, that's a strong indicator that you're sticking too much in them and some sort of refactoring should occur.  This may mean pulling some components out of the Battlefield and into some other container, or it may mean finding some common interface for the various components in the Battlefield and just pulling all the conditional code out to some higher level class that interact with the common interface.

1

Share this post


Link to post
Share on other sites

Thanks for reminding me about interfaces, wow!

Preferred functionality would be a 'State' interface of some kind that turns effects on and off on battlefield hexes, I think. And then, as you mention, perhaps something similar (would I be able to use the same interface on another instance?) for cards in hexes (i.e. something that affects a unit, but not the hex it's in).

Again, thank you so much for your help :) Design is a lot harder when you don't really know all of the options you have, or how to put them together.

0

Share this post


Link to post
Share on other sites


Preferred functionality would be a 'State' interface of some kind that turns effects on and off on battlefield hexes, I think. And then, as you mention, perhaps something similar (would I be able to use the same interface on another instance?) for cards in hexes (i.e. something that affects a unit, but not the hex it's in).

 

Again that will depend on how similar spells and cards are.  If they're mostly similar in the way they're handled and placed on the field, and only really differ in how they are used, then you could utilize a common interface, possibly even just the same class (as opposed to having a spell class and card class inherit from a common interface) via the Strategy pattern.  Your use() method would call the appropriate strategy for the object it's called on.  The strategy would get plugged into the object at time of creation.

 

http://en.wikipedia.org/wiki/Strategy_pattern

1

Share this post


Link to post
Share on other sites

I think you might want to look at it more as placed cards and targeted actions. Placed cards occupy a cell in the battle field, while targeted actions apply an effect to cards occupying a cell in the battle field (or the cell it's self).

 
Attacks could be treated similarly to playing a targeted Action, while Units with abilities to summon other units could be treated as playing a placed card when there ability is used. 

 

Then, decide if two placed cards are allowed to occupy the same battlefield cell. Allowing one vs many can be a simple as using a 2d array of lists of the type rather than just a 2d array of the type. I would assume that the upper limit of cards per cell would be fairly low, certainly it would be unwieldy to control 100+ cards on a single battlefield cell so it wouldn't require a very complex collection. For the code controlling which cards are active in which order i would suggest a priority queue like you mentioned, but it should be decoupled from the cards/battlefield it's self. I am not 100% certain how the game plays out, but I would think that the order in which spells/attacks affect a hex would be controlled by the order in which the cards/players where allowed to choose an action. In that case, maintaining a simple First in, First out queue would suffice.

2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0