CARD BASED BATTLE SYSTEM

Posts

Pages: 1
So a few years back I posted a topic about my game Legend of Otaku. I mentioned it had a card based battle system.

I want to elaborate and figure out how to implement that into the engine, perhaps so that I can eventually make some demo or trial of the game I want to make.

What I know/what I'm after:

  • Each character will have a separate deck of abilities that they will draw from to govern what moves they can use each turn.

  • Each ability can be added to the deck up to the deck's maximum size.

  • Each card will have unique properties that can affect and be affected by how many or which cards are used. (E. G. a Fire spell has the Fury property, which means if it is used then you can choose to use other copies of it in the same turn)

  • Abilities will be locked by class

  • Abilities will also be locked by stats

  • The main character of the party (the Otaku) can ignore class restrictions, but not stat restrictions

  • Stats will affect card and character behavior. (Higher speed draws more and plays (first) more often, Intelligence gives larger hand caps, etc)

  • When a character is unable to draw a card on their turn, they are left in 'exhausted' state and are unable to act for that turn.

  • The Otaku character will be able to immediately enter 'exhausted' state for his/her turn to edit his/her deck mid-combat, allowing for large versatility at a great risk.


What I do not know/what I'm guessing at

  • How to implement skills as cards (I theorize integers could do the trick, but I won't elaborate on the actual theory in case there's something that could potentially do the job currently)

  • How to install addons to the system as needed.

  • Basically how to use the system.


I'm probably doing a massive jump-of-the-gun here, but I also figured finding a way to get this information NOW as I try to learn to program and use the system might save me headaches later.

I already know what I want and have ideas on how to achieve them in an engine, but I don't know coding or how to achieve them using THIS engine, which while it might be more than most people, is not a lot and still requires a massive amount of work.

I get that a single guy built the entirety of Dust: An Elysian Tail. But I don't think that was his first project or if it was that he had some kind of experience. And even he took on some help.

That and I thought this might help other people figure out how to implement cards into the system to so that the engine could be made even more versatile.

Anyway, thanks for at least reading this far.
You failed to mention what "engine" you are using. I actually thought of a card based battle system. I was able to successfully implement it in VX Ace.

However, being that the cards are items, making it so each person in your party has a different deck, as far as I can tell, is impossible. Or st least I have no knowledge of a script that allows it, and I can't script so I can't invent it myself. As a result a card battle system must either a) be limited to one party member, or b) everyone in the party shares the same deck.

Your ideas seem much more elaborate than mine. I'd say they are too specific. To simulate a deck I simply borrowed someone else's random item script. Instead of drawing one card out of a let's say 30 card deck I just give an item that randomly becomes one of 30 items. (It can be any number, using 30 as an example) When you factor in the fact you can make multiple such items (even chaining them into each other- yes, it works) and use battle events and global switches to control them, there's a lot that becomes possible.
Do you have any equipment or combat skills that aren't cards? (Aside from the Otaku's edit deck ability, which could be implemented as a pseudo-card that's always in his hand.) I'd have cards be used as equipment and check class and stat restrictions when "equipped". Then each turn draw however many cards and create the skill menu from that (skill IDs match card IDs). I don't know if RM's default skill handling will have trouble with duplicate skills.
Marrend
Guardian of the Description Thread
21781
I think there was mention of using VX Ace in a different thread for this game? My memory is a bit fuzzy, but, the title of the game sounds familiar.

I figure a deck would be some kind of array. What each object of that array would be is a little more ambivalent. It could be an item, or it could be a skill. I think it could work either way.

So, if cards are reliant on having certain stats or characters, there's probably a deckbuilding component to handle those conditions. Which usually translates to players having a stock of cards they are not using because they either do not meet those contitions, or have a full deck already. Thus, where do they exist when not in use? Is there a place where you can view them? Another question, where to cards go after they are used? Are they consumed, or do they go to some temporary space until the next situation that uses them arise?
If I may?

  • First: abilities are the attacks. Guarding, using items, and other tactics aren't actually cards. (Although I am on the fence about whether or not guarding should burn a card or not)

  • Second: Essentially the cards ARE the equipment. The idea is that your attacks or skills are limited to cards, and everything else is part of the menu.

  • Third: I have no idea what system to use in the first place. I'm on the fence between VX Ace and MV.

  • Fourth: The integers work thusly:


Each skill is assigned a value, acting as a call sign for what information is on the card. These call signs govern placement in the deck (basically I make the game generate a list of the values and go down the list to draw cards) as well as how many of a 'card' is in the deck. The skills don't actually duplicate, but the information OF the skills is used for each card.

Example:

The Black Witch has a fire spell called Firren. Now Firren is listed as a skill in the game's directory. The Black Witch also has an ice spell called Blizzen and a thunder spell called Thunden.

When building the deck, the 'compendium' (what will act as the skill list) will list one copy of each 'card'. Players will select the card, assigning it a value in the corresponding deck.

So let's say the Black Witch will have 2 Firren copies and 3 Blizzen copies in the deck, with only one copy of Thunden.

The game's logic will then give these skills a value, in this case we'll call it 'BWitchDeck', and this value will act as a reference for the game to go 'Okay, I use this information for this listing, and it will come up this many times in the list'.

This basically let's the game use the same information for the skill without actually duplicating it. It's a facsimile of actual cards so that on the surface you'll see the cards and they can behave like cards, but in the code the game is just using the same skill again and again.

This will also allow for properties like 'Fury' to work by limiting the player to what they have in their hand for repeated use effects.

The best part? Randomization and searching not only become usable, but they work within the limitations of the engine. Instead of shuffling skills you're shuffling the placement values of each skill. And because the game understands 'this skill appears this many times in the list' it will always have a frame of reference for how the deck will behave.

If this is still too complex, there's an easy way to break it down:

Take some of your favorite cards (Yu-Gi-Oh, Magic, whatever) and give yourself only one copy of each. Then take some chunks of paper, more than the cards you have, and write the name of the card on one side.

Now take the strips of paper and stack them name down. Pull the strips one at a time, and each time you do, look at the card whose name matches that on the strip.

If you like, reorganize the entire stack however you like, search it, do whatever.

The playing cards represent the in-game skills. The strips the deck placement value(s). And the name which 'card' that value is referencing. After that, the rest is relatively simple: attach the information it pulls to the skill, add a string that pulls the information when that skill is called, and use that for graphics, animations, damage math, and so on.

Of course the game gets a bit more challenging with the addition of Ultimas, Status Effects, copying skills from enemies later on...
I like the idea of giving each spell/skill its own MP bar (sorta like Mega Man X / classic series) but that's another thing that doesn't seem to be possible in VX Ace. Except by making spells items, and placing events everywhere to manipulate how many of each item you have. (for example, making it so using an inn replenishes your items)
Hmm...

Wait...can anything be done outside of creating events?

And on top of that, are there any addons or plugins that can be used to help with this?

What about MV? Is that more versatile? Or am I trying to make an car engine with a chisel here?

I mean, I have some other ideas that MIGHT work in RPG maker, which is kind of why I created this to double check so I don't waste effort.
Dragnfly
Beta testers!? No, this game needs a goddamn exorcist!
1809
You can do some pretty rule-bending things with scripts and plugins. People have made action games, tactics games, changed the entire interface and even made meta games that add files to your game folder etc etc etc.

One of MV's strongest points IMO is that it uses javascript whereas the others use ruby. Is one better than the other? Hell if I know. But outside the RM community itself I had a hell of a tough time finding anyone who even knew the basics of Ruby, whereas javascript tends to be taught in schools. So it's just easier to get somebody who can help you. That said, the RM community's ruby users swear by it and know it inside and out.

I'll edit this post soon after I've read the rest of this topic.
author=Dragnfly
You can do some pretty rule-bending things with scripts and plugins. People have made action games, tactics games, changed the entire interface and even made meta games that add files to your game folder etc etc etc.

One of MV's strongest points IMO is that it uses javascript whereas the others use ruby. Is one better than the other? Hell if I know. But outside the RM community itself I had a hell of a tough time finding anyone who even knew the basics of Ruby, whereas javascript tends to be taught in schools. So it's just easier to get somebody who can help you. That said, the RM community's ruby users swear by it and know it inside and out.

I'll edit this post soon after I've read the rest of this topic.


Thanks for that.

I'm actually hoping to find said plugins and scripts. Granted there's most likely going to be some modification involved, but I do believe that this can work on the engine, the question is how.

Keep in mind this is coming from someone who has no real programming experience. I probably need to do a lot more Code Academy work before I can touch any of the Makers.

Hmm...yeah Javascript is probably way easier to learn.

And if there's anyone willing to help by all means! I'll be happy to give you the specs of how the engine is supposed to work or any other details to help with the experiments! Hell I'll lend voice work or whatever I can! I do have some card graphics on file SOMEWHERE...
Dragnfly
Beta testers!? No, this game needs a goddamn exorcist!
1809
author=yugijak
And if there's anyone willing to help by all means! I'll be happy to give you the specs of how the engine is supposed to work or any other details to help with the experiments! Hell I'll lend voice work or whatever I can! I do have some card graphics on file SOMEWHERE...


Toss that and more details in a new topic in the help forum so you can ask for what you want more specifically. You'll get a better chance for development there.
author=Dragnfly
author=yugijak
And if there's anyone willing to help by all means! I'll be happy to give you the specs of how the engine is supposed to work or any other details to help with the experiments! Hell I'll lend voice work or whatever I can! I do have some card graphics on file SOMEWHERE...
Toss that and more details in a new topic in the help forum so you can ask for what you want more specifically. You'll get a better chance for development there.


Thanks for that. I figured this would be good to try to figure it out here, hence the post here, but help is probably better.

And...thinking about it, it would probably 'help' more people.
Pages: 1