Jump to content

  • Log In with Google      Sign In   
  • Create Account


Card Games, Hex Battlefields


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 ChrisAMazur(ing)   Members   -  Reputation: 148

Like
0Likes
Like

Posted 18 November 2013 - 05:11 PM

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.

 

 



Sponsor:

#2 jHaskell   Members   -  Reputation: 988

Like
5Likes
Like

Posted 19 November 2013 - 07:52 AM

You should start thinking at a bit higher level and develop classes to encapsulate the underlying containers and desired behavior and provide a more intuitive interface.

 

For example, instead of working with a linked list of cards, develop a Deck class that encapsulates and hides that linked list (or whatever container is used) and instead provides an interface of capabilities you need to perform on a deck of cards; shuffling, dealing, etc.

 

Same thing with your battlefield.  Don't interact with the 2D array directly.  Implement an interface that allows you to 'do what you want'.  Hiding those containers and providing battlefield and deck specific interfaces for interacting with them are the main steps to eliminating that clumsy and basic feel.



#3 ChrisAMazur(ing)   Members   -  Reputation: 148

Like
0Likes
Like

Posted 19 November 2013 - 02:30 PM

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?



#4 jHaskell   Members   -  Reputation: 988

Like
1Likes
Like

Posted 19 November 2013 - 03:58 PM


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.



#5 ChrisAMazur(ing)   Members   -  Reputation: 148

Like
0Likes
Like

Posted 19 November 2013 - 09:18 PM

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.



#6 jHaskell   Members   -  Reputation: 988

Like
1Likes
Like

Posted 20 November 2013 - 07:30 AM


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



#7 Paragon123   Members   -  Reputation: 434

Like
2Likes
Like

Posted 21 November 2013 - 03:43 PM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS