Are there any good CRPGs made with RPG Maker?

That's your problem, right there.
Failure is a natural part of life and how we deal with it (hint: by learning from it is the correct way) determines how much we grow. Might not even be your fault, it's kind of an ancient cultural tradition to see failure as something terrible to be avoided at all cost instead of getting over the frustration part asap and see the learning opportunity.
This might of course be true when you are developing things that truly must not fail (say, medical devices) - but we're talking about the acquisition of knowledge here, learning.
That is the time to make mistakes, as many of them as possible, so that you won't make them later on when it truly matters.

If you experience repeated failures in the same area, there are two possibilities:
1) You have made the only truly bad mistake: not learning from your previous mistakes.
2) You were just really bad at something - that's fine, everyone has talents and things they suck at (I suck at maths, which is somewhat weird for a coder, I'm basically out as soon as it gets more complex than vector * matrix) -, in which case the failures also taught you something valuable: this isn't for me.

Once you have some good experience, sure.
I do it like that. With my 12+ years doing development by now.

But a beginner at X cannot do that, at all. A beginner has only their motivation to go on, and motivation is wrecked by working on something you don't find interesting in any way.

This must never, absolutely never, be the goal when you are learning something. You are doing it to learn, not to produce the best end result.
You cannot produce the best end result anyway due to your lack of experience, so trying to do it only hampers how much you can learn.

 

Nope, that's basic brain chemistry. You succeed, you get dopamine. You fail, you get cortisol.
There are studies that I'm too lazy to find links to that show that assessment that emphasizes students' successes is ultimately more efficient in facilitating their learning than one that zooms in on mistakes.

And that is supposed to be more exciting and motivating than painting by the numbers? Pfft.

There's a galaxy-wide grey area between doing something uninteresting and pursuing every single idea and ambition you have. And both these extremes are only a sure way to burn out. It makes a lot more sense to focus on one or two ideas you find interesting and strip everything else down to default features.

 

Meh, that'd be implying that you learn to code by writing pieces of code which go nowhere, which is wrong, you only learn that you actually can do something that you can obviously do, better said you learn nothing. Ok, I'm exaggerating but it's only one third of the dev process, another third of the dev process is to put together something usable, and based on the state of some released games it seems that even some big teams actually learn that the hard way, and another third starts when you have a "finished product", catching the last bugs, polishing UI and content, and thinking of you next project, based on users' feedback and you learn as much about what's right or wrong with your code during these two last parts as during the first one. Also since I've made my first "Guess the number" code on a calculator I get some extra motivation to keep on coding when people enjoy it which is only natural while stuff which goes nowhere just makes me stop and spend my free time on something else.

 

Nobody is suggesting zooming in on mistakes. That would be absurd.
It is about encouraging people to try out new things on their own, especially if they are beyond their current skill set. To go out of their comfort zone and seek larger challenges. And because they do it on their own and not as directly instructed or by-the-numbers, they will make many mistakes and learn from them. It is the best and most efficient way to learn. There's even a name for it, which I naturally forgot...

Those who only aim low, will only receive low results. It really is as simple as that.

And sorry, but studies in that area are almost always tainted by the result they want to achieve from the get-go, or by whoever gives the money. The last thing any educated person should do is blindly trust any "study".
Almost no study, especially studies of the mind and psychology, actually has a large enough number of participants to really say something of actual substance. And then they rely on people actually being truthful when questioned, etc.
Trusting studies in cases like this is like believing in a horoscope.

Doing a project you actually find exciting is more motivating than doing some by-the-numbers project to stay "safe".
I assume you have never worked with game dev students if you find that questionable in any way.

That isn't much different from what I wrote.
When you do that, you already don't do any boring painting-by-numbers project but follow whatever you find interesting.

The only difference is I say to aim high for as many aspects as you can. When you learn, the end result simply doesn't matter.
Except when you learn for the producer role - which is why I always advocate to separate those from the rest of the developers at least the first year or so.

These student groups hamper each other's learning potential enormously due to the entirely opposite goals. Producers need to learn to keep things realistic, doable, plannable, etc.
The rest of the team needs to pursue what skillset they want to improve by doing it with as little constraint as possible.
Whatever teams decide on will be to the detriment of either producer or the rest - kind of sucks, honestly. And it does lead to the situation as you described. A few exciting things are left, if any, the rest lands on the chopping block, motivation tanks.

I've read this multiple times now and I really don't know what point you are trying to make.

Nobody codes pieces of code that go nowhere. You work on a project with the goal to complete it - but also with the knowledge that it is okay to fail. What you learn coding is more important than finishing the project itself. Because nothing depends on the finished project, but everything depends on what you learn while doing it. The project is not the goal, it is the means to achieve the goal: learning something.
"you only learn that you actually can do something that you can obviously do" - this doesn't make sense. Before doing it for the first time, you didn't even have the knowledge. It's called learning and its results do not invalidate the process.
If you played it safe, doing only things you already know with little to no challenge, that is when you learn nothing.

The rest you wrote is mostly about the producer & management role, which isn't wrong, but for our purpose here, learning RPG Maker, it is entirely irrelevant.

Damn it, we really need a WYSIWYG editor here, I always fuck up the quoting and have to edit the post a dozen times

 

And that's where I disagree. Getting overambitious is a sure way to crash and burn, and lose your motivation to continue in the area.

How are you supposed to get excited about doing something and not care about the end result? It's an oxymoron.

 

You can do something interesting within the constraints of a toolset.

One thing that's also important in game dev is to know what you can do. If you start out with a program like RPG Maker with known limitations, you can structure your project around those limitations and do something interesting with them. Finish that project, then progress to something that tries to break the limitations.

Many excellent games were made in the DOS era when computers were weak and in the early days, you even had to limit the amount of text you could put in your game in order to save space.

If devs back then had tried to make, I dunno, something like Skyrim, they would have given up 5 minutes in when they realized it wasn't possible.

 

One of the best games I've ever played is a german-only RPG-Maker-game: "Die Sternenkindsaga". It feels like a mix between the virtues of Ultima, Gothic and the old The Dark Eye games. So many possibilities to solve problems with different skills, interesting quests, good world design, gripping story, fantastic exploration... Dialogues can seem a bit childish at times but overall it's a true masterpiece, much more wrpg than jrpg.

https://sternenkindsaga-download.rpg-atelier.net/

Other masterpieces are the works by realTroll. German-only again. These are among the most sophisticated games I know, great experimentation with the possibilities of the Maker, very playful and funny. Especially the Allreise is a timeless masterpiece, but El Dorado 2, Wolfenhain and Endzeit are brillant too. One of the most creative and productive RPG-Maker creators I know and a damn fine guy.

https://realtroll.hpage.com/

 

I am moderately happy with Wannika 1 and 2 as well as the greater ambition in 2.

Additionally, the internet is absolutely full of abandoned indie projects that tried to do too much. I chose my approach from observing them. Doesn't really matter to me how much they personally learned as devs, their games don't exist, nor will they ever.

I'd also say doing something feasible doesn't mean doing something boring.

 

I don't know what you want to say here.
Devs back then created games that simply offer way more than Skyrim. See Daggerfall. In all but graphics (and arguably controls) the game just has more to it than Skyrim.

If you are talking about graphics, well, duh - the hardware back then was the limit. If the software was, we would've had a Skyrim in 1995.
There is a difference between aiming high and attempting something physically impossible

I never said you don't care about the end result, just that it doesn't matter.
Of course people care about their projects, even if it is unrealistic. And of course they will try to get it finished. I don't think I've ever seen any other thing happening, or seen any project ideas (talking about student projects spanning maybe half a year or so) that were so ridiculously unrealistic that even pros couldn't have done it.
All of that happens pretty much automatically because generally people aren't complete morons.

The point is that they might fail - but if project was achieved or not in the end (or to what degree) is irrelevant. What matters, if the goal is to learn, is only what they learned while doing it.
And due to that, more lofty projects are better for learning as they offer people more and higher challenges, quite simply forcing them to learn more in the same time than a safe project would have.

Also, due to all of that, a learning project should be chosen not based on how realistic it is, but based on what it will teach you.

The internet is full of abandoned projects, period.
When something is a hobby and free time is spent on it, people may just lose interest no matter what. There are so many reasons for this.
Of course, a tiny project has a greater chance of being finished, simply because there is less time to lose interest, so if your primary goal is to finish something, no matter what or how small, then that's the way to go.
But if your primary goal is to learn something as efficiently as possible, that's a terrible way to go about it.

I have a whole bunch of unfinished projects myself, and each one has a different reason why I didn't finish it. Scope was never one of them.

 

Daggerfall was released in 96 (or 95?), I'm talking more about the 80s when games like Pool of Radiance had to put much of their journal text into the printed manual to save hard disk space.

My basic gist is: learn to work within the limitations of whatever tools you're working with first, then attempt to go past those limitations once you know what you're doing.

You don't have to throw all ambition out of the window and do a cookie cutter standard project, but you should be aware of what can be done realistically before diving in.

While it's possible to use a dozen different plugins in RPG Maker and create a Fallout clone, it's better to work with the engine's core features for your first project and try to do something interesting with that. Maybe the limitations will even give you some ideas you would never have had if you had limitless possibilities at your disposal.

 

Yes, you did:

But the goal isn't to learn. We're not at school anymore - although learning for the sake of learning doesn't work even at school, there needs to be a point in doing it.
The goal is to make a game. Full stop. Learning is just a necessary, but not the most pleasant part of getting there. And it makes sense to set up your project in such a way that you actually have to learn as little as possible.

 

Friendly reminder that all the Codexians who released their own games made concessions to practicability, and upped the vision on the second game.

VD has explained that many of Age of Decadence's controversial elements (like the over-reliance on CYOA sequences) was partially due to budget constraints and cost/benefit calculations. Iron Tower learned from the experience, switched engines for the next game and promised to fix some of the problems.
J_C has made an RPG Maker adventure game, his second game was a simple SHMUP. He took those game maker programs and created decent games within the inherent limitations of the programs rather than trying to break through the limits.
Agesilaus made Theseus: Journey to Athens with Game Maker Studio, which is a rather simple game mechanically, but still unique in its gameplay. The next game he has planned is going to have higher production values.
MF made Titan Outpost, which features unique gameplay different to other RPGs, but it's not overly complex in its mechanics (and still has some bugs). It tries something new with the genre but isn't overly ambitious in its mechanics.

All of the Codexian-made games recognize limitations and have limited scopes appropriate for a small one-man project (AoD being the exception here for not being a one-man project).

Understanding the limitations of your tools and staying within them is part of game development, especially for a one-man indie gig.

 

The best times were the RPG Maker 2k era. Or at least the ones people have the most nostalgia for. The decline started with RPG Maker XP, even though it and its successors made "programming" easier by adopting first Ruby, then JS.

 

I think it is possible - eminently preferable, even - to aim high and learn things while simultaneously pruning down your scope, though. The point isn't to make something that's by-the-book and boring, but rather, to figure out something that is both interesting and achievable. It's also a creative enterprise in itself. Pruning your ideas down is important because it helps you discover what it is that you find most interesting and valuable about your project.

I don't want to sound too demeaning, but ofen the initial concepts that people have for games revolve around some vague high-concept idea or far-flung mechanical concept they're fixated upon that ultimately isn't particularly relevant to the moment-to-moment gameplay. "Oh, I want to make a game where you play a sentient sword that possesses its wielders and if you die you become the guy who killed you!" "Hey, I'm making this game where you use magic to enter people's heads like dungeons and what you do there alters reality!" Alright, that's neat, but how does the game work? What is it that I, the player, am doing, minute to minute? How is that impacted by the fact that I am a sentient ghost sword or fantasy Inception wizard or whatever?

My personal experience is that the big initial hurdle in making a game is making the game genuinely fun for around five to fifteen minutes. It is my impression that a lot of people who just play games don't quite grasp this, because most people can't be bothered to play a game that doesn't pass this bar, so they have only a vague sense of all the things that need to work for a game to, well, work. There's more to be learned there than in entertaining pie-in-the-sky ideas - five minutes is a long time and the player is going to experience a lot of the game's basic premise and mechanics in that time. If the game isn't fun to play for a quarter-hour, it's not going to be fun for an hour or thirty hours either.

 

The goal, at least as far as this discussion started, is absolutely to learn. That's what I've been talking about from the very beginning.
If you are talking about different goals, okay, but that just means we are talking about different things.

Of course you'd learn RPG Maker to eventually make a game with it that is more than a 1-2 hour romp. I assume, anyway - why else would you want to learn that?

But for the sake of learning to do something, loftier goals are way more helpful than doing a lot of easy goals first. Both will eventually lead to the same knowledge, but the first one is way faster.
If the first project ends up really good, that's great, but if it doesn't you won't even have to release it.
And you will be better prepared for the bigger project that follows, your "long term goal" if you will.

And that is exactly why there are so many incapable developers and badly made games.
They just want to make games, but not learn the craft to do so. Taking shortcut after shortcut after shortcut when it comes to knowledge, just to get a job done in the most haphazard way possible.

Whatever your profession, I do hope you apply a bit more curiosity to it. If it's not just something you do for money, that is.

 

That is indeed one of the most important aspects. And only possible if you aim high to begin with.

 

The original post that started everything:

Does it say anything about wanting to learn? No. It says "I've always fancied making an RPG". And it's never "I want to learn to make an RPG" because what's the point of learning if you can't put it to use?
It's just the "you learn from failure so you should aim for failing" bullshit that got me triggered. Because in reality, you learn from successes a lot more. If he aims for something realistic (which it won't be anyway, because everyone always overestimates their abilities) and makes a modest game, he'll learn the most important thing - that he can make a game. No amount of failure can teach him that. Then his next one will be more ambitious, and the next one even more so. He'll ultimately learn the same things, and more, than he would have in an overambitious failed project, but he'll also have three completed games under his belt.

I was talking about hobbyists and beginners, that might have needed clarifying. But the point still stands even concerning the most commercially successful indies - these are games that focus on one or two things and do them brilliantly, compared to AAs and AAAs, which try to do everything at once, and do it badly.

Let me blow your mind a little bit: I work in academia. In humanities, so my profession is literally producing knowledge for the sake of knowledge, with rather little practical implications. And still I've seen way many papers, both from students and more senior academics, that are made absolutely incomprehensible by cramming every notion and reference they could think of in there. So no, even in knowledge production, focus is the key.

 

Captain Obvious. Note that it also facilitates authority-status.

 

I mean, at least you are honest about the practical use
That gets a brofist from me.

Yes. After how much cutting of planned features? Do you honestly think they would have arrived at the same point if they started planning only that, without learning from their higher goals which ones they really needed/wanted to focus on?

Exactly.
And the focus in making a game should first be "learn how to make a game", before you actually tackle any real-world projects.

But let me tell you a story about aiming high vs aiming low:
When I started learning programming at a game dev school, my first project (out of five) was absurdly ambitious for my level of knowledge. It was to be done in C++ (I had no prior knowledge of C++ beyond reading about it), in 3D (always more complex than 2D), in an engine that featured only graphics (sound, input and UI had to be done extra). Oh, and there was video playback, too! I was the only programmer in the team, and with sweet 19 the youngest one as well.
The game would've been realistic in scope for a same-sized team of professionals. And I was told as much by the tutors, who also encouraged me to do it precisely because of that. The gist being "You won't be able to pull it off, but you'll come out a much more skilled person".
In that half year, I had to learn C++, 3D math at least enough for the project, using sound libraries, input libraries, UI libraries and also how to cobble together a game while doing so. Help from tutors was rare, because tutors were rare (it was very early game school days, most tutors were there as a side job...). All of that next to the normal courses, tests, etc.
80% of that project time was filled with failure and me doing stuff all wrong until I finally got it "right" (well, somewhat working, anyway...). The cursing going on was glorious.
Let me tell you, that project saw me (and others from the team, as it wasn't easy on them, either) pulling quite a bunch of all-nighters. And I liked doing it, because the idea was actually pretty cool and because I learned so much. We all chose it because we knew we would learn a ton.
Everyone in that team, after the "vocational school" (it wasn't quite that but it's hard to translate what it was...) went on to find well-paid jobs, gained ranks and can generally be seen as successful enough, I'd say.
Another one - not in our team, but working with the same mindset - even became dean of engineering at another game dev school.

Why? Because we aimed high, failed often, had lots of fun and learned a ton from it. The project itself? Barely playable in the end, but we were proud even of the little bit that did end up working.
I lost the source code of that project, btw, and I will eternally curse myself for that.

Now, there was another team.
One of them a coder who knew Java.
What did they make? A 2D tetris-clone.... With only one person less than we had. In Java, naturally, because why would you not play it safe, right?
They finished that project. A nicely polished and pretty standard tetris clone.

And where did they all end up?
One probably drank himself to death by now, the other one quit the industry entirely after the school, yet another one is still (10 years later) doing QA jobs, and not in a leading position, and the final one quit after that half year - citing "I learned nothing here" as the reason. We had a good laugh about that last one

They all aimed low, succeeded in their low goals, but failed in their actual objective of learning the craft to begin with and ended up not being all too successful afterwards (being diplomatic).
I fail to see how anything in this story leaves any conclusion other than: Aiming low won't get you anywhere, aiming high and learning through failure will.

I learned a lot from the "success" of that other team, so I guess you are right in a way, after all.

Maybe, really just maybe, if you only want to do something for a few hours a week as a small hobby without much focus, just to relax or sth. like that (like others do gaming), aiming low is a better idea.
But in all other cases, aiming low will just manage to waste a lot of your time.

 

sheep, have you considered that generalizing from your own approach of creative working isn't working for others. people are different and especially when it comes to creative endeavors what works for one doesn't have to work for others. some may be better served with your aim high and learn fast approach, others with a small and manageable scope first

 

Both approaches get you the knowledge in the end, that's for sure.
But one does it faster and that is quite simply a fact. Which makes it the better approach.

 

Not if it doesn't work for the person and he gives up altogether

 

If someone is that low on discipline or skill, and that discouraged by failure, they are in the wrong field anyway and should do something else.

 

I c you rather pass moral judgment than encourage creativity

 

Absolutely.
You can encourage creativity in children and teenagers if you want.
In fact, please do, it could be important.

When it comes to adults, I have little patience and understanding for people with a weak mind and a lack of discipline.