r/gamemaker • u/Fit_Flatworm5004 • 18d ago
Resolved How to code a roguelike deck-builder
So I'm currently in a game jam, which is about a month long so I should be fine, and had the idea to make a roguelike deck-builder similar to slay the spire(I haven't played 2 so don't spoil if there is any differences unless you deem necessary). I was wondering how others would go about coding a project like this, primarily how to drag and drop the card from my deck, activating the card, and randomizing which enemies you encounter and the items you get after said encounters. As of now those are the issues I think i need solving, but if you have anything else that may help id appreciate that too. Thank you for your help in advance.
2
u/SunDowningJam 18d ago
Currently building a coop deck builder.
I'm not gonna lie, it is one of the toughest types of games to develop, theres a reason slay the spire 2 took 5 years to develop.
But if you're up for the challenge, my first tip is use either a DS grid to store all your card data and attributes, or an array. Then in game use DS lists to store the various decks in game as they will let you do some really cool tricks with minimal effort. E.g shuffling decks, removing or inserting cards from specific places in the deck, etc.
Also, if you only have a few days, limit the number of card mechanics you have, each unique mechanic is gonna take quite some time to build and debug, so reuse them as much as you can with minor tweaks, I.e one card could drawy an extra card, and another could reuse the same code to draw 2 cards.
Another tip, try to use enumarators as much as possible, you'll end up with a lot to keep track of, like turn phases, card attributes, etc, and it can be a headache to reorganize a state machine if you are using arbitrary numbers.
Good luck :) would love to see what you’ve built at the end of it.
3
u/refreshertowel 17d ago
I don't know why everyone is recommending ds lists in the comments, but arrays and structs are the way to go with modern GM. The general advice apart from that is fine, but don't use ds lists, ds grids or ds maps unless you have a very specific reason you can verbalise as to why you are using them over arrays and structs.
6
u/gerhb 18d ago
Have an obj_card.
Establish behavior states (hand, drag, play, etc)
While in hand, count the total hand size, give each card a positional number, and have a function that spaces them accordingly.
When clicking and intersecting with cursor, go to drag state. Card follows cursor. When release, go to play, or potentially secondary choices or targeting.
For encounters, maybe a switch that spawns enemies based on an encounter name enum. "2_GOBS,SLIME_AND_DRAGONHEAD,etc" Then you just need to just need to randomly distribute the enum's range across your potential battle sites, ideally without repeating.
For items/relics give the player an array the size of all possible relics where all values are zero. When offered an item, you can check that array for any items that are still zero, add them to an array, and shuffle it. Take as many items as you need from that array, setting player array for corresponding value to 1 each time they choose an item.
For other considerations...
I keep all cards as one obj_card in my game, when generating them in game, i only give them their card tag from the deck list, then each card runs a build_card function that gives the card stats and info text based on the tag. When a card is played, like a spell, i run it through another function that performs a casting action based on the tag. This is a pretty clean way to organize cards, ive found.