Quote:

If the PA3 engine will be used the battle mode is like DS6 which means no enemy sprites on the playing field...it could all work y'know

PA3 did have in-game enemies on the playing field. PA2 didn't.

Quote:

I would really like to see a new RPG made, and would also like to help in the graphics design department and coding. The point is making an RPG is not as easy as it seems. All this talk about a scrolling engine like YS2 and screen split and so is really nice, but I can bet it remains at talking about it. You are just getting too much "hay on your fork". Believe me, I speak from experience (*cough*roa*cough*) Im serious. If you use the PA3/Lost world engine, a good team of devoted artists can build a really fun rpg in less than a year. (I build Lost World all by myself). You just have to accept the shortcomings. No scrolling. No battles like Ys2. limited music files (wolf?). The most important part of a good RPG is a fun and interesting storyline anyway. The pa3/Lost world engine offers enough possibilities to support this.

Accepting shortcoming because it is less work might be efficient, but surpassing the existing stuff is the real challenge. I don't see a problem there, as long as there is a good coder that picks it up. Of course an RPG is mainly compelling because of the storyline and characters, that doesn't mean it is stupid to consider technical improvements. Research, resolve, evolve.

Of course, that is just my 2 cents

Oh and Thom..READ! In an earlier post Umax said:

Quote:

Of course there are some mayor shortcomings that you need to accept, such as no scrolling and a battle mode like DS6

That doesn't sound like real-time on-the-field battles like Ys does it?

Using a screensplit for the status bar actually makes things easier... It is a piece of cake to program and you have much less worries about which colours you can use. I already have a very tiny start for an RPG laying on my harddisk for ages which has this basic functionality. Works like a charm (on v9958 ).

And of course, an RPG doesn't need a border at all.

~Grauw

Quote:

Accepting shortcoming because it is less work might be efficient, but surpassing the existing stuff is the real challenge. I don't see a problem there, as long as there is a good coder that picks it up. Of course an RPG is mainly compelling because of the storyline and characters, that doesn't mean it is stupid to consider technical improvements. Research, resolve, evolve.

Sure, that is really cool, but it is also a hell of a lot of work. It might be years before something is finished, if ever.
How many amateur groups tried to make an RPG when MSX was still fully alive? How many succeeded? Why would it be different now?

Most of the talk in this thread has been about colors, palette and font.
You are going to build a house, and you are talking about how the paintwork will be done, while you have not given any thought yet about the foundations and main construction.

Wouldn't it be cooler to actually make an rpg using a simple engine that exists, then talk about how cool an rpg might be made with an extensive engine that doesn't exist?

And in Thom's defense, you did see the enemies walk around in PA3, only when you collided with them did the screen switch to battle mode. That's what he meant, and he is right.

Quote:

I would really like to see a new RPG made, and would also like to help in the graphics design department and coding.

Yeah, I was hoping the old Umax RPG thingy was still on tho. I was serious when I offered my help.

Quote:

The point is making an RPG is not as easy as it seems. All this talk about a scrolling engine like YS2 and screen split and so is really nice, but I can bet it remains at talking about it. You are just getting too much "hay on your fork". Believe me, I speak from experience (*cough*roa*cough*)

Well, the scrolling part I already did. That's not the hard part. Currently the screen split idea still stands too. I'm kind of aiming at the Illusion City effect where you do have a border but do a split to show conversations etc.

Quote:

Im serious. If you use the PA3/Lost world engine, a good team of devoted artists can build a really fun rpg in less than a year. (I build Lost World all by myself). You just have to accept the shortcomings. No scrolling. No battles like Ys2. limited music files (wolf?).

Errm, I'm not coding for nothing am I? ^_^

Quote:

The most important part of a good RPG is a fun and interesting storyline anyway. The pa3/Lost world engine offers enough possibilities to support this.

Well, that's as true as it gets. We all know SD-Snatcher is considered by many the best RPG ever and its no technical miracle.

Quote:

How many amateur groups tried to make an RPG when MSX was still fully alive? How many succeeded? Why would it be different now?

Better development tools. Really, it makes a huge difference...

Quote:

Using a screensplit for the status bar actually makes things easier... It is a piece of cake to program and you have much less worries about which colours you can use. I already have a very tiny start for an RPG laying on my harddisk for ages which has this basic functionality. Works like a charm (on v9958 ).

Well, yeah, but I think most people would prefer an RPG for the V9938. And since my engine is supposed to be an all-purpose engine I can't just assume that the player doesn't want a border. Keep in mind tho, that the border doesn't have to have the same pallete through the game. Many RPG's change the border colors from time to time to better suit the map pallette.

Quote:

Better development tools. Really, it makes a huge difference...

Yup, it took me only hours to rip the map and gfx from the first Gazzel map and to make a scrolling demo out of it...

I'd say that xdev'ing (is that an official verb now ? ) is a small effort for a person, but a giant leap for msx-development

Quote:

Errm, I'm not coding for nothing am I? ^_^

How far along are you?
If the scrolling is done, I'm guessing you already worked out how maps are build and have a map editor?
How about NPC movements across the map, collissions with NPCs, collissions of player and NPCs with walls, water, etc. Can the player walk behind trees and walls? How about battle? How about game program? (where do you code what should happen when a player collides with an NPC, door, chest, etc?)

If you worked all that out, that would be great.

I've a playable version of sonic's stuff here.. it acts like Xak ttog, but then w/o NPC's, without moving doors, and without the slowness of Xak

The slowness will come when you add those things

Although I'm sure Sonic can program it to run faster than Microcabin did

Quote:

Quote: Accepting shortcoming because it is less work might be efficient, but surpassing the existing stuff is the real challenge. I don't see a problem there, as long as there is a good coder that picks it up. Of course an RPG is mainly compelling because of the storyline and characters, that doesn't mean it is stupid to consider technical improvements. Research, resolve, evolve. Sure, that is really cool, but it is also a hell of a lot of work. It might be years before something is finished, if ever. How many amateur groups tried to make an RPG when MSX was still fully alive? How many succeeded? Why would it be different now? Most of the talk in this thread has been about colors, palette and font. You are going to build a house, and you are talking about how the paintwork will be done, while you have not given any thought yet about the foundations and main construction. Wouldn't it be cooler to actually make an rpg using a simple engine that exists, then talk about how cool an rpg might be made with an extensive engine that doesn't exist? And in Thom's defense, you did see the enemies walk around in PA3, only when you collided with them did the screen switch to battle mode. That's what he meant, and he is right.

I think this makes a lot of sense to use an already working, proven to be good engine. Who cares about a few limitations. Heck, if you don't like limitations, don't do a RPG on a MSX!

I've never played YS, SD Snatcher because of the scrolling (it's blocky anyway) but because it was fun to play, because it had a good feeling to it. The Zelda on the NES and Gameboy are the RPG that sold the most worldwide, and they didn't have a scrolling so truly if you guys are serious about making a RPG, I'd jump on the offer and use the PA3 engine, unless you prefer to waste a year or so of someone's time to add a minimal feature by re-creating a whole new engine. Now people, stop nit-picking and get your ass at work

About the limit of memory for music and such, I don't know how the PA3 engine works really but I agree with Wolf, 256kb is acceptable by today's standards.

Quote:

The Zelda on the NES and Gameboy are the RPG that sold the most worldwide, and they didn't have a scrolling

Zelda 1 on NES idd didn't, but the Gameboy Zelda's and NES' Zelda II all had scrolling. ^^;
But you are right, scrolling is often overrated...
Besides, I don't mind 8 pixel scrolling...

Quote:

How far along are you? If the scrolling is done, I'm guessing you already worked out how maps are build and have a map editor? How about NPC movements across the map, collissions with NPCs, collissions of player and NPCs with walls, water, etc. Can the player walk behind trees and walls? How about battle? How about game program? (where do you code what should happen when a player collides with an NPC, door, chest, etc?)

Well, the beauty of xdevving, as wolf so eloquently dubbed it, it that I won't have to make most of those tools. Scores of tools are already available for the PC that can create maps suitable for this. All that would be needed is a description on how to create the walk/event map.

Hmm, the rest I'll take point by point I guess...

1) NPCs have not yet been implemented.
2) Collisions with walls work already.
3) You can walk behind walls.
4) You can walk behind trees. (partially transparant objects)
5) Battle will be done by modules, explained further on.
6) Events are determined on the event map.

I haven't worked on NPCs yet, but my basic idea is to divide them in 'enemies' and 'NPCs'. A collission with an enenmy just fires up the combat module and passes along the enemy ID. The combat module should handle the rest from there on, only returning on victory and passing on the stat gains in a table. NPCs just trigger script mode, passing their respective ID. The 'user' (rpg maker) will then have to figure out how this event fits in his story line and act accordingly.

And advantage of the battle module thing is that more than one battle system would be an option. This could, eventually, allow for different battle systems such as those of Illusion City or perhaps SD-Snatcher. You could then also create a custom battle mod for a certain Boss or something like that.

Quote:

If you worked all that out, that would be great.

Well, I'm a long way from finding all that out. The most difficult part is setting up a scripting language that fits the many needs the user might have. It needs to be open enough to accomodate all sorts of RPGs, but limited enough to still be fast and to allow me to finish the project while we're all still alive ^_^