AenaonDusky
DeliveryBoy
- 315
- Posts
- 6
- Years
- Seen Apr 28, 2024
This tutorial should cover some of the general issues that might prevent you from getting started (and keep going) on a general level. After a short, more personal paragraph, we'll delve right into the juicy bits. Any more points you want me to add, just leave a comment. If you want a more specific tutorial pertaining to usage of Essentials, you can check out FL's here. I will be updating this as often as I can.
When it comes to first starting out, the biggest question that arises is "Where to even begin? I am totally lost and this feels like an immense undertaking."
When I first began making games, I had the same question. I loved games since I was a kid, and was mildly obsessed with them. When I noticed fan projects around my teenage years, I was left speechless by what the developers could do. Was it even possible to make anything even close to all these amazing graphics? The story? How could they come up with ideas, and materialize them, to such a degree that it felt like a humongous mountain looking down on a beginner with zero experience? How can you deal with the thought that your work will be inadequate, and that you aren't a real designer or artist – not only compared to other fangames – but because of your work is a fangame in the first place, too. Should I really undertake such an enormous task, only for it to be a silly idea about an almost 30year old franchise, one that will never really net you any money – and when there is enormous "competition" from what seems like unreachable developers?
The truth is that fangames are not in direct competition with each other - and the result of your work is not dependent on your talents alone. We'll address these later, so let's begin with the most important factor that can determine your progress, and that is learning.
Learning Methods:
There are generally three major approaches to learning how to make a game.
1) Through observation and imitation
This method requires you to break down a game you like into the smallest segments possible, so that you can analyze them in practice. Forget about the more general concepts that a game has managed to do well, and just go to one map/level. Break it down.
How long is it? If it's the first map, it's likely small, right? What purpose does it serve? Is it to teach the player how future mechanics come into play? Why are some of the sprites using this color? Is it to set the mood? Why is the story presented only through objects and without dialogue? Is it because the game wants to tell a story through its environment?
After breaking it down, try making a map/level of your own, following the same principles. Some people can go as far as to count the number of total tiles, houses and objects, to imitate a level perfectly. That may or may not prove useful, as it can lead to uninspired copying, instead of inspired imitation.
The purpose of imitating something, is so that you can uniquely expand on its well-done elements. It is also possible to absorb what you see in a more intrinsic manner, but this is usually a process that "just happens" and there is not a lot to say about it. Some people have this tendency more developed than others.
2) From Reading tutorials
This is self-explanatory, learning from tutorials is a great place to start, but will be constrained by a) the amount of tutorials, b) the topic of tutorials, c) the quality of tutorials, d) the scope of tutorials. That is why you should immediately attempt to apply in practice what you have read.
Good tutorials are a must to save you a huge amount of time. You can find a lot of great tutorials on Relic Castle and Pokecommunity. It's likely that some will need to be re-read more than a couple of times to make sense as a beginner, but you should also notify the authors about the parts that weren't communicated as well to you. Again, tutorials exist so that you can apply them.
3) By Experimenting (this part will be updated with pictures later)
You must learn by tinkering with, and actually using the game engine. Make one map. Two events. Play the map. What happens if you do X? What happens if Y comes before X? This is learning by doing. It is vital to use this method, if you want to have any progress at all.
Do everything you can to mess around with how the gears move. Take a mental or written note of what did what, and try to think about the reasons. For instance, you transferred the player to another map - the map's name showed, but the screen is black. What have you done wrong? Perhaps the fading to black is a different thing from the actual transfer?
Experimentation should be done with the most limited and isolated scope possible. This serves the purpose of isolating and replicating a process, but also teaching you how to properly test a game. Let's go back to attempting to transfer the player. If we open one of the example transfer events that come with Essentials, let's say, the event that transfers the player to their house, we can see there is a number of commands.
As beginners, we can't understand what these commands do just by looking at them. But we know they work. So, let's copy this event, and remove the last line (that sets screen tone to 0, 0, 0). Hit the playtest button and let's enter the door. What happens now? The transfer worked but the screen faded to black – or more correctly, it was never set back to the "no color" value. So, from this, we can understand that this command does exactly that. The command right above it says quite clearly what it does: transfers the player to a specific tile on a map. At the very top, the same command we removed from the bottom appears – but is slightly different. It sets everything to -255. That means that it makes everything black. Let's try to slide the values all the way up to +255. Hit play. What happens now? Everything is white. Now let's try only to use the Transfer Map command. What happens? Player transfers as they are to their house, without any change in the screen. Now let's not use a "wait" command. The player insta-transfers.
You will have noticed that we only changed one thing at a time. It is necessary, when you tinker with anything in the engine, to only test one change you have made, in one place only, and one at a time.
This will have the extra bonus of allowing you to understand, and later examine, why things work how they do, so that you can also know the when. Now that you know that a Screen Tint command that goes to -255, fades everything to black, if you find your player transferred to a place where you cant see anything, you will know that this actually occurred in the previous map, where the transfer itself took place.
Remember: a game is not a hypothetical, theoretical work. It is an actual, material work. If you don't know what bricks are, how to stick them together, and where to do so, you can't build a house.
Planning and How To:
Once you have learned the basics, and have a basic understanding and tinkering experience, there will be one big hurdle that you will have to face. This hurdle is often "invisible", and is the second biggest time-sucker in game development, after improper learning. That hurdle is called lack of planning.
Lack of planning means that while you are using your bricks to build a house, you are also designing how, where, and with what to build the house at the same exact time. This means more than double the work, concurrently. Suffice to say, this is not only much more exhausting than needed (and will drain you in the long-term) but it's also physically inefficient. Both your on-the-spot design, and your actual building, will suffer from the divided attention, brainpower, and energy reserves.
A good plan not only can save you up to years of actual work, but it is the most successful strategy to make short jam games, and long big games too. This happens for primarily three reasons:
1) Your ideas can immediately be applied
All your subsequent actions are the materialization of your work, and you can immediately transfer from paper to an actual map/level/cutscene
2) you have set the exact limits
which means you know where to start because you know where to end. A practical example: Let's say we want to make a small town. If we decide that we'll have 5 buildings, that the town will have to be on a 68x68 map, and if we have designed the map on a paper (roughly), we have already done half the work. And the limits and "skeleton" of our map, level, dialogue, cutscene etc. tell us exactly where to stop. So actually making it is a matter of (way less) time.
3) you get instant self-feedback
because you can actually see your work, rather than "think about it". This will train your eyes and mindset to perceive errors before those errors are in game form, and you'll have to do double the work to correct themselves
In short, make sure you have pre-planned everything, from your maps, character dialogue, cutscenes, encounters etc, before you go ahead and make them. Plan both on the smallest scale possible for the specifics, and on the grandest scale possible so you can visualize the project's ultimate aim.
If it is a small jam game, spending 5 days planning the entire game, with the scope being small in mind, and knowing you just need a simple game with a core concept, will be as if you had been actually developing it for 5 months. We will expand on the core concept issue later.
Finally, it is absolutely true that many people are impulsive and can much more easily design on-the-spot. They might feel asphyxiated by following a pre-planned route. Some might even lose inspiration. If you are one such person, then pre-plan a very general bare-bones skeleton, and derive your more specific creativity from that.
The Test Map:
A good practice is to have a map where you can test the vast majority (if not all) of the main gears of your game. Remember the Transfer example from above? Make a map that includes all the different transfer tests. In the same map, you can include, let's say, your distinct types of trainers you will use (let's say, a single battle, a double battle, a gym battle, and wild encounters). Pokemon encounters both in grass and in events. A small cutscene test, with a proper conclusion. Events that trigger other events. The examples that come with Essentials are very good, but might be too spread out if you aren't already familiar with RPG Maker.
The Tester-Developer:
Do not just wait for Testers to show up, and do not hand out your game for testing if you haven't done at least three runs, one of which being meticulous, yourself. First of all, don't playtest in you debug mode, menus, or functions. Play the game normally.
Secondly, to avoid perception errors, take a small break from development, then test your game afresh. Only then, invite external Testers over. Remember, community testers do this out of their own free time – make sure you are giving them something that will respect their time. Otherwise people will simply avoid playing your game.
Make Your Game about One Thing Mostly:
You don't need a multigenre spanning experience with shadow Pokemon, contests, soaring, and 18 gyms. Make a game about a Trainer struggling to get their first Badge, or a battle-focused facility, or a very small region with one main challenge.
You can be great at one thing, but not very good at multiple things, especially as a beginner.
Manage your Time:
"I want to make a game with 1 great map". "Today, I will work on only ONE character's dialogue for ONE cutscene" These small victories will maintain your motivation and endurance in the long run. Looking back at what you have done every day is not a simple psychologically uplifting checkmark. It is a factual progression point in your endeavor.
Managing your time isn't limited to game development. You also need to learn many new things, and do a lot of extra activities. Exercise will do good for your brain. Paying attention to your friends needs' will take your mind away from monotonous work and give you inspiration. Becoming a better person yourself will make you write better characters… etc
But most of all, don't crunch. It will devastate you physically, and you aren't even getting paid for it.
You are primarily a designer, and then everything else:
No matter your skill in making assets, story, or even code, you need to primarily function as a designer, to be able to make an actual game. It's good to be specialized in one area, by all means, but those cannot stand on their own. Develop your general design and engine use skills in tandem with your specialty.
Coding frequently comes up, but is "unnecessary" in engines like RPG Maker, so that shouldn't even be a fear in the first place. Besides, if you learn how to use an engine properly, you will gradually adjust to code too (although for most fangames, it's not required).
Do not Reuse:
Anything that is general, and not specific, and needs to be used multiple times, should only exist in one place, where you can access it from.
Example: We want to check if the player has a Pikachu in their party. We go to an example map in Essentials, or the Wiki, and we find out that a "Conditional Branch" is used, that checks for the species called Pikachu.
Now, let's say we want to check that many times in our game, in like 4 different maps. Instead of copying and pasting the same event, we can use a Common Event – an event we can access from anywhere, by using Call Common Event from our Commands. This event exists in our Database, under Common Events. We can copy and paste the call to our Common Event on many different maps.
So if we need to make any changes to this, we won't need to make changes in 4 different events on 4 different maps. We only need to change 1 event in 1 place – our list of globally called Common Events.
Auto vs Manual:
Do not try to manually do what can automatically be done. This will cost you hours upon hours of development.
Example: You want different shiny sprites. Ask yourself, would it be wise to spend 200 hours manually recoloring 200 species? Or, perhaps, there is a way to do this automatically? For instance, you could use external program to batch-handle these files and assign them a different pallete. Or use code in the game that does exactly that. But, could there be a public resource that already does that?
Public Resources
If you have had an idea, there's likely already a resource about it. Public Resources are the bread and butter of any hobbyist community, and they cover almost everything you could come up with.
The "Mechanics and Assets First" Fallacy:
Don't wait for the "proper assets" to make a game.
Not only will you almost never find them, they are unnecessary for a good game. Imagine that you have literal grey blocks for graphics, and no music. You can make an amazing game with only those.
Don't waste your time on a "needed" mechanic to make your game stand out, when said mechanic isn't the sole focus of the game.
The "I need a Team " Fallacy:
Many people wait for team positions to be filled before they even start making any game. Do not wait for a team to start. Make your game yourself, and then ask for extra support (that might not even be needed, in the end).
If you have very specific needs, consider 1) learning how to do it yourself later, 2) get some people to join, only after you have a concrete, playable game. You don't really need either "that one asset" that will make your game good, neither "that specialist", when you first start out – especially as a designer.
The Paid Commission Fallacy:
Paid assets give the impression that "if I buy them my game will be great" or "this artist is amazing, their work will make my game good" or "I don't want to use public assets because every game will look the same", which, as a beginner, translates to: " I have no essence to show and nothing unique in my game's core, and I want my selling point to be the assets".
Personally, I am against paid work and resources in the fangame world, not only due to the above practical reason, but because it also has an ethical side to it. It's understandable that commissions provide those in financial need with more means, and are a good way to train for future professions, but they can get people to rely on them (and spend money on a project that might not even see fruition, exacerbating the guilt on part of the amateur developer). Moreover, many devs will feel intimidated by the perceived competition, and thus become disheartened.
Donations for public resources are a great way to avoid all these issues. Back to the point:
Assets by themselves won't make your game a good game. You will, and only you can. You might be afraid of the fact that this is an inherent limitation, and that you have to work with it. However...
Limitation is the Mother of Creativity
Many unique styles have been birthed because of limitation - almost all videogames before the 2000s - many gaming traditions are the direct evolution of concepts based on hardware limitation, and most of all inventiveness comes as a result of attempting to overcome limitations, or, working with a limited toolset.
Let's use a practical example. Remember the previous mention of grey blocks for graphics, and no music? Use this as a starting point.
What if the story is about a stray pixel inside a computer screen, in a dystopic hardware world, that tries to overcome its mundane, physics-constrained routine? What if the lack of music can be supplemented later by a few electronic sounding pieces you can just use automatic synths to make?
The only ceiling that exists in art and everything else, is giving up. Work with, and around your limitations, and not against them.
Do not Reinvent the Wheel
Don't try to make something without looking up if it has been implemented first. Alternatively, make sure you have learned how to do any of the basic stuff, before you bring that one mechanic you want to life. You will lose so much time, that might even be years of gamedev, that you could have avoided had you asked people about something that has already been done. Don't be afraid to ask not only for their guidance but also for permission to use something that's already there.
Scope
You will have likely heard about how important it is to make a smaller game when you first set out to develop something. This is in the vast majority of cases absolutely true. At this point, you are not yet equipped with the experience necessary to inherently understand how large of a scope you can realistically manage, and how to adapt to either a project deadline, or to changes in your personal life.
Experience is a multiplier of time. If you don't obtain said multiplier by making smaller projects with achievable aims, you will spend double, triple, or quadruple the time on a big project. And this time will most likely work against you on a psychological and material level.
The very big type of project suits the 26-36 age demographic (or college students depending on their field), whose jobs are more stable, and whose general free time can be more easily devoted to a single thing. Other age groups need to take into consideration their own specifics (spending free time, learning new things, looking for a job, having fun etc). You can definitely work on your "magnum opus" on the side, but you should be very careful about it. Burnout from general creativity is a real thing.
The takeout from this is: go small, but don't be afraid of bigger projects. You don't really need to be a special person to make a big project. This is likely a demotivational understanding of your own capabilities. Big projects simply need discipline, consistency, and experience.
A Game is a Game only when it's Playable.
In the end, it all boils down to this. Countless hours of brainstorming, or even planning. Meticulous crafting of dialogue. Even… preparing assets. All for a "concept" of a project that has never really materialized into playable form. I will repeat this over and over. You only have a game, when you actually have a playable one. No matter if you have hired Mozart for your music, and Van Gogh for your assets – if the game isn't a game, you have done nothing. The most bland, boring game, that is playable, is by definition a superior game to your theoretical game, that really isn't one.
Make the game, no matter what it is. Then you will make more, and more, and better...
Motivation vs Discipline
As a hobbyist developer, or perhaps an aspiring indie one, you most likely have had a burst of inspiration and motivation that propelled your imagination to the stars, and kindled a desire within you to make something of your own. Or, perhaps, you are obsessed with games and want to try your hand at making one. Or, even, you are just a kid with big dreams, and want to do what is popular at the moment (videogames have become really big nowadays) or are totally enamored by both the fantastical worlds of games, and the idea of making one itself.
It is highly likely you have caught yourself during an unmotivated phase, or telling other people about how you "can't find the motivation" to keep working on a project. But, how does motivation work? Motivation feels like an unstoppable force, but has a limited capacity. Think of it like sprinting. When you sprint, you can go insanely fast, but you'll eventually run out of steam. Whether you will reach your target or not, will be entirely dependent on your inherent talent, and not your working ethic.
So what happens when you don't have the speed and energy to complete a run? Well, the answer is easy. You don't. You must walk.
Walking, in this case a consistent routine of working on your game. It will necessarily bear fruits in the long-run.
In essence, working on a project consistently also allows for room for more improvement, and self-reflection. Motivation alone is too much of a chaotic force to rely on, unless you are a very impulsive person in general – in which case you will also likely suffer from intense burnouts more frequently, to accompany the motivation spurs.
Begin with one hour a day, weekends off. That would be 5 hours a week. Now imagine keeping that up for a month. That'd be at least around 22 hours of work. Add that for a year, and you'll end up with a humongous number, usually well-over 5000 hours. And that is assuming you only put in 1 hour of work every day.
In short: Consistent, disciplined work, instead of reliance on your current emotional state, waiting for motivation to kick in, and inspiration to suddenly fall from the sky. Obviously, this is necessarily accompanied by emotion.
Internal Matters - The Big Idea:
By far the most difficult thing is managing your emotions (even if you are an analytical person). On the early stages, most people are enamored and sometimes overwhelmed by the idea of making a game, and the possible images of said game idea popping up in their heads. That is good for the first few days, but after that it can become a hindrance. Any idea you have you must apply it in a game form, as fast as possible.
Your Personality:
As a beginner (and even further up), you are likely to be met with fear, anxiety, and creative paralysis, if you are more sensitive in general - or resistance to change, boredom and dismissiveness if you are less sensitive. The common denominator here is your ego. For sensitive people, it manifests as aversion to feedback, or fear of being judged, and for less sensitive people, as omission of feedback (for instance, you have the feeling that your work is perfectly fine, and feedback is being understood as nitpicking, or hyperbole). It is obviously great to be content with your work in the latter case, but you shouldn't let that stop you from elevating your art, and constant improvement.
The Objective Measurement:
The only real objective indicator of your work being good is your own progress, regardless of level. You should judge yourself based on constant self-improvement adaptation, and building using small blocks every day, rather than where your work currently stands in relation to other works.
Then, you need to consider what comparing your game to other games really means. Let's get straight to the point, here. To compare yourself to other developers, is unnecessary. You shouldn't be comparing a person, but a learnable skillset. For instance, a developer has made a huge game with great stuff in it. Nice, but it is the actual work and the methods used that should be in your mind, and not the skills of the person who made it. So you should ask them about their methods, and consider imitating their practices, instead of comparing yourself against them.
The degree of your success should be always be how much you have learned. Have confidence in what you have learned, not in who you are.
Talent vs Work
You will no doubt have heard about this a million times before. But there is a method to it. People who have inborn talents have a stronger and faster start. But they also have to put a lot of work into something, barring extreme cases. What really matters here, is that your desire to learn, can overcome even the biggest of talents.
That's right. Stop hanging around nihilistic Reddit threads, born from the spirit of people who do not wish to live outside their own screens. I am sorry if this sounds like a take, but you can't improve if you think everything is pointless. Especially if you haven't trained yourself how to learn. You aren't limited by your genetics, or intelligence. This is a frequent topic coming up in art forums, and in the minds of many people who get overwhelmed.
Your issues as a hobbyist most likely derive from 1) bad learning and teachers, 2) your emotional state, 3) lack of consistent long-term practice and work. If you lack a lot in some areas, you need people who can identify those weaknesses and teach you in a manner that is better communicated to you. People who are geniuses, are just people. And so are you. Don't let the negative aspects of your game design skills prevent you from becoming better.
Hard Work should be Smart Work
Just spending thousands of hours doing the wrong, inefficient, or mundane things, will net you a game that is not a good game. You will end up with resentment, telling others "I've worked for 6 years but my game sucks and nobody wants to play it".
Assume you are reading a book. If you are reading the same page for 6 years, will you know anything about the rest of the book? No. That is why you must wake your heart up to the fact that you must be perceptive of, and willing to learn, first.
Train yourself how to learn.
You are not Competing Against Anybody:
Fangames, as hobbyist works, are not in competition with each other. Of course, having the spirit of friendly competition is a great thing, but even if you don't have it, you need to consider that fangames coexist, instead of competing against each other, as another developer has wisely said (shoutout to, Aki). That means, you are just offering people another new experience! So, get over the anxieties of having to "measure up" to certain standards.
Discarding Ego:
If there is one thing that halts all progress, that would be one's ego. It will always fight against your progress, irrespective of skill level, and experience.
It is impossible to learn if you already believe you know.
You need to put yourself in the heart of a child – and become a sponge that will absorb any and all feedback, any and all information, and consider themselves a person who doesn't have the faintest idea about the world. In fact the more knowledgeable and wise you become, the less you will think you know.
The most difficult cases are usually late teens or early young adults, who have been born with big talents, and who find everything much easier in their path – yet either start to fall off as the years progress, or become very set in their ways and their understood knowledge. The more your ego gets inflated, the less your work will be filled passion, be adaptable, and open to improvement. At first, you'll need to realize that you are indeed a beginner.
But Then Using Ego:
You'd then need to realize that you aren't really that different from anyone else. But after maintaining a humble mindset that is accepting of learning and feedback, you now have to build a steadfast, "never give up" attitude, so that you can push yourself as a hobbyist. Professionals need to do that as part of their work, hence why they are disciplined and have to practice long-term. But you need to keep moving forward despite likely having to take care of another job altogether.
Overcoming Shame
Most people are afraid to expose their work to the world. This can be the result of self-esteem disguised in both negative and positive ways.
Perhaps you are secretly considering your work too important, and as related to your own self-conception, to be judged poorly. Or, because of a condition, or your upbringing, or both, you could be considering yourself "worthless" or incapable of attempting to make something. Having all the aforementioned from the previous paragraphs in mind, don't be. Your work is a process of incessant improvement, rather than a result.
A work of art is not an object in space, but in time.
You will get people who will say that what you did sucks. And it could very well suck! That means you will need to improve it. If your work didn't suck in specific ways, you would never know where to improve. So base your self-judgement on the specific areas that need to be improved upon constantly.
Even if you have to deal with issues unrelated to gamedev, do not convince yourself that those issues are preventing you from improving. Your mindset and bad habits are most likely to blame.
Dealing with Feedback, or Lack Thereof
Listening to feedback is 90% of game development progress. It is naturally harder for any artist or designer to have a clear view of their work, for two reasons. One, bias. Two, getting used to what you see and do. Outside view is not only integral to understanding your own, but it is also EXACTLY what a game is about – other people playing it. A game is by nature made to be played. This necessitates other people's input.
However, you must both adapt to feedback, and not remove the core things that make your game your game. This is a delicate balance that can only come with experience.
Aside from that, the worst thing that can happen to a dev at any point of development, is lack of feedback. Emotionally, this is the point where most developers stop. No responses, no comments, no attention. This is where you have to take a step back, and consider making a very small project with unique ideas, and be upfront about your weaknesses. Focus on one area, and make it your strong area. Then show the world.
Even if you don't get any feedback, keep going. Rome wasn't built in a day, and one of the biggest virtues is patience. Under any, and all negative circumstances you need to keep pushing forward, and learn to love your work.
Giving feedback
Giving feedback can actually be a good way of reflecting on parts of your own work. However, you must be careful. Don't be fast to judge the work of others before attempting to see what actually making such a work is.
It's easy to make fun of a fangame's imperfect pixel art, when you haven't sank hundreds of hours into trying to really make pixel art yourself. Modern-day constant dopamine rush from perfect-looking works of professionals, and an incessant stream of stimuli also don't help in that regard. Give both yourself and your fellow devs a break, and look for the essence of the experience.
Who are you doing this for?
Do not attempt to make a game for its reception, or to get popular. If you are business-oriented person that also has talent, efficiency and discipline -sure. But that is a very small percentage of people. You must primarily make a game because you love doing it. Secondarily, for its own sake. Art for the sake of art, and expressing yourself and your emotions. That's what makes games good. Neither graphics, nor music, nor a great story, but the communication of your feelings.
Don't shoot for your Style Immediately:
Offering your unique flavor is fine but it's not recommended to do so, before learning the accepted methods and style conventions first. What do I mean by "accepted"?
You might be resistant to adopting concepts, techniques, and methodologies. Some people might even feel threatened by the "accepted" methods, and want to "follow their own path". However, there is a reason certain methods, best practices, and approaches exist, and are considered better than others.
That is because not only do they work, but they are also the result of very painful years of careful thought and practice, from people much more experienced, and likely talented, than you. After using them for a while, and learning them, you will understand why they are considered as such. But, you will also have the experience and skills to produce something as unique as can be.
What is inspiration?
An elusive creature. Make sure to look for it in other people's works, and let yourself be changed (in good ways) by what they want to communicate. Then, it's likely you will, quite literally, take a part of them and incorporate in yourself. In a less joking manner, you are your friends. Yeah this sounds like something from a manga for kids. But it is ultimately true. To be humble, and be influenced by the great work of others, means you actively adapt that into your own approach.
Gaming is a waste of time?
If you like making games, you most likely like playing them too. I have spent a big amount of my early years playing videogames, and I can tell you from both personal experience and working with people, that it is true that gaming can consume you. Some experts will tell you that to be addicted to videogames in the first place, you need to have a preexisting condition, or other issue. That is also true, but it's a fact that videogames are addicting by nature.
Everything in excess can be bad for you. Games can be amazing provided you are playing them, and they aren't playing you. In terms of game development – just think about this: How many hours do you have on a random MMO on steam, or another game(s)? What if those hours were spent creatively? I will, again, mention that doing something you love isn't a waste of time. But excessive usage will always be bad for you. Input of stimulus is an inferior form of entertainment, compared to output. You will be a happier person being creative, than just consuming. With time, you will find the proper balance!
Finally, The most Important, and perhaps Only Thing You Need to Have
And that is love. If you love your work of art, it will be carved onto said work, and people will not pay attention to the inevitable negatives of your game. That is because their attention goes to the overall fruit of your labor, the epicenter, rather than the layers above.
Rationalistic, scholastic, and purely analytical arguments about art should be reconsidered. Art is primarily driven by emotion, and is about emotion.
While analytical work can get you extremely far, you need to operate under the axiom that there are forces of the soul whose actions cannot be reduced to a materialistic causality. If the sentence above sounds like gibberish, then you are on the right track. If you know what it is about, then you can also understand why it says what it does.
You have to want to feel, in order to output feeling – which is what art is all about. Of course, analytical work, if done under the above axiom, will help you achieve the emotional side that you might not be able to, at first.
========================================================================
And with this the guide has concluded. You can read further below for a more personal experience with RPG Maker, and the scene over the years.
The Shame of a "pokemon" Game, and the issues of "What engine to use"
During my teenage years, another thought lingered in my mind. I've had a bit of a tumultuous relationship with the internet, and I remember the days where there was mockery and sometimes even hatred against fangames for being "angsty" and "sad teen attempts" to play-pretend at being a "real" developer.
Obviously, there was a truth to the angsty side of early games. And while we must avoid judging other people, or criticizing their work, we must learn from their mistakes, as well as our own. Does it really matter if your game is angsty? It does if you are willing to improve. But if you are a teenager making a game, of course it will contain your worries and emotions. That is perfectly fine! Don't be afraid to express your emotions! But make sure you learn in the process.
The modern fangame scene is not only very accepting (with a few exceptions, and this is a huge topic for another day), but the scene itself has gone past its adolescent year as a scene. We have amazing people pushing out incredible resources, random teenagers that can come up with code my old ass can't even comprehend, artists of immense talent that have not even gotten out of school. This is the best period to make your games, and with everything that is going on in the world right now, it might be the best outlet, too!
But, back then, I couldn't consolidate these thoughts. I was quite critical of other people's work, and in my own teenager negativistic phase, I was making fun of "pokemon fangames". I thought the developers were just crazy manchildren who were also artistically inept. You see, I couldn't understand the value of hard work, neither the fact that these projects were labors of love, a process that I ultimately was secretly jealous of.
So, I ended up giving it a go myself. It is obvious to anyone who has ever put any effort into anything, that things aren't as simple, or easy, as they seem.
A small game in RPG Maker (an engine that more than a decade ago, was frowned upon by "the real developers", and for catering to the baby crowd) takes big effort to bring into fruition. You see, these very easy to use hobbyist engines are mostly utilized for prototyping purposes (imagine a barebones draft that is playable to test out concepts), or are considering too limiting for professionals.
While the above statements are true to a degree, there is one major characteristic that these easy-to-develop-with engines provide. And that is they teach you how to actually design a game. If you stick with a couple of RPG Maker projects, you will have an innate understanding of how things work in general game development. Migrating to a more professional engine will be much easier, and most of all, you will actually have released a playable game.
Obviously, you can make professional projects on RPG Maker too – but the point of this rant, is that as a hobbyist, RPG Maker is a great tool to put a real playable game out.
And as a final reminder….
DO WHAT YOU LOVE!
When it comes to first starting out, the biggest question that arises is "Where to even begin? I am totally lost and this feels like an immense undertaking."
When I first began making games, I had the same question. I loved games since I was a kid, and was mildly obsessed with them. When I noticed fan projects around my teenage years, I was left speechless by what the developers could do. Was it even possible to make anything even close to all these amazing graphics? The story? How could they come up with ideas, and materialize them, to such a degree that it felt like a humongous mountain looking down on a beginner with zero experience? How can you deal with the thought that your work will be inadequate, and that you aren't a real designer or artist – not only compared to other fangames – but because of your work is a fangame in the first place, too. Should I really undertake such an enormous task, only for it to be a silly idea about an almost 30year old franchise, one that will never really net you any money – and when there is enormous "competition" from what seems like unreachable developers?
The truth is that fangames are not in direct competition with each other - and the result of your work is not dependent on your talents alone. We'll address these later, so let's begin with the most important factor that can determine your progress, and that is learning.
Learning Methods:
There are generally three major approaches to learning how to make a game.
1) Through observation and imitation
This method requires you to break down a game you like into the smallest segments possible, so that you can analyze them in practice. Forget about the more general concepts that a game has managed to do well, and just go to one map/level. Break it down.
How long is it? If it's the first map, it's likely small, right? What purpose does it serve? Is it to teach the player how future mechanics come into play? Why are some of the sprites using this color? Is it to set the mood? Why is the story presented only through objects and without dialogue? Is it because the game wants to tell a story through its environment?
After breaking it down, try making a map/level of your own, following the same principles. Some people can go as far as to count the number of total tiles, houses and objects, to imitate a level perfectly. That may or may not prove useful, as it can lead to uninspired copying, instead of inspired imitation.
The purpose of imitating something, is so that you can uniquely expand on its well-done elements. It is also possible to absorb what you see in a more intrinsic manner, but this is usually a process that "just happens" and there is not a lot to say about it. Some people have this tendency more developed than others.
2) From Reading tutorials
This is self-explanatory, learning from tutorials is a great place to start, but will be constrained by a) the amount of tutorials, b) the topic of tutorials, c) the quality of tutorials, d) the scope of tutorials. That is why you should immediately attempt to apply in practice what you have read.
Good tutorials are a must to save you a huge amount of time. You can find a lot of great tutorials on Relic Castle and Pokecommunity. It's likely that some will need to be re-read more than a couple of times to make sense as a beginner, but you should also notify the authors about the parts that weren't communicated as well to you. Again, tutorials exist so that you can apply them.
3) By Experimenting (this part will be updated with pictures later)
You must learn by tinkering with, and actually using the game engine. Make one map. Two events. Play the map. What happens if you do X? What happens if Y comes before X? This is learning by doing. It is vital to use this method, if you want to have any progress at all.
Do everything you can to mess around with how the gears move. Take a mental or written note of what did what, and try to think about the reasons. For instance, you transferred the player to another map - the map's name showed, but the screen is black. What have you done wrong? Perhaps the fading to black is a different thing from the actual transfer?
Experimentation should be done with the most limited and isolated scope possible. This serves the purpose of isolating and replicating a process, but also teaching you how to properly test a game. Let's go back to attempting to transfer the player. If we open one of the example transfer events that come with Essentials, let's say, the event that transfers the player to their house, we can see there is a number of commands.
As beginners, we can't understand what these commands do just by looking at them. But we know they work. So, let's copy this event, and remove the last line (that sets screen tone to 0, 0, 0). Hit the playtest button and let's enter the door. What happens now? The transfer worked but the screen faded to black – or more correctly, it was never set back to the "no color" value. So, from this, we can understand that this command does exactly that. The command right above it says quite clearly what it does: transfers the player to a specific tile on a map. At the very top, the same command we removed from the bottom appears – but is slightly different. It sets everything to -255. That means that it makes everything black. Let's try to slide the values all the way up to +255. Hit play. What happens now? Everything is white. Now let's try only to use the Transfer Map command. What happens? Player transfers as they are to their house, without any change in the screen. Now let's not use a "wait" command. The player insta-transfers.
You will have noticed that we only changed one thing at a time. It is necessary, when you tinker with anything in the engine, to only test one change you have made, in one place only, and one at a time.
This will have the extra bonus of allowing you to understand, and later examine, why things work how they do, so that you can also know the when. Now that you know that a Screen Tint command that goes to -255, fades everything to black, if you find your player transferred to a place where you cant see anything, you will know that this actually occurred in the previous map, where the transfer itself took place.
Remember: a game is not a hypothetical, theoretical work. It is an actual, material work. If you don't know what bricks are, how to stick them together, and where to do so, you can't build a house.
Planning and How To:
Once you have learned the basics, and have a basic understanding and tinkering experience, there will be one big hurdle that you will have to face. This hurdle is often "invisible", and is the second biggest time-sucker in game development, after improper learning. That hurdle is called lack of planning.
Lack of planning means that while you are using your bricks to build a house, you are also designing how, where, and with what to build the house at the same exact time. This means more than double the work, concurrently. Suffice to say, this is not only much more exhausting than needed (and will drain you in the long-term) but it's also physically inefficient. Both your on-the-spot design, and your actual building, will suffer from the divided attention, brainpower, and energy reserves.
A good plan not only can save you up to years of actual work, but it is the most successful strategy to make short jam games, and long big games too. This happens for primarily three reasons:
1) Your ideas can immediately be applied
All your subsequent actions are the materialization of your work, and you can immediately transfer from paper to an actual map/level/cutscene
2) you have set the exact limits
which means you know where to start because you know where to end. A practical example: Let's say we want to make a small town. If we decide that we'll have 5 buildings, that the town will have to be on a 68x68 map, and if we have designed the map on a paper (roughly), we have already done half the work. And the limits and "skeleton" of our map, level, dialogue, cutscene etc. tell us exactly where to stop. So actually making it is a matter of (way less) time.
3) you get instant self-feedback
because you can actually see your work, rather than "think about it". This will train your eyes and mindset to perceive errors before those errors are in game form, and you'll have to do double the work to correct themselves
In short, make sure you have pre-planned everything, from your maps, character dialogue, cutscenes, encounters etc, before you go ahead and make them. Plan both on the smallest scale possible for the specifics, and on the grandest scale possible so you can visualize the project's ultimate aim.
If it is a small jam game, spending 5 days planning the entire game, with the scope being small in mind, and knowing you just need a simple game with a core concept, will be as if you had been actually developing it for 5 months. We will expand on the core concept issue later.
Finally, it is absolutely true that many people are impulsive and can much more easily design on-the-spot. They might feel asphyxiated by following a pre-planned route. Some might even lose inspiration. If you are one such person, then pre-plan a very general bare-bones skeleton, and derive your more specific creativity from that.
The Test Map:
A good practice is to have a map where you can test the vast majority (if not all) of the main gears of your game. Remember the Transfer example from above? Make a map that includes all the different transfer tests. In the same map, you can include, let's say, your distinct types of trainers you will use (let's say, a single battle, a double battle, a gym battle, and wild encounters). Pokemon encounters both in grass and in events. A small cutscene test, with a proper conclusion. Events that trigger other events. The examples that come with Essentials are very good, but might be too spread out if you aren't already familiar with RPG Maker.
The Tester-Developer:
Do not just wait for Testers to show up, and do not hand out your game for testing if you haven't done at least three runs, one of which being meticulous, yourself. First of all, don't playtest in you debug mode, menus, or functions. Play the game normally.
Secondly, to avoid perception errors, take a small break from development, then test your game afresh. Only then, invite external Testers over. Remember, community testers do this out of their own free time – make sure you are giving them something that will respect their time. Otherwise people will simply avoid playing your game.
Make Your Game about One Thing Mostly:
You don't need a multigenre spanning experience with shadow Pokemon, contests, soaring, and 18 gyms. Make a game about a Trainer struggling to get their first Badge, or a battle-focused facility, or a very small region with one main challenge.
You can be great at one thing, but not very good at multiple things, especially as a beginner.
Manage your Time:
"I want to make a game with 1 great map". "Today, I will work on only ONE character's dialogue for ONE cutscene" These small victories will maintain your motivation and endurance in the long run. Looking back at what you have done every day is not a simple psychologically uplifting checkmark. It is a factual progression point in your endeavor.
Managing your time isn't limited to game development. You also need to learn many new things, and do a lot of extra activities. Exercise will do good for your brain. Paying attention to your friends needs' will take your mind away from monotonous work and give you inspiration. Becoming a better person yourself will make you write better characters… etc
But most of all, don't crunch. It will devastate you physically, and you aren't even getting paid for it.
You are primarily a designer, and then everything else:
No matter your skill in making assets, story, or even code, you need to primarily function as a designer, to be able to make an actual game. It's good to be specialized in one area, by all means, but those cannot stand on their own. Develop your general design and engine use skills in tandem with your specialty.
Coding frequently comes up, but is "unnecessary" in engines like RPG Maker, so that shouldn't even be a fear in the first place. Besides, if you learn how to use an engine properly, you will gradually adjust to code too (although for most fangames, it's not required).
Do not Reuse:
Anything that is general, and not specific, and needs to be used multiple times, should only exist in one place, where you can access it from.
Example: We want to check if the player has a Pikachu in their party. We go to an example map in Essentials, or the Wiki, and we find out that a "Conditional Branch" is used, that checks for the species called Pikachu.
Now, let's say we want to check that many times in our game, in like 4 different maps. Instead of copying and pasting the same event, we can use a Common Event – an event we can access from anywhere, by using Call Common Event from our Commands. This event exists in our Database, under Common Events. We can copy and paste the call to our Common Event on many different maps.
So if we need to make any changes to this, we won't need to make changes in 4 different events on 4 different maps. We only need to change 1 event in 1 place – our list of globally called Common Events.
Auto vs Manual:
Do not try to manually do what can automatically be done. This will cost you hours upon hours of development.
Example: You want different shiny sprites. Ask yourself, would it be wise to spend 200 hours manually recoloring 200 species? Or, perhaps, there is a way to do this automatically? For instance, you could use external program to batch-handle these files and assign them a different pallete. Or use code in the game that does exactly that. But, could there be a public resource that already does that?
Public Resources
If you have had an idea, there's likely already a resource about it. Public Resources are the bread and butter of any hobbyist community, and they cover almost everything you could come up with.
The "Mechanics and Assets First" Fallacy:
Don't wait for the "proper assets" to make a game.
Not only will you almost never find them, they are unnecessary for a good game. Imagine that you have literal grey blocks for graphics, and no music. You can make an amazing game with only those.
Don't waste your time on a "needed" mechanic to make your game stand out, when said mechanic isn't the sole focus of the game.
The "I need a Team " Fallacy:
Many people wait for team positions to be filled before they even start making any game. Do not wait for a team to start. Make your game yourself, and then ask for extra support (that might not even be needed, in the end).
If you have very specific needs, consider 1) learning how to do it yourself later, 2) get some people to join, only after you have a concrete, playable game. You don't really need either "that one asset" that will make your game good, neither "that specialist", when you first start out – especially as a designer.
The Paid Commission Fallacy:
Paid assets give the impression that "if I buy them my game will be great" or "this artist is amazing, their work will make my game good" or "I don't want to use public assets because every game will look the same", which, as a beginner, translates to: " I have no essence to show and nothing unique in my game's core, and I want my selling point to be the assets".
Personally, I am against paid work and resources in the fangame world, not only due to the above practical reason, but because it also has an ethical side to it. It's understandable that commissions provide those in financial need with more means, and are a good way to train for future professions, but they can get people to rely on them (and spend money on a project that might not even see fruition, exacerbating the guilt on part of the amateur developer). Moreover, many devs will feel intimidated by the perceived competition, and thus become disheartened.
Donations for public resources are a great way to avoid all these issues. Back to the point:
Assets by themselves won't make your game a good game. You will, and only you can. You might be afraid of the fact that this is an inherent limitation, and that you have to work with it. However...
Limitation is the Mother of Creativity
Many unique styles have been birthed because of limitation - almost all videogames before the 2000s - many gaming traditions are the direct evolution of concepts based on hardware limitation, and most of all inventiveness comes as a result of attempting to overcome limitations, or, working with a limited toolset.
Let's use a practical example. Remember the previous mention of grey blocks for graphics, and no music? Use this as a starting point.
What if the story is about a stray pixel inside a computer screen, in a dystopic hardware world, that tries to overcome its mundane, physics-constrained routine? What if the lack of music can be supplemented later by a few electronic sounding pieces you can just use automatic synths to make?
The only ceiling that exists in art and everything else, is giving up. Work with, and around your limitations, and not against them.
Do not Reinvent the Wheel
Don't try to make something without looking up if it has been implemented first. Alternatively, make sure you have learned how to do any of the basic stuff, before you bring that one mechanic you want to life. You will lose so much time, that might even be years of gamedev, that you could have avoided had you asked people about something that has already been done. Don't be afraid to ask not only for their guidance but also for permission to use something that's already there.
Scope
You will have likely heard about how important it is to make a smaller game when you first set out to develop something. This is in the vast majority of cases absolutely true. At this point, you are not yet equipped with the experience necessary to inherently understand how large of a scope you can realistically manage, and how to adapt to either a project deadline, or to changes in your personal life.
Experience is a multiplier of time. If you don't obtain said multiplier by making smaller projects with achievable aims, you will spend double, triple, or quadruple the time on a big project. And this time will most likely work against you on a psychological and material level.
The very big type of project suits the 26-36 age demographic (or college students depending on their field), whose jobs are more stable, and whose general free time can be more easily devoted to a single thing. Other age groups need to take into consideration their own specifics (spending free time, learning new things, looking for a job, having fun etc). You can definitely work on your "magnum opus" on the side, but you should be very careful about it. Burnout from general creativity is a real thing.
The takeout from this is: go small, but don't be afraid of bigger projects. You don't really need to be a special person to make a big project. This is likely a demotivational understanding of your own capabilities. Big projects simply need discipline, consistency, and experience.
A Game is a Game only when it's Playable.
In the end, it all boils down to this. Countless hours of brainstorming, or even planning. Meticulous crafting of dialogue. Even… preparing assets. All for a "concept" of a project that has never really materialized into playable form. I will repeat this over and over. You only have a game, when you actually have a playable one. No matter if you have hired Mozart for your music, and Van Gogh for your assets – if the game isn't a game, you have done nothing. The most bland, boring game, that is playable, is by definition a superior game to your theoretical game, that really isn't one.
Make the game, no matter what it is. Then you will make more, and more, and better...
Motivation vs Discipline
As a hobbyist developer, or perhaps an aspiring indie one, you most likely have had a burst of inspiration and motivation that propelled your imagination to the stars, and kindled a desire within you to make something of your own. Or, perhaps, you are obsessed with games and want to try your hand at making one. Or, even, you are just a kid with big dreams, and want to do what is popular at the moment (videogames have become really big nowadays) or are totally enamored by both the fantastical worlds of games, and the idea of making one itself.
It is highly likely you have caught yourself during an unmotivated phase, or telling other people about how you "can't find the motivation" to keep working on a project. But, how does motivation work? Motivation feels like an unstoppable force, but has a limited capacity. Think of it like sprinting. When you sprint, you can go insanely fast, but you'll eventually run out of steam. Whether you will reach your target or not, will be entirely dependent on your inherent talent, and not your working ethic.
So what happens when you don't have the speed and energy to complete a run? Well, the answer is easy. You don't. You must walk.
Walking, in this case a consistent routine of working on your game. It will necessarily bear fruits in the long-run.
In essence, working on a project consistently also allows for room for more improvement, and self-reflection. Motivation alone is too much of a chaotic force to rely on, unless you are a very impulsive person in general – in which case you will also likely suffer from intense burnouts more frequently, to accompany the motivation spurs.
Begin with one hour a day, weekends off. That would be 5 hours a week. Now imagine keeping that up for a month. That'd be at least around 22 hours of work. Add that for a year, and you'll end up with a humongous number, usually well-over 5000 hours. And that is assuming you only put in 1 hour of work every day.
In short: Consistent, disciplined work, instead of reliance on your current emotional state, waiting for motivation to kick in, and inspiration to suddenly fall from the sky. Obviously, this is necessarily accompanied by emotion.
Internal Matters - The Big Idea:
By far the most difficult thing is managing your emotions (even if you are an analytical person). On the early stages, most people are enamored and sometimes overwhelmed by the idea of making a game, and the possible images of said game idea popping up in their heads. That is good for the first few days, but after that it can become a hindrance. Any idea you have you must apply it in a game form, as fast as possible.
Your Personality:
As a beginner (and even further up), you are likely to be met with fear, anxiety, and creative paralysis, if you are more sensitive in general - or resistance to change, boredom and dismissiveness if you are less sensitive. The common denominator here is your ego. For sensitive people, it manifests as aversion to feedback, or fear of being judged, and for less sensitive people, as omission of feedback (for instance, you have the feeling that your work is perfectly fine, and feedback is being understood as nitpicking, or hyperbole). It is obviously great to be content with your work in the latter case, but you shouldn't let that stop you from elevating your art, and constant improvement.
The Objective Measurement:
The only real objective indicator of your work being good is your own progress, regardless of level. You should judge yourself based on constant self-improvement adaptation, and building using small blocks every day, rather than where your work currently stands in relation to other works.
Then, you need to consider what comparing your game to other games really means. Let's get straight to the point, here. To compare yourself to other developers, is unnecessary. You shouldn't be comparing a person, but a learnable skillset. For instance, a developer has made a huge game with great stuff in it. Nice, but it is the actual work and the methods used that should be in your mind, and not the skills of the person who made it. So you should ask them about their methods, and consider imitating their practices, instead of comparing yourself against them.
The degree of your success should be always be how much you have learned. Have confidence in what you have learned, not in who you are.
Talent vs Work
You will no doubt have heard about this a million times before. But there is a method to it. People who have inborn talents have a stronger and faster start. But they also have to put a lot of work into something, barring extreme cases. What really matters here, is that your desire to learn, can overcome even the biggest of talents.
That's right. Stop hanging around nihilistic Reddit threads, born from the spirit of people who do not wish to live outside their own screens. I am sorry if this sounds like a take, but you can't improve if you think everything is pointless. Especially if you haven't trained yourself how to learn. You aren't limited by your genetics, or intelligence. This is a frequent topic coming up in art forums, and in the minds of many people who get overwhelmed.
Your issues as a hobbyist most likely derive from 1) bad learning and teachers, 2) your emotional state, 3) lack of consistent long-term practice and work. If you lack a lot in some areas, you need people who can identify those weaknesses and teach you in a manner that is better communicated to you. People who are geniuses, are just people. And so are you. Don't let the negative aspects of your game design skills prevent you from becoming better.
Hard Work should be Smart Work
Just spending thousands of hours doing the wrong, inefficient, or mundane things, will net you a game that is not a good game. You will end up with resentment, telling others "I've worked for 6 years but my game sucks and nobody wants to play it".
Assume you are reading a book. If you are reading the same page for 6 years, will you know anything about the rest of the book? No. That is why you must wake your heart up to the fact that you must be perceptive of, and willing to learn, first.
Train yourself how to learn.
You are not Competing Against Anybody:
Fangames, as hobbyist works, are not in competition with each other. Of course, having the spirit of friendly competition is a great thing, but even if you don't have it, you need to consider that fangames coexist, instead of competing against each other, as another developer has wisely said (shoutout to, Aki). That means, you are just offering people another new experience! So, get over the anxieties of having to "measure up" to certain standards.
Discarding Ego:
If there is one thing that halts all progress, that would be one's ego. It will always fight against your progress, irrespective of skill level, and experience.
It is impossible to learn if you already believe you know.
You need to put yourself in the heart of a child – and become a sponge that will absorb any and all feedback, any and all information, and consider themselves a person who doesn't have the faintest idea about the world. In fact the more knowledgeable and wise you become, the less you will think you know.
The most difficult cases are usually late teens or early young adults, who have been born with big talents, and who find everything much easier in their path – yet either start to fall off as the years progress, or become very set in their ways and their understood knowledge. The more your ego gets inflated, the less your work will be filled passion, be adaptable, and open to improvement. At first, you'll need to realize that you are indeed a beginner.
But Then Using Ego:
You'd then need to realize that you aren't really that different from anyone else. But after maintaining a humble mindset that is accepting of learning and feedback, you now have to build a steadfast, "never give up" attitude, so that you can push yourself as a hobbyist. Professionals need to do that as part of their work, hence why they are disciplined and have to practice long-term. But you need to keep moving forward despite likely having to take care of another job altogether.
Overcoming Shame
Most people are afraid to expose their work to the world. This can be the result of self-esteem disguised in both negative and positive ways.
Perhaps you are secretly considering your work too important, and as related to your own self-conception, to be judged poorly. Or, because of a condition, or your upbringing, or both, you could be considering yourself "worthless" or incapable of attempting to make something. Having all the aforementioned from the previous paragraphs in mind, don't be. Your work is a process of incessant improvement, rather than a result.
A work of art is not an object in space, but in time.
You will get people who will say that what you did sucks. And it could very well suck! That means you will need to improve it. If your work didn't suck in specific ways, you would never know where to improve. So base your self-judgement on the specific areas that need to be improved upon constantly.
Even if you have to deal with issues unrelated to gamedev, do not convince yourself that those issues are preventing you from improving. Your mindset and bad habits are most likely to blame.
Dealing with Feedback, or Lack Thereof
Listening to feedback is 90% of game development progress. It is naturally harder for any artist or designer to have a clear view of their work, for two reasons. One, bias. Two, getting used to what you see and do. Outside view is not only integral to understanding your own, but it is also EXACTLY what a game is about – other people playing it. A game is by nature made to be played. This necessitates other people's input.
However, you must both adapt to feedback, and not remove the core things that make your game your game. This is a delicate balance that can only come with experience.
Aside from that, the worst thing that can happen to a dev at any point of development, is lack of feedback. Emotionally, this is the point where most developers stop. No responses, no comments, no attention. This is where you have to take a step back, and consider making a very small project with unique ideas, and be upfront about your weaknesses. Focus on one area, and make it your strong area. Then show the world.
Even if you don't get any feedback, keep going. Rome wasn't built in a day, and one of the biggest virtues is patience. Under any, and all negative circumstances you need to keep pushing forward, and learn to love your work.
Giving feedback
Giving feedback can actually be a good way of reflecting on parts of your own work. However, you must be careful. Don't be fast to judge the work of others before attempting to see what actually making such a work is.
It's easy to make fun of a fangame's imperfect pixel art, when you haven't sank hundreds of hours into trying to really make pixel art yourself. Modern-day constant dopamine rush from perfect-looking works of professionals, and an incessant stream of stimuli also don't help in that regard. Give both yourself and your fellow devs a break, and look for the essence of the experience.
Who are you doing this for?
Do not attempt to make a game for its reception, or to get popular. If you are business-oriented person that also has talent, efficiency and discipline -sure. But that is a very small percentage of people. You must primarily make a game because you love doing it. Secondarily, for its own sake. Art for the sake of art, and expressing yourself and your emotions. That's what makes games good. Neither graphics, nor music, nor a great story, but the communication of your feelings.
Don't shoot for your Style Immediately:
Offering your unique flavor is fine but it's not recommended to do so, before learning the accepted methods and style conventions first. What do I mean by "accepted"?
You might be resistant to adopting concepts, techniques, and methodologies. Some people might even feel threatened by the "accepted" methods, and want to "follow their own path". However, there is a reason certain methods, best practices, and approaches exist, and are considered better than others.
That is because not only do they work, but they are also the result of very painful years of careful thought and practice, from people much more experienced, and likely talented, than you. After using them for a while, and learning them, you will understand why they are considered as such. But, you will also have the experience and skills to produce something as unique as can be.
What is inspiration?
An elusive creature. Make sure to look for it in other people's works, and let yourself be changed (in good ways) by what they want to communicate. Then, it's likely you will, quite literally, take a part of them and incorporate in yourself. In a less joking manner, you are your friends. Yeah this sounds like something from a manga for kids. But it is ultimately true. To be humble, and be influenced by the great work of others, means you actively adapt that into your own approach.
Gaming is a waste of time?
If you like making games, you most likely like playing them too. I have spent a big amount of my early years playing videogames, and I can tell you from both personal experience and working with people, that it is true that gaming can consume you. Some experts will tell you that to be addicted to videogames in the first place, you need to have a preexisting condition, or other issue. That is also true, but it's a fact that videogames are addicting by nature.
Everything in excess can be bad for you. Games can be amazing provided you are playing them, and they aren't playing you. In terms of game development – just think about this: How many hours do you have on a random MMO on steam, or another game(s)? What if those hours were spent creatively? I will, again, mention that doing something you love isn't a waste of time. But excessive usage will always be bad for you. Input of stimulus is an inferior form of entertainment, compared to output. You will be a happier person being creative, than just consuming. With time, you will find the proper balance!
Finally, The most Important, and perhaps Only Thing You Need to Have
And that is love. If you love your work of art, it will be carved onto said work, and people will not pay attention to the inevitable negatives of your game. That is because their attention goes to the overall fruit of your labor, the epicenter, rather than the layers above.
Rationalistic, scholastic, and purely analytical arguments about art should be reconsidered. Art is primarily driven by emotion, and is about emotion.
While analytical work can get you extremely far, you need to operate under the axiom that there are forces of the soul whose actions cannot be reduced to a materialistic causality. If the sentence above sounds like gibberish, then you are on the right track. If you know what it is about, then you can also understand why it says what it does.
You have to want to feel, in order to output feeling – which is what art is all about. Of course, analytical work, if done under the above axiom, will help you achieve the emotional side that you might not be able to, at first.
========================================================================
And with this the guide has concluded. You can read further below for a more personal experience with RPG Maker, and the scene over the years.
The Shame of a "pokemon" Game, and the issues of "What engine to use"
During my teenage years, another thought lingered in my mind. I've had a bit of a tumultuous relationship with the internet, and I remember the days where there was mockery and sometimes even hatred against fangames for being "angsty" and "sad teen attempts" to play-pretend at being a "real" developer.
Obviously, there was a truth to the angsty side of early games. And while we must avoid judging other people, or criticizing their work, we must learn from their mistakes, as well as our own. Does it really matter if your game is angsty? It does if you are willing to improve. But if you are a teenager making a game, of course it will contain your worries and emotions. That is perfectly fine! Don't be afraid to express your emotions! But make sure you learn in the process.
The modern fangame scene is not only very accepting (with a few exceptions, and this is a huge topic for another day), but the scene itself has gone past its adolescent year as a scene. We have amazing people pushing out incredible resources, random teenagers that can come up with code my old ass can't even comprehend, artists of immense talent that have not even gotten out of school. This is the best period to make your games, and with everything that is going on in the world right now, it might be the best outlet, too!
But, back then, I couldn't consolidate these thoughts. I was quite critical of other people's work, and in my own teenager negativistic phase, I was making fun of "pokemon fangames". I thought the developers were just crazy manchildren who were also artistically inept. You see, I couldn't understand the value of hard work, neither the fact that these projects were labors of love, a process that I ultimately was secretly jealous of.
So, I ended up giving it a go myself. It is obvious to anyone who has ever put any effort into anything, that things aren't as simple, or easy, as they seem.
A small game in RPG Maker (an engine that more than a decade ago, was frowned upon by "the real developers", and for catering to the baby crowd) takes big effort to bring into fruition. You see, these very easy to use hobbyist engines are mostly utilized for prototyping purposes (imagine a barebones draft that is playable to test out concepts), or are considering too limiting for professionals.
While the above statements are true to a degree, there is one major characteristic that these easy-to-develop-with engines provide. And that is they teach you how to actually design a game. If you stick with a couple of RPG Maker projects, you will have an innate understanding of how things work in general game development. Migrating to a more professional engine will be much easier, and most of all, you will actually have released a playable game.
Obviously, you can make professional projects on RPG Maker too – but the point of this rant, is that as a hobbyist, RPG Maker is a great tool to put a real playable game out.
And as a final reminder….
DO WHAT YOU LOVE!
Last edited:
