Card RPG Game: Suggestions and advice!

Have any of you heard of Rage of Bahamut? It is an Android exclusive game that is addicting, but has major crash issues. I wanted to create my own version of the game, but far more simplified. A bit more detail about Rage of Bahamut...

It is a game all about collecting cards, leveling up the cards, and evolving the cards. You can get the cards via trading with other real players, by questing, treasures, or purchasing mobcoins by the game's "host", mobage. Treasures are obtained through quests, PvP duels, or by players donating their own treasures. The player, you, can also level up and gain points for stamina (which allows you to quest), attack (which allows you to initiate PvP duels), or defense (which allows you to prevent other player's from winning a PvP duel they initiated). During PvP battles, you may obtain treasures and/or just coins (the in-game currency) only. The in-game currency is used for evolving and leveling the cards (both of which is important for winning boss battles and PvP duels), and it's also used for donating to an order. An order is a guild that, when enough in-game currency has been donated, they may purchase perks that activate during PvP duels. Players may also obtain fellows, which give them additional points to spend on stamina, attack, or defense. The fellows are also used for boss battles that are at the end of sets of quests. The quests are used for obtaining cards, treasure, in-game currency, and experience points for the player to level. They also do bonus perks for daily log-ins, promotions, etc. An important feature of these perks are free "card packs". While they are called packs, the player only obtains one card per price. The price may be a ticket that is earned for reaching a certain level, or daily promotion feature, or for obtaining "friend points" by posting on other player's profiles once a day.

Now, this may seem like it's an advertisement, but this is not the case, I swear! I point out all these features and activities to help get an idea of what is possible with Game Maker. Most of the PvP, quest, card obtaining, etc actions are followed by a GIF, which is what causes the crash issues and has made me want to bring my own version of this game to the PC. I'm still rather a novice at Game Maker (only have made three basic games), though, so these may be over my head! I want to try anyways, and want people's advice about the best way to create a better version of this fun game for PC. This is a very fresh idea, however, and there is a lot that needs going over. Based off my description (or, if you've played the game, your own experience), what elements should I keep, what things would be difficult to do, etc etc.

If you have any questions, please feel free to ask! I will answer them to the best of my ability.

the easy way:
scrap the multiplayer features as i expect you have no experience of even basic multiplayer in game maker

next is just implement either a client server or client to client multiplayer just for pvp battles

and thirdly the more modern way of implementing it online like facebook games, either on a social network like such(whcih you can implement facebook feeds and such) and use their login service so you can keep track of the players and there stats

4th is probablyt the worse idea for you is to fully implement all the features but requiring you to host and make your own server database and login system for people to be able to connect to and keep track of there stats and still be able to play each other.

but i wouldnt scrap any of the gameplay features as you can easily get help from us lot when you get stuck.

You are very true that I have no experience with multiplayer with Game Maker. In fact, I was questioning whether it was even possible and recognized that I may need to do it. x3 With that acknowledged, I like your first and third suggestion. So, I have to ask: How would Game Maker be used to make a multiplayer game for a social networking website?

which then you host on your site(or a hosting site) and you go to facebook games dev section and create an app(after you have fully made a game in game maker html) and you tell it where it is and some more stuff(facebook has alot of tutorial documents on creating the facebook app part(not the game part)) they will give you a developer name, and app id

which in your code when ever you use some facebook feature you include in the function(a facebook API function) you include the developer name and ap ID. and facebook does the rest(assuming you used the right functions) ie. if you use a score funtion and fill it in correctly, facebook will creat a news feed saying "player x" just scored 2000points, and if it needs to will create a highscore if its new...

you can do all sorts just you have to learn some or all of facebooks api

i think one of the yoygames devs made a tiny facebook game. and ofcourse there is as little or as much of facebook integration as the developer needs. I read today another html5 game maker api that was for scores but not on facebook(assuming you didnt want to use facebook)

PS. the player needs to be running a html5 compliant browser(eg. a modern one) even works(aslong as you do it right) on ios and android. I was at confrence last week that had a facebook games employee talking about the new opengraph api features and facebook timeline, was interesting

Making a trading card game is a huge undertaking - a really experienced user (far beyond me, at least at that time) called GameGeisha tried once but for reasons I don't remember (likely the workload) abandoned the project.

If you're gonna make it anyway, my recommendation is to start from the root and then gradually add in more complex effects; aka start with a card shuffling engine, then add in card attributes like attack power and special effects. Most TCGs have really complex effects where every card has unique effects, so you're gonna have lots of trouble and need to hardcode every single one. Good luck, you're gonna need it.

0

- The above is my personal opinion and in no way representative of Yoyogames or the GMC, except when explicitly stated -

First off, Facebook stuff?! Man, they must've changed that... back when I was looking into developing stuff for Facebook it appeared to be limited to PHP and ASP. Makes me want to look into it again if it can use HTML5 and JavaScript...

Second off, that game sounds a lot like the Kingdom of Loathing ( http://www.kingdomofloathing.com/ ), but with cards. You didn't exactly describe the graphics, but if you do something KoL style (the entire game is pretty much text with some very simple drawings as graphics) then that could help take a lot of the work of it (graphics-wise at least).

Here's my suggestions...
- do not do his first idea (removing the multiplayer features), as it seems the multiplayer features are a major part of what makes that game any good and not just a generic single-player "go questing and stuff" game (not to mention that if you make it entirely single-player you'll need to do a better job with the AI in order to keep the game challenging)
- if you do choose to not include multiplayer features, at least program it in such a way that adding those features will not be impossible or too difficult (for when you become more experienced and decide to add the features, or if you choose to give the source code to someone with experience to add the features for you).
- most of what you said can probably be achieved with the mplay functions... no need to even use a server. But with no server you wouldn't be able to include some of the features you've mentioned (guilds, for example. Or any quest that requires the player to be online)

Also, overall multiplayer games are more difficult to make, even if you know what you're doing, simply because it's more difficult to test.

And I don't think you're asking for this, but an improvement I would make would be to instead of only giving one card per pack... include like 5 or 10 cards per pack. And maybe have some in-game card stores (which sell individual non-random cards, but for a high price), in-game trades, and the option to sell cards to other players (which would usually require a server).

Thank you Yal and Danny for your advice and suggestions! I know that this will be a large workload; heck, any game more complicated than a platformer is a workload! I do plan to start from the very basics, and gradually add the more complicated features. There is many benefits to this, the key being I'm still a newb and it's the best way for us to learn. ;3 I expect this game to take at least a year in development, give or take, due to it not being a main focus and simply a hobby. Is there any recommendations for a good card shuffling engine? Is GameGeisha an individual that I could get into contact with? Also, I am familiar with Kingdom of Loathing. I believe my game will be a bit more complicated than that, and I'm deserving a bit more artwork than what KoL has, lol. However, any demos and working material will most likely be done in a KoL fashion, so that is a good reminder for ideas. o:

well as you call yourself a newb. I would say scrap the idea and work on something smaller as you will hit soooo many brick walls(assuming your new to all things game programming not just GML)

and before you even think about making this game, you need to design it and no i dont mean the one vital thing to any game idea -games design- i mean software design or coding design(your idea is solid anyways). As with a project like this especially one with cards(or similar types of things) you need to lay out the code in a good way and this ofcourse would help with what danny said if you chose to add multiplayer later.

You would need to build whole code structures for a card, deck, battle................................. so they need to be coded in a good way with arrays and data structures that can easilly be accessed and such.

I know im not the man for designing a whole games's code structure, i just jump in and i regret it later which isnt great for my kind of projects but it would be awful for even a single player tiny card game let alone what you want.

While I am new to programming, I do understand the basics. I've babbled with programming (GML and others), so I understand the basics and the needed structures. Since this game will probably need a lot of by-hand coding, having the "outline" of the code done first is a very good idea.

No offense, but one year is simply not reasonable. Unless you get some serious help, like a team or something, it could take you over a year just to design and draw the cards (unless you're not planning on including that many, but I'm picturing thousands or at least several hundred)

Card shuffling engine - I don't know of any. But I'm sure there's one out there. It is a very simple task... it can be done with either arrays or data structures. Basically it's just what you would think... you could start with an ordered deck or non-shuffled deck (whether its an array or data structure) and choose a card at random and add it to your shuffled deck and repeat the process until the entire ordered deck is down to no cards.

And Jack Indie Box's second piece of advice is good (plan everything out in advance... not just concept, but the code itself. Variables and stuff. If you do not, you will regret it (I've started an RPG and got partly through, then ended up creating duplicate variables for the exact same purpose simply because I forgot that the originals existed. Then I wanted to change the battle system (introduce a new variable), and my coding was so specific that adding any new variables was a real pain).His first piece of advice I may or may not follow... he does have a point, but personally I've learned more from failed attempts at games than by doing various smaller projects. That being said, the downside is that any code you write while you are still learning will not be optimized... you may end up wanting to restart completely once you've learned a lot (and you might even need to, especially if your old code is so bad that it actually slows the game or something).

First of all, I'd like to expand on that Jack Indie Box said about design. It's true that you will need well designed code, but I disagree that the -game design- isn't where you should be focusing first. Now, I haven't played Rage of Bahamut, and I obviously don't know how well you have established your own version of the game (or are you planning on directly porting the gameplay across?), but I myself am working on a Yu-Gi-Oh TCG in Game Maker, and if you haven't actually designed how the game itself (the actual card game) is going to work, then that is where you absolutely need to start. I've run into my share of problems already, and that's with a well established TCG. I'd hate to think how difficult it would be if you don't have the rules of your game set in stone.

On Yal's first point, I was in correspondence with Game Geisha, and I followed the project for a little while. The reason that the game was no longer developed was not due to a work overload, but a HDD failure. Even though the engine was still in tact, apparently a lot of card designs were lost, and Game Geisha did not feel up to the task of remaking them all, so the project ended there.

Now, on to some more useful advice: Switch Statements are your friend. In looking up the details of each card, switch statements can be used much like a vlookup table in MS Excel. Create a script with a switch statement like this:

Then all you need to do is pass the card name to the script and it will throw back the appropriate value. I do this for each 'stat' that the cards have (ATK, DEF, Level, Attribute, Type, etc), and it works really nicely. It's actually even better if you have a script for the name of the card, and instead of passing the name to each script when you want a value, pass a card ID number or something. It's just much easier to illustrate using the names.

Dannyjenn's card shuffling example is spot on, and will work really nicely, however, I recommend using ds_lists as there is a wide range of functions available for them, including ds_list_shuffle() which will simply shuffle a list. You can use one list for every area that a card can conceivably be (each player's hand, each player's deck, each player's graveyard, etc). Then just add a card to one list and delete it from another any time you need to move a card around.

It's going to be a huge project, but I wish you all the best. If you have any sense of motivation, you should be able to pull this off... I don't and I've been working on the game on and off for a few years now... much more 'off' than 'on'.

Anyway, if you need any help with anything I've said, or if you want to talk or bounce some ideas off somebody, please feel free to shoot me a PM.

An alternate way of doing things (not sure how this would work with data structures, but this is how I did it in an RPG using arrays) is to simply have a separate array for every stat. So, using Shadow Archangels's example,

Then you shuffle the array index numbers. So, for example, a deck might start out simply as 0,1,2,3,4 and be shuffled to 1,4,2,0,3. Then the first card is drawn... it returns a 1. So you check the data in every array in slot 1... name[1] returns "Red Eyes Black Dragon", atk[1] returns 2400, etc.There are positives and negatives to both ways of doing it...- my way is faster to compute than his way (looking up an index number takes 1 computation for every variable... his way it has to check the value against everything in the switch statement will take n computatations in the worst case (n being the number of cards... if you have 1000 cards programmed into your game then it may have to go through up to 1000 calculations as it goes through every case each time the function is run)... and that's for every function.- my way only requires use of a single function... his way requires 1 function for every stat (so, 1 for name, 1 for ATK, one for DEF, one for level, probably other things as well...)- my way requires much more memory... there several arrays with thousands of indexes, whereas his way doesn't even use a single array- my way isn't quite as easy to read as his way so if you're not careful you're more prone to mistakes

Dannyjenn makes some valid points, however the reason I chose switch statements over arrays is the memory usage. I have only tested my method with about 300 cards, but even grabbing 10 stats for the 300th card I didn't notice any slowness, but perhaps 300 cards isn't enough to demonstrate it.

My issue with arrays is that once we get up to a large number of cards, you then have arrays that are huge, and you can't get rid of them. ds_lists can be resized or even deleted, so they are much kinder on memory usage.

Even so, it would be good to see tests done to benchmark both methods.

I would personally use one big array to store card data, so that say card #34 is "Bulbasaur", is a Monster card (not a spell, etc...) and has an atk of 400 and a def of 300 plus runs Flip Effect script #26 when flip-summoned, runs Turn Effect script <NONE> each turn, and runs Tap Effect script <NONE> when tapped. (And so on).

Then you store the player deck data in another array, storing the pointers to the cards in the data array. For instance your deck may at one time be:

in this example the top card is a Bulbasaur, with two more bulbasaurs further down, plus two other cards.

The benefit of storing data in an array and then just save pointers to the actual card data in the player deck array?

- Less stuff to shuffle, saving CPU time
- Having loads of cards saved in decks, etc, takes very little space if you only need to save a single real per card, compared to multiple reals and strings
- Harder to mess around with save files since you can't just read card names, increase ATK values and stuff

Basically, whenever you've got "Loads of stuff" that "never changes" you should put them in a constant-data structure rather than wasting your time processing the data around if it's never gonna change anyway.

0

- The above is my personal opinion and in no way representative of Yoyogames or the GMC, except when explicitly stated -

I didn't make it but I have used it a lot. Basically it returns the angle (argument2) degrees from direction (argument0) towards direction (argument1)so use like:

old_direction=rotate(old_direction, wanted_direction, rotation_speed)

So how is this useful in a card game?Well you can program an easy card flip! Give cards a "flip" variable and a "yrot" variable. This variable will be the pseudo 3D rotation of your card on the y-axis. xscale of the card's image will be cos(degtorad(yrot)). Manipulation of the "flip" variable will determine if the card is face up (flip=0) or face down (flip=180). the yrot variable will be dfependant on the flip variable by the "rotate" script. As so:

yrot=rotate(yrot,flip,5)

Note: 5 is just an example of a fliping speed.Now I know what you're thinking, "But Blopit! Won't the card just show up as horizontally mirrored when it's supposed to be face down?" Yes, that's why you have to put a little check for the sign of the card's xscale (cos(degtorad(yrot))).

All you have to do is change the flip variable from 0 (faceup) to 180 (facedown) whenever a card is selected to do so.

Don't know if that code exactly will work but I hope I helped!

Also ds_grid data stores are much easier to manage when finding certain values for cards. What I would do is code a seperate grid data structure with all the cards unique constants and make the program spit out the data structure code using ds_grid_write(id) and then store it in an ingame script. Use ds_grid_read(id,str) to read the contents you made beforehand. Just an idea as this would save the computer from writing a bunch of constants and then reading them. You can adjust this process such that the game reads from a temporary text file before final data importation, so that you can edit the constants (stats) on the fly while making your game. As sometime, you may find some cards are too over-powered and that you should edit their stats immediately before you forget.