Current Project: RPG Toolkit, codename "M3"

[Ra]

It might stretch the software a great deal, but what about shapechanging characters like lycanthropes? Would they be feasable on this program, or would it be a coding nightmare?

[Ace Pace]

Would "downstream" in a boat be faster than "upstream"?

This is going to be harder to do, the direction of the stream (or wind or whatever) will need to be known to do this.

There two ways of accomplishing that:

1. Let the engine randomly create a direction, the content creator has no control, and just sets a flag in the vehicle file if it is affected by the stream.
2. Or make it controlled by the content creator somehow. It could be a tile characteristic, but that would be pretty useless, considering that most the ocean will be the same tile over and over again. It could also be a layer on the map.

I prefer option #1 for this, since #2 introduces more complexity to the dungeon maps, meaning even more time needs to be taken in creating one.

Another option is, aslong as the artist is not a doofus, you basicly have a reversible water animation. So acording to the flag on the river as a whole, you can flip the animation sequence around.

[Destructionator XV]

Well, to that I pose a question: Are we using a 'Job' system? If so, could there be a secondary class of 'Jobs' that can only be gained after dabbling in two? Ups the replay a bit, I think, if you make them worth it.

Yeah, you would just set the prerequisites of the new job so you need to gain a few levels of the other jobs first

In effect, he can replace himself with a character who is slower, non-magical, and but has truly devastating physical attacks, and very hard to kill.

I think I am going to have to do a summon system where a character is swapped out for another character (which can be created to be summon monsters).

It might stretch the software a great deal, but what about shapechanging characters like lycanthropes? Would they be feasable on this program, or would it be a coding nightmare?

Well, doing this with the above mentioned summon system, having a character be replaced by another character for the duration of the battle (or until unsummoned) would start to do this effect.

Adding in a way for the summoned monster to have its stats derived from the summoner and be automatically unsummoned at end of combat, and HP loss taken into account (which would simulate shapeshifting) shouldn't be very hard at all.

[Ra]

Well, doing this with the above mentioned summon system, having a character be replaced by another character for the duration of the battle (or until unsummoned) would start to do this effect.

Adding in a way for the summoned monster to have its stats derived from the summoner and be automatically unsummoned at end of combat, and HP loss taken into account (which would simulate shapeshifting) shouldn't be very hard at all.

Awesome.

Just to note, I've also made some progress on my sprite work, having done most frames for a 16 x 16 thief character, and single frames for a few others. They're turning out pretty nice. Although, that eagle I drew looks a little wierd.

[Destructionator XV]

As you will remember in my first post here, I gave an argument on why I wanted to reduce the in game resolution to 320x240 from my original plan of 640x480.

But there is an alternative I did not address at that point: increasing the tile size from 16x16 to 32x32. Increasing the tile size would have the same effect on gameplay and map creation as decreasing the resolution, and would allow the artists to add more detail to their tiles.

The down sides would be increased file size for tile art, but this is going to be small thanks to png compression, and unimportant since a couple kilobytes per frame is nothing compared to the size of hard drives.

Art might take longer to create, but the artist could always just scale up their 16x16 art they would have used, which is a 2:1 ratio, and will maintain the same quality. Allowing for more detail in the tiles will probably make art faster and easier to develop, since they can just let their creativity flow.

Also, this means backgrounds are bigger; again, allowing more quality is just going to be a good thing.

The increased resolution will also allow me to use better antialiasing on the drawn primitives and text, making them look much better. Animations may be smoother too, but that might take an increase in timer resolution, which I don't feel is needed at this time, but will investigate further once I have the tile editor starting to work.

So yes, I have changed my mind again from the first post. The in game resolution is being returned to 640x480 and tile size increased to 32x32 pixels. Number of colours remains unlimited, and always will.

[Ace Pace]

One thing to consider, Ra, is you need everything to be transperency enabled.

[Destructionator XV]

One thing to consider, Ra, is you need everything to be transperency enabled.

Though if he doesn't do that himself, I can just run the files through one of gimp's batch antialiasing filters, which should add it automatically and look really good.

[Ace Pace]

On another note, does the graphics engine automaticly do Anti Aliasing? If so, what kind since some types of AA can cause text to look blurred.

[Destructionator XV]

On another note, does the graphics engine automaticly do Anti Aliasing? If so, what kind since some types of AA can cause text to look blurred.

It does for primitives (circles, polygons, etc) and text on the main screen (not in user controlled animation sub-buffers), but not sprites or images.

I'm not sure what kind it does, since I am going to allow the Qt engine to do it all for me. If it looks bad though, I can turn it off with a simple flag to the toolkit.

Actually, drawing text with the build in functions in Qt might look weird on some systems; I can't assume everyone has the same fonts as I do. Unless I include one with the program, which I just might do.

[Ace Pace]

Just include, always better and looks good.

[Ra]

Alright... I'm not able to do the transparencies myself, unfortunately, but I have screwed around with simply doubling the size of the sprites I already made.

Thus I get this with a fighter sprite:


Much larger, really.

I'll go back and make new 32 x 32 sprites anyway, due to the far greater detail allowed, since it's certainly no bother. Though... *thinks* if I were going for more "realism", 16 x 32 would allow for slimmer characters. It won't have quite the "cute and classic" cRPG look, but like it either way. I'll try both and see how they work. I quite enjoy drawing these sprites.

[Destructionator XV]

That looks really good, excellent work!

And since I increased the size, valid character sizes will be 32x32 for the classic look and 32x64 for the tall (more realistic) look.

[Ace Pace]

That looks really good, excellent work!

And since I increased the size, valid character sizes will be 32x32 for the classic look and 32x64 for the tall (more realistic) look.

Are you saying we can have dynamic character sizes?

[Destructionator XV]

Are you saying we can have dynamic character sizes?

I was thinking about making it a switch in the game config file, you pick your preference before hand, but there is no real need for that either since both sizes can interact just fine with eachother.

I actually see no reason why a character couldn't have both tall and short sprites if you wanted. I'm not sure why you would want to, but you could.

[Ra]

I've been getting some problems trying to draw the taller sprites at 32 x 64, namely the fact that my drawing skill isn't quite up to par with larger images. *sigh* I was rather good with tiny ones, so I may just size them up from 16 x 32, as before.

So, does the game exactly need tall sprites in it as well as the munchkins? I'm unsure on the matter.

[Ace Pace]

It dosn't need, but it can use them.

Adam, for travelling map, will it shrink the image or use specialised frames?

[Destructionator XV]

I've been getting some problems trying to draw the taller sprites at 32 x 64, namely the fact that my drawing skill isn't quite up to par with larger images. *sigh* I was rather good with tiny ones, so I may just size them up from 16 x 32, as before.

Yeah, scaling it up will be fine. The bigger thing just allows you to use the details if you wanted to; you certainly don't have to.

I actually prefer the classic look myself.

So, does the game exactly need tall sprites in it as well as the munchkins? I'm unsure on the matter.

Nope. Just another option, one that is easily ignored.

Adam, for travelling map, will it shrink the image or use specialised frames?

It will use the same image everywhere in my current plan. Might change that though, as specialised battle or town sprites might be interesting, but using the same sprite in all situations is easier to do, quicker to create, and looks fine (look at all the classix cRPGs).

[Destructionator XV]

Well, I have decided to do the vehicle class and editor, a new component based off Mayabird's ideas before doing the tile editor, which was going to be my next step.

The reasoning for this is simple: tiles need to know about vehicles to be made. Since the walk, land, and dock flags are now dynamic (I allow you to make custom cars, etc), the tile editor has to know how many vehicles you have in the template, and preferably their names, to aide you in creating the flags. It would be quite a hassle to have to refer to them by number all the time!

A tile can also set default flags for vehicles about which it does not know. That way, tiles can be more easily reused in different games, which may have different vehicle sets.

The vehicle editor will be written in a stand alone style, meaning it will have its own main window and can be invoked without needing to know the whole game state. It will be able to save and load vehicle set definition files: one large file that contains all the vehicles you want in your set.

The game should be able to load multiple vehicle files at once and merge them, but that is not a concern of the vehicle editor window itself (though it is a concern of the internal vehicle set class code).

There are two internal classes relating to vehicles themselves: vehicle and vehicleset. Vehicleset will probably simply be implemented as an array of vehicles. I will make that decision when I start writing code.

Vehicles shall not be directly accessible from inside scripts. To add vehicles for character use, they are added to the party's key item list.

The vehicle editor window will consist of two parts: a dock widget on the side, which contains a list of all vehicles in the set, and a main widget in the center, which displays and allows editing of details of the selected vehicle from the set.

The vehicle data is rather simple:

• Name. The name is what appears in the player's inventory, and is used for your convinence in the tile editor.
• Animations. These are the animations of the vehicle pointing in all 4 or 8 directions (depending on if you want to support diagonals). You create these animations in the animation editor, and double clicking one of these animations will allow you to open the animation editor automatically loaded with the file in question.
• Speed. This is how fast the vehicle moves across the map, in tiles / second.
• A flag that determines if the speed is affected by the stream or wind or whatever.
• A flag that tells if you have random battles in the vehicle. (Might actually be a value which overrides or alters the current tile's xdec value.
• A flag that determines if you can "rush" in the vehicle (like holding cancel to run in Chrono Trigger)
• Oh man, fights from inside the vehicle, like in Phantasy Star 4. These were awesome. You would be driving around in your Ice Digger and stupid creatures would attack and you could blast them to shreads with the vehicles laser cannons.
  
  I need to support that, but not sure how yet. Will ponder that. This changes many things about battles: backgrounds, possibly your characters entirely, maybe even the battle forground (in PS4 the place where your character's stats would be were replace with an awesome looking hi tech dashboard animation).
• edit A flag that determines if the vehicle is carriable. If this is set, you invoke the vehicle from your inventory, or it can be automatic (see below). If not, the vehicle is parked somewhere, like normal boats.
• edit A flag that determines if the vehicle is automatic (meaning you get into it when needed automatically, like FF1's canoe)

Time to get started, how exciting!

[Destructionator XV]

Something you guys should look at if you have never played Phantasy Star 4 before:

Screenshots!

Look how awesome the graphics are. That game had so many good ideas in it, what high quality.

Note in particular the shots captioned "Walking high above" and "vehicle battle". Those are even cooler animated: the lights would blink, the markers on the elevators would move, the background below the characters would move with you, but slower, so it actually looked 3d. In some dungeons, the background was actually the floor under it, darkened and shrunk so it looked like it was seen from above. I will be supporting that with map background flags in a sense.

The game also had anime style cutscenes, but on the Genesis, they wouldn't be full motion, so they used the great idea of just having a few static images painted on top during the dialog to make it interesting. I will be supporting that via the pixmap interface in M3's script system.

That game provided me with much inspiration.

[Something Awesome]

That game provided me with much inspiration.

This would suggest that you might do custom battle sprites? PS IV (and II) have different animated battle sprites. Heck, each character had tons of battle animations, like just standing there, casting magic, long range weapons, close combat weapons, special attacks...It sounds like the battle system is similar to Phantasy Star's anyway, so it would look like an even cheaper knock-off without battle animations.

[Destructionator XV]

The battle system is actually nothing like Phantasy Star's. The battle system is aiming more toward Final Fantasy 6 right now, which had lame as hell battle animations. Which is good, because drawing nice animations for every weapon or for every character and writing code to have them run up to the enemies is hard. Though making them teleport over to the enemies will be easier.

I dunno, I'll decide battle system specifics later.

[Mayabird]

Ooooh, pretty.

While you're working on vehicle sets, do you just have sailing, traveling on land, and flying in mind? Could there be submarines also (like FFVII), underground travel (as in FFIV), or space travel (as in so freaking many of them)?

I'm on my lunch break now, but I'll work on some music when I get off work.

[Ra]

The sprites on that game certainly look awesome, so I definitely feel more comfortable with working on the tall sprites now. As for vehicles, we've mentioned submarines and airships, but I think I'll also try to draw a horse or drake, or some other more fantastic mount.

[Destructionator XV]

Could there be submarines also (like FFVII),

I really liked that, so I think I will make it work, and the coding shouldn't be too hard, and will also support something like FF4 had.

Basically tie a couple maps together and make the land button do something special. Instead of disembarking from the vehicle, it goes to a different map, in the same x,y position.

Need to add a flag to support that and entering flying towns (or make events triggerable from certain vehicles, that makes much more sense)

or space travel

I like the Phantasy Star method of space travel: you go to the space port, pick your destination, the game cuts to a short scene of the ship taking off, flying through space, and landing, then you regain control at the destination spaceport.

So space travel would be an instance of a cutscene, not a vehicle, since it is not really player controlled.

Also, it could be done in a similar method to the submarine or underground worlds, like FF4 did: you fly around in it like a normal airship, but you press cancel and fly to the moon or wherever.

And also supporting a map like the interior of the Highwind would be cool to do, and again not too hard, just a few more data members in the vehicle class and a kind of persistant storage (I'll take care of remembering where you were in the code).

As for vehicles, we've mentioned submarines and airships, but I think I'll also try to draw a horse or drake, or some other more fantastic mount.

Sounds cool.

[Ace Pace]

Space travel can just be loading an entirely new world map thats basicly stars and stuff, no need for specialisation then, only for differant data.