I should probably note, I know how to make games with limited art assets. The game I linked to used 25 sprites. This game will probably only use 60-75. It won't really affect the quality of the game because nobody looks at a game and says, it only had 60-75 sprites, therefore it's bad. But you do need to plan the game accordingly. I might end up using more, but we'll see.

I shall refer you to a thread on another forum, which is more art focused but still relevant http://wayofthepixel.net/index.php?topic=15726.0

And a guy you might like. One of the few to actually have some success in solo RPG making http://www.blossomsoft.com/gamedevs/

Don't worry, "flashing the FF card" on internet forums will always get you responses like you've gotten here. Doesn't mean you shouldn't do what you want.

My challenge to you is to create 30 minutes of fun gameplay, where all the artwork and music you see/hear is done by yourself.

As for how to approach it, first is story/design. The story is the core of the game, so spend as much time as you want on it to make it good. For gameplay design, just saying "FF6 like" eliminates a lot of the work for you. You just need to decide the specifics of the classic RPG formula you want to do. Then think up as many items/spells/monsters as you can. Then start making some real in-game artwork and music. The "vertical slice" approach. A couple map tilesets, a couple character sprites, a battle background, a couple monsters, a couple songs. Then do most of the programming.

Up to this point should be completed as quickly as possible (except the story)... maybe 1-6 months depending on your experience and the programming difficulty. Then you can get to the real work of the project, cranking out artwork and music, designing maps, and telling the story. Naturally, you'll encounter lots of stuff you forgot to program at first, and come up with new ideas along the way... just roll with it. That's why the pre-planned stage was considered quick and easy This phase takes forever, and will feel like you're not getting anywhere and will never finish most of the time. If you're like me, you'll have a tendency to abandon ship because your design wasn't good enough to be worth all the work still needing done.

Then comes testing/debugging/balancing. This is where you can see the light at the end of the tunnel, but you're still depressed at how far away it is. Usually work lots of overtime here.

Then finally you start running out of bugs and everything feels good and all of a sudden you notice it's actually a game and not just a random collection of features This is where you start putting on some finishing touches and can decide at any time when to call it done. Because it will never be done done.

My challenge to you is to create 30 minutes of fun gameplay, where all the artwork and music you see/hear is done by yourself.

That's a good challenge. I'm not that good with making music, despite owning the software I need for it.

I was planning on doing the art myself though.

I'm noticing you say only 60-75 sprites....the word only probably isn't a good one because that isn't really a small amount, though for this type of game it is. I'm guessing maybe when you mention FF, you are saying the style and gameplay, but not necessarily the length of time of story gameplay. If I'm right, than 60 -75 sprites is fine, but if you are going for that 20+ hours gameplay, you are going to get really repetive really quick with only that many sprites. Also, if you didn't, make sure you take into account the other graphics. You may be including your tiles as what you are calling "sprites" for this discussion, but if not, remember how much more time that will take up too.

About DekuTree's challenge, it is a good way to start. It is basically the plan I had, but only the to the second step. Then, if you like it, you could take the time to finish the art and gameplay, which(as said by other posters) will take the most time, and can be a long time if you plan for a full scale game.

EDIT***

I forgot to mention...someone mentioned using Blender for creating the sprites. I've done plenty of that myself. Using different settings, you can get pretty nice results, and you can even get different styles depending on the lighting, etc... But, I've never been able get anything smaller than 32x32 looking OK, and it takes 64x64 to actually look right to me, with 32x32 being OK'ish, but not really good. FF6 had I think mostly sprites of 24x24 for the characters. At that level, you can't get detail from a 3d render. You can probably get something to be recognizable, but between recognizable and minimal quality I'd say are two different things. If you decide to implement similar gameplay to final fantasy, but using a style with bigger sprites, than maybe 3d renders will work. In any case, the challenge is going to come if you want to go with a tiled world. I've never been able to get nice tiles out of 3d renders, except for blocky tiles. Things like grass etc... just don't work very well, and when they do, you have to do work to get things tilable anyway. On the other hand, if you do renders of full screens, instead of building the world out of tiles, 3d renders can probably work, though that will of course take more work too. It will also take up much more space for the graphics.Modern computers can handle it, but I wouldn't think you would want to try to put such a game on Google's Play Store due to the 50MB limit. It might be fine for iOS though. I only mention the mobile platforms since GMStudio can export to them and I had suggested it earlier in the topic, not because I'm assuming you would even care to port the game to somewhere besides PC.

ShadowFlar3, with all due respect, the technical difficulties in developing a 2D RPG these days isn't what it was in 1992 (I assume development on FF6 starter around then, but I didn't look it up). That's more than 20 years ago.

Development started December 1992. And yes, there are ample reasons why a game that to 35 people a year to make 20 years ago can be replicated with a much smaller group of people today.

For starters, not all of those people worked on just this one game during that year. Minoru Akao (credited as Sound Programmer), for example, was Square's resident audio programmer, and therefore worked on basically every game Square was making at the time. Thus 35 people over 1 year does not necessarily equal 35 man-years of work.

Additionally, a good deal of time had to spent simply to make sure the game actually fit withing the limitations of the hardware, on both the programming and artisic fronts. For example, a sizeable number of the game's visual effects involve drawing geometric shapes onscreen - to say nothing of things like the free-rotating tilted world map or the minecart sequence - which are significantly easier to implement nowadays than they were on the more limited SNES hardware. Even something as simple as having an enemy fade out (or opening a text window, for that matter) is far simpler today than it was on the SNES.

Next, the game was fairly cuting-edge at the time, technologically, including such advances as the use of a text font which is not tile-grid aligned (and in the US version, variable-width). Today we can print text in a variable-width font with a simple library call.

What WILL be almost as time consuming as it was 20 years ago, and will be the main stumbling block will be art creation. A game like FF6 will require hundreds of NPC character spritesheets, dozens of enemy sprite sheets, tilesets for each town. Depending on your art style you can save some time by 3D modeling and animating characters and rendering them out to sprite sheets, but if you're going for a FF6 art style I don't know how you can do that.

A bit nitpicky, but more like a few dozen NPC spritesheets (most of the NPC variety in a game like FF6 comes from palette swaps) and dozens of enemy sprites (full spritesheets not needed, since enemies in FF6 and in fact most 2D JRPGs are, with a handful of exceptions, not animated). And towns (and dungeons as well) typically don't have unique tilesets - in fact, the vast majority of towns in FF6 use one of two different tilesets (with a small degree of palette swapping for variety).

However, the loosening of hardware limitations over time means that producing all of that is still easier and faster now than it was then. For starters, the low resolution (256x224) and small characters (16x24) means that each individual pixel matters far more than at higher resolutions and sprite sizes - counterintuitively, it can take longer to make a small sprite look good than a large one.

Additionally, each character is constrained to 15 colors + transparent. The game has 14 playable characters, and it's possible for all 14 to be on screen at one time, but the hardware only has 8 sprite palettes, so some characters have to share palettes - in fact, because the characters can be on screen with NPCs and other sprites, the player characters are all restricted to using one of four palettes, meaning that color choices for one character will affect 2 or 3 other characters. And to top things off, one of those 15 colors in each palette is reserved for a universal shadow/outline color, so the character artist has, for each palette, 14 colors with which to color 3 or 4 different characters. Similarly, in FF6, monster images are limited to 15 colors (as are character portraits). None of this is a concern anymore.

The tileset for the overworld has to be carefully constructed, because the scaling/rotation requires the SNES be in video mode 7. And while mode 7 does allow for 255-color tiles (120 of those colors shared with the sprite palettes), it only supports a single background layer, and only 256 unique 8x8 background tiles.

Tilesets for town and dungeons have a bit more leeway, as these areas allow for 2 separate 15-color-per-tile background layers, as well as an additional 3-color-per-tile background layer (mostly used in FF6 for translucency effects like clouds or water). However, certain areas restrict that, reserving a layer or two for backdrops or visual effects. And because the translucency on the SNES has significant limitations, if you want to have, for example, a railing that casts a visible shadow on the ground below, you have to draw as set of ground tiles with that shadow baked in. Nowadays we can have as many layers of tiles as we want, using as many colors as we want, and the presence of an alpha channel means we can even include that railing's shadow in the railing tile itself and then layer it on top of any ground tile we want (instead of just the ones we drawn the appropriate shadowed tiles for).

Even the battle backdrops are limited to 15 colors in each 8x8 tile, and are further limited to 4 palettes total (so 60 colors per backdrop), as the other 4 background palettes are reserved for enemies (the Final Fantasy engine renders enemies as background objects - with a handful of exceptions - which also means that, since only one background layer is used for enemies, they can't overlap on screen). This means a lot of artist time spent making sure the backdrops look good even within those limitations - time that would not need to be spent today.

However things like event scripting and map editing are likely not notably faster and easier now than they were then, so there's that. Still, it's definitely possible nowadays for a team of two people to make a 5-10 hour JRPG in just a few months.

I'll throw out a different kind of challenge for you. Estimate what'll be required for this game before you start. Then you can look back when you're done and see how close you were.

For example, estimate the amount of times each "major module" will take. Like you did earlier in the thread, estimate how many sprites will be needed. And other estimates like that (# of sound effects, time to write dialogue, etc). Then have those estimates set aside somewhere (blog, Word or Google doc, notebook, whatever) so when you finish a module, you can note how long it took in that same place. when done with the game, you can look back at your estimates and how close they were for the whole project.

I'll throw out a different kind of challenge for you. Estimate what'll be required for this game before you start. Then you can look back when you're done and see how close you were.

For example, estimate the amount of times each "major module" will take. Like you did earlier in the thread, estimate how many sprites will be needed. And other estimates like that (# of sound effects, time to write dialogue, etc). Then have those estimates set aside somewhere (blog, Word or Google doc, notebook, whatever) so when you finish a module, you can note how long it took in that same place. when done with the game, you can look back at your estimates and how close they were for the whole project.

I like this idea as well. If nothing else, it will give you perspective for future projects, whether you actually finish this one or not. You'll then have a better idea if your estimates are accurate or if maybe for the next one you need to double(or triple) your estimates, or if maybe you are pretty realistic and come close.

I should probably note, I'm thinking about using 640x480 resolution for my game. This is higher than Final Fantasy VI's resolution and 640x480 is somewhere between retro and high-definition. I can't really go any higher than 640x480 because then it ceases to be pixel art, art focused on a single pixel, and becomes raster art.

I should probably note, I'm thinking about using 640x480 resolution for my game. This is higher than Final Fantasy VI's resolution and 640x480 is somewhere between retro and high-definition. I can't really go any higher than 640x480 because then it ceases to be pixel art, art focused on a single pixel, and becomes raster art.

There is nothing stopping you from doing a smaller resolution and scaling up. Games like Spelunky and Cave Story did this, and I'm sure there are others. This way you can keep your drawing resolution down and then have the engine scale it for you. I don't know for sure about Construct 2, but GameMaker can easily do this.

I think a resolution 1024x768 is a good target total resolution, although you could pick a widescreen as those are common enough these days. Then you would either halve or quarter it, leaving either 512x384 or even 256x192. If you like the retro style, that last one is closest to retro resolutions, and since you can scale it up it works fine. I wouldn't use any other resolutions than those two, except for widescreen versions. This is because they are in a good ratio with a standard resolution(1024x768) and so if you double or quadruple it, you can still get exact pixels, and so you don't lose anything from the pixel art. If you choose some random resolution, depending on what it is and how you scale, it can be more difficult to get crisp clean pixels. At least when going with the standard, you have a much higher chance of keeping things clean. The thing about 640x480 is that it is pretty high for pixel art, and if you go full screen with it, it isn't going to scale up as cleanly. It may work fine, depending on the video card and monitor, but I don't think it is even supported as a full-screen resolution anymore in some computers, which is why I'd say it is better to pick a more scalable amount and scale up to a more compatible resolution, like 1024x768, or a wide-screen variant.

I agree with the above post, stick with low res. 256x192 is good. Nintendo DS uses it, and it's very close to SNES. I'd recommend against widescreen. My current game (somewhere between FF1 and FF6 style) is on GBA and thus 240x160, which is a little cramped. Taller is better for these games, because the battle menu takes up a lot of vertical real estate.

High res pixel art is really hard, IME. 16x16 tiles and 16x24 sprites are my favorite, and look just right at 256x192.

If you ever want to chat about RPG making, feel free to message me :) I'm on MSN as my name here at hotmail.com.