You can see it here: https://www.patreon.com/himeworks
I'm trying a different approach to engage users and have decided to go with Patreon.
However, I have decided not to change the way I do things, so things like
- writing scripts
- filling script requests
- offering general support for events, script calls, etc
- writing tutorials
- making videos
Will still be normal content.
I will still be using my website, Twitter, Facebook, Youtube as well for public posts.
But I feel there should be some exclusive content, like maybe a way to bring people into my development process or other things.
So all of this makes things a bit difficult to decide what would be good "rewards" beyond a "thanks for your support!" kind of thing.
The Shop Manager currently handles shops on a per-event basis.
A shop is uniquely identified by two keys: a map ID, and an event ID.
This does not allow you to have multiple shops in a single event, especially if you want the shop to sell different things under different conditions (for example, a shop sells beginner equips at the start of the game, but near the end of the game sells advanced equips)
I am tempted to add the page number of the event to the key as well, but will have to evaluate the consequences. As long as you are not explicitly trying to grab a shop using `ShopManager.get_shop`, it should not be much of a problem, but there may be cases where you actually want to get a specific shop using script calls.
In any case, the next version of the shop manager will add the page number to the shop key. This change should not affect any existing shop plugins.
In this devlog I discuss one of the mistakes I made while writing a plugin called Disabled Choice Conditions.
By starting with an overly complex specification (at the time, it sounded alright), I ended up running into issues that required me to add even more complexities on top of what I wrote initially.
And in the end, it just became really complex, with very little flexibility.
However, going back to the drawing board, I discovered a solution that was very simple, but was far more flexible than the other solution I came up with.
Here's another dev log. It's a pretty short one this time since I wanted to get straight to the point.
It discusses one of the issues we had in Ace, and continue to have in MV: troop events that get skipped under certain conditions.
Read about it here: https://www.patreon.com/posts/3627859
Here is an article that I've written about page conditions in RPG Maker MV, and why I have decided to write a plugin that will allow you to define your own page conditions:
The monthly summary for the month of December 2015 is now available!
The purpose of this summary is to let you know all of the plugins that have been created, or are currently in progress, and potentially future plans that I have for the next month.
It covers three different activities that I'm currently involved in as HimeWorks
2. Plugin Summary
3. Game Summary
You can read the summary on my website: http://himeworks.com/2016/01/monthly-summary-december-2015/
All of the plugins published by HimeWorks can be used freely for commercial projects.
Please share this announcement to anyone that is still wondering whether they can use my plugins or not.
I would prefer that you contact me so that I know that I will know about your project, but other than that, you can use them freely.
After writing a couple MV plugins related to choices, I've realized that a well-integrated event solution is extremely powerful for developers.
In particular, I would like to highlight the following choice-related plugins:
Disabled Choice Conditions
Hidden Choice Conditions
Conditional Choice Text
All of which have been optimized for use with the event editor.
And I'm reminded of a plugin I wrote early on: Custom Page Conditions.
If you think about it, this doesn't capitalize on the power of the event system. Instead, it simply tries to force itself into it by taking a couple commands and trying to parse it.
Which really isn't how it should be done.
In this dev log I define new specifications for how I want additional page conditions to be defined, and why it is superior to my old solution: https://www.patreon.com/posts/3719652
I've been running a Patreon campaign for about 2 months now, and am constantly think of ways to improve my campaign and to contribute to the community in other ways.
One thing that I've seen is that there are people that want a copy of MV, but may not have the means to get it. So I've decided that if I can raise enough funds, I will give away copies of MV every month depending on the pledge levels.
I will start by running monthly giveaways for patrons (so for example, you can give a copy to a friend or a teammate), but I may also do some public giveaways as well.
For the Ace users that enjoy my scripts and may be thinking of moving to MV in the future, this might be a good opportunity!
Going to write a common event shop that does something similar to this for the Shop Manager.
Some usage and implementation details
1: Shop type = "CommonEventShop"
2: In the Items tab in the database, users will create some "common event" items. The name, icon, description, price, and other shop-related information will be specified using the database. No more comments for these things
3: The common event will be set up as an effect. When the item is purchased, the common event will be executed. I have not decided whether the shop scene will close or not.
4: Setting up the shop is a matter of selecting these "common event" items in the shop processing editor.
The only purpose of the shop is to allow you to sell items that trigger common events. Anything that you want each item to do will be done in the common event. It shouldn't matter what you want to do.
If anyone has any requests regarding this common event shop idea or things I should consider let me know.
The next version of the Shop Manager will come with a new set of "shop options".
These options influence the shop and shop goods.
All options are set through script calls before the shop processing command.
In particular, it will support the following options:
1: Hidden. You can attach a condition to a shop good to hide the good from the list. If the condition is met, then the shop good will not appear on the list.
2: Disabled. You can attach a condition to a shop to disable a good from the list, even if you have enough money to buy it. If the condition is met, then the shop good will appear on the list, but will not be selectable
Additional options will be added in the future if they are useful.
Shop options apply to all shops that inherit from Game_Shop, which should be all shops.
This dev log prefaces the development of my next MV plugin.
It starts with a scenario that I randomly picked and then try to solve the problem in a way that you might intuitively do.
However, I end up finding that the "intuitive" way to solve the problem is not scalable, and a different solution is needed.
With MZ around the corner in a week, I've got plans to port things over from MV to MZ, revamp some older stuff, maybe try some new things.
Got a plugin request recently to make a shop that will appear "on the map".
While building it, I noticed events could actually run while you're shopping, and then found a way to allow you to control the actual shop itself with a parallel process event.