Nice! I've read an article about outsourcing tasks you need a long time to do. And since I spend hours and hours looking for free music that fits my game, I think it is time to buy some of these music packs . I am also looking forward to some tutorials on how to make your game more interesting and versatile.
These are just little things I've noticed in the program that help speed up efficiency the tiniest amount, but nevertheless, here I go:
When you create a new event, the event name's textfield will be selected automatically. That means you can instantly put a name to an event just by selecting an empty box, pressing enter to create a new event, then just typing in something for the event name.
So all event commands have an "OK" and "Cancel" button, right? Instead of reaching over with your mouse and clicking that button, you can just press CTRL + ENTER.
The event editor itself has an "OK", "Cancel", and "Apply" button. The thing is, the OK and cancel buttons are so close to each other that you can occasionally click on the wrong thing. So instead, if you just press CTRL+ ENTER, it will save any changes you make to the event and close the event window. If you press ESC, it's equivalent to clicking "Cancel".
Heck, everything that has an OK and Cancel button can be navigated with CTRL+ENTER and ESC, respectively.
I use Yanfly's Durability plugin and his Equip Core too. Is there a way to display the Durability of an item on the Equip screen of an item with this setup? Currently, it doesn't, so it makes equipping a bit of a chore, because you can't tell what's wearing out.
Tip: Don't wing it! Especially if you're a newbie to RPG Making!
What I mean by this is start on smaller projects first. Try to make a short 1-hour game. Then make a bit longer game. Then an even longer one.
The reason I say this is because before you get into a bigger game, you need to learn how to use your RPG Maker correctly, efficiently, and proficiently.
And even if you've "done that, been there" and you're proficient with an RPG Making program, it's always easier to create the full concept on paper and pencil (or your information-holder of choice) rather than ending up with plot holes, conflicts, and other things as you go.
Also, see what your friends/family think of some of your ideas! They might think of ways to improve them that you may have never come up with!
So, helping out only counts in that specific forum section? Just asking because I don't really go over there, but I do a bit of help in the script sections.
Before reporting bugs for script makers or rushing here to post a topic about a nasty error you get or want to do something with the script but you don't know how, read the header/manual/description/explanations found in the script. All of them! Multiple times!
If there is a demo too, check what has been done there too.
If you made sure that you did everything right, only than report a bug or ask for help, but only after you search for the said error/issue/etc on the big internet. No need to ask the same questions all over the internet if it is already answered.
This makes the life of both sides easier. You learn something in the process, while the script maker will have more time to work on his scripts.
An awful lot of topics here are asking for already answered questions or issues which aren't really issues (the issue comes from the user's wrong script usage, not from the script itself).
Okay, now this might sound that I just want to make my life easier (which is true ), but I am sure that doing what I wrote could potentially help other people here too.
Taarna's random tip: if you find yourself making the same event over and over, or same block of event commands, make it a common event and call that instead of copying and pasting. In events or in code, repeating the same stuff over again is generally not optimal.
Expanding on slimmmeiske2's tip. Something I've learned is don't just use the built-in play test, but also test the deployed version. A lot of time could have been saved for my dad if I had did that before letting him play it. RMMV has an option when deploying to remove unused resources, but it doesn't take into account resources used my plugins. My dad started up the game, but it immediately crashed because RMMV removed something it shouldn't have.
One suggestion I have for new people to RM is make a dummy project when you start out to test out scripts and script edits in. This way you don't risk wrecking your main project until you are sure how to make the scripts work.
- Start with the default map size and expand the map as you go along and add in details as you go along. This way, you'll avoid the dreaded negative space that is associated with so many beginner maps.
- Start from the inside out and use the Shift-Map function to move your maps around. For example, if you're designing a village square, create that first and work outwards.
- Don't underestimate the Tint command and avoid using overly saturated tints. Never use a dark blue for your night scenes. A faded out purple hue works just fine.
- Use event mapping!
- Try to limit your tilesets. Constraint breeds creativity, after all. =)
This is such an awesome event. Great idea and nice execution so far :3
As already mentioned there is so much you can learn by trying to teach.
Hmm... maybe I should try to finish that door tutorial I started years back.
Oh yeah, as a tip, remember to keep an open mind. If you ever feel like you know everything there is to know, it's probably just because you are only considering the world within a little bubble. There's always new stuff to learn.
I try to check out 2-3 projects from the Games In Development forum every fortnight. I usually don't spend more then 30 minutes to an hour on each project, but I do try to leave a comment to share my thoughts on each one I check out. I usually just pick whatever catches my eye, but if you're reading this and would like a little feedback on your project in development let me know and I'll see if I can check it out