Devlog for May 26, 2019 Update


This devlog is to explain a few things.

  • What I changed for this update.
  • What to expect out of the deck builder.
  • What to expect going forward.

1. What I changed for this update.

First, I want to announce that the price has been raised from $30 to $40. I said in the previous devlog that I will be raising prices and this is will be one of them. A $10 increase seems a bit drastic, but when I talk about the deck builder, I hope you can see why it increased to such a degree.

Second, I want to say thank you to those who bought in on the early access. I'm still a new plugin dev to the RPG Maker community so there's a lot of trust issues I thought people would have regarding me in expecting me to deliver a full and finalized product. I'm glad you guys took that leap of faith and I hope you feel the product you purchased early in advance feels worth the money. Now, for those who did buy it, I want to point out a few things that have changed from the first one.


There's a new plugin parameter in the Card Templates: Icon Index. I didn't think about adding this last time so I thought I'd add it in this time to make things fit better for future plugins. If you guys have already implemented the card templates into your game, please update the plugin, go through each template, and assign an icon to each of them.


This is the other plugin parameter addition. It gives you the option to choose to Show Health or not on your cards. This also makes it easier for the plugins down the line to adapt to the setting, too. Now, if you're already using card templates from before, you'll have to change the JS: Draw Code to this at the end:

if (!$showCardHealth) return;
// Health
var healthBitmap = ImageManager.loadPicture('CardHeartIcon');
healthBitmap.addLoadListener(function(bitmap, healthBitmap) {
var health = this._card.currentHealth();
var maxHealth = this._card.maxHealth();
var x = 4;
var y = 160;
var w = 48;
var h = 48;
bitmap.blt(healthBitmap, 0, 0, healthBitmap.width, healthBitmap.height, x, y);
bitmap.fontFace = 'Times New Roman';
bitmap.fontSize = 28;
if (health > maxHealth) {
  bitmap.textColor = green;
} else if (health < maxHealth && health <= 1) {
  bitmap.textColor = red;
} else {
  bitmap.textColor = white;
}
bitmap.outlineColor = black;
bitmap.drawText(health, x, y, w, h, 'center');
}.bind(this, bitmap, healthBitmap));

Other than that, that's all the changes made for the Core Plugin.


Meanwhile, the assets pack got a lot bigger, namely for all the deck boxes and deck sleeves I've included. Be sure to download that again if you want all the new assets.

2. What to expect out of the deck builder.

Before I went to make the deck builder, I went and did a lot of research on what online games used for their deck builders. The ones I looked through, downloaded, and played in particular are Hearthstone, Shadowverse, Yu-Gi-Oh! Duel Links, and Magic the Gathering Arena. I've probably spent about two days looking through everything to make sure I had known what is needed for a proper deck builder. The things I've came up was these key aspects:

  • Intuitive design: Just looking at it should give you an idea of how it's used.
  • Free flowing navigation: Being able to quickly toggle between everything to change whatever is needed.
  • Relevant information display: Being able to see important information at all the right times
  • Customization potential (game dev): Being still able to control how the scene looks from the game dev side.
  • Customization potential (player): Being able to customize the deck to how the player wants.
  • Mouse control: Being able to fully navigate through mouse intuitively.
  • Keyboard control: Being able to fully navigate through keyboard intuitively. 
  • Filter/Sorting: Being able to quickly find the card you need.

Now, let's talk about each of those.


1. Intuitive Design: This one was pretty tricky. When I played each of the four games, none of their menus ever really stopped me from understanding what they're trying to tell me. The information is relayed to me in the most efficient way possible and I thought that was awesome, yet, it was hard to figure out what they did right until I played the games back to back across the days. Eventually, it came to me that the information has to feel natural and always accessible. This is done through the next two things: free flowing navigation and relevant information display.


2. Free Flowing Navigation: Navigating programmer menus can be nightmare. Programmers just tend to have an end-goal of just only caring about the result, not necessarily the user experience. To make menu navigation feel intuitive, it needs to be free flowing. For example, in the deck list selection above, you could either press OK on a deck to pull up a menu to give you a variety of options to choose from with Edit Deck as the main choice, you could press cancel to go back to rule select, or you can press the Right button to go to the card list inside the deck to see what each card's about (with the preview window of the deckbox change to the highlighted card).


3. Relevant Information Display: Information about the deck you're editing is always going to be available when you need it to be. For example, let's look at the Ratio Window (above). It will tell you the average Level and Power rating of the deck, the ratios of the elements you have, and the exact card count you have for the deck over the minimum needed. Below the ratio window is the card list. It will show you what cards are available in the deck and the quantity. Selecting the card will change the preview window from the deck box to the selected card to show you what the card is all about.


4. Customization potential (game dev): As you are the game dev of your project, I'm not going to force you to use the menu layout I've chosen. I've given you all the key code you need to change to modify the game menus to your liking. This is important in making your project yours. Of course, JavaScript knowledge won't be included in the purchase of this plugin. You're on your own for that.


5. Customization potential (player): One of the things I love about the four games I played is that there's so much deck customization potential from even outside of the deck lists. There's deck boxes to collect, deck sleeves to use, and card skins even. I've implemented deck boxes, deck sleeves, but card skins will have to wait for another day since that will involve a revisit to the Card Game Core plugin. The deck boxes and deck sleeves are "unlockable" in the sense where all you have to do is give the player an item with certain notetags in them to "unlock" them. This is a minor thing in the grand scheme of the gameplay, but it changed my play experience a lot during the few days I've played the four games.

6. Mouse control: The entire deck builder menu can be navigated by mouse. This does not mean RPG Maker MV's default mouse navigation. This is all hard-coded stuff to make the navigation feel natural. Cards in the inventory window will automatically highlight on where you hover your mouse. If you click over to the deck contents window, it will automatically activate that. Click back and it will swap back. Change filters with just a click instead of needing to activate the filter window first, the old RPG Maker MV way. You can right click cards in the inventory window to remove them from the deck, too.

7. Keyboard control: Not a fan of the mouse? No problem. Navigation with the keyboard should feel just as natural, too. Press right on the deck list will automatically select the deck list. Press left and it'll take you back. This can be combined with Yanfly's Key Name Entry for a more intuitive deck building experience.


8. Filter/Sorting: Being able to find the cards you want and quickly is important. It's also important to be able to quickly compare them to the other cards that you're not familiar with. Filtering and sorting is a key important feature that is added to provide quality of life improvements to the deck builder and to respect the player's time.

Ultimately, I could have just taken the easy way out and just gave you a list of card names to push back and forth between two windows without so much as even a filter/sorting system. I could have just left the default RPG Maker MV mouse navigation system. I could have also just forced people to use the clunky keyboard control. The ratio gauge window could have been left out and I could have just given a programmer's menu. But I decided not to because if there's going to be a card game to be built after this, there's going to have to be a proper deck builder, too.

Something that could have taken me 1 day to complete with just the bare minimum stuff took me 10+ days instead. Research had to be done, making sure navigation feels great, manually go through and building individual features, and above all, make it fun to build decks in both a visual and mechanical manner. For that reason, I've raised the price of this early access from $30 to $40 as I stated I would in the previous devlog.

3. What to expect going forward.


What's left to make is the actual card game itself. At first, I was planning on simply coding everything, make it all flow through a fluid stream of code to get the card game experience I had in mind a proper making. Card effects would be made in the same structure as Yanfly's Tips & Tricks using "Lunatic Mode" and JavaScript. The sample project would house different card effects made across the 100+ cards available to it as reference.

But then, I was presented with a different idea from Archeia, MirageV, and Yanfly: Why not event the card game battle system and let card effects be common events instead?

I know I've answered to y'all before about how I decided to not use common events to determine card effects. But that's because I originally decided to code the whole battle system and common events would be hard to implement in to make it work. On the other hand, if I evented the whole card battle system instead, common events would flow completely naturally here.

There's a couple of reasons behind this change in ideas:

1. You, as the game dev, will need to event the battles to a degree anyway. Meaning, you'd have to setup the opponent, their cards, their health, etc. through events before launching the script call to start the battle. That was the original idea at least. If we're going to go that far, we may as well go the full nine yards and have the whole battle system be evented in that case. Granted, not everything is going to be evented. There will be a plugin with lots of script calls to supplement the evented battle system. Because there's another benefit to it:

2. An evented battle system means it's easier to understand for non-JavaScript users. While I say that there's a thin line between eventing and coding, people will easily argue that more users can grasp eventing than coding. I know there's some plugin parameters made in JavaScript for this plugin, but for those, there's no real way around them due to how they're strictly made to work on coordinates and whatnot. But for a battle system, there's more than just coordinates. There's logic flow and committing actions. And eventing is all about proper logic flow and committing actions. Users will need to download the sample project to grab the working battle system unless they wish to event it from scratch themselves. And with that in mind:

3. An evented battle system means that users can manipulate the card game to their will instead of having to choose exactly what I wanted to do with what I had in mind. Granted, I'll be eventing it in the way I originally envisioned it, but if you wanted to change up the way the behaviors work by flipping a few Conditional Branches, being unfamiliar with JavaScript will no longer stop you. As long as you have a grasp on what you want to do with the battle system, the battle flow will work the way you want and how you want. This also means that:

4. Card effects can now be made through common events! That's right, you don't have to use JavaScript anymore (though you still could through script calls). Just event away at how you want something to behave, how damage is dealt in a certain way, or use your own eventing tricks to get things working the way you want. While there's still going to be an advantage for those with JavaScript knowledge, those with eventing experience can still keep up and get what they want made and done. Which also goes to:

5. You can even make different types of card game battle styles in the same game as long as you know how to event them. I originally mentioned before that there would be rulesets for play styles. However, those rulesets would be limited on what could be done. Now, with the whole card game's structure available through eventing, you could make it play however you want as long as you know how to event it.

Now, with all that said and done, I'm going to state to you the drawbacks.

1. This will make the final product even more expense. I'm estimating there will an increase to the final price from $40 to $50. Why would an evented system be so expensive and is it even worth the $10? If you want my opinion, yes. Making an evented system would take considerably longer time than if I were to straight up code it. On top of that, I'm still going to have to code it. But instead of coding to make due with what I need done, I need to change the focus of the code to make it work with the event system, which is also extra work. As said before in the previous devlog, I will be bumping the price tag to an amount that I feel is worth the work I'm putting into it. I won't be compromising on this, maybe except for the occassional sale or two maybe (if I feel like it). Plus, there's also the extra bonus of massive customization potential that should offset that price increase, too.

2. Harder to report bugs and fix them. Evented systems don't provide proper tracks to figuring out what went wrong and where. This means that if I were to ever release this product and you changed it in some way that would cause an eventing error, I won't be able to help you fix it. If it's a bug report regarding a script call or some other code that I provided, then sure, I can help fix those. Eventing errors though? That's going to be all on you. Updates to the battle system will also have to come through the sample project.

3. Potential conflicts with other plugins. As the card game battle won't be in its own self contained scene and instead, will be on the map where the evented battle system will take place, it's going to be subject to just about anything caused by other plugins. Incompatibilities may possibly occur and that's going to make it harder for you as the game dev. Sadly, there ain't much I can do on this front. It's going to be up to you to figure out which ones work and which ones don't on your own. However, given the nature of how common events work, you should already know full well if your game's going to incompatible with them or not based on how events interact with your game already.

Finishing Up

It's been a pretty rough week for me for a variety of reasons, but I'm glad to have finished making this deck builder. It's a product that I'm proud to say I've finished and working the way I intended (so far). If there's problems to be found, just let me know and I'll fix them right up. Otherwise, to review what we've gone through:

  • There's been same changes to the Card Game Core plugin. Please go through and fix those up.
  • The deck builder is something I totally did more than I could have for. It's anything but the bare minimum. I personally believe the price increase is justified due to the fully functioning deck builder.
  • There's a change of plans regarding the card game battle system. It'll no longer be fully coded. Instead, it'll be partially coded and mostly evented to give you, the game dev, maximum customization potential. There will be a price increase upon the final release as well.

See y'all later. I'm going to rest up and try to recover from this terrible cold of mine that just wouldn't go away.

Get Collectible Card Game plugin for RPG Maker MV

Buy Now
On Sale!
10% Off
$49.99 $44.99 USD or more