Nina Aquila: Legal Eagle, Chapter II: "Broken Wings"
Structuring a larger game project in RPG Maker - Part 1, “Understanding the Problem”
Today we’re going to look at something that I hope will be useful for you guys who are just emerging from doing tutorials to starting to plan your "full games". This approach could also apply to most narrative-based indie games, like visual novels or pretty much anything else.
Years ago, when I made my first ever game in BASIC, back in the late 80s, I ran into a problem:
I was up to the ~tenth location in my indie adventure game, and in truth, it was starting to become a mess. I had tons of switches, variables and such that save character presence and positions, as well as the things with which the player had interacted, and it was very difficult to remember what-controlled-what.
What’s worse is that to test some parts of my game, I had to either use the save/load system (which was not be reliable with all the changes I was making) or I had to play my game each time from the start... Which became a problem once my game was over 20 minutes’ long.
I ended up just trying to “wing it”; I didn't test, my game got worse, and before I knew it, I had something which was less like a clean project, and more like this:
Has that ever happened to you? If so, then hopefully what I’m going to say in these articles will be of some help to you.
One of the things you notice, when you’ve been in the RPG Maker or indie development communities for a while, is how game creation tends to involve a series of gateways. The first one is simply getting something, anything, onscreen - a short step for RPG Maker, Unity or other engines, a longer step if you’re learning how to program from scratch. Still, most dedicated people reach this point.
After this, most people look at tutorials, and they manage to make some simple, 1-room or 1-screen games, and build from there. However, the next gate comes when you want to go from those simpler games to something more elaborate, with a large number of locations and events - and speaking personally, I started to falter at this stage. I knew the tools, but didn't understand how to apply them to a larger-scale project.
Perhaps you’ve struggled with this yourself. In RPG terms it’s a pretty tricky early boss to slay.
This “gateway” is the barrier between a simple project and a more complex one, and can be a bit of a dark art.
I'm going to show you guys how I learned to get over this problem, I’m relatively new to RPG Maker, but principles I’m going to describe are quite universal and could be used to structure narrative experiences for most games.
When this comes up in development circles, often people say “you just need to plan your work in advance”, which is fine - but planning is only helpful if you know what you’re doing. Put simply, you don’t need to plan more; you need to plan better.
So taking the paragraph above, I'm going to break down the problems I faced, and will explain how I got over each.
- It’s difficult to test a longer game. I needed to create a system which was easy to test; this is because a working, robust game is always preferable to a buggy one. Ultimately I just needed to make this easier for myself.
- Problems in parts of my game broke other parts. These are called “dependencies”, and I needed to remove them. Ideally, as much of your game needs to be independent from the rest as possible.
- Losing track of what switches/variables affect what else. Sometimes this is just about having good names, but also, it’s about having more elements depend on fewer variables, in a better-planned manner (this will be expanded on later).
In this series of guides, I’m going to talk about the ways I went about fixing this, and if you've had these problems, hopefully they can help you. This isn’t a guide for programmers as such, but I will touch on some programming concepts that I’ll hopefully explain well-enough for newcomers to game development - but let me know in the comments if you struggle to understand anything.
So, we’re gonna start next week with a brief explanation of a vital software development concept which is useful in-games - the state-machine.
Going to try and make these weekly updates, so follow me if you want to be first to read them!
Comments
Log in with itch.io to leave a comment.
1) rpg maker has many ways to fix the "test a longer game" like fighting boss with items and stats for that boss. You can teleport your player with the given stuff to make sure things run, etc. This isn't a problem with testing longer game it is a problem of not using rpg maker tools to test things.
2) Nothing gets broken unless you mix plugins with plugins that do the same things or bad programing within plugin. RPG maker is made to run in almost anywhere. The only known errors that might ruin your game from RPG Maker series are new updates that might break your game.
3) This is a common problem but not something people do a lot in rpg maker.
All this just seems to be your problem reather than everyone problem. New people could face these problems but even they try to keep a game neat. I never heard people complain about rpg makers having bad programing or errors it's just people complain about rpg maker being easy for people to make games.
Thanks for the detailed reply, Firecat!
I totally acknowledge your point; in that none of these problems are weaknesses of RPG Maker, and that the engine has the tools and capabilities for all this stuff. Naturally though, a new user may not be aware of those techniques (though they're quite simple once you know them).
In terms of teleporting the player around the game, that's actually what I had planned to talk about next week, with a high-level state-machine that guides the player through the narrative, and gives the developer the ability to teleport to any point within the game with the prerequisite variables, switches and items activated.
In terms of your points 2 and 3, please accept my apologies; I think my language was unclear. I can see how I may have suggested these things were programming issues; what I meant to express was dealing with the complexity that arises when you go from a small, short, simple experience to starting to work with many locations, events and other things. RPG Maker's actually a pretty robust piece of software; I hadn't intended to suggest it was a problem with the program itself - but more a beginner user might start to struggle to keep track of things, and I plan to talk about some ways to deal with that.
You're right in that this is very much a "me" problem in RPG Maker, because part of these articles is about explaining that I've encountered these problems and how I dealt with them. That being said, I've seen a similar problem come up with others who are working in different engines, so I assumed it to be quite universal. Evidently that was in error, but still, hopefully the follow-up articles will be useful to absolute beginners.
I'll take on-board your feedback, and try to be clearer in the future about where my examples come from, and about being very clear about how these problems arise from the user's own issues rather than the software itself.
Judging from your profile, you're pretty expert on matters RPG Maker, so any feedback you have would be incredibly useful!
You're right about combat testing, but there are some limitations with the basic RPGMaker (I'm on MV) combat editor - for one, it's not immediately obvious how to test a battle where an actor enters with a status effect!
I think he was talking about poor-planning behaviors like using variables without giving them names and then accidentally using them to track a second thing, or making a section of a game dependent on a resource location the player would already have exhausted long ago in a full playthrough.
There are countless ways to softlock - and even hardlock! - your players without crashing the game. For example: start making a common event that switches on when a certain switch is flicked, and then change what that boolean does later, forgetting it was used for a common event... and you've made a complete monster. I bet with sufficiently bad logic, you could even get a normal event object to crash the game. It's par for the course with anything programming related; there are *always* bizarre edge cases that let the player do something unanticipated.
Listened to this, until you said "20 mins" project as already a long project. Well, honestly I'm not sure about that.
Maybe you'd be better to define what is a "long project". A playtime imo doesn't qualify it as a long project. You could have 10 mins intro scene including tutorial or whatnot, then 10 mins of dungeon crawling with some battles and it still feels a short project. You can have one hour game but it's basically just a linear game where you just walk straight into the linear part and it still feels like a short project.
Or maybe, you want to change the term from "longer project" into "complex project". Because I don't think "longer project" will suffer from management difficulty like switches/variables management. Because you can just use next switches/variables and it will still fine because you may not want to touch the previous switches since your game is linear. But for the complex one, it may be because you may want to keep coming back to the same map and things get too complex because of the switches/variables interactions.
I understand what you're saying; my choice of words on this could've been better.
I can see why you're suggesting I change it to "complex" games, because "longer" is too nebulous a term.
Can I ask what you'd suggest? What I'm getting at isn't so much games that are much more complicated (i.e. expansive open-world games, or nonlinear story games) but rather trying to guide people who are just going from their first, probably-simple game (where they're mainly focusing on grasping use of the tools) to starting out on their first "full" game, now they feel a bit more confident. It's about helping them plan this.
Given that, how do you feel I should change my title? Is "complex" still the right word, in your opinion?
I'd say "Larger" would be even better because "complex" will have a different meaning, like when you decide to create a harvest moon clone. But larger is definitely not a small game and may contains either or both complex and longer gameplay.
Yeah "Structuring a larger game project" sounds more convincing imo.