WOLFCODER'S PROFILE
Search
Filter
Tileset Format
I see, that behavior was entirely an editor thing since the .lmu just had the weird tile codes in it. The old RPG Maker 20XX could render maps exactly as drawn, so it would explain why I couldn't find if that tile ever actually did anything in the spec I was working off of.
However, the adjacent option makes the tile not effect adjacent autotiles for all autotiles. I've never had to use the "Parent Background" feature before, but I might as well implement it otherwise I would be wasting a tile slot for every autotile file... Neither did the original chipset (it wasted an entire autotile slot for a grass tile that wasn't an autotile).
I mostly threw in the Update Adjacent flag so you could draw water like before, I ditched the old water tile format so any of the 16 autotiles may or may not be animated.
However, the adjacent option makes the tile not effect adjacent autotiles for all autotiles. I've never had to use the "Parent Background" feature before, but I might as well implement it otherwise I would be wasting a tile slot for every autotile file... Neither did the original chipset (it wasted an entire autotile slot for a grass tile that wasn't an autotile).
I mostly threw in the Update Adjacent flag so you could draw water like before, I ditched the old water tile format so any of the 16 autotiles may or may not be animated.
Basic Editor
I can't seem to figure out how RPG Maker 2003 had that single resize separator thingy between the tileset palette and the map tree. If scrolling around in the area I've provided you becomes too small, I'll just make it a floating tool window so you can make it tiny or huge and move it about (or close it / reopen it).
I think I'll do that.
I think I'll do that.
Font Engine
Sound Engine
That only works if you have WaveOut enabled on your system and that is all up to your sound driver. But if you do, then Audacity will do it.
But that's only if you're going to sell the game. Most of you would just grab RPG 20XX off the shelf and have fun.
I think this time around, I might look into having a version for Android since I found the Android NDK. I love how Google is trying to convince me that I don't want to write my engine in C/C++ but I thrive in low-level write-your-own-salvation quirky to-the-metal environments... Also want to use the same code base so I can give people new features and bug fixes for all platforms at once.
But that's only if you're going to sell the game. Most of you would just grab RPG 20XX off the shelf and have fun.
I think this time around, I might look into having a version for Android since I found the Android NDK. I love how Google is trying to convince me that I don't want to write my engine in C/C++ but I thrive in low-level write-your-own-salvation quirky to-the-metal environments... Also want to use the same code base so I can give people new features and bug fixes for all platforms at once.
Image Display
There is no such thing as "portable", really. But that wouldn't stop people. It does make it easier though. Let's get the engine to fit 2003's place first.
RPG 20XX will be a Windows program, but WINE will be a valid target (issues when running under WINE will be valid bugs to report).
I'm going to have a self-contained font engine (like LandTraveller) too.
RPG 20XX will be a Windows program, but WINE will be a valid target (issues when running under WINE will be valid bugs to report).
I'm going to have a self-contained font engine (like LandTraveller) too.
Coming Soon
Oh don't worry, I can't remember if I explained this out loud in a blog post somewhere or not, I'll explain here:
I spent 90% of my development time trying to get a piece of software to work with Enterbrain's bizarre formats and designs and quirks. Also don't forget having to constantly re-test functionality so that it's close enough to be compatible to 2003 games. With this gone, I can just make an engine. If you want software that actually works, testing will take MORE than the time it took to build it the first time. Being compatible with 2003 meant that the testing of 20XX would be even worse than a typical software project like this. I hate buggy rushed-out pieces of software as much as any user.
I agree, I even make fun of "new RPG maker come look!" threads myself. I'd like to promise you some deadline or something, but you'll want me to take my time with this. I wrote the spec in the newer blog post to actually be the thing you use to see how much progress I make when I report in.
That's another problem, tons of project authors post tons of stuff just to make it look like they're going fast. I want to outline clearly what RPG 20XX should do, what it should not do, and what features it must have so that you can judge how good a job I am doing.
This is just the nature of the beast of software engineering and software engineers. Personally I just wanted to do the original job the right way. It does seem like a harder project, but it's actually about 8 times an easier job than before... for the engine. Realize that an editor is required now. I know in advance I'm going to spend lots of time on it.
I have anticipated the editor being something else. That's going to be a tricky thing to make well. The biggest complaint I hear about open source toolkits is that "the interface sucks / is awkward".
Production has been halted after I posted the spec (see the newer blog post) waiting for comments. It will resume shortly. Typically it is my job to decide what features it should have to accomplish the tasks you will all give it, so it's not surprising the thread is silent. I anticipate people will speak up about the spec once I actually release test programs, but I can handle wildly shifting requirements. Specs should not be set in stone, they have to adapt to the task.
You should take a look though to see. I've made a simple set of 2003-like features that are both incredibly powerful but as easy to use or easier than the original 2003 (features like being able to change the battle system and calculations in the same way as event scripting!).
So how fast will development be? I'm sad to say it'll be slow since I just don't have the same kind of time anymore. I'm not working off donations or anything nor do I need em- money won't make me any faster or better. I got all the tools I need. What drives me for this project isn't fame or glory, it's actually exciting to me to see how people react to tools I write in order to create their own games. It's actually kind of scientific where I see all of you field test experimental software. How each of you attempt to use the software differently and the like as you come from a non-software engineer background (or sometimes you do!).
If you just scrolled down here for a quick answer, I have way more an idea of what is required, what I will do, how fast I will work, and implementing only the important features written down in the spec without drifting about or getting distracted. But don't expect any defined deadlines.
I spent 90% of my development time trying to get a piece of software to work with Enterbrain's bizarre formats and designs and quirks. Also don't forget having to constantly re-test functionality so that it's close enough to be compatible to 2003 games. With this gone, I can just make an engine. If you want software that actually works, testing will take MORE than the time it took to build it the first time. Being compatible with 2003 meant that the testing of 20XX would be even worse than a typical software project like this. I hate buggy rushed-out pieces of software as much as any user.
I'm just a little bit concerned that after what happened last time, and with all the other groups and people who're making open source rm replacements that always seem to disappear, that we won't see this materialize as a usable product.
I agree, I even make fun of "new RPG maker come look!" threads myself. I'd like to promise you some deadline or something, but you'll want me to take my time with this. I wrote the spec in the newer blog post to actually be the thing you use to see how much progress I make when I report in.
That's another problem, tons of project authors post tons of stuff just to make it look like they're going fast. I want to outline clearly what RPG 20XX should do, what it should not do, and what features it must have so that you can judge how good a job I am doing.
This is just the nature of the beast of software engineering and software engineers. Personally I just wanted to do the original job the right way. It does seem like a harder project, but it's actually about 8 times an easier job than before... for the engine. Realize that an editor is required now. I know in advance I'm going to spend lots of time on it.
I have anticipated the editor being something else. That's going to be a tricky thing to make well. The biggest complaint I hear about open source toolkits is that "the interface sucks / is awkward".
Production has been halted after I posted the spec (see the newer blog post) waiting for comments. It will resume shortly. Typically it is my job to decide what features it should have to accomplish the tasks you will all give it, so it's not surprising the thread is silent. I anticipate people will speak up about the spec once I actually release test programs, but I can handle wildly shifting requirements. Specs should not be set in stone, they have to adapt to the task.
You should take a look though to see. I've made a simple set of 2003-like features that are both incredibly powerful but as easy to use or easier than the original 2003 (features like being able to change the battle system and calculations in the same way as event scripting!).
So how fast will development be? I'm sad to say it'll be slow since I just don't have the same kind of time anymore. I'm not working off donations or anything nor do I need em- money won't make me any faster or better. I got all the tools I need. What drives me for this project isn't fame or glory, it's actually exciting to me to see how people react to tools I write in order to create their own games. It's actually kind of scientific where I see all of you field test experimental software. How each of you attempt to use the software differently and the like as you come from a non-software engineer background (or sometimes you do!).
If you just scrolled down here for a quick answer, I have way more an idea of what is required, what I will do, how fast I will work, and implementing only the important features written down in the spec without drifting about or getting distracted. But don't expect any defined deadlines.
Coming Soon
Better to start over, it's easier and will have less bugs occur. The specs will be completely different, so the old engine's design won't work.
Coming Soon
Just posting to let you know I had some business to take care of since last week, the specs for RPG 20XX will be posted sometime between tomorrow and the 14th. Then you all can review them to see if I missed anything or if something looks wrong.
Coming Soon
Whenever I finish the spec, it will be posted. Since it will be a new engine, it will be required to make sure I hit all the desired features and to measure progress.
Or, if you want to make stock resources, the spec will tell you exactly how to lay out the sprite sheets and then you can just make/format them. The engine can set to any 'asset scale' but anything bundled with RPG 20XX will need to be in the familiar retro 1x 320x240 scale (16x16 instead of VX's 32x32).
Or, if you want to make stock resources, the spec will tell you exactly how to lay out the sprite sheets and then you can just make/format them. The engine can set to any 'asset scale' but anything bundled with RPG 20XX will need to be in the familiar retro 1x 320x240 scale (16x16 instead of VX's 32x32).














