• Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS
Click here for documentation (Includes material formats)

RPG 20XX is a redesign of RPG Maker 20XX... Which was an upgrade replacement for RPG Maker 2003's engine. This newer engine will have nothing to do with the RPG Maker series of engines apart from the familiarity of the editor and engine features.

RPG 20XX should provide lots of advanced features yet remain faithful to the retro scale of RPG Maker 2003. It should not require actual writing of program scripts and instead provide a clever implementation of a click-together event scripting system similar to the older RPG Maker engines. Most notably the ability to re-adjust the battle calculations purely through event scripting.

Lots of common tedium and annoyances of RPG Maker 2003 should be eliminated. RPG 20XX will provide global battle events for all battles, a quest system, simplified character development, local save variables per event, and other simple conveniences.

All of this is currently licensed under the MIT license so you can check out the source code any time if you really wanted to. It will be a community project, free as in price and in freedom to create the RPGs in a fun familiar way like you always wished RPG Maker 2003 could do these days.

If you use this software, you agree to use the software under the MIT license: https://opensource.org/licenses/MIT
Copyright © 2014, 2021 WolfCoder Workshop LLC


Latest Blog

RPG 20XX Asset Starter Pack

First things first, I'll need to gather stock assets to create RPG 20XX's default asset pack. It's like an RTP except "Run Time Package (RTP)" doesn't make sense here since all required assets get built into .2xg files and players of your game won't have to go download it separately. I'm organizing what I had found before with what I can find off stock asset sites, but I think maybe the RPG creation kit that was born on RMN ought to have assets from the community.

If you have assets you're willing to contribute that have lots of "Generic RPG Energy", let me know. You'll need to license them under a creative commons license so we can all use them. Don't worry about formatting, I'll convert them, just make sure they're drawn to 16x16 pixel tile scale.

The resulting asset pack will have all of the sources cited even when attribution isn't a requirement, so be sure to let me know how you want to be credited and if there's links to something you want to include.

Anything simple and easy to map with but with an appealing retro generic RPG look is great. Here's an example I made using art I found elsewhere:

Posts

A built-in run key would be sick too (where you can choose which speed is walk/run).
author=NewBlack
...The same goes for volume control on sound effects/music...

Actually volume controls and musical things are linear, don't know what you're talking about.

Anyway, it sounds simple but I would have to adjust the new default speed carefully. I'll think about this when I finish with the engine first.
dragonheartman
Developer, Starless Umbra / Heroes of Umbra
2966
author=PepsiOtaku
A built-in run key would be sick too (where you can choose which speed is walk/run).
Maybe this is the RM2k3 in me, but you can already do that though. (With more control, too.)

I'd kinda rather see it emulate the existing RPG_RT.exe first before all these features are added that bring compatibility issues to existing games (even thought WolfCoder has expressed it is better to test the engine with a new project specifically made for RPG Maker 20xx). In other words I'd just be happy for it to do the exact same thing the current RPG_RT does (minus enterbrain's bugs of course). In the end I'm excited for whatever direction this engine takes. *shrug*
Yes, that's why I can't be too crazy with what I decide to make anew with the engine. Especially since I played Starless Umbra and it had running and walking in it.

(even thought WolfCoder has expressed it is better to test the engine with a new project specifically made for RPG Maker 20xx)

Actually I mean it's easier to make a new game with 20XX since even if the engine was whacky, the game would take everything into account vs. something that assumes 2003.
Writing a run key using parallel processes isn't hard (I did so in my own game), but you run into passability issues with on-touch events. You can essentially hit the run key while you touch the event to instantly cancel out the event's actions. Players can easily exploit this. Even if you added a switch to that event to turn the key off, it wouldn't matter because it can be exploited before the event reads any of its actions.

Maybe just fix the way touch events and parallel processes are handled to correct this?
It sounds nice, but like I said I want to make the engine first. Let me put it this way: you won't mind not having a built-in running system if the battle system actually worked and the agility wasn't messed up. I'll come back to this though if more people want this after I finish the engine.
author=WolfCoder
It sounds nice, but like I said I want to make the engine first. Let me put it this way: you won't mind not having a built-in running system if the battle system actually worked and the agility wasn't messed up. I'll come back to this though if more people want this after I finish the engine.


What does having a dash system built into the engine and the battle system working properly have to do with one another?

Two totally separate features, and the way dash currently works (or doesn't), isn't acceptable.
What does having a dash system built into the engine and the battle system working properly have to do with one another?


They don't.

Two totally separate features, and the way dash currently works (or doesn't), isn't acceptable.


My entire project probably wouldn't have existed if it weren't for the horribly bugged battle system and agility. I'm talking about priorities here. I think you would like to have a menu system... at all first before you can dash. I think saving games and loading them is also more important, etc.
author=WolfCoder
What does having a dash system built into the engine and the battle system working properly have to do with one another?
They don't.

Two totally separate features, and the way dash currently works (or doesn't), isn't acceptable.


My entire project probably wouldn't have existed if it weren't for the horribly bugged battle system and agility. I'm talking about priorities here. I think you would like to have a menu system... at all first before you can dash. I think saving games and loading them is also more important, etc.



Oooh, okay, gotcha.

You are correct! Core features are certainly more important than dashing.

In addition to that, I feel I may have been giving off a negative vibe when really I love the work you're doing here and think it's going to be massively useful to a large amount of us. So for that, <3
Don't worry. It's good that you, a seemingly random person, spoke up about this. The more people who feel strongly enough about a particular feature to bug me about it, the more important it appears to me. There's lots of things I've got piled up for after the initial engine

After all, I actually don't really need this thing- it was a project for everyone else to begin with so I'm not that closed about it.

Of course there are lots of extra features that have already been implemented and/or will be implemented with the first engine. Like drawing a number! No more wasting six pictures and copy pasting modulus functions.
author=WolfCoder
Don't worry. It's good that you, a seemingly random person, spoke up about this. The more people who feel strongly enough about a particular feature to bug me about it, the more important it appears to me. There's lots of things I've got piled up for after the initial engine

After all, I actually don't really need this thing- it was a project for everyone else to begin with so I'm not that closed about it.

Of course there are lots of extra features that have already been implemented and/or will be implemented with the first engine. Like drawing a number! No more wasting six pictures and copy pasting modulus functions.


That's seriously what I'm most looking forward to. I really really hate going through all the pictures/events/etc to get numbers to display.
Not sure if this is one for you or cherry or someone working on the engine, but how about some way apart from using complicated MP differentials to determine what skill has just been used?

As it stands I have to use pain in the ass common events and a bunch of variables to decipher which skill has just been used, and doing this for a bunch is a pain.

Maybe just a simple (character) uses (skill x):

Also, the default walking speed seems to fast, but the next setting down is too slow. Is there maybe a happy medium here? Does anyone else even care about this?
As it stands I have to use pain in the ass common events and a bunch of variables to decipher which skill has just been used, and doing this for a bunch is a pain.

Maybe just a simple (character) uses (skill x):


I'll consider this one, but it's never been a problem for me.

Also, the default walking speed seems to fast, but the next setting down is too slow. Is there maybe a happy medium here? Does anyone else even care about this?


If you look above you can see there are many who think the same.
Versalia
must be all that rtp in your diet
1405
I know this isn't fully polished but, I tested it out, and it disables the 'okay' button (enter, spacebar, etc) and doesn't seem to reassign it anywhere else. Also, all of my "on collision" events stopped working...

/* Main keys */
case WCINPUT_OK:
if(wcinput_keys[SDLK_z])
return 1;
if(wcinput_keys[SDLK_RETURN])
return 1;
if(wcinput_keys[SDLK_SPACE])
return 1;
return 0;


Don't know what's wrong with the OK key. However, I think the collisions were added. Can you reproduce this in a small RTP game to isolate this problem and send it to me?
Versalia
must be all that rtp in your diet
1405
author=WolfCoder
Don't know what's wrong with the OK key. However, I think the collisions were added. Can you reproduce this in a small RTP game to isolate this problem and send it to me?


I'm not at the computer with my files in it at the present time, but I'll shoot this over to you later this evening.
You're able to start the game so I don't think the input is wrong. If there was something weird going on with the trigger system, then it would make sense why it seems like OK does nothing and nothing responds to collisions.
Rave
Even newspapers have those nowadays.
290
WolfCoder, did you consider publishing source of engine? More devs==faster work. Of course I wouldn't be able to help you, because I am not good at all with C++ (that's why I using gamemaking software in first place), but others may be able too. And if you set up SVN, you will be able to easily manage changes take of ones you don't want (probably ones that doesn't work or breaks existing functionality) and accept ones which you want.

//edit: And you should replace DX9 calls with appropriate OpenGL calls, because Wine still has problems with DX emulation. And using OGL will improve compatibility. Also you should consider using Audiere as music library, because PM2k3 uses FMOD and... wll, let's say that PM2k3 works perfectly on Wine... except sound.
WolfCoder, did you consider publishing source of engine?

It's up there in the link. Got the Visual Studio project files and everything.

More devs==faster work.

You're dead wrong. It doesn't work like that. It's been a wonder that I have been ahead of expected schedule too, it usually takes longer than you think to do anything.

And if you set up SVN, you will be able to easily manage changes take of ones you don't want (probably ones that doesn't work or breaks existing functionality) and accept ones which you want.

This is only true in a team. All by myself, SVN only makes the project harder and more annoying to work on. I use documentation for anything which cannot be reliably held inside my head, otherwise I am capable of remembering many many design details.

Adding more members means I have to write documents, set up SVN, and then give them enough information so that they can work optimally. Not only this, but I would have to find skilled programmers too which are hard to come by for free. My project is much faster if only I do it. By a factor of about 2.5 times, I figure.

Furthermore, adding more team members increases the amount of bugs. I've been going fine with minimal bugs so far and I would like to keep it this way for as long as it is possible.

I am already past the stage where I considered team work. I have reviewed the past projects of this nature and concluded that the best way to proceed is alone. This especially works well for a time-only cost project with no required deadline (I only need to be half as fast as my peers, but I would like to be as fast or faster). I would have to have planned this to be a team project for a start, and it would have been a small, tight team.

Notice how I'm neck and neck with EasyRPG and I'm not even trying to go fast at all (that Christmas Eve was a little too crazy for a hobby).

//edit: And you should replace DX9 calls with appropriate OpenGL calls, because Wine still has problems with DX emulation. And using OGL will improve compatibility.

Actually, OpenGL is a horrible idea if I want to implement all the advanced effects. OpenGL is actually less compatible because not everyone's video card vendor writes good OpenGL drivers for Windows. This is a Windows project because Windows is a gaming platform, whether this reality is one that we enjoy or not.

Also you should consider using Audiere as music library, because PM2k3 uses FMOD and... wll, let's say that PM2k3 works perfectly on Wine... except sound.

Well, that's nice. It's a good thing I'm not going to write this for Linux or Wine then I suppose.


The user base gain for spending an eternity adapting my engine to Linux or Wine is a tiny sliver, not worth destroying a perfectly fine project with. In the 10 or so years of me programming, this is the one time it's been going very well and I know a single mistake can ruin it. I know how hobby projects die all too well, and this is one way to dig a grave.
Welp, so there is not 1 but 2 engines currently being in the work (both "improvement" based on Rm2k3 engine). Great news.

I made similar suggestion (question?) to the RPGmaker 2009 ultimate and I thought it might be a good idea to post it here too :

Problems I find with Rm2k3
1. Changing Class graphic in battle (instantly applied?) Note: I think yours have this already
2. Ability to set stat value to x instead of adding/reducing it -x +x
3. Ability to change resistance/reduce stat like in SMT series (perhaps by “level”) so stat change skills is more strategic
4. Changing class while maintaining battle graphic (instead of making duplicate of class just to change resistance).

For the 4th, let's say you are making a Mecha game where you can select which system to use to set your resistance (done via Class). However you also want to allow the player to be able to use different Mechas in battle.

If you have 10 systems (10 different resistance/weakness) / Class, that means you will end up with 10 x N (N = no. of different mecha graphic in battle). Essentially cluttering the database with duplicates.

So if there is a way to select a class attribute THEN the graphic to the assigned class that would be nice.

I'd say the ability to change resistance in battle (ex fire shield for 1 turn) but that'd be asking too much methink

...
Of course if I misunderstood your project then I apologize in advance.

Cheers!