Rookie Mistakes!

[Ragpuppy87]

So to all the more experienced game designers out there...
Care to share some classic rookie mistakes you made with your first few projects?
Make the rest of us beginners feel a bit better about our own mistakes?

 

[MushroomCake28]

I'll beat everyone else to it... (since all veterans here will all give you this piece of advice):

Do not start with a huge project as your first project. Start small.

And here's another advice (more like warning) that people sometimes forget: ALWAYS BACKUP YOUR PROJECT! There were too many members here that quit game making because they lost their whole project (many months of work) and didn't back it up.

With that out of the way, here are my personal advice:

• Although it's good to learn new stuff and theory, try not to drown yourself in it: just start now creating your game. If you need to learn something along the way then learn it, but don't try to learn everything before starting.
• Plan ahead and make a clear timeline and design for your game. It's not only for your story, but it's also for the technical aspects (for example, compatibility between plugins, or planing ahead for multiple languages, etc.).
• After you estimate the time it takes to finish your project, multiple that time span by 2 (at least). And and another 2-3 months (more or less, depending on the length of your project) for polishing, publishing and marketing.
• Do not have too many complex mechanics that you added just because you think they are cool. They might be cool, but the general rule is simpler is better. But even more important is consistency in your game: if a feature isn't necessary to your game, don't add it. It might be cool to have a super cool crafting system, but it's not necessary in all rpgs (note that it can be good to have depending on the game).

That's all I can think off at the top of my head.

 

[Shaz]

Do not add many plugins just because they are shiny and sparkly. Do as much as you can without plugins first, and then, if you need something that you can't get without them, find one that does just what you want.

Start with the minimum viable product - only those things necessary to get you from the start of your game to the end. When you are done, start adding other stuff, one at a time, and complete each one before you move onto the next. If you get too ambitious and try to put in too many things, it can easily become overwhelming and disheartening. That's where I am right now - too many things added but not finished, and now I wish I hadn't added them at all.

 

[Ragpuppy87]

ALWAYS BACKUP YOUR PROJECT! There were too many members here that quit game making because they lost their whole project (many months of work) and didn't back it up.

Oh yes. I know that all too well. Learned a bitter lesson after losing 8 months of work recently. 2 weeks before it was to be completed no less. Nearly gave up on the whole thing. Probably would have if it weren't for the support I received from these forums and some friends.

 

[Kes]

Know that your first few maps will be dreadful e.g. too big, too empty, poor layout, mapping errors, cluttered with the wrong junk (I remember a game about a Roman Emperor, and to fill in the space in the dining room, there were lots of crates and barrels. In an emperor's dining room???) You will be very proud of them, because these are the first you've created, but while it's right to feel that, it is unlikely that many experienced developers will agree with your assessment. Put them on the Game & Map screenshot thread for feedback and listen carefully to your critics.

Ditch them and start again.

 

[samkfj]

- Have a plan; have a back-up plan because your first plan wont work.
- Read everything, watch everything, learn everything you can. Even if it doesn't seem like it'll help--it can, and it will.
- Ask for help when you need, give help when you can.
- Things that are easily replaced are not as important as those that aren't. In other words--know when to continue and when to use placeholders.
- Take breaks. Work for sure--but take a break when it feels monotonous.
- Save often and back up frequently. Think of it like gathering wood... when you think you have enough... get more.
- Be able to accept criticism. No one is trying to hurt you. I've seen this too often.
- If at first you don't succeed--DIY. Then placehold.
- Test often, every time you add, remove, check--test.
- Start simple. Simplicity is key--you can build from there.

 

[watermark]

There are none.

More accurately, there’s tons but you probably shouldn’t listen to any of it. Why? Because mistakes teach you the fastest.

Say I tell you not to start with a huge project. Or stay away from parallax mapping. Or not try to implement an ABS on your first go. Some of you rookies out there will roll your eyes and smirk with confidence, “Maybe you, but not I.” And I would agree. Go and try it. Only then will you truly know why the Do Not Enter sign was nailed there. Or...maybe you’ll surprise us.

So I say go out there and try things out yourself. Get knocked around a bit and have fun. You’ll learn the most this way.

 

[Ragpuppy87]

Know that your first few maps will be dreadful e.g. too big, too empty, poor layout, mapping errors, cluttered with the wrong junk (I remember a game about a Roman Emperor, and to fill in the space in the dining room, there were lots of crates and barrels. In an emperor's dining room???) You will be very proud of them, because these are the first you've created, but while it's right to feel that, it is unlikely that many experienced developers will agree with your assessment. Put them on the Game & Map screenshot thread for feedback and listen carefully to your critics.

Ditch them and start again.

This one I can appreciate. My dungeons are just randomly generated with some decorations to make them look pretty at the moment. They look decent in my opinion but I know they can be better. Just not sure how to do complex mapping yet.

 

[BlueMage]

Don't drink enough of coke!

 

[Davekron]

A few things I learned the hard-way

• Always focus on the main story and the characters it includes. Side quests and exploration are secondary (important of course, but not as important as the plot)
• Make the map based on the events, not the events based on the map. I mean never create the map first, because you can easily find yourself in a very desperate situation when you figure out something cool, then you realize the map you have spent hours to work on would not serve your purposes and you have to rework it. Just a blank map with grass tiles, do every stories that part has to include, then head to the mapping. You will find it much easier if you know what and where to put.
• This comes from the second part: plan, plan, plan, plan and plan. Design your quests and story, because it will be much easier to implement them. I can give you an example: I usually write down the quest title, then I write a quick walkthrough just for myself, but the way like it was written by someone else. During inventing the whole walkthrough, I become curious and more curious about my own story and finally I can't wait to start working on it within the engine. I even write all my dialogues with all possible outcomes in my mother language, because it will be much easier to translate it back to English later on
• I know Parallax Mapping is not that easy for a beginner and could take much more time to create than a regular one, I'd still encourage you to start studying this method. There are video tutorials which may lend you a hand. Everyone started somewhere
• And finally, start simple, test often and don't let your mistakes take away your mood. They can be solved and they are going to teach you the most

 

[Frogboy]

I'll delve into some more practical and less theoretical suggestions.

Learn the engine first

It's important to learn the core engine with at least a dummy project. Knowing what TRG, EVA and the rest of the ExParams and SpParams do will allow you to avoid making all of your classes feel too samey.

Learning the difference between Autorun and Parallel events is crucial.

I remember getting tripped up on the Through flag. I tried to build a Bridge event over a river doesn't show up until you complete your first quest like in FF1 and assumed that Through meant that the player could walk through the event. Turns out that Through means to ignore the passability of the event and use that of the tile underneath which of course meant that I couldn't walk across the bridge.

Don't decorate your maps until you are fairly sure that you are finished with them.

I don't know how many times I created a nice looking map, spent a bunch of time shift-clicking edges to get it to look the way I wanted to. Put all kinds of crates and bushes in and such, just to later decide that I wanted to change the walls or floor. Because of the way mapping works in RPG Maker, I had to wipe everything out and start over.

Utilize Common Events for anything you repeat often.

Opening treasure chest, opening doors, pushing boulders, initializing maps, storing the player's current location along with a host of other small things will occur many, many times throughout your game. The last thing you want to have to do is locate and update 500 treasure chests because you need to tweak something here.

Use a Plot variable to track story progress

Unless your story is very open-ended and the player can pretty much do whatever they want in whatever order they want, a variable that tracks how far along in the story the player is, is much more efficient and easier to manage than having to constantly check a half a dozen Switches to try to figure out where they are. Also, I'd recommend counting by 10, 50 or 100 so that you can easily insert extra trackable plot points in between the ones that you pre-planned.

And of course, my most controversial opinion
https://forums.rpgmakerweb.com/index.php?threads/auto-dash-is-bad-game-design.78005/

I'll probably think of more.

 

[bgillisp]

-Try to cram too many features into your first game. There's a reason we have a classic saying here that a Titanic list of features is a great way for your game to go the way of the Titanic.

-Starting with a huge game for a first project. I did, and there's a reason I joke my 2nd project is going to be Harold Makes His Bed.

-Trying to mimic whatever the popular system or feature is of the time when you start your project.

-Adding a feature to your game as you feel it is the holy grail of game development, and refusing to consider any other ideas on the feature ever. Any feature, battle system, or even graphics can work well if you USE them well. It's all in how you use them. You can make a great game with nothing but ASCII art if you want to.

-Feeling that adding feature x will automatically make your game great. Hate to break it to you, but nope. A fancy ATB system does not automatically make your game good vs a simple front view system. Graphics does not make your game good just because your graphics are not RTP. Getting a full symphony to play your music will not necessarily make your game any better than if you just used the music that comes with the game. It's all about HOW you use things, not what you use. But many make this error I've noticed.

-Listening to every advice you get on what should go into a game. I have found the most opinionated advice I've heard here and elsewhere comes from devs who have yet to ever finish a single game themselves. If you listen to every piece of advice you get you will end up with a mess that no one likes in the end. Be willing to make a firm decision and just know that you will not please everyone no matter what you do with your game.

 

[empresskiova]

Despite not having released a game yet, I’ve done some stuff that requires conscious design so I’ve got a few tips too...

>Don’t be too hard on yourself.
Whichever hobby it is, whether its making RPG games or creating customs units/battles for skirmish games or writing novels, understand that you’re doing it for fun. Go to work. Take care of your family. Meditate. Sleep. Do whatever you have to do. Your hobby can be jumped on when your ready. And if you go in with a bad mindset, it will reflect in your work. In fact...

>If you go into a project with a bad mindset, it will reflect in your work. You’ll have typos, buggy codes, or lazy graphic designs, and shoddier balance. Even if you only are in a bad mood a couple of times, those couple of times could result in your game having enough bugs to render it unplayable.

>Accept natural imbalances, but still try to balance them as best you can. This is pretty common in games where you can choose your party, whether it’s a job system or 39 different party members. Odds are there will be only a few builds that are the best, and every other one is slightly to significantly worse. You can try to shore up the balance, but somethings just won’t happen. A player probably won’t use two healers in the same party, but they’ll use two warriors if that’s what the game gave em.

I’ll actually use an example here:
I created a homebrew war game not really geniusly called “Alpha Centauri”. It’s a game played on a map of a fictitious planet of the same name, played with standard playing cards and varying american coin denominations primarily.

Now, I pretty much created the initial idea while I was drunk and feeling creative. My being drunk while initially designing the game still affects the game, with some weird but somewhat enjoyable mechanics. One of which was that you couldn’t receive change from the bank when you overpaid. I kept it in mostly for thematic/strategic reasons, but if I had designed the game sober I likely wouldn’t have implemented that.

I’ve been testing the game for years now, trying to get more insight on the balance of the game. One thing I noticed was the relative power spike for Battleship units (in relation to Infantry and Tank units). Now, I won’t re-design the whole combat system, and trying to balance the Battleship is like winning a horserace while riding a pig. So, I’ve come to accept the relative power of the ship. I accepted the natural imbalance.

And finally, most of the time I’m not even thinking about the game. I don’t worry about rushing to my computer to update the rulebook with new balance changes after every game. I think of the game the most when me or my gaming group is in the mood to play it. The game was made in good fun, and I’m pretty proud of the work I’ve done for it (I even drew and colored our copy of the gameboard with crayons!). It’s not perfect, but I’m happy.

 

[Ragpuppy87]

-Starting with a huge game for a first project. I did, and there's a reason I joke my 2nd project is going to be Harold Makes His Bed.

This made me laugh. Not because the advice isn't good, but the joke about the 2nd project's title.

-Listening to every advice you get on what should go into a game. I have found the most opinionated advice I've heard here and elsewhere comes from devs who have yet to ever finish a single game themselves. If you listen to every piece of advice you get you will end up with a mess that no one likes in the end. Be willing to make a firm decision and just know that you will not please everyone no matter what you do with your game.

This advice I really appreciate. I know it will apply to me once my project is ready for playtesting. I tend to try and please everyone and then end up with something that isn't even my own anymore.

 

[TheoAllen]

A lot of aspects already mentioned, so I'd mention my own personal experience in the past which I don't think it might apply to everyone.

Talk about idea and design as if I knew everything but actually didn't do research or had experience at all.
Prior the time I actually make (and complete) a game, I used to talk a lot about design, or even bashing some RM games as If I knew how they should do it. I made scripts and it made looked like a veteran RM user. But in fact, I had no proof at all if I had a complete game.

Later time, I decided to actually make a game, a small one, I pursue the game completion other than anything. What did I learn? some of my scripts were never suitable for actual game dev. It can be because of inefficient performance in a bigger project, harder to manage, or some of my scripts features just flawed for a certain design. Just because it looks cool, doesn't mean it works as a mechanic. I learned how painful is to manage the switches and variables, how painful is to event, how troublesome is to balance out the enemy from stage 1 to the last stage, bug tracking, and many things. Also, I should have done this long time ago rather than dreaming with my larger project that is stuck because it's too large.

Nowadays, I respect people who actually do their project and released it. Even if it's not good. At least they get their hands dirty and has proof. Everyone could throw a critique, but not everyone could throw a critique as well as how to fix it.

 

[M.I.A.]

i think the biggest rookie mistake is not asking yourself to EDIT. Edit everything. And by edit, I mean REALLY put things in your game under the microscope. Ask yourself "to which purpose does this serve?" and "is it necessary for my game?".

When mapping.. databasing.. skill design.. everything. Just ask yourself "to which purpose does this serve?" and if there isn't an answer that gives that thing usefulness, then edit it out.

Hope this helps!
-MIA

 

[VitaliaDi]

Not having a backup for your game. I lost my first game that was almost completely finished because I didn't have a backup. (I still don't always have backups )

Other things I've seen or done are poor mapping, either too empty or too busy (still learning this one its totally a skill on its own), not getting beta testing feedback and releasing a game with a ton of bugs, not being prepared for all types of feedback (negative, positive, or even none at all).

Everyone should check for plot holes, bugs, and get some outside opinions before they officially release a game

 

[Ragpuppy87]

Not having a backup for your game. I lost my first game that was almost completely finished because I didn't have a backup. (I still don't always have backups )

I also lost a game that was nearly finished due to not having a backup. In fact it nearly happened again today. This time all that saved me was a backup.

 

[Hermoni]

I've learned to not rush to show a demo of anything before it's really all ok.

Some years ago, I rushed cause somebody asked me if I wanted to show my project to a rm contest. I wasnt ready for that and I regret a lot.
50% of the playable project was really too bad and I gave up this project during loooong long time.

So I'll never rush anymore. I'll take my time even if that will take years and years^^

 

[HexMozart88]

Not much that I can add that hasn't been said already, but here are some thoughts:
- Going for what's popular instead of what you like: Even though you think it'll get you more money to release whatever's trendy at the time, it actually may have less of a chance than if you went with your own idea. Because, passion is what makes a great deal of the project. If you don't like the type of game you're attempting to make, you don't know what makes the genre good, because well, it's not good to you. Make the game you want to make and appeal to those who enjoy that.
- Fancy over practical: Think about it this way. You can't add lace curtains and silk bedspreads to your house until you've built the house itself. Likewise with game dev. If your game needs scripting, turn first to Yanfly's message system and then worry about Moghunter's Oppai later. That doesn't just apply to scripting. Don't add your elegant parallax maps and custom character sprites until you know exactly what you want.
- Being non-curious: Even Einstein asked questions. Search things up, make posts on here, watch tutorials, you're no worse of a game dev for it.

Use a Plot variable to track story progress

Unless your story is very open-ended and the player can pretty much do whatever they want in whatever order they want, a variable that tracks how far along in the story the player is, is much more efficient and easier to manage than having to constantly check a half a dozen Switches to try to figure out where they are. Also, I'd recommend counting by 10, 50 or 100 so that you can easily insert extra trackable plot points in between the ones that you pre-planned.

Huh. Not even a beginner and I've managed to learn something from this thread. Pretty clever, actually.

Utilize Common Events for anything you repeat often.

Opening treasure chest, opening doors, pushing boulders, initializing maps, storing the player's current location along with a host of other small things will occur many, many times throughout your game. The last thing you want to have to do is locate and update 500 treasure chests because you need to tweak something here.

Common events are honestly my best friends. Most of my GUI relies on them.