We did it folks! The Party update is here!

New in this Update

Bug fixes

• Fixed MZ-exclusive functions that would cause problems if card battle was disabled.

Minor changes

• Due to the addition of Party support, cards are no longer drawn at the start of battle, and instead at the start of an actor's input. All this means is that if you have only one party member then you will draw cards after navigating through the Party Command Window rather than immediately at battle start.
• Added a few more plugin parameters, including one to give you control over the X coordinate of the center point of the hand.

New features

This is the part to get excited about!

It's been 3000 years, but Party Battle is now fully supported. Each Actor has their own hand, their own deck, and their own discard. The Start of Battle Actions and Start of Turn Actions occur separately for each actor, during their input. It does come with some unique UI problems to solve, as I'm sure you can see in this screenshot.

We've added plugin parameters for displaying icons that represent the size of an actor's hand, deck, and discard, so even when you can't see that actor's cards you still have access to important information. But a party of 4 does take up quite a bit of space on the screen.

So we've created a free UI plugin you can use, included with all demo projects going forward, which improves the spacing a bit.

With IsiahCGCPartyUI_A, we have two status windows - one that just shows HP information, and one that shows everything for the currently active party member. This UI was designed by Neel along with a few other UI mockups. Every project has its own UI needs, so I named this plugin PartyUI_A in case we decided to implement some of the others he designed. I know most RPG devs have their personal favorite solutions to UI control and I want to do what I can to make sure my plugins are compatible with those, which means giving you options.

For those of you who like writing your own plugins for UI and want to keep the card zone information on your custom-made windows, the functions are:

Window_Base.prototype.drawActorCardZones(actor, x, y)
Window_Base.prototype.drawActorCardZonesVertical(actor, x, y)

Note from Neel: Hey all, you may have noticed that the Deck and Discard Images are missing from the new UI. They have not been removed from the plugin, but instead been moved off-screen and can be easily placed back in. While we lose the benefit of the card draw and discard animations with this setup, the information of each Actor's deck and discard amounts is still provided by the Main Status Window. My hope is that we can pull them back in for future UI plugins.

What to look forward to:

So we have a few minor things planned for 1.3.5 before we move on to 1.4.0. Firstly, I have no doubt that this update will introduce a plethora of bugs we couldn't catch in testing, as everyone's project has different needs and quite frankly Party support was a big overhaul. Please remember to report any bugs you find and I'll try to fix them quickly.

One thing I want to improve is plugin compatibility. I have a short list of plugins I want to add compatibility with, most of which only require minor changes - if there's a plugin compatibility issue you really want resolved, check our Compatibility List and if you don't see it there please let me know. Or if you DO see it there under the Known Compatible Plugins section and it isn't working properly, let me know about that too.

Aside from that, here are the features we're looking at in the next major update:

Card Types

I'm unsure if I'm just going to use the Skill Types system base RPG Maker has or if I'm going to use exclusively notetags to facilitate this. I know there are plugins that let you give Skills multiple Types but compatibility with those plugins will have to be manually added in, and it would be nice to natively support multiple types.

Regardless, having multiple card types will help with organization on the Card Library scene, and there will be a feature to let you specify a different card base for each card type.

Card Filtering

This would include two categories of effects: The first would be Deck Filtering type effects such as Targeted Card Draw (Searching/Tutoring), Milling your Deck till you find a specific Card, recurring a Card of a specific Type from Discard, and Scrying/Surveil type effects. The second category of effects would be Sacrifice type such as Cards that require other specific cards or Card Types to be in your hand to play. If you are familiar with Yu-Gi-Oh, this would be similar to Tribute/Sacrifice type requirements.

Card Actions that effect the Target rather than the User

So right now, when Card Actions are executed, they affect the hand/deck/discard of the current active Actor - as in, whichever hand you can see at the time of the execution. If the game only has one party member, that's all fine  - the player's skills affects the one actor, and the enemy's skills affects the one actor. However, if you're doing a party battle, that's much less good. Maybe you want an enemy to force their target to discard a card. Maybe you want a Cleric type party member to "buff" an ally by making them draw a card.

Some amount of reconstruction is going to be necessary for this to work, but it's basically the other half of the puzzle to a fully functioning party battle.

Final Thoughts

It's been 6 months since I first released CardGameCombat. The plugin has changed drastically in that time, but there's still a long way to go before I'm done with it. I have ideas all the time for potential features, or plugin extensions, and I'm always excited to work on it. I only wish I could dedicate more time to it. I'm unfortunately in the position of having to choose between new features and bug fixes/compatibility.

I'm also running into a problem of too many plugin parameters. I want to give users as much control as possible, but the scroll bar is getting rather long and it's not convenient to edit them; plus it's a nightmare for new users to learn, even with the demo projects. I think making new features that require a lot of parameters into their own plugins, like I did with PartyUI_A, is a potential good solution, because it at least organizes those parameters a bit better. Internally the team talked about reorganizing plugin params in a way which would be good long-term but force users to re-input their current parameters. I'm unsure about this - the last time we changed a system in a way that would potentially break things for users, we wrote code to make sure the legacy implementation would work, and we did this early enough in the plugin's lifetime that it wouldn't be a huge hassle for most people.

-Isiah (@IsiahGames) 
MythAtelier